Une « usine d’IA » ne consiste pas en un seul modèle ou en un cluster Kubernetes unique, mais en un parc partagé d’unités de traitement graphique GPU utilisé simultanément par plusieurs équipes à des fins différentes : réglage fin, exécution de l’inférence et évaluation. Selon un article publié sur le blog de la CNCF, le véritable défi pour les entreprises n’est plus seulement d’entraîner le modèle, mais d’accorder à chaque équipe un accès sécurisé et isolé au même matériel, tout en maintenant un taux d’utilisation élevé des unités GPU et des coûts mesurables.
L’article a été rédigé par Hrittik Roy, en sa qualité d’ambassadeur de la CNCF et de Platform Advocate chez vCluster. Il propose une lecture pratique de la manière dont cet environnement peut être construit au-dessus de Kubernetes. L’idée centrale de l’article est que Kubernetes fournit une base mature pour les conteneurs, le RBAC, la mise à l’échelle automatique et les politiques, mais qu’il a fallu lui adjoindre un écosystème supplémentaire pour gérer les accélérateurs et l’isolation entre locataires sur les mêmes nœuds.
Le goulot d’étranglement est l’utilisation, pas seulement la vitesse d’inférence
Les unités GPU représentent les dépenses d’investissement les plus importantes dans une infrastructure d’IA. Le taux d’utilisation devient donc un indicateur économique plus important que l’atteinte d’une vitesse maximale lors d’une seule exécution. L’article présente deux problèmes principaux : le modèle d’allocation des ressources et le modèle d’isolation.
Dans le modèle traditionnel du device plugin, la charge demande par exemple nvidia.com/gpu: 1 et réserve une unité entière, même si elle n’en utilise que dix pour cent. Le Dynamic Resource Allocation, ou DRA, devenu généralement disponible dans Kubernetes 1.34, permet au planificateur de traiter les accélérateurs comme des appareils dotés de caractéristiques, de mémoire et d’une topologie. Il ne divise toutefois pas automatiquement une unité GPU en parts ; la densité provient de la couche matérielle, comme HAMi, un projet en phase Incubating au sein de la CNCF qui impose des limites logicielles de mémoire et de calcul au niveau du conteneur et prend en charge plusieurs fournisseurs d’accélérateurs.
À l’inverse, attribuer du matériel distinct à chaque équipe peut offrir une isolation forte, mais laisse une grande partie de la capacité inutilisée. L’article distingue donc l’allocation d’une unité entière lorsque les limites de confiance sont strictes, et le partitionnement de l’unité au sein d’un même domaine de confiance afin d’augmenter la densité. NVIDIA MIG fournit une isolation de la mémoire et des pannes au niveau matériel, mais l’article souligne que son utilisation comme séparation entre locataires hostiles fait encore débat ; l’allocation de GPU entières reste donc l’option prudente dans les situations de faible confiance.
Les couches de l’usine, du matériel à la charge
L’écosystème commence par le provisionnement du matériel brut. Les nœuds sont détectés, les unités GPU, l’état de la mémoire ECC et les identités des cartes réseau sont vérifiés, puis une image du système d’exploitation comprenant le pilote GPU ainsi que les bibliothèques CUDA et NCCL est installée. Les paramètres BIOS appropriés sont ensuite appliqués, et les nœuds sont soumis à des tests de résistance ainsi qu’à des tests NCCL afin de vérifier que les unités GPU communiquent à la pleine largeur de bande, avant que le résultat soit enregistré dans une source de vérité telle que NetBox. Ce cycle peut être construit au moyen d’un gestionnaire matériel propre au fournisseur ou avec des outils ouverts tels que Metal3 avec Ironic ou vMetal.
Après l’allocation, des outils tels que KAI Scheduler et Volcano prennent en charge la planification par lots et tenant compte de la topologie, tandis que Kueue gère l’attente, l’admission et les quotas. Dans la couche des charges, vLLM peut être utilisé pour les moteurs d’inférence, et KServe pour fournir des points de terminaison standard et la mise à l’échelle automatique, en plus de NVIDIA Dynamo et de llm-d pour l’inférence découplée dans les environnements plus importants. Gateway API assure le routage, tandis que LiteLLM ajoute une passerelle compatible avec l’interface OpenAI.
La plateforme ne se limite pas aux conteneurs. L’article explique que les environnements d’entraînement peuvent utiliser Slurm via Slinky de SchedMD, qui représente les services Slurm comme des ressources personnalisées et les intègre à GPU Operator et DRA. KubeVirt peut également exécuter des machines virtuelles comme des charges Kubernetes, de sorte que les machines virtuelles et les conteneurs soient gérés depuis le même parc, avec des autorisations et des quotas uniformes.
L’isolation ne se résume pas aux espaces de noms
L’article divise le problème de l’isolation en deux niveaux. Au niveau du contrôle, le modèle tenant cluster fournit à chaque équipe une interface Kubernetes virtuelle comprenant un serveur API, des ressources dédiées, des règles d’admission et un RBAC indépendants, tout en l’exécutant comme une charge au-dessus d’un seul cluster de base. vCluster en constitue un exemple, avec la possibilité d’utiliser des outils familiers tels que kubectl, Helm et Argo CD sans extensions propriétaires.
Le niveau des données nécessite quant à lui l’isolation des réseaux, du stockage, des quotas et de l’environnement d’exécution. Cilium peut être utilisé pour le CNI et les politiques, et Multus ainsi que SR-IOV pour le chemin rapide, avec InfiniBand ou RoCEv2 pour transporter le trafic GPU entre les nœuds. Des VPC distincts peuvent également être utilisés via VXLAN et EVPN, ou des clés de partitionnement dans InfiniBand, tandis que des unités DPU telles que NVIDIA BlueField ou AMD Pensando déportent certaines fonctions d’isolation et de chiffrement du processeur hôte. L’article affirme que le véritable critère d’un cloud est une isolation imposée par le matériel lorsque cela est nécessaire, et non le recours aux seuls espaces de noms.
Qu’est-ce qui transforme le parc en service cloud ?
Lecture éditoriale : l’intérêt pratique de cette approche est de déplacer le débat de « quel modèle est le plus rapide ? » vers la question de l’exploitation de l’infrastructure elle-même. La plateforme ne devient pas un service cloud par le simple regroupement d’unités GPU ; elle le devient lorsque le locataire peut créer et supprimer des clusters via une API, Terraform ou GitOps, et lorsque les ressources sont décrites de manière déclarative et gérées par Flux ou Argo CD, avec une identité OIDC et des autorisations RBAC.
Le service a également besoin d’une mesure et d’une facturation compréhensibles. L’article propose d’utiliser les données DCGM pour calculer les secondes GPU, puis de les répartir entre les locataires via OpenCost. La supervision et la fiabilité font elles aussi partie du produit, et non d’une annexe opérationnelle : DCGM surveille la dégradation, Node Problem Detector transforme les signaux de panne en états pour les nœuds, tandis que le cycle de traitement isole le nœud suspect et le draine avant la planification de nouvelles charges. La couche de sécurité comprend des outils tels que Keycloak via OIDC, OpenBao avec External Secrets Operator, Kyverno ou OPA pour les contrôles, ainsi que Falco et Trivy pour la sécurité de l’exécution et de la chaîne d’approvisionnement.
Le test le plus difficile reste le passage d’une démonstration à une production à grande échelle. L’exemple qui exécute deux équipes et deux modèles sur un seul GPU partitionné ne suffit pas à démontrer la validité de la conception avec des centaines de nœuds et plusieurs centres de données. L’article évoque le rôle d’outils de validation tels que NVIDIA AI Cluster Runtime et le programme Kubernetes AI Conformance, présenté avec la version 1.35, mais laisse ouvertes des questions opérationnelles concernant le rayon d’explosion, les limites de l’isolation entre locataires et le choix entre la suite NVIDIA DSX OS et l’assemblage de couches open source.
En conclusion, le succès d’une « usine d’IA » dépend de la combinaison de la densité, de l’isolation et de la facturation, tout en tenant compte de la topologie matérielle : position des unités GPU par rapport à NVLink ou NVSwitch, connexion à un réseau InfiniBand ou RoCE, et emplacement du GPU, de la NIC et du CPU sur les nœuds NUMA. Planifier la charge sans ces informations peut ralentir les opérations de communication collective au niveau de la liaison la plus lente, même si la plateforme semble saine du point de vue logiciel.