NVIDIA mesure 42,5 % de débit en plus sur GSM8K avec DGX Spark
NVIDIA a publié le 27 octobre des essais de trois optimisations de l’inférence de Ling-3.0-flash sur un seul DGX Spark, avec un lot de taille un. Ce modèle à mélange d’experts compte 124 milliards de paramètres au total, dont 5,1 milliards sont actifs pour chaque unité de texte produite. Le profilage a indiqué que la lecture des poids limitait surtout la génération, notamment pour les experts et la projection de sortie.
NVIDIA a publié le 27 octobre des essais de trois optimisations de l’inférence de Ling-3.0-flash sur un seul DGX Spark, avec un lot de taille un. Ce modèle à mélange d’experts compte 124 milliards de paramètres au total, dont 5,1 milliards sont actifs pour chaque unité de texte produite. Le profilage a indiqué que la lecture des poids limitait surtout la génération, notamment pour les experts et la projection de sortie. L’article contient de véritables bancs d’essai : nier leur existence serait faux. Ce sont toutefois des mesures du fabricant sur un modèle et un appareil précis, pas une expérience indépendante ni une promesse pour tous les services d’inférence.
La première optimisation remplace le moteur FlashInfer MXFP4 de référence pour les experts par des noyaux Humming spécialisés. Sur une charge synthétique de 32 000 unités de texte en entrée et 2 000 en sortie, le temps par unité produite passe de 27,71 à 25,35 millisecondes. Le débit annoncé monte de 36,09 à 39,45 unités par seconde, soit 9,3 % de plus. La deuxième optimisation quantifie en FP8 uniquement la tête de sortie du modèle, dont les poids étaient lus en BF16 à chaque étape. Elle divise par deux le volume de lecture de cette couche. Avec Humming, le débit synthétique atteint 43,94 unités par seconde, soit 21,7 % au-dessus de la configuration de référence. Ces pourcentages n’ont de sens qu’avec leur base de comparaison.
La troisième technique utilise la couche NEXTN intégrée pour proposer plusieurs unités à la fois et les vérifier ensemble. Dans la charge synthétique, 3,90 unités sont acceptées en moyenne par tour. Les trois techniques combinées atteignent alors 102,88 unités par seconde, une hausse de 185,1 % par rapport à la base. NVIDIA signale pourtant un piège d’intégration : le modèle de proposition doit partager le module entier de la tête de sortie FP8 avec le modèle principal. Partager seulement le tenseur des poids peut provoquer silencieusement une interprétation erronée, faire tomber la longueur acceptée à 1,00 et rendre l’ensemble plus lent que la base non optimisée. Des paramètres activés ne prouvent pas que le bon chemin fonctionne réellement.
L’article donne aussi une comparaison sur les 1 319 questions du jeu GSM8K. Avec les mêmes exemples de départ et réglages d’échantillonnage, le débit de génération passe de 37,81 à 53,89 unités par seconde : la hausse mesurée est de 42,5 %. La latence moyenne va de 15,21 à 11,49 secondes, soit une baisse de 24,5 %. La précision mesurée est de 96,89 % puis 96,82 %; NVIDIA dit ne pas observer de changement statistiquement détectable. Le temps moyen avant la première unité est de 0,207 puis 0,214 seconde, ce qui n’est pas une amélioration. Les réponses répétitives du test synthétique facilitent la prédiction; le nombre moyen d’unités acceptées tombe à 2,68 dans GSM8K.
Il serait donc trompeur d’annoncer que toute inférence MoE devient « trois fois plus rapide ». Les gains de 185,1 % sur la charge synthétique et de 42,5 % sur les questions GSM8K répondent à des protocoles différents. Humming et FP8 diminuent le coût de chaque étape, tandis que la prédiction multiple réduit le nombre d’étapes; leur combinaison dépend d’un partage correct du module. Un exploitant devrait figer son modèle, sa version logicielle et sa base, puis mesurer sur ses propres requêtes débit, latence complète, première réponse et exactitude. Les résultats de NVIDIA offrent une méthode, non une garantie générale.
Sources
FAQ
Quel modèle et quel appareil ont été testés ?
NVIDIA a publié le 27 octobre des essais de trois optimisations de l’inférence de Ling-3.0-flash sur un seul DGX Spark, avec un lot de taille un. Ce modèle à mélange d’experts compte 124 milliards de paramètres au total, dont 5,1 milliards sont actifs pour chaque unité de texte produite. Le profilage a indiqué que la lecture des poids limitait surtout la génération, notamment pour les experts et la projection de sortie. L’article contient de véritables bancs d’essai : nier leur existence serait faux. Ce sont toutefois des mesures du fabricant sur un modèle et un appareil précis, pas une expérience indépendante ni une promesse pour tous les services d’inférence.
Que mesure la comparaison GSM8K ?
L’article donne aussi une comparaison sur les 1 319 questions du jeu GSM8K. Avec les mêmes exemples de départ et réglages d’échantillonnage, le débit de génération passe de 37,81 à 53,89 unités par seconde : la hausse mesurée est de 42,5 %. La latence moyenne va de 15,21 à 11,49 secondes, soit une baisse de 24,5 %. La précision mesurée est de 96,89 % puis 96,82 %; NVIDIA dit ne pas observer de changement statistiquement détectable. Le temps moyen avant la première unité est de 0,207 puis 0,214 seconde, ce qui n’est pas une amélioration. Les réponses répétitives du test synthétique facilitent la prédiction; le nombre moyen d’unités acceptées tombe à 2,68 dans GSM8K.
Pourquoi le gain synthétique de 185,1 % ne se généralise-t-il pas ?
Il serait donc trompeur d’annoncer que toute inférence MoE devient « trois fois plus rapide ». Les gains de 185,1 % sur la charge synthétique et de 42,5 % sur les questions GSM8K répondent à des protocoles différents. Humming et FP8 diminuent le coût de chaque étape, tandis que la prédiction multiple réduit le nombre d’étapes; leur combinaison dépend d’un partage correct du module. Un exploitant devrait figer son modèle, sa version logicielle et sa base, puis mesurer sur ses propres requêtes débit, latence complète, première réponse et exactitude. Les résultats de NVIDIA offrent une méthode, non une garantie générale.