HAMi
Project HAMiHeterogeneous GPU sharing and scheduling for Kubernetes, hosted by the CNCF. HAMi registers each accelerator in a cluster with its split count, memory limit and core limit, and its own scheduler decides which node and which devices a pod receives, recording the decision on the pod. It covers NVIDIA GPUs alongside Cambricon MLUs and other vendors' accelerators.
Ships as container images and a Helm chart with no package channel, so adoption bands on stars. Verified 2026-09-16 via the repository, its recursive tree, the HAMi scheduling protocol and the CNCF project page.
Openness
5 high confidence- license
- Apache-2.0(OSI)
- source
- public(Project-HAMi/HAMi is the product you run)
- core-gated
- ungated(a 591-entry recursive tree carries no path matching enterprise, ee, commercial or proprietary)
Apache-2.0 under CNCF hosting, with no vendor positioned to sell a fuller edition. The recursive tree carries no enterprise, ee or commercial path.
- https://github.com/Project-HAMi/HAMi recorded 2026-09-16
Repository page for Project-HAMi/HAMi: Apache-2.0 license, public and unarchived, described as 'Heterogeneous GPU Sharing on Kubernetes'. Establishes the license and that the source is public.
- https://api.github.com/repos/Project-HAMi/HAMi/git/trees/master?recursive=1 recorded 2026-09-16
Full untruncated recursive tree of the default branch, 591 entries. One root LICENSE. No path matches enterprise, ee, commercial or proprietary. A tree lists paths; it is cited for that and for nothing about the vendor's offerings.
- https://www.cncf.io/projects/hami/ recorded 2026-09-16
HAMi's project page on cncf.io, establishing CNCF hosting rather than vendor ownership, so no commercial party is positioned to withhold functionality from the published source.
Adoption
2 low confidence4,600 GitHub stars. HAMi ships as container images and a Helm chart and publishes no package-registry artifact, so no usage-volume channel exists and the band rests on stars, which measure attention rather than use. The stars route caps at level 3.
- https://github.com/Project-HAMi/HAMi recorded 2026-09-16
Repository page showing the star count for Project-HAMi/HAMi.
Capability
4 medium confidenceAdmitted on the accelerator limb: HAMi registers devices in its own annotation schema and its own scheduler consumes that to choose placement. Band 4 - it selects the node AND the specific devices, which is more than dispatching, and nothing cited shows it reserving a multi-machine set as one allocation, which is what band 5 asks. Repointed from nvidia-run-ai to openpai when Run:ai moved to band 5: a peer must be at the band being claimed, and openpai selects hardware on the same footing this record does.
- https://raw.githubusercontent.com/Project-HAMi/HAMi/master/docs/develop/protocol.md recorded 2026-09-16
HAMi's own protocol document: device-plugin registration patches each device's UUID, split count, memory limit and core limit into node annotations, and under Schedule Decision 'HAMi scheduler needs to patch schedule decisions into pod annotations' as hami.io/vgpu-devices-to-allocate and hami.io/vgpu-node: {schedule decision node}. Establishes that HAMi's own scheduler chooses the node.
- https://project-hami.io/docs/core-concepts/gpu-virtualization recorded 2026-09-16
HAMi's GPU virtualization documentation, describing the device-plugin mechanism it builds on.
Verified 2026-09-16