Baie de serveurs GPU : guide d’architecture, de performance et de déploiement cloud

Une baie de serveurs GPU n’est pas seulement une armoire remplie d’accélérateurs. C’est une frontière de déploiement où la topologie GPU, l’infrastructure réseau, le stockage, la gestion, l’alimentation, le refroidissement et l’ordonnancement fonctionnent ensemble — ou créent des goulots d’étranglement coûteux.

Pour les développeurs d’IA et les ingénieurs en infrastructure ML, la question utile n’est pas « Combien de GPU tiennent dans une baie ? » Elle est plutôt : cette baie peut-elle fournir le comportement de communication, de chemin de données et de récupération dont la charge de travail a besoin ? Ce guide transforme cette question en liste de contrôle d’architecture et en plan d’acceptation cloud.

Qu’est-ce qu’une baie de serveurs GPU ?

Une baie de serveurs GPU est une baie physique ou une allocation à l’échelle d’une baie gérée par un fournisseur, contenant un ou plusieurs serveurs GPU ainsi que les composants réseau, d’alimentation, de refroidissement et de gestion nécessaires à leur exploitation. Dans un déploiement cloud, vous ne contrôlez peut-être pas l’armoire elle-même, mais vous devez tout de même demander quelles parties de la topologie sont garanties : GPU par hôte, interconnexion intra-hôte, infrastructure entre hôtes, chemin de stockage, domaine de maintenance et politique de placement.

Un seul serveur GPU constitue un nœud. Une baie de serveurs GPU est le système qui entoure plusieurs nœuds. Un cluster GPU peut s’étendre sur une ou plusieurs baies. Ces distinctions sont importantes, car un service d’inférence peut être limité par la mémoire GPU et le chemin PCIe/NVLink d’un seul hôte, tandis que l’entraînement distribué ou l’inférence à grande échelle peuvent être limités par les chemins réseau et de stockage entre les hôtes.

L’architecture de référence BasePOD de NVIDIA illustre cette différence : elle sépare un réseau de calcul InfiniBand, une infrastructure Ethernet de gestion et de stockage, et un réseau de gestion hors bande. Votre conception ne doit pas nécessairement reproduire cette architecture de référence, mais elle doit expliciter les chemins équivalents avant que vous engagiez de la capacité. Architecture de référence NVIDIA DGX BasePOD

Architecture d’une baie de serveurs GPU : les six éléments à cartographier

Commencez par un schéma de baie montrant le placement physique et les chemins logiques. Si un fournisseur ne peut pas divulguer chaque composant, consignez ce qui est garanti et testez le reste pendant la période d’acceptation.

1. Traitez la topologie comme une entrée de la charge de travail

Le nombre de GPU est une description incomplète de la capacité. Pour un hôte, examinez comment les GPU sont connectés entre eux et aux NIC. Entre les hôtes, déterminez si une tâche restera sur un serveur, dans une baie ou traversera plusieurs baies. Enregistrez la règle de placement attendue dans la spécification de la charge de travail au lieu de supposer que « huit GPU » décrit partout la même machine.

NCCL utilise des chemins directs pair à pair lorsque CUDA indique que les GPU concernés peuvent accéder à la mémoire les uns des autres. NVIDIA documente nvidia-smi topo -p2p comme moyen d’inspecter l’état pair à pair ; utilisez-le comme donnée de validation, et non comme substitut à un benchmark de charge de travail. Guide de dépannage GPU de NCCL

2. Séparez les flux de calcul, de données et de gestion

Une baie de serveurs GPU a besoin de plus qu’un réseau d’entraînement rapide. Le trafic de gestion, les téléchargements d’artefacts, la télémétrie, le stockage partagé et l’accès utilisateur peuvent interférer avec le trafic des charges de travail lorsqu’ils partagent un chemin sous-dimensionné. Utilisez des chemins logiques ou physiques séparés lorsque votre architecture l’exige, puis définissez quel chemin transporte chacun des éléments suivants :

• les communications collectives et le trafic GPU-direct ;
• les téléchargements d’images, les poids de modèles, les jeux de données et les points de contrôle ;
• le trafic Kubernetes, SSH, BMC, de journalisation et de surveillance ;
• la sortie vers des API, le stockage objet ou des services en aval.

Cela est particulièrement important pour la capacité cloud : demandez si les chiffres de bande passante décrivent la bande passante entre hôtes, la liaison montante de la baie, le débit du stockage ou un agrégat au mieux de l’effort. Ils ne sont pas interchangeables.

3. Concevez l’alimentation et le refroidissement comme des contraintes de capacité

Ne dimensionnez pas une baie de serveurs GPU à partir des seules unités de baie. Une configuration qui tient mécaniquement peut être contrainte par l’alimentation de l’installation, la redondance des PDU, le sens du flux d’air, les exigences de refroidissement liquide, le rayon de courbure des câbles ou le dégagement nécessaire à la maintenance. NVIDIA indique que les dispositions de baie varient selon la puissance maximale locale et l’infrastructure de refroidissement ; utilisez les documents à jour de votre fournisseur de serveurs et de votre fournisseur de colocation pour connaître l’allocation réelle. FAQ NVIDIA DGX SuperPOD

Avant le déploiement, demandez une réponse écrite à ces questions :

1. Quelle est l’enveloppe de puissance soutenue de la baie et quelle hypothèse de redondance est incluse ?
2. La conception du refroidissement repose-t-elle sur l’air, le liquide direct-to-chip, l’échange thermique par porte arrière, ou une combinaison de ces solutions ?
3. Quel composant déclenche en premier une limitation de performances ou un événement de maintenance : l’hôte, le PDU, le commutateur réseau ou la boucle d’installation ?
4. Un technicien peut-il intervenir sur un nœud, un câble ou un composant de porte arrière sans perturber la capacité adjacente ?

Si le déploiement est uniquement dans le cloud, traduisez ces mêmes questions dans les termes du fournisseur : placement sur hôte dédié, domaine de maintenance, politique de remplacement des hôtes et possibilité pour l’allocation de changer de topologie après le provisionnement.

4. Ne donnez au planificateur une connaissance des baies que lorsqu’elle est utile

Les étiquettes de baie sont utiles lorsque la charge de travail dépend de la localité ou des domaines de défaillance. Une tâche d’entraînement distribué peut préférer un placement dans une seule baie avant de s’étendre sur plusieurs baies. Un service d’inférence hautement disponible peut délibérément répartir les répliques entre plusieurs baies ou hôtes. Commencez par un petit ensemble d’étiquettes vérifiables, tel que topology.rack, topology.host-class, topology.fabric et topology.failure-domain, puis vérifiez que le placement du planificateur les respecte.

Pour Kubernetes, validez l’ensemble de la pile logicielle GPU par rapport à son système d’exploitation, Kubernetes, pilote, runtime et option de déploiement pris en charge — et pas seulement la version du cluster. La matrice de prise en charge de GPU Operator de NVIDIA distingue le bare metal, les VM avec GPU passthrough et les déploiements vGPU, et publie des détails de compatibilité pour les environnements pris en charge. Prise en charge des plateformes NVIDIA GPU Operator

Comment choisir une baie de serveurs GPU pour votre charge de travail

Utilisez le cahier des charges de la charge de travail pour déterminer si vous avez besoin d’un seul hôte haute densité, d’une baie ou d’un cluster multi-baies.

Pour un nouveau déploiement, comparez la décision relative à la baie avec une alternative plus simple. Si le travail ne requiert pas de contrôle sur la topologie, la localité des données ou une pile de service personnalisée, une API de modèle managée peut imposer une charge opérationnelle moindre. Utilisez cette comparaison entre cloud GPU et API de modèle dans le cadre de la décision, plutôt que de considérer une baie de serveurs GPU comme la réponse par défaut.

Comment évaluer les performances d’une baie de serveurs GPU

N’acceptez pas une baie de serveurs GPU sur la seule base d’un chiffre de performances de pointe de l’accélérateur. Élaborez un court test de réception qui distingue les principaux chemins de performance.

Étape 1 : Établir une référence d’inventaire et de topologie

Pour chaque hôte alloué, collectez l’identité du GPU, les versions du pilote et de CUDA, la topologie GPU-à-GPU, l’affinité GPU-à-NIC, la disposition NUMA du CPU, le stockage local et les interfaces réseau. Conservez cet enregistrement avec la révision du déploiement. Il fournit un point de comparaison lorsque les performances changent après une image, un firmware, un pilote ou un remplacement d’hôte.

nvidia-smi -L
nvidia-smi topo -m
nvidia-smi topo -p2p p
nvidia-smi topo -p2p n

Ne modifiez pas les paramètres du kernel, du BIOS, de l’IOMMU ou du contrôle d’accès PCIe à partir d’une liste de contrôle générique. NVIDIA documente le comportement sensible à la configuration du pair-à-pair sur les systèmes Linux bare metal ; utilisez les paramètres pris en charge pour le serveur et la plateforme cloud que vous exploitez réellement. Dépannage de la topologie et du pair-à-pair NCCL

Étape 2 : Tester aux frontières importantes

Exécutez des tests représentatifs à trois niveaux :

1. Nœud unique pour valider la visibilité des GPU et le chemin NVLink/NVSwitch ou PCIe local.
2. Même baie pour valider le placement hôte à hôte et le fabric local.
3. Entre baies pour comprendre le chemin que votre planificateur utilisera lorsque la capacité s’étend ou bascule.

Les recommandations de test NCCL de NVIDIA utilisent explicitement des exécutions sur un seul nœud, une seule baie et plusieurs baies afin de valider la visibilité des GPU, l’interconnexion intra-nœud, le fabric inter-nœuds et le placement. Capturez la latence et la bande passante avec la commande de test, le digest de l’image conteneur, la liste des nœuds et les étiquettes de placement afin qu’un résultat puisse être reproduit. Tutoriel de validation NCCL

Étape 3 : Mesurer le chemin réel de l’application

Exécutez ensuite la charge de travail que vous prévoyez de servir. Pour l’entraînement, indiquez le temps par étape, l’attente des données, le temps de communication collective, le temps de point de contrôle et le comportement de récupération. Pour l’inférence, indiquez le temps jusqu’au premier jeton, le débit de sortie, la latence de queue, le délai de mise en file d’attente, le comportement du cache et les taux d’erreur ou de redémarrage. Conservez le même modèle, le même profil de lot/concurrence, la même longueur de contexte et le même état du cache lorsque vous comparez les placements.

C’est ainsi que vous distinguez un problème de GPU d’un problème de données, de réseau, d’ordonnanceur ou de configuration.

Étape 4 : Tester une défaillance planifiée

Une baie de serveurs GPU opérationnelle nécessite un chemin de récupération. Avant le trafic de production, vérifiez ce qui se passe lorsqu’un worker est évacué, qu’un nœud devient indisponible, qu’un job est préempté ou qu’un point de contrôle doit reprendre ailleurs. Confirmez que les données persistantes sont séparées du calcul remplaçable et que les identifiants, les images et l’observabilité fonctionnent toujours sur le chemin de remplacement.

Déployer une baie de serveurs GPU dans le cloud : une séquence pratique

Le déploiement dans le cloud modifie la frontière de contrôle, mais pas le travail d’ingénierie. Vous devez toujours rendre visibles les hypothèses liées au matériel et au placement.

1. Rédigez le contrat de charge de travail. Précisez la taille du modèle, le nombre de GPU, les besoins en mémoire, le SLO de latence ou de débit, la sensibilité au réseau, la source des données, l’emplacement des points de contrôle, l’objectif de disponibilité et la limite budgétaire.
2. Choisissez la frontière de topologie. Déterminez si le job doit rester sur un seul hôte, dans une seule baie ou dans une structure multi-baies définie. Traitez cela comme une exigence dans la demande au fournisseur, et non comme une préférence informelle.
3. Demandez une fiche d’allocation. Demandez la classe d’hôte, le nombre de GPU, l’interconnexion GPU, les NIC, la structure réseau, les options de stockage, la garantie de placement, la politique de maintenance et toutes les métadonnées de topologie exposées à votre ordonnanceur.
4. Figez le contrat logiciel. Consignez le système d’exploitation, le noyau, le pilote NVIDIA, CUDA, le runtime de conteneur, la version de Kubernetes, la version de GPU Operator, l’image du framework et le condensat de l’image d’application. Validez la combinaison par rapport à la matrice prise en charge avant le déploiement.
5. Créez une fenêtre d’acceptation restreinte. Exécutez des tests d’inventaire, de topologie, de communication sur le même nœud/dans la même baie/entre baies, de stockage, d’application et de récupération avant de déplacer un trafic soutenu.
6. Instrumentez chaque couche. Configurez des alertes distinctes pour la santé des GPU, les erreurs de fabric, l’attente de stockage, l’attente de l’ordonnanceur, les événements thermiques ou de limitation et les SLO de l’application. Une seule métrique d’utilisation ne peut pas expliquer un incident à l’échelle d’une baie.
7. Conservez des options de sortie et de récupération. Maintenez les définitions d’images, la configuration de l’infrastructure, les emplacements des données persistantes, les points de contrôle et un plan de retour en arrière indépendamment d’une allocation particulière.

Pour les parties de cette séquence relatives au niveau de l’hôte, consultez le guide de déploiement de serveurs GPU. Pour la perspective du plan de contrôle et de la fabric multi-nœuds, consultez le guide d’architecture des clusters GPU.

Checklist d’acceptation d’une baie de serveurs GPU

Utilisez cette checklist avant d’accepter une nouvelle baie de serveurs GPU, une allocation cloud dédiée ou une installation en colocation.

• [ ] Le contrat de charge de travail indique une frontière de topologie : un hôte, une même baie ou plusieurs baies.
• [ ] La fiche d’allocation identifie le nombre de GPU par hôte, l’interconnexion des accélérateurs, les NIC, la fabric réseau et le chemin de stockage.
• [ ] L’alimentation, le refroidissement, la redondance des PDU, les exigences de circulation d’air ou de refroidissement liquide et l’espace de maintenance ont un responsable.
• [ ] Les versions du GPU, du pilote, de CUDA, du noyau, du runtime de conteneur et de l’orchestration sont consignées.
• [ ] L’ordonnanceur expose et respecte les libellés de placement ou de domaine de défaillance lorsque la charge de travail en a besoin.
• [ ] Les sorties de topologie d’inventaire et de nvidia-smi sont stockées pour chaque classe d’hôte.
• [ ] Les tests de communication couvrent les placements sur un seul nœud, dans la même baie et entre baies que l’ordonnanceur de production peut créer.
• [ ] Le test applicatif utilise une source de données et un profil de charge de travail représentatifs.
• [ ] Les chemins de point de contrôle, d’évacuation d’hôte, de remplacement et de retour en arrière sont testés.
• [ ] Le reporting des coûts distingue le temps GPU productif des coûts d’inactivité, de nouvelle tentative, de données et de support, sans compter deux fois le même temps. Pour le modèle de coûts plus large, commencez par ce guide de location de GPU.

Questions fréquentes

Une baie de serveurs GPU est-elle la même chose qu’un cluster GPU ?

Non. Une baie de serveurs GPU décrit une frontière de déploiement physique ou gérée par un fournisseur à l’échelle d’une baie. Un cluster GPU est un groupe logique de nœuds qui peut couvrir une partie d’une baie, une baie entière ou plusieurs baies. La différence est importante lorsque le réseau, le stockage, les domaines de défaillance et la planification franchissent des frontières physiques.

Combien de serveurs GPU tiennent dans une baie de serveurs GPU ?

Il n’existe pas de nombre universel utile. La profondeur des serveurs et les unités de baie ne constituent que la première contrainte. La réponse pratique dépend de la consommation électrique du serveur, de la conception du refroidissement, de la capacité et de la redondance des PDU, du routage des câbles, de l’accès pour la maintenance et de la densité approuvée par l’installation. Validez la réponse par rapport à la conception exacte de l’hôte, de la baie et du centre de données que vous utiliserez.

Chaque baie de serveurs GPU a-t-elle besoin d’InfiniBand ?

Non. La fabric appropriée dépend de la charge de travail et de la topologie. Les charges de travail sur un seul hôte peuvent ne pas nécessiter du tout de fabric inter-nœuds haute performance. Les charges de travail distribuées doivent être testées sur le chemin réseau qu’elles utiliseront réellement, y compris les placements dans la même baie et entre baies. Évitez de sélectionner une fabric uniquement sur la base d’une spécification marketing.

Que dois-je tester avant d’accepter une capacité de baie GPU dans le cloud ?

Testez l’allocation que vous avez reçue : inventaire matériel, topologie, affinité GPU-à-NIC, comportement du stockage local et partagé, communication sur un seul nœud, communication au sein d’une même baie, communication entre baies si cela est possible en production, comportement représentatif de l’application et récupération après une défaillance planifiée.

Quand dois-je éviter d’exploiter une baie de serveurs GPU ?

Évitez les opérations à l’échelle de la baie lorsque votre charge de travail n’a pas besoin du contrôle qu’elles offrent. Si une API de modèle gérée peut répondre aux exigences en matière de modèle, de latence, de disponibilité, de confidentialité et de coût, elle peut éliminer le travail lié au matériel, au fabric, aux pilotes, à l’ordonnanceur et à la gestion de la capacité. Faites cette comparaison de manière délibérée avant de vous engager dans une baie de serveurs GPU.

Construisez la baie autour de la charge de travail

Une baie de serveurs GPU réussit lorsque sa conception physique et son allocation cloud correspondent aux chemins de communication, de données et de récupération de la charge de travail. Rendez la topologie explicite, séparez les classes de trafic susceptibles d’interférer les unes avec les autres, validez les performances aux échelles d’un seul nœud, d’une même baie et de plusieurs baies, et n’acceptez la capacité qu’après avoir testé l’application réelle et un scénario de défaillance.

Si le contrôle au niveau de la baie n’est pas nécessaire, comparez une approche par API de modèle avant d’assumer la charge opérationnelle. S’il est nécessaire, utilisez ce guide avec le guide des serveurs GPU, le guide d’architecture des clusters GPU et la checklist des coûts du cloud GPU afin de transformer la capacité en un déploiement vérifiable.

Sources

• Architecture de référence NVIDIA DGX BasePOD
• FAQ NVIDIA DGX SuperPOD
• Prise en charge des plateformes par NVIDIA GPU Operator
• Dépannage des GPU NCCL de NVIDIA
• Tutoriel de validation NCCL NVIDIA Run:ai