What Does an MPS GPU Fraction Actually Reserve?

Identify the resource mode before interpreting the fraction

NVIDIA's Multi-Process Service, or MPS, supports cooperating CUDA processes and applications sharing a GPU. It permits work from different processes to execute concurrently, so an MPS allocation need not mean taking turns on the entire device. Streaming multiprocessors, or SMs, are the execution resources at issue here.

For a buyer, the important distinction is whether the offer limits how much execution resource a context can use or assigns a particular set exclusively to a partition. A label such as 50% MPS leaves that distinction unresolved. Ask the platform owner to name the mechanism before treating the number as a reservation.

References: [N1][N2]

A dynamic execution ceiling does not reserve dedicated SMs

The MPS guide describes active-thread provisioning as restricting the threads available to a client context. Different clients' kernels may still execute on the same SM. The limit constrains usage; it supplies no dedicated set.

Programmatic execution affinity can instead express a context's limit as an SM count. Consequently, even a number stated in SMs needs its mode identified: it can describe a usage ceiling rather than exclusive ownership.

The effective limit also needs confirmation. NVIDIA documents downward rounding of active-thread limits to a supported thread count and upward rounding of execution-affinity requests to a supported SM count. CUDA Driver API 13.4 identifies SM-count execution affinity as supported under Volta-and-newer MPS. Have the platform owner establish the applicable hardware, software and effective limit; decimal arithmetic on an advertised fraction cannot establish them.

References: [N2][N4]

Static SM partitioning creates an exclusive resource boundary

The current guide separately documents static SM partitioning for NVIDIA Ampere architecture and newer GPUs. This mode assigns specific SM resources to partitions. Exclusivity applies between partitions: one or more MPS clients can use the same partition. A claim of dedicated SMs for one application therefore also needs to identify who else is assigned to its partition.

Static mode ignores the documented dynamic resource-provisioning controls, including active-thread percentage and per-context multiprocessor partitioning. A proposal cannot silently combine these descriptions as two independently enforced limits. Ask which mechanism actually determines the client's resources.

References: [N2][N3]

Compare a 32/32 static layout with a separate 50% dynamic offer

Consider an explicitly hypothetical, supported static layout with 64 SMs split into two 32-SM partitions. Client A alone uses the first partition; client B alone uses the second. These numbers assume a valid layout rather than specify one for a named GPU.

When B is idle, A cannot automatically borrow B's 32 idle SMs. A remains assigned its own 32. A buyer expecting the application to expand across all 64 whenever the other client stops has asked for behavior this static allocation does not supply.

Now consider a separate offer described as a 50% dynamic active-thread limit. Do not translate it into the same exclusive 32-SM assignment, half the GPU's time or half its memory bandwidth. Its execution ceiling leaves the exclusive-assignment question unanswered. B becoming idle does not itself remove A's ceiling.

For an application that needs an exclusive SM set, the static offer addresses that resource requirement. For a requirement to gain extra execution resources during another client's idle periods, the static offer's unborrowable allocation becomes a constraint to assess. Neither description establishes which offer would run the application faster. The useful comparison is the promised behavior under the intended pattern of simultaneous and intermittent demand.

References: [N2][N3]

Keep memory entitlement and fault containment at their stated boundaries

Exclusive SM assignment alone establishes neither exclusive HBM capacity nor exclusive HBM bandwidth. NVIDIA documents device-memory partitioning separately from SM allocation. Require the offered memory entitlement to be stated independently, and retain any response-time or throughput requirement as an application acceptance question.

There is also a dated containment qualification. The Common Tasks guide says that, starting with driver r610, static partitioning provides partial isolation of SM-triggered faults between different SM partitions. The driver stops the faulting client's work and blocks further submission. This is neither an all-fault isolation promise nor a tenant-security guarantee.

An exclusive execution set is useful evidence about resource access. It does not establish that every shared-resource effect has disappeared or that the application meets its response target.

References: [N3][N5]

Ask the platform owner to return an allocation the application can assess

Resolve the offer into a named GPU and architecture, driver and CUDA versions, resource mode, and effective execution allocation. For static mode, include the assigned partition and whether other clients share it. Carry the separately stated memory terms alongside that description.

Then give the application owner the intended competing-work pattern and the required output and response criteria. Evidence gathered with neighboring work idle answers a different question from evidence gathered during simultaneous demand.

Use the related MIG/vGPU comparison for the broader allocation decision and the activity-and-occupancy article for interpreting counters. A dashboard percentage does not replace the resource description.

References: [N2][N4]

Bring the selected equipment into physical installation planning

If the platform decision leads to installing customer equipment, Leviathan's rack-and-stack service covers agreed mounting, IT cabling, labeling and physical installation records. Share the equipment models and quantities, site, released rack and cable plans, required window and physical handoff through the service and project-inquiry links below.

That physical scope connects the selected servers to their installation package. MPS configuration and software acceptance remain with the appointed platform owner.

References: [L1]