Lambda bereitet Open-Source-Scheduler Run:ai für den Kubernetes-Service vor

Lambda teilte am 13. Oktober 2026 mit, dass das Unternehmen mit NVIDIA daran arbeitet, den als Open Source veröffentlichten GPU-Scheduler Run:ai als vollwertige verwaltete Option in den Lambda Kubernetes Service (LKS) aufzunehmen. Dieser ist Teil einer geplanten Bibliothek von Schedulern, die als verwaltete Komponenten bereitgestellt werden.

Der Plan wurde in einem Beitrag vom 13. Oktober 2026 im Blog von Lambda vorgestellt. „Wir begrüßen NVIDIAs Entscheidung, Run:ai als Open Source zu veröffentlichen, und arbeiten daran, den Scheduler zu einer vollwertigen Option im Lambda Kubernetes Service (LKS) zu machen“, erklärte das Unternehmen. Lambda zufolge unterstützt das Unternehmen Run:ai seit 2022 auf seiner Infrastruktur. Ziel sei es, die Einführung und den Betrieb der Funktionen von Run:ai über LKS zu erleichtern, damit Teams mehr Kontrolle darüber erhalten, wie GPU-Kapazitäten zugewiesen und gemeinsam genutzt werden.

NVIDIA veröffentlichte den Scheduler 2025 als Open Source

NVIDIA gab am 1. April 2025 die Veröffentlichung des KAI Scheduler als Open Source unter der Apache-2.0-Lizenz bekannt. Dabei handelt es sich um eine Kubernetes-native Lösung zur GPU-Planung, die ursprünglich innerhalb der Run:ai-Plattform entwickelt wurde, wie aus NVIDIAs Ankündigung hervorgeht. NVIDIA zufolge wird der Scheduler weiterhin als Teil der NVIDIA-Run:ai-Plattform gebündelt und bereitgestellt.

NVIDIA zufolge berechnet der Scheduler fortlaufend Fair-Share-Werte neu und passt Quoten und Grenzwerte in Echtzeit an. Dabei kombiniert er Gang-Scheduling, GPU-Sharing und hierarchische Warteschlangen. Ein integrierter Podgrouper ordnet Workloads automatisch Frameworks wie Kubeflow, Ray, Argo und dem Training Operator zu. NVIDIA beschreibt einen Planungszyklus, in dem eine Momentaufnahme des Kubernetes-Clusters erstellt, für jede Warteschlange anhand von Phasen für zustehende und überschrittene Quoten ein Fair Share berechnet und anschließend durch Zuweisungs-, Konsolidierungs-, Rückforderungs- und Präemptionsaktionen die aktuellen Zuweisungen an den berechneten Zustand angepasst werden.

GPU-Sharing und quotenbasierte Planung in Run:ai

Lambda beschrieb die unterschiedlichen Anforderungen, die die KI-Entwicklung an GPUs stellt: Bei Debugging-Sitzungen genügt möglicherweise ein Teil einer GPU, Evaluierungen können auf viele unabhängige Jobs verteilt werden, und verteiltes Training kann gleichzeitig zahlreiche eng miteinander verbundene GPUs erfordern. Zudem ändern sich die Anforderungen im Verlauf der Arbeit – von ersten Ideen über Experimente bis hin zur Produktion. Wenn kleine Jobs ganze GPUs erhalten, müssen Forschende warten, während reservierte Kapazitäten ungenutzt bleiben. Außerdem können Teams feststellen, dass ihre Experimente hinter den reservierten, aber ungenutzten GPUs einer anderen Gruppe feststecken.

Run:ai ist laut Lambda ein GPU-Scheduler für Kubernetes, der den standardmäßigen Kubernetes-Scheduler in zweierlei Hinsicht erweitert: GPU-Sharing ermöglicht es, mehrere Workloads auf einer einzelnen GPU auszuführen, und die quotenbasierte Planung sichert jedem Team eine Zuweisung zu und ermöglicht es den Teams zugleich, ungenutzte Kapazitäten voneinander auszuleihen.

NVIDIAs Dokumentation zu GPU-Anteilen erläutert, dass GPU-Speicheranteile den Speicher in kleinere Einheiten aufteilen, die mehrere Workloads gemeinsam nutzen können. Dabei wird die angeforderte Speichergröße für jeden Workload durchgesetzt, sodass dieser weder mehr als angefordert nutzen noch in den Speicher eines anderen Workloads eingreifen kann. Jeder Pod erhält einen eigenen, separaten virtuellen Adressraum für den Speicher – eine Anordnung, die in der Dokumentation als „logische GPU“ bezeichnet wird.

Laut Dokumentation nutzen GPU-Anteile standardmäßig NVIDIAs Time-Slicing, um GPU-Rechenleistung gemeinsam zu nutzen. Anteile über mehrere GPUs hinweg weisen innerhalb eines einzelnen Knotens mehreren GPUs dieselbe Anteilgröße zu: Ein Modell, das beispielsweise 8 GPUs nutzt und pro GPU 40 GB Speicher benötigt, kann mit 8×40 GB statt mit dem gesamten Speicher jeder GPU ausgestattet werden. So bleiben auf jeder GPU 40 GB für andere Workloads auf diesem Knoten verfügbar. Die Dokumentation weist darauf hin, dass GPU-Anteile und der Multi-Instance-GPU-Modus (MIG) nicht auf demselben Knoten verwendet werden können.

NVIDIAs Dokumentation zu Scheduler-Konzepten erläutert, dass jeder neu erstellte Pod einer Pod-Gruppe zugewiesen wird und dass beim Gang-Scheduling ein aus mehreren Pods bestehender Workload entweder vollständig eingeplant wird oder vollständig in der Warteschlange bleibt. Für jedes Projekt und jede Abteilung wird pro Knotenpool eine Planungswarteschlange erstellt. Zustehende Quoten begrenzen, welche nicht verdrängbaren Workloads ausgeführt werden können; Ressourcen oberhalb der Quote stehen ausschließlich verdrängbaren Workloads zur Verfügung. Der Scheduler berechnet für jedes Projekt und jede Abteilung pro Knotenpool einen Fair-Share-Wert. Liegt eine Warteschlange unter ihrem Fair Share, während eine andere darüber liegt, verschiebt der Scheduler Ressourcen zwischen den Warteschlangen, um das Gleichgewicht wiederherzustellen. Dabei können verdrängbare Workloads oberhalb der Quote präemptiert werden. Außerdem kann der Scheduler Ressourcen zwischen Projekten und Abteilungen zurückfordern. Administratoren können für jeden Knotenpool Strategien zur dichten Packung (Bin-Packing) oder zur Verteilung (Spread) festlegen.

Automatische Knotenbehebung in LKS

Lambda wies darauf hin, dass sowohl Sharing als auch Präemption voraussetzen, dass die zugrunde liegende GPU fehlerfrei funktioniert – und dass dies bei großem Maßstab nicht selbstverständlich ist: Beschleuniger melden XID-Fehler, NVLink- und PCIe-Verbindungen verschlechtern sich, Speicherzeilen werden neu zugeordnet und InfiniBand-Ports fallen unter ihre erwartete Datenrate. Ein Scheduler kann eine fehlerfreie GPU nicht von einer ausfallenden unterscheiden und sendet daher weiterhin Jobs an einen Knoten, der sie abweist.

Lambda teilte mit, dass die automatische Fehlerbehebung in LKS bereits bereitgestellt wird. Das Unternehmen erklärte, es überwache jeden Knoten auf solche Fehler und melde jeden davon als standardmäßigen Kubernetes-Knotenzustand. Sobald ein solcher Zustand eintritt, wird der Knoten für neue Workloads gesperrt und laufende Jobs werden beendet. Der Fehler wird entweder automatisch behoben oder zur Hardware-Reparatur eskaliert. Erst nach einer erneuten Validierung wird der Knoten wieder in Betrieb genommen.

Die Dokumentation zu Lambdas verwaltetem Kubernetes beschreibt den Dienst als Kubernetes-Umgebung mit Unterstützung für GPUs und InfiniBand (RDMA) sowie gemeinsamem persistentem Speicher auf allen Knoten eines 1-Click-Clusters. Der NVIDIA GPU Operator und der NVIDIA Network Operator sind vorinstalliert. Außerdem führt der Dienst kontinuierliche Prüfungen durch, um sicherzustellen, dass GPUs, Netzwerke und Speicher ordnungsgemäß funktionieren. Hinzu kommt eine automatische Fehlerbehebung auf den Knoten, die Hardwareprobleme erkennt und behebt.

Die Roadmap für die Bibliothek verwalteter Scheduler

Lambda bezeichnete die GPU-Planung als die Ebene, die das Unternehmen bewusst offenlässt. Als Nächstes soll LKS laut Lambda zu einer sogenannten KI-Softwarebibliothek ausgebaut werden: Scheduler, die auf Kubernetes laufen, darunter Slurm und Run:ai, sollen als verwaltete Komponenten bereitgestellt werden, die Lambda auf seiner eigenen Hardware validiert und aktuell hält. Kunden müssten sie dann nicht mehr von Hand aus Helm-Charts zusammenstellen. Run:ai ist ein wichtiges Ziel für diese Bibliothek, und Lambda erklärte, mit NVIDIA daran zu arbeiten.

Laut Lambda ermöglicht die Open-Source-Veröffentlichung diesen Ansatz: Das Unternehmen kann Run:ai direkt in LKS paketieren, testen und warten, statt den Kunden eine Reihe von Integrationsanleitungen an die Hand zu geben. Lambda erklärte, eine sofort einsatzbereite Integration anzustreben, bei der das Unternehmen Paketierung, Validierung und den laufenden Betrieb übernimmt.

Lambda, das selbst offene Forschung betreibt, erklärte, es schätze die Möglichkeit, die eingesetzten Tools zu prüfen, anzupassen und zu verbessern. Die Entscheidung von NVIDIA, so Lambda, übertrage diese Freiheit auch auf die Orchestrierung.