Introduction

Enterprise GPU design becomes confused when several different decisions are compressed into one question: “How should we share the GPU?” That question mixes hardware assignment, virtualization, Kubernetes scheduling, tenant isolation, business priority, and service-level commitments. The result is often a platform that advertises many GPU “slices” but cannot explain what each slice guarantees.

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.

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.

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.

TL;DR

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.

The most important design rule is to separate three layers:

• 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.

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

The Decision Has Three Separate Layers

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.

The platform should model the decision in three layers:

The same service class can sometimes be implemented by more than one mechanism. A committed production class might use a dedicated whole GPU in Kubernetes, passthrough to a VM, or a full-framebuffer vGPU when vMotion is required. A small internal development class might use a small vGPU profile, a MIG instance, or time-sliced access, but those implementations do not provide identical guarantees.

This separation also prevents the catalog from becoming tied to one GPU generation. The business can retain stable service names while the platform team changes the underlying implementation from an L40S vGPU profile to an H200 MIG profile, for example, after testing and approval.

Allocation Mechanisms at a Glance

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.

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

The most important distinction is between sharing and partitioning.

• 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

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.

Whole GPU Does Not Automatically Mean Passthrough

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.

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.

vGPU Is Not a Synonym for MIG

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].

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:

• 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

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].

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.

Kubernetes Scheduling Does Not Create Physical 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.

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.

How Each Allocation Model Actually Works

Dedicated Whole-GPU Allocation

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.

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.

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.

Choose whole GPU 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.

Avoid whole GPU as the universal default when:

• 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 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.

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].

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.

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.

Choose passthrough when:

• 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.

Avoid passthrough when:

• 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

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].

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.

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].

vGPU also introduces an important scheduling choice:

• 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.

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.

Choose standard vGPU when:

• 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.

Avoid standard vGPU when:

• 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

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].

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.

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.

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.

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.

Choose MIG when:

• 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.

Avoid MIG when:

• 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

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:

• 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].

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.

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].

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.

Choose MIG-backed vGPU when:

• 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.

Avoid MIG-backed vGPU when:

• 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

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].

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].

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:

• 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.

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

Choose time-slicing when:

• 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.

Avoid time-slicing when:

• 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

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

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

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.

Compute Isolation

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.

Performance Isolation

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.

Fault Isolation

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.

Administrative Isolation

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.

Cryptographic and Confidential-Computing Isolation

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.

Hardware, Hypervisor, and Kubernetes Requirements

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.

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

As of the research date:

• 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].

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.

Scheduling Behavior Changes the Meaning of a GPU Request

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

Whole-GPU Kubernetes Requests

A normal extended-resource request for 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.

MIG Resource Requests

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.

Time-Sliced Requests

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.

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

The reader should change the product label, image, toleration, and shared-resource name to match the validated cluster configuration. A successful deployment means the pod lands only on the approved shared GPU node pool, sees the GPU, and remains within application-level memory and runtime controls. A failure can occur if the shared resource was not renamed, the node label differs, the device-plugin configuration was not restarted, or no shared replica is allocatable.

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.

vGPU Placement

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.

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

• 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.

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].

Dynamic Resource Allocation

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.

Fragmentation and Stranded Capacity

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.

Whole-GPU Fragmentation

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.

Passthrough Fragmentation

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.

vGPU Profile Fragmentation

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].

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.

MIG Geometry Fragmentation

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.

Time-Slicing Hides, Rather Than Solves, Fragmentation

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.

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.

Monitoring and Evidence Limitations

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

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]

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.

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.

Security and Multitenancy Policy

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

Trusted Internal Development

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.

Internal Production

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.

Regulated Workloads

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.

External Paid Customers

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

• 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.

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

Training, Inference, Development, and Research Fit

Large-Scale Training

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.

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.

Fine-Tuning

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.

Production Inference

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

• 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

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.

Research and Experimental Workloads

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.

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

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

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

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.

GPU-M Is a Partitioned Product

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.

GPU-C Is a Business Commitment

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.

Business Entitlement Fields

Every service-class record should include:

• Guaranteed GPU count or profile count.
• Maximum consumption limit.
• Borrowing eligibility.
• Reclamation notice and grace period.
• Priority and preemption policy.
• Maximum queue time or startup objective.
• Performance and latency envelope.
• Memory and compute isolation statement.
• Fault-domain statement.
• Monitoring and chargeback method.
• Recovery, maintenance, and mobility behavior.
• Approved workload data classifications.
• Support hours and escalation path.

A Practical Decision Tree

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

A second pass should then validate mobility, observability, licensing, failure domains, and cost. The first technically feasible answer is not automatically the correct service design.

Recommended Enterprise Policy

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

Default to Whole GPU for Critical Work

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.

Use MIG as the Preferred Fractional Production Mechanism

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.

Use vGPU When the VM Is the Product Boundary

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.

Restrict Time-Slicing to Trusted Best-Effort Classes

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.

Preserve a CPU-Only Default

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.

Separate Node Pools by Operational Purpose

Use node pools or clusters to separate:

• 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.

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

Common Design Failures

Calling Every Advertised Resource a GPU

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

Treating Framebuffer as Compute Capacity

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.

Assuming MIG Means vGPU Support

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].

Allowing Every MIG Profile

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

Selling Time-Slicing as Isolation

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

Assuming vMotion Solves Every Mobility Problem

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.

Ignoring the Driver and Licensing Chain

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.

Optimizing for Average Utilization Only

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.

Why Maximum Utilization Is Not the Correct Goal

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.

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

Service-Effective Utilization =

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

This is not a universal accounting formula. It is an operating principle. Useful work can be tokens generated within latency targets, training steps completed within a deadline, inference requests served without error, or researcher jobs completed within a queue-time objective.

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.

Implementation Roadmap

Inventory the Workload Demand

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.

Define Service Classes Before Mechanisms

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.

Validate the Compatibility Chain

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.

Build Separate Pilot Pools

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.

Benchmark the Service, Not Just the 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.

Test Failure and Maintenance Operations

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.

Publish the Catalog and Evidence

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.

Conclusion

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.

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.

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.

External References

• [1] NVIDIA: Time-Slicing GPUs in Kubernetes
  Canonical URL: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-sharing.html
• [2] NVIDIA: Introduction, NVIDIA Multi-Instance GPU User Guide
  Canonical URL: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/introduction.html
• [3] NVIDIA: Supported GPUs, NVIDIA Multi-Instance GPU User Guide
  Canonical URL: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/latest/supported-gpus.html
• [4] NVIDIA: Virtual GPU Software User Guide
  Canonical URL: https://docs.nvidia.com/vgpu/latest/grid-vgpu-user-guide/index.html
• [5] NVIDIA: VMware vSphere Installation and vGPU Configuration
  Canonical URL: https://docs.nvidia.com/vgpu/deployment/vmware/latest/vgpu-config.html
• [6] NVIDIA: NVIDIA Virtual GPU Software
  Canonical URL: https://docs.nvidia.com/vgpu/index.html
• [7] NVIDIA: vGPU Features, Comprehensive Knowledge Base on vGPU Features Across Hypervisors
  Canonical URL: https://docs.nvidia.com/vgpu/knowledge-base/latest/vgpu-features.html
• [8] NVIDIA: VMware vSphere ESXi Support, NVIDIA vGPU Software v20.0 through 20.1
  Canonical URL: https://docs.nvidia.com/vgpu/20.0/product-support-matrix/vmware-vsphere.html
• [9] NVIDIA: Platform Support, NVIDIA GPU Operator
  Canonical URL: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html
• [10] Kubernetes: Schedule GPUs
  Canonical URL: https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
• [11] Kubernetes: Dynamic Resource Allocation
  Canonical URL: https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
• [12] Kubernetes: Multi-Tenancy
  Canonical URL: https://kubernetes.io/docs/concepts/security/multi-tenancy/
• [13] Broadcom: Configure NVIDIA vGPU or GPU Passthrough for AI Workloads
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-0/private-ai-foundation-9-x/deploying-private-ai-foundation-with-nvidia/configure-nvidia-vgpu-or-gpu-passthrough-on-the-esx-hosts.html
• [14] Broadcom: Configure VM Classes for AI Workloads for VMware Private AI Foundation with NVIDIA
  Canonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/private-ai/foundation-with-nvidia/9-0/private-ai-foundation-9-x/deploying-private-ai-foundation-with-nvidia/configure-vgpu-based-vm-classes-for-ai-workloads.html
• [15] NVIDIA Developer Forums: vGPU on Kubernetes
  Canonical URL: https://forums.developer.nvidia.com/t/vgpu-on-kubernetes/341704
• [16] NVIDIA Developer Forums: Expected Behavior with NVIDIA GPU Operator and Time-Slicing on a Server with Multiple GPUs
  Canonical URL: https://forums.developer.nvidia.com/t/expected-behavior-with-nvidia-gpu-operator-and-time-slicing-on-server-with-multiple-gpus/353675
• [17] NVIDIA Developer Forums: MIG Support on RTX PRO 6000 Blackwell
  Canonical URL: https://forums.developer.nvidia.com/t/mig-support-on-rtx-pro-6000-blackwell/334906?page=4

The post Whole GPU, Passthrough, vGPU, MIG, or Time Slicing? The Enterprise GPU Allocation Decision Matrix appeared first on Digital Thought Disruption.