Lambda prepara lo scheduler open source Run:ai per il servizio Kubernetes

Il 13 ottobre 2026 Lambda ha dichiarato di collaborare con NVIDIA per rendere lo scheduler GPU open source Run:ai un’opzione gestita di primo piano su Lambda Kubernetes Service (LKS), nell’ambito di una libreria pianificata di scheduler forniti come componenti gestiti.

Il piano è stato illustrato in un post del 13 ottobre 2026 sul blog di Lambda. «Accogliamo con favore la decisione di NVIDIA di rendere Run:ai open source e stiamo lavorando per farne un’opzione di primo piano su Lambda Kubernetes Service (LKS)», ha dichiarato l’azienda. Lambda ha affermato di supportare Run:ai sulla propria infrastruttura dal 2022 e ha descritto il proprio obiettivo: rendere più semplice adottare e gestire le funzionalità di Run:ai tramite LKS, così che i team possano avere un maggiore controllo sull’allocazione e la condivisione della capacità GPU.

NVIDIA ha reso lo scheduler open source nel 2025

Il 1° aprile 2025 NVIDIA ha annunciato il rilascio open source di KAI Scheduler, una soluzione di pianificazione GPU nativa per Kubernetes sviluppata originariamente nell’ambito della piattaforma Run:ai, con licenza Apache 2.0, secondo l’annuncio di NVIDIA. NVIDIA ha dichiarato che lo scheduler continua a essere distribuito come parte della piattaforma NVIDIA Run:ai.

Secondo NVIDIA, lo scheduler ricalcola continuamente i valori di quota equa e adegua in tempo reale quote e limiti, combinando la pianificazione di gruppi di job, la condivisione delle GPU e le code gerarchiche; inoltre, un componente integrato per il raggruppamento dei pod associa automaticamente i carichi di lavoro a framework come Kubeflow, Ray, Argo e Training Operator. NVIDIA descrive un ciclo di pianificazione che acquisisce un’istantanea del cluster Kubernetes, calcola una quota equa per ogni coda attraverso le fasi di quota spettante e di superamento della quota, quindi applica le azioni di allocazione, consolidamento, recupero e prelazione per allineare le allocazioni correnti allo stato calcolato.

Condivisione delle GPU e pianificazione basata sulle quote in Run:ai

Lambda ha descritto le diverse esigenze che lo sviluppo dell’IA impone alle GPU: le sessioni di debug possono richiedere solo una parte di una GPU, le valutazioni possono diramarsi in molti job indipendenti e l’addestramento distribuito può richiedere simultaneamente un gran numero di GPU strettamente interconnesse. Le esigenze cambiano man mano che il lavoro passa dalle prime idee agli esperimenti e poi alla produzione. Quando ai job di piccole dimensioni vengono assegnate GPU intere, i ricercatori restano in attesa mentre la capacità riservata rimane inutilizzata; inoltre, i team possono ritrovarsi con gli esperimenti bloccati dietro alle GPU riservate ma inattive di un altro gruppo.

Come la descrive Lambda, Run:ai è uno scheduler GPU per Kubernetes che amplia le funzionalità dello scheduler Kubernetes predefinito in due modi: con la condivisione delle GPU, che consente a più di un carico di lavoro di essere eseguito su una singola GPU, e con la pianificazione basata sulle quote, che garantisce a ogni team una determinata allocazione e permette ai team di prendere in prestito reciprocamente la capacità inutilizzata.

La documentazione sulle frazioni di GPU di NVIDIA spiega che le frazioni suddividono la memoria della GPU in blocchi più piccoli, condivisibili tra più carichi di lavoro; la quantità di memoria richiesta da ciascun carico viene fatta rispettare, così che non possa superare la richiesta né invadere la memoria assegnata a un altro carico. Ogni pod riceve un proprio spazio di indirizzamento della memoria virtuale, una configurazione che la documentazione definisce «GPU logica».

Secondo la documentazione, per impostazione predefinita le frazioni utilizzano il time-slicing di NVIDIA per condividere le risorse di calcolo della GPU. Le frazioni multi-GPU assegnano la stessa dimensione di frazione a più GPU all’interno di un singolo nodo: per esempio, a un modello che usa 8 GPU e richiede 40GB di memoria per GPU possono essere assegnati 8×40GB anziché l’intera memoria di ciascuna GPU, lasciando 40GB su ogni GPU disponibili per altri carichi di lavoro sul nodo. La documentazione specifica che le frazioni di GPU e la modalità Multi-Instance GPU (MIG) non possono essere utilizzate sullo stesso nodo.

La documentazione sui concetti alla base dello scheduler di NVIDIA spiega che a ogni pod appena creato viene assegnato un gruppo di pod e che la pianificazione di gruppi di job fa sì che un carico di lavoro composto da più pod venga pianificato interamente oppure resti interamente in attesa. Per ogni progetto e reparto viene creata una coda per ciascun pool di nodi; le quote spettanti delimitano i carichi di lavoro non soggetti a prelazione che possono essere eseguiti, mentre le risorse oltre quota sono disponibili solo per i carichi di lavoro soggetti a prelazione. Lo scheduler calcola un valore di quota equa per ogni progetto e reparto in ciascun pool di nodi; quando una coda si trova al di sotto della propria quota equa e un’altra la supera, lo scheduler sposta risorse da una coda all’altra per riequilibrare la situazione, un processo che può comportare la prelazione di carichi di lavoro oltre quota soggetti a prelazione. Può anche recuperare risorse tra progetti e reparti; gli amministratori possono inoltre impostare, per ciascun pool di nodi, strategie di collocazione basate sul raggruppamento dei carichi o sulla loro distribuzione.

Ripristino automatico dei nodi in LKS

Lambda ha osservato che sia la condivisione sia la prelazione presuppongono che la GPU sottostante funzioni correttamente, ma che, su larga scala, non è affatto scontato: gli acceleratori generano errori XID, i collegamenti NVLink e PCIe si deteriorano, le righe di memoria vengono rimappate e le porte InfiniBand scendono al di sotto della velocità prevista. Uno scheduler non è in grado di distinguere una GPU funzionante da una in avaria e continua quindi a inviare job a un nodo che li interrompe.

Lambda ha dichiarato che il ripristino automatico è già disponibile in LKS. L’azienda ha spiegato di monitorare ogni nodo per individuare guasti di questo tipo e di segnalarli tramite una condizione standard del nodo Kubernetes; quando si attiva una condizione, il nodo viene escluso dall’assegnazione di nuovi carichi, i job in esecuzione vengono evacuati e il guasto viene corretto automaticamente oppure segnalato per la riparazione dell’hardware. Il nodo torna in servizio solo dopo aver superato una nuova verifica.

La documentazione di Lambda su Kubernetes gestito descrive il servizio come un ambiente Kubernetes con supporto per GPU e InfiniBand (RDMA) e storage persistente condiviso tra tutti i nodi di un cluster 1-Click. NVIDIA GPU Operator e NVIDIA Network Operator sono preinstallati; inoltre, il servizio esegue controlli continui per verificare il corretto funzionamento di GPU, rete e storage, insieme a interventi automatici sui nodi per rilevare e risolvere i problemi hardware.

La roadmap della libreria di pianificazione gestita

Lambda ha descritto la pianificazione delle GPU come il livello che lascia deliberatamente aperto e ha affermato che il prossimo passo per LKS sarà quello che definisce una libreria software per l’IA: pianificatori che funzionano su Kubernetes, tra cui Slurm e Run:ai, distribuiti come componenti gestiti che Lambda convalida sul proprio hardware e mantiene aggiornati, invece di lasciare che i clienti li assemblino manualmente a partire da chart Helm. Run:ai è un componente di primo piano di questa libreria e Lambda ha dichiarato di collaborare con NVIDIA per realizzarla.

Secondo Lambda, il rilascio open source è ciò che rende possibile questo approccio: l’azienda può integrare, testare e mantenere Run:ai direttamente in LKS, anziché fornire ai clienti una serie di istruzioni per l’integrazione. Lambda ha dichiarato di puntare a un’integrazione pronta all’uso, di cui si occuperà direttamente per quanto riguarda l’integrazione, la convalida e la gestione continuativa.

Lambda, che conduce attività di ricerca aperta, ha dichiarato di apprezzare la possibilità di esaminare, adattare e migliorare gli strumenti da cui dipende e ha descritto la decisione di NVIDIA come un’estensione di questa libertà all’orchestrazione.