DRA vs HAMi: Choosing a GPU Sharing Strategy for Kubernetes in 2026

If you run AI workloads on Kubernetes, you've hit the same wall we have: a single A100 or H100 is too expensive to dedicate to one pod, but vanilla Kubernetes has no real way to share a GPU across workloads. Two answers have emerged - HAMi, the de facto patch, and Dynamic Resource Allocation (DRA), the upstream answer. They are not interchangeable, and the right choice in 2026 depends on what you're willing to bet on.

This post walks through what each one actually does, where the sharp edges are, and how we help clients pick between them. Most of what we recommend falls out of the GPU Kubernetes work we do day to day and the broader AI infrastructure patterns we ship.

Why GPU sharing is hard on Kubernetes

Kubernetes was designed around countable resources: CPU in millicores, memory in bytes, ephemeral storage. GPUs don't fit that model cleanly. A single physical GPU is one resource, but most AI workloads don't use 100% of it. A 70B-parameter LLM inference pod might consume 35 GB of an 80 GB A100; the rest is wasted unless you can pack something else on the same device.

There are three ways engineers try to solve this:

1. MIG (Multi-Instance GPU) - hardware partitioning on NVIDIA A100/H100. Real isolation, real performance guarantees, but only on supported SKUs and with limited slice sizes.
2. Time-slicing - the kernel driver lets multiple processes use the same GPU context-switched. Cheap, no isolation, workloads interfere.
3. Application-level sharing - vLLM, Triton, TGI all have their own batching and request-routing logic, but they assume the GPU is already in their namespace.

DRA and HAMi both target the missing middle ground: software-defined GPU partitioning with scheduler awareness, without requiring MIG.

What HAMi actually does

HAMi (Heterogeneous AI Computing Virtualization Middleware, formerly k8s-vGPU-scheduler) is a CNCF Incubating project. You label a node with the GPU resources you want to expose - nvidia.com/gpu, nvidia.com/gpumem, nvidia.com/gpucores - and HAMi lets pods request slices like nvidia.com/gpumem: 10000.

Under the hood, HAMi is a stack: a mutating webhook that injects device requirements into pod specs, a scheduler extender that filters and scores nodes on device constraints, a device plugin that registers the resources with kubelet, and an in-container virtualization layer (libnvgpu for NVIDIA) that enforces memory and compute limits inside the container. For batch AI workloads, HAMi pairs cleanly with Kueue for gang scheduling and queue-based allocation - a value-add if you're already on Kueue. We use the same HAMi + Kueue gang scheduling patterns that we ship to clients running GPU batch workloads.

It supports MIG transparently if MIG is enabled on the hardware, and it has a working time-slicing mode for cases where you don't need strict isolation.

The things HAMi gets right today:

• It's deployed in production at scale. We see it in financial services, autonomous driving shops, and large research clusters. Real users, real war stories.
• The scheduler integration is mature. Pods requesting nvidia.com/gpumem: X get scheduled onto nodes with available slice capacity, and the device plugin sets the right CUDA_MPS_ACTIVE_THREAD_PROCENTAGE or memory limits on the container.
• MIG is first-class. If you're on H100s with MIG enabled, HAMi knows about it and exposes MIG instances as schedulable resources.
• Observability hooks exist. You can see what's allocated where, though you'll still need Prometheus and the NVIDIA exporters to make sense of utilization.

The things that are sharp:

• It's a stack, not a single binary. Mutating webhook + scheduler extender + device plugin + in-container library. Each piece has its own upgrade cadence, its own failure modes, and (importantly) its own HA story. Plan accordingly.
• vGPU support requires NVIDIA AI Enterprise licensing. HAMi can partition vGPUs, but only on licensed hardware. Bare metal and MIG work without it.
• The community is Chinese-led. Most of the contributors, the docs, and the Slack conversations are in Chinese. This is not a problem for adoption - the code is solid - but it is a problem if your team needs English-language support tickets or fast turnaround on issues. Plan accordingly.

If you're operating HAMi in production, watch for these failure modes:

• CUDA MPS instability under memory pressure. When pods over-promise memory but the workload actually uses more, MPS gets unstable and the device plugin can deadlock. Set conservative limits and oversubscribe slowly.
• The scheduler extender is a single point of failure. hami-scheduler is stateless, so HA is trivial, but most teams don't deploy it HA by default. Deploy HA from day one.
• The `nvidia.com/gpu` semantic flips after install. When you install HAMi, the value of nvidia.com/gpu on each node changes from "number of GPUs" to "number of vGPUs." Pods that were written for the upstream device plugin need to be re-read. This is the #1 reason new HAMi adopters see "this pod used to schedule, now it doesn't."

What Dynamic Resource Allocation actually does

DRA is the upstream Kubernetes answer to the same problem. It graduated to beta in 1.32 and reached general availability in 1.34; the resource.k8s.io/v1 API is on by default in 1.34+ clusters. It generalizes the resource allocation model so device drivers can describe their own resources, and the scheduler can match pods to devices that satisfy structured claims.

The mental model is different from device plugins. With DRA:

1. A driver (the DRA equivalent of a device plugin) publishes a set of ResourceSlices - opaque, structured resources with attributes like memory, productName, architecture.
2. Pods declare ResourceClaims referencing those resources, optionally with selectors ("a GPU with at least 40 GB of memory").
3. The scheduler matches claims to slices using CEL-based selection logic.
4. The kubelet hands the driver a StructuredResourceClaim at runtime; the driver prepares the device and exposes it inside the container.

The Kubernetes-sig-wg-resource-management working group maintains the spec, and the NVIDIA DRA driver ships as two pieces with different maturity. The ComputeDomain (Multi-Node NVLink) kubelet plugin is officially supported for GB200-class workloads. The GPU kubelet plugin - what most people want for H100/A100 allocation - is alpha, disabled by default in the Helm chart, and the MIG dynamic allocation features are still on the roadmap. As of August 2026, we don't have a THNKBIG client running either path in production yet.

What DRA gets right:

• It's the upstream answer. No fork, no separate control plane. The scheduler, kubelet, and API server know about it natively. Whatever you learned about Kubernetes resource management applies here.
• Structured selection. "Give me a GPU with ≥ 40 GB memory and compute capability ≥ 9.0" is a real selector. Device plugins can't express that.
• Per-pod configuration. Each ResourceClaim can include opaque config blobs that drivers interpret. This is how the GPU driver passes CUDA_MPS settings, MIG profile selection, or memory limits.
• Multiple resource types per claim. A single pod can claim GPUs, FPGAs, and NICs in one ResourceClaim, with shared allocation policy.

What's still in flight:

• Driver maturity for the GPU path. The NVIDIA GPU kubelet plugin is alpha and MIG dynamic allocation is on the roadmap. Production-adjacent reference deployments for the GPU path are thin.
• Ecosystem lag. Monitoring (DCGM, Prometheus exporters), admission controllers, and CI tooling all assume the device-plugin model. Most of that needs to catch up.
• The migration story from device plugins is not done. You can run both side by side, but a clean cutover path with shared node pools is still a moving target.

The honest comparison

| Dimension | HAMi | DRA | |---|---|---| | Production maturity | High - multiple years, large fleets | Mixed - ComputeDomain GA for GB200; GPU plugin alpha | | Upstream alignment | Fork of device-plugin model | Native to Kubernetes (core API GA in 1.34) | | MIG support | First-class | Roadmap - alpha today | | Time-slicing support | First-class | Driver-dependent | | Structured selection | Limited (label-based) | First-class (CEL selectors) | | Observability | Mature, well-understood | Catching up | | Community language barrier | Real (Chinese-led) | None | | Upgrade path with K8s | Independent of K8s version | Tied to K8s release cadence |

How we help clients choose

The decision is rarely "DRA or HAMi" in the abstract. It's "what's the cheapest path to validated GPU sharing for the workloads we have today, with a clean migration to the upstream answer when it's ready."

Default today (mid-2026): HAMi for production, with MIG enabled on H100/A100 where the workload shape fits. It works, it's deployed, the operational patterns are well-understood, and the failure modes are documented.

Watch and prototype: DRA, with a non-production cluster running the NVIDIA DRA driver against a representative workload set. If you're on GB200 NVLink fabric, the ComputeDomain path is GA-quality and worth piloting. For H100/A100 per-GPU allocation, the GPU kubelet plugin path is still alpha and should remain in prototype until first GA-quality. We use both tracks to validate the migration story before recommending it to a CTO.

Mixed deployments are normal. Lots of our clients run HAMi for inference (where sharing is critical and the workloads are well-characterized) and bare device plugins for training jobs (where MIG or full-GPU is the right answer anyway). For batch AI workloads, HAMi + Kueue is a credible stack.

The trigger to switch from "HAMi production + DRA prototype" to "DRA production" is:

1. The NVIDIA DRA driver hits GA-quality (not alpha).
2. Your monitoring and observability stack has DRA-aware metrics.
3. You've run a parallel workload on DRA for at least one quarter without regressions.

We don't expect all three to land before mid-2027. Until then, HAMi is the right answer for most teams.

A note on alternatives

Time-slicing alone - without HAMi or DRA - is fine for dev/test clusters and for workloads that don't care about isolation (think batch offline scoring where jobs queue serially anyway). It's not fine for mixed-tenant production where one runaway pod can OOM the GPU out from under everyone else.

MIG is the right answer when your workload fits the supported slice sizes. MIG profiles are fixed by NVIDIA; slice sizes are set per-SKU and you can't carve arbitrary amounts. If your models are uniformly sized and MIG slices match, MIG is cheaper than any software solution because the hardware does the isolation for you.

Application-level sharing (vLLM's continuous batching, Triton's model repository, TGI's request routing) is the layer above all of this. It assumes the GPU is yours once it's in your namespace. It doesn't solve the cluster-level sharing problem - that's what HAMi and DRA are for.

What this means for platform teams

If you're a platform team being asked to support AI workloads:

• You don't get to defer this. Your data science team will start running Jupyter on shared Kubernetes nodes whether you're ready or not. If you don't give them a GPU-sharing story, they'll find one - usually by running on bare metal outside your control.
• The right answer isn't "Kubernetes can't do that." It can, with help. Pick HAMi today and a DRA migration path for tomorrow.
• Budget for the migration. Whatever you build on HAMi will need to be rebuilt on DRA within 18-24 months. Don't over-engineer; budget for the rebuild.

If you're a CTO or VP of Engineering evaluating Kubernetes for AI:

• Ask vendors what they support, not what they recommend. A lot of "Kubernetes AI platforms" still mean "Kubernetes with vendor-managed device plugins." Make sure the answer is "HAMi or DRA, here's the upgrade path."
• Ask for production references. Not case studies, actual teams running your intended workload shape. We have a short list of references we're happy to share.
• Budget GPU cost separately from Kubernetes cost. A shared GPU cluster looks 20-50% cheaper in TCO than dedicated pods per workload, depending on workload mix, but only if your utilization model is right. Range reflects published benchmarks from CoreWeave, Run:ai, and NVIDIA; clusters with high training skew toward the lower end. Most teams over-provision because the telemetry isn't there yet.

Where to start

If you're starting fresh on Kubernetes with GPU workloads:

1. Stand up a small cluster with HAMi + MIG on H100s.
2. Run one representative inference workload and one training workload against it.
3. Measure utilization with DCGM and Prometheus.
4. Decide whether HAMi's isolation model fits your workload mix.
5. Set a calendar reminder for six months out to re-evaluate DRA driver maturity.

If you're already running NVIDIA device plugins without HAMi, your near-term move is to pilot HAMi on a single node pool and migrate one workload to it. Don't forklift everything.

If you're already running HAMi in production, your near-term move is to set up the DRA prototype cluster in parallel. You don't need to migrate yet. You need to know what the migration looks like before someone asks you for a date. If you're starting from a bare cluster and aren't sure which path fits, the workloads and tooling patterns we ship for Kubernetes GPU workloads cover the baseline DCGM, Prometheus, and node-pool decisions that both paths assume.

Sources and further reading

• CNCF blog, Does Kubernetes DRA Replace HAMi? (Mesut Oezdil, August 7, 2026)
• CNCF blog, HAMi becomes a CNCF Incubating project (HAMi Maintainers, July 15, 2026)
• Kubernetes 1.34 release blog, "Stable: The core of DRA is GA" (August 2025)
• Kubernetes documentation, "Dynamic Resource Allocation" (KEP-1287)
• NVIDIA DRA driver repository (kubernetes-sigs/dra-driver-nvidia-gpu) and HAMi CNCF Incubating project documentation
• Our production experience shipping HAMi with MIG on H100 clusters (gated, available to clients under NDA - the HAMi + Kueue scheduling patterns we've validated are the patterns referenced here)

If you're evaluating GPU sharing strategies for a Kubernetes platform and want a second opinion from engineers who've done it, book an Assessment Workshop. We'll walk through your workload mix, hardware inventory, and isolation requirements, and tell you which path fits - including when the right answer is "don't share GPUs, buy more." If you want platform engineering help to drive the rollout, our Kubernetes consulting work covers the migration story end to end.