Lambda gør Run:ai-planlægningsværktøj med åben kildekode klar til Kubernetes-tjenesten

Lambda oplyste den 13. oktober 2026, at virksomheden samarbejder med NVIDIA om at gøre den open source-udgivne Run:ai-GPU-planlægger til en førsteklasses administreret mulighed på Lambda Kubernetes Service (LKS), som er en del af et planlagt bibliotek af planlæggere, der leveres som administrerede komponenter.

Planen blev fremlagt i et indlæg på Lambdas blog den 13. oktober 2026. »Vi hilser NVIDIAs beslutning om at gøre Run:ai open source velkommen, og vi arbejder på at gøre tjenesten til en førsteklasses mulighed på Lambda Kubernetes Service (LKS),« oplyste virksomheden. Lambda sagde, at infrastrukturen har understøttet Run:ai siden 2022, og beskrev målet som at gøre det nemmere at tage Run:ai-funktionerne i brug og drive dem via LKS, så teams får større kontrol over, hvordan GPU-kapacitet fordeles og deles.

NVIDIA gjorde planlægningsværktøjet open source i 2025

NVIDIA annoncerede den 1. april 2025 udgivelsen af KAI Scheduler som open source under Apache 2.0-licensen. KAI Scheduler er en GPU-planlægningsløsning, der er udviklet specifikt til Kubernetes og oprindeligt blev udviklet som en del af Run:ai-platformen, ifølge NVIDIAs meddelelse. NVIDIA oplyste, at planlægningsværktøjet fortsat pakkes og leveres som en del af NVIDIA Run:ai-platformen.

Ifølge NVIDIA genberegner planlægningsværktøjet løbende værdier for en retfærdig andel og justerer kvoter og grænser i realtid. Det kombinerer gang-planlægning, GPU-deling og hierarkisk køstyring, mens en indbygget podgruppering automatisk forbinder arbejdsbelastninger med rammeværk som Kubeflow, Ray, Argo og Training Operator. NVIDIA beskriver en planlægningscyklus, der tager et øjebliksbillede af Kubernetes-klyngen, beregner en retfærdig andel for hver kø gennem faser med berettigede kvoter og ressourcer ud over kvoten og derefter anvender handlingerne allokering, konsolidering, tilbagekrævning og foregribelse for at bringe de aktuelle allokeringer på linje med den beregnede tilstand.

GPU-deling og kvotebaseret planlægning i Run:ai

Lambda beskrev de forskellige krav, som AI-udvikling stiller til GPU’er: Fejlfindingssessioner kræver måske kun en del af én GPU, evalueringer kan brede sig over mange uafhængige job, og distribueret træning kan kræve et stort antal tæt forbundne GPU’er på én gang. Behovene ændrer sig desuden, efterhånden som arbejdet går fra de første idéer over eksperimenter til produktion. Når små job får tildelt hele GPU’er, må forskerne vente, mens reserveret kapacitet står ubrugt, og teams kan opleve, at deres eksperimenter blokeres af en anden gruppes reserverede, men inaktive GPU’er.

Som Lambda beskriver det, er Run:ai en GPU-planlægger til Kubernetes, der går videre end Kubernetes’ standardplanlægger på to måder: GPU-deling, som gør det muligt at køre flere arbejdsbelastninger på én GPU, og kvotebaseret planlægning, som garanterer hvert team en tildeling og samtidig lader teams låne ubrugt kapacitet af hinanden.

NVIDIAs dokumentation om GPU-fraktioner oplyser, at fraktioner opdeler GPU-hukommelsen i mindre dele, som flere arbejdsbelastninger kan dele. Den anmodede hukommelsesstørrelse håndhæves for hver arbejdsbelastning, så den hverken kan overskride sin anmodning eller gøre indhug i en anden arbejdsbelastnings hukommelse. Hver pod får sit eget separate virtuelle adresserum, en ordning, som dokumentationen kalder en »logisk GPU«.

Ifølge dokumentationen anvender fraktioner som standard NVIDIAs tidsopdeling til at dele GPU-beregningskapaciteten. Fraktioner med flere GPU’er tildeler samme fraktionsstørrelse på tværs af flere GPU’er på én node: En model, der bruger 8 GPU’er og kræver 40GB hukommelse pr. GPU, kan for eksempel få tildelt 8×40GB i stedet for hver GPU’s fulde hukommelse, så 40GB på hver GPU forbliver tilgængelig for andre arbejdsbelastninger på noden. Dokumentationen bemærker, at GPU-fraktioner og tilstanden Multi-Instance GPU (MIG) ikke kan bruges på samme node.

NVIDIAs dokumentation om planlægningsbegreber oplyser, at hver nyoprettet pod tildeles en podgruppe, og at gang-planlægning betyder, at en arbejdsbelastning bestående af flere pods enten planlægges fuldt ud eller forbliver helt afventende. Der oprettes en planlægningskø for hvert projekt og hver afdeling i hver nodepulje; berettigede kvoter sætter grænser for, hvilke arbejdsbelastninger, der ikke kan afbrydes, der kan køre, mens ressourcer ud over kvoten kun er tilgængelige for arbejdsbelastninger, der kan afbrydes. Planlægningsværktøjet beregner en værdi for en retfærdig andel for hvert projekt og hver afdeling i hver nodepulje. Når én kø ligger under sin retfærdige andel, mens en anden overskrider sin, flytter planlægningsværktøjet ressourcer mellem køerne for at skabe balance; denne proces kan medføre, at arbejdsbelastninger, der kan afbrydes, og som bruger ressourcer ud over kvoten, afbrydes. Planlægningsværktøjet kan også tilbagekræve ressourcer mellem projekter og afdelinger, og administratorer kan vælge pakke- eller fordelingsstrategier for placering i hver nodepulje.

Automatisk afhjælpning af fejl på noder i LKS

Lambda bemærkede, at både deling og foregribelse forudsætter, at den underliggende GPU fungerer korrekt, og at det ikke kan tages for givet i stor skala: Acceleratorer giver XID-fejl, NVLink- og PCIe-forbindelser forringes, hukommelsesrækker ommappes, og InfiniBand-porte falder til under deres forventede hastighed. En planlægningsfunktion kan ikke skelne mellem en velfungerende GPU og en GPU med fejl, så den bliver ved med at sende job til en node, der afviser dem.

Lambda oplyste, at automatisk afhjælpning allerede leveres i LKS. Virksomheden sagde, at den overvåger alle noder for sådanne fejl og viser hver fejl som en standardtilstand for en Kubernetes-node. Når en tilstand udløses, sættes noden i karantæne, så den ikke modtager nyt arbejde, igangværende job drænes, og fejlen enten rettes automatisk eller sendes videre til hardwarereparation. Noden tages først i brug igen, når den er blevet valideret på ny.

Lambdas dokumentation for administreret Kubernetes beskriver tjenesten som et Kubernetes-miljø med understøttelse af GPU’er og InfiniBand (RDMA) samt delt, vedvarende lagerplads på tværs af alle noder i en 1-Click Cluster. NVIDIA GPU Operator og NVIDIA Network Operator er forudinstalleret, og tjenesten udfører løbende validering for at kontrollere, at GPU’er, netværk og lager fungerer korrekt. Derudover afhjælpes nodefejl automatisk, så hardwareproblemer opdages og udbedres.

Køreplan for biblioteket med administrerede schedulere

Lambda beskrev GPU-planlægning som det lag, virksomheden bevidst lader stå åbent, og sagde, at næste skridt for LKS er det, virksomheden kalder et AI-softwarebibliotek: schedulere, der kører på Kubernetes, herunder Slurm og Run:ai, leveret som administrerede komponenter, som Lambda validerer på sin egen hardware og holder opdaterede, i stedet for at kunderne selv skal sammensætte dem ud fra Helm-diagrammer. Run:ai er et centralt mål for biblioteket, og Lambda sagde, at virksomheden samarbejder med NVIDIA for at nå dertil.

Ifølge Lambda er det open source-udgivelsen, der gør denne tilgang mulig: Virksomheden kan pakke, teste og vedligeholde Run:ai direkte i LKS i stedet for at give kunderne et sæt integrationsvejledninger. Lambda sagde, at virksomheden sigter mod en integration, der fungerer direkte fra start, og hvor den selv står for pakning, validering og løbende drift.

Lambda, der selv producerer åben forskning, sagde, at virksomheden sætter pris på at kunne undersøge, tilpasse og forbedre de værktøjer, den er afhængig af, og beskrev NVIDIAs beslutning som en udvidelse af denne frihed til orkestrering.