CUDA Toolkit 13.4 is the release that makes the RTX Spark laptops buildable before they exist. It adds Windows on Arm as a target, drops a first developer preview of Vera Rubin into the same package, and rearranges what a Linux CUDA install actually puts on the machine.
Windows Arm64 becomes a build target
CUDA has run on Arm through Linux for years, and 13.4 extends that to Windows. How far it extends depends on which NVIDIA document is open: the release notes scope it to RTX Spark devices, while the release-day summary describes developers preparing Windows Arm64 applications now. The narrower reading is the safe one. Either way the work available today is porting Arm64 builds, validating dependency chains, and finding out which libraries have no Arm64 story at all, because the hardware follows in October. Tom's Hardware detailed the two N1X configurations when the platform was named, and we went through what the N1X memory tiers actually hold.
The driver floor is the part worth writing down. CUDA 13.4 corresponds to the R615 branch. Existing CUDA 13.x applications keep running on anything from 580 upward under minor version compatibility, but the new features and the newly enabled platforms need R615 or later, and the release notes put the Windows driver for the RTX Spark device at 616.41 or later. Build hosts and target machines drift apart on exactly this, and the failure it produces is a binary that builds cleanly and then refuses to load on the newer platform.
Vera Rubin arrives in the same release as a developer preview, with functional support for compute capability 10.7 and the sm_107 target. NVIDIA states plainly that it is not intended for benchmarking, performance analysis, or production deployment, which applies to every Rubin number a 13.4 toolchain produces. The most concrete figure sits in cuBLAS, where emulated FP64 matrix multiplication now covers Rubin through the Ozaki-I and Ozaki-II schemes and a new TI16 type on the tcgen05.mma instruction, quoted at up to 212 TFLOPS of emulated DGEMM and 301 TFLOPS of ZGEMM. Both are NVIDIA's own figures for silicon that has not shipped, produced by the same preview the release notes say not to benchmark.
What a Linux CUDA install stops shipping
The toolkit no longer carries a driver at all. Windows lost the bundled driver at CUDA 13.1 and Linux loses it at 13.4, so the driver is a separate download and a separate step in every provisioning script that assumed otherwise. The R615 packages changed too: they no longer include the proprietary kernel modules, and supported Linux systems use the NVIDIA open kernel modules instead.
The change that can actually bite is the memory mode. On coherent platforms, which NVIDIA lists as Grace Hopper, Grace Blackwell and Vera Rubin, the driver now defaults to Coherent Driver-based Memory Management rather than onlining GPU memory to the operating system as a NUMA node. NUMA mode remains fully supported, but the setting is node-wide, controlled by a kernel module parameter, and only takes effect after a driver reload or a reboot, which is why NVIDIA says to choose the mode before upgrading rather than after. Anything that treats GPU memory as a NUMA node, from a scheduler's placement logic to a numactl line in a run script, is looking at a different machine once R615 is in. The active mode reports through grep Coherent /proc/driver/nvidia/params, which belongs in a health check now rather than in a debugging session later.
MPS V3 adds a scriptable command-line interface, TOML configuration, named server instances, SM partition controls and per-container time slicing, and both CUDA and NVML now honour cgroup-based GPU memory limits in allocation and reporting.
Arm licenses a 128-core server subsystem
Arm announced the Neoverse CSS N4, the compute subsystem its partners license rather than a chip anyone can buy. It scales from 8 to 128 N4 cores per die at up to 3.8 GHz, the widest core-count range Arm has put in a Neoverse CSS, with up to 2MB of private L2 per core and up to 256MB of system-level cache per die. Memory is DDR5 or LPDDR6, and I/O reaches 128 lanes of PCIe Gen 6/7 with CXL 4.0, as Chips and Cheese recorded after asking Arm directly. ServeTheHome adds a 3nm target, an Armv9.3 baseline with FP8 and MMLA, the CMN S4 fabric with a 16 by 16 mesh, and MRDIMM support at 8000 to 12000 MT/s.
For a GPU reader the socket matters more than the cores. PCIe Gen7 and CXL 4.0 at 128 lanes is the host side of an accelerator rack, and a lane count that generous only makes sense next to parts that can saturate it, which puts the resulting silicon at least a generation out. The LPDDR6 option is a tradeoff rather than a free win: soldered memory buys bandwidth per watt and costs capacity headroom and serviceability, so a DPU taking that route is a different product from a 128-core server part taking the other.
The disclosure itself was thin. Chips and Cheese reports that CSS N4 got a single slide, that the specification above only arrived when Arm was asked, and that the underlying core, per-die memory bus width and per-die PCIe lane count went unstated. Read the numbers as the ceiling of a licensable menu, not the shape of any chip that ships from it.