Lambda prépare le planificateur open source Run:ai pour son service Kubernetes

Le 13 octobre 2026, Lambda a déclaré travailler avec NVIDIA pour faire du planificateur de GPU Run:ai, désormais open source, une option gérée de premier plan dans Lambda Kubernetes Service (LKS), dans le cadre d’une bibliothèque de planificateurs prévue et fournie sous forme de composants gérés.

Le projet a été présenté dans un article publié le 13 octobre 2026 sur le blog de Lambda. « Nous saluons la décision de NVIDIA de rendre Run:ai open source et travaillons à en faire une option de premier plan dans Lambda Kubernetes Service (LKS) », a déclaré l’entreprise. Lambda a indiqué qu’elle prend en charge Run:ai sur son infrastructure depuis 2022 et a expliqué que son objectif est de faciliter l’adoption et l’exploitation des capacités de Run:ai par l’intermédiaire de LKS, afin que les équipes puissent mieux contrôler la répartition et le partage de la capacité GPU.

NVIDIA a rendu le planificateur open source en 2025

NVIDIA a annoncé le 1er avril 2025 la publication sous licence Apache 2.0 du KAI Scheduler, une solution de planification GPU native de Kubernetes développée à l’origine au sein de la plateforme Run:ai, selon l’annonce de NVIDIA. NVIDIA a précisé que le planificateur continue d’être intégré et fourni dans le cadre de la plateforme NVIDIA Run:ai.

Selon NVIDIA, le planificateur recalcule en continu les valeurs de partage équitable et ajuste les quotas et les limites en temps réel. Il combine la planification par groupes, le partage des GPU et la mise en file d’attente hiérarchique. Un regroupement automatique des pods, intégré au système, associe les charges de travail à des infrastructures logicielles telles que Kubeflow, Ray, Argo et Training Operator. NVIDIA décrit un cycle de planification qui prend un instantané du cluster Kubernetes, calcule une part équitable pour chaque file d’attente en passant par des phases de quotas attribués et de dépassement de quota, puis applique des actions d’allocation, de consolidation, de récupération et de préemption afin d’aligner les allocations en cours sur l’état calculé.

Partage des GPU et planification par quotas dans Run:ai

Lambda a décrit la diversité des besoins en GPU liés au développement de l’IA : les sessions de débogage peuvent ne nécessiter qu’une partie d’un GPU, les évaluations peuvent se répartir entre de nombreux travaux indépendants, et l’entraînement distribué peut exiger simultanément un grand nombre de GPU étroitement interconnectés. Les besoins évoluent à mesure que le travail passe des premières idées aux expérimentations, puis à la production. Lorsque de petites tâches se voient attribuer des GPU entiers, les chercheurs doivent attendre tandis que des capacités réservées restent inutilisées, et les équipes peuvent voir leurs expérimentations bloquées derrière les GPU réservés mais inactifs d’un autre groupe.

Selon la description de Lambda, Run:ai est un planificateur de GPU pour Kubernetes qui va au-delà du planificateur Kubernetes par défaut de deux façons : le partage des GPU, qui permet à plusieurs charges de travail de s’exécuter sur un même GPU, et la planification par quotas, qui garantit une allocation à chaque équipe tout en permettant aux équipes d’emprunter les capacités inutilisées des autres.

La documentation de NVIDIA sur les fractions de GPU indique que les fractions divisent la mémoire du GPU en blocs plus petits que plusieurs charges de travail peuvent partager. La quantité de mémoire demandée par chaque charge de travail est imposée : elle ne peut ni dépasser la demande ni empiéter sur la mémoire d’une autre charge de travail. Chaque pod reçoit son propre espace d’adressage de mémoire virtuelle, une configuration que la documentation appelle un « GPU logique ».

Selon la documentation, les fractions utilisent par défaut le partage du calcul GPU par tranches de temps de NVIDIA. Les fractions multi-GPU attribuent la même taille de fraction à plusieurs GPU au sein d’un même nœud : par exemple, un modèle qui utilise 8 GPU et nécessite 40 Go de mémoire par GPU peut se voir allouer 8×40 Go au lieu de la mémoire totale de chaque GPU, ce qui laisse 40 Go disponibles sur chaque GPU pour d’autres charges de travail sur ce nœud. La documentation précise qu’il n’est pas possible d’utiliser les fractions de GPU et le mode Multi-Instance GPU (MIG) sur un même nœud.

La documentation de NVIDIA sur les concepts de planification indique que chaque pod nouvellement créé est affecté à un groupe de pods et que la planification par groupes signifie qu’une charge de travail composée de plusieurs pods est soit entièrement planifiée, soit entièrement en attente. Une file de planification est créée pour chaque projet et chaque service dans chaque pool de nœuds ; les quotas attribués limitent les charges de travail non préemptibles pouvant s’exécuter, tandis que les ressources au-delà des quotas sont réservées aux charges de travail préemptibles. Le planificateur calcule une valeur de part équitable pour chaque projet et chaque service dans chaque pool de nœuds. Lorsqu’une file se situe sous sa part équitable et qu’une autre la dépasse, il transfère des ressources entre les files pour rééquilibrer la répartition ; ce processus peut entraîner la préemption de charges de travail préemptibles dépassant leur quota. Il peut également récupérer des ressources entre projets et services, et les administrateurs peuvent définir, pour chaque pool de nœuds, des stratégies de placement privilégiant le regroupement ou la dispersion.

Remédiation automatique des nœuds dans LKS

Lambda a souligné que le partage et la préemption supposent tous deux que le GPU sous-jacent fonctionne correctement, ce qui n’est pas acquis à grande échelle : les accélérateurs génèrent des erreurs XID, les liaisons NVLink et PCIe se dégradent, des lignes de mémoire sont réaffectées et le débit des ports InfiniBand passe sous le niveau attendu. Un planificateur ne peut pas distinguer un GPU en bon état d’un GPU défaillant ; il continue donc d’envoyer des tâches vers un nœud qui les abandonne.

Lambda a déclaré que la remédiation automatique est déjà déployée dans LKS. L’entreprise a indiqué qu’elle surveille chaque nœud afin de détecter ce type de défaillance et signale chacune d’elles sous la forme d’un état standard de nœud Kubernetes. Lorsqu’un état est déclenché, le nœud est mis en quarantaine pour empêcher le lancement de nouvelles tâches, les tâches en cours sont évacuées, puis la défaillance est soit corrigée automatiquement, soit transmise au service de réparation matérielle. Le nœud n’est remis en service qu’après une nouvelle validation.

La documentation de Lambda sur Kubernetes géré décrit le service comme un environnement Kubernetes prenant en charge les GPU et InfiniBand (RDMA), ainsi qu’un stockage persistant partagé entre tous les nœuds d’un cluster 1-Click. NVIDIA GPU Operator et NVIDIA Network Operator sont préinstallés. Le service effectue également des validations continues pour vérifier le bon fonctionnement des GPU, du réseau et du stockage, et remédie automatiquement aux problèmes matériels en détectant les défaillances et en rétablissant le fonctionnement des nœuds.

La feuille de route de la bibliothèque de planificateurs gérés

Lambda a présenté la planification des GPU comme la couche qu’elle choisit délibérément de laisser ouverte et a indiqué que la prochaine étape pour LKS consiste à évoluer vers ce qu’elle appelle une bibliothèque logicielle d’IA : des planificateurs fonctionnant sur Kubernetes, notamment Slurm et Run:ai, proposés sous forme de composants gérés que Lambda valide sur son propre matériel et maintient à jour, au lieu de laisser les clients les assembler eux-mêmes à partir de charts Helm. Run:ai est une cible de premier plan pour cette bibliothèque, et Lambda a déclaré travailler avec NVIDIA pour y parvenir.

Selon Lambda, la publication en open source rend cette approche possible : l’entreprise peut intégrer Run:ai à LKS, le tester et le maintenir elle-même, plutôt que de remettre aux clients un ensemble d’instructions d’intégration. Lambda a déclaré viser une intégration prête à l’emploi, dont elle prendrait en charge le conditionnement, la validation et l’exploitation continue.

Lambda, qui publie ses propres travaux de recherche en accès libre, a déclaré tenir à pouvoir examiner, adapter et améliorer les outils dont elle dépend, et a présenté la décision de NVIDIA comme une extension de cette liberté à l’orchestration.