The Frontier
3 left
Compute & power

CUDA 13.4 operator stack: Windows on Arm, Rubin preview, MPS V3, and a CDMM default flip

NVIDIA's 9 September 2026 toolkit release extends CUDA to Windows on Arm, previews Rubin (sm_107), modernizes shared-GPU control, and changes memory-management defaults on coherent platforms.

4 min readFrontier Surveycuda, cuda-13-4, mps, cdmm, windows-on-arm, rubin, nvidia, operator

Share

What it does

CUDA Toolkit 13.4 is the operator-facing toolkit and driver-control release that ships Windows on Arm support, early Rubin architecture access, and a redesigned shared-GPU control plane.

Primary: Jonathan Bentz, CUDA Toolkit 13.4 Adds Windows on Arm Support and Greater Control over Shared GPUs, NVIDIA Developer Blog, 9 September 2026.

Operator-relevant surfaces in the primary:

  1. Windows on Arm. CUDA applications already ran on Arm under Linux. 13.4 extends that path to Windows on Arm.
  2. Rubin preview (compute capability 107). Functional support for NVIDIA Rubin as a preview so developers can begin porting before GA in a future toolkit. NVCC gains the SM_107 target. Core math libraries also get functional Rubin support.
  3. Multi-Process Service V3. Modernized control layer for shared GPUs: scriptable CLI, named server instances, namespaces, TOML configuration, SM partition controls, and cgroup-integrated GPU memory limits. Aimed at containerized partitioning with programmatic compute, memory, and priority boundaries.
  4. CUDA Compute Fabric Transport (CFT). Transport-centric Driver API for moving data across NVLink fabric via named logical endpoints (endpoint ID + offset) with asynchronous put, get, and reduction. Intended for communication-library developers. Most application teams should stay on NCCL or NVSHMEM per NVIDIA.
  5. Locality domains. Programmatic access to GPU partitions that contain SMs and device memory. Allocate memory and green contexts in the same locality domain to keep compute near the data on multi-domain devices.
  6. Unified-memory residency queries. cudaMemGetLocationInfo and related support so libraries can see where managed or system-allocated data currently resides.
  7. Driver / toolkit split. CUDA SDK installers no longer bundle the NVIDIA driver. Install nvidia-open driver or cuda-toolkit packages separately.
  8. CDMM default on coherent platforms. On Grace Hopper, Grace Blackwell, and Vera Rubin, the driver defaults to Coherent Driver-based Memory Management instead of NUMA. NUMA remains supported via a kernel-module parameter. The mode is node-wide and needs a driver reload or reboot. NVIDIA says select the mode before upgrading.

Also in the release (secondary for most cluster operators, primary for library teams): cuda.core 1.1.0 texture/surface and NUMA-aware managed memory; cuda.compute 1.1 ahead-of-time CCCL serialization; CCCL 3.4 Blackwell DeviceScan bandwidth gains and single-call CUB overloads; Nsight Python 1.0; Nsight Compute / Systems updates for CUDA 13.4 and Rubin; cuBLAS Grouped GEMM and FP8 scaling-mode experiments on Blackwell.

Why now

  • Rubin bring-up. Preview sm_107 lets ISVs and internal stacks compile and smoke-test before Rubin GA.
  • Shared-GPU density. MPS V3 answers the operator need to partition one GPU across containers with scriptable limits rather than ad-hoc MPS flags.
  • Coherent CPU-GPU platforms. CDMM as the default acknowledges that Grace-class and Vera Rubin coherent memory wants a different default than classic NUMA assumptions.
  • Windows on Arm laptops and N1X. Extends CUDA beyond Linux-on-Arm for that client path; core math libraries also cite Windows on Arm for the N1X laptop ecosystem.
  • Install hygiene. Decoupling driver from toolkit matches how Linux package managers already want to version those layers separately.

Maturity (as of the 9 Sep 2026 primary)

SurfaceMaturity signal in primary
Windows on ArmShipped support in 13.4
Rubin / sm_107Explicit preview; GA in a future toolkit
MPS V3Documented with quickstart; treat as new control plane
CFTDriver API only; for communication-library authors
Locality domainsDocumented in Programming Guide path
CDMM defaultProduction default flip on coherent platforms; NUMA still selectable
Driver/toolkit splitInstaller behavior change; package-manager path

Field validation numbers for MPS V3 isolation under production orchestrators: UNKNOWN beyond NVIDIA's description. Independent third-party CDMM migration case studies: UNKNOWN in this primary.

Pick vs

Reach for CUDA 13.4 now when:

  • you need Windows on Arm CUDA builds;
  • you are preparing Rubin ports and can accept preview sm_107;
  • you want MPS V3's TOML / CLI / cgroup memory controls for multi-tenant GPUs;
  • you operate Grace Hopper, Grace Blackwell, or Vera Rubin nodes and must consciously choose CDMM vs NUMA before the driver upgrade.

Stay on an earlier 13.x toolkit when:

  • your certified stack pins an older toolkit/driver pair and you cannot absorb CDMM or installer changes this cycle;
  • you have no WoA, Rubin, or MPS V3 requirement and change windows are frozen.

Use CFT only when:

  • you build communication libraries that need endpoint-ID fabric transfers NCCL/NVSHMEM do not expose.

Prefer NCCL / NVSHMEM when:

  • you are an application or serving team (NVIDIA's own guidance in the primary).

Failure modes

  1. CDMM surprise. Upgrading coherent nodes without selecting NUMA first locks the node onto CDMM until a reload/reboot with the module parameter. Apps that assumed NUMA topology semantics can regress.
  2. Driver not in the SDK. Automation that expected the toolkit installer to bring a driver will leave nodes without a matching driver.
  3. Preview Rubin binaries in prod. sm_107 is preview. Shipping production artifacts against it before GA risks ABI and performance churn.
  4. MPS V3 misconfiguration. Named instances, namespaces, and cgroup memory limits are powerful. Wrong TOML or missing cgroup integration can starve or overcommit tenants.
  5. CFT misuse. Application teams calling CFT instead of NCCL/NVSHMEM inherit Driver-API complexity and incomplete higher-level semantics.
  6. Locality-domain ignore. On multi-domain GPUs, allocating memory in one domain and running SMs in another leaves performance on the table.
  7. New host-compiler targets. Host compatibility adds GCC 16 and Clang 22; these are newly supported compilers, not a raised minimum floor. Teams that opt into them must refresh build images; teams on older still-supported hosts are unaffected by that bullet alone.

Operator read

Treat 13.4 as three separate decisions: (1) toolkit bump for WoA / libraries / Rubin preview, (2) driver bump with explicit CDMM vs NUMA choice on coherent platforms, (3) MPS V3 adoption for shared-GPU fleets. Do not conflate this release with CUDA Rust tracks (separate live Stack piece). Schedule a dry-run node that exercises CDMM default and MPS V3 limits before fleet rollout.

CDMM white-paper deep dive and fleet-wide migration metrics: see NVIDIA's linked CDMM materials; independent operator telemetry remains UNKNOWN.

Share

Cite this piece

Canonical URL

https://www.thefrontier.dev/articles/cuda-13-4-operator-stack

Attribution

The Frontier, “CUDA 13.4 operator stack: Windows on Arm, Rubin preview, MPS V3, and a CDMM default flip”, 20 Sept 2026

TLDR

NVIDIA's 9 September 2026 toolkit release extends CUDA to Windows on Arm, previews Rubin (sm_107), modernizes shared-GPU control, and changes memory-management defaults on coherent platforms.

Plain text

Frontier Survey. “CUDA 13.4 operator stack: Windows on Arm, Rubin preview, MPS V3, and a CDMM default flip.” The Frontier. 20 Sept 2026. https://www.thefrontier.dev/articles/cuda-13-4-operator-stack

BibTeX

@misc{frontier_cuda_13_4_operator_stack_2026,
  title = {CUDA 13.4 operator stack: Windows on Arm, Rubin preview, MPS V3, and a CDMM default flip},
  author = {{Frontier Survey}},
  howpublished = {The Frontier},
  year = {2026},
  month = sep,
  url = {https://www.thefrontier.dev/articles/cuda-13-4-operator-stack}
}

Full text may be reprinted with canonical link and byline.

Related reading