Deux points reviennent systématiquement lorsqu'on aborde le sujet du NVIDIA DGX Spark. Le premier concerne ses caractéristiques principales : 128 Go de mémoire unifiée dans un boîtier de bureau à environ 4 000 $, une capacité qui aurait semblé inconcevable il y a encore deux ans. Le second est le réseau 200 Gb/s intégré. La présence d'une véritable infrastructure réseau de niveau centre de données sur un appareil de bureau attire l'attention, car elle implique bien plus qu'une simple station de travail plus rapide. Elle suggère la possibilité de connecter plusieurs Sparks et de les répliquer physiquement, une configuration multi-nœuds qui, auparavant, était exclusivement réservée aux racks.
Cette analyse examine cette capacité. Nous évaluons l'inférence distribuée sur les trois implémentations OEM Spark dont nous disposons, appariées en clusters à deux nœuds connectés via une infrastructure 200 Gb/s, et ce, pour différentes variantes de modèles et trois configurations de charge de travail. Nous faisons également un choix méthodologique délibéré concernant la répartition du modèle entre les deux machines, un choix qui diffère de la recommandation par défaut de NVIDIA, et nous le justifions par des données. Avant toute chose, deux éléments de contexte sont essentiels : le réseau qui rend le clustering possible et les raisons pour lesquelles un utilisateur pourrait souhaiter ou non l'utiliser.
Nous avons abordé en détail l'implémentation réseau dans notre test initial du DGX Spark, mais il est important de rappeler les points essentiels, car tout ce qui est présenté ici en dépend. À l'arrière de chaque Spark se trouvent deux baies QSFP56 gérées par une carte réseau intelligente NVIDIA ConnectX-7 intégrée. Sur le papier, ces deux baies offrent une connectivité agrégée de 400 Go, mais la limite réelle est le PCIe : la ConnectX-7 est protégée par deux liaisons Gen5 x4, et la plateforme plafonne à 200 Go de bande passante utilisable, quelle que soit la configuration des baies. Une seule baie QSFP56 équipée fournit déjà les 200 Gb/s supportés par le boîtier ; le second port sert donc à la flexibilité de la topologie plutôt qu'à augmenter le débit.
Cette flexibilité se manifeste par trois configurations courantes. La plus simple consiste en un unique port de 200 Gb utilisé comme liaison directe entre deux instances Spark, configuration spécifiée par NVIDIA pour une architecture à deux nœuds et que nous avons utilisée pour ce test. La deuxième utilise deux ports de 100 Gb pour établir une topologie en anneau entre les instances Spark, permettant ainsi un clustering sans commutateur. La troisième est une configuration à rôles partagés : une cage est connectée à une instance Spark homologue pour le clustering, tandis que l’autre est dédiée au stockage haute vitesse via NVMe-oF. Cette solution est particulièrement utile lorsque les données de travail ne tiennent pas sur le SSD NVMe interne de l’instance Spark.
NVIDIA propose le Spark en trois configurations, chacune correspondant à un usage spécifique du réseau. Un Spark unique pour les applications de bureau individuelles, un cluster validé à deux Sparks connectés directement via le réseau 200 Gb/s pour les modèles étendus, et, depuis la GTC de cette année, une configuration à quatre unités présentée publiquement par NVIDIA pour répondre à la demande des utilisateurs souhaitant dépasser la limite de deux nœuds. La configuration à deux Sparks est celle que NVIDIA commercialise activement, celle que la plupart des utilisateurs déploieront et celle qui, selon nous, représente la limite supérieure raisonnable pour l'inférence en production sur ce matériel. C'est également celle que nous évaluons de bout en bout dans ce test.
La raison principale de mettre en cluster des instances Spark est la même que pour tout cluster : un seul serveur de 128 Go ne peut pas contenir tous les modèles importants. Répartir un modèle de 120 milliards de paramètres sur deux serveurs permet de prendre en charge des charges de travail qui seraient autrement impossibles. C’est le cas d’utilisation phare, et celui qui fait l’objet du plus grand nombre de démonstrations.
La raison la moins évidente, et sans doute la plus importante pour la clientèle actuelle de NVIDIA sur cette plateforme, est l'apprentissage. NVIDIA positionne le Spark comme un point d'entrée. documentation officielleLes exemples de notebooks et les guides partenaires utilisent le boîtier comme un outil pédagogique. Ils proposent des guides de premier ordre pour tout, depuis le déploiement d'un modèle pré-construit via une interface de chat locale jusqu'à l'exécution d'un assistant de programmation sur un point de terminaison hébergé, en passant par l'optimisation de petits modèles et la création d'applications complètes en PyTorch et JAX. L'argument principal est qu'une personne n'ayant jamais écrit de noyau CUDA peut, en un week-end, créer un flux de travail d'IA fonctionnel directement depuis son poste de travail. Il en va de même pour les ingénieurs d'autres domaines qui souhaitent un environnement de test autonome et entièrement contrôlé. Un cluster à deux nœuds Spark étend ces possibilités d'apprentissage au domaine multi-nœuds : la même personne peut désormais apprendre le fonctionnement du parallélisme tensoriel, du parallélisme de pipelines et des bibliothèques de communication collective, au sein d'un réseau suffisamment réaliste pour révéler les véritables goulots d'étranglement.
Ce qui manque cruellement dans la communication de NVIDIA, c'est l'affirmation que Spark est destiné à la production de calculs d'inférence. Jensen a évoqué la co-conception matériel-logiciel lors de presque toutes ses conférences ces dernières années, et ce principe s'applique ici. Chaque plateforme NVIDIA est optimisée pour un type de charge de travail spécifique, et Spark est optimisé pour l'exploration et l'apprentissage individuels, et non pour la gestion du trafic. Nos précédents tests de Spark ont déjà démontré que la plateforme est fortement limitée par la bande passante mémoire pour la plupart des tâches d'inférence, et le réseau accentue encore cette contrainte dès que l'on utilise un cluster. Une liaison unique de 200 Gb/s, bien qu'impressionnante pour un ordinateur de bureau, est sensiblement plus lente qu'une connexion PCIe Gen5 x16 au sein d'un même châssis, et les modèles de communication collective qui fonctionnent parfaitement entre deux GPU de centre de données connectés par NVLink ne sont pas transposables à une infrastructure 200 Gb/s sans engendrer des pertes de latence significatives.
C’est la véritable raison pour laquelle NVIDIA a longtemps limité la configuration officiellement prise en charge à deux Sparks, et pourquoi la démonstration à quatre unités lors de la GTC répondait à une demande des utilisateurs plutôt qu’à une extension naturelle du produit. Rien n’empêche la pile logicielle de fonctionner sur quatre ou huit nœuds, et plusieurs utilisateurs et médias ont publié des résultats obtenus avec des clusters plus importants. Les performances de ces expériences sont généralement décevantes : le coût de l’interconnexion entre les nœuds devient prépondérant, les performances globales se dégradent fortement et, de surcroît, le débit par utilisateur en fin de compte peut chuter à quelques jetons par seconde pour tout modèle suffisamment important pour justifier le cluster. À ce stade, la configuration s’apparente davantage à un laboratoire d’apprentissage qu’à une plateforme de service.
Il ne s'agit en aucun cas d'un rejet. Le clustering Spark est une excellente méthode pour développer une intuition en matière d'inférence et d'entraînement distribués, intuition qui reste généralement inaccessible sans un matériel de centre de données coûteux (plusieurs centaines de milliers de dollars). La valeur pédagogique de pouvoir observer concrètement les bulles de pipeline, les goulots d'étranglement liés à la réduction totale et les compromis de parallélisme sur son propre système est considérable. Notre plan initial était d'aller plus loin en entraînant un petit modèle d'un milliard de paramètres (ou moins) à partir de zéro sur un cluster double Spark. La configuration choisie devait refléter au mieux les conditions d'un véritable pré-entraînement distribué, afin de démontrer précisément les cas où ce type de cluster est pertinent et ceux où il ne l'est pas. Ce projet est actuellement mis en suspens le temps de finaliser d'autres articles que vous avez peut-être déjà vus et d'attendre la livraison des composants optiques de notre nouveau commutateur de cœur de laboratoire 800 Gb. Nous prévoyons de le reprendre une fois le laboratoire opérationnel.
Ce qui suit se concentre sur le cas d'utilisation pour lequel la configuration à deux Spark est la plus pertinente : l'inférence distribuée de modèles suffisamment volumineux pour nécessiter les deux boîtiers, évaluée sur les trois implémentations OEM dont nous disposons. Avant de présenter les résultats par modèle, la section suivante explique pourquoi nous les rapportons dans le cadre d'une configuration parallèle de pipeline plutôt que dans le cadre d'une configuration parallèle de tenseurs, généralement privilégiée par la documentation NVIDIA.
NVIDIA a publié Guides DGX Spark La plupart de leurs documents de référence s'appuient sur le parallélisme tensoriel (TP) pour décrire la mise à l'échelle d'un modèle sur deux machines Spark. Le TP répartit chaque multiplication matricielle entre les deux GPU, de sorte que chaque couche s'exécute simultanément sur les deux machines. Les résultats partiels sont ensuite combinés par une réduction globale après chaque bloc d'attention et chaque bloc MLP. Le parallélisme de pipeline (PP) adopte une approche différente : il divise le modèle en deux par couche, place la première moitié sur une machine et la seconde sur l'autre, puis répartit les activations entre elles. Chaque requête parcourt toujours le modèle complet, mais à un instant donné, une seule machine effectue les calculs pour un jeton donné tandis que l'autre traite le microlot suivant.
Le compromis réside dans la nature des données transitant sur le réseau. Une pile double Spark connecte les deux systèmes via une liaison ConnectX-7 200 GbE, rapide pour une liaison réseau mais lente comparée à la bande passante mémoire d'un seul Spark. L'opération de réduction complète de TP s'exécute deux fois par couche de transformateur ; ainsi, un modèle à 80 couches exécutant TP=2 génère 160 échanges inter-boîtes pour chaque jeton de sortie, chacun de ces échanges bloquant le calcul suivant. PP=2 ne transmet les activations qu'une seule fois par jeton, à la jonction entre les deux moitiés du modèle. Sur une liaison 200 GbE avec une latence non négligeable, cette différence est prépondérante.
Nos mesures GPT-OSS-120B le confirment clairement. En dehors des lots de taille 1, où la charge de travail est trop faible pour masquer la surcharge de chaque stratégie, PP=2 prend l'avantage et le conserve malgré l'augmentation de la concurrence. Dans la charge de travail Equal ISL/OSL, TP=2 atteint 252.01 tok/s pour des lots de taille 128, tandis que PP=2 grimpe à 554.69 tok/s sur le même matériel, soit un avantage de 2.20x. Le scénario Prefill Heavy présente la même tendance, avec PP=2 à 310.63 tok/s contre 164.99 tok/s pour TP=2. Le scénario Decode Heavy est le plus serré des trois, mais PP=2 reste en tête pour des lots de taille 8 à 64, ne cédant qu'une légère avance pour des lots de taille 128, où la sortie longue de 8 Ko amplifie le coût des bulles de pipeline.
TP=2 présente un avantage certain dans une plage de fonctionnement restreinte. Avec une taille de lot de 1 dans tous les scénarios, TP offre un léger avantage, mais non négligeable : 39.55 tok/s contre 28.79 tok/s en mode Equal, 37.97 contre 29.60 en mode Prefill Heavy et 39.42 contre 30.28 en mode Decode Heavy. Lorsqu'une seule requête est en cours, aucun second microlot ne maintient l'étape de pipeline inactive occupée. Par conséquent, PP consomme un emplacement vide à chaque étape, tandis que TP exploite les deux GPU sur l'unique jeton disponible. C'est précisément pour ce type de configuration que les recommandations TP de NVIDIA sont conçues : la diffusion interactive à flux unique, où la latence sur la première et unique requête est plus importante que le débit global. Si le déploiement s'apparente véritablement à une messagerie instantanée, avec un utilisateur par machine et des objectifs TTFT stricts, TP=2 est le choix judicieux, ce qui correspond également à la vision de NVIDIA concernant Spark.
Pour les charges de travail qui desservent une infrastructure à grande échelle, avec inférence par lots et de nombreuses requêtes simultanées, le parallélisme de pipeline est plus adapté lors du passage à l'échelle sur plusieurs serveurs, en particulier lorsque des stratégies comme le parallélisme expert ne sont pas utilisées. L'infrastructure 200 GbE ne peut pas supporter le trafic de réduction par jeton du parallélisme de pipeline sans saturer les ressources de calcul, et dès que la taille des lots atteint 4 ou 8, le coût de la bulle du parallélisme de processus disparaît dans le flux de données en régime permanent. C'est pourquoi, dans la suite de cet article, chaque valeur par modèle est indiquée avec TP=1 et PP=2. Cette configuration représente fidèlement les performances d'un déploiement à deux instances Spark en situation réelle.
Nous avons délibérément choisi GPT-OSS-120B comme modèle principal du graphique TP vs PP car il présente l'écart le plus important. Cependant, nous souhaitons également montrer que cela ne s'applique pas à tous les modèles et que ces paramètres dépendent de ceux du modèle. Llama-3.1-8B-Instruct à BF16 présente un tableau beaucoup plus prudent. Ce modèle est suffisamment petit pour que le calcul de chaque couche soit rapide et que le trafic de réduction global de TP soit par conséquent modeste. En revanche, le coût de coordination par étape de PP est fixe, quelle que soit la taille du modèle. De ce fait, TP=2 conserve l'avantage sur la quasi-totalité du balayage par lots. En mode ISL/OSL égal, TP=2 domine de la taille de lot 1 (23.2 contre 13.4 tok/s) à la taille de lot 32 (388.7 contre 349.3 tok/s), ne cédant la première place qu'aux tailles de lot 64 (524.8 contre 638.2 tok/s) et 128 (679.2 contre 1 047,1 tok/s). En mode Préremplissage lourd, la tendance est identique : TP=2 est en tête jusqu'à la taille de lot 32, avant que PP=2 ne prenne le dessus aux tailles 64 et 128. En mode Décodage lourd, la différence est la plus nette : TP=2 l'emporte à chaque taille de lot, atteignant 366.7 tok/s contre 330.5 tok/s pour PP=2 à la taille de lot 128.
Ce contre-exemple renforce, plutôt qu'il ne contredit, les mécanismes sous-jacents. PP=2 ne l'emporte que lorsque la taille des lots est suffisamment élevée pour saturer le pipeline et amortir intégralement le coût des bulles, et lorsque le modèle lui-même est suffisamment petit pour que la réduction complète par couche de TP soit peu coûteuse ; ce point de bascule est alors repoussé. Le résultat « Decode Heavy » est également cohérent : des séquences de sortie plus longues impliquent davantage d'étapes de décodage, un plus grand nombre de bulles de pipeline payées consécutivement et une fenêtre plus réduite pour que PP compense la différence. En d'autres termes, les mêmes mécanismes qui confèrent à PP un avantage de 2.20x sur GPT-OSS-120B avec une taille de lot de 128 expliquent également pourquoi il ne l'emporte que pour les deux plus grandes tailles de lots sur un modèle de 8 B et ne remporte jamais la victoire avec un décodage intensif.
En ISL/OSL égaux, Dell démarre à 67.06 tok/s et atteint 927.93 tok/s avec une taille de lot de 64. GIGABYTE commence légèrement en dessous à 65.77 tok/s mais termine plus fort à 994.53 tok/s, tandis que HP domine le groupe avec 1 009,75 tok/s. L'écart reste faible pendant la majeure partie du test, HP prenant l'avantage à partir d'une taille de lot de 32.
En mode Préremplissage intensif, le débit augmente de manière beaucoup plus marquée. Dell passe de 164.42 tok/s à 2 097,80 tok/s, GIGABYTE de 162.96 tok/s à 2 086,72 tok/s, et HP affiche le meilleur résultat, avec une progression de 165.95 tok/s à 2 208,16 tok/s. HP domine pour presque toutes les tailles de lots, tandis que Dell et GIGABYTE restent très proches, notamment pour les lots de 32 et 64.
En mode Décodage intensif, les performances globales sont inférieures, comme prévu pour cette charge de travail. Dell affiche des performances allant de 41.20 tok/s à 563.98 tok/s, GIGABYTE de 40.83 tok/s à 617.96 tok/s et HP de 41.63 tok/s à 593.56 tok/s. GIGABYTE obtient les meilleurs résultats avec une taille de lot de 64, tandis que HP domine en milieu de gamme. Dell reste compétitif, mais accuse un léger retard à des niveaux de concurrence plus élevés.
En termes de performances ISL/OSL égales, Dell domine la majeure partie du test, passant de 88.73 tok/s pour une taille de lot de 1 à 1 953,55 tok/s pour une taille de lot de 64. GIGABYTE suit de près, avec une augmentation de 88.42 tok/s à 1 904,62 tok/s, tandis que les performances de HP varient de 83.49 tok/s à 1 831,45 tok/s. Dell conserve la meilleure progression globale, notamment à partir d'une taille de lot de 16.
En mode Préremplissage intensif, le débit augmente fortement sur les trois systèmes. Dell affiche le meilleur résultat, passant de 216.05 tok/s à 4 261,96 tok/s pour une taille de lot de 64. GIGABYTE suit avec 4 011,86 tok/s, tandis que HP atteint 3 785,25 tok/s. Les trois systèmes restent très proches pour les petits lots, mais Dell commence à se démarquer à partir de 16 lots et creuse l'écart jusqu'à la fin du test.
En mode Decode Heavy, la montée en charge est plus progressive, mais reste performante sur toutes les plateformes. Dell affiche des performances allant de 54.88 tok/s à 1 173,31 tok/s, GIGABYTE de 55.24 tok/s à 1 181,94 tok/s et HP de 53.20 tok/s à 1 082,23 tok/s. GIGABYTE surpasse légèrement Dell pour les lots les plus importants, tandis que HP est en retrait par rapport aux deux systèmes pour les niveaux de concurrence plus élevés.
En conditions ISL/OSL égales, Dell affiche des performances allant de 27.69 tok/s à 1 376,38 tok/s pour une taille de lot de 64, devançant de peu GIGABYTE, dont les performances varient de 27.23 tok/s à 1 372,27 tok/s. HP reste légèrement en retrait tout au long du test, avec des performances allant de 26.89 tok/s à 1 235,32 tok/s. Les trois systèmes présentent des performances très proches jusqu'à une taille de lot de 16, avant que Dell ne prenne légèrement l'avantage à des niveaux de concurrence plus élevés.
En mode pré-remplissage intensif, le débit augmente fortement avec la taille des lots. Dell passe de 68.60 tok/s à 2 575,25 tok/s, tandis que GIGABYTE affiche finalement le meilleur résultat, passant de 67.49 tok/s à 2 694,25 tok/s pour une taille de lot de 64. HP atteint 2 315,15 tok/s, restant compétitif mais systématiquement derrière Dell et GIGABYTE pour les lots de grande taille. GIGABYTE prend la tête pour les lots de grande taille, notamment pour les lots de 64 ou plus.
Lors du test Decode Heavy, la vitesse de traitement reste constante. Dell affiche une vitesse de 17.19 tok/s à 726.22 tok/s, GIGABYTE de 16.96 tok/s à 720.57 tok/s et HP de 16.79 tok/s à 663.31 tok/s. Dell et GIGABYTE conservent des performances quasi identiques pendant la majeure partie du test, Dell conservant un léger avantage aux niveaux de concurrence les plus élevés. En revanche, HP accuse un léger retard pour les lots de grande taille.
En conditions ISL/OSL égales, Dell affiche des performances allant de 69.71 tok/s à 2 849,20 tok/s pour une taille de lot de 64, tandis que GIGABYTE prend légèrement l'avantage, passant de 70.92 tok/s à 2 912,03 tok/s. HP reste compétitif, avec des performances comprises entre 69.52 tok/s et 2 821,50 tok/s. Les trois systèmes conservent des performances très proches sur l'ensemble de la charge de travail, un léger écart n'apparaissant qu'à des niveaux de concurrence plus élevés.
En mode Prefill Heavy, la mise à l'échelle devient beaucoup plus agressive, notamment pour les lots de grande taille. Dell passe de 170.09 tok/s à 4 417,65 tok/s, tandis que GIGABYTE affiche le meilleur résultat du groupe, passant de 173.55 tok/s à 4 767,43 tok/s pour un lot de 64. HP passe de 170.12 tok/s à 4 214,57 tok/s. GIGABYTE se démarque nettement à partir d'un lot de 32, offrant le débit maximal le plus élevé pour cette charge de travail.
Lors du décodage intensif, les trois systèmes restent très proches en termes de performances sur la majeure partie du cycle. Dell affiche des débits allant de 43.19 tok/s à 1 260,24 tok/s, GIGABYTE de 43.53 tok/s à 1 258,05 tok/s et HP de 42.54 tok/s à 1 178,74 tok/s. Dell et GIGABYTE se partagent la tête du classement en fonction de la taille des lots, tandis que HP accuse un léger retard aux niveaux de concurrence les plus élevés.
En mode ISL/OSL égal, Dell voit son débit passer de 46.93 tok/s à 2 206,52 tok/s pour une taille de lot de 64, tandis que GIGABYTE oscille entre 46.16 tok/s et 2 175,44 tok/s. HP suit de près, avec une augmentation de 46.40 tok/s à 2 149,15 tok/s. L'écart global reste faible tout au long du test, les trois systèmes conservant un comportement d'évolution quasi identique jusqu'à une taille de lot de 32.
En mode Prefill Heavy, le débit augmente plus rapidement avec la concurrence. Dell passe de 115.85 tok/s à 3 794,52 tok/s, tandis que GIGABYTE affiche le meilleur résultat global, passant de 113.34 tok/s à 4 133,76 tok/s pour une taille de lot de 64. HP atteint 3 624,73 tok/s. GIGABYTE creuse l'écart pour les tailles de lot plus importantes, notamment à partir de 32.
Dans Decode Heavy, les trois systèmes restent très proches les uns des autres à faible niveau de concurrence, avant que de légers écarts n'apparaissent à forte concurrence. Dell affiche des performances allant de 29.11 tok/s à 1 077,07 tok/s, GIGABYTE de 28.64 tok/s à 1 068,92 tok/s et HP de 28.68 tok/s à 1 000,20 tok/s. Dell conserve une légère avance sur la majeure partie de la charge de travail, GIGABYTE le suivant de très près, tandis que HP accuse un léger retard pour les lots de grande taille.
En conditions ISL/OSL égales, Dell affiche des performances allant de 10.41 tok/s à 498.56 tok/s pour une taille de lot de 64, tandis que GIGABYTE prend légèrement l'avantage en haut de gamme, passant de 9.76 tok/s à 509.18 tok/s. HP est légèrement en retrait par rapport aux deux systèmes, avec des performances comprises entre 9.25 tok/s et 477.25 tok/s. L'écart entre les systèmes reste relativement faible tout au long de la charge de travail, en particulier aux niveaux de concurrence faibles et moyens.
En mode Prefill Heavy, les performances s'améliorent sensiblement sur les trois systèmes. Dell passe de 25.91 tok/s à 1 079,19 tok/s, tandis que GIGABYTE passe de 24.25 tok/s à 1 071,07 tok/s. HP atteint 988.82 tok/s avec une taille de lot de 64. Les performances de Dell et GIGABYTE restent quasiment identiques sur la majeure partie du test, Dell conservant un léger avantage au niveau de concurrence le plus élevé.
En mode Décodage intensif, le débit reste globalement nettement inférieur, comme prévu pour une charge de travail axée sur le décodage sur un modèle plus grand. Le débit de Dell varie de 6.49 tok/s à 297.82 tok/s, celui de GIGABYTE de 6.10 tok/s à 297.23 tok/s et celui de HP de 5.77 tok/s à 276.55 tok/s. Dell et GIGABYTE sont au coude à coude tout au long du test, tandis que HP accuse un léger retard constant sur les deux systèmes pour les lots de grande taille.
En conditions ISL/OSL égales, Dell affiche des performances allant de 59.05 tok/s à 817.82 tok/s pour une taille de lot de 64, tandis que GIGABYTE se situe entre 59.81 tok/s et 809.88 tok/s. HP est légèrement en retrait, avec des performances passant de 56.51 tok/s à 780.21 tok/s. Les performances de Dell et GIGABYTE restent quasiment identiques sur la majeure partie de la plage de tests, seules de légères variations apparaissant pour les tailles de lot plus importantes.
En mode Prefill Heavy, le débit augmente significativement avec la concurrence. Dell passe de 144.81 tok/s à 1 756,99 tok/s, tandis que GIGABYTE affiche la meilleure progression globale, passant de 147.55 tok/s à 1 862,40 tok/s pour une taille de lot de 64. HP atteint 1 751,17 tok/s, restant compétitif mais légèrement en retrait par rapport aux deux autres systèmes en haut de gamme. GIGABYTE prend une légère avance à partir d'une taille de lot d'environ 32 et la conserve jusqu'à la fin du test.
En mode décodage intensif, les trois systèmes affichent des performances très proches sur la majeure partie de la charge de travail. Dell atteint des débits allant de 36.69 tok/s à 427.48 tok/s, GIGABYTE de 36.92 tok/s à 417.42 tok/s et HP de 35.30 tok/s à 403.32 tok/s. Dell conserve un léger avantage pour les lots les plus importants, tandis que HP est légèrement en retrait par rapport à Dell et GIGABYTE sur l'ensemble de la charge de travail axée sur le décodage.
En termes de débit ISL/OSL égal, Dell affiche un débit allant de 98.65 tok/s à 1 379,26 tok/s pour une taille de lot de 64, tandis que GIGABYTE oscille entre 100.20 tok/s et 1 308,79 tok/s. HP reste compétitif sur l'ensemble du test, avec un débit en hausse de 97.06 tok/s à 1 354,23 tok/s. HP prend brièvement la tête pour plusieurs tailles de lot faibles et moyennes, mais Dell affiche finalement le meilleur débit global pour les lots les plus élevés.
En mode Prefill Heavy, le débit augmente considérablement sur les trois systèmes. Dell passe de 240.43 tok/s à 3 041,72 tok/s, tandis que GIGABYTE affiche le meilleur résultat global, passant de 245.92 tok/s à 3 088,62 tok/s pour une taille de lot de 64. HP atteint 2 857,80 tok/s. GIGABYTE prend une avance significative dès la taille de lot de 4 et la conserve jusqu'à la fin du test.
En mode Décodage intensif, Dell affiche la meilleure évolutivité globale. Son débit varie de 60.91 tok/s à 705.77 tok/s, tandis que celui de GIGABYTE passe de 61.53 tok/s à 639.80 tok/s et celui de HP de 59.85 tok/s à 635.25 tok/s. HP prend brièvement l'avantage pour les petits lots, mais Dell reprend la tête pour les niveaux de concurrence plus élevés, affichant finalement le meilleur débit de décodage du groupe.
Le tableau ci-dessous récapitule le débit de sortie de jetons maximal observé lors des tests de traitement distribué (PP=2) sur les systèmes Dell, GIGABYTE et HP à double Spark. Chaque valeur représente le débit de sortie maximal mesuré (tok/s) pour ce scénario de charge de travail et la taille de lot testée. Les valeurs en gras indiquent le système le plus performant pour ce scénario de charge de travail spécifique.
| Modèle | Scénario (BS – 64) | Sortie maximale Dell | Puissance de crête GIGABYTE | Puissance de crête HP |
|---|---|---|---|---|
| Modèles GPT-OSS | ||||
| GPT-OSS-120B | Égalité ISL/OSL | 463.97 tok/s | 497.26 tok/s | 504.88 tok/s |
| GPT-OSS-120B | Préremplissage lourd | 419.56 tok/s | 417.34 tok/s | 441.63 tok/s |
| GPT-OSS-120B | Décode Heavy | 451.18 tok/s | 494.37 tok/s | 474.85 tok/s |
| GPT-OSS-20B | Égalité ISL/OSL | 976.77 tok/s | 952.31 tok/s | 915.72 tok/s |
| GPT-OSS-20B | Préremplissage lourd | 852.39 tok/s | 802.37 tok/s | 757.05 tok/s |
| GPT-OSS-20B | Décode Heavy | 938.65 tok/s | 945.55 tok/s | 865.78 tok/s |
| Modèles de lamas | ||||
| Lama-3.1-8B-Instruct | Égalité ISL/OSL | 689.53 tok/s | 687.48 tok/s | 618.87 tok/s |
| Lama-3.1-8B-Instruct | Préremplissage lourd | 515.45 tok/s | 539.27 tok/s | 463.39 tok/s |
| Lama-3.1-8B-Instruct | Décode Heavy | 581.43 tok/s | 576.91 tok/s | 531.07 tok/s |
| Lama-3.1-8B-FP4 | Égalité ISL/OSL | 1427.39 tok/s | 1458.86 tok/s | 1413.51 tok/s |
| Lama-3.1-8B-FP4 | Préremplissage lourd | 884.22 tok/s | 954.23 tok/s | 843.57 tok/s |
| Lama-3.1-8B-FP4 | Décode Heavy | 1008.98 tok/s | 1007.23 tok/s | 943.73 tok/s |
| Lama-3.1-8B-FP8 | Égalité ISL/OSL | 1105.42 tok/s | 1089.85 tok/s | 1076.68 tok/s |
| Lama-3.1-8B-FP8 | Préremplissage lourd | 759.50 tok/s | 827.40 tok/s | 725.51 tok/s |
| Lama-3.1-8B-FP8 | Décode Heavy | 862.33 tok/s | 855.81 tok/s | 800.78 tok/s |
| Modèles Mistral et Qwen | ||||
| Mistral-Petit-3.1-24B | Égalité ISL/OSL | 249.77 tok/s | 255.09 tok/s | 239.09 tok/s |
| Mistral-Petit-3.1-24B | Préremplissage lourd | 216.01 tok/s | 214.38 tok/s | 197.92 tok/s |
| Mistral-Petit-3.1-24B | Décode Heavy | 238.44 tok/s | 237.97 tok/s | 221.41 tok/s |
Le principal enseignement de cette série de tests n'est pas lié à la performance des différents constructeurs sur telle ou telle charge de travail. Sur l'ensemble des modèles et des types de charges de travail testés, les trois implémentations Spark de Dell, GIGABYTE et HP ont affiché des performances très proches. De légers avantages sont apparus pour certaines tailles de lots, mais aucune plateforme ne s'est démarquée nettement, ni n'a systématiquement accusé un retard. Les acheteurs qui doivent choisir entre ces trois plateformes devraient privilégier la conception du châssis, le comportement thermique, les conditions de garantie et le service d'assistance plutôt que les écarts de performances mesurés par les benchmarks, qui reflètent la variabilité inhérente à tout système de bureau soumis à une charge soutenue.
Le résultat le plus intéressant est d'ordre méthodologique. Sur l'infrastructure 200 GbE reliant deux Spark, le choix entre le parallélisme tensoriel et le parallélisme pipeline est plus important que toute différence entre les trois constructeurs. Pour l'inférence par lots à un niveau de concurrence raisonnable, le parallélisme pipeline est plus adapté. Le trafic de réduction par couche du TP=2 ne survit pas à la transmission sur une liaison ConnectX-7 sans laisser des ressources de calcul inactives, et le coût de la bulle du pipeline du PP=2 est amorti dans le flux en régime permanent dès que le lot remplit le pipeline. La documentation NVIDIA préconise le TP par défaut pour une raison valable : leur positionnement principal pour Spark est la diffusion interactive de flux unique avec un TTFT serré, le seul cas où le TP=2 l'emporte nettement. Dès que la charge de travail ressemble à la gestion d'une infrastructure plutôt qu'à une interface de chat, le rapport de force s'inverse.
Cette inversion met en lumière ce qu'est et ce qu'est Spark. Un cluster Spark à deux nœuds est une plateforme de développement et d'apprentissage qui permet à un ingénieur d'observer directement le comportement de l'inférence distribuée sur un réseau suffisamment rapide pour simuler l'infrastructure d'un véritable centre de données, tout en étant suffisamment contraint pour révéler les goulots d'étranglement que les déploiements en production contournent à grande échelle.
Il est pertinent d'étudier les configurations Spark de plus grande envergure pour elles-mêmes, avec des charges de travail et des stratégies de parallélisme adaptées à cette échelle ; ce travail est prévu dans notre feuille de route. Par ailleurs, la prochaine expérience, qui succède à celle-ci, passe de l'inférence à l'entraînement : un modèle comportant moins d'un milliard de paramètres sera entraîné à partir de zéro sur un cluster double Spark, configuré pour reproduire les conditions de pré-entraînement distribuées de systèmes beaucoup plus importants. Ce travail est suspendu en attendant la mise en service de l'interface optique de notre nouveau commutateur de laboratoire de 800 Gb/s ; nous prévoyons de le publier une fois ce dernier opérationnel.
Bien que les serveurs Dell PowerEdge R4715 et R5715 soient deux produits distincts, ils doivent être considérés comme une matrice configurable. Cette matrice…
Le SSD NVMe 6600 ION de Micron atteint désormais 245.76 To, propulsant ainsi la gamme PCIe Gen5 QLC de l'entreprise, axée sur la capacité, dans la catégorie des quarts de pétaoctets. Micron…
La Radeon RX 9070 GRE n'est pas une nouvelle carte graphique. AMD l'a lancée l'année dernière exclusivement en Chine, et…
Les mises à jour de stockage se présentent généralement sous deux formes. Il y a la mise à niveau discrète, où un fournisseur intègre un nouveau processeur, affirme…
L'infrastructure de sauvegarde et de restauration a toujours été la partie du centre de données qui retient le plus l'attention lorsqu'un problème survient…
L'infrastructure de cyber-résilience occupe une place dans l'architecture d'entreprise que le stockage principal n'occupe pas. Lorsqu'un système tombe en panne…