Lambda pregătește schedulerul open-source Run:ai pentru serviciul Kubernetes

Pe 13 octombrie 2026, Lambda a anunțat că lucrează cu NVIDIA pentru a transforma schedulerul GPU Run:ai, devenit open-source, într-o opțiune gestionată de prim rang în Lambda Kubernetes Service (LKS), ca parte a unei biblioteci planificate de schedulere furnizate drept componente gestionate.

Planul a fost prezentat într-o postare de pe blogul Lambda din 13 octombrie 2026. „Salutăm decizia NVIDIA de a transforma Run:ai în open-source și lucrăm pentru a-l face o opțiune de prim rang în Lambda Kubernetes Service (LKS)”, a declarat compania. Lambda a spus că oferă suport pentru Run:ai pe infrastructura sa din 2022 și și-a descris obiectivul ca fiind acela de a facilita adoptarea și operarea capabilităților Run:ai prin LKS, astfel încât echipele să aibă mai mult control asupra modului în care este alocată și partajată capacitatea GPU.

NVIDIA a transformat schedulerul în open-source în 2025

NVIDIA a anunțat lansarea open-source a KAI Scheduler, o soluție de programare GPU nativă pentru Kubernetes, dezvoltată inițial în cadrul platformei Run:ai și distribuită sub licența Apache 2.0 la 1 aprilie 2025, potrivit anunțului NVIDIA. NVIDIA a precizat că schedulerul continuă să fie împachetat și distribuit ca parte a platformei NVIDIA Run:ai.

Potrivit NVIDIA, schedulerul recalculează permanent valorile cotelor echitabile și ajustează cotele și limitele în timp real, combinând programarea în grup (gang scheduling), partajarea GPU-urilor și cozile ierarhice; între timp, componenta integrată podgrouper conectează automat sarcinile de lucru la cadre de lucru precum Kubeflow, Ray, Argo și Training Operator. NVIDIA descrie un ciclu de programare care surprinde o imagine a clusterului Kubernetes, calculează o cotă echitabilă pentru fiecare coadă prin etapele cotelor cuvenite și ale resurselor peste cotă, apoi aplică acțiuni de alocare, consolidare, recuperare și preempțiune pentru a alinia alocările curente la starea calculată.

Partajarea GPU-urilor și programarea pe bază de cote în Run:ai

Lambda a descris cerințele variate pe care dezvoltarea AI le impune GPU-urilor: sesiunile de depanare pot avea nevoie doar de o parte dintr-un GPU, evaluările se pot extinde la numeroase sarcini independente, iar antrenarea distribuită poate necesita simultan un număr mare de GPU-uri strâns interconectate; în plus, cerințele se schimbă pe măsură ce activitatea trece de la ideile inițiale la experimente și apoi la producție. Când sarcinile mici primesc GPU-uri întregi, cercetătorii așteaptă, în timp ce capacitatea rezervată rămâne nefolosită, iar echipele se pot trezi cu experimentele blocate în spatele GPU-urilor rezervate, dar inactive, ale altei echipe.

Așa cum îl descrie Lambda, Run:ai este un scheduler GPU pentru Kubernetes care extinde funcționalitatea schedulerului Kubernetes implicit în două privințe: prin partajarea GPU-urilor, care permite rularea mai multor sarcini de lucru pe un singur GPU, și prin programarea pe bază de cote, care garantează o alocare pentru fiecare echipă, permițând totodată echipelor să împrumute reciproc capacitatea nefolosită.

Documentația NVIDIA privind fracțiunile GPU precizează că fracțiunile împart memoria GPU în segmente mai mici, care pot fi partajate de mai multe sarcini de lucru, iar dimensiunea de memorie solicitată de fiecare sarcină este impusă astfel încât aceasta să nu poată depăși cererea proprie și nici să ocupe memoria alocată altei sarcini. Fiecare pod primește propriul spațiu separat de adrese pentru memoria virtuală, configurație pe care documentația o numește „GPU logic”.

Potrivit documentației, fracțiunile folosesc implicit tehnica NVIDIA de partajare în timp (time-slicing) pentru a partaja capacitatea de calcul a GPU-urilor, iar fracțiunile multi-GPU alocă aceeași dimensiune a fracțiunii pe mai multe GPU-uri dintr-un singur nod: de exemplu, un model care folosește 8 GPU-uri și necesită 40 GB de memorie per GPU poate primi 8×40 GB, în locul memoriei complete a fiecărui GPU, lăsând 40 GB pe fiecare GPU la dispoziția altor sarcini de lucru de pe acel nod. Documentația menționează că fracțiunile GPU și modul Multi-Instance GPU (MIG) nu pot fi folosite pe același nod.

Documentația NVIDIA despre conceptele schedulerului precizează că fiecare pod nou creat este atribuit unui grup de poduri și că programarea în grup (gang scheduling) înseamnă că o sarcină de lucru alcătuită din mai multe poduri este fie programată în întregime, fie rămâne în întregime în așteptare. Pentru fiecare proiect și departament se creează o coadă de programare în fiecare grup de noduri; cotele cuvenite limitează sarcinile de lucru care nu pot fi preemptate, în timp ce resursele peste cotă sunt disponibile numai sarcinilor de lucru care pot fi preemptate. Schedulerul calculează o valoare a cotei echitabile pentru fiecare proiect și departament din fiecare grup de noduri, iar când o coadă se situează sub cota sa echitabilă, în timp ce alta o depășește, mută resurse între cozi pentru a restabili echilibrul; acest proces poate duce la preempțiunea sarcinilor de lucru preemptabile care depășesc cota. De asemenea, poate recupera resurse între proiecte și departamente, iar administratorii pot configura strategii de plasare de tip bin-pack sau de distribuire pentru fiecare grup de noduri.

Remedierea automată a nodurilor în LKS

Lambda a remarcat că atât partajarea, cât și preempțiunea presupun că GPU-ul subiacent funcționează corect, lucru care nu este garantat la scară largă: acceleratoarele generează erori XID, conexiunile NVLink și PCIe se degradează, rândurile de memorie sunt remapate, iar porturile InfiniBand funcționează sub rata așteptată. Un scheduler nu poate distinge un GPU sănătos de unul defect, așa că continuă să trimită sarcini către un nod care le întrerupe.

Lambda a spus că funcția de remediere automată este deja disponibilă în LKS. Compania a precizat că monitorizează fiecare nod pentru a detecta astfel de defecțiuni și le expune pe fiecare ca stare standard a unui nod Kubernetes; când o stare este activată, nodul este marcat astfel încât să nu mai primească sarcini noi, sarcinile în curs sunt evacuate, iar defecțiunea este fie remediată automat, fie escaladată către echipa de reparații hardware; nodul revine în serviciu numai după ce trece din nou validarea.

Documentația Lambda pentru Kubernetes gestionat descrie serviciul ca pe un mediu Kubernetes cu suport pentru GPU și InfiniBand (RDMA), precum și cu stocare persistentă partajată între toate nodurile dintr-un cluster 1-Click. NVIDIA GPU Operator și NVIDIA Network Operator sunt preinstalate, iar serviciul efectuează validări continue pentru a verifica dacă GPU-urile, rețeaua și stocarea funcționează corect, precum și remedierea automată a nodurilor, pentru a detecta și a remedia problemele hardware.

Planul de dezvoltare a bibliotecii de planificatoare gestionate

Lambda a descris planificarea GPU-urilor drept stratul pe care îl lasă în mod deliberat deschis și a declarat că următoarea etapă pentru LKS este ceea ce numește o bibliotecă de software pentru IA: planificatoare care rulează pe Kubernetes, printre care Slurm și Run:ai, livrate ca componente gestionate, pe care Lambda le validează pe propriul hardware și le menține actualizate, în loc ca utilizatorii să le asambleze manual din diagrame Helm. Run:ai este o componentă de prim rang a acestei biblioteci, iar Lambda a declarat că lucrează cu NVIDIA pentru a ajunge la acest rezultat.

Potrivit Lambda, lansarea cu sursă deschisă este cea care face posibilă această abordare: compania poate împacheta, testa și întreține Run:ai chiar în LKS, în loc să le ofere clienților un set de instrucțiuni de integrare. Lambda a declarat că își propune o integrare funcțională imediat, în care se ocupă de împachetare, validare și operațiunile curente.

Lambda, care publică propriile cercetări în regim deschis, a declarat că apreciază posibilitatea de a inspecta, adapta și îmbunătăți instrumentele de care depinde și a descris decizia NVIDIA ca pe o extindere a acestei libertăți la orchestrare.