Whole GPU, Passthrough, vGPU, MIG, or Time Slicing? The Enterprise GPU Allocation Decision Matrix

nvidia.com/gpu: 1 usually means exclusive allocation of one advertised GPU device to a pod. Kubernetes resource requests are integers, so the platform does not request 0.25 of a GPU through the standard device-plugin model.

This design is stronger than Kubernetes time-slicing for memory governance because framebuffer is assigned by profile. It is weaker than MIG for compute isolation because the physical engines remain shared unless the deployment uses a MIG-backed profile.

The most important distinction is between sharing and partitioning.

A vGPU profile’s framebuffer size is not a guaranteed percentage of SM cycles. The scheduler mode and co-resident workload count determine compute behavior.

TL;DR

The trust level of the tenant should directly constrain the allowed mechanisms.

Research needs flexibility, profiling, custom drivers, debuggers, and sometimes unsupported kernels. A dedicated research node pool with whole GPUs may be safer than weakening production clusters. Time-slicing can be useful for early experiments, but researchers should be able to request a temporary whole-GPU reservation when profiling or reproducibility matters.

• Allocation mechanism: whole GPU, passthrough, vGPU, MIG, MIG-backed vGPU, or time-slicing.
• Service class: the technical contract for memory, compute, availability, observability, and support.
• Business entitlement: who receives guaranteed capacity, who may borrow, who may be preempted, and what evidence is owed.

Every service-class record should include:

The Decision Has Three Separate Layers

Choose MIG when:

NVIDIA currently lists MIG support for several Ampere, Hopper, and Blackwell products, including the RTX PRO 6000 Blackwell Server Edition, Workstation Edition, and Max-Q Workstation Edition. However, the NVIDIA vGPU supported-GPU list separately identifies which products support vGPU software. The RTX PRO 6000 Blackwell Server Edition is listed for vGPU, while workstation editions should not be assumed to support vGPU merely because they support MIG [3], [8].

Collect peak and steady-state GPU memory, SM utilization, batch size, concurrency, queue time, latency, training duration, topology, profiler requirements, and data classification. Do not size from average utilization alone.

Allocation Mechanisms at a Glance

This article establishes that decision model for production AI, inference, training, research, interactive development, virtual machines, and Kubernetes. The current compatibility baseline is July 24, 2026. Exact GPU SKU, server, firmware, driver, hypervisor, guest operating system, Kubernetes, and NVIDIA software compatibility must still be checked before deployment because support boundaries change by release.

Allocation model	Primary boundary	Memory isolation	Compute isolation	Predictability	Mobility	Operational complexity	Typical best fit
Dedicated whole GPU	Scheduler or host assignment	High	High	High	Medium in Kubernetes, low in bare metal	Low to medium	Training, large inference, critical production
GPU passthrough	One physical GPU to one VM	High	High	High	Low	Medium	Exclusive VM workloads, appliances, legacy stacks
Standard NVIDIA vGPU	VM plus fixed framebuffer profile	High for assigned framebuffer	Medium or low unless scheduler policy guarantees a share	Medium	High when supported	High	GPU-enabled VM fleets, development, VDI, managed inference
MIG	Hardware GPU Instance and Compute Instance	High	High within profile	High	Medium through restart and rescheduling, not transparent state transfer	Medium to high	Partitioned inference, trusted multitenancy, predictable small workloads
MIG-backed vGPU	VM plus MIG hardware partition	High	High for a whole GPU Instance, lower if time-sliced within that instance	High to medium	Potentially high, but release-specific	Very high	VM-based tenant isolation with hardware partitioning
Kubernetes time-slicing	Shared process scheduling on one GPU	None between replicas	None as a guaranteed fraction	Low	Medium through pod restart and rescheduling	Low initially, high operationally	Trusted internal notebooks, bursty tests, low-duty-cycle jobs

These are a publication baseline, not a design shortcut. A production bill of materials should record the exact server model, GPU SKU, firmware, BIOS, GPU VBIOS, ESX or other hypervisor build, vGPU Manager, guest driver, Kubernetes version, GPU Operator, CUDA stack, and application runtime.

• Sharing lets multiple workloads take turns using the same engines or device. Kubernetes time-slicing is sharing. Standard vGPU normally combines fixed framebuffer assignment with shared, time-sliced engines.
• Partitioning creates defined subdevices with assigned hardware resources. MIG is hardware partitioning. MIG-backed vGPU places a VM-facing virtual device on top of that partition.
• Dedication assigns the entire GPU to one scheduling unit or one VM. Whole-GPU Kubernetes allocation and passthrough are both dedication models, but their management boundaries differ.

Scope, Assumptions, and Terminology Guardrails

Choose passthrough when:

Whole GPU Does Not Automatically Mean Passthrough

Many AI pipelines are CPU, memory, storage, or network bound. Tokenization, document parsing, orchestration, preprocessing, API gateways, and vector-database operations do not automatically need a GPU. A CPU-only class prevents expensive accelerators from becoming the default answer to every AI workload.

A platform that reports forty allocatable shared GPUs from four physical GPUs should display both numbers. Capacity dashboards must distinguish physical devices, hardware partitions, virtual profiles, and shared access tokens.

vGPU Is Not a Synonym for MIG

Passthrough means a hypervisor directly assigns the physical PCIe device to one VM. The guest driver owns the GPU from the workload perspective, and the NVIDIA vGPU Manager is bypassed. Both models can provide exclusive use, but their lifecycle, monitoring, mobility, and failure-handling paths are different.

GPU-C should mean committed service, not simply a particular GPU model. It can be implemented by a dedicated whole GPU in Kubernetes, passthrough to a VM, or a full-GPU vGPU when mobility is required. The entitlement should define whether capacity is reserved continuously, available within a queue-time objective, or temporarily borrowable by lower-priority workloads.

• Standard vGPU is primarily a virtualization and framebuffer-partitioning model with engine scheduling.
• MIG is a hardware partitioning model.
• MIG-backed vGPU combines hardware partitioning with virtual-machine delivery.

MIG Capability and vGPU Capability Are Separate Checks

Dedicated whole-GPU allocation assigns an entire physical GPU to one workload at a time. In bare metal, the workload runs directly on the host. In Kubernetes, a pod normally requests an integer extended resource, such as one GPU, and the device plugin makes the device available to the container.

NVIDIA GPU Operator time-slicing oversubscribes a GPU by advertising multiple replicas of one physical resource. Workloads receive shared access and interleave on the underlying device. NVIDIA explicitly states that replicas do not provide memory or fault isolation, and requesting more than one replica does not guarantee proportionally more compute [1].

Kubernetes Scheduling Does Not Create Physical Isolation

Whole-GPU allocation strands unused memory and compute inside an allocated device. This is visible and easy to explain. It can be reduced with shorter job durations, queueing, checkpointing, autoscaling, and moving interactive work to smaller service classes.

How Each Allocation Model Actually Works

Dedicated Whole-GPU Allocation

Training usually prefers whole GPUs because the workload benefits from full memory, full compute, high-speed interconnects, and topology-aware scheduling. Multi-GPU training may require GPUs connected through NVLink or NVSwitch and low-latency scale-out networking. Fractional allocation can disrupt communication topology and extend training duration.

A platform that maximizes utilization but cannot protect production latency, isolate customer workloads, or explain consumption is not efficient. It is merely busy.

Avoid whole GPU as the universal default when:

Choose standard vGPU when:

• The model or batch genuinely needs most of the device memory.
• Multi-GPU communication, NVLink, NVSwitch, GPUDirect RDMA, or topology-aware scheduling matters.
• Latency or training duration is contractually important.
• The workload is externally paid, regulated, or operationally critical.
• Debugging, profiling, or unified-memory behavior must not be constrained by migration features.
• The platform wants the simplest supported path with the fewest sharing layers.

MIG can be useful for small experiments, hyperparameter sweeps, unit tests, or independent jobs that fit a profile. It is not the default for distributed training that expects full GPUs or peer-to-peer topology.

• Most workloads use a small fraction of memory and compute.
• Developers hold GPUs idle for long interactive sessions.
• The organization cannot afford the resulting capacity fragmentation.
• A smaller, well-isolated MIG or vGPU profile can meet the service objective.

GPU Passthrough

GPU-M should have a defined memory profile and a measured performance envelope. MIG is the clearest implementation because the hardware partition is explicit. A whole-GI MIG-backed vGPU can provide a similar VM-delivered service. A standard vGPU can qualify only after the platform validates scheduler behavior and communicates that engine sharing differs from MIG.

The commercial offer must state whether memory, compute, performance, and fault isolation are guaranteed. “One GPU” is not a sufficient product description.

A whole GPU assigned to a Kubernetes pod is not the same thing as a whole GPU passed through to a virtual machine. A standard NVIDIA vGPU profile reserves framebuffer but generally time-slices GPU engines. Multi-Instance GPU, or MIG, partitions supported hardware into defined compute and memory instances. MIG-backed vGPU adds a virtual-machine delivery layer to a MIG partition. Kubernetes time-slicing creates more schedulable access tokens for the same underlying device, but it does not create independent memory or fault domains.

Service-Effective Utilization =

Useful GPU Work Delivered Within SLO
————————————
Available GPU Capacity and Operating Cost

Where the GPU supports MIG and the workload fits a stable profile, use MIG for predictable fractional production. Standardize only a few approved layouts and maintain separate node pools if frequent reconfiguration would disrupt service.

• One VM needs an exclusive physical GPU.
• Full-device performance and compatibility are more important than live mobility.
• The workload has a stable placement and maintenance model.
• The VM owner can operate and monitor the guest GPU stack.
• The organization wants a VM boundary without vGPU Manager and vGPU profile management.

As of the research date:

• The service depends on frequent vMotion or automated host balancing.
• Many small VMs need fractional GPU memory.
• The platform needs to reclaim and repack capacity dynamically.
• A failure of one GPU assignment would create an unacceptable recovery process.

Standard NVIDIA vGPU

Administrative isolation comes from the surrounding platform. A VM provides a stronger guest-operating-system boundary than two containers in one Kubernetes node. A Kubernetes namespace limits API objects and policy scope, but it is not equivalent to a separate cluster, VM, or physical host. External customer services should combine the GPU mechanism with identity, network, storage, secret, and control-plane isolation.

Use dedicated whole GPUs as the default for performance-critical training, large-model inference, externally committed services, and workloads that need predictable memory and compute behavior. Use passthrough when a VM needs direct exclusive control of a GPU and mobility is less important than simplicity and performance. Use standard vGPU when VM mobility, VM lifecycle integration, and framebuffer partitioning matter more than hard compute isolation. Use MIG when supported hardware can be divided into predictable hardware-isolated instances. Use MIG-backed vGPU when the organization needs both VM delivery and MIG isolation, and the exact GPU, vGPU release, and hypervisor combination is certified. Use Kubernetes time-slicing only for trusted, bursty, internal workloads that can tolerate contention and weak attribution.

GPU passthrough assigns an entire physical GPU directly to one virtual machine. NVIDIA defines passthrough as exclusive assignment that bypasses the vGPU Manager [4]. The VM sees a physical GPU, uses a guest driver, and controls the device for the duration of the assignment.

Production inference can use all six models, but the service objective decides which is safe:

• Best effort: optimizes use of idle cycles but does not guarantee an equal or fixed compute share.
• Equal share: divides cycles among active vGPUs, but each share changes when the number of active vGPUs changes.
• Fixed share: provides a configured share on supported combinations, improving predictability at the cost of potentially idle cycles.

For enterprise use, set failRequestsGreaterThanOne to enforce that a pod cannot imply it receives twice the compute by asking for two replicas. Use admission policy to prevent production namespaces from requesting shared resources.

The allocation model determines what evidence the platform can collect and how confidently it can attribute usage.

• The VM lifecycle is the primary operating model.
• Fixed framebuffer allocation is sufficient for memory governance.
• Live migration and host maintenance flexibility are important.
• Workloads tolerate shared engines or use a supported scheduler policy.
• The organization accepts vGPU Manager, guest-driver, and NVIDIA License System requirements.

A scheduler can only allocate the resource model it is given. The platform team must make that model explicit.

• Paid customers expect hardware-partitioned compute isolation.
• A hard performance floor cannot be achieved with the supported scheduler.
• The application requires unsupported CUDA features during live migration.
• Profile packing and licensing complexity exceed the value of VM mobility.

Multi-Instance GPU

Measure queue time, startup time, model load, tokens per second, requests per second, time to first token, p95 and p99 latency, throughput, error rate, memory pressure, GPU reset behavior, node drain, VM migration, checkpoint recovery, and telemetry attribution.

MIG-backed vGPU assigns a vGPU device to a VM from a MIG GPU Instance. This combines the VM boundary and lifecycle model of vGPU with hardware-level MIG partitioning. NVIDIA’s current vGPU documentation distinguishes two forms:

The strongest enterprise design separates the mechanism from the service class and the business entitlement. Consumers should request CPU-only, GPU-S, GPU-M, or GPU-C based on their workload objective. The platform team should decide whether that class is implemented with a whole GPU, passthrough, vGPU, MIG, MIG-backed vGPU, or time-slicing on the current hardware generation.

External customer services should not default to Kubernetes time-slicing. The platform should offer a clearly described partitioned or dedicated product:

apiVersion: v1
kind: Pod
metadata:
name: internal-notebook
labels:
platform.example/gpu-service-class: gpu-s
spec:
nodeSelector:
nvidia.com/gpu.product: L40S
tolerations:
– key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
containers:
– name: notebook
image: registry.example/ai/notebook:2026.07
resources:
limits:
nvidia.com/gpu.shared: 1

MIG partitions supported hardware into GPU Instances with isolated memory paths and defined compute resources. A MIG-backed vGPU exposes a virtual GPU to a VM from that MIG partition. Therefore:

• The GPU is on NVIDIA’s supported MIG list.
• Workloads fit predefined profiles.
• Predictable fractional memory and compute are required.
• Kubernetes or bare-metal services need stronger isolation than time-slicing.
• The platform can manage MIG geometry, node drains, and profile lifecycle.

This distinction is critical. “MIG-backed” does not always mean one VM has exclusive use of the complete MIG instance. The profile and hypervisor support determine whether the GPU Instance is dedicated to one vGPU or time-sliced among several.

• The workload needs the full device or changes size frequently.
• The GPU model does not support MIG.
• The profile geometry creates more stranded capacity than whole-GPU scheduling.
• The organization cannot operationalize reconfiguration and monitoring.

MIG-Backed vGPU

Passthrough strands an entire GPU inside a VM assignment and adds host-placement constraints. It can also strand CPU and memory because the VM must fit on a host that owns a compatible free GPU and enough MMIO space.

• A vGPU that occupies an entire GPU Instance and has exclusive use of that instance’s engines.
• A time-sliced MIG-backed vGPU that shares engines with other vGPUs inside the same GPU Instance while still running in parallel with workloads in other GPU Instances [4].

A Kubernetes pod can receive exclusive access to a physical GPU through the NVIDIA device plugin without the GPU being passed through to a VM. The host driver owns the device, Kubernetes allocates the extended resource, and the container receives device access.

vGPU improves memory packing but introduces profile-placement rules. Heterogeneous profiles can reduce waste for diverse VMs, yet packing and alignment constraints may lower maximum density. NVIDIA’s current example shows that an L40S can host six 8 GB vGPUs in equal-size mode but only four of the same profile in heterogeneous mode [7].

There is no universal best GPU allocation mechanism because the mechanisms solve different problems. Whole-GPU allocation and passthrough provide dedication. Standard vGPU provides VM integration, fixed framebuffer assignment, and configurable engine scheduling. MIG provides hardware-partitioned memory and compute. MIG-backed vGPU combines MIG with VM delivery. Kubernetes time-slicing provides oversubscribed access without memory or fault isolation.

Internal developers working under the same enterprise security policy can often use time-slicing or standard vGPU. The platform should still enforce namespace RBAC, network policy, storage boundaries, secrets isolation, image policy, runtime controls, and quotas. Time-slicing should be labeled best effort and should not host sensitive workloads alongside untrusted code.

• VM delivery and lifecycle integration are mandatory.
• Standard vGPU compute sharing is insufficient.
• The exact certified stack supports the required MIG-backed profile.
• The organization can operate the additional compatibility and monitoring layers.
• Tenant or customer isolation justifies the complexity.

MIG-backed vGPU has the highest operational complexity in this article. The administrator must align server certification, GPU SKU, firmware, vGPU Manager, guest driver, license service, MIG mode, GPU Instance profile, vGPU profile, hypervisor, guest operating system, and migration behavior.

• A standard whole-GPU VM or standard vGPU already meets the requirement.
• The platform lacks disciplined version and compatibility management.
• The team assumes every MIG-capable GPU is vGPU-capable.
• Mobility requirements have not been proven on the selected profile.

Kubernetes Time-Slicing

Create at least one whole-GPU pool, one MIG pool, and one shared development pool. Add vGPU and MIG-backed vGPU pilots when VM services require them. Keep the pools small enough to change but representative enough to test real workloads.

Every allocation model fragments capacity differently. The goal is not to eliminate fragmentation. The goal is to understand which kind of fragmentation the service can tolerate.

This means a time-sliced “GPU” is not a fraction in the same sense as a MIG profile. It is a scheduler-visible access token. On a four-GPU node configured with ten replicas per GPU, Kubernetes can advertise forty shared resources, but the hardware still contains four physical GPUs. The community thread supplied for this article illustrates why this can surprise operators: the count looks like capacity, while each pod still sees access to one underlying GPU and shares it with other processes [16].

• One process can consume most or all available GPU memory.
• A fault or reset can affect all workloads sharing the device.
• The scheduler cannot infer true compute demand from replica count.
• DCGM Exporter cannot associate GPU metrics with containers when time-slicing is enabled through the NVIDIA Kubernetes Device Plugin [1].
• A pod requesting multiple replicas may not receive more effective compute.

Intentional headroom has value. It absorbs bursts, protects tail latency, enables maintenance, provides failure capacity, and avoids profile repacking. The platform should measure idle capacity and challenge waste, but it should not automatically eliminate every idle cycle.

Time-slicing can make a node appear to have many allocatable GPUs. This reduces scheduler-visible scarcity but does not create more framebuffer or aggregate compute. The fragmentation becomes runtime contention, out-of-memory risk, and unpredictable queueing inside the device.

• Tenants are trusted and internal.
• Workloads are bursty, low-duty-cycle, or disposable.
• Memory use is bounded by application policy and testing.
• The service is explicitly best effort.
• The platform collects model-server, request, queue, and process telemetry to compensate for weak container attribution.

A namespace can limit a team to four GPU resources. It cannot make four time-sliced replicas become four memory-isolated devices. Dynamic Resource Allocation can improve device selection and claim handling, but it does not turn time-slicing into MIG or passthrough.

• Tenants are external or mutually untrusted.
• Workloads can allocate most of GPU memory.
• Performance or latency is committed.
• Per-tenant billing requires precise device-level attribution.
• Fault isolation is part of the service promise.

Isolation Must Be Evaluated by Dimension

Time-slicing should be treated as an internal oversubscription policy, not a security partition.

Mechanism	Memory isolation	Compute isolation	Performance isolation	Fault isolation	Administrative isolation	Suitable for hostile multitenancy
Whole GPU in Kubernetes	Strong while exclusively allocated	Strong	Strong	Good at GPU level, node still shared	Namespace and cluster dependent	Sometimes, but dedicated node may still be required
Passthrough	Strong	Strong	Strong	Good for assignment, host and PCIe remain shared	Strong VM boundary	Better, but dedicated host may be required
Standard vGPU	Strong framebuffer boundary	Shared engines unless scheduler guarantees a share	Medium	VM isolated, physical GPU reset can affect neighbors	Strong VM boundary	Conditional, depends on trust and controls
MIG	Strong hardware memory paths	Strong predefined compute allocation	Strong	Stronger than time-slicing, whole-device faults remain	Container, process, or VM boundary dependent	Good for many use cases, not equivalent to dedicated hardware
MIG-backed vGPU	Strong VM and MIG memory boundary	Strong for whole-GI profile, shared within time-sliced GI	Strong to medium	Stronger tenant boundary, physical board remains shared	Strong VM boundary	Strong fractional option when certified
Kubernetes time-slicing	None between replicas	None as a hard partition	Low	Low	Namespace only controls Kubernetes objects	No

Memory Isolation

Kubernetes does not normally ask vCenter to create an arbitrary vGPU profile for each pod through the standard device-plugin path. The VM class or worker-node design determines the vGPU capacity visible inside the cluster. The supplied NVIDIA forum discussion reflects this boundary and is useful as an operational clarification, but the current NVIDIA and Broadcom documentation should govern production design [15].

Compute Isolation

vGPU is valuable when the VM is the enterprise service boundary. It integrates GPU assignment with VM templates, VM classes, guest operating systems, backup workflows, access controls, and vMotion. VMware vSphere can live-migrate supported vGPU VMs when compatibility prerequisites are met. The destination requires compatible GPU type, framebuffer configuration, hypervisor and driver versions, and available profile capacity. Certain CUDA features, including unified memory, debuggers, and profilers, can restrict live migration [4], [7].

Performance Isolation

Passthrough is attractive when the application needs a VM boundary but does not benefit from vGPU sharing. It can also simplify compatibility for software that expects a full physical device. In VMware environments, the GPU is configured for passthrough on the ESX host, then attached to the VM or to a GPU-enabled worker-node class [5], [13].

Fault Isolation

This distinction explains much of the confusion seen in community discussions. A GPU may support bare-metal MIG but not MIG-backed vGPU on a particular hypervisor. A GPU may support standard vGPU but not MIG. A product family name alone is insufficient; the exact SKU and software matrix govern.

Administrative Isolation

With MIG, Kubernetes can advertise profile-specific resources, such as a defined MIG instance. The resource name describes a hardware profile, not a percentage. The scheduler must find a node with a compatible free instance and valid profile placement.

Cryptographic and Confidential-Computing Isolation

Memory isolation answers whether one tenant can consume, corrupt, or observe memory allocated to another. Whole GPU and passthrough avoid co-resident GPU tenants. Standard vGPU gives each vGPU exclusive framebuffer allocation. MIG creates hardware-partitioned memory paths. Kubernetes time-slicing does not create a memory boundary.

Hardware, Hypervisor, and Kubernetes Requirements

The GPU model alone does not determine support. vGPU Manager, guest driver, NVIDIA License System, hypervisor build, firmware, and application CUDA dependencies must remain compatible.

Mechanism	Hardware requirements	Hypervisor requirements	Kubernetes requirements	Driver and licensing considerations
Whole GPU	Supported GPU and server; topology matters for multi-GPU	None for bare metal; VM worker may use passthrough or vGPU	NVIDIA device plugin or GPU Operator; compatible container runtime	Data center driver or NVIDIA AI Enterprise stack as applicable; no vGPU license solely for whole-GPU device-plugin use
Passthrough	IOMMU, PCIe/MMIO support, qualified server and GPU	Supported DirectPath or PCI passthrough implementation	GPU Operator supports VMs with passthrough; worker VM owns the physical GPU	Guest driver required; vGPU Manager bypassed; enterprise software licensing may still apply
Standard vGPU	GPU listed for vGPU and certified server	Supported hypervisor, vGPU Manager, compatible host build	Kubernetes can run inside a vGPU-enabled worker VM	vGPU Manager and guest driver compatibility; NVIDIA License System and appropriate entitlement
MIG	GPU listed in current MIG support table	Optional for bare metal; passthrough and vGPU support vary	GPU Operator MIG Manager or equivalent; single or mixed MIG strategy	Supported driver, firmware, VBIOS, CUDA, and profile configuration
MIG-backed vGPU	GPU supports both MIG and vGPU	Exact hypervisor and vGPU branch support required	Kubernetes may run inside VM and sees assigned vGPU or MIG-backed device	Highest compatibility burden; vGPU license required
Time-slicing	Any supported GPU that can run the required CUDA stack; MIG not required	Bare metal, passthrough VM, or vGPU VM supported by GPU Operator	Device-plugin time-slicing config, node labels, and admission policy	No additional vGPU license on bare metal solely for time-slicing; vGPU environments retain vGPU licensing

Current Release Baseline

Time-slicing provides sharing, not memory or fault isolation. It is inappropriate as the primary boundary for untrusted paid customers.

• NVIDIA vGPU 20.1 is the current production release, while vGPU 19.5 is the current long-term-support release [6].
• NVIDIA GPU Operator 26.3.x is the current supported operator branch in NVIDIA’s platform-support documentation [9].
• The same GPU Operator documentation validates bare metal, VMs with GPU passthrough, and VMs with NVIDIA vGPU, and lists current Kubernetes and VMware vSphere Kubernetes Service support ranges [9].
• Broadcom’s current platform family is VMware Cloud Foundation 9.1 and vSphere 9.1, but NVIDIA’s exact vGPU and GPU support matrix still governs whether a specific board and ESX build are supported [8], [13].

MIG provides hardware fault isolation between instances for many classes of failure, but physical device, driver, firmware, PCIe, power, cooling, and host failures can still cross instance boundaries. Standard vGPU and time-slicing share the physical GPU fault domain. Whole-GPU and passthrough reduce co-tenant blast radius because only one tenant owns the device, but a failed board can still affect the host.

Scheduling Behavior Changes the Meaning of a GPU Request

For vGPU, include the scheduler mode in dashboards. A 16 GB profile under best effort does not have the same compute contract as the same profile under fixed share. For MIG, record the GPU Instance and Compute Instance profile, not only the memory size.

Whole-GPU Kubernetes Requests

Fine-tuning spans a broad range. Parameter-efficient methods may fit a MIG profile or large vGPU, while full-model fine-tuning may require multiple whole GPUs. The decision should be based on peak memory, optimizer state, sequence length, batch size, precision, checkpoint behavior, and interconnect needs, not on the model parameter count alone.

MIG Resource Requests

The tradeoff is stranded capacity. A notebook using 6 GB of a 96 GB GPU may hold the entire device. A small inference service may run at 10 percent average utilization but still block other workloads. That is not always a design failure. The idle headroom may be the capacity required to protect p99 latency, absorb bursts, complete a training stage on time, or reduce the blast radius of a fault.

Time-Sliced Requests

This separation reduces accidental cross-class scheduling and makes capacity evidence easier to interpret.

MIG provides strong intra-GPU isolation, but it is not a dedicated-host guarantee. The PCIe device, board, driver, firmware, power domain, cooling path, and physical host remain shared. Some faults can still affect the whole GPU or node. External hostile multitenancy or stringent compliance may still require dedicated GPUs or hosts.

This article assumes NVIDIA data center or enterprise RTX accelerators in enterprise servers, with workloads delivered through bare metal, virtual machines, Kubernetes, or Kubernetes worker nodes running as VMs. It does not treat consumer desktop GPUs as equivalent substitutes for certified data center deployments.

vGPU Placement

For every candidate design, verify the server, GPU SKU, firmware, BIOS, VBIOS, hypervisor, vGPU branch, host manager, guest driver, Kubernetes version, GPU Operator, CUDA runtime, application framework, and license entitlement.

Avoid standard vGPU when:

• Kubernetes worker VMs receive vGPU devices from the hypervisor, then the NVIDIA device plugin exposes those devices to pods.
• A VM-based workload consumes the vGPU directly without Kubernetes.

GPU-S should be marketed as shared access. Its contract should state that compute performance varies and that the service may be preempted. When implemented with Kubernetes time-slicing, it must not promise isolated memory. When implemented with a small vGPU, it may promise framebuffer capacity but still needs a compute-sharing statement.

Dynamic Resource Allocation

Use standard vGPU for enterprise VM fleets that need lifecycle integration and mobility. Choose the scheduler mode deliberately. Do not treat framebuffer size as a compute guarantee. Use MIG-backed vGPU only after exact compatibility and migration testing.

Fragmentation and Stranded Capacity

VMware vSphere 9 support for MIG-backed vGPU begins with NVIDIA vGPU 19.0 in NVIDIA’s current deployment guide. That does not mean every MIG-capable GPU, vGPU profile, VMware release, and migration function is supported. The product support matrix must be checked for the exact GPU and ESX build [5], [8].

Whole-GPU Fragmentation

For time-sliced services, chargeback based only on advertised replica-hours is misleading. Replica-hours measure entitlement or access duration, not useful work. Add model-server metrics such as requests, tokens, batch size, latency, queue time, memory allocation, and active execution time.

Passthrough Fragmentation

Create CPU-only, GPU-S, GPU-M, and GPU-C contracts. Define guarantees, limits, priority, preemption, isolation, monitoring, and support. Then map mechanisms to classes.

vGPU Profile Fragmentation

A practical enterprise default can be expressed as a small set of rules.

The most important design rule is to separate three layers:

MIG Geometry Fragmentation

Compute isolation answers whether one tenant has dedicated SMs or a guaranteed compute share. Whole GPU, passthrough, and MIG provide the clearest answer. Standard vGPU shares engines unless the scheduler policy supplies an enforceable share. Time-slicing provides neither dedicated SMs nor a proportional guarantee.

Time-Slicing Hides, Rather Than Solves, Fragmentation

Choose time-slicing when:

An unconstrained profile catalog creates packing failures and operational churn. Standardize a few profiles aligned to measured workloads.

Monitoring and Evidence Limitations

MIG divides supported GPUs into predefined GPU Instances and Compute Instances. NVIDIA describes dedicated memory paths, L2 cache, memory controllers, DRAM address buses, and assigned compute resources that provide predictable throughput, latency, quality of service, and fault isolation [2].

Mechanism	Best evidence source	Main limitation
Whole GPU	DCGM, DCGM Exporter, nvidia-smi, pod and node metadata	One allocation can still host multiple application processes
Passthrough	Guest DCGM and application metrics, hypervisor assignment inventory	Host has limited process visibility; tenant must expose guest telemetry
Standard vGPU	Hypervisor vGPU metrics plus guest metrics and VM identity	Compute sharing must be interpreted with scheduler mode and co-resident profiles
MIG	DCGM with MIG-aware entity identifiers, Kubernetes profile metadata	Ampere-era nvidia-smi process attribution can be limited; use supported DCGM versions
MIG-backed vGPU	Hypervisor, guest, MIG entity, and VM profile telemetry	Multiple identity layers complicate end-to-end attribution
Time-slicing	Application, model-server, pod, process, queue, and node metrics	DCGM Exporter cannot associate metrics to containers through device-plugin time-slicing [1]

This makes MIG the strongest fractional-GPU mechanism in the comparison. A workload receives a real hardware partition rather than a scheduling token. The instance appears as a schedulable GPU resource to containers, processes, or supported virtualized deployments.

Maximum utilization is not the goal. The goal is predictable, secure, supportable, and measurable useful work. Sometimes that means sharing a GPU aggressively. Sometimes it means leaving deliberate headroom. Sometimes it means dedicating an expensive device to one workload because the cost of contention, missed latency, failed recovery, or weak tenant isolation is higher than the value of the idle cycles.

Security and Multitenancy Policy

The cost is reduced mobility and placement flexibility. Direct device assignment constrains host maintenance, DRS placement, and migration. The platform should treat live mobility as unsupported unless the exact hypervisor, GPU, firmware, and feature combination explicitly documents it. Operational recovery usually means shutting down, detaching, reassigning, or restarting the VM on a compatible host.

Trusted Internal Development

An enterprise GPU platform exists to deliver business workloads, not to produce a beautiful utilization graph. A GPU running at 95 percent can still be poorly managed if production requests queue behind experiments, customer latency varies unpredictably, or no one can attribute consumption.

Internal Production

The following decision tree deliberately starts with service requirements, not utilization.

Regulated Workloads

Avoid passthrough when:

External Paid Customers

“Isolated” is not a single technical property. The platform should evaluate at least six dimensions: memory, compute, performance, fault, administrative, and tenant-security isolation.

• MIG for hardware-partitioned container services.
• MIG-backed vGPU for VM-delivered fractional services where certified.
• Standard vGPU only when the contract accurately describes shared engines and the scheduler policy.
• Whole GPU or passthrough for premium isolation and performance.
• Dedicated host when the threat model or contract requires a physical boundary.

Avoid MIG when:

Training, Inference, Development, and Research Fit

Large-Scale Training

Kubernetes Dynamic Resource Allocation is now a stable framework for richer device claims and device classes [11]. It can improve device selection, claim lifecycle, and structured resource parameters. It should not be marketed as an isolation mechanism. A DRA claim for a shared GPU is still backed by a shared GPU unless the driver allocates a partitioned or dedicated device.

Regulated workloads require evidence that the complete trust boundary is acceptable. MIG can strengthen intra-GPU isolation, but compliance may also require dedicated nodes, separate clusters, restricted administrators, encrypted storage, network segmentation, confidential computing, controlled images, and audit retention. Do not present MIG alone as a compliance solution.

Fine-Tuning

Avoid time-slicing when:

Production Inference

vGPU live migration has prerequisites and feature exclusions. MIG-backed profiles require their own validation. Passthrough should be treated as mobility-constrained unless explicitly proven otherwise.

• Whole GPU for large models, strict latency, predictable bursts, or premium service.
• MIG for smaller models with defined memory and throughput needs.
• MIG-backed vGPU for VM-based isolated inference.
• Standard vGPU for VM mobility when engine sharing is acceptable or fixed-share scheduling is validated.
• Time-slicing for internal low-duty-cycle endpoints without hard latency guarantees.
• Passthrough for a VM-based inference appliance needing exclusive control.

Interactive Development and Notebooks

This is why “vGPU on Kubernetes” usually means one of two things:

Research and Experimental Workloads

NVIDIA vGPU allows multiple VMs to receive virtual GPU devices from one physical GPU. Each vGPU profile receives a fixed framebuffer allocation that remains exclusive to that vGPU while it exists. On a standard single-instance GPU, vGPU processes share the GPU engines through time-sliced scheduling [4].

Workload-to-Allocation Decision Matrix

Workload or tenant pattern	Preferred allocation	Acceptable alternative	Usually avoid	Decision rationale
Distributed foundation-model training	Whole GPU	Passthrough to dedicated training VMs	Time-slicing, small MIG	Needs topology, memory, bandwidth, and predictability
Single-GPU full fine-tuning	Whole GPU	Passthrough or full-profile vGPU	Time-slicing	Memory pressure and duration sensitivity
Parameter-efficient fine-tuning	MIG or whole GPU	Large vGPU	Time-slicing without memory controls	Can fit a partition but still needs reproducibility
Large-model production inference	Whole GPU	Passthrough or full-profile vGPU	Time-slicing	p95 and p99 latency plus memory footprint
Small-model production inference	MIG	MIG-backed vGPU or standard vGPU with validated scheduler	Uncontrolled time-slicing	Predictable fractional capacity
Internal low-volume inference	MIG or standard vGPU	Time-slicing	Passthrough unless required	Balance utilization and acceptable variability
Developer notebook	Small MIG or small vGPU	Time-slicing with idle timeout	Whole GPU as permanent assignment	Interactive duty cycle and memory guardrails
CUDA validation and CI tests	Time-slicing	Small MIG	Passthrough	Short, disposable, trusted workloads
Research profiling	Whole GPU	Passthrough	Standard vGPU with migration constraints	Needs direct metrics and profiler access
GPU-enabled enterprise VM	Standard vGPU	Passthrough	Kubernetes time-slicing outside the VM contract	VM lifecycle and mobility
External paid fractional GPU	MIG or MIG-backed vGPU	Standard vGPU with explicit shared-engine contract	Kubernetes time-slicing	Isolation and billable evidence
External paid dedicated GPU	Whole GPU or passthrough	Full-GPU vGPU where mobility is required	Shared profiles	Clear premium boundary
Regulated sensitive inference	Dedicated whole GPU, potentially dedicated node	MIG with full control stack	Time-slicing	Trust boundary and audit evidence
Bursty internal batch queue	Whole GPU with queueing	MIG or time-slicing for small jobs	Static passthrough	Scheduler can reclaim and backfill capacity
CPU-sufficient preprocessing	CPU-only	GPU-S for validated acceleration	Permanent GPU allocation	Avoid consuming accelerators for CPU-bound work

Service Classes Should Be Stable, Mechanisms Can Change

Internal production services should normally use whole GPU, MIG, standard vGPU with an appropriate scheduler, or MIG-backed vGPU. Selection depends on latency, mobility, and isolation. A low-volume internal API may be a good MIG candidate. A VM-based AI application requiring vMotion may fit standard vGPU. A large inference engine with strict p99 latency may require a whole GPU.

Service class	Intended consumer	Technical contract	Candidate implementations	Business entitlement
CPU-only	Preprocessing, orchestration, light analytics, non-accelerated services	No accelerator guarantee	CPU nodes or VMs	Standard quota, no GPU borrowing by default
GPU-S, Shared	Internal development, CI, light notebooks, bursty inference	Best effort, no hard compute guarantee, limited support objective	Kubernetes time-slicing, small standard vGPU, time-sliced MIG-backed vGPU where certified	Low or zero guarantee, borrowable, preemptible, usage cap
GPU-M, Managed Partition	Small production inference, controlled notebooks, paid fractional service	Defined memory profile, defined isolation, monitored capacity, documented performance envelope	MIG, whole-GI MIG-backed vGPU, fixed or equal-share vGPU after validation	Guaranteed quota, bounded borrowing, protected from lower classes
GPU-C, Committed	Critical production, large inference, training, regulated or premium customer	Dedicated device or equivalent full-capacity commitment, strongest performance and support objective	Whole GPU, passthrough, full-GPU vGPU when mobility is required	Guaranteed reservation, high priority, non-preemptible, explicit recovery objective

GPU-S Is an Access Product, Not a Fraction

MIG profiles occupy predefined geometry. A node can have free memory and free compute slices but still lack a valid contiguous placement for a requested profile. Repacking can require draining workloads and recreating instances. The platform should standardize a small set of supported MIG layouts rather than offering every possible profile.

GPU-M Is a Partitioned Product

Choose MIG-backed vGPU when:

GPU-C Is a Business Commitment

For every class, publish the actual isolation statement, resource name, supported workloads, SLO, quota behavior, monitoring limitations, and escalation path. Make the physical-to-logical capacity mapping visible to platform operators and consumers.

Business Entitlement Fields

Introduction

The platform should model the decision in three layers:

Recommended Enterprise Policy

Choose whole GPU when:

Default to Whole GPU for Critical Work

Encryption at rest and in transit does not change GPU allocation behavior. Confidential computing can protect data in use on supported platforms, but it should be treated as a separate control plane. A confidential VM with a vGPU is not automatically a dedicated GPU, and a MIG partition is not automatically a confidential-computing boundary. The platform must verify whether the selected GPU, CPU, hypervisor, guest, driver, and attestation path support the required confidential-computing mode.

Use MIG as the Preferred Fractional Production Mechanism

Use node pools or clusters to separate:

Use vGPU When the VM Is the Product Boundary

These mechanisms are useful, but they solve different problems. The enterprise decision is not simply which mechanism achieves the highest average utilization. It is which combination of allocation mechanism, platform boundary, service class, and business entitlement produces an acceptable balance of isolation, performance, mobility, operational complexity, supportability, and cost.

Restrict Time-Slicing to Trusted Best-Effort Classes

Forty time-sliced replicas are not forty physical GPUs. Dashboards and catalogs must state the physical-device count and the allocation mechanism.

Preserve a CPU-Only Default

A governed GPU service should never expose a raw mechanism as though it were a complete product. “One MIG slice,” “one vGPU,” or “one shared GPU” does not tell a consumer whether the capacity is guaranteed, preemptible, dedicated, metered, or recoverable.

Separate Node Pools by Operational Purpose

Use whole GPUs for training, large inference, strict latency, sensitive workloads, and premium customer commitments until measurement proves that a partitioned class meets the same objective.

• GPU generation and memory size.
• Whole-GPU and shared-GPU policy.
• MIG layouts.
• vGPU-backed and passthrough-backed worker VMs.
• Production and development service classes.
• External customer and internal tenant trust zones.
• Confidential-computing capable hardware.
• High-speed fabric and standard Ethernet requirements.

The enterprise catalog should expose stable service classes rather than raw vendor mechanisms. The following example uses four classes.

Common Design Failures

Calling Every Advertised Resource a GPU

Place time-sliced GPUs in dedicated node pools. Label the resource as shared. Prevent production and external namespaces from requesting it. Enforce one shared token per pod, memory-aware application controls, idle timeouts, and model-server telemetry.

Treating Framebuffer as Compute Capacity

A decision matrix is useful only when the chosen option can be implemented on the actual platform. Compatibility must be treated as a chain, not as a GPU feature checkbox.

Assuming MIG Means vGPU Support

Performance isolation includes latency, throughput, memory bandwidth, cache behavior, and scheduler jitter. MIG is designed to provide predictable resource allocation within its supported profiles. Standard vGPU behavior depends on scheduler mode and neighboring activity. Time-slicing is intentionally opportunistic.

Allowing Every MIG Profile

That is a reminder that framebuffer arithmetic is not sufficient. The placement matrix, scheduler mode, hypervisor, and existing profiles determine whether the next VM can start.

Selling Time-Slicing as Isolation

Kubernetes namespaces, ResourceQuotas, PriorityClasses, taints, node selectors, and Dynamic Resource Allocation can control who may request a resource and where a workload is placed. They do not change the physical isolation characteristics of the underlying GPU mechanism.

Assuming vMotion Solves Every Mobility Problem

High utilization can increase queue time, p99 latency, failure blast radius, thermal stress, and operational uncertainty. A platform should optimize useful work delivered within service objectives, not a single utilization percentage.

Ignoring the Driver and Licensing Chain

With time-slicing, replicas multiply the advertised resource count. When renameByDefault is enabled, the operator can advertise a shared resource name. The following pod requests one shared access token. It does not request a guaranteed percentage of the GPU.

Optimizing for Average Utilization Only

Passthrough also moves much of the useful GPU telemetry into the guest. The hypervisor knows the PCI device assignment, but process-level and framework-level metrics are normally collected inside the VM. This can be acceptable for a single accountable tenant, but it complicates centralized showback when guest access is delegated.

Why Maximum Utilization Is Not the Correct Goal

A standard vGPU has a fixed amount of framebuffer reserved for the VM, but the GPU engines are commonly shared through a time-sliced scheduler. NVIDIA provides best-effort, equal-share, and fixed-share scheduling modes on supported combinations. Best effort maximizes opportunistic use, equal share divides cycles among active vGPUs, and fixed share provides a configured share while potentially leaving unused cycles idle [4], [7].

Interactive sessions often hold memory while using little compute. Time-slicing can improve access density, but a single user may still exhaust memory. Small vGPU or MIG profiles provide better guardrails. A queue-based notebook service can release the GPU after idle timeout and preserve the workspace on persistent storage.

Framebuffer size is not a compute entitlement. Two VMs with the same framebuffer profile can experience different performance under best effort because neighboring demand changes.

MIG configuration changes can also require workload evacuation, instance destruction, or node reconfiguration. A mixed set of profile sizes can strand capacity that cannot be assembled into the requested shape. The scheduler may report free slices while no valid placement exists for the next profile.

Implementation Roadmap

Inventory the Workload Demand

Validate driver upgrades, GPU Operator upgrades, MIG reconfiguration, vGPU Manager upgrades, VM migration, host maintenance, pod eviction, node failure, GPU reset, license-service interruption, and rollback.

Define Service Classes Before Mechanisms

Bare-metal MIG support, standard vGPU support, MIG-backed vGPU support, and hypervisor support are separate compatibility checks. The RTX PRO 6000 Blackwell family is a current example where exact edition matters [3], [8], [17].

Validate the Compatibility Chain

MIG is not infinitely flexible. Profiles are predefined, the maximum number of instances varies by product, and placement geometry matters. For example, current documentation lists up to seven instances on A100, H100, H200, B200, and GB200 products, but up to four on the RTX PRO 6000 Blackwell variants and A30 [3]. The platform cannot arbitrarily create any memory or compute ratio it wants.

Build Separate Pilot Pools

A vGPU request is a profile-placement problem handled by the hypervisor. The VM receives a specific framebuffer profile, and the hypervisor must find a physical GPU with a valid placement. Kubernetes running inside that VM can only schedule against the virtual device already assigned to the worker node.

Benchmark the Service, Not Just the GPU

The first matrix shows the default enterprise posture. “High” does not mean perfect security or absolute performance. It means the mechanism provides a comparatively strong boundary for that dimension when configured on a supported platform.

Test Failure and Maintenance Operations

Time-slicing can be useful for low-duty-cycle notebooks, compile tests, CUDA validation, light experimentation, and small inference processes that do not run concurrently at peak. It is dangerous when presented as a guaranteed service because:

Conclusion

This model is operationally simple because the platform does not need to maintain vGPU profile packing or MIG geometry. The workload receives all framebuffer and compute engines on the device. Monitoring is also comparatively direct because device metrics map more cleanly to one workload or one pod allocation.

Avoid MIG-backed vGPU when:

The correct objective is service-effective utilization. It combines useful work, performance, reliability, and cost:

External References