Pour être honnête, j'ai été surpris. Quand j'ai connecté deux unités DGX Spark en cluster et exécuté DeepSeek-V4-Flash, le résultat était 1,78x plus rapide en temps de génération total (temps réel sur le mur) par rapport au Mac Studio M3 Ultra — ce qui signifie qu'il a terminé la tâche en environ la moitié du temps. Et ce, avec le DGX Spark exécutant le modèle FP8 officiel sans quantification supplémentaire.
En effectuant ces benchmarks, j'ai eu le sentiment que le point que je n'arrête pas de soulever était une nouvelle fois confirmé par les chiffres. À savoir :
La performance d'un LLM ne peut pas être mesurée uniquement par la vitesse de décodage (tokens par seconde, TPS) basée sur la bande passante mémoire.
La puissance de traitement GPU, la communication nœud à nœud, la hiérarchie mémoire, la qualité de quantification, la longueur de contexte, le traitement parallèle, etc. — "l'équilibre" de tous ces facteurs détermine l'expérience utilisateur réelle. Et le DGX Spark avait tout simplement un meilleur équilibre.
Le Benchmark Utilisé : le Coding Benchmark de shi3z
Pour la mesure, j'ai utilisé le benchmark de codage du Japanese LLM Benchmark de shi3z. La tâche consiste à "compléter une application de chat fonctionnant sur React en une seule génération." Le code généré est effectivement lancé dans Docker et automatiquement testé via Playwright pour la connexion, les amis, les messages privés et les mises à jour en temps réel, avec un score fonctionnel sur 80 points.
Les résultats de l'exécution de DeepSeek-V4-Flash Q4 (quantification 4 bits) sur un Mac Studio M3 Ultra via le moteur d'inférence ds4 d'antirez sont listés dans le dépôt de shi3z. Le tableau ci-dessous compare ces résultats avec ceux du cluster de 2 unités DGX Spark + FP8 officiel de cette fois-ci.
Résultats du Benchmark
Pourquoi il "Perd en tok/s mais Gagne en Temps Réel sur le Mur"
Si vous regardez le tableau et pensez : "Attendez, le Mac est plus rapide en tok/s", vous avez raison. En ne regardant que la vitesse instantanée de crachat d'un token (TPS de décodage), le Mac Studio M3 Ultra est 1,58x plus rapide. Cela est dû à l'énorme bande passante mémoire du Apple Silicon.
Cependant, il y a un piège ici. Pour compléter la même application de chat "score parfait 80/80", le Mac a écrit 8 036 tokens, tandis que le DGX Spark en a écrit 2 866. Soit une différence d'environ 2,8x.
Les deux ont utilisé DeepSeek-V4-Flash sans dégradation de qualité officielle, mais il est naturel d'interpréter que le côté Mac, quantifié en Q4, est devenu redondant, tandis que le côté Spark, fonctionnant en FP8 pleine qualité, est resté concis. C'est un phénomène courant où l'impact de la quantification sur la distribution de sortie n'apparaît pas dans la vitesse de décodage mais affecte silencieusement la stratégie de génération.
En conséquence, le calcul ressemble à ceci :
Temps Réel sur le Mur = (Tokens de Sortie) ÷ (tok/s)
Mac : 8 036 ÷ 26,2 = 307 secondes Nous : 2 866 ÷ 16,6 = 172 secondes
Perdre en tok/s mais gagner en temps réel sur le mur signifie "atteindre la même réponse correcte en moins d'étapes". En utilisation pratique, ce que les humains expérimentent, c'est le "temps jusqu'à ce que la tâche soit terminée", pas le tok/s instantané.
Configuration Utilisée
- Matériel : DGX Spark × 2 (NVIDIA GB10, basé sur Blackwell, 128 Go de mémoire unifiée chacun)
- Interconnexion de Nœuds : Connexion directe via ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, backend distribué PyTorch)
- Moteur d'Inférence : La recette d'Aiden, qui intègre b12x (un ensemble de noyaux CuTe DSL spécifiques au GB10) dans vLLM 0.21.1dev
- Modèle : DeepSeek-V4-Flash FP8 officiel (154 Go, attention FP8, MoE MXFP4 — c'est le format officiel publié par DeepSeek)
- Contexte : 524 288 tokens (512K), util 0,82, cache KV 19,85 GiB, concurrence 3,89×
- Prédiction Multi-Tokens (MTP) : Décodage spéculatif avec un taux d'acceptation d'environ 62% (gagnant en vitesse sans sacrifier la qualité de sortie)
Un Regard Plus Approfondi sur la Performance
Au-delà des chiffres de ce benchmark, j'ai mesuré séparément les vitesses pures de décodage et de préremplissage :
- Vitesse de Décodage Pure (Texte court, hors TTFT) : Stable à environ 39 tok/s
- Vitesse de Préremplissage (Grand contexte) : 1 277 tok/s (C'est environ 6,5x plus rapide que les 196 tok/s de l'ancienne configuration sans noyaux b12x)
- Décodage avec Long Contexte : Même en augmentant de 8K → 64K → 128K → 256K → 512K → 768K, la vitesse de décodage n'a pas chuté brusquement ; en fait, elle s'est accélérée (106 tok/s à 768K). Cela est dû au fait que l'Attention Éparse (DSA) de DeepSeek est implémentée nativement dans les noyaux b12x, rendant les calculs d'attention presque indépendants de la longueur du contexte.
C'est un Résultat avec "Aucune Quantification, Pleine Qualité"
Un autre point que je veux souligner est que le côté DGX Spark n'a utilisé aucune quantification supplémentaire sur le modèle. Nous avons chargé les 154 Go officiels distribués sur HuggingFace tels quels et les avons exécutés dans le format de quantification officiel conçu par DeepSeek : attention FP8 + MoE MXFP4.
Dans le monde des LLM locaux, il est devenu courant de compresser les énormes modèles en IQ2 (2 bits) ou Q4 pour les faire fonctionner, mais cela enlève définitivement de la qualité. En fait, j'ai précédemment essayé la version IQ2XXS (2 bits) de DeepSeek-V4-Flash et j'ai vu un résultat de 55/80 + effondrement du comportement de l'agent sur le même benchmark. La quantification n'est pas un repas gratuit.
Une configuration qui peut sécuriser 256 Go de mémoire unifiée avec deux DGX Sparks rend l'option "d'exécuter d'énormes modèles en pleine qualité" réalisable pour la première fois. Je pense que c'est une avancée plus significative que ne le suggèrent les chiffres.
Pourquoi l'"Équilibre" du Spark a Fonctionné
Décomposons les éléments techniques qui ont soutenu ce résultat :
- Suite de Noyaux b12x : Quatre types de noyaux (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, attention paginée FP8 et attention MLA éparse) écrits spécifiquement pour GB10 / SM12.x en utilisant CuTe DSL. Contrairement au chemin MARLIN dans vLLM général, ceux-ci calculent directement en mode fusionné sans déquantifier.
- Connexion Directe 200 Gbps RoCE : Bien que la réduction totale (all-reduce) TP=2 nœud à nœud se produise deux fois par couche, la connexion directe 200 Gbps maintient une latence effective faible, de sorte qu'elle ne devient pas un goulot d'étranglement pour le décodage.
- Mémoire Unifiée 128 Go × 2 : Un avantage de Grace Blackwell, qui ne sépare pas HBM et DDR. Cela permet de répartir le modèle FP8 officiel de 154 Go sur deux unités telles quelles, avec suffisamment d'espace pour un cache KV de 19,85 GiB pour un contexte de 512K.
- Implémentation Native de l'Attention Éparse de DeepSeek (DSA) : Les noyaux b12x gèrent correctement la conception où la complexité de l'attention ne dépend pas de la longueur du contexte en utilisant les opérations éparses natives du GB10. Cela a conduit au résultat où la vitesse de décodage ne chute pas avec la longueur du contexte.
En d'autres termes, si un seul de ces éléments — bande passante mémoire, puissance de calcul, communication de nœuds, optimisation du long contexte ou qualité de quantification — était exceptionnel, ce résultat ne se serait pas produit. Le Spark fournit tous ces éléments à un niveau plus élevé que toute configuration monomachine dans la même gamme de prix. C'est la véritable nature de son "équilibre".
Qu'est-ce qui Change en Utilisation Pratique ?
Pour aller au-delà de la théorie abstraite, voici quelques avantages concrets :
- La synthèse et l'analyse de code d'énormes documents deviennent réalistes : Avec un contexte de 512K et une vitesse de préremplissage de 1 277 tok/s, vous pouvez charger et synthétiser un livre entier (~300 000 tokens) en environ 4 minutes.
- Les boucles d'agent ne se bloquent pas : Avec une concurrence de 3,89×, vous pouvez exécuter le chat et la synthèse de longs textes simultanément (par exemple, avec Hermes Agent) sans effondrement du décodage.
- Plus de problème "l'Agent parle pour ne rien dire" dû à un échec de quantification : C'est un piège dans lequel je suis tombé plusieurs fois avec les modèles de la série IQ2 ; avec la pleine qualité, cela n'arrive tout simplement pas.
- Compétitif avec le Mac en termes de consommation électrique : La consommation électrique totale de deux GB10 pendant l'inférence est d'environ 100W–140W, ce qui est proche du Mac Studio M3 Ultra à pleine puissance. Compte tenu de la performance 1,78x, l'efficacité énergétique n'est pas mauvaise non plus.
Conclusion : L'Ère du Jugement de la Performance des LLM par le TPS Seul est Révolue
La vitesse instantanée de crachat d'un token — le TPS de décodage — est certainement une métrique importante. Cependant, c'est comme la "vitesse de pointe d'un 100 mètres." Ce qui est nécessaire en pratique, c'est le "temps pour atteindre la même réponse correcte", la "qualité de la réponse", "combien peuvent fonctionner simultanément", "quelle longueur de contexte peut être gérée" et "si les boucles d'agent fonctionnent." Ce sont les scores totaux.
Ce que ce résultat a montré, c'est que le DGX Spark commence à prendre de l'avance dans ce score total. Nous sommes entrés dans une ère où vous pouvez exécuter un énorme modèle à qualité officielle, avec un long contexte, tout en maintenant la compatibilité des agents, à 1,78x la vitesse réelle sur le mur d'un Mac Studio, simplement en connectant deux unités en cluster.
Ces dernières années, les gens ont dit "les LLM ne sont qu'une question de bande passante mémoire" et "le TPS de décodage est tout", mais après avoir réellement exécuté le Spark, je sens que mon affirmation selon laquelle "l'équilibre est la performance pratique" a enfin été prouvée par les chiffres.
Le RTX Spark a également été annoncé, et on a l'impression que les choses s'échauffent plus que prévu (même si l'ambiance pourrait se refroidir une fois le prix connu...). J'ai de grands espoirs que la communauté se développe et que davantage d'optimisation et de savoir-faire s'accumulent !
Jensen est vraiment incroyable... Son règne va-t-il se poursuivre encore longtemps ?
**
**
**
**
**
Bonus
Les lecteurs avisés pourraient avoir cette critique :
"Alors, ne serait-ce pas une comparaison équitable si vous exécutiez le FP8 officiel brut sur le Mac Studio aussi ?"
"La comparaison n'est-elle pas injuste ? Le Mac Studio n'est devenu redondant que parce qu'il a été quantifié en Q4. Si vous exécutiez le FP8 officiel brut sur le Mac Studio, ne serait-il pas sur un pied d'égalité en termes de qualité ?" C'est une question raisonnable.
Pour aller droit au but : Actuellement, il n'existe aucun moyen d'exécuter le 'FP8 officiel brut + MoE MXFP4' sur un Mac Studio à des vitesses pratiques.
- Tout d'abord, il n'existe pas de moteur d'inférence compatible.
Il ne semble pas y avoir de moteur qui prenne en charge entièrement le format officiel de DeepSeek-V4-Flash (attention FP8 + MoE MXFP4 + Lightning Indexer + Attention Éparse DSA) sur Apple Silicon (selon une recherche de Claude Code).
- MLX (le framework LLM officiel d'Apple pour Apple Silicon) : Pas d'implémentation native de NVFP4 fused MoE GEMM, pas d'attention paginée FP8, et pas d'implémentation MLX de l'Attention Éparse DSA de DeepSeek. Si vous essayiez de l'exécuter, vous devriez probablement le sur-convertir en bf16.
- llama.cpp : Ne peut pas charger MXFP4 directement, donc nécessite une re-quantification en GGUF = cela finit par être converti en Q4 / Q5 / IQ2, etc., et ce n'est plus la "version officielle brute".
- vLLM : La prise en charge d'Apple Silicon est limitée pour commencer, et les noyaux spécifiques au GB10 comme b12x ne fonctionneront pas sur un Mac.
- antirez/ds4 : C'est un moteur spécialisé écrit basé sur MLX spécifiquement pour DeepSeek V4 Flash avec l'hypothèse du Q4. C'est la solution optimale actuelle pour l'exécuter sur Mac Studio, mais il n'est pas construit pour gérer le "FP8 brut".
Le fait qu'antirez ait écrit un moteur dédié pour DeepSeek V4 Flash spécifiquement pour Q4 témoigne de la réalité qu'il n'existe actuellement aucun chemin pratique pour exécuter la qualité officielle telle quelle sur Apple Silicon.
- Même s'il était exécuté avec une sur-conversion en bf16, la bande passante serait presque entièrement consommée.
Pour les besoins de l'argumentation, disons que quelqu'un crée une implémentation MLX qui sur-convertit les poids officiels en bf16. Vous pouvez estimer ce qui se passerait avec un calcul approximatif de bande passante :
- DeepSeek-V4-Flash a une configuration MoE avec environ 30B de paramètres actifs.
- En Q4 (4 bits), les paramètres actifs occupent environ 15 Go, et ds4 atteint 26,2 tok/s (mesuré).
- Si le même modèle est conservé en FP8 (8 bits), les paramètres actifs occupent environ 30 Go = 2x l'exigence de bande passante = théoriquement ~13 tok/s sur le même moteur.
- De plus, la sur-conversion en bf16 dans MLX prend environ 60 Go pour les paramètres actifs = 4x l'exigence de bande passante = théoriquement ~6,5 tok/s.
- Étant donné que la bande passante mémoire effective du Mac Studio M3 Ultra est d'environ 800 Go/s, lire 60 Go pour chaque token atteindrait la limite de bande passante.
En d'autres termes, le choix de "prendre la qualité brute" sur Apple Silicon a actuellement le coût de "sacrifier plus du double de la vitesse." Fonctionner à 26,2 tok/s avec ds4 + Q4 était un choix plus pratique que d'obtenir seulement 6 tok/s avec bf16 pleine qualité.
- C'est là qu'intervient l'avantage structurel du Spark.
D'un autre côté, cette configuration DGX Spark exécute le "FP8 officiel brut + MoE MXFP4 nativement." Ceci est soutenu par :
- La suite b12x de noyaux spécifiques au GB10, qui a des implémentations pour exécuter NVFP4 fused MoE GEMM et l'attention paginée FP8 "sans déquantification".
- Cela n'a pas encore été écrit pour Apple Silicon.
- En conséquence, le Spark est actuellement la seule solution réaliste pour exécuter "la qualité officielle telle quelle" et "à des vitesses pratiques."
Pour résumer, si l'on ne regarde que la bande passante matérielle, la valeur absolue du Mac Studio pour une seule unité est à un niveau similaire, mais la présence ou l'absence d'"implémentations de noyaux qui exécutent les formats de quantification officiels nativement" crée une différence décisive. L'avantage du Spark ne vient pas seulement de la puce, mais de toute la combinaison avec la pile logicielle spécialisée GB10 comme b12x.
Si quelqu'un écrit NVFP4 fused MoE GEMM, l'attention paginée FP8 et l'Attention Éparse DSA pour Apple Silicon dans MLX à l'avenir, cette prémisse s'effondrera. Le paysage changera en fonction des implémentations de la communauté. Pour l'instant, le fait est que le Spark est un pas en avant dans la réalisation de la combinaison "qualité officielle × vitesse pratique."
Voici les résultats de l'analyse fournie par Claude Code.
