NVIDIA détaille trois optimisations d’inférence pour DGX Spark

NVIDIA a indiqué trois les optimisations logicielles peuvent considérablement améliorer l’inférence sur DGX Spark lors de l’exécution du modèle Ling-3.0-flash d’Inclusion IA, les plus grands gains proviennent du décodage spéculatif une fois les composants configurés pour fonctionner ensemble. Dans un article publié le 27 octobre 2026, la société a rapporté une génération de tokens plus rapide et une latence de bout en bout plus faible, tout en avertissant que un erreur d’intégration peut ralentir la configuration combinée par rapport à la base non optimisée.

Ce que NVIDIA a mesuré

L’évaluation a utilisé Ling-3.0-flash-fp4, un modèle mixte d’experts avec 124 milliards de paramètres totaux et 5.1 milliards de paramètres actifs par jeton, selon le post de NVIDIA. La base suivait la configuration de la société dans le livre de cuisine, incluant FlashInfer MXFP4 les noyaux MoE, NVIDIA CUTLASS dense GEMM et fp32 sortie de tête LM. NVIDIA a indiqué que le profilage montrait que le chemin de décodage était limité par la mémoire, avec des lectures pondérées dominant le temps d’exécution, et que le calcul MoE et la projection de la couche de sortie étaient les principales cibles d’optimisation.

Sur une charge de travail synthétique avec 32,000 jetons d’entrée, 2,000 jetons de sortie et 1 taille de lot, la première optimisation, l’échange du backend Humming MXFP4 MoE, la réduction du temps par jeton de sortie de 27.71 ms à 25.35 ms et l’augmentation du débit de décodage de 36.09 tok/s à 39.45 tok/s, ou 9.3% par rapport à la baseline, selon NVIDIA. L’ajout en ligne d’une quantification FP8 LM-head a réduit le TPOT à 22.76 ms et a augmenté le débit à 43.94 tok/s, soit un gain cumulé de 21.7% par rapport à la base.

La troisième technique, le décodage spéculatif par prédiction multi-jetons avec NEXTN, a eu le plus grand effet lors du test synthétique. NVIDIA a indiqué que la pile complète d’optimisation trois avait ramené TPOT à 9.72 ms et augmenté le débit de décodage à 102.88 tok/s, soit une amélioration 185.1% par rapport à la base de cette configuration synthétique. La société a indiqué que la durée d’acceptation du MTP avait atteint 3.90 jetons par tour lors de ce test, mais a averti que le résultat n’établit pas de gains comparables sur d’autres charges de travail.

Les résultats de GSM8K de bout en bout furent plus modestes

NVIDIA a également rapporté une comparaison plus stricte de bout en bout sur toutes les questions de 1,319 GSM8K tests utilisant des indications cinq-shot, des 0.6 de température, top_p 0.95, top_k 29 et max_tokens 32,768, avec la chaîne de pensée activée. Dans cette série, la base affichait 26.45 ms TPOT et 37.81 tok/s, tandis que la configuration entièrement optimisée atteignait 18.56 ms TPOT et 53.89 tok/s, soit une augmentation 42.5% du débit. La latence moyenne est passée de 15.21 secondes à 11.49 secondes, soit une réduction 24.5%, tandis que GSM8K précision est passée de 96.89% à 96.82%, soit une différence de 0.08 points de pourcentage, selon le post.

L’entreprise a indiqué que l’écart entre les gains de charge synthétique et réels reflétait plusieurs facteurs, notamment des sorties synthétiques plus répétitives, un échantillonnage plus simple et avide dans le test synthétique et des sorties réelles plus courtes, qui diluent les coûts fixes de chaque étape de décodage. NVIDIA a noté que la longueur médiane GSM8K sortie était d’environ 310 tokens, contre une sortie synthétique fixe 2,000 tokens, et a déclaré que le benchmark synthétique exagère donc les avantages du décodage spéculatif pour d’autres charges de travail.

La mise en garde sur l’intégration est importante

NVIDIA a indiqué que les techniques trois ne se recoupent pas conceptuellement : le bourdonnement et la quantification FP8 têtes LM réduisent le coût de chaque étape de décodage, tandis que MTP réduit le nombre d’étapes. Mais l’entreprise a également signalé un problème de déploiement. Lorsque la quantification en ligne FP8 tête LM et MTP sont activées ensemble, le modèle brouillon doit partager le module LM-head complet avec le modèle cible. Sans cette interface, NVIDIA a indiqué que le framework peut silencieusement retomber dans une configuration défaillante où la longueur d’acceptation tombe à 1.00 et le débit descend en dessous de la base.

L’avertissement pratique du post est que la validation de démarrage compte autant que les chiffres de benchmark. NVIDIA a indiqué que les développeurs devraient vérifier que chaque optimisation est active au lancement plutôt que d’inférer l’état de configuration uniquement à partir des performances ultérieures. L’article ne fournissait pas de catalyseur programmé au-delà des directives publiées.