The HAMi community is proud to announce the official release of HAMi v2.11.0.
Highlights of this release:
- Remote GPU: run CUDA and vLLM Pods on GPU-less, driver-less client nodes, using GPUs served over the network by Lupine GPU servers.
- AMD Instinct GPU sharing: AMD GPUs (ROCm) are now first-class in HAMi, with memory limits by size or percentage, compute limits, NUMA- and XGMI-aware placement, scheduling policies and queue priorities, all enforced at the container level.
- Ascend ENPU mode: policy-based isolation (
fixed-share, elastic, best-effort) as a third partitioning mode alongside templates and hami-core, plus a major hami-vnpu-core performance overhaul.
- NUMA refit: kubelet's Topology Manager and HAMi's scheduler now agree, so CPU affinity and GPU placement land on the same NUMA node.
- Flexible MIG grows up: CDI injection for dynamic MIG devices, placement scoring with backtracking, and per-Pod profile preferences.
- A harder scheduler: security-audit-driven hardening of the scheduler extender and webhook, plus Filter-path performance gains.
- Platform and chart: OpenShift and SELinux support, a restructured
devices.VENDOR chart, and node capacity resource reporting.
- Website overhaul: reorganized information architecture, a redrawn Concepts section,
llms.txt, and restructured installation and upgrade guides.
In total, v2.11.0 merges more than 220 pull requests from over 50 contributors, including 29 first-time contributors.
This article walks through the major updates in v2.11.0.
HAMi has always offered per-Pod GPU scheduling policies through the hami.io/gpu-scheduler-policy annotation: binpack to pack workloads onto as few cards as possible, spread to distribute them, mutex (new in v2.10.0) to demand an exclusive card. Until now, the annotation accepted exactly one value.
Real clusters rarely want just one behavior at a time. A typical production wish list looks like this: pack inference replicas tightly to leave whole cards free, but keep each Pod's GPUs on the same NUMA node for bandwidth, and give the latency-critical tier cards of its own. That is three policies in a single sentence. Before v2.10.0 you had to pick one and give up the rest.
v2.10.0 closes this gap: hami.io/gpu-scheduler-policy now accepts an ordered, comma-separated list of policies, so filter-style and sort-style policies compose (#2621, @mesutoezdil, closes #2010). This post explains how the combination actually works, and how to adopt and verify it. If you prefer to learn by doing, the companion Lab 14: Composable GPU Scheduling Policies on GKE walks through every scenario below on a real cluster.
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.
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.
KCD Beijing 2026 was one of the largest Kubernetes community events in recent years.
Over 1,000 people registered, setting a new record for KCD Beijing.
The HAMi community not only gave a technical talk but also set up a booth, engaging deeply with developers and enterprise users from the cloud-native and AI infrastructure fields.
The topic of this talk was:
From Device Plugin to DRA: GPU Scheduling Paradigm Upgrade and HAMi-DRA Practice
This article combines the on-site presentation and slides for a more complete technical review. Slides download: GitHub - HAMi-DRA KCD Beijing 2026.
During the use of HAMi, it is common for Pods to be created and remain in a Pending state, particularly due to the following two issues:
- Pod UnexpectedAdmissionError
- Pod Pending
This section provides a rough walkthrough of the related code to explain the interactions between components during scheduling and how resources are calculated. Other details may be omitted.
