Hysen LabsHAMi
Heterogeneous GPU Sharing on Kubernetes
HAMi: sharing GPUs across Kubernetes workloads
HAMi splits physical accelerators by memory, core, or device count so Kubernetes teams can share expensive GPUs without rewriting their applications.
Why teams end up here
The README opens with the problems AI infrastructure teams keep hitting. Whole GPUs get allocated to small jobs. Teams compete for scarce devices. Schedulers do not have enough device context to make good decisions. HAMi, which stands for heterogeneous AI computing virtualization middleware and was formerly known as a vGPU scheduler, addresses those with device sharing and isolation. The problems are described as recurring, which suggests the README is written for people who have already felt them.
How sharing works
Sharing happens by slicing a physical accelerator. Allocations can be by memory, by core, or by device count. Per workload limits enforce memory and compute bounds so one tenant cannot drain the hardware. Scheduling uses topology aware, binpack, spread, and device specific policies to decide where pods land. The management side spans NVIDIA GPUs, NPUs, DCUs, MLUs, and other accelerator types through one workflow, with the README claiming zero application changes for the workloads involved.
Where the project sits
HAMi is a CNCF Incubating project and appears in the CNCF and CNAI project listings, which the README notes as a marker of its standing. The operational surface is fairly complete: metrics, dashboards, a web UI, Helm installation, and community supported deployment guidance. For platform teams, the combination of device sharing, per workload isolation, and a real project status is the whole pitch.
Editorial conclusion
HAMi is aimed at a specific pain: expensive accelerators sitting idle because one small job grabbed a whole GPU. Device sharing plus per workload limits is the core answer, and the CNCF Incubating status gives some signal of community weight.
Community notes