Lambda gör Run:ai-schemaläggaren med öppen källkod redo för Kubernetes-tjänsten

Lambda uppgav den 13 oktober 2026 att företaget samarbetar med NVIDIA för att göra den schemaläggare för GPU:er med öppen källkod, Run:ai, till ett förstahandsval som hanterad komponent i Lambda Kubernetes Service (LKS), som ingår i ett planerat bibliotek med schemaläggare som levereras som hanterade komponenter.

Planerna presenterades i ett blogginlägg på Lambda den 13 oktober 2026. ”Vi välkomnar NVIDIAs beslut att göra Run:ai till öppen källkod, och vi arbetar för att göra det till ett förstahandsval i Lambda Kubernetes Service (LKS)”, uppgav företaget. Lambda sade att företaget har gett stöd för Run:ai på sin infrastruktur sedan 2022 och beskrev målet som att göra det enklare att införa och driva Run:ai-funktionerna via LKS, så att teamen får större kontroll över hur GPU-kapacitet fördelas och delas.

NVIDIA gjorde schemaläggaren till öppen källkod 2025

NVIDIA tillkännagav att KAI Scheduler, en Kubernetes-baserad lösning för schemaläggning av GPU:er som ursprungligen utvecklades inom Run:ai-plattformen, släpptes som öppen källkod under licensen Apache 2.0 den 1 april 2025, enligt NVIDIAs tillkännagivande. NVIDIA uppgav att schemaläggaren fortfarande paketeras och levereras som en del av NVIDIA Run:ai-plattformen.

Enligt NVIDIA räknar schemaläggaren löpande om värdena för rättvis fördelning och justerar kvoter och begränsningar i realtid. Den kombinerar gang-schemaläggning, delning av GPU:er och hierarkisk köhantering, medan en inbyggd podgrupperare automatiskt kopplar samman arbetslaster med ramverk som Kubeflow, Ray, Argo och Training Operator. NVIDIA beskriver en schemaläggningscykel där en ögonblicksbild av Kubernetes-klustret tas, en rättvis andel beräknas för varje kö genom faser med tilldelade kvoter och resurser över kvotgränsen, och åtgärderna tilldela, konsolidera, återta och föregripa sedan används för att anpassa de aktuella tilldelningarna till det beräknade läget.

Delning av GPU:er och kvotbaserad schemaläggning i Run:ai

Lambda beskrev de varierande krav som AI-utveckling ställer på GPU:er: felsökningssessioner kan behöva bara en del av en GPU, utvärderingar kan förgrenas till många oberoende jobb och distribuerad träning kan kräva ett stort antal tätt sammankopplade GPU:er samtidigt. Kraven förändras dessutom när arbetet går från tidiga idéer via experiment till produktion. När små jobb får tillgång till hela GPU:er får forskarna vänta medan reserverad kapacitet står oanvänd, och team kan upptäcka att deras experiment fastnar bakom en annan grupps reserverade men inaktiva GPU:er.

Så som Lambda beskriver det är Run:ai en schemaläggare för GPU:er i Kubernetes som går längre än Kubernetes standardschemaläggare på två sätt: delning av GPU:er, vilket gör att flera arbetslaster kan köras på samma GPU, och kvotbaserad schemaläggning, som ger varje team en garanterad tilldelning samtidigt som teamen kan låna oanvänd kapacitet av varandra.

NVIDIAs dokumentation om GPU-fraktioner anger att fraktioner delar upp GPU-minnet i mindre delar som flera arbetslaster kan dela på. Den begärda minnesmängden för varje arbetslast upprätthålls, så att den inte kan överskrida sin begäran eller inkräkta på en annan arbetslasts minne. Varje pod får ett eget, separat virtuellt adressutrymme för minnet, en lösning som dokumentationen kallar en ”logisk GPU”.

Enligt dokumentationen använder fraktioner som standard NVIDIAs tidsdelning för att dela på GPU-beräkningskapaciteten. Fraktioner med flera GPU:er tilldelar samma fraktionsstorlek på flera GPU:er i en och samma nod: en modell som använder 8 GPU:er och behöver 40 GB minne per GPU kan till exempel tilldelas 8×40 GB i stället för hela minnet på varje GPU, vilket lämnar 40 GB på varje GPU tillgängligt för andra arbetslaster på noden. Dokumentationen påpekar att GPU-fraktioner och läget Multi-Instance GPU (MIG) inte kan användas på samma nod.

NVIDIAs dokumentation om schemaläggningskoncept anger att varje nyskapad pod tilldelas en podgrupp och att gang-schemaläggning innebär att en arbetslast som består av flera poddar antingen schemaläggs helt eller förblir helt väntande. En schemaläggningskö skapas för varje projekt och avdelning i varje nodpool. Tilldelade kvoter begränsar vilka arbetslaster som inte kan föregripas får köra, medan resurser över kvotgränsen endast är tillgängliga för arbetslaster som kan föregripas. Schemaläggaren beräknar ett värde för rättvis andel för varje projekt och avdelning i varje nodpool. När en kö ligger under sin rättvisa andel och en annan överskrider sin flyttar schemaläggaren resurser mellan köerna för att återställa balansen. Denna process kan innebära att arbetslaster som kan föregripas och använder resurser över kvotgränsen avbryts. Schemaläggaren kan också återta resurser mellan projekt och avdelningar, och administratörer kan ange strategier för tät packning eller spridd placering i varje nodpool.

Automatisk återställning av noder i LKS

Lambda påpekade att både delning och föregripande av arbetslaster förutsätter att den underliggande GPU:n fungerar som den ska, något som inte kan tas för givet i stor skala: acceleratorer drabbas av XID-fel, NVLink- och PCIe-länkar försämras, minnesrader mappas om och InfiniBand-portar sjunker under sin förväntade hastighet. En schemaläggare kan inte skilja en fungerande GPU från en som håller på att fallera och fortsätter därför att skicka jobb till en nod som tappar dem.

Lambda uppgav att automatisk felåtgärd redan är tillgänglig i LKS. Företaget sade att det övervakar varje nod för sådana fel och redovisar varje fel som ett standardvillkor för Kubernetes-noder. När ett villkor utlöses spärras noden för nya jobb, pågående jobb dräneras och felet åtgärdas antingen automatiskt eller eskaleras till en hårdvarureparation. Noden återgår till drift först efter att den har validerats på nytt.

Lambdas dokumentation om hanterad Kubernetes beskriver tjänsten som en Kubernetes-miljö med stöd för GPU och InfiniBand (RDMA) samt delad beständig lagring på alla noder i ett 1-Click Cluster. NVIDIA GPU Operator och NVIDIA Network Operator är förinstallerade, och tjänsten utför fortlöpande valideringar för att kontrollera att GPU:er, nätverk och lagring fungerar som de ska. Den åtgärdar också automatiskt problem med noder för att upptäcka och återställa efter maskinvarufel.

Färdplanen för biblioteket med hanterade schemaläggare

Lambda beskrev GPU-schemaläggning som det lager de medvetet lämnar öppet och sade att LKS nu går vidare mot det företaget kallar ett bibliotek med AI-programvara: schemaläggare som körs på Kubernetes, däribland Slurm och Run:ai, levererade som hanterade komponenter som Lambda validerar mot sin egen maskinvara och håller uppdaterade, i stället för att kunderna själva sätter ihop dem från Helm-diagram. Run:ai är ett av bibliotekets främsta mål, och Lambda sade att företaget arbetar med NVIDIA för att nå dit.

Enligt Lambda är det öppen källkod som möjliggör detta arbetssätt: företaget kan paketera, testa och underhålla Run:ai direkt i LKS i stället för att överlämna en uppsättning integrationsanvisningar till kunderna. Lambda sade att företaget siktar på en färdig integration som fungerar direkt, där Lambda ansvarar för paketering, validering och löpande drift.

Lambda, som bedriver egen öppen forskning, sade att företaget värdesätter möjligheten att granska, anpassa och förbättra de verktyg det är beroende av och beskrev NVIDIAs beslut som ett sätt att utvidga den friheten till orkestrering.