A cloud provider offers an inexpensive fraction of a GPU. Does that fraction have its own memory allocation? Can another customer consume its execution time? What happens if another workload crashes? The answers depend on how the GPU is shared, not on the fraction advertised in the price list.

MIG provides hardware partitions

NVIDIA's Multi-Instance GPU (MIG) documentation describes hardware partitioning on supported accelerators. A GPU instance receives a defined share of resources, including dedicated paths through parts of the memory system. Separate GPU instances offer isolation and more predictable access to their assigned resources than ordinary time-sliced workloads.

An allocation with 10 GB of dedicated GPU memory, for instance, should not be treated as a whole 80 GB GPU that happens to be lightly utilized. A model requiring 14 GB cannot fit in that partition without changing the execution strategy, even if the physical device has unused memory elsewhere.

The exact profiles depend on the GPU model, configuration and software. Consult NVIDIA's supported profiles and the provider's allocation description. MIG is a hardware capability, not a guarantee that every available profile is already configured on the server.

Time-slicing lets more workloads use the same device

Kubernetes can advertise multiple logical resources backed by one physical GPU. NVIDIA's GPU Operator time-slicing documentation describes how replicas allow workloads to interleave execution. Unlike separate MIG GPU instances, these replicas do not have memory or fault isolation from one another.

Suppose an operator advertises eight time-sliced replicas of one GPU. The scheduler can place workloads against those resources, but it has not created eight GPUs. Requesting two replicas does not guarantee twice the compute share of requesting one. Under contention, actual performance depends on the processes and the sharing implementation.

This can be sensible for intermittent development jobs that rarely run simultaneously. It is less attractive for an interactive service that must maintain a particular response time even when other tenants are busy. The documented time-slicing mechanism does not provide a dedicated memory quota. A hosting platform may impose additional controls, but those need to be stated separately.

vGPU adds a virtualization layer

NVIDIA's vGPU documentation covers conventional time-sliced vGPUs and MIG-backed configurations. A supported MIG-backed vGPU can map to a hardware instance; some configurations allow multiple vGPUs to time-slice within one MIG instance.

This produces two levels of sharing. The outer hardware partition may have dedicated resources, while the vGPUs within it still compete for execution time. Ask which profile is assigned and whether another VM can share that same instance.

GPU passthrough is different again. In the documented passthrough arrangement, a single VM receives the entire MIG-enabled GPU and can use its slices. Enabling MIG does not by itself assign slices to different VMs. That requires the supported virtualization mechanism.

Licensing, host and guest compatibility and driver versions are part of the vGPU service. Hardware support for MIG does not establish that a particular hypervisor or licensed feature is included in the rental.

Changing a partition may require downtime

Amazon EKS's MIG guidance describes dedicated memory and predictable resource allocation, along with disruption associated with reconfiguring the device. The exact maintenance behavior varies by GPU and platform. Changing the partition layout may require draining affected workloads.

A customer moving from a small profile to a larger one should know whether a suitable partition is already available. A provider offering flexible profile sizes may still need time to relocate jobs or change the configuration.

What to compare before renting

An exclusive GPU, MIG profile and time-sliced vGPU are different products. A useful quotation identifies:

  • The physical GPU model, assigned memory and supported profile.
  • Whether the allocation has dedicated compute and memory resources or shares them in time.
  • The isolation and fault-containment mechanisms, including which workloads can affect each other.
  • Supported drivers, hypervisor, software licenses and maintenance behavior.
  • Representative latency and throughput under the contention conditions expected in service.

For inference, measure response times under load, not just a throughput test while the rest of the device is idle. For a model that must fit in a fixed memory allocation, establish that it has sufficient space for weights, temporary buffers and active request state.

Confidential computing is a separate feature. A MIG partition does not establish that the host cannot read sensitive model data. Our explanation of confidential GPU computing covers the additional attestation and security-mode requirements.