Comprendre NVIDIA DGX : systèmes, logiciels et options cloud

NVIDIA DGX désigne une famille de systèmes intégrés pour l’IA, qui va des machines de bureau aux infrastructures réparties sur plusieurs baies. Le choix dépend des besoins des modèles, de la communication entre GPU et de l’équipe chargée de l’exploitation. Le nom DGX ne suffit pas à connaître la capacité mémoire, le coût de déploiement ou les performances d’une configuration.

Ce guide distingue les principales options DGX et les critères à examiner avant d’acheter du matériel ou de louer des GPU. Pour les notions de base, consultez notre guide du calcul sur GPU.

Qu’est-ce que NVIDIA DGX ?

La plateforme NVIDIA DGX associe du matériel de calcul accéléré à des logiciels et à une assistance pour développer et déployer des applications d’IA. Elle couvre plusieurs échelles : un DGX Spark de bureau et une installation DGX SuperPOD répondent à des besoins d’infrastructure différents.

Précisez d’abord ce que vous évaluez. Une personne peut avoir besoin d’une machine locale pour ses expériences. Une équipe de recherche peut chercher un serveur partagé à plusieurs GPU. Une organisation plus grande peut avoir besoin d’un cluster, avec stockage, réseau, ordonnanceur et personnel d’exploitation. Ce sont des décisions d’achat distinctes, même sous une marque commune.

DGX Spark, Station, serveurs et SuperPOD

Ce tableau aide à choisir une catégorie avant de comparer les caractéristiques détaillées. Les usages proposés servent de points de départ à l’évaluation ; ils ne garantissent ni qu’un modèle tiendra en mémoire ni qu’il sera assez rapide.

Option	Ce qu’elle désigne	Première question à poser
DGX Spark	Système compact de développement d’IA sur bureau	Le modèle tient-il en mémoire, avec une vitesse d’inférence ou d’ajustement suffisante ?
DGX Station	Système de développement d’IA de bureau plus volumineux	L’architecture mémoire et logicielle convient-elle au projet ?
Serveur DGX, par exemple B300	Système intégré à plusieurs GPU pour centre de données	La charge utilisera-t-elle l’interconnexion entre GPU et la capacité disponible ?
Systèmes DGX à l’échelle d’une baie	Calcul organisé sur une baie, avec notamment des conceptions à refroidissement liquide	Le site peut-il répondre aux besoins précis d’alimentation, de refroidissement et d’installation ?
DGX SuperPOD	Infrastructure de cluster intégrée autour de systèmes DGX	Le stockage, les réseaux, l’ordonnancement et l’exploitation sont-ils dimensionnés pour l’ensemble des traitements ?

DGX Spark et DGX Station : développer localement

La documentation de DGX Spark décrit un système compact Grace Blackwell, doté de 128 Go de mémoire unifiée et d’un processeur Arm. Il peut être utilisé directement ou par le réseau. Les logiciels préconfigurés comprennent DGX OS, les outils CUDA et la prise en charge des conteneurs.

Le guide actuel de DGX Station présente un système de bureau GB300 Grace Blackwell avec jusqu’à 748 Go de mémoire cohérente. Cette capacité réunit la mémoire HBM du GPU et celle du CPU ; elle ne correspond pas à 748 Go bénéficiant tous de la même bande passante GPU. Vérifiez la machine et la configuration exactes.

Pour ces deux appareils, testez les images de conteneurs et leurs dépendances sur l’architecture CPU cible. Un environnement fonctionnel sur x86 ne garantit pas que chaque paquet ou extension compilée fonctionnera sans modification sur Arm. Distinguez aussi l’inférence de l’ajustement : l’état de l’optimiseur, les activations, la longueur du contexte et la taille des lots modifient fortement les besoins mémoire.

Serveurs DGX et systèmes à l’échelle d’une baie

Un système DGX de centre de données associe plusieurs accélérateurs aux ressources hôtes et aux connexions nécessaires à leur fonctionnement commun. Le guide du DGX B300 indique, par exemple, huit GPU B300 dans un système de dix unités de baie, avec des interconnexions NVLink et des réseaux distincts pour le cluster, le stockage et l’administration.

Ces caractéristiques ne s’appliquent pas à tous les DGX. Les générations de GPU, l’architecture CPU, le refroidissement et le réseau varient. La gamme actuelle de NVIDIA comprend des systèmes Blackwell et Rubin, dont DGX Vera Rubin NVL72 et DGX Rubin NVL8. Confirmez auprès du fournisseur le produit précis, le calendrier de livraison et les exigences du site.

L’achat à l’échelle d’une baie exige aussi un plan d’installation. Prévoyez les commutateurs, le câblage, l’accès au stockage, l’espace de maintenance et les personnes chargées des incidents. Une puissance maximale annoncée sert à dimensionner le site ; elle ne mesure pas l’énergie consommée par votre application.

Ce qu’apporte DGX SuperPOD

DGX SuperPOD réunit calcul DGX, réseau, stockage, logiciels et gestion d’infrastructure à l’échelle d’un cluster. Ce n’est pas le nom d’un GPU. BasePOD constitue une approche connexe par architecture de référence pour construire une infrastructure d’IA.

Il faut déterminer si l’ensemble de l’installation peut alimenter les traitements utiles. Un accélérateur rapide peut attendre les données d’entraînement, l’écriture d’un point de contrôle ou un autre processus. Notre guide des clusters GPU explique ces dépendances entre composants.

DGX et HGX : quelles différences ?

NVIDIA HGX est une plateforme GPU utilisée dans des systèmes proposés par des partenaires matériels. DGX désigne l’offre intégrée de systèmes et de plateforme de NVIDIA. Un serveur HGX peut employer la même génération de GPU qu’un DGX, sans pour autant partager tous ses composants ou ses modalités d’assistance.

Comparez la liste des composants et le contrat de service. Qui prend en charge les micrologiciels, le système d’exploitation hôte, les pannes de GPU, le stockage et le réseau ? Quels abonnements logiciels sont inclus, et pour combien de temps ? Le nom de l’accélérateur ne répond pas à ces questions.

Les logiciels et l’exploitation comptent autant que les GPU

NVIDIA AI Enterprise est une suite commerciale qui propose des outils et une assistance professionnelle pour les charges d’IA. Son périmètre diffère de celui d’un pilote GPU ou d’une bibliothèque CUDA. Confirmez les droits d’utilisation, les versions prises en charge et les conditions de renouvellement associés au système proposé.

Avant le déploiement, attribuez la responsabilité des mises à jour de pilotes, de la validation des conteneurs, des accès, de l’ordonnancement, de la supervision et de la reprise. Des logiciels préconfigurés peuvent réduire le travail initial, mais votre organisation doit disposer de procédures d’exploitation testées pour ses applications.

Conservez un relevé reproductible de l’environnement : version du modèle, empreinte du conteneur, pilote, bibliothèque d’apprentissage, précision numérique et version du jeu de données. Il permet d’interpréter les mesures et de déplacer un traitement sans confondre modification logicielle et amélioration matérielle.

Que signifie DGX Cloud aujourd’hui ?

La présentation actuelle de DGX Cloud le décrit comme l’environnement cloud interne de NVIDIA pour développer des modèles, valider des architectures et exécuter des charges d’IA chez plusieurs fournisseurs. Cette même page conserve des descriptions de services propres à certains fournisseurs. Les articles plus anciens peuvent donc décrire une autre offre commerciale.

Pour un nouveau projet, vérifiez le service effectivement proposé : fournisseur de capacité, matériel, réseau, prestations de gestion et contrat. Une instance GPU dans le cloud ne correspond pas nécessairement à un serveur DGX physique. Le nom DGX Cloud ne garantit pas non plus un accès immédiat à un GPU donné.

Comment comparer DGX et les instances GPU dans le cloud

Partir du traitement et de la mémoire

Indiquez s’il s’agit d’entraînement, d’ajustement, de mise à disposition d’un modèle ou de tâches indépendantes par lots. Précisez le modèle, la précision, la longueur du contexte, la taille des lots et le temps de réponse attendu. Un système adapté à une petite démonstration peut échouer lorsque des utilisateurs simultanés ou des entrées plus longues augmentent la demande mémoire.

Si un traitement utilise plusieurs GPU, le logiciel doit répartir explicitement le travail et la mémoire. Le parallélisme tensoriel est une méthode possible, dont les échanges peuvent peser sur les performances. Additionner les capacités mémoire ne prouve pas qu’une application pourra les utiliser comme un espace unique.

Mesurer le travail accompli

Pour l’entraînement, comparez le temps nécessaire pour atteindre le même niveau de qualité, points de contrôle et reprise compris. Pour l’inférence, comparez le débit à latence et qualité de sortie données. Mesurez séparément le chargement et les transferts afin qu’un test court ne masque pas les coûts de préparation.

Les FLOPS maximaux n’ont de sens qu’avec leur format numérique et leurs hypothèses. Les performances FP4 avec parcimonie ne sont pas interchangeables avec les performances BF16 denses. Demandez des résultats pour votre modèle et vos réglages, puis répétez un test représentatif avant de réserver de la capacité.

Prenons deux équipes hypothétiques. La première exécute des centaines de tâches indépendantes de génération d’images, chacune tenant sur un seul GPU. Elle peut mesurer le débit en répartissant les tâches sur des appareils distincts. La seconde répartit un grand modèle de langage sur plusieurs GPU, qui échangent des résultats intermédiaires tout au long de l’inférence. Pour elle, la latence et la bande passante des échanges peuvent être déterminantes. Un même nombre de GPU ne convient donc pas nécessairement aux deux cas.

Testez aussi la gestion des pannes. Dans un environnement contrôlé, redémarrez un processus de calcul, restaurez un point de contrôle et mesurez le délai de reprise du service. Utilisez des entrées réalistes et répétez les mesures. Une démonstration réussie prouve qu’un traitement fonctionne ; des mesures prolongées indiquent si l’infrastructure atteint son objectif opérationnel.

Calculer le coût complet

Il n’existe pas de « prix DGX » unique qui représente à la fois une machine de bureau, un serveur et une installation sur plusieurs baies. Demandez un devis pour une configuration précise. Intégrez le matériel, l’assistance, les renouvellements logiciels, le réseau, le stockage, l’électricité, le refroidissement, les locaux et le temps de travail sur la durée d’utilisation prévue.

Pour une capacité cloud, ajoutez le temps d’exécution GPU, le stockage associé, les transferts, les ressources inactives et les éventuels engagements de capacité. Comparez une même quantité de travail accompli. L’achat peut convenir à une demande régulière ; la location peut limiter la capacité inutilisée si la demande est intermittente. Le tarif horaire du GPU ne suffit pas à trancher.

Évaluez les arguments environnementaux avec la même rigueur. Mesurez l’énergie du traitement et considérez la source d’électricité, les dépenses énergétiques du site, la durée de vie du matériel et son utilisation. Un prix inférieur ou un déploiement distribué ne démontre pas une empreinte carbone plus faible.

La place de Compute with Hivenet

Compute with Hivenet propose actuellement des instances RTX 5090 avec 32 Go de VRAM par GPU, et jusqu’à huit GPU selon la capacité disponible. La flotte RTX 4090 a été retirée. Consultez la console pour les configurations, localisations, disponibilités et prix actuels.

Évaluez ces instances pour des traitements compatibles avec leur mémoire et leurs conditions d’exécution. Le nombre de GPU ne suffit pas à faire d’une instance RTX un remplacement de DGX : les interconnexions, l’architecture mémoire, l’assistance logicielle et les responsabilités de service diffèrent. Testez la configuration réelle avant de la choisir pour des traitements multi-GPU fortement couplés.

Les vérifications avant de s’engager

1. Définir le traitement, le niveau de qualité, la latence attendue et la demande prévue.
2. Estimer la mémoire sur tout le parcours d’exécution, concurrence et état d’entraînement compris.
3. Vérifier l’architecture CPU, la compatibilité logicielle, la topologie GPU, le stockage et le réseau.
4. Exécuter un test représentatif et documenter ses paramètres et ses limites.
5. Comparer les coûts complets d’achat ou de location, temps d’inactivité et exploitation compris.
6. Confirmer l’assistance, le traitement des données, la disponibilité et le plan de reprise.

Choisissez le plus petit déploiement qui répond de façon fiable à ces besoins. Augmentez sa capacité lorsque les mesures identifient la prochaine limite.

Pour un déploiement partagé, définissez les règles d’accès et d’attribution des ressources avant d’accueillir les équipes. Précisez la durée maximale des tâches, l’emplacement des données et des points de contrôle, ainsi que le suivi de l’utilisation. Pour les données sensibles, examinez les contrôles d’accès, le chiffrement, la conservation et les responsabilités contractuelles. Une marque de matériel ne garantit pas, à elle seule, la sécurité ou la conformité du déploiement.

Questions fréquentes

DGX est-il un GPU ?

Non. DGX désigne des systèmes et des infrastructures de calcul accéléré NVIDIA. Le modèle de GPU n’est qu’un composant de la configuration.

DGX peut-il servir à l’inférence et à l’entraînement ?

Oui. Le système adapté dépend de la taille du modèle, de la concurrence, de la latence et de la compatibilité logicielle. Un système d’entraînement plus puissant n’améliore pas automatiquement un service d’inférence peu sollicité.

Faut-il DGX pour utiliser CUDA ou PyTorch ?

Non. Des stations de travail NVIDIA compatibles, des serveurs partenaires et des instances cloud peuvent aussi exécuter des traitements CUDA pris en charge. DGX apporte une offre particulière de matériel, de logiciels et d’assistance intégrés.