HAMi

HAMi is open-source middleware for sharing accelerator capacity across Kubernetes workloads. It suits teams operating self-hosted AI, machine-learning or HPC clusters with mixed devices. Its quota controls and scheduling make shared GPUs more practical, but its best-effort isolation rules it out when hardware-enforced guarantees are essential.

Overview

HAMi lets Kubernetes workloads request GPU memory and core limits through resource controls such as nvidia.com/gpumem and nvidia.com/gpucores. For operators, that can make accelerator capacity available to more jobs than assigning whole devices individually. Its scheduling policies—binpack, spread and numa-first—offer different ways to place workloads; binpack and spread can be applied at node or GPU scope.

The project supports a wide range of accelerators, including NVIDIA, AMD, AWS Neuron, Huawei Ascend, Cambricon, Enflame, Hygon, Iluvatar, Kunlunxin, MetaX, Moore Threads, Vastai and Biren. That breadth is useful in heterogeneous clusters, but support is not uniform: some devices lack memory isolation, core isolation or multi-card partitioning.

Key features

Scheduling and monitoring

HAMi exposes real-time device memory and core utilization through a node metrics endpoint that Prometheus can scrape. Its scheduling ecosystem includes Kubernetes, Volcano, Kueue, Koordinator and NVIDIA KAI Scheduler. The built-in priority field has only two levels, so teams needing multi-level queue priorities should integrate Volcano rather than rely on HAMi alone.

Isolation and deployment

For NVIDIA devices, HAMi enforces limits by intercepting user-space library calls. Applications that bypass the CUDA library are outside that mechanism, and the FAQ describes memory and compute enforcement as soft and best-effort. That may suit shared development or batch capacity, but teams with compliance or SLA requirements for hardware-enforced isolation should use MIG instead.

Classic HAMi supports Kubernetes v1.23 or later. HAMi-DRA has a newer baseline: Kubernetes v1.34 or later, the DRA Consumable Capacity feature gate, CDI and NVIDIA driver 440 or later. Installation uses Helm and requires Kubernetes, Helm, kubectl and installation permissions. This is an infrastructure tool for cluster operators, not a managed service for users without Kubernetes administration.

Pricing

HAMi is free and open source. The HAMi plan costs free and provides open-source GPU virtualization middleware for AI workloads on Kubernetes. There is no paid tier or free trial in the stated plan; teams should account for operating their own deployment and matching device capabilities to their isolation needs.

Platforms

HAMi runs on Linux in a self-hosted deployment and supports Kubernetes. The project documents Kubernetes APIs, DRA and CDI integration. That makes it a fit for teams managing their own cluster, not organizations looking for a hosted accelerator-sharing service.

Who it's for

HAMi is best suited to platform teams sharing accelerator capacity among LLM, machine-learning and HPC workloads on Kubernetes, particularly where clusters mix GPU and other accelerator vendors. It is less suitable when workloads need strong hardware-level isolation, or when the target devices do not support the required memory, core or multi-card features.

Pros and cons

• Pro: Memory and core quotas let operators allocate accelerator capacity at workload level instead of reserving whole devices.
• Pro: Support across many accelerator families can help teams manage heterogeneous Kubernetes clusters with one middleware project.
• Pro: Prometheus-scrapable utilization metrics provide node-level visibility into device memory and core use.
• Con: NVIDIA enforcement relies on user-space library interception, and applications bypassing CUDA are not covered.
• Con: Best-effort isolation is not a substitute for hardware-enforced guarantees; some devices also lack specific isolation or partitioning capabilities.
• Con: Built-in priorities have two levels, limiting teams that need richer queue hierarchies without Volcano integration.
• Con: HAMi-DRA's Kubernetes v1.34 requirement is a significant constraint for clusters on older releases.

Alternatives

dstack is another free option, with a self-hosted open-source orchestration stack and a separate GPU marketplace plan billed by GPU usage; consider it when orchestration or marketplace access is a better match than HAMi's accelerator-sharing focus. ClearML offers a free Community plan and says its self-hosted version is open source; it may suit teams seeking a broader self-hosted platform. GPUStack is a free open-source GPU cluster manager, a reasonable alternative when cluster management is the priority.

Backend.AI has a free open-source plan for home users running their own hardware, plus a free try-out plan; it may suit users looking for those options. NVIDIA ShadowPlay is a free Windows app for supported GeForce hardware, rather than a Kubernetes cluster tool. OpenPBS, TORQUE Resource Manager and Apache YuniKorn are free scheduling or resource-management alternatives; choose among them when their respective project is the desired fit.

Browse GPU Cluster Management Software for more options.

Verdict

Choose HAMi if you operate a self-hosted Kubernetes cluster and want free, quota-based sharing and scheduling across a range of accelerators. Its clearest advantage is bringing those controls and utilization metrics into a Kubernetes workflow; its key reason to look elsewhere is that best-effort isolation cannot meet every device's security or SLA requirements.