Supercharging SAS Model Manager with CAS Gateway (Part 2: The Standard Workflow)

[#1]

In Part 1, we introduced the CAS Gateway concept and the key bottleneck it solves: serialization overhead. We saw that keeping data in memory and avoiding data serialization is the critical factor in accelerating Python/R scoring.

Now, let’s see this in action. How does SAS Model Manager use this capability today, out of the box?

In this three-part series, we will unpack this technology:

• Part 1 explores the concept and architecture.
• Part 2 (this post) explains how SAS Model Manager leverages this today (The “Comfort” Zone).
• Part 3 explores how to unlock maximum performance using code (The “Power” Zone).

The “Easy Button” for Data Scientists

SAS Model Manager prioritizes ease of use and governance. You don’t need to write complex distributed code to benefit from CAS Gateway.

CAS Gateway is enabled by default in the SAS Model Manager UI, there is nothing you need to toggle. If you want to verify a run, check the “Scoring Tests” log; you should see an entry such as: Added action set ‘gateway’.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Or via Python code using sasctl:

# Create score definition configuration
  score_definition = sd.create_score_definition(
  score_def_name='HMEQ_score_def_10000x_gw',
  model=model_uuid,
  table_name='HMEQ_10000_SHUFFLED',
  use_cas_gateway=True,  # --- Model Manager enables this by default; shown here for clarity
)

What Happens Behind the Scenes?

By default, SAS Model Manager performs a sophisticated orchestration. It doesn’t just “run your pickle file”. It creates a wrapper environment to ensure your model executes safely within the CAS architecture.

1. Wrapper Generation: Model Manager generates a Python script that imports the gateway module.
2. Execution: This script is submitted to the CAS gateway.run action.
3. Data Access: The script uses gateway.read_table() to pull data from CAS memory into a Pandas DataFrame (via Apache Arrow).
4. Scoring: Your model (loaded from the pickle file) scores the DataFrame.
5. Result Return: The script uses gateway.write_table() to push results back.

The Standard Configuration: Safety First (single=True)

Here is a critical detail for technical architects and data scientists: By default, SAS Model Manager configures this execution with the parameter single=True (which implies nthreads=1).

This means:

• Execution: The Python code runs on a single CAS worker node, not distributed across all nodes.
• Threading: It uses a single thread for execution.

Wait, isn’t distributed processing the whole point?

Yes and no. While CAS Gateway can run on every node (massively parallel processing), the primary bottleneck for most mid-sized data (1M - 10M rows) is data transfer, not compute.

By moving the Python process to the data node (even just one node) and using Zero-Copy memory access (Apache Arrow), we eliminate the network I/O and data serialization costs. This alone provides the performance boost we observed in the benchmarks results I shared in “Part 1”.

Why Single Node?

Running Python code distributed across many nodes introduces complexity:

• State Management: If your model needs global state (like a cumulative sum), running it in slices on different machines breaks the calculation.
• Resource Contention: Launching 50 Python interpreters on a busy cluster consumes significant RAM.
• Simplicity: A single-threaded execution model is deterministic and easier to debug.

For the substantial proportion of “score test” scenarios, the single-node approach is the perfect balance of speed and stability.

Note: SAS R&D is actively evaluating the possibility of switching from single=True to single=False as the default in future releases, as well as optimizing the nthreads settings. This would bring distributed processing power to the standard workflow without requiring custom code.

Next Up

But what if you do have 100 million rows? What if “7x faster” isn’t fast enough? In Part 3, we break the glass. We will show you how to write custom code to override the defaults, setting single=False and unleashing the full parallel power of your CAS cluster.

TL;DR, Prerequisites, and Security

TL;DR: SAS Model Manager enables CAS Gateway by default to improve scoring performance by running model code next to the data (zero-copy via Arrow). The default single=True configuration prioritizes safety and debuggability; use distributed execution only when you intentionally need cluster-wide parallelism.

Prerequisites: - SAS Model Manager 2025.01+ with CAS Gateway support enabled. - SAS Viya LTS 2024.09+ and Python 3.10+ available on worker nodes. - pandas, pyarrow, and swat installed in the Python environment used by the gateway.

Security / Trust note: The wrapper generated by Model Manager will execute code on CAS workers; ensure model artifacts (pickles, Python modules) are from trusted sources and have been code-reviewed. Avoid untrusted pickles and consider using signed model packages.

Find more articles from SAS Global Enablement and Learning here.