In 2018 I was a Product Line Marketing Manager at VMware. Along with other things, I worked with Dell on the go-to-market for vSphere Scale-Out, the edition we built for HPC and machine learning. That same year, VMware published test results showing one NVIDIA GPU shared across 24 VMs. We brought GPU virtualization and the virtualization playbook to AI before most enterprises had a GPU cluster to manage.
GPU virtualization is the practice of splitting and pooling GPUs so many AI jobs can share the same hardware. It is repeating what server virtualization did in the 2000s. Back then, most enterprises ran one application per physical server. At that time, Industry analysts put average x86 utilization somewhere between 5 and 15 percent. That meant companies were paying for power, cooling, floor space, and refresh cycles on hardware that did almost nothing most of the day.
Twenty years later, the same pattern is showing up with GPUs, and each idle box now costs far more. In ClearML’s (now Klique) State of AI Infrastructure at Scale 2025-2026 report, 44% of enterprises said they either assign workloads to GPUs by hand, or have no utilization strategy at all. 70% named cost control as their top infrastructure priority.
VMware solved the server version of this problem in three steps:
- Carved up the hardware
- Pooled it
- Gave IT a way to govern it.
- AI compute is going through the same following the same pattern. Klique (formerly ClearML) does all three: it slices and pools GPUs, then lets IT set who gets compute, which models they can call, and how much they can spend.
How did VMware fix server utilization?
VMware fixed server utilization by building three layers on top of the hardware.
- Slice the hardware. The hypervisor let one physical server run many virtual machines. This meant ten lightly used apps could share one box instead of ten.
- Pool and schedule. Resource pools, DRS and vMotion made a cluster of servers behave like one large computer. Admins set shares, reservations and limits, and the scheduler moved VMs around to keep the cluster balanced.
- Govern and manage. vCenter Server gave IT one console to set permissions and resource limits for every team. VMware then added self-service provisioning (vCloud Director, later vRealize Automation) and chargeback (vCenter Chargeback Manager, later vRealize Business). This meant teams could request capacity and finance could see what each group used.
Once VMware’s management stack could provide the policies, the quotas, and the chargeback reports, it became the system IT ran the business on.
Why is GPU utilization harder to fix than server utilization?
GPU utilization is harder to fix than it was for servers. This is because GPUs cost more, AI workloads are short-lived, and the infrastructure for them is split across many platforms. Teams still hoard GPUs and leave them idle between runs, as server teams did before VMware.
- Scarcer, pricier hardware.An idle 8-GPU node wastes far more per hour than an idle 2008 web server, and you can’t buy more on short notice.
- Bursty jobs. Training runs, notebooks, sweeps, and inference spikes start and stop in minutes, while VMs ran for months.
- Mixed infrastructure.Kubernetes, Slurm, PBS, bare metal, VMs and cloud often run side by side.
- New consumers.Agents and apps call models through APIs, so spend shows up as tokens as well as GPU hours.
How does Klique improve GPU utilization?
Klique virtualizes GPUs by giving each workload its own slice of a physical GPU, so one device can run many jobs at once. Which approach fits depends on your hardware and on whether you want a fixed layout or on-demand slicing.
Klique supports four approaches to fractional GPUs across NVIDIA and AMD hardware:
| Approach | How it works |
| Static MIG | Each queue maps to a fixed MIG slice on NVIDIA GPUs, and jobs from that queue run on it. Workloads are never evicted. |
| Dynamic MIG | MIG profiles are created and reclaimed as jobs are scheduled. To change the layout, Klique evicts running work, repartitions and reschedules. |
| Container memory limits | Any GPU, MIG or not, is shared by capping each container’s GPU memory per task and time-slicing compute. No pre-partitioning needed |
| AMD partitioning | AMD Instinct GPUs (MI300X, MI355X) are split into 1, 2, 4 or 8 hardware partitions, and Klique assigns them to workloads |
How is GPU virtualization different from server virtualization?
Server virtualization was built around long-lived machines. However, GPU virtualization is built around short-lived jobs. With GPUs, capacity gets claimed and released many times a day as jobs start and finish. That means buying for peak and holding it indefinitely leaves expensive hardware sitting idle.
| Server virtualization | GPU virtualization with Klique | |
| Unit of allocation | A VM that runs for months | A job that might run for twenty minutes |
| How hardware is split | Virtual machines on a hypervisor | Fractional GPUs: static or dynamic MIG, container memory caps with time slicing, or AMD partitions. |
| When capacity is sized | Up front, when the VM is built | Per job, from slices that are fixed in advance or created on demand. |
| What happens when work ends | The VM keeps its CPU and memory | The GPU slice returns to the pool for the next job |
| How work is placed | Resource pools and DRS | Compute pools, queues, and priority scheduling |
| Who gets what | Shares, reservations, and limits | Quotas and over-quotas per user and project |
| What runs underneath | A hypervisor on every host | Bare metal, Kubernetes, Slurm, PBS or VMs |
Klique: the vCenter layer for AI
Klique is an enterprise AI control plane that routes model requests, orchestrates GPU compute, and enforces budgets, quotas and access policies across users, agents, models, and tools. It plays the role vCenter played for servers, only it covers GPUs and AI spend on external models.
- Model routing. Each request goes to the model that’s best for the job. The model is chosen on cost, latency, policy, and data sensitivity, no matter if that model runs in-house or behind a third-party API.
- One set of controls for people and agents. Budgets, quotas, virtual keys, SSO, audit trails and access policies apply across users, agents, models, projects, and tools.
- Compute and tokens on the same books. GPU hours on an on-premises cluster and tokens spent on a hosted model show up against the same team budget.
Think of an IT platform lead who has to answer two questions every week: which team gets the next free H100, and why the agent pilot ran up a five-figure API bill. In the VMware era, vCenter answered the first question for servers. Klique answers both, using policies IT sets once.
What does the VMware era teach us about AI compute?
vCenter kept VMware in the data center because it was where IT managed the whole environment. AI infrastructure is on the same path, only faster. VMware must see that too, because at Explore 2026, Broadcom announced VMware AI Factory to bring shared GPU pools and model governance to VCF.
GPU slicing is already table stakes. The open question is who sets the rules for GPUs, clouds, models, and agents together, and can those rules cover you anywhere your AI runs.
So, ask yourself: who in your company decides which team gets the next GPU, or which model answers the next prompt. If the answer is a spreadsheet and a Slack channel, you are in the same place server teams were in 2005.
I came up on the infrastructure side of this story: Linux admin, then EMC, Dell, and VMware, then seven years running go-to-market for AI infrastructure companies. If you ran vSphere clusters back in the beginning, GPU virtualization will feel familiar, and I’d like to hear how your team is managing it.
FAQ
What is GPU virtualization?
GPU virtualization splits one physical GPU into smaller slices, or pools many GPUs, so several AI jobs or users can share the hardware. Common methods are NVIDIA vGPU, MIG partitioning, and memory caps with time slicing.
What is a MIG-capable GPU?
A MIG-capable GPU is an NVIDIA data center GPU that supports Multi-Instance GPU, such as the A100, H100, H200, B200 or RTX PRO 6000 Blackwell. MIG splits the GPU into as many as seven isolated instances.
How is MIG different from vGPU time slicing?
MIG gives each slice its own compute cores, cache, and memory bandwidth, so jobs don’t slow each other down. Time-sliced vGPU only partitions memory, and jobs take turns on the compute.
Does Klique need VMware to share GPUs?
No. Klique runs fractional GPUs on bare metal, Kubernetes, Slurm or inside VMs, so it works with or without vSphere.
What does Klique add beyond GPU sharing?
Klique adds model routing and governance, including budgets, quotas, virtual keys, SSO and audit trails, so GPU hours and model API tokens fall under the same policies.
