Test du Supermicro JumpStart : Une semaine avec une carte mère NVIDIA HGX B200

Le programme JumpStart de Supermicro JumpStart adopte une approche radicalement différente en matière d'évaluation matérielle. Au lieu d'une courte démonstration scénarisée dans un environnement de laboratoire partagé, JumpStart offre aux clients éligibles un accès gratuit et limité dans le temps à un catalogue de serveurs de production réels. Des nouvelles plateformes X14 avec Intel Xeon 6 aux systèmes H14 équipés de processeurs AMD EPYC de 5e génération et de puissantes configurations GPU HGX, les clients réservent des systèmes, se connectent à distance et exécutent leurs propres charges de travail comme si le matériel était installé dans leur propre baie.

La valeur ajoutée pour l'entreprise se révèle pleinement lorsqu'on prend des décisions rapides et éclairées concernant la plateforme. Mettre en place une preuve de concept réaliste pour l'IA ou le calcul haute performance implique généralement d'attendre le matériel d'évaluation, de coordonner les efforts de plusieurs fournisseurs et d'espérer que la configuration de test soit suffisamment proche de celle prévue pour le déploiement. JumpStart élimine ces contraintes. Les équipes peuvent valider les performances, vérifier la compatibilité logicielle, analyser la consommation d'énergie et le comportement thermique, et comparer les architectures sans mobiliser les ressources de leur laboratoire interne ni expédier une palette de serveurs à l'autre bout du pays. Pour la plupart des organisations, une semaine consacrée à la configuration optimale suffit à confirmer l'adéquation d'une plateforme à leurs besoins ou à l'éliminer avant tout engagement.

Ce qui rend JumpStart particulièrement attractif, ce n'est pas seulement le nombre de systèmes en ligne, mais aussi la richesse des technologies que Supermicro est prêt à dévoiler. Parmi les options les plus demandées figurent les serveurs GPU X14 équipés de processeurs Intel Xeon 6 et d'accélérateurs NVIDIA, les plateformes H14 optimisées pour le calcul haute performance avec des processeurs AMD EPYC de 5e génération, et des systèmes dédiés au stockage combinant des processeurs modernes et une architecture 100 % NVMe. Supermicro propose déjà un accès aux systèmes HGX B200 et B300 pour l'entraînement et l'inférence en IA, et utilise JumpStart pour offrir un aperçu anticipé, sous accord de confidentialité, des plateformes de nouvelle génération qui ne sont pas encore commercialisées à grande échelle. Aucun autre constructeur n'a fait preuve d'une telle détermination à transformer une infrastructure de pré-commercialisation en un laboratoire distant structuré et reproductible.

La plupart des environnements de démonstration des fournisseurs se limitent à des laboratoires de solutions guidés ou à des environnements de test produits restreints. Ces derniers sont utiles pour se familiariser avec les outils de gestion et les flux d'orchestration, mais offrent rarement un accès root à un serveur de pointe ou la liberté d'installer et d'exécuter sa propre infrastructure. JumpStart fonctionne bien plus comme une baie de prêt dans un centre de données distant. Lorsque vous réservez un système spécifique, vous bénéficiez d'un contrôle total via SSH, VNC et IPMI pendant toute la durée de la réservation, et Supermicro efface et reconstruit l'environnement avant que le client suivant ne l'utilise. En pratique, cela ressemble moins à une démonstration marketing qu'à une session courte et ciblée dans un laboratoire distant parfaitement géré.

Pour cette analyse, Supermicro a donné à StorageReview un accès à JumpStart exactement comme un client l'utiliserait. Nous avons planifié une session sur un Système GPU X14 10U Le serveur était équipé d'une carte mère NVIDIA HGX B200 à 8 GPU et de deux processeurs Intel Xeon Platinum 6960P de 6e génération. Il était configuré avec 3 To de mémoire DDR5-6400 ECC, un mélange de SSD NVMe M.2 et U.2 pour le stockage local, et huit GPU B200, chacun doté de 180 Go de mémoire HBM3e. Pendant une semaine, nous avons utilisé cette plateforme pour tester ponctuellement les charges de travail d'IA et le comportement du système, en nous concentrant sur les questions que se posent les acheteurs potentiels avant de s'engager dans une infrastructure de nouvelle génération.

Notre semaine dans le programme Supermicro JumpStart

Dès l'ouverture de notre période de réservation, le portail JumpStart est devenu la plateforme centrale de nos tests. Le tableau de bord initial, présenté ci-dessous, affichait le calendrier de la réservation et fournissait tout le nécessaire pour démarrer, notamment les identifiants SSH pour l'environnement Ubuntu distant et un accès IPMI complet. La disponibilité immédiate de ces deux interfaces nous a permis de commencer la validation du système en quelques minutes, sans attendre la mise en service ni l'intervention du support.

La première étape de notre processus consistait à vérifier que le matériel était prêt. À l'aide de la page Vue d'ensemble du système du portail (voir la capture d'écran ci-dessous), nous avons vérifié que le châssis était sous tension, que les deux processeurs étaient détectés, que la mémoire était entièrement installée et que le BMC indiquait un état système optimal. Ce contrôle rapide est devenu une pratique courante lors de nos évaluations en laboratoire, et la visibilité à distance offerte par le portail a considérablement simplifié le processus.

Une fois le système validé, nous sommes passés à la phase de développement pratique. Le chargement des fichiers pour les ressources de test s'effectuait directement via l'interface JumpStart, ce qui éliminait les difficultés habituelles liées à la préparation des jeux de données sur une plateforme distante. Nous nous connections ensuite via SSH pour le déploiement des charges de travail et utilisions la console distante via IPMI lorsque nous avions besoin d'un accès bas niveau ou pour observer le comportement au démarrage.

Tout au long de la semaine, le flux de travail s'est avéré très similaire à l'utilisation du matériel dans notre propre laboratoire. Nous avons pu démarrer, arrêter et itérer rapidement sur les charges de travail, redémarrer la plateforme au besoin et surveiller le comportement du matériel sans solliciter le support de Supermicro. L'accès au niveau du système d'exploitation et le contrôle total hors bande ont permis de garantir un environnement prévisible et efficace pour les cycles de test courts.

À la fin de la réservation, le système a été automatiquement récupéré et réinitialisé, clôturant ainsi la mission sans problème. Cette structure prévisible nous a permis de nous concentrer sur les tests plutôt que sur la logistique et de tirer pleinement parti de la période d'accès limitée.

Performances de stockage GPUDirect

L'un des tests que nous avons effectués sur la plateforme Supermicro X14 était le test Magnum IO GPUDirect Storage (GDS). GDS est une fonctionnalité développée par NVIDIA qui permet aux GPU de contourner le CPU lors de l'accès aux données stockées sur des disques NVMe ou d'autres périphériques de stockage haute vitesse. Au lieu de faire transiter les données par le CPU et la mémoire système, GDS permet une communication directe entre le GPU et le périphérique de stockage, réduisant ainsi considérablement la latence et améliorant le débit de données.

Comment fonctionne le stockage GPUDirect

Traditionnellement, lorsqu'un GPU traite des données stockées sur un disque NVMe, ces données doivent d'abord transiter par le CPU et la mémoire système avant d'atteindre le GPU. Ce processus engendre des goulots d'étranglement, le CPU jouant le rôle d'intermédiaire, ce qui augmente la latence et consomme des ressources système précieuses. GPUDirect Storage élimine cette inefficacité en permettant au GPU d'accéder directement aux données depuis le périphérique de stockage via le bus PCIe. Ce chemin direct réduit la surcharge liée aux transferts de données, permettant ainsi des transferts plus rapides et plus efficaces.

Les charges de travail d'IA, notamment celles impliquant l'apprentissage profond, sont très gourmandes en données. L'entraînement de grands réseaux neuronaux nécessite le traitement de téraoctets de données, et tout retard dans le transfert de données peut entraîner une sous-utilisation des GPU et des temps d'entraînement plus longs. GPUDirect Storage relève ce défi en garantissant que les données sont transmises au GPU le plus rapidement possible, minimisant ainsi les temps d'inactivité et maximisant l'efficacité de calcul.

En outre, GDS est particulièrement utile pour les charges de travail impliquant la diffusion de grands ensembles de données, comme le traitement vidéo, le traitement du langage naturel ou l'inférence en temps réel. En réduisant la dépendance au processeur, GDS accélère le déplacement des données et libère les ressources du processeur pour d'autres tâches, améliorant ainsi encore les performances globales du système.

Au-delà de la bande passante brute, GPUDirect avec NVMe-oF (TCP/RDMA) offre également des E/S à très faible latence. Ainsi, les GPU ne manquent jamais de données, ce qui en fait le système idéal pour l'inférence d'IA en temps réel, les pipelines d'analyse et la relecture vidéo.

Débit de lecture séquentielle GDSIO

Lors de nos tests de lecture séquentielle GDSIO sur la plateforme B200, la charge de travail initiale était modeste, avec un seul thread atteignant environ 14 à 15 Gio/s, selon la taille des blocs. Dès que nous avons augmenté le nombre de threads et la taille des blocs, les performances se sont rapidement améliorées. Le passage à 2 et 4 threads a permis d'atteindre un débit de 20 à 36 Gio/s, démontrant ainsi l'excellente montée en puissance du système grâce au parallélisme.

L'accélération réelle s'est produite à partir de huit threads, la plupart des charges de travail se stabilisant alors autour de 30 Gio/s. Les blocs de grande taille ont été les plus performants, avec des résultats constamment excellents pour les tailles de 5 Mo et 10 Mo, quel que soit le nombre de threads.

Le débit a finalement atteint un maximum d'environ 43 Gio/s avec une taille de bloc de 10 Mo à 256 threads, ce qui représente le taux de lecture séquentiel soutenu le plus élevé que nous ayons observé dans ce test.

Latence de lecture séquentielle GDSIO

En termes de latence, la charge de travail a démarré avec une excellente réactivité : les lectures mono-thread se situaient entre 0.06 et 0.1 ms pour les petits blocs. À mesure que le nombre de threads augmentait, la latence diminuait progressivement, restant inférieure à 1 ms jusqu’à 8 threads pour la plupart des charges de travail.

Au-delà de 16 threads, les tailles de blocs plus importantes ont commencé à engendrer des latences de plusieurs millisecondes, le chemin de stockage étant de plus en plus saturé. La latence maximale a été observée à la fin du test, avec une taille de bloc de 10 Mo et 256 threads, atteignant un pic d'un peu plus de 1.2 seconde (environ 1 200 ms), ce qui correspond à une charge extrême conçue pour saturer le système.

Débit d'écriture séquentielle GDSIO

Pour les écritures séquentielles, les performances étaient beaucoup plus stables qu'en lecture. La charge de travail se stabilisait rapidement, la plupart des combinaisons de threads et de tailles de blocs se situant autour de 6.3 à 6.5 Gio/s. Cela indique que le débit d'écriture atteint un plafond constant très tôt, probablement lié au support de stockage et à la mise en mémoire tampon plutôt qu'aux limitations du GPU ou du PCIe.

Augmenter le nombre de threads n'a pas eu d'impact significatif, le débit restant quasiment inchangé entre 2 et 128 threads. Le seul résultat notable est survenu en fin de test : avec une taille de bloc de 10 Mo et 256 threads, le débit a atteint un pic de 18.2 Gio/s, démontrant un léger avantage lorsque le système exploite pleinement les files d'attente profondes et l'agrégation d'écritures.

Latence séquentielle d'écriture GDSIO

La latence d'écriture était initialement relativement faible, se situant entre 0.15 et 0.5 ms pour les charges de travail monothread avec des blocs de petite taille. Avec l'augmentation du nombre de threads, la latence a crû beaucoup plus rapidement qu'en lecture, atteignant 1 à 4 ms pour quatre threads et 4 à 9 ms pour huit threads.

Dès que nous avons atteint 32 threads avec des blocs de plus grande taille, la latence a fortement augmenté, les blocs de 5 et 10 Mo passant dans la plage de 170 à 350 ms. Le cas le plus extrême était celui des blocs de 10 Mo avec 256 threads, qui a culminé à un peu moins de 3 secondes (environ 2 900 ms), illustrant clairement la rapidité avec laquelle le chemin d'écriture est saturé sous une charge parallèle importante.

Débit de lecture aléatoire GDSIO

Pour les lectures aléatoires, la charge de travail a rapidement augmenté. Les performances en mono-thread se situaient entre 11 et 31 Gio/s environ, selon la taille des blocs, les blocs plus volumineux bénéficiant immédiatement d'une bande passante plus élevée. Avec deux puis quatre threads, le débit a atteint 20 à 36 Gio/s, démontrant une excellente scalabilité dès les premières utilisations.

À partir de 8 threads, le système s'est stabilisé autour de 30 Gio/s, un résultat très similaire à celui observé lors du test de lecture séquentielle. Le meilleur résultat a été obtenu avec une taille de bloc de 10 Mo et 256 threads, atteignant un pic d'environ 42.7 Gio/s.

Latence de lecture aléatoire GDSIO

La latence de lecture aléatoire était initialement très faible, de l'ordre de 0.15 à 0.4 ms pour les charges de travail mono-thread avec des blocs de petite taille. À mesure que le nombre de threads augmentait, la latence s'élevait progressivement, restant inférieure à 1 ms jusqu'à 4 threads et atteignant environ 1 à 3 ms à 8 threads.

Dès que nous sommes passés à 32 threads et à des blocs plus volumineux, la latence a augmenté plus fortement, les transferts de 5 et 10 Mo atteignant des valeurs comprises entre 30 et 55 ms. Le cas le plus extrême a été observé avec 256 threads et une taille de bloc de 10 Mo, où la latence a culminé à un peu plus de 1.1 seconde (environ 1180 ms).

 

Débit d'écriture aléatoire GDSIO

Les performances en écriture aléatoire étaient très homogènes, la plupart des tailles de blocs et des nombres de threads se situant autour de 5.8 à 6.1 Gio/s. La charge de travail a atteint ce niveau presque instantanément et n'a que très peu progressé avec l'ajout de threads supplémentaires, ce qui indique que le chemin d'écriture atteint rapidement sa limite.

La seule exception notable est apparue à la fin du test, où une taille de bloc de 10M à 256 threads a brièvement atteint 12.5Gio/s, bénéficiant probablement d'une mise en file d'attente profonde et d'une agrégation d'écritures sous une charge parallèle importante.

Latence d'écriture aléatoire GDSIO

La latence d'écriture aléatoire était initialement relativement faible, avec des performances monocœur allant d'environ 0.6 à 1.2 ms pour les petits blocs et de 5 à 12 ms pour les transferts les plus importants. À mesure que la concurrence augmentait, la latence augmentait rapidement, atteignant 4 à 9 ms avec huit threads et 18 à 38 ms avec 32 threads.

Au-delà de ce seuil, le chemin d'écriture s'est saturé. Avec des blocs plus volumineux, la latence a atteint 150 à 380 ms à 64 threads, et une augmentation continue de la taille des blocs a fait grimper la latence de façon spectaculaire. Le cas le plus défavorable a été observé avec des blocs de 10 Mo et 256 threads, avec une latence maximale d'environ 4.4 secondes.

Service en ligne vLLM – Performances d'inférence LLM

vLLM est le moteur d'inférence et de diffusion à haut débit le plus populaire pour les LLM. Le benchmark de diffusion en ligne vLLM est un outil d'évaluation des performances qui mesure les capacités de diffusion réelles de ce moteur d'inférence sous des requêtes simultanées. Il simule les charges de travail de production en envoyant des requêtes à un serveur vLLM en cours d'exécution avec des paramètres configurables, tels que le débit de requêtes, la longueur des entrées/sorties et le nombre de clients simultanés. Le benchmark mesure des indicateurs clés, notamment le débit (jetons par seconde), le temps d'obtention du premier jeton et le temps par jeton de sortie (TPOT), permettant ainsi aux utilisateurs de comprendre les performances de vLLM sous différentes conditions de charge.

Nous avons testé les performances d'inférence sur une suite complète de modèles couvrant diverses architectures, échelles de paramètres et stratégies de quantification afin d'évaluer le débit sous différents profils de concurrence.

Performances du modèle dense

Les modèles denses suivent l'architecture LLM classique, où tous les paramètres et activations sont utilisés lors de l'inférence, ce qui engendre un traitement plus intensif en ressources de calcul que leurs homologues clairsemés. Afin d'évaluer de manière exhaustive les performances des différents modèles, en fonction de leur taille et des stratégies de quantification, nous avons comparé plusieurs configurations de modèles denses de la famille Llama 3.1 8B.

Notre suite de tests comprenait des évaluations de Meta Llama 3.1 8B sur trois formats de précision : la configuration standard, ainsi que les versions quantifiées FP8 et FP4 utilisant le format NVFP4 de NVIDIA. Il est important de noter que vLLM utilise actuellement le noyau Marlin pour les modèles quantifiés NVFP4, et que les gains de performance optimaux de ce format de quantification ne sont pas encore pleinement visibles dans ces benchmarks. De futures optimisations de vLLM ciblant les opérations natives du cœur tensoriel NVFP4 pourraient apporter des améliorations de performance supplémentaires. Cette stratégie de sélection de modèles permet une comparaison directe des performances tout en isolant l'impact de la quantification progressive sur le débit d'inférence.

Llama 3.1 8B Performance

Le modèle Llama 3.1 8B, en précision standard, présente les caractéristiques de mise à l'échelle suivantes en fonction du niveau de concurrence. En mode mono-utilisateur (BS=1), il atteint 279.27 tok/s par utilisateur, pour un débit total de 1 727,62 tok/s et un TPOT de 3.37 ms. À mesure que la taille des lots augmente, le débit par utilisateur diminue tandis que le débit total augmente. Avec BS=8, le modèle atteint 82.85 tok/s par utilisateur, pour un débit total de 3 386,48 tok/s et un TPOT de 3.28 ms. Les performances continuent de progresser jusqu'à BS=32 (56.46 tok/s par utilisateur, 8 274,66 tok/s au total) et BS=64 (52.70 tok/s par utilisateur, 13 707,66 tok/s au total).

Le modèle atteint son débit total maximal à la station de base 256 (BS=256), avec 32 797,67 tok/s, soit 30.64 tok/s par utilisateur et un TPOT de 16.13 ms. Cela représente une augmentation de 19 fois du débit total par rapport aux performances d'un utilisateur unique. Les valeurs de TPOT restent comprises entre 3 et 4 ms jusqu'à la station de base 64, puis augmentent jusqu'à 16.13 ms à la station de base 256.

Performances du Llama 3.1 8B FP8

La variante quantifiée FP8 présente des caractéristiques différentes. À BS=1, elle atteint 149.46 tok/s par utilisateur, avec un débit total de 9 565,20 tok/s et un TPOT de 3.44 ms. L’analyse de Pareto révèle trois points optimaux (BS=1, BS=128, BS=256).

À BS=128, le modèle fournit 44.12 tok/s par utilisateur avec un total de 19 198,40 tok/s et un temps de réponse de 11.04 ms. 

Le débit total maximal est atteint à BS=256 avec un total de 29 219,67 tok/s, soit 30.13 tok/s par utilisateur, et un TPOT de 13.26 ms. La variante FP8 atteint un débit total maximal inférieur à celui de la précision standard (29.2 K contre 32.8 K tok/s).

Performances du Llama 3.1 8B FP4

La configuration quantifiée FP4 affiche les résultats suivants : en mode mono-utilisateur (BS=1), elle atteint 279.73 tok/s par utilisateur, un débit total de 830.46 tok/s et un TPOT de 3.43 ms.

Le modèle FP4 présente sept points de frontière de Pareto. À la station de base 2 (BS=2), il offre un débit de 159.95 tok/s par utilisateur, soit un débit total de 928.60 tok/s, et un TPOT de 3.43 ms. Les performances continuent de progresser jusqu'à BS=4 (76.36 tok/s par utilisateur, soit un débit total de 1 631,69 tok/s) et BS=32 (76.09 tok/s par utilisateur, soit un débit total de 9 014,29 tok/s). Le modèle atteint son débit total maximal à BS=256, avec 29 340,89 tok/s, 30.13 tok/s par utilisateur et un TPOT de 16.18 ms.

Performances du modèle parcimonieux

Les modèles épars, notamment les architectures Mixture of Experts (MoE), constituent une approche émergente pour la mise à l'échelle efficace des modèles de langage. Ces architectures conservent un nombre total de paramètres élevé tout en n'activant qu'un sous-ensemble de paramètres par jeton, ce qui peut potentiellement améliorer les performances par paramètre actif.

Nous avons évalué deux architectures MoE : DeepSeek-R1, un modèle axé sur le raisonnement, et Qwen3 Coder 30B-A3B, une architecture clairsemée spécialisée dans la génération de code. DeepSeek-R1 est le modèle axé sur le raisonnement le plus répandu, présentant des performances nettement supérieures aux modèles de langage traditionnels. Le modèle Qwen3 Coder conserve l’intégralité de ses 30 milliards de paramètres tout en n’en activant que 3 milliards par jeton généré. Nous avons comparé les performances de Qwen3 Coder avec celles de ses variantes de quantification par défaut et par virgule flottante FP8 afin d’analyser les variations selon la stratégie de quantification.

Performances de DeepSeek-R1

Le modèle DeepSeek-R1 présente un comportement de mise à l'échelle intéressant en fonction de la taille des lots. En mode mono-utilisateur (BS=1), il atteint 30.24 tok/s par utilisateur, un débit total de 88.13 tok/s et un TPOT de 29.85 ms. Avec BS=4, les performances atteignent 29.77 tok/s par utilisateur et un débit total de 266.40 tok/s, pour un TPOT de 32.04 ms, soit le débit total maximal obtenu sur l'ensemble des configurations.

Les performances de DeepSeek-R1 plafonnent au-delà de BS=4. À BS=8, le débit par utilisateur chute brutalement à 14.98 tok/s, et cette baisse se poursuit pour des tailles de lots plus importantes, atteignant seulement 0.46 tok/s par utilisateur à BS=256. Le débit total reste relativement stable entre 200 et 260 tok/s de BS=4 à BS=256, car le modèle ne peut pas gérer un nombre accru de requêtes simultanées sur un seul nœud, ce qui entraîne une augmentation de la latence sans gain de débit significatif. Il est important de noter que le B200 DGX est l'une des rares solutions mono-serveur capables d'exécuter ce modèle complexe.

Performances du codeur Qwen3 30B-A3B

Le codeur Qwen3 en précision standard présente les performances suivantes en fonction du niveau de concurrence. En mode mono-utilisateur (BS=1), le modèle atteint 178.30 tok/s par utilisateur, un débit total de 527.25 tok/s et un TPOT de 5.46 ms. Avec BS=2, les performances atteignent 174.56 tok/s par utilisateur, un débit total de 718.70 tok/s et un TPOT de 5.60 ms. Lorsque la taille des lots augmente, le débit par utilisateur diminue tandis que le débit total continue de croître : avec BS=16, on obtient 127.76 tok/s par utilisateur, un débit total de 4 204,40 tok/s et un TPOT de 6.93 ms.

Le modèle atteint son débit total maximal à la station de base 256 (BS=256), soit 22 305,88 tok/s au total, avec 46.16 tok/s par utilisateur et un TPOT de 17.64 ms. La frontière de Pareto comprend huit points distincts, avec une entrée dupliquée à la station de base 32 (72.97 tok/s et 93.50 tok/s par utilisateur, correspondant probablement à des configurations différentes). Les valeurs de TPOT restent comprises entre 5 et 9 ms jusqu'à la station de base 64.

Performances du codeur Qwen3 30B-A3B FP8

La variante quantifiée FP8 présente les caractéristiques de performance suivantes : en mode mono-utilisateur (BS=1), elle offre un débit de 107.46 tok/s par utilisateur, un débit total de 317.75 tok/s et un TPOT de 9.16 ms. En mode BS=2, le modèle atteint 99.55 tok/s par utilisateur, un débit total de 409.87 tok/s et un TPOT de 9.86 ms.

Passage à des tailles de lots plus importantes : avec BS=8, le débit est de 54.60 tok/s par utilisateur, soit un total de 1 383,13 tok/s et un TPOT de 10.24 ms. Avec BS=32, ce débit atteint 48.78 tok/s par utilisateur, soit un total de 3 874,21 tok/s et un TPOT de 10.67 ms. Le débit total maximal est obtenu avec BS=256, soit 19 114,86 tok/s, 36.38 tok/s par utilisateur et un TPOT de 20.00 ms. Cela représente environ 86 % du débit maximal en précision standard.

Performances des types de données à micro-échelle

La microscaling représente une approche de quantification avancée qui applique des facteurs d'échelle précis à de petits blocs de pondérations plutôt qu'une quantification uniforme sur de grands groupes de paramètres. Le format NVFP4 de NVIDIA implémente cette technique grâce à une représentation en virgule flottante bloquée où chaque bloc de microscaling de 8 à 32 valeurs partage un exposant commun comme facteur d'échelle. Cette approche granulaire préserve la précision numérique tout en obtenant une représentation 4 bits, préservant ainsi la plage dynamique essentielle aux architectures de transformateurs. Ce format s'intègre à l'architecture Tensor Core de NVIDIA, permettant un calcul efficace en précision mixte avec décompression à la volée lors des opérations matricielles.

Nous avons évalué les modèles GPT OSS d'OpenAI à deux échelles de paramètres en utilisant la quantification NVFP4 : la variante 20 octets et la variante plus grande 120 octets. Ces résultats de référence démontrent les performances de la quantification à micro-échelle pour différentes tailles de modèles.

Performances du GPT-OSS-20B

Le modèle à 20 milliards de paramètres offre les performances suivantes pour différentes tailles de lots. En mode mono-utilisateur (BS=1), il atteint 299.28 tok/s par utilisateur, soit un débit total de 943.43 tok/s et un TPOT de 3.23 ms. En mode BS=2, le modèle maintient 299.19 tok/s par utilisateur, un débit total de 1 356,87 tok/s et un TPOT de 3.19 ms.

Passage à des tailles de lots plus importantes : BS=8 atteint 259.02 tok/s par utilisateur, pour un total de 5 149,59 tok/s et un TPOT de 3.42 ms, tandis que BS=16 offre 200.69 tok/s par utilisateur, pour un total de 7 765,73 tok/s et un TPOT de 3.77 ms. Le modèle continue de progresser jusqu’à BS=32 (168.34 tok/s par utilisateur, pour un total de 12 411,72 tok/s) et BS=64 (123.96 tok/s par utilisateur, pour un total de 16 931,47 tok/s).

Le débit total atteint 38 258,50 tok/s à la station de base 256, soit 65.08 tok/s par utilisateur et un TPOT de 9.39 ms. Cela représente une augmentation de 40.5 fois du débit total par rapport aux performances d'un utilisateur unique. Les valeurs de TPOT restent comprises entre 3 et 5 ms jusqu'à la station de base 32. La frontière de Pareto comprend huit points distincts.

Performances du GPT-OSS-120B

Le modèle à 120 octets de paramètres conserve les performances suivantes malgré l'augmentation du nombre de paramètres : en mode mono-utilisateur (BS=1), il atteint 248.62 tok/s par utilisateur, un débit total de 783.73 tok/s et un TPOT de 3.89 ms ; en mode BS=2, il atteint 240.99 tok/s par utilisateur, un débit total de 1 092,91 tok/s et un TPOT de 3.99 ms.

Les performances continuent de progresser avec l'augmentation de la taille des lots : BS=4 atteint 190.63 tok/s par utilisateur, pour un total de 2 096,73 tok/s et un TPOT de 4.22 ms, tandis que BS=8 offre 172.66 tok/s par utilisateur, pour un total de 3 692,10 tok/s et un TPOT de 4.54 ms. L'augmentation du débit se poursuit avec BS=16 (138.28 tok/s par utilisateur, pour un total de 5 751,41 tok/s), BS=32 (111.63 tok/s par utilisateur, pour un total de 8 646,05 tok/s) et BS=64 (88.64 tok/s par utilisateur, pour un total de 13 027,97 tok/s).

Le modèle atteint son débit total maximal à BS=256, avec 29 976,99 tok/s, soit 48.64 tok/s par utilisateur et un TPOT de 12.53 ms. Cela représente une augmentation de 38.2 fois du débit total par rapport aux performances d'un utilisateur unique. Le débit total maximal représente environ 78 % du débit maximal du modèle 20B. La frontière de Pareto comprend neuf points distincts, soit le plus grand nombre parmi tous les modèles testés.

Performances inattendues du modèle quantifié

Les résultats obtenus avec le modèle quantifié étaient inattendus et justifient une analyse plus approfondie. Dans plusieurs cas, les versions quantifiées NVFP4 et FP8 des modèles n'ont pas permis d'atteindre les gains de performance escomptés par rapport à leurs homologues en précision native. Par exemple, le modèle Llama 3.1 8B FP4 n'a atteint qu'un débit total de 830.46 tok/s à BS=1, contre 1 727,62 tok/s pour la variante en précision standard, malgré un débit par utilisateur similaire. Pour des tailles de lots plus importantes, bien que les modèles quantifiés se soient rapprochés du débit en précision standard (29 200 à 29 300 tok/s contre 32 800 tok/s à BS=256), les résultats globaux suggèrent que l'implémentation actuelle de vLLM n'est peut-être pas entièrement optimisée pour Blackwell.

Nous prévoyons de réaliser des tests supplémentaires sur vLLM et de le comparer également à TensorRT-LLM afin de déterminer les performances que les utilisateurs finaux peuvent attendre aujourd'hui.

Supermicro JumpStart révolutionne le jeu des preuves de concept en IA.

Le programme JumpStart de Supermicro tient ses promesses : un accès réel et illimité à du matériel de production, sans les contraintes logistiques, les délais de livraison ni les coûts de laboratoire d'un PoC traditionnel. Notre semaine JumpStart sur la plateforme X14 HGX B200 a démarré rapidement, s'est déroulée sans accroc et nous a permis d'évaluer les performances comme si nous utilisions du matériel installé dans nos propres racks.

Pour les organisations qui prennent rapidement des décisions concernant leur infrastructure d'IA, ce type d'accès à la plateforme permet de réduire des semaines de planification à quelques jours. Qu'il s'agisse de valider le débit du GPU, le comportement du stockage, les performances du modèle ou simplement de confirmer la compatibilité de la pile logicielle, JumpStart vous apporte des réponses en toute simplicité. Cette approche, qui privilégie la confiance dans l'évaluation du matériel, est très prometteuse et nous souhaiterions voir davantage de fournisseurs l'adopter.