Accelerator sharing: name the partition and the fault domain

On supported hardware, a MIG GPU instance combines allocated memory slices, compute resources, and associated engines. The dedicated memory resources provide a defined memory capacity and bandwidth QoS boundary between GPU instances. A compute instance created inside a GPU instance subdivides its SM resources while sharing the parent instance’s memory and engines. Therefore two compute instances inside one GPU instance do not have the same memory isolation relationship as two separate GPU instances. Name the exact object assigned to the tenant rather than merely count visible CUDA devices.

Supported profiles and their placement are constrained by hardware and driver capabilities. Aggregate spare compute and memory do not prove that the requested combination can be instantiated in the remaining layout. Fragmentation, profile shapes, and engine requirements can prevent placement even when a simple sum fits. Outside the instance, host memory, CPUs, networking, storage, driver administration, and other system dependencies still need their own boundaries. A device partition also does not authenticate the customer’s model artifact or restrict what a privileged host administrator can do.

For Volta-and-later MPS dynamic active-thread-percentage provisioning, the setting limits available execution resources but does not reserve dedicated SMs for each client; work from different contexts may execute on the same SM. Hardware granularity affects the effective limit. Those clients have distinct GPU address spaces, and documented fatal-fault containment is limited to affected connected sharing cohorts rather than complete independence. Do not describe this mode as having no memory protection, or interpret an execution percentage as dedicated memory bandwidth. Fault, capacity, bandwidth, and execution constraints are different dimensions.

Avoid turning that scoped statement into “MPS never partitions resources.” NVIDIA also documents static SM partitioning, and MPS v3 adds device-memory partitioning for supported non-MIG deployments requiring CUDA 13.4 or newer and Linux cgroup v2. Its dmem backend requires a supported controller on kernel 6.14 or newer, with a documented misc fallback. These versioned capacity-accounting features do not by themselves establish the same hardware memory-bandwidth QoS or fault domain as a MIG GPU instance. Check the actual deployment contract and limitations instead of transferring an older comparison table to every new mode.

For a tenant serving variable context lengths, test memory capacity pressure, prefill bandwidth demand, decode latency, and failure recovery separately. Cooperative clients inside one research job can accept different risks from unrelated customers with strict confidentiality obligations. Record the selected instance or MPS mode, effective resource settings, driver version, and neighboring workload during each test. A larger apparent utilization number can coexist with worse deadline success or a broader fault cohort. Evaluate the claim the customer needs rather than optimize only the number of active processes.

Reset the roofline lab, explicitly set intensity eight and bandwidth 80, predict the ceiling, then Play or Step. Compare a separate Reset with intensity 16 and bandwidth 80 explicitly set. The fixed synthetic compute ceiling is 1,000 GFLOP/s, so the first setting is bandwidth-bound and the second reaches the compute roof. Playback traces the roof without changing the kernel parameters. This model contains no GPU instances, MPS contexts, memory allocations, fault propagation, or driver behavior; it cannot establish a tenant partition’s real performance or security.