The HAMi community is proud to announce the official release of HAMi v2.10.0. This release advances HAMi on three fronts: more flexible scheduling policies, broader heterogeneous accelerator coverage, and a richer scheduler ecosystem.

v2.10.0 introduces dynamic Flexible MIG, a new mutex scheduling policy, a long-requested NUMA-aware sort fix, composable scheduler policies, gang-scheduling (PodGroup) support, and correct init-container resource accounting. On the device side it adds AMD MI300X and Biren support, heterogeneous Ascend management that lets template-based vNPU and HAMi-core nodes coexist in one cluster, and vNPU HAMi-core monitoring. It also debuts a KAI Scheduler + HAMi-core integration through the new KAI Resource Isolator companion project.

This article walks through the major updates in v2.10.0.

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.

Volcano is the batch scheduler of choice for many AI clusters, and HAMi-core is the runtime that makes shared accelerators behave. This post covers their intersection on Ascend hardware: running hami-vnpu-core soft-sliced vNPUs under the Volcano scheduler, so batch scheduling semantics (queues, gangs, binpack) and per-container isolation (memory and compute limits enforced at the Ascend API layer) work together.

We verified the full path on a single-node Kubernetes cluster running on an Ascend 310P3 aarch64 server: built the Volcano images from source, deployed the official ascend-device-plugin v1.4.0 image, and confirmed that a container requesting an 8192 MiB slice sees exactly that much memory, while a second Pod binpacks onto the same physical card with its own independent slice and the plugin's Prometheus endpoint reports both limits. The complete step-by-step procedure (including every command and captured output) is Lab 13: Soft-Slicing Ascend 310P3 vNPU with Volcano and HAMi-core.

Because this topic mixes several concepts that are often conflated, the post first separates the layers: what a vNPU is, how hard and soft slicing differ, and what exactly the Volcano integration adds beyond the existing HAMi scheduler path.

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.

The Linux Foundation LFX Mentorship Program 2026 Term 3 is live, and HAMi is mentoring four open-source projects from September to November 2026.

Mentee applications open August 3, 2026 and close August 18, 2026. Whether your interest is low-level C/C++ performance, GPU observability, container isolation security, or developer education, there is a project for you.

KubeCon + CloudNativeCon Japan 2026 was held July 28-30 at Pacifico Yokohama. HAMi took part with a main-stage session and a booth in the Project Pavilion. Reza Jelveh presented the session and staffed the booth.

For the full overview, talk slides, and the SNOW case study, see the KubeCon Japan 2026 page.

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.

We are excited to announce that on July 2, 2026, HAMi was accepted as a CNCF Incubating project, with the CNCF Technical Oversight Committee passing the incubation vote unanimously in favor.

This is an important milestone following HAMi joining the CNCF as a Sandbox project in August 2024. It means the CNCF Technical Oversight Committee (TOC) recognizes HAMi's mature technical and security practices, active community, real production adoption, and open ecosystem integration.

Held on June 18-19, 2026, in Mumbai, India, KubeCon + CloudNativeCon India 2026 brought together cloud native practitioners, platform engineers, AI infrastructure teams, and open source contributors from across the ecosystem. As AI emerged as one of the conference's defining themes, HAMi showcased how Kubernetes-native GPU sharing helps organizations maximize accelerator utilization while maintaining workload isolation and operational flexibility.

From the opening keynote to live booth demonstrations and technical discussions with engineering teams, the event highlighted a growing industry focus: making expensive GPU infrastructure practical for multi-tenant AI workloads.

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.