# CUDA 13.4: MPS management controls and MIG isolation remain different mechanisms

CUDA 13.4 expands MPS management after earlier GPU partition controls. How to distinguish programmable sharing policy from a MIG hardware-isolation boundary.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-09
Original announcement: https://developer.nvidia.com/blog?p=121255
Canonical URL: https://retrivium.ai/retrospectives/retro-cuda134-mps-control-isolation/

Sharing an accelerator requires both an allocation policy and a definition of the boundary that policy protects. CUDA 13.4 develops the management side of MPS. Looking back at earlier partition controls helps explain the direction, while a comparison with MIG prevents one management interface from becoming a universal isolation label.

## The dated path

- 2025-12-04: [NVIDIA CUDA 13.1 Powers Next-Gen GPU Programming with NVIDIA CUDA Tile and Performance Gains](https://developer.nvidia.com/blog/nvidia-cuda-13-1-powers-next-gen-gpu-programming-with-nvidia-cuda-tile-and-performance-gains/).

- 2026-01-05: [NVIDIA Kicks Off the Next Generation of AI With Rubin](https://nvidianews.nvidia.com/news/rubin-platform-ai-supercomputer).

- 2026-09-09: [CUDA Toolkit 13.4 adds Windows on Arm, Rubin preview and MPS V3](https://developer.nvidia.com/blog?p=121255).

## The earlier problem was already resource ownership

Earlier green-context and partition controls made explicit GPU resource allocation a programming concern. The next hardware roadmap expanded the set of combinations an operator might eventually manage. September’s MPS update adds a more programmable control surface. The retrospective connection is a growing need to express resource ownership through repeatable operations. This is an editorial interpretation of the sequence, not evidence that hardware growth alone caused the interface change. Workload concurrency, operational complexity and application requirements would need separate evidence before assigning a single cause.

## A limit needs an object and an enforcement boundary

A hypothetical scheduler could express a compute allocation and a memory budget for a client. That description is incomplete until it identifies what is counted, when enforcement applies and which lifecycle owns the allocation. A process restart, for example, raises a different question from admission of a new request. These are suggested review questions rather than undocumented claims about MPS behavior. A useful configuration record connects each policy to its mechanism instead of using the presence of a limit as proof of every desired isolation property.

## MIG supplies a different comparison boundary

As current technical background checked at the review date, NVIDIA’s [MIG guide](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/introduction.html) describes supported GPU instances with separately assigned memory-system paths. That document is not presented as an earlier September milestone. Its relevance is conceptual: hardware-instance boundaries and a shared-service control plane describe different mechanisms. A comparison should specify which resources and failure properties matter to the workload. Neither a familiar acronym nor an automation feature establishes that every GPU supports a desired partition or that every application fits its resource profile.

## Automation makes policy inspectable rather than self-justifying

A repeatable interface helps an operator review intended allocation, apply it consistently and associate a change with an observed workload result. The policy still needs justification. A proposed evaluation would separate fairness, throughput interference, recovery and access protection instead of compressing them into one shared-GPU score. For an inference provider, this distinction supports an honest service description: name the configured mechanism, the supported hardware and the property actually evaluated. The news advances the management story while leaving the deployment-specific acceptance question attached to its own evidence.

## Technical background

Related engineering context: [Serving memory budgets](/journal/vllm-gpu-memory-utilization/); [Interference and service performance](/journal/throughput-latency-tradeoff/).