NVIDIA a publié la plateforme complète NVIDIA Run:ai en tant que logiciel open source. Le code source est distribué sous la licence Apache 2.0 sur GitHub. NVIDIA Run:ai open source met l'ordonnancement des GPU en production, les quotas et la gestion des charges de travail entre les mains des développeurs. Cette version fait de Run:ai une partie de la plateforme NVIDIA DSX AI Factory. Les équipes de plateforme peuvent désormais inspecter, forker et auto-héberger la pile sans abonnement payant.
TL;DR
- Taille : Un monorepo avec le plan de contrôle, les services de cluster, l'installateur, la CLI et le serveur MCP. Les builds de développement locaux compilent environ 50 services Go.
- Fonctionne sur : Des clusters Kubernetes ou OpenShift avec des GPU NVIDIA. Le développement local fonctionne sur macOS ou Linux avec 8 GPU Tesla-A10 simulés, sans GPU nécessaire.
- Performance : NVIDIA n'a publié aucun benchmark au niveau de la plateforme pour cette version.
- Points forts : Le Model Streamer associé a chargé les modèles 3x à 6x plus rapidement sur 8 VM NVIDIA H100 sur Azure.
- Points faibles : L'édition communautaire n'a aucun support d'entreprise NVIDIA. Les builds locaux nécessitent 16 Go de RAM et 100 Go de disque sur Linux.
Qu'est-ce que NVIDIA Run:ai ?
NVIDIA Run:ai est une plateforme d'orchestration de charges de travail IA et de GPU pour Kubernetes de NVIDIA. Elle ordonnance les charges de travail de développement, d'entraînement et d'inférence sur des clusters de GPU partagés. Elle fonctionne au-dessus de Kubernetes et ne le remplace pas.
Le plan de contrôle gère la soumission des charges de travail, la gestion des ressources et la surveillance. Les services de cluster s'exécutent sur chaque cluster Kubernetes et ajoutent un ordonnancement conscient des GPU. Les utilisateurs y accèdent via une interface web, une CLI, une API REST et un serveur MCP pour les assistants IA.
Quels sont les 4 composants modulaires ?
NVIDIA a divisé la version en 4 composants que les équipes peuvent adopter indépendamment :
- KAI Scheduler est le moteur d'ordonnancement natif de Kubernetes. Il est sous Apache 2.0 et constitue un projet CNCF Sandbox. Il couvre l'ordonnancement en groupe (gang scheduling), le partage équitable basé sur le temps, la conscience de la topologie, le bin-packing et le support de DRA.
- L'opérateur de fractionnement de GPU (GPU Fractioning Operator) apporte les fractions de GPU natives de CUDA 13.4 à Kubernetes. Le pilote CUDA applique une limite stricte de mémoire par charge de travail. NVIDIA a retiré son ancien fractionnement propriétaire au profit de cette approche. L'opérateur est indépendant de l'ordonnanceur et exporte des métriques par pod.
- KAI Resource Management ajoute les projets, départements, quotas et pools de nœuds. L'exemple de NVIDIA garantit 50% d'un cluster à une équipe de recherche.
- Workload Map est une bibliothèque Go qui décrit les types de charges de travail tels que PyTorchJob, RayCluster et les services KServe. Elle fonctionne hors ligne et n'ordonnance, ne met en file d'attente ni n'autoscale.
Comment les développeurs exécutent-ils NVIDIA Run:ai en local ?
Le guide de développement local repose sur 1 script, local-dev.sh. Il compile une cinquantaine de services Go... environ 50 services Go à partir des sources dans des conteneurs. Il crée ensuite un cluster Kind à 5 nœuds épinglé à Kubernetes v1.32.5. Un faux opérateur GPU simule 8 GPU Tesla-A10, donc aucun matériel GPU n'est requis.
- Hôtes pris en charge : macOS ou Linux, sur amd64 ou arm64. Windows n'est pas pris en charge.
- Les hôtes Linux nécessitent 4 CPU, 16 Go de RAM et 100 Go d'espace disque libre.
- Les VM Podman sous macOS nécessitent au moins 12 Go de RAM.
- 1 build complet laisse environ 44 Go de caches.
Le --gpu-operator drapeau permet de passer à de vrais GPU NVIDIA. Ce mode nécessite Linux, Docker et le NVIDIA Container Toolkit. Les accélérateurs AMD et Intel ne sont pas pris en charge.
Comment les équipes peuvent-elles le déployer en production ?
Les équipes de développement peuvent déployer à partir des sources ou à partir du Helm chart NGC Community Product . Cette édition ne nécessite aucun abonnement payant mais exclut le support enterprise de NVIDIA.
Les équipes peuvent également l'adopter via 8 partenaires de l'écosystème DSX. Ceux-ci sont Crusoe, Mirantis, Nebius, OpenNebula Systems, Rafay, Saturn Cloud, Spectro Cloud et vCluster« Les éditions commerciales prises en charge se poursuivent via NVIDIA AI Enterprise, NVIDIA Mission Control et certaines places de marché cloud. »
Quels projets open source connexes sont livrés en complément ?
Deux projets adjacents complètent l'ensemble. Model Streamer diffuse directement les poids du modèle dans la mémoire GPU. vLLM et SGLang l'activent avec --load-format runai_streamer.
de Microsoft benchmark publié a utilisé 8 VMs NVIDIA H100. Elle a montré un chargement 3x à 6x plus rapide que le loader par défaut. Le débit s'est maintenu à 80 Gbps contre environ 40 Gbps sur le chemin par défaut.
Grove orchestre des charges de travail d'inférence à plusieurs composants. Il démarre des composants tels que le préremplissage (prefill) et le décodage (decode) comme des unités tout ou rien.
Comment NVIDIA Run:ai se compare-t-il aux autres planificateurs Kubernetes open source ?
| Fonctionnalité | NVIDIA Run:ai (open source) | Volcan | Kueue | Apache YuniKorn |
|---|---|---|---|---|
| Licence | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 |
| Gouvernance | NVIDIA DSX AI Factory org (KAI Scheduler : CNCF Sandbox) | CNCF Incubating | kubernetes-sigs (wg-batch) | Apache Software Foundation |
| Périmètre | Plateforme complète : plan de contrôle, UI, CLI, API REST, serveur MCP | Système d'ordonnancement par lots | Contrôleur de file d'attente de jobs | Ordonnanceur, alternative à celui par défaut |
| Remplace kube-scheduler | Non, l'étend avec KAI Scheduler | Non divulgué | Non | Oui, comme alternative |
| Ordonnancement en gang (gang scheduling) | Oui | Oui | Tout ou rien basé sur un délai d'expiration | Oui |
| Hiérarchie de quotas | Projets, départements, pools de nœuds | Files multi-niveaux | Cohortes, partage équitable | Files hiérarchiques |
| Partage de GPU | Fractions natives CUDA 13.4 avec limites strictes de mémoire | vGPU, MIG dynamique | Quota GPU basé sur DRA ; le fractionnement absent de la présentation | Non divulgué |
| Sensible à la topologie | Oui | Oui | Oui | Non divulgué |
| Multi-cluster | Oui, via le plan de contrôle | Oui | Oui, MultiKueue | Non divulgué |
| Interface web | Oui | Projet de tableau de bord séparé | Non divulgué | Non divulgué |
La différence clé réside dans le périmètre. Volcano, Kueue et YuniKorn se concentrent sur l'ordonnancement ou la mise en file d'attente. Run:ai propose une plateforme de gestion complète au-dessus de son ordonnanceur.
Points clés
- NVIDIA Run:ai est désormais entièrement open source sous Apache 2.0.
- 4 composants sont livrés en standalone : KAI Scheduler, GPU Fractioning, Resource Management, Workload Map.
- Le fractionnement GPU utilise désormais l'isolation mémoire native de CUDA 13.4.
- Le développement local s'exécute sur un cluster Kind à 5 nœuds avec 8 GPU simulés.
- L'édition gratuite exclut le support entreprise NVIDIA.
Découvrez le dépôt GitHub, le guide de développement local et le blog technique de NVIDIA. Tout le crédit revient au chercheur de ce projet. De plus, n'hésitez pas à nous suivre sur Twitter et n'oubliez pas de rejoindre notre SubReddit ML de plus de 150k membres et de vous abonner à notre Newsletter. Attendez ! êtes-vous sur telegram ? vous pouvez désormais nous rejoindre également sur telegram.
L'article NVIDIA rend Run:ai open source sous Apache 2.0 pour l'orchestration des GPU sous Kubernetes est apparu en premier sur MarkTechPost.