CUDA 13.5 and Vera Rubin GA 2026: What Changes for AI Developers

NVIDIA has shipped CUDA 13.5 with general-availability support for the Vera Rubin platform. For AI developers, Rubin GPUs and Vera CPUs are now hardware you can build for, profile, and run in production, not slideware you plan around. The silicon matters, but the toolkit decides when your kernels, frameworks, and inference stacks can use it. If you sign GPU reservations, tune training runs, or maintain custom CUDA code, the CUDA 13.5 Vera Rubin release starts your migration clock.

What’s new in the CUDA 13.5 Vera Rubin release

The main change is that Rubin now has production status in the CUDA toolkit. Earlier 13.x releases gave early-access partners enough to bring up systems. With CUDA 13.5, NVIDIA supports the compiler, libraries, driver stack, and developer tools for production Rubin deployments. nvcc generates native code for the Rubin architecture, Nsight Compute and Nsight Systems can profile it, and the core math and communication libraries (cuBLAS, cuDNN, CUTLASS, NCCL) ship tuned paths for the new hardware instead of generic fallbacks.

The hardware is a large step up from Blackwell. NVIDIA’s published Rubin figures are about 50 petaflops of NVFP4 inference per GPU, 288 GB of HBM4 at roughly 22 TB/s, and NVLink 6 at 3.6 TB/s per GPU. The Vera CPU replaces Grace with 88 custom Arm cores, attached to the GPUs over 1.8 TB/s NVLink-C2C. The flagship system is the Vera Rubin NVL72 rack. These are vendor numbers, so expect real workloads to land below them. Even so, the jump from HBM3e to HBM4 is the change that matters most for inference teams bound by memory bandwidth.

Most of the software work makes that hardware usable without rewriting everything. Low-precision formats (NVFP4, FP8) get first-class library support, NCCL is tuned for NVLink 6 topologies, and the Vera CPU path improves CPU-GPU coherent memory, which pays off for KV-cache offload and large-context inference. If you already moved to CUDA 13 on Blackwell, 13.5 is an incremental upgrade. If you’re still on CUDA 12.x, you face a major-version migration and a new architecture at once. Plan for that.

Why it matters

• Procurement gets real dates. Cloud providers and neoclouds wait for toolkit GA before selling Rubin instances as generally available instead of private preview. If you’re comparing AI datacenter GPUs for 2026 contracts, Rubin capacity is now something you can negotiate for.
• Blackwell-tuned kernels are not automatically Rubin-optimal. PTX JIT will run your code on Rubin, but tile sizes, shared-memory layouts, and pipeline depths hand-tuned for Blackwell leave performance on the table. Expect a re-tuning pass on custom kernels.
• Inference economics shift toward FP4. Rubin’s headline gains come from NVFP4. Teams that haven’t validated FP4 quantization for accuracy will miss most of the Rubin-over-Blackwell improvement. Quantization work is now on the critical path.
• The CPU matters again. Vera’s coherent NVLink-C2C link makes CPU memory a practical extension of GPU memory. Re-architect long-context serving, KV-cache offload, and data preprocessing pipelines to use it rather than simply porting them.
• Framework lag is the real bottleneck. PyTorch, JAX, vLLM, TensorRT-LLM, and SGLang all need builds against CUDA 13.5 with Rubin targets. Your timeline depends on their release cadence as much as NVIDIA’s.
• Mixed fleets become the norm. Few teams will replace Blackwell overnight. Build systems, containers, and CI must produce binaries that run well on both architectures for the next 12-24 months.

How to upgrade to CUDA 13.5 today

This is the practical path from a Blackwell-era CUDA setup to code that runs and performs on Rubin. Check every version number against NVIDIA’s official CUDA 13.5 release notes before rollout, because driver minimums and package names change between point releases.

1. Audit your current stack. Record your driver, toolkit, and framework versions first so you have a rollback baseline.

   nvidia-smi
   nvcc --version
   python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.get_device_capability())"

2. Upgrade the driver first. CUDA 13.5 needs a newer driver branch than early CUDA 13 releases. On Ubuntu with NVIDIA’s network repository configured, install the branch named in the release notes, then reboot and confirm.

   sudo apt-get update
   sudo apt-get install -y nvidia-open   # or the specific branch listed in the 13.5 release notes
   sudo reboot
   nvidia-smi   # confirm driver version and that Rubin GPUs enumerate

3. Install the CUDA 13.5 toolkit side by side. Keep your previous toolkit until validation is done. Versioned packages let you switch with PATH.

   sudo apt-get install -y cuda-toolkit-13-5
   export PATH=/usr/local/cuda-13.5/bin:$PATH
   export LD_LIBRARY_PATH=/usr/local/cuda-13.5/lib64:$LD_LIBRARY_PATH
   nvcc --version

4. Find the Rubin compile target. Don’t guess architecture names. Ask the compiler which targets it supports, and query the device for its compute capability.

   nvcc --list-gpu-arch
   nvcc --list-gpu-code
   nvidia-smi --query-gpu=name,compute_cap --format=csv

5. Build fat binaries for a mixed fleet. Generate native code for Blackwell and Rubin, and embed PTX so future architectures can JIT-compile. Replace RUBIN_SM with the value reported in step 4.

   nvcc -O3 \
     -gencode arch=compute_100,code=sm_100 \
     -gencode arch=compute_RUBIN_SM,code=sm_RUBIN_SM \
     -gencode arch=compute_RUBIN_SM,code=compute_RUBIN_SM \
     -o my_kernel my_kernel.cu

   For CMake projects, set the architectures list instead:

   cmake -B build -DCMAKE_CUDA_ARCHITECTURES="100;RUBIN_SM" \
         -DCMAKE_CUDA_COMPILER=/usr/local/cuda-13.5/bin/nvcc
   cmake --build build -j

6. Test PTX forward-compatibility. Before shipping native Rubin code, confirm older binaries still run through JIT. This catches missing PTX in third-party libraries.

   CUDA_FORCE_PTX_JIT=1 ./my_kernel
   # If this fails, some dependency shipped SASS-only and needs a rebuild.

7. Use a pinned container for frameworks. An NGC container built against CUDA 13.5 is the fastest route to a working PyTorch or TensorRT-LLM stack. Pin the tag that matches the toolkit; avoid latest.

   docker run --gpus all -it --rm --ipc=host \
     nvcr.io/nvidia/pytorch:<tag-built-on-cuda-13.5> \
     python -c "import torch; print(torch.cuda.get_device_name(0), torch.cuda.get_device_capability(0))"

8. Profile before you optimize. Run your hottest kernels through Nsight Compute on Rubin and compare against Blackwell baselines. Check memory throughput first, because HBM4 changes the roofline.

   nsys profile -o rubin_run --trace=cuda,nvtx,osrt python train.py
   ncu --set full -k regex:gemm -o rubin_gemm ./my_kernel

9. Validate NCCL on the new topology. Collective performance on NVLink 6 decides multi-GPU training gains or losses. Benchmark it explicitly.

   git clone https://github.com/NVIDIA/nccl-tests.git
   cd nccl-tests && make CUDA_HOME=/usr/local/cuda-13.5
   ./build/all_reduce_perf -b 8M -e 8G -f 2 -g 8

How it compares: Rubin GPU vs Blackwell vs AMD

Most teams care about two comparisons: Rubin against Blackwell Ultra, which they already run, and Rubin against AMD’s Instinct MI400 series, the main non-NVIDIA option for 2026 datacenter buys. The figures below are approximate, vendor-published per-GPU claims. Treat them as direction, not benchmarks.

Spec	NVIDIA Rubin (Vera Rubin)	NVIDIA Blackwell Ultra (B300)	AMD Instinct MI455X
Memory	288 GB HBM4	288 GB HBM3e	432 GB HBM4
Memory bandwidth	~22 TB/s	~8 TB/s	~19.6 TB/s
Low-precision compute (FP4, vendor claim)	~50 PF NVFP4 inference	~15 PF dense FP4	~40 PF FP4
Scale-up interconnect	NVLink 6, 3.6 TB/s per GPU	NVLink 5, 1.8 TB/s per GPU	UALink / Infinity Fabric (Helios rack)
Paired CPU	Vera (88 custom Arm cores)	Grace (72 Arm Neoverse V2 cores)	EPYC “Venice”
Software stack	CUDA 13.5	CUDA 12.8+ / 13.x	ROCm 7.x
Migration cost from existing CUDA code	Low to moderate (re-tune)	Baseline	Moderate to high (port and validate)

Our view: AMD’s capacity advantage is real, and memory-heavy inference workloads deserve a serious evaluation on it. For teams with years of CUDA kernels, NVIDIA-tuned Triton code, and TensorRT-LLM deployments, Rubin’s main advantage is that CUDA 13.5 turns migration into a re-tuning job, not a porting project. Porting hours cost real money, and they count against any hardware discount.

What’s next

Watch the frameworks first. Toolkit GA is necessary, but most teams don’t write raw CUDA. They depend on PyTorch wheels, vLLM and SGLang releases, TensorRT-LLM builds, and JAX/XLA support. Track their release notes for explicit Rubin targets and NVFP4 kernels. If a framework you depend on supports Rubin only through PTX JIT, you’re running new hardware at Blackwell-era efficiency.

Next come cloud availability and pricing. Vera Rubin GA in the toolkit sets the clock for hyperscalers and GPU clouds to move Rubin instances from reserved, enterprise-only access to on-demand capacity. Early on-demand pricing will be high and supply thin. Teams that benchmark now, on whatever preview access they can get, will negotiate from data instead of marketing slides when capacity opens.

Further out, NVIDIA’s public roadmap puts Rubin Ultra next, Feynman after it, and Rubin CPX aimed at long-context prefill. The pattern holds: a new architecture roughly every year, with CUDA point releases carrying each one to production. The lasting lesson for 2026 is to build for portability within the NVIDIA ecosystem. Use fat binaries, keep PTX embedded, pin containers, and keep your quantization pipeline validated, so each generation is a recompile and re-tune rather than a rebuild.

Frequently Asked Questions

Do I need CUDA 13.5 to run code on Vera Rubin?

For native, tuned performance, yes. Applications that embed PTX can JIT-compile onto Rubin with a sufficiently new driver, but they miss architecture-specific optimizations and the tuned library paths in CUDA 13.5. SASS-only binaries built for older architectures will not run at all.

Will my Blackwell-optimized kernels run on Rubin GPUs?

They’ll run if PTX is embedded, but they probably won’t be optimal. Tile sizes, shared-memory usage, and pipeline staging tuned for Blackwell may underuse Rubin’s higher memory bandwidth and new tensor core paths. Profile with Nsight Compute and re-tune your hottest kernels. If you use CUTLASS or cuBLAS, upgrading the library often captures most of the gain.

Is upgrading from CUDA 12.x to 13.5 a big job?

It’s a major-version jump, so budget real time. CUDA 13 removed or deprecated older APIs and dropped support for some legacy architectures. Audit deprecation warnings, rebuild every dependency that ships compiled CUDA code, and validate on Blackwell before touching Rubin so you aren’t debugging two changes at once.

What does the Vera CPU change for AI workloads?

Vera replaces Grace and connects to Rubin GPUs over coherent NVLink-C2C, making CPU memory a fast extension of GPU memory. The biggest beneficiaries are long-context inference with KV-cache offload, large embedding tables, and data preprocessing that used to stall on PCIe transfers.

Should we wait for Rubin or buy Blackwell now?

If you need capacity next quarter, buy Blackwell. It’s mature, available, and runs the same CUDA code. If your workload is memory-bandwidth-bound inference at scale and you can wait for Rubin cloud capacity to stabilize, the HBM4 jump justifies waiting. Most teams will run both, so build for a mixed fleet either way.

How does Rubin compare to AMD’s MI400 series?

AMD offers more HBM capacity per GPU and competitive bandwidth, which matters for very large models. Rubin leads on claimed FP4 throughput, NVLink 6 scale-up, and above all the CUDA ecosystem. For teams with heavy CUDA investment, the cost of switching to ROCm usually outweighs the hardware differences. Greenfield inference deployments should benchmark both.