Version 2.10 schedules shared accelerators through Kubernetes
HAMi v2.10 is a cluster layer for dividing and placing accelerators across pods. A mutating webhook prepares the workload, a scheduler extender filters and scores devices, and device plugins complete allocation on the chosen node. Vendor-specific runtime components can then apply supported memory or compute limits inside the container. Applications keep using Kubernetes resource requests, so platform operators do not have to rewrite each training or inference program.
commit 4434305 is sizable at 553 files and roughly 109,220 source lines, though the clean checkout occupied only 8 MB. The code covers scheduler logic, monitoring, Helm templates, device backends, examples, and end-to-end suites. HAMi lists NVIDIA, Ascend, Cambricon, Hygon, Iluvatar, Kunlunxin, MetaX, Moore Threads, and other device families. That breadth saves platform teams from building a separate scheduler vocabulary for every vendor, but support depth is explicitly hardware-dependent.
The 178-second build ends with 7 failing test targets
Our sandbox installed 234 packages in 31 seconds and compiled the project successfully in 178 seconds. That proves the measured commit can resolve its Go dependencies and build in a fresh golang:1.24-bookworm container with 3 CPUs and 8 GB of RAM. It does not prove that a Helm deployment will work with a particular GPU, driver, runtime, or Kubernetes configuration. A scheduler that builds cleanly can still make a poor placement decision under real cluster state.
The test command exited 1 after 72 seconds, reporting 80 passes and 7 failures out of 87. The supplied tail shows successful utility, client, flag, leader-election, node-lock, and version packages. It then names failures under test/e2e, test/e2e/node, and test/e2e/pod. The tail contains no error explaining those failures, so assigning them to a missing cluster, permissions, timing, or code would be guesswork. The result remains red until a better log proves otherwise.
What happened when we ran it
Our run used commit 4434305 in an unprivileged Debian container with no secrets. Installation succeeded in 31 seconds, the build passed in 178 seconds, and tests failed after 72 seconds with 80 of 87 reported targets passing. The repository scan also found 18 CI workflow files, no Dockerfile at the scanned location, and a tests directory. The 234 installed packages are the only dependency count this review attributes to the setup.
Those numbers describe source mechanics, not a live accelerator trial. Our sandbox did not install HAMi into Kubernetes, attach a GPU, schedule a pod, enforce a memory share, or inspect Prometheus output. We measured no utilization gain, placement quality, workload throughput, or isolation strength. A buyer should replay the failing targets with full logs, then run the chart against the exact server model and container runtime intended for production. The 72-second failure is a release gate, not a performance benchmark.
Kubernetes 1.23 is only the start of the platform contract
The NVIDIA quick start requires Kubernetes 1.23 or newer, an NVIDIA driver at least 440, nvidia-docker above 2.0, glibc 2.17 or newer, Linux 3.10 or newer, and Helm above 3.0. Nodes must be labeled for management, and the NVIDIA runtime must be configured as the default for containerd, Docker, or CRI-O. The Helm chart then installs scheduler and device-plugin components into the cluster, where both must reach a Running state before a sample workload means anything.
Day-two operation includes more than those 6 prerequisites. Teams must own webhook availability, scheduler behavior, device-plugin rollout, certificates, node labels, vendor drivers, runtime configuration, and safe chart upgrades. Metrics are exposed from the scheduler monitor endpoint, whose README default is port 31993, and the project supplies Grafana material plus a separate WebUI. Alerts and rollback policy still belong to the cluster owner.
Cooperative quotas do not isolate hostile tenants
HAMi's security policy draws a useful boundary: in-container enforcement is for cooperative sharing on a trusted cluster. A sufficiently privileged workload may bypass its hook by changing LD_PRELOAD, using a static binary, or attaching with ptrace. That means memory and compute quotas should be treated as scheduling and fairness controls. They are not a substitute for a security boundary between mutually hostile tenants that can change their own process environment or container privileges.
The same caveat appears in the README's device wording. Isolation depends on what each backend, model, driver, and hardware generation supports. Before admitting a device type, run escape, over-allocation, restart, and failure tests for that exact combination. The open issue tracker gives a current example: issue 2974 reports that changing a v2.10.0 node from MIG mode to HAMi-core left the physical GPU in MIG mode even though reported node information changed. Maintainers were replying on September 8, 2026.
Release v2.10.0 expands scheduling and separates DRA
Release v2.10.0 arrived on August 21, 2026. Its notes cover init-container accounting, pod-group handling, dynamic MIG work, a mutex scheduling policy, policy combinations, NUMA alignment, and more device support. The same release removes Dynamic Resource Allocation components from the main HAMi chart and links Ascend DRA to a separate driver project. That split matters for evaluation: installing the primary chart does not deliver every DRA path named elsewhere in the ecosystem.
September 2026 activity supports a serious cluster trial
GitHub showed 4,534 stars, 55 combined issues and pull requests, and a last push on September 8, 2026. That push fixed a scheduler liveness-probe placement in the Helm template, while nearby commits handled image-pull secrets, an Ascend webhook rejection, NVIDIA allocation input, and cached allocations. Issue 2974 received discussion the same day. The latest release is only weeks behind the default branch, so both code and issue activity indicate current maintenance.
HAMi is worth a trial for platform teams whose unused accelerator capacity has a clear cost. The project documents more of its operational and security limits than many infrastructure tools, and the 178-second successful build is a useful starting signal. The trial still needs a disposable cluster, vendor-specific acceptance tests, and a repeat of the 87-target Go run with full failure output.