NVIDIA présente 3 méthodes pour accélérer l'inférence MoE sur DGX Spark, avec un gain de 42,5 % de débit pour Ling-3.0-flash
NVIDIA a publié un billet technique qui montre comment accélérer l'inférence des modèles à mélange d'experts (MoE) sur un seul DGX Spark. Le modèle de test est Ling-3.0-flash d'inclusionAI (Ant Group), un MoE de 124 milliards de paramètres dont 5,1 milliards sont actifs par token, avec un contexte natif de 256K. NVIDIA a empilé trois optimisations: un nouveau backend de noyaux MoE, une couche de sortie en FP8 et le décodage spéculatif intégré au modèle. Sur les 1 319 questions de GSM8K, le débit de décodage passe de 37,81 à 53,89 tokens par seconde, soit +42,5 %, avec une latence moyenne réduite de 24,5 % et une précision inchangée de façon statistiquement détectable (96,89 % contre 96,82 %). Concrètement, le backend Humming remplace les noyaux MXFP4 de FlashInfer et compile ses noyaux à la volée en quelques secondes, contre plusieurs dizaines de minutes pour la voie CUTLASS, ce qui apporte +9,3 %. La tête de langage (LM head), une matrice de 157 184 x 2 560 en BF16 lue en entier à chaque token, est quantifiée en FP8 au chargement via SGLANGENABLEFP8LMHEAD=1, pour 43,94 tokens par seconde combinés à Humming. Enfin, la couche de prédiction NEXTN livrée avec le modèle (MTP) propose trois tokens vérifiés par groupes de quatre. Sur un test synthétique, le débit atteint 102,88 tokens par seconde, soit +185,1 %.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
L'intérêt tient au fait que le DGX Spark est une machine de bureau et non un nœud de centre de données. Les mesures montrent qu'un MoE de 124 milliards de paramètres peut répondre à un seul utilisateur nettement plus vite sur cette machine posée sur un bureau. Le profilage à taille de lot 1 indique que le décodage est limité par la mémoire: lire les poids du modèle domine le temps d'exécution, en particulier le calcul MoE et la tête de langage. Deux leviers en découlent: déplacer moins d'octets par étape et générer plus de tokens par cycle de vérification. Les trois techniques ne se recoupent pas, les deux premières réduisant le coût de chaque étape et la troisième le nombre d'étapes. Les gains restent toutefois dépendants de la charge: sur GSM8K, le taux d'acceptation du MTP tombe de 3,90 à 2,68 tokens par cycle, ce qui explique l'écart entre +185,1 % en synthétique et +42,5 % en conditions réelles.
Le DGX Spark repose sur la puce GB10 Grace Blackwell, avec 128 Go de mémoire unifiée, 273 Go/s de bande passante et jusqu'à un pétaFLOP en FP4 creux. NVIDIA le donne pour l'inférence de modèles jusqu'à 200 milliards de paramètres. La référence de départ suivait la recette officielle W4A8, avec des noyaux FlashInfer MXFP4, du GEMM dense CUTLASS et un chemin LM head en FP32, et affichait 27,71 ms par token (36,09 tokens par seconde) sur un test de 32K tokens en entrée et 2K en sortie. L'empilement n'est pas automatique: si la tête FP8 et le MTP sont activés ensemble, le brouillon doit partager le module complet de la tête de langage. Sinon, le framework retombe silencieusement sur un autre chemin et le brouillon lit les poids FP8 comme du BF16. La longueur d'acceptation tombe alors à 1,00 et le débit passe sous celui de la référence non optimisée. NVIDIA recommande donc de vérifier au démarrage que chaque optimisation est bien active, et renvoie vers le notebook du cookbook Ling pour reproduire la configuration.
Pas d'impact direct sur la France/UE