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.
On July 16, 2026, Li Mengxuan, Co-founder & CTO of Dynamia and HAMi author, delivered a technical talk on vLLM deployment and compute optimization at vLLM Meetup. Built around one pointed question, "Are you making good use of your compute?", the talk laid out a complete evolution path for vLLM inference clusters, from "getting it to run" to "squeezing the hardware dry", broken down into three clear stages.
This recap walks through the talk slide by slide, combining the deck with the on-site Q&A notes.
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.
One physical NVIDIA L40S virtualized into 10 vGPUs with HAMi. An AI Agent deployed as a Kubernetes CRD via kagent. Agent-to-Agent delegation, GPU pod creation, overcommit protection - all driven by Llama 3.3 70B with no closed-source dependencies.
