GPU-Scheduling für ML-Teams: NVIDIA KAI Scheduler, Kueue oder Slurm, Entwurf für 16 GPUs

KAI Scheduler, Kueue oder Slurm: welcher Scheduler für welches Unternehmen

Ein Unternehmen mit zwei bis vier GPU-Servern und mehreren ML-Teams braucht von einem Scheduler drei Dinge: einen festen Anteil an Karten je Team, einen Weg, freie Karten zu verleihen und zurückzuholen, und Jobs, die erst starten, wenn alle ihre GPUs frei sind. In Kubernetes leistet NVIDIAs KAI Scheduler alle drei als Ersatz-Scheduler, Kueue als Kontingentschicht über dem Standard-Scheduler, und außerhalb von Kubernetes leistet Slurm sie für Batch-Jobs. Für einen Cluster, der nur GPU-Arbeit trägt und in dem Notebooks Karten teilen sollen, passt KAI besser; für einen Cluster mit gemischten Kartentypen oder Job-Frameworks, der den Standard-Scheduler behält, Kueue.

README, Queue- und Fairness-Dokumentation des KAI Scheduler auf GitHub; Kueue-Überblick (geändert am 9. Oktober 2026) und Installationsanleitung (1. Oktober 2026); alle gelesen am 25. Oktober 2026. Kueue-Felder und Slurm-Optionen wie in unseren Leitfäden zu geteilten GPU-Plattformen und Servern für Hochschullabore dokumentiert.

Die Zeile zu den Kartentypen zählt bei gemischten Flotten. KAIs Queue-Dokumentation nennt Kontingentfelder für cpu, memory und gpu, ohne Feld je GPU-Modell; ein Team, das H200 NVL und RTX PRO 6000 Server Edition als getrennte Zahlen halten soll, lässt sich daher mit den ResourceFlavors von Kueue leichter abbilden. Ein Cluster aus einem einzigen Kartentyp, etwa vier Inferenzknoten, hat dieses Problem nicht.

NVIDIA KAI Scheduler im Überblick

Der KAI Scheduler entstand in Run:ai. NVIDIAs Entwicklerblog vom 1. April 2025 kündigte an, dass der Scheduler, „Originally developed within the Run:ai platform“, unter der Lizenz Apache 2.0 verfügbar ist und weiterhin als Teil von NVIDIA Run:ai ausgeliefert wird. Das README des Projekts nennt es ein CNCF-Sandbox-Projekt auf Basis von kube-batch. Das Repository liegt inzwischen in der GitHub-Organisation kai-scheduler, und am 25. Oktober 2026 war v0.18.5 das neueste Release, das OCI-Tags des Helm-Charts ohne das Präfix „v“ ergänzte, damit sich Semver-Bereiche nutzen lassen.

Das README zählt die Funktionen auf: Gang Scheduling („Ensure all pods in a group are scheduled simultaneously or not at all“), Bin Packing oder Verteilung, Workload-Priorität, hierarchische Queues, Kontingente und Gewichte je Queue mit Dominant Resource Fairness, zeitbasierte Fair-Share-Verteilung, die frühere Nutzung mit zeitlichem Abklingen zählt, elastische Workloads, DRA-Unterstützung über ResourceClaims, GPU-Sharing, topologiebewusstes Scheduling und das Zusammenlegen laufender Workloads gegen Fragmentierung. Als native Integration nennt es Ray über KubeRay; NVIDIAs Ankündigung nannte außerdem Kubeflow, Argo und den Training Operator.

Die Installation ist ein Helm-Release aus dem OCI-Chart auf ghcr.io im Namespace kai-scheduler, mit der Version von der Release-Seite. Voraussetzungen sind ein laufender Kubernetes-Cluster, Helm und für GPU-Workloads der NVIDIA GPU Operator; eine Mindestversion von Kubernetes nennt das README nicht. Ein Pod nutzt KAI mit schedulerName: kai-scheduler und nennt seine Queue mit dem Label kai.scheduler/queue. Eine frische Installation legt default-parent-queue und die Blatt-Queue default-queue an, ein erster Pod läuft also, bevor es Team-Queues gibt.

GPU-Kontingente für Teams in KAI: Queues, Fairness und Reclaim

Queues sind eine eigene Ressource, apiVersion scheduling.run.ai/v2, kind Queue. Jede hat eine optionale parentQueue, eine Priorität und für cpu, memory und gpu je drei Werte: quota, den für die Queue reservierten Anteil; limit, die harte Obergrenze; und overQuotaWeight, den Anteil an freien Ressourcen innerhalb einer Prioritätsstufe. „Only leaf queues (queues with no children) can be used for scheduling jobs“; übergeordnete Queues verteilen die Ressourcen auf ihre Kinder.

Zwei Vorgaben verdienen Aufmerksamkeit. Ein Kontingent von 0 oder ohne Wert gibt der Queue keine reservierten Ressourcen, -1 bedeutet unbegrenzt. Ein Limit von 0 oder ohne Wert bedeutet laut Dokumentation „No additional resources allowed“, -1 bedeutet kein Limit. Eine Team-Queue, die freie GPUs leihen soll, braucht also ausdrücklich limit -1 oder eine Zahl über ihrem Kontingent.

Die Fairness-Dokumentation legt die Reihenfolge fest. Das Kontingent einer Queue wird ihr immer zugeteilt („Deserved quota for a queue will always be allocated to it“), freie Kapazität wird danach nach Priorität und Gewicht verteilt, und Workloads aus Queues unter ihrem fairen Anteil können Workloads aus Queues darüber verdrängen. Der Quota-Reclaim greift nur auf Ressourcen oberhalb des Kontingents zu. Ressourcen innerhalb des Kontingents von einer Queue niedrigerer Priorität zurückzuholen, braucht die Option queuePriorityInQuotaReclaim, standardmäßig aus und als Alpha gekennzeichnet. Mit den Vorgaben behält ein Team, das innerhalb seines Kontingents bleibt, seine GPUs.

Kueue und Slurm im Vergleich

Kueue beschreibt sich als „a kubernetes-native system that manages quotas and how jobs consume them“: Es entscheidet, wann ein Job wartet, zugelassen oder verdrängt wird, und „does not replace any existing Kubernetes components“. Sein Überblick nennt eingebaute Unterstützung für Batch-Jobs, Kubeflow-Trainingsjobs, RayJob, RayCluster, JobSet, AppWrappers und einfache Pods, einen All-or-nothing-Modus mit Timeout, teilweise Zulassung mit geringerer Parallelität, topologiebewusstes Scheduling und MultiKueue, das Jobs an andere Cluster abgibt. Die Installationsanleitung, gelesen am 25. Oktober 2026, installiert v0.20.3 und empfiehlt Kubernetes 1.34 oder neuer. Wie ClusterQueues, Cohorts sowie Leih- und Verleihgrenzen für Abteilungen funktionieren, erklärt unser Leitfaden zur geteilten GPU-Plattform mit Kontingenten und Kostenverrechnung; dieser Artikel wiederholt es nicht.

Slurm passt zu anderen Nutzern und Umgebungen: Forschenden, die Batch-Jobs mit sbatch abschicken, MPI-Codes und Servern ohne Kubernetes. Es plant GPUs als generische Ressourcen, unterstützt vorab angelegte MIG-Geräte und zählt GPUs im Fair-Share erst, wenn TRESBillingWeights ihnen ein Gewicht gibt, wie unser Leitfaden zu GPU-Servern für Hochschul-Forschungslabore erklärt. Ein Unternehmen, dessen ML-Teams Container, Notebooks und Modelldienste betreiben, gewinnt mit Kubernetes und KAI oder Kueue mehr.

Unsere KI-Server dienen als Kubernetes-GPU-Knoten, mit den Voraussetzungen des GPU Operators. Nennen Sie uns die Zahl der Teams und GPUs im Cluster, und unser Team schlägt Knoten und Kartenaufteilung vor.

Ein Queue-Entwurf für drei Teams auf 16 GPUs

Nehmen Sie vier Server mit je vier RTX PRO 6000 Server Edition, den Inferenzknoten unserer KI-Server-Seite, also 16 Karten mit 96 GB in einem Kubernetes-Cluster. Drei Teams teilen sie: ein Produktteam, das Modelle für die Belegschaft im Dauerbetrieb bereitstellt, ein Team für angewandtes ML, das Modelle in Jobs über mehrere GPUs feinabstimmt, und ein Data-Science-Team, das in Notebooks arbeitet.

Unser Beispielentwurf, geschrieben für KAIs Queue-Felder (quota, limit, overQuotaWeight, priority, parentQueue) nach der Dokumentation vom 25. Oktober 2026. Die Kontingente ergeben zusammen die 16 Karten.

Die Queue serving hält sechs Karten und nie mehr, genug für drei Tensor-Parallel-Paare mit gpt-oss-120b, jedes Paar mit 93 Gesprächen von 32K Tokens bei 16-Bit-KV-Cache nach unserer Nutzer-pro-Karte-Regel wie in unserem Leitfaden zum Server mit vier Karten. Da sie innerhalb ihres Kontingents bleibt, nimmt KAIs Standard-Reclaim ihr diese Karten nie weg. Modelldienste sollten trotzdem als mehrere Replikate auf verschiedenen Knoten laufen, damit ein Knotenausfall Kapazität kostet und nicht den Dienst.

Die Queue training hält sechs Karten und darf alle freien leihen. Ein Fine-Tuning-Job mit vier GPUs in einem Pod landet auf einem Knoten; ein Job aus mehreren Pods über Knoten hinweg, etwa ein PyTorch- oder Ray-Job mit zwei Workern zu je vier GPUs, nutzt Gang Scheduling und startet erst, wenn alle acht Karten frei sind. Kommt das Notebook-Team morgens zurück, verdrängt KAIs Fair-Share-Reclaim die geliehenen Trainings-Pods; Trainingsjobs brauchen also Checkpoints. Das Gewicht 2 gibt dem Training doppelt so viel von den freien Karten wie den Notebooks.

Die Queue notebooks hält vier Karten und ein Limit von acht. Mit GPU-Sharing, bei der Installation eingeschaltet (global.gpuSharing=true), kann ein Notebook-Pod mit der Annotation gpu-fraction und dem Wert 0.5 eine halbe Karte anfordern oder mit gpu-memory eine Speichermenge. KAIs Dokumentation ist eindeutig: „By default, KAI Scheduler does not enforce memory allocation limits or perform memory isolation between processes“, und Pods auf einer gemeinsamen GPU „may consume more memory than requested“; zur Durchsetzung verweist sie auf HAMi. Darf ein Notebook den Speicher eines anderen nicht erschöpfen können, sind MIG-Instanzen mit 24 GB und eigenem Speicher, wie in unseren MIG-Profilen der RTX PRO 6000 aufgeführt, die stärkere Wahl. KAIs GPU-Sharing-Dokumentation erwähnt MIG nicht; testen Sie MIG-Ressourcen mit KAI also zuerst auf einem Knoten.

Derselbe Entwurf in Kueue

In Kueue werden die drei Teams zu drei ClusterQueues in einer Cohort, mit nominalQuota 6, 6 und 4 für nvidia.com/gpu, einer LocalQueue im Namespace jedes Teams und einem lendingLimit von null auf der Queue serving, damit ihre Karten nie in den gemeinsamen Pool gehen. Training bekommt ein borrowingLimit, und reclaimWithinCohort auf den verleihenden Queues lässt das Notebook-Team seine Karten zurückholen. Die Platzierung bleibt beim Standard-Scheduler. Der Kueue-Überblick nennt keine eigenen GPU-Anteile; ganze Karten oder MIG-Profile, die der GPU Operator bereitstellt, werden zur Einheit des Kontingents, wie unser Leitfaden zum GPU-Sharing in Kubernetes zeigt.

In keiner der Projektdokumentationen, die wir gelesen haben, fanden wir beide Scheduler auf denselben Pods kombiniert. Wählen Sie einen je Cluster, mindestens aber je Workload.

Run:ai, jetzt Open Source, und NVIDIA AI Enterprise

NVIDIAs Produktseite zu Run:ai, veröffentlicht am 13. Oktober 2026, nennt Run:ai „the open source AI workload and GPU orchestration platform for Kubernetes“ und verlinkt das Quellcode-Repository, das unter der Apache License 2.0 steht, Marken ausgenommen. Das Repository beschreibt eine Web-Oberfläche, CLI und REST-API, Abteilungen und Projekte mit Kontingenten, rollenbasierte Zugriffe und darunter den KAI Scheduler. Dieselbe Seite bietet Run:ai als Teil von NVIDIA AI Enterprise an, der kommerziellen Suite mit Support. Für ein Unternehmen, das mit KAI beginnt, ergibt sich so ein Weg zu Oberfläche und Abteilungsberichten auf demselben Scheduler, entweder selbst betrieben aus dem Open-Source-Code oder mit Support über eine AI-Enterprise-Lizenz. Unser Leitfaden zur Lizenzierung von NVIDIA AI Enterprise erklärt die Berechtigung je GPU.

Vor der Entscheidung

Einige Fakten entscheiden die meisten Fälle:

1. Mischt der Cluster Kartentypen und soll der Anteil jedes Teams je Typ gezählt werden, beginnen Sie mit Kueue und seinen ResourceFlavors.
2. Sollen Notebooks Karten teilen und akzeptieren die Teams gemeinsamen Speicher, sind KAIs Anteile das einfachste Werkzeug; für Isolation nutzen Sie MIG.
3. Müssen Trainingsjobs aus mehreren Pods vollständig starten, bieten das beide; KAI hat es eingebaut, Kueue nutzt einen Modus mit Timeout.
4. Brauchen Nutzer eine Oberfläche, Abteilungen und Berichte, liefert Run:ai über KAI sie, als Open Source oder mit Support über AI Enterprise.
5. Besteht die Arbeit aus MPI-Batch-Jobs auf Bare Metal, bleibt Slurm das Werkzeug.

Kubernetes 1.34 erreicht am 27. Oktober 2026 sein Lebensende, ein neuer GPU-Cluster beginnt also mit einem neueren Release; unser Leitfaden zu Kubernetes DRA für NVIDIA-GPUs beschreibt, was sich ändert, wenn Pods GPUs nach Attributen anfordern.

Was wir liefern

Wir bauen KI-Server auf Bestellung als Kubernetes-GPU-Knoten: einen Einstiegsserver mit zwei RTX PRO 6000 Server Edition, einen Inferenzknoten mit vier und einen Trainingsknoten mit acht H200 NVL, jeweils mit zwei AMD-EPYC-Prozessoren, vor der Lieferung montiert und getestet und EU-weit auf einen Vertrag und eine Rechnung geliefert. Lizenzen für NVIDIA AI Enterprise, die Run:ai einschließen, liefern wir mit der Hardware. Schicken Sie uns Ihre Teams und deren Workloads, und wir antworten innerhalb eines Werktages mit einer Knotenkonfiguration.

FAQ