Apache YuniKorn vs HAMi

Apache YuniKorn is a resource scheduler for batch, data, and machine learning workloads on Kubernetes. It is a Kubernetes-compatible alternative to the default scheduler and is described as transparent to existing Kubernetes applications. Hierarchical queues provide fine-grained tenant controls that can reflect an organization’s structure. Scheduling features include gang scheduling, FIFO and Fair job ordering, resource fairness, reservations, and preemption. A web UI centralizes cluster capacity, utilization, and application information. YuniKorn exposes metrics through Prometheus, and project guidance covers monitoring with Prometheus and Grafana. The project recommends deployment to an existing Kubernetes cluster using its Helm chart and Helm 3 or later. The software is free under the Apache License 2.0. Releases include source tarballs, which must be built before use, and prebuilt Docker images. The project advises checking release artifacts for tampering with GPG or SHA-512. Help is available through the YuniKorn Slack #yunikorn-user channel or the user mailing list.

HAMi is open-source middleware for sharing and scheduling GPUs and other accelerators among AI workloads on Kubernetes. Workloads can request GPU memory and core limits through Kubernetes resource controls. Scheduling options include binpack, spread and numa-first, with binpack and spread available at node or GPU scope. The supported-device list spans NVIDIA, AMD, AWS Neuron, Huawei Ascend, Cambricon, Enflame, Hygon, Iluvatar, Kunlunxin, MetaX, Moore Threads, Vastai and Biren; isolation and partitioning capabilities vary by device. HAMi works with Kubernetes APIs, DRA and CDI, and documents scheduling integrations including Volcano, Kueue, Koordinator and NVIDIA KAI Scheduler. Its node metrics endpoint exposes device memory and core utilization for Prometheus. Classic HAMi requires Kubernetes v1.23 or later. HAMi-DRA requires Kubernetes v1.34 or later, the DRA Consumable Capacity feature gate, CDI and NVIDIA driver 440 or later. NVIDIA limits use user-space library interception, which does not cover applications that bypass CUDA. Enforcement is described as soft and best-effort; the FAQ recommends MIG when hardware-enforced isolation is required.