HAMi

license

Apache-2.0(OSI)

source

public(Project-HAMi/HAMi is the product you run)

core features withheld

no — a 591-entry recursive tree carries no path matching enterprise, ee, commercial or proprietary

HAMi is Apache-2.0, and its recursive tree holds one root license and no enterprise, ee or commercial path, so nothing in the core is held back for a fuller edition.

• 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://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://raw.githubusercontent.com/Project-HAMi/community/main/governance.md recorded 2026-10-07

  HAMi's project governance: 'Community over Product or Company: Sustaining and growing our community takes priority over shipping code or sponsors' organizational goals', and 'Currently, the maintainers are the governing body for the project'.

HAMi ships as container images and a Helm chart rather than through a package registry, so GitHub stars are the only adoption signal available. A star is not a use, so the signal shows attention rather than real usage.

• https://github.com/Project-HAMi/HAMi recorded 2026-09-16

  Repository page showing 4,600 GitHub stars for Project-HAMi/HAMi.

HAMi registers each accelerator in its own annotation schema, and its own scheduler consumes that to choose both the node and the specific devices a pod receives, which is more than simple dispatching. Nothing cited shows it reserving a multi-machine set as a single allocation, which keeps it level with OpenPAI.

• 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.

• 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.