GPU Partitioning MIG Explained: MIG vs Time-Slicing (UK 2026)

The 5% problem: why million-pound GPU fleets sit idle

The headline figure for 2026 is uncomfortable: Cast AI's analysis of 23,000 production Kubernetes clusters puts average enterprise GPU utilisation at 5%, meaning the overwhelming majority of provisioned GPU capacity is never touched by a workload at any given moment. That is not a rounding error — it is the default state of most GPU estates, because most workloads are sized nowhere near the full capability of a modern accelerator.

This is what the industry calls the 'GPU atomicity problem': a single high-end GPU is often too much card for the job. A small inference endpoint, a notebook session, or a lightweight fine-tuning run doesn't need the full compute, memory bandwidth and cache of a flagship part, but until recently the only unit of allocation was the whole GPU. Every job below full size therefore wastes the remainder.

For UK buyers the arithmetic is sharper than most. A new NVIDIA H100 PCIe card carried a landed UK price of roughly £32,050 in June 2026 once VAT, import duties and certification are factored in. Each accelerator sitting at 5% utilisation is, in effect, a five-figure asset earning a fraction of its keep — which is exactly the gap that GPU partitioning technologies like MIG and time-slicing are built to close. Anyone exploring GPU accelerators for a new deployment needs to size for the workload, not just the card.

What MIG actually does: hardware-level partitioning, not a software trick

Multi-Instance GPU (MIG) is a hardware feature, not a scheduling hack. It was introduced with NVIDIA's Ampere architecture and has since been extended through Hopper and Blackwell, meaning it is present across the current generation of accelerators UK buyers are deploying today.

MIG physically partitions a single GPU into multiple instances, each of which behaves like a standalone GPU with its own dedicated memory, cache and compute cores. Because the split happens at the hardware level rather than through software time-sharing, each instance gets strong isolation and predictable performance — one tenant's workload cannot starve or interfere with another's, because they are not actually sharing the same silicon resources at the same time.

The trade-off is rigidity. MIG profile sizes are fixed once configured, and resizing an instance means destroying and recreating it — which interrupts whatever workload is currently running on it. That inflexibility is the price of the isolation guarantee, and it is the single biggest planning consideration for anyone deploying MIG at scale.

MIG vs time-slicing vs MPS vs vGPU: picking the right sharing model

MIG is not the only way to share a GPU, and it is not always the right one. Time-slicing is a purely software-based approach: multiple workloads share the entirety of the GPU's resources through context switching, with no hardware partitioning involved. It works on virtually any NVIDIA GPU supported by the relevant operator, and it delivers much higher workload density than MIG — but it does not offer MIG's strong isolation guarantees, since jobs are still competing for the same underlying compute and memory at different moments in time.

NVIDIA's Multi-Process Service (MPS) sits between the two: it lets multiple CUDA processes execute kernels concurrently on the same GPU with process-level isolation and memory caps, an approach that has been enhanced on Volta-generation architectures and later. It suits concurrent microservice-style CUDA workloads that need some separation but not the full hardware wall MIG provides.

On the virtualisation side, Microsoft's Hyper-V GPU partitioning (GPU-P) uses SR-IOV to share a physical GPU across multiple virtual machines with hardware-backed security and predictable performance, and — since Windows Server 2025 — supports live migration of those partitioned VMs, which matters for enterprises running mixed Windows virtualisation estates rather than bare-metal Linux clusters.

The decision comes down to how much isolation the workload genuinely needs versus how much density matters. Multi-tenant environments with strict SLA or compliance requirements point towards MIG or SR-IOV-based vGPU. Homogeneous internal batch or development workloads, where occasional contention is tolerable, point towards time-slicing. Concurrent CUDA microservices that need memory caps but not full hardware separation are MPS's sweet spot.

Stranded capacity: the hidden cost of fixed MIG profiles

Because MIG profiles are fixed and resizing forces a destroy-and-recreate cycle that interrupts running workloads, teams frequently over-provision instance sizes or leave slices configured for peak demand that rarely arrives. That unused, unreclaimable slice of compute is stranded capacity — capacity that is technically allocated but not delivering any useful work, and it is a direct consequence of MIG's rigidity rather than a configuration mistake.

The most practical mitigation identified in current practice is combining time-slicing within MIG instances: rather than dedicating a whole fixed-size MIG instance to a single light job, several lightweight workloads share that instance via time-slicing underneath the hardware partition. This balances MIG's strong isolation boundary at the instance level with time-slicing's higher density inside it, reducing the amount of compute left stranded on any given card.

Why does this matter more in 2026 than before? Because the constraint on new AI capacity in the UK has shifted from GPU supply to grid connection and power availability. An 8x H100 SXM5 node draws around 10.1 kW under inference load, and a Blackwell-based rack in liquid-cooled configuration can reach 120–140 kW of power density. When power, not silicon, is the binding constraint, every stranded slice of GPU capacity is also stranded electricity — a cost that compounds in a country where grid connection is already the primary bottleneck for new data centre projects.

The UK numbers: why utilisation matters more here than most markets

The scale of UK investment makes this a live issue rather than a theoretical one. NVIDIA and its partners have pledged £11 billion to the UK AI ecosystem, with plans to deploy 120,000 Blackwell GPUs by the end of 2026 — set to become Europe's largest GPU cluster. The wider UK data centre GPU market is valued at USD 2.02 billion in 2026 and is projected to grow at a CAGR of 12.73% through 2031, according to Mordor Intelligence.

Yet this growth is landing into a power-constrained grid, particularly around the dominant London and Slough corridor, where connection capacity — not GPU availability — is now the limiting factor for new deployments. That has pushed the UK government to promote 'AI growth zones' and encouraged 'neoclouds' that keep workloads on domestic infrastructure for data sovereignty reasons, even where local electricity costs run higher than alternatives.

Put these threads together and the ROI case for GPU partitioning in the UK is straightforward: every MIG instance, time-sliced job, or MPS process that runs on an already-deployed £32,050 H100 instead of triggering a new GPU purchase saves both capital and a share of an increasingly scarce power allocation. Teams sizing the next deployment should use our AI GPU calculator or determine GPU server requirements for LLM inference before assuming a fresh card is the only option — and it's worth comparing the current generation of hardware via our guide to NVIDIA H200, H100, B100, and B200 GPUs before committing budget.

Configuring MIG: from nvidia-smi to Kubernetes with the GPU Operator

In practice, deploying MIG starts at the card level: MIG mode is enabled on a supported GPU, the device is reset, and the administrator then defines how many GPU instances to carve out and at what profile size — the fixed sizes discussed above. Each resulting instance appears to the operating system and to CUDA applications as its own GPU, with its own memory and compute allocation.

In containerised environments, the NVIDIA GPU Operator exposes each MIG instance as a distinct schedulable resource to Kubernetes, so pods can request a specific instance size rather than a whole physical GPU. The most common pitfall here is a mismatch between the profile sizes configured on the card and the actual shape of workload demand: if every pod in a cluster wants a slightly different memory footprint, some MIG instances will inevitably run under-utilised or force a disruptive reconfiguration — the same stranded-capacity dynamic described earlier, now expressed as a scheduling problem.

Capacity planning therefore has to happen before MIG profiles are cut, not after. Understanding the expected mix of inference and training jobs — and how often that mix will change — should inform how a physical GPU is split in the first place, since undoing that decision means interrupting whatever is already running on it.

Security and isolation: why MIG is safe for multi-tenant estates

The isolation MIG provides is not a permissions layer bolted on top of a shared resource — each MIG instance has its own dedicated memory, cache and compute cores, meaning a fault, crash or misbehaving process in one instance has no path to another instance's data or compute cycles. This is the property that makes MIG suitable for genuinely multi-tenant estates, where different customers or business units share one physical card.

The equivalent guarantee in a virtualised Windows environment comes from Microsoft's Hyper-V GPU partitioning, which uses SR-IOV to give each virtual machine hardware-backed security and predictable performance when sharing a physical GPU — and, from Windows Server 2025 onward, supports live migration of those partitioned VMs without losing that isolation boundary.

For UK operators building neoclouds to keep AI workloads on domestic infrastructure for data sovereignty reasons, this hardware-level separation is what allows genuinely mixed-tenant hosting on shared iron: one customer's inference workload and another's training job can occupy the same physical card without either being able to see or affect the other's data.

What's next for GPU partitioning

The direction of travel is convergence rather than a single winning technology. Combining time-slicing within MIG instances — using MIG's hardware boundary for tenant-level isolation and time-slicing underneath it for density — is already being used to squeeze more usable work out of each card, and is likely to become the default pattern rather than a niche optimisation as GPU costs and power constraints both remain high through 2026.

That pressure is only going to increase as the UK's 120,000-GPU Blackwell cluster comes online by the end of 2026 against a grid that is already the binding constraint on new capacity. Utilisation tooling — MIG, time-slicing, MPS, and SR-IOV-based virtualisation — is shifting from a nice-to-have efficiency measure to the mechanism that determines how much useful AI work a given power allocation and capital budget can actually produce. Teams planning their next build should learn about NVIDIA DGX systems and review server configuration options with partitioning in mind from day one, rather than retrofitting it after the hardware has been racked.

Sources

Every figure in this article traces to the sources below.

• •Cast AI — enterprise GPU utilisation across production Kubernetes clusters
• •Cast AI — combining time-slicing within MIG instances for utilisation
• •Vertex AI Search / StorageSwiss.com / Spheron Blog / Alliance Doc — MIG architecture and isolation mechanics
• •Spheron Blog — MIG profile resizing limitations
• •Kubernetes GPU Isolation Methods / Sagar Parmar (Medium) / Cast AI — time-slicing characteristics
• •Spheron Blog / GPU Sharing on Kubernetes — NVIDIA MPS process-level isolation
• •Spheron Blog / Enki AI / Towards AI / Armason — 2026 shift to power/grid as AI deployment bottleneck
• •ITPro — £11bn NVIDIA UK investment and 120,000 Blackwell GPU cluster
• •Reddit / Microsoft Learn — Hyper-V GPU-P, SR-IOV and live migration since Windows Server 2025
• •ElectronicsHub by Alibaba.com — NVIDIA H100 PCIe/SXM5 pricing (USD) and UK landed price (£32,050)