HAMi: teilt GPUs im Kubernetes-Cluster auf Speicher- und Core-Isolation für geteilte Beschleuniger

GPU-Kapazität bleibt knapp und teuer. HAMi teilt eine physische GPU in Anteile nach Speicher, Rechenkernen oder Gerätezahl und lässt mehrere Kubernetes-Pods parallel darauf rechnen. Die harte Isolation zur Laufzeit hält die Workloads dabei getrennt.

Die Cloud Native Computing Foundation führt „HAMi“ seit dem 15.07 2026 als Incubating-Projekt. Der Name steht für Heterogeneous AI Computing Virtualization Middleware. HAMi sitzt zwischen Kubernetes und dem Beschleuniger, fängt die CUDA-Aufrufe der Container ab und weist jedem Pod exakt den zugesagten Anteil an GPU-Speicher und Rechenleistung zu. Anwendungen laufen ohne Codeänderung.

GPU-Anteile statt ganzer Karten

Ein einzelnes Modell belegt oft nur einen Bruchteil des Speichers, der Rest der Karte bleibt ungenutzt. HAMi setzt hier an. Der Scheduler-Extender und ein Device-Plugin melden dem Cluster feingranulare Ressourcen, darunter 4 GByte Videospeicher oder 30 Prozent der Rechenkerne, statt einer kompletten GPU.

Mehrere Inferenz-Dienste teilen sich damit eine Nvidia-Karte, ohne sich gegenseitig den Speicher zu überschreiben, und die HAMi-Core-Schicht kappt jeden Prozess, der sein zugewiesenes Kontingent zur Laufzeit überzieht.

Der Aufbau ruht auf mehreren getrennten Bausteinen:

• Scheduler-Extender: platziert Pods nach freiem GPU-Speicher und gewählter Strategie;

• Device-Plugin: meldet Kubernetes die teilbaren Ressourcen je Knoten;

• HAMi-Core: erzwingt die Speicher- und Kerngrenzen im laufenden Container;

• WebUI und Prometheus-Metriken: zeigen Auslastung und Kontingente je Beschleuniger.

Betrieb ohne Eingriff in den Code

Der Einbau geschieht über einen Mutating Webhook, der die Pod-Spezifikation beim Start ergänzt und die angeforderten GPU-Anteile einträgt. Bestehende Container-Images bleiben unverändert.

Entwickler fordern Speicher und Kerne über normale Ressourcen-Limits an, und über die HAMi-WebUI sowie eine Prometheus-kompatible Schnittstelle sehen Betreiber, wie stark jede Karte ausgelastet ist und welcher Pod gerade welchen Anteil an Speicher und Rechenkernen für sich belegt.

Das Projekt zählt nach eigenen Angaben mehr als 550 mitwirkende Organisationen und rund 3.500 Sterne auf GitHub.

Verteilung über Hersteller und Standorte

HAMi bindet Beschleuniger mehrerer Hersteller über eine einzige Schnittstelle ein. Neben NVIDIA-GPUs unterstützt das Projekt AMD-Karten sowie NPU-, DCU- und MLU-Chips. Der Scheduler verteilt Pods nach den Strategien binpack, spread und topology-aware, also dicht gepackt, breit gestreut oder entlang der Hardware-Topologie. Bei DaoCloud steuert HAMi nach Angaben des Anbieters mehr als 10.000 GPUs in über zehn Rechenzentren. Die aktuelle stabile Version 2.9.0 folgt auf insgesamt 16 Releases.

Seit Juni 2026 steckt die harte Speicher-Isolation von HAMi-Core auch im KAI Scheduler, den NVIDIA quelloffen gestellt hat. Damit wandert die Technik aus einem einzelnen Projekt in den breiteren GPU-Scheduling-Stack. Für Betreiber sinkt so die Bindung an die festen MIG-Grenzen der Hardware, denn die Aufteilung liegt in Software.

Fazit

HAMi bringt die Mehrfachnutzung von Beschleunigern in Kubernetes auf eine herstellerübergreifende Basis. Der Aufsatz aus Webhook, Scheduler-Extender und HAMi-Core teilt Speicher und Rechenkerne hart ab und hält die Auslastung teurer Karten hoch. Mit dem Wechsel in den CNCF-Incubator und der Übernahme in den KAI Scheduler gewinnt das Projekt an Gewicht im RZ-Betrieb.

KI-Infrastruktur im Rechenzentrum

AMD im Rennen gegen Nvidia – Ist der MI455X die bessere KI-GPU?

(ID:50918687)