NVIDIA détaille la recette Kubernetes pour le support NVL72 Vera Rubin
NVIDIA a indiqué que son IA Cluster Runtime peut rendre les clusters Kubernetes prêts pour Vera Rubin NVL72 les bacs de calcul le jour un en empaquetant les réglages réglés, en générant des bundles de déploiement et en validant le cluster en cours d’exécution. L’entreprise a présenté cet effort comme faisant partie de sa DSX IA Factory Platform, et a indiqué que le travail traite des changements matériels, de pilotes et de planificateurs nécessaires lors de l’introduction de nouveaux systèmes GPU dans une pile native cloud.
Quels changements changent pour Vera Rubin NVL72
Dans ce post, NVIDIA a indiqué que Vera Rubin NVL72 est une évolution de la même architecture rack MGX utilisée par GB200 NVL72, mais avec plusieurs changements visibles pour les utilisateurs que les équipes de plateforme doivent anticiper. La société a indiqué que le nouveau système nécessite la branche pilotes R615.23 , avec un support initial destiné à R610 et un support officiel de la plateforme en R620. Il a également indiqué que Vera Rubin remplace ConnectX-7 cartes réseau et BlueField-3 DPU par ConnectX-9 des SuperNIC et BlueField-4 DPU, et que DOCA 3.3.0 est la première version GA supportant ConnectX-9.
NVIDIA a indiqué que la topologie évolue également de manière importante pour les charges de travail très axées sur les E/S comme le réseau RDMA et le stockage GPUDirect. Selon le post, le bac de calcul Vera Rubin NVL72 expose huit ConnectX-9 groupes de périphériques PCI avec 32 fonctions, comparé aux adaptateurs quatre ConnectX-7 sur le plateau de calcul NVIDIA DGX GB200 NVL72. La société a également indiqué que la connectivité GPU-NIC est un nœud dans un socket et un SYS entre sockets, et que le nombre de fonctions PCI ne représente pas le nombre physique de ports.
Le post précisait que les GPU Rubin introduisaient de nouveaux profils MIG, mais que les recettes Vera Rubin décrites là-bas utilisent une allocation GPU entière et ne configurent pas le MIG. Il ajoutait que les charges de travail NVIDIA NVLink multi-nœuds continuent d’utiliser IMEX, et que DRA v0.5.0 inclut une option alpha gérée par l’hôte avec isolation de domaine uniquement, tandis que le cluster décrit dans le post utilise le mode driverManageed.
Validation sur le matériel ancien
NVIDIA a indiqué avoir validé la pile Vera Rubin NVL72 de bout en bout en utilisant la version officielle de l’opérateur GPU v26.7.0 , la version officielle du pilote DRA v0.5.0 et un pilote R615 installé par l’hôte. La société a indiqué que les variantes de la recette d’entraînement et d’inférence avaient validé avec succès pour le déploiement et la conformité, et que la recette d’entraînement a également franchi une porte de performance basée sur un NCCL all-reduce inter-nœuds sur le tissu NVIDIA NVLink via un IMEX ComputeDomain.
Dans la table de validation, NVIDIA a rapporté un résultat de performance de 744.71 GB/s de bande passante de bus à 16 GiB pour le premier all-reduce NCCL entre nœuds sur les deux bacs de calcul. La société a indiqué que la variante d’inférence a passé la même matrice de déploiement et de conformité sur le même cluster, mais que cette inférence servant la performance reste différée pour l’instant.
Le post précisait également que les premiers projectiles de validation avaient été temporairement bloqués par un problème matériel ou de tissu dans une des premières clusters Vera Rubin qui empêchait une seule boîte de calcul d’entrer dans le tissu NVLink. NVIDIA a indiqué que le problème n’était pas lié à l’opérateur GPU ni au pilote DRA et avait été résolu après la réinstallation matérielle.
Déploiement basé sur des recettes et limites enregistrées
Selon NVIDIA, AICR capture les choix de plateforme nécessaires pour mettre en place un cluster Vera Rubin fonctionnel comme une recette versionnée, y compris le mode pilote, le câblage à l’exécution du conteneur, les versions des composants et les paramètres spécifiques à la plateforme. La société a indiqué que la nouvelle famille de recettes Vera Rubin pour rke2, l’accélérateur de vr200 et Ubuntu sont livrés en version Aperçu, ce qui signifie qu’elle est destinée aux premiers utilisateurs et ne dispose pas encore du support en production ni de la qualification du cycle de vie d’une recette prise en charge.
Le post disait que la recette encode le mode pilote géré par l’hôte car l’image système préinstalle le pilote arm64 module à noyau ouvert, tandis que la boîte à outils conteneur reste gérée par l’opérateur. Il précisait également que la recette permet des ComputeDomains soutenus par IMEX pour le tissu NVL72 , laisse l’allocation complète du GPU au plugin de périphérique, et fixe un ensemble d’étages et particularités incluant Kubernetes 1.34.1 ou versions ultérieures, Ubuntu 26.04, et un noyau arm64 64k pages optimisé pour Vera.
NVIDIA a indiqué que le premier déploiement du bundle visait une combinaison de plateforme qui n’avait pas encore été validée ensemble : arm64, Ubuntu 26.04, un noyau de 64k pages, RKE2 et Vera Rubin. La société a indiqué que cette configuration est passée du transfert de cluster à une autonomie saine en quelques heures, et qu’un second cluster Vera Rubin a reproduit le résultat le lendemain.
Le post précisait également que la frontière validée n’est pas définitive. NVIDIA a noté que la performance de service par inférence dépend toujours d’une image d’exécution publiée construite en CUDA 13.4 ou ultérieure, et a précisé que les images vLLM publiques actuelles et IA-dynamo ne répondent pas encore à cette exigence de la manière nécessaire pour un plancher de performance d’inférence Vera Rubin. La société a indiqué que les preuves de validation publiées devraient donc être considérées comme le document historique de la coordonnée de recette contre laquelle elles ont été capturées.
NVIDIA a indiqué que les recettes Vera Rubin sont publiées dans le dépôt open source NVIDIA/aicr en v1.0.0, et que les utilisateurs peuvent générer la configuration validée avec des commandes de recette aicr pour des variantes d’entraînement ou d’inférence.