MIG, Time-Sliced vGPU or a Whole GPU: What Allocation Are You Buying?

Describe the allocation before comparing its price

Start with the resource the supplier is assigning. A whole-device allocation reserves the physical GPU for the stated use. In a virtualized environment, NVIDIA distinguishes GPU passthrough, which assigns an entire physical GPU to one VM, from vGPU sharing. A VM can therefore receive a whole device; VM delivery does not necessarily mean a fractional GPU.

Then ask what the customer can actually use and who else can use the same resources. A count of virtual devices, a memory figure and a promise of dedicated compute answer different questions. Compare them separately instead of translating every fractional label into a percentage of a card's performance.

For this buying decision, define whole-device exclusivity at the physical GPU boundary. Ask whether the offer instead dedicates only a VM, a framebuffer allocation or a hardware instance. Exclusivity at one boundary does not establish exclusive use of the entire server or ownership of the equipment. The supplier's returned allocation description should make that boundary explicit.

References: [N4]

Time-slicing reserves memory while scheduling compute access

NVIDIA's AI Enterprise Release 7 overview describes a vGPU with fixed framebuffer reserved from its creation until it is destroyed. In time-sliced vGPU, the VMs take scheduled turns using the shared GPU's streaming multiprocessors, or SMs, and engines. Memory can remain assigned while another VM receives its compute turn. Resident data is therefore different from continuously available compute.

Four running VMs do not imply four independently executing hardware partitions. Ask which resources they time-share and how the offered scheduling policy distributes access when several VMs are busy. NVIDIA documents different scheduling policies, including best effort, equal share and fixed share. VM count alone does not identify the policy or establish equal time.

This distinction matters when workloads overlap. A development environment with intermittent jobs and a service that needs compute throughout a busy interval present different demands. Ask for workload evidence under the intended competing activity. A result obtained while the other allocations are idle cannot answer how the offer behaves when all are active.

References: [N2][N5]

MIG creates hardware instances with a specific resource boundary

NVIDIA defines a MIG GPU instance, or GI, as a combination of GPU slices and engines. Its assigned memory resources include capacity and bandwidth. Its SM resources can be subdivided into compute instances, or CIs. Those CIs share their parent GI's memory and engines, even though they receive separate SM resources.

Consequently, ask whether an offer supplies separate GIs or CIs inside one GI. Those descriptions do not promise the same memory-resource separation. A label such as isolated fraction is insufficient to identify the boundary.

The permitted divisions are defined by supported instance profiles and combinations. They are not arbitrary percentages selected by dividing the device's headline memory. Request the actual GI profile and any CI subdivision for the named GPU. Preserve compute, memory and engine allocations as distinct fields.

References: [N1]

vGPU delivery can sit on top of MIG

A vGPU Manager on the hypervisor exposes a virtual GPU device to a guest VM. MIG-backed vGPU places that delivery on a hardware GPU instance. In NVIDIA's description, a vGPU backed by its own GI uses that instance's resources, while workloads on other GIs can execute in parallel. This combines spatial allocation with a virtual GPU presented to the guest. MIG and vGPU are therefore compatible dimensions of an offer.

There is a further distinction on configurations that support time-sliced MIG-backed vGPU. Several VMs can time-share resources within one GI, while separate GIs retain their hardware partition boundaries. Ask which VMs occupy the same parent instance and which receive separate instances. The presence of MIG somewhere on the card does not establish a separate GI for every VM.

Read the exact backing mode with the profile. These mechanisms describe allocation boundaries; they do not by themselves approve a tenant-security design, guarantee application latency or establish a service-level result.

References: [N2][N3]

Compare two fictional offers for four allocations on one GPU

Suppose two fictional offers each advertise four GPU allocations on one physical GPU, delivered to four VMs. Each lists framebuffer for every VM. The example compares the descriptions only: it names no real GPU, memory size, supported profile combination, price or test result.

Offer A explicitly supplies time-sliced vGPU. All four VMs share the physical GPU's compute through scheduling. Its memory lines identify assigned framebuffer, but its description leaves the applicable scheduling policy and behavior during simultaneous demand unresolved. Calling each allocation a quarter GPU would add a compute entitlement that A has not stated.

Offer B stipulates four separate supported MIG GIs, each backing one vGPU, with no further time-sharing within those GIs. The stipulated difference is that the VMs receive separate hardware compute partitions capable of parallel execution. The supplier must still identify the real GPU and valid profiles that would implement B. This example supplies no profile by dividing a card into quarters, and does not assume equal memory or compute resources across the four instances.

Now give both suppliers the same requirement: four workloads must remain active during one shared operating interval. A needs to explain the offered compute-time allocation and provide relevant evidence with competing work present. B needs to establish that each selected hardware instance supplies the resources required by its assigned workload. Neither description establishes that the workloads fit their memory allocations or meet a completion or response-time target.

If B changes its proposal to place several VMs inside one time-sliced GI, the buyer must reassess that changed resource relationship. Four visible devices would still appear in the offer, but four separate hardware instances would no longer describe it. Compare the returned resource mapping before comparing cost. Both original offers use one physical GPU; allocation has created neither extra cards nor separate physical equipment for every VM.

Choose the mechanism and verify the complete software combination

A whole-device allocation can address a requirement for access to the complete GPU without sharing it with other VMs. Temporal sharing can address workloads willing to take compute turns. Spatial partitioning can address a requirement for simultaneous access to separate hardware compute allocations, provided the supported profiles suit the jobs. None of these choices inherently establishes a lower cost or a faster application.

After selecting that resource model, obtain the supported implementation. NVIDIA's version-pinned AI Enterprise Infrastructure 7.8 matrix distinguishes vGPU Manager on the host from the vGPU guest driver in the VM and lists deployment combinations. Match the exact GPU and server, backing mode, profiles, hypervisor, guest OS and host/guest driver releases. A GPU's MIG capability alone cannot answer those software-support questions.

Identify who supplies the software entitlement and who owns its continuing operation. The Release 7 licensing guidance requires vGPU for Compute VMs to obtain the applicable license for full functionality. Buying a GPU or assigning framebuffer does not document that entitlement. Have the appointed software supplier connect the offered configuration to its actual licensing and support scope.

Finally, ask the application owner to define useful output and the evidence needed under the intended concurrent workload. Keep memory fit, compute access and application performance distinguishable. The allocation description should explain what is being purchased; workload evidence determines whether that purchase serves the intended job.

References: [N4][N6][N7]

Take the selected hardware package into physical deployment planning

If the decision leads to customer equipment installation, bring the confirmed server configuration, physical GPU quantity, rack layout, supplied mounting parts and IT connection requirements to Leviathan's Complete Physical Infrastructure Deployment service. The physical package can combine receiving, rack integration, agreed hardware QA, onsite installation, cabling and handoff records around the stages the project needs.

Name the team that will receive the equipment and separately deliver the virtualization environment. MIG configuration, hypervisor and guest software, licensing, tenant-security decisions and workload acceptance remain with the appointed platform and software owners. Agree the physical tasks, available resources and returned records for the engagement.

Use the service and project-inquiry links below to share a nonconfidential equipment and site outline. Describe the actual servers and connections to install alongside the intended software handoff. A change from four whole GPUs to four allocations on one GPU only changes the physical installation package if the selected hardware package actually changes.

References: [L1]