Lambda maakt open-sourcescheduler Run:ai klaar voor Kubernetes-dienst

Lambda zei op 13 oktober 2026 dat het samenwerkt met NVIDIA om de opensource-GPU-scheduler Run:ai als volwaardige beheerde optie aan te bieden op Lambda Kubernetes Service (LKS), als onderdeel van een geplande bibliotheek met schedulers die als beheerde componenten worden geleverd.

Het plan werd aangekondigd in een blogbericht van Lambda van 13 oktober 2026. „We verwelkomen NVIDIA’s besluit om Run:ai opensource te maken en werken eraan om het als volwaardige optie aan te bieden op Lambda Kubernetes Service (LKS)”, verklaarde het bedrijf. Lambda zei Run:ai sinds 2022 op zijn infrastructuur te ondersteunen. Het omschreef zijn doel als het eenvoudiger maken om de mogelijkheden van Run:ai via LKS te implementeren en te beheren, zodat teams meer controle krijgen over de toewijzing en het delen van GPU-capaciteit.

NVIDIA maakte de scheduler in 2025 opensource

NVIDIA kondigde op 1 april 2025 de opensourcerelease aan van KAI Scheduler, een Kubernetes-native GPU-scheduler die oorspronkelijk binnen het Run:ai-platform is ontwikkeld en onder de Apache 2.0-licentie wordt uitgebracht, volgens de aankondiging van NVIDIA. NVIDIA zei dat de scheduler nog steeds als onderdeel van het NVIDIA Run:ai-platform wordt verpakt en geleverd.

Volgens NVIDIA berekent de scheduler voortdurend de waarden voor een eerlijke verdeling opnieuw en past hij quota’s en limieten in realtime aan. Daarbij combineert hij gang scheduling, het delen van GPU’s en hiërarchische wachtrijen. Een ingebouwde podgrouper koppelt workloads automatisch aan frameworks zoals Kubeflow, Ray, Argo en de Training Operator. NVIDIA beschrijft een planningscyclus die een momentopname van het Kubernetes-cluster maakt, voor elke wachtrij een eerlijk aandeel berekent via fasen voor toegewezen quota en quotaoverschrijding, en vervolgens de acties toewijzen, consolideren, terugvorderen en onderbreken toepast om de huidige toewijzingen in overeenstemming te brengen met de berekende situatie.

GPU’s delen en quota’s plannen in Run:ai

Lambda beschreef de uiteenlopende eisen die AI-ontwikkeling aan GPU’s stelt: voor foutopsporingssessies is soms maar een deel van één GPU nodig, evaluaties kunnen zich over veel zelfstandige taken uitstrekken en gedistribueerde training kan in één keer grote aantallen nauw verbonden GPU’s vereisen. De behoeften veranderen bovendien naarmate het werk zich ontwikkelt van eerste ideeën via experimenten tot productie. Wanneer kleine taken volledige GPU’s toegewezen krijgen, moeten onderzoekers wachten terwijl gereserveerde capaciteit ongebruikt blijft. Ook kunnen teams merken dat hun experimenten vastlopen achter GPU’s die door een andere groep zijn gereserveerd maar niet worden gebruikt.

Zoals Lambda het beschrijft, is Run:ai een GPU-scheduler voor Kubernetes die op twee punten verder gaat dan de standaard Kubernetes-scheduler: GPU’s delen, waardoor meerdere workloads op één GPU kunnen draaien, en plannen op basis van quota’s, waarbij elk team een gegarandeerde toewijzing krijgt en teams ongebruikte capaciteit van elkaar kunnen lenen.

In de documentatie over GPU-fracties van NVIDIA staat dat fracties het GPU-geheugen in kleinere delen opsplitsen die meerdere workloads kunnen delen. De gevraagde geheugengrootte wordt voor elke workload afgedwongen, zodat die niet meer geheugen kan gebruiken dan aangevraagd of beslag kan leggen op het geheugen van een andere workload. Elke pod krijgt een eigen, afzonderlijke virtuele adresruimte voor geheugen; de documentatie noemt dit een „logische GPU”.

Volgens de documentatie gebruiken fracties standaard tijdslicing van NVIDIA om GPU-rekenkracht te delen. Fracties voor meerdere GPU’s wijzen dezelfde fractiegrootte toe op verschillende GPU’s binnen één node. Zo kan een model dat 8 GPU’s gebruikt en per GPU 40GB geheugen nodig heeft, bijvoorbeeld 8×40GB toegewezen krijgen in plaats van het volledige geheugen van elke GPU. Daardoor blijft op elke GPU in die node 40GB beschikbaar voor andere workloads. De documentatie vermeldt dat GPU-fracties en de modus Multi-Instance GPU (MIG) niet op dezelfde node kunnen worden gebruikt.

In de documentatie over schedulerconcepten van NVIDIA staat dat elke nieuw aangemaakte pod aan een podgroep wordt toegewezen en dat gang scheduling inhoudt dat een workload met meerdere pods óf volledig wordt ingepland, óf volledig in afwachting blijft. Voor elk project en elke afdeling wordt per nodepool een planningswachtrij aangemaakt. De toegewezen quota begrenzen welke niet-onderbreekbare workloads kunnen draaien, terwijl resources boven het quotum alleen beschikbaar zijn voor onderbreekbare workloads. De scheduler berekent voor elk project en elke afdeling per nodepool een waarde voor een eerlijke verdeling. Wanneer een wachtrij onder haar eerlijke aandeel blijft en een andere daarboven uitkomt, verplaatst de scheduler resources tussen wachtrijen om het evenwicht te herstellen. Daarbij kunnen onderbreekbare workloads die hun quotum overschrijden, worden onderbroken. De scheduler kan ook resources tussen projecten en afdelingen terugvorderen. Beheerders kunnen per nodepool kiezen voor plaatsingsstrategieën die workloads zo compact mogelijk groeperen of juist spreiden.

Nodes automatisch herstellen in LKS

Lambda merkte op dat zowel delen als onderbreken ervan uitgaan dat de onderliggende GPU naar behoren werkt, maar dat dit op grote schaal niet vanzelfsprekend is: accelerators geven XID-fouten, NVLink- en PCIe-verbindingen verslechteren, geheugenrijen worden opnieuw toegewezen en InfiniBand-poorten zakken onder hun verwachte snelheid. Een scheduler kan geen onderscheid maken tussen een gezonde GPU en een GPU die defect raakt, en blijft daarom taken sturen naar een node die ze laat mislukken.

Lambda zei dat automatisch herstel al beschikbaar wordt gemaakt in LKS. Het bedrijf zei elke node te controleren op dergelijke fouten en elke fout als een standaardconditie van een Kubernetes-node weer te geven. Zodra zo’n conditie optreedt, wordt de node afgeschermd van nieuwe taken, worden lopende taken afgevoerd en wordt de fout automatisch verholpen of doorgestuurd voor hardwareherstel. De node wordt pas weer in gebruik genomen nadat deze opnieuw is gevalideerd.

De documentatie van Lambda voor Managed Kubernetes beschrijft de dienst als een Kubernetes-omgeving met ondersteuning voor GPU’s en InfiniBand (RDMA), en gedeelde permanente opslag op alle nodes in een 1-Click Cluster. De NVIDIA GPU Operator en NVIDIA Network Operator zijn vooraf geïnstalleerd. De dienst voert voortdurend controles uit om te verifiëren dat de GPU’s, netwerken en opslag correct functioneren, en herstelt nodes automatisch om hardwareproblemen op te sporen en te verhelpen.

De roadmap voor de beheerde bibliotheek met taakplanners

Lambda omschreef GPU-planning als de laag die het bewust openlaat en zei dat LKS zich nu richt op wat het een AI-softwarebibliotheek noemt: taakplanners die op Kubernetes draaien, waaronder Slurm en Run:ai, geleverd als beheerde componenten die Lambda op zijn eigen hardware valideert en up-to-date houdt, in plaats van dat klanten ze zelf samenstellen met Helm-charts. Run:ai is een van de belangrijkste onderdelen van die bibliotheek, en Lambda zei dat het met NVIDIA samenwerkt om dat mogelijk te maken.

Volgens Lambda maakt de opensourcerelease deze aanpak mogelijk: het bedrijf kan Run:ai in LKS zelf bundelen, testen en onderhouden, in plaats van klanten een reeks integratie-instructies te geven. Lambda zei toe te werken naar een kant-en-klare integratie waarbij het bedrijf verantwoordelijk is voor de bundeling, validatie en doorlopende werking.

Lambda, dat zelf open onderzoek doet, zei dat het waarde hecht aan de mogelijkheid om de tools waarvan het afhankelijk is te inspecteren, aan te passen en te verbeteren. Het bedrijf beschreef NVIDIA’s besluit als een uitbreiding van die vrijheid naar orkestratie.