HAMi reaches CNCF incubation
The Cloud Native Computing Foundation confirmed on July 15 that HAMi, a GPU virtualization middleware for Kubernetes, has advanced to incubating status. The project entered the CNCF Sandbox on August 21, 2024, and the Technical Oversight Committee approved the move to Incubation on July 2, 2026. For platform teams standardizing on Kubernetes as the substrate for AI workloads, this promotion matters because it places accelerator sharing inside the same governance model that already covers networking, storage, and policy. HAMi ships as version 2.9.0 across sixteen releases, and it now sits alongside other incubating projects that enterprises treat as production candidates.
We read incubation as a maturity signal that shortens internal procurement debates. CNCF TOC sponsor Karena Angell framed the value directly: "HAMi solves a real problem: scheduling and sharing accelerator resources on Kubernetes in a way that works across vendors." That cross-vendor promise is the part worth underlining. Teams running mixed fleets of NVIDIA GPUs, domestic NPUs, and other accelerators have carried bespoke scheduling glue for years. A CNCF incubating project with a defined governance process gives those teams a maintained upstream to consolidate on, and it reduces the number of one-off device plugins a platform group has to own.
The fragmentation problem HAMi targets
The pain HAMi addresses is familiar to anyone running accelerators on Kubernetes. Whole GPUs get allocated to small jobs, teams compete for scarce devices, and vendors expose different operational models that schedulers cannot reason about. The result is low utilization on some of the most expensive hardware in the data center. HAMi lets platform teams slice a physical GPU, NPU, DCU, or MLU into units defined by memory, core count, or device count, so a single card can back several workloads at once. That reclaims capacity that would otherwise sit idle behind coarse-grained allocation.
The design keeps application code untouched. Workloads request fractional resources through standard Kubernetes primitives, and HAMi handles partitioning and placement underneath. For engineering leaders, the practical payoff is measured in effective GPU-hours per dollar. When a training or inference fleet runs many jobs that each need a slice of a card, packing them onto shared devices lifts utilization without asking developers to rewrite manifests. That separation of concerns is what makes the middleware adoptable across teams with different skill levels and different accelerator vendors.
How isolation and scheduling work
HAMi enforces hard runtime isolation between workloads that share a device, which is the property that makes multi-tenant GPU sharing safe enough for production. Memory and compute limits are applied at runtime, so one pod cannot starve or crash its neighbors on the same card. This distinguishes the approach from time-slicing schemes that offer no memory boundary. For regulated environments, that isolation is often the gating requirement before any sharing is permitted at all.
Scheduling is the second half of the story. HAMi supports binpack, spread, and topology-aware placement policies, so operators can pack workloads tightly to maximize utilization or spread them for resilience. Topology awareness matters on multi-GPU nodes where interconnect bandwidth between cards shapes training throughput. Maintainer Xiao Zhang described the breadth the project has reached: "Seeing HAMi reach Incubation is a proud moment for all of us. HAMi now supports dozens of Heterogeneous GPU and has grown into a global community." That heterogeneity is the differentiator for shops that refuse to standardize on a single silicon vendor.
Adoption at data center scale
The adoption figures behind the promotion are substantial. HAMi counts 2,687 contributors across GitHub, a 43 percent year-over-year increase, drawn from more than 550 organizations. The repository carries roughly 3,500 stars, and CNCF has published five independent case studies documenting production use in education, cloud platforms, and enterprise technology. Numbers of that shape are what the TOC weighs when judging whether a project has crossed from early adopters into broader production reliance.
Two deployments anchor the credibility. DaoCloud runs HAMi across more than 10,000 GPUs in over 10 data centers spanning mainland China and Hong Kong, and China Merchants Bank uses the project to manage diverse accelerator resources at scale. Maintainer Mengxuan Li tied the milestone back to the project's origins: "When I attended KubeCon Paris back in 2024, HAMi had just been open-sourced. Two years have flown by, and HAMi has grown into a recognized CNCF incubating project." A bank and a large platform vendor running it in production give the reference points a risk-averse buyer looks for.
What this means for accelerator strategy
For platform leaders, HAMi's promotion reframes a build-versus-buy decision that many teams have been quietly losing. Custom device plugins and homegrown fractional-GPU logic carry real maintenance cost, and they rarely keep pace with new accelerator generations. A CNCF incubating project with an active multi-vendor community absorbs that treadmill on the team's behalf. Standardizing on HAMi lets a platform group offer fractional GPUs as a self-service capability inside an internal developer platform, with utilization and isolation guarantees baked in.
We would treat this as a prompt to evaluate HAMi against whatever accelerator sharing exists in-house today. The questions worth answering are concrete: what utilization does the current setup achieve, what isolation does it guarantee, and how many vendor-specific code paths does the team maintain. If the answers point to low utilization and high maintenance, an incubating CNCF project with production references at bank and hyperscale platform scale is a credible consolidation target. The GPU budget line makes the payback easy to model.
Where HAMi fits the wider cloud native AI stack
HAMi lands in a Kubernetes ecosystem that is actively growing native accelerator support. Dynamic Resource Allocation reached general availability in Kubernetes 1.34, giving the scheduler a richer vocabulary for describing devices. HAMi complements that direction by supplying the fractional slicing, hard isolation, and multi-vendor coverage that the core APIs leave to the ecosystem. For a platform team, the two work together: the upstream scheduler gains device context, and HAMi supplies the runtime enforcement and packing policies that turn that context into higher utilization.
The heterogeneity story is where HAMi separates itself from single-vendor tooling. Organizations that run NVIDIA GPUs in one region and domestic NPUs, DCUs, or MLUs in another have struggled to present a uniform interface to developers. HAMi abstracts those devices behind consistent Kubernetes requests, so an internal platform can offer the same fractional-accelerator experience regardless of the silicon underneath. As enterprises diversify their hardware suppliers to manage cost and supply risk, a scheduler that treats mixed fleets as first-class becomes a strategic asset rather than a convenience.
