CUDA 13.4 tells you to pick your GPU memory mode before you upgrade the driver

"Functional support ... as a preview" is a careful phrase, and NVIDIA's release note uses it for Rubin at compute capability 107 ^[2]. Read it as builds-and-runs. No Rubin performance figure appears in the note, and the general availability date is given only as a future toolkit release ^[2].

So the porting work that survives to GA is the plumbing, not the tuning. For a preview port to pay off later, two things have to hold: the target identifier stays 107, and codegen and library behaviour do not move between preview and GA. The release note commits to neither ^[2]. What it does buy you now is the boring half of the job: finding every place your build matrix, your CI images and your runtime dispatch enumerate a fixed list of compute capabilities, and getting a new one through them.

Windows on Arm is a similar shape of claim. Arm CUDA has meant Linux until now, and 13.4 extends application support to Windows on Arm ^[1]. The announcement does not enumerate supported devices, drivers, or which of the CUDA libraries ship for the target ^[3], so parity with x86 Windows is not something you can read off the note. It is a build target you can now attempt.

Two items in this release change existing behaviour rather than adding any ^[4]. The SDK installers no longer bundle the driver, and you install nvidia-open or the cuda-toolkit packages separately through your package manager ^[5]. And on coherent platforms, which the note lists as Grace Hopper, Grace Blackwell and Vera Rubin, the driver now defaults to Coherent Driver-based Memory Management instead of NUMA ^[6]. NUMA mode stays fully supported, selected with a kernel module parameter, and NVIDIA's instruction is explicit: if you plan to use it, make the change before upgrading ^[6]. That instruction is the mechanism. A module parameter is decided when the driver loads, so the cheap moment to choose is the same maintenance window as the upgrade, and the expensive one is after a coherent node comes back up presenting its memory differently than your placement logic expects.

The rest of the release reads as one theme. MPS V3 adds a scriptable CLI, named server instances, namespaces, TOML configuration, SM partition controls and cgroup-integrated GPU memory limits ^[7]. Locality domains become programmatically addressable, so an application can allocate device memory in a domain and create a green context with SM resources in that same domain ^[8]. A residency query for unified memory, cudaMemGetLocationInfo, lets a runtime ask where managed or system-allocated data actually sits before it schedules against it ^[9]. Compute Fabric Transport replaces mapping every remote GPU allocation into a process address space with named endpoints addressed by ID and offset, plus asynchronous put, get and reduction operations issued from the GPU ^[10]. It is driver-API only, and the note tells most application developers to keep using NCCL or NVSHMEM ^[11]. An API whose own announcement points most readers elsewhere is refreshingly scoped.

On a Grace or Vera Rubin node, the toolkit bump is the easy part of adopting 13.4. The part that needs a scheduled window is deciding which memory mode the driver comes up in ^[6].