Lambda klargjør Run:ai-planleggeren med åpen kildekode for Kubernetes-tjenesten

Lambda opplyste 13. oktober 2026 at selskapet samarbeider med NVIDIA for å gjøre den åpne GPU-planleggeren Run:ai til et førsteklasses administrert alternativ på Lambda Kubernetes Service (LKS), som inngår i et planlagt bibliotek med planleggere levert som administrerte komponenter.

Planene ble omtalt i et innlegg på Lambdas blogg 13. oktober 2026. «Vi ønsker NVIDIAs beslutning om å gjøre Run:ai til åpen kildekode velkommen, og vi arbeider for å gjøre løsningen til et førsteklasses alternativ på Lambda Kubernetes Service (LKS)», uttalte selskapet. Lambda opplyste at selskapet har støttet Run:ai på infrastrukturen sin siden 2022, og beskrev målet som å gjøre det enklere å ta i bruk og drifte Run:ai-funksjonene gjennom LKS, slik at team får større kontroll over hvordan GPU-kapasiteten fordeles og deles.

NVIDIA gjorde planleggeren til åpen kildekode i 2025

NVIDIA kunngjorde at KAI Scheduler, en Kubernetes-basert GPU-planleggingsløsning som opprinnelig ble utviklet som en del av Run:ai-plattformen, ble utgitt som åpen kildekode under Apache 2.0-lisensen 1. april 2025, ifølge NVIDIAs kunngjøring. NVIDIA opplyste at planleggeren fortsatt pakkes og leveres som en del av NVIDIA Run:ai-plattformen.

Ifølge NVIDIA beregner planleggeren løpende verdier for rettferdig ressursfordeling og justerer kvoter og grenser i sanntid. Den kombinerer gang-planlegging, GPU-deling og hierarkisk køstyring, mens en innebygd pod-grupperer automatisk kobler arbeidslaster til rammeverk som Kubeflow, Ray, Argo og Training Operator. NVIDIA beskriver en planleggingssyklus som tar et øyeblikksbilde av Kubernetes-klyngen, beregner en rettferdig andel for hver kø gjennom fasene for tildelt kvote og ressurser utover kvoten, og deretter utfører handlingene tildeling, konsolidering, tilbakehenting og forebyggende avbrytelse for å bringe de gjeldende tildelingene i samsvar med den beregnede tilstanden.

GPU-deling og kvotebasert planlegging i Run:ai

Lambda beskrev de ulike kravene AI-utvikling stiller til GPU-er: Feilsøkingsøkter trenger kanskje bare en del av én GPU, evalueringer kan fordeles på mange uavhengige jobber, og distribuert trening kan kreve mange tett sammenkoblede GPU-er samtidig. Behovene endrer seg etter hvert som arbeidet går fra tidlige ideer via eksperimenter til produksjon. Når små jobber får tildelt hele GPU-er, må forskere vente mens reservert kapasitet står ubrukt, og team kan oppleve at eksperimentene deres blir stående fast bak GPU-er som er reservert av en annen gruppe, men ikke i bruk.

Slik Lambda beskriver det, er Run:ai en GPU-planlegger for Kubernetes som går lenger enn Kubernetes’ standardplanlegger på to måter: GPU-deling, som lar mer enn én arbeidslast kjøre på én GPU, og kvotebasert planlegging, som gir hvert team en garantert tildeling og samtidig lar teamene låne ubrukt kapasitet av hverandre.

NVIDIAs dokumentasjon om GPU-fraksjoner forklarer at fraksjoner deler GPU-minnet inn i mindre deler som flere arbeidslaster kan dele. Hver arbeidslast får håndhevet den forespurte minnestørrelsen, slik at den verken kan bruke mer enn den har bedt om eller ta minne fra en annen arbeidslast. Hver pod får sitt eget, separate virtuelle adresserom for minnet – en ordning dokumentasjonen kaller en «logisk GPU».

Ifølge dokumentasjonen bruker fraksjoner som standard NVIDIAs tidsdeling for å dele GPU-ens regnekapasitet. Fraksjoner med flere GPU-er tildeler samme fraksjonsstørrelse på tvers av flere GPU-er i én node: En modell som bruker 8 GPU-er og trenger 40 GB minne per GPU, kan for eksempel få tildelt 8×40 GB i stedet for hele minnet på hver GPU. Dermed blir 40 GB på hver GPU tilgjengelig for andre arbeidslaster på noden. Dokumentasjonen påpeker at GPU-fraksjoner og Multi-Instance GPU (MIG)-modus ikke kan brukes på samme node.

NVIDIAs dokumentasjon om planleggerkonsepter opplyser at hver nyopprettede pod blir tilordnet en podgruppe, og at gang-planlegging innebærer at en arbeidslast bestående av flere podder enten planlegges fullt ut eller forblir helt uplanlagt. Det opprettes en planleggingskø for hvert prosjekt og hver avdeling i hver nodepool. Tildelte kvoter setter grenser for hvilke arbeidslaster som ikke kan avbrytes, mens ressurser utover kvoten bare er tilgjengelige for arbeidslaster som kan avbrytes. Planleggeren beregner en verdi for rettferdig andel for hvert prosjekt og hver avdeling i hver nodepool. Når én kø ligger under sin rettferdige andel mens en annen overskrider sin, flytter planleggeren ressurser mellom køene for å gjenopprette balansen. Denne prosessen kan føre til at arbeidslaster som kan avbrytes, og som bruker ressurser utover kvoten, blir avbrutt. Planleggeren kan også hente tilbake ressurser mellom prosjekter og avdelinger, og administratorer kan velge strategier for enten tett pakking eller spredning av plasseringer i hver nodepool.

Automatisk utbedring av noder i LKS

Lambda påpekte at både deling og forebyggende avbrytelse forutsetter at den underliggende GPU-en fungerer som den skal, noe som ikke kan tas for gitt i stor skala: Akseleratorer får XID-feil, NVLink- og PCIe-forbindelser svekkes, minnerader omtilordnes, og InfiniBand-porter faller under forventet hastighet. En planlegger kan ikke skille mellom en GPU som fungerer som den skal, og en GPU som svikter, og fortsetter derfor å sende jobber til en node som avviser dem.

Lambda opplyste at automatisk utbedring allerede er tilgjengelig i LKS. Selskapet sa at det overvåker alle noder for slike feil og viser hver feil som en standardtilstand for en Kubernetes-node. Når en slik tilstand utløses, sperres noden for nye arbeidslaster, jobber som kjører, tømmes fra noden, og feilen rettes enten automatisk eller sendes videre til maskinvarereparasjon. Noden tas ikke i bruk igjen før den er validert på nytt.

Lambdas dokumentasjon for administrert Kubernetes beskriver tjenesten som et Kubernetes-miljø med støtte for GPU og InfiniBand (RDMA) samt delt, persistent lagring på tvers av alle noder i en 1-Click Cluster. NVIDIA GPU Operator og NVIDIA Network Operator er forhåndsinstallert, og tjenesten utfører kontinuerlig validering for å kontrollere at GPU-er, nettverk og lagring fungerer som de skal. I tillegg utbedres feil på noder automatisk, slik at maskinvareproblemer oppdages og løses.

Veikart for biblioteket med administrerte planleggere

Lambda beskrev GPU-planlegging som laget selskapet bevisst lar være å lukke, og sa at LKS nå går videre mot det selskapet kaller et programvarebibliotek for KI: planleggere som kjører på Kubernetes, blant dem Slurm og Run:ai. Disse leveres som administrerte komponenter som Lambda validerer mot sin egen maskinvare og holder oppdatert, i stedet for at kundene setter dem sammen manuelt fra Helm-diagrammer. Run:ai er et hovedmål for dette biblioteket, og Lambda sa at selskapet samarbeider med NVIDIA for å få det til.

Ifølge Lambda er det åpen kildekode-utgivelsen som gjør denne tilnærmingen mulig: Selskapet kan pakke, teste og vedlikeholde Run:ai direkte i LKS, i stedet for å overlate kundene et sett med integrasjonsinstruksjoner. Lambda sa at selskapet sikter mot en integrasjon som fungerer rett ut av esken, der Lambda selv står for pakking, validering og løpende drift.

Lambda, som selv publiserer åpen forskning, sa at selskapet setter pris på muligheten til å undersøke, tilpasse og forbedre verktøyene det er avhengig av, og beskrev NVIDIAs beslutning som en utvidelse av denne friheten til orkestrering.