DevOps Engineer, CNCF TAG Infrastructure Tech Lead, HAMi Contributor
note
This article was originally published on the CNCF blog on August 7, 2026.
Projects that want to share a GPU on Kubernetes have to work around an API instead of with it. The device plugin interface could count devices, and that was the whole vocabulary: nvidia.com/gpu: 1. It meant one whole card, take it or leave it. HAMi, which the CNCF Technical Oversight Committee (TOC) accepted as an incubating project on July 15, 2026, built its entire pipeline (mutating webhook, scheduler extender, annotations, in-container enforcement) to express what that vocabulary couldn't: "give this pod 8,000 MiB and 10% of a GPU, and make the limit stick."
Then, the vocabulary changed. Dynamic Resource Allocation (DRA) reached general availability in Kubernetes v1.34 and is enabled by default since v1.35. With the consumable capacity feature, a pod can now ask the scheduler itself for a slice of a device's memory, natively, with no annotations involved.
So the question I keep seeing in the HAMi communication channels is: does DRA make HAMi obsolete? The short answer is no, but the complete answer depends on which of HAMi's jobs you're talking about. One of them, encoding fractional requests where the scheduler can see them, is exactly what DRA absorbs. The other, enforcing those fractions inside the container at CUDA-call granularity, is a job DRA was never designed to do. HAMi's response has been to split accordingly: keep the enforcement, and rebuild the encoding on top of DRA across 3 repositories. Let's walk through both halves, then look at what running the DRA stack takes today.
The companion post HAMi-core adopted by NVIDIA KAI Scheduler already introduces KAI Scheduler and the collaboration behind this integration. This post skips that background and focuses on one question: when KAI Scheduler places two Pods on one GPU, does HAMi-core actually enforce each Pod's memory quota?
We verified the currently documented combination—KAI Scheduler v0.17.0 and kai-resource-isolator 1.1.0-chart—on GKE 1.35/COS/CDI. Both Pods shared the same NVIDIA T4, each saw a 4147 MiB ceiling, a 3 GiB CUDA allocation succeeded, and a cumulative 5 GiB allocation failed. The optional monitor also exported live limit and usage metrics for both Pods.
About the captured output
The UUID, memory ceiling, CUDA allocation results, and monitor metrics below came from the verified GKE run. Resource suffixes and addresses will differ in another cluster.
The integration target here is strictly HAMi-core, not the full HAMi platform. KAI Scheduler keeps its own scheduling capability and brings in HAMi-core to provide GPU memory isolation.
In June 2026, two core PRs were officially merged into the NVIDIA KAI Scheduler main branch. HAMi's GPU memory hard isolation shipped as a built-in feature starting with KAI Scheduler v0.16.4. Cloud-native GPU scheduling has officially moved from "cooperative sharing" into the "hard isolation" era.
HAMi (Heterogeneous AI Computing Virtualization Middleware), formerly known as k8s-vGPU-scheduler, manages heterogeneous AI computing devices within Kubernetes clusters. It enables sharing of various AI devices while enforcing resource isolation between tasks, and provides a unified interface for different device types.
