NVIDIA DGX Spark · 9 September 2026

Speculative decoding sur DGX Spark : la ruse qui fait exploser le débit d’inférence sans sacrifier un seul token de qualité

Le DGX Spark de NVIDIA est un paradoxe : capable de charger des modèles de 200 milliards de paramètres dans ses 128 Go de mémoire unifiée, il plafonne pourtant à quelques tokens par seconde en décodage natif. La faute à une bande passante mémoire qui n’a rien d’exceptionnel. Mais une technique vieille de quelques années, le speculative decoding, pourrait bien transformer ce colosse aux pieds d’argile en machine d’inférence redoutable — à condition de savoir l’apprivoiser.

Le GB10, ce colosse aux pieds de mémoire : pourquoi le décodage natif plafonne

Le DGX Spark, propulsé par le superchip GB10 Grace Blackwell, est un objet fascinant. Dans un format de mini-PC, NVIDIA a réussi à loger un système complet capable d’exécuter des modèles de plusieurs centaines de milliards de paramètres. La clé de cette prouesse tient dans ses 128 Go de mémoire unifiée LPDDR5x, une configuration qui permet de charger des poids qui dépassent de très loin ce qu’une carte graphique classique peut accueillir. Le tout est interconnecté via le NVLink-C2C, qui relie le CPU Grace et le GPU Blackwell avec une cohérence mémoire totale.

Mais ce colosse a un talon d’Achille : sa bande passante mémoire. Les spécifications publiques, relayées par des sources tierces comme QuelLLM.fr, indiquent environ 273 Go/s — un chiffre impressionnant pour un mini-PC, mais dérisoire face aux 3,35 To/s d’une H100 ou aux 8 To/s d’un B200. Or, le décodage autorégressif d’un LLM est une opération fondamentalement memory-bound : à chaque token généré, le modèle doit relire l’intégralité de ses poids depuis la mémoire. Plus le modèle est gros, plus cette relecture est coûteuse, et plus la bande passante devient le facteur limitant.

Les mesures communautaires confirment ce diagnostic. Sur un modèle dense 70B en FP8, la machine plafonne à environ 2,7 tokens/s selon une mesure LMSYS relayée par QuelLLM.fr. Pour un Llama 3.1 8B, les ordres de grandeur rapportés sur les forums NVIDIA et Reddit tournent autour de 20 à 30 tokens/s — utilisable, mais loin des performances d’un GPU discret. Un Qwen 2.5 14B quantifié en Q4 atteint péniblement 10 à 15 tokens/s. Et un 70B en Q4, malgré la réduction de poids, reste coincé sous la barre des 5 tokens/s. Autant dire que l’expérience interactive, celle où l’on attend la réponse token après token, devient vite frustrante.

Le paradoxe est cruel : le DGX Spark peut charger des modèles que même un RTX 5090 ne peut pas accueillir, mais il les fait ramper. C’est exactement le scénario pour lequel le speculative decoding a été inventé.

Le draft model, ou comment tricher intelligemment : le principe du pari à plusieurs tokens

Le décodage autorégressif classique est d’une lenteur exaspérante parce qu’il est séquentiel : un token à la fois, chaque token nécessitant une passe complète du modèle. Le speculative decoding, popularisé par les travaux de Google Research en 2023, propose une alternative élégante : parier sur plusieurs tokens à la fois.

Le principe est simple. Un petit modèle — typiquement 0,5 à 1 milliard de paramètres, appelé draft model — propose une séquence de k tokens candidats. Le modèle cible, celui qui nous intéresse vraiment, vérifie ensuite ces k tokens en une seule passe forward, en parallèle. Si les tokens proposés sont corrects, on les accepte tous et on a gagné k tokens pour le prix d’une seule passe du gros modèle. Si certains sont faux, on les rejette et on repart du dernier token correct. La qualité finale est strictement identique au décodage natif : le modèle cible reste l’arbitre ultime.

Le gain théorique dépend d’un paramètre clé : le taux d’acceptation p, c’est-à-dire la probabilité que le draft model propose un token que le modèle cible aurait choisi. La formule classique du speedup est 1 / (1 – p + p×k). Avec un taux d’acceptation de 0,7 et k = 4 tokens proposés, le speedup théorique atteint 1 / (1 – 0,7 + 0,7×4) ≈ 1,35×. Avec p = 0,8 et k = 5, on monte à 1,56×. Le draft model doit être suffisamment petit pour être rapide, mais suffisamment intelligent pour bien prédire — un équilibre délicat.

Cette technique est particulièrement adaptée aux architectures memory-bound comme le GB10. Pourquoi ? Parce que le draft model, avec ses quelques centaines de millions de paramètres, ne pèse que quelques centaines de Mo en mémoire. Le lire en entier ne coûte qu’une fraction de la bande passante nécessaire pour lire un modèle de 70B. Le pari est donc presque toujours gagnant : on sacrifie une petite lecture mémoire pour potentiellement économiser plusieurs grosses lectures.

273 Go/s, le goulot qui change tout : pourquoi le speedup théorique ne s’applique pas comme sur une H100

Sur une H100, le speculative decoding est une affaire de compute. Le GPU est si rapide que le draft model ajoute une charge de calcul supplémentaire qui peut, dans certains cas, dépasser le gain obtenu. Les implémentations doivent donc être fines, et le choix du draft model est crucial pour ne pas transformer l’opération en gouffre énergétique.

Sur le GB10, l’équation est radicalement différente. La machine est memory-bound : le GPU passe l’essentiel de son temps à attendre que les poids arrivent de la mémoire LPDDR5x. Le compute, lui, reste largement sous-utilisé. Dans ce contexte, le draft model n’ajoute pas une charge de calcul significative — il ajoute une lecture mémoire supplémentaire, mais une lecture minuscule. Le rapport coût/bénéfice est donc structurellement favorable.

La mémoire unifiée et le NVLink-C2C jouent ici un rôle décisif. Sur une architecture classique avec un GPU discret, les allers-retours entre le draft model (souvent logé en VRAM) et le modèle cible (parfois en RAM système) passent par le bus PCIe, avec ses latences et ses goulots d’étranglement. Sur le GB10, tout est dans le même espace d’adressage : le CPU et le GPU partagent la même mémoire physique, et le NVLink-C2C offre une cohérence totale. Les bascules entre draft et cible se font sans copie, sans transfert, sans synchronisation coûteuse. C’est un avantage structurel que les frameworks commencent tout juste à exploiter pleinement.

Cela dit, le speedup pratique reste inférieur au speedup théorique. La formule 1/(1-p+p×k) suppose que le draft model est gratuit, ce qui n’est jamais le cas. Sur le GB10, le draft model consomme de la bande passante — environ 0,5 à 1 Go/s pour un modèle 0,5B en FP8, ce qui reste négligeable face aux 273 Go/s disponibles. Mais il ajoute aussi de la latence : chaque cycle draft → vérification introduit un aller-retour supplémentaire. En streaming single-request, cette latence peut annihiler le gain de débit, comme nous le verrons plus loin.

vLLM, TensorRT-LLM, llama.cpp : le match des implémentations sur mémoire unifiée

Trois frameworks dominent le paysage du speculative decoding sur DGX Spark : vLLM, TensorRT-LLM et llama.cpp. Chacun a ses forces, ses faiblesses, et sa manière d’exploiter — ou non — la mémoire unifiée.

vLLM est probablement le plus mature. Son flag --speculative-model permet de spécifier un draft model séparé, et le framework gère automatiquement le KV cache partagé entre le draft et la cible. C’est un avantage considérable : le draft model et le modèle cible partagent les mêmes clés/valeurs de contexte, ce qui évite de dupliquer la mémoire et accélère les transitions. vLLM supporte également le speculative decoding avec des modèles MoE, ce qui le rend compatible avec les architectures récentes comme DeepSeek V4 Flash.

TensorRT-LLM, la solution maison de NVIDIA, est plus rigide mais potentiellement plus rapide. Son outil pyexec permet de charger des draft models pré-convertis en moteurs TensorRT. L’avantage est une latence minimale grâce à l’optimisation en profondeur du graphe de calcul. L’inconvénient est la complexité : il faut convertir chaque modèle, gérer les versions, et les mises à jour sont fréquentes. NVIDIA a annoncé lors du CES 2026 des optimisations permettant jusqu’à 2,5× de performance en inférence sur DGX Spark, incluant TensorRT-LLM et le speculative decoding — un chiffre prometteur, mais dont le détail technique reste flou.

llama.cpp, le framework communautaire par excellence, propose le flag -md (pour model draft). Son avantage est la simplicité : on charge un GGUF de draft model, et c’est parti. Sa gestion de la mémoire unifiée est plus rudimentaire, mais le framework est constamment mis à jour par une communauté très active. Pour les utilisateurs qui veulent tester rapidement, c’est souvent le meilleur point d’entrée.

Le point commun des trois : grâce à la mémoire unifiée, ils évitent les copies PCIe qui plombent les systèmes à GPU discret. Le draft model et la cible vivent dans le même espace mémoire, et les transitions se font par simple pointeur. C’est un avantage que les benchmarks sur H100 ne montrent pas, car sur ces machines, le PCIe est un goulot d’étranglement supplémentaire.

Chiffres réels et promesses : de Llama 8B à DeepSeek 284B, que gagne-t-on vraiment ?

La question des chiffres est délicate : les benchmarks publics de speculative decoding sur DGX Spark restent rares et souvent partiels. Les données fiables manquent, et il faut se méfier des annonces marketing. Ce que l’on sait, c’est que les gains mesurés sur d’autres architectures memory-bound — comme les Mac M-series — se situent typiquement entre 1,3× et 2× selon le modèle et le draft choisi. Il est raisonnable d’attendre des ordres de grandeur similaires sur le GB10.

Le cas le plus documenté est celui de DeepSeek V4 Flash 0731, un MoE de 284 milliards de paramètres (13 milliards actifs par token) publié le 31 juillet 2026. Ce modèle intègre un module DSpark, décrit comme un décodeur spéculatif fusionné dans le checkpoint. Autrement dit, le draft model n’est plus un fichier séparé : il est intégré au modèle lui-même, ce qui simplifie considérablement la configuration. Les premiers retours sur les forums NVIDIA indiquent des performances honorables : environ 30 tok/s en configuration par défaut, et jusqu’à 59 tok/s en serving multi-agents après ajustement de la configuration. Un utilisateur rapporte même 1 000 tok/s en prefill et 59 tok/s en serving multi-agents sur une seule machine.

Le surcoût mémoire d’un draft model séparé est un autre point crucial. Un modèle 1B en FP8 pèse environ 1 Go de poids, plus son KV cache. Pour un 70B Q4 (environ 40 Go), l’ajout d’un draft 1B représente un surcoût de 2 à 3 % — négligeable. Mais pour un 70B Q8 (environ 70 Go), il faut surveiller la mémoire restante pour le contexte. Sur 128 Go, on peut charger un 70B Q8, un draft 1B, et conserver un contexte de 32K à 64K tokens selon la configuration. C’est un compromis acceptable.

Les promesses de NVIDIA pour 2026 — jusqu’à 2,5× de performance en inférence — sont alléchantes, mais il faut les prendre avec prudence. Le chiffre exact, annoncé au CES 2026, n’est pas détaillé publiquement : concerne-t-il uniquement TensorRT-LLM ? vLLM ? Les deux ? Et sur quels modèles ? En attendant, les utilisateurs qui ont testé le speculative decoding sur DGX Spark rapportent des gains réels mais variables, typiquement entre 1,2× et 1,8× selon la configuration.

Guide de terrain : monter son pipeline de speculative decoding en 30 minutes

Assez de théorie, passons à la pratique. Voici comment configurer un pipeline de speculative decoding sur votre DGX Spark, en moins de 30 minutes.

Étape 1 : Choisir le draft model. L’idéal est un modèle dense de 0,5 à 1 milliard de paramètres, de préférence de la même famille que le modèle cible. Par exemple, pour un Qwen 3.5 27B, un Qwen 3.5 0.8B est un excellent choix : il ne pèse que 0,9 Go en Q4_K_M, 1,1 Go en Q6_K, ou 1,3 Go en Q8_0, et ses besoins minimaux sont de 1 Go de VRAM (2 Go recommandés). Pour un Llama 3.1 70B, un draft Llama 3.2 1B ou un Qwen 0.5B fonctionnera correctement.

Étape 2 : Lancer vLLM. La commande est simple :

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model Qwen/Qwen3.5-0.8B \
  --num-speculative-tokens 4 \
  --max-model-len 32768

Le flag --num-speculative-tokens (k) est le nombre de tokens proposés par le draft. Une valeur de 4 est un bon point de départ. Vous pouvez l’ajuster entre 2 et 8 selon le taux d’acceptation observé.

Étape 3 : Avec llama.cpp. Encore plus simple :

llama-server -m llama-3.1-70b-instruct.Q4_K_M.gguf \
  -md qwen3.5-0.8b.Q4_K_M.gguf \
  -nk 4

Le flag -nk contrôle le nombre de tokens spéculatifs. Le flag -md pointe vers le draft model.

Étape 4 : Régler et observer. Le paramètre le plus important est le taux d’acceptation. La plupart des frameworks exposent des métriques en temps réel. Si le taux d’acceptation est inférieur à 0,5, votre draft model est trop mauvais : essayez un modèle plus gros ou de la même famille que la cible. Si le taux dépasse 0,8, vous pouvez augmenter k pour gagner plus de tokens par cycle.

Étape 5 : Gérer la mémoire. Avec 128 Go, vous avez de la marge, mais surveillez le KV cache. Pour un 70B Q4 avec un draft 1B, vous pouvez viser un contexte de 32K à 64K tokens. Utilisez --max-model-len pour borner le contexte et éviter les surprises.

Les pièges du GB10 : quand le draft model devient lui-même le goulot d’étranglement

Le speculative decoding n’est pas une baguette magique. Sur le GB10, plusieurs pièges peuvent transformer le gain en perte.

Le piège n°1 : la latence en streaming single-request. En mode interactif, où l’utilisateur attend chaque token, le speculative decoding ajoute un aller-retour supplémentaire : le draft propose, la cible vérifie. Si le draft est lent, la latence perçue augmente, même si le débit moyen s’améliore. Sur un GB10, avec un draft 0.5B, cet aller-retour coûte quelques millisecondes — souvent acceptable. Mais avec un draft 1B, le coût peut dépasser le gain, surtout si le taux d’acceptation est faible. La règle d’or : en streaming single-request, testez avec et sans speculative decoding, et comparez la latence perçue.

Le piège n°2 : la taille du batch. Le speculative decoding brille en batch, où plusieurs requêtes sont traitées en parallèle. Avec un batch de 32, le draft model propose des tokens pour toutes les requêtes d’un coup, et la vérification par la cible est amortie sur l’ensemble du batch. Le gain en débit est alors maximal. Mais avec un batch de 1, le gain est souvent marginal, voire négatif. Si votre usage est principalement interactif (chat, agent), le speculative decoding peut ne pas vous aider.

Le piège n°3 : un draft trop gros. Un draft de 1B consomme environ 1 Go de poids et, surtout, de la bande passante à chaque cycle. Sur un GB10 limité à 273 Go/s, lire un draft 1B coûte environ 1/273e de la bande passante totale — négligeable. Mais si le draft est mal optimisé (par exemple en FP32), le coût peut doubler ou tripler. Un draft 0.5B est souvent le meilleur compromis : assez intelligent pour bien prédire, assez léger pour ne pas peser sur la mémoire.

Le piège n°4 : le KV cache partagé. Certains frameworks ne partagent pas le KV cache entre draft et cible, ce qui force à dupliquer les clés/valeurs. Sur un GB10, cela peut réduire le contexte disponible de 10 à 20 %. Vérifiez que votre framework supporte le partage (vLLM le fait automatiquement, llama.cpp partiellement).

Passer à l’échelle : le speculative decoding en cluster DGX Spark, entre promesses et réalité

Le DGX Spark peut être clusterisé : deux machines reliées via un lien QSFP 200 Gb/s offrent 256 Go de mémoire agrégée. C’est la configuration idéale pour les modèles 70B+ en haute précision, ou pour les MoE géants comme DeepSeek V4 Flash.

Mais le speculative decoding en cluster pose une question fondamentale : où placer le draft model ? Si le draft est sur le nœud A et la cible sur le nœud B, chaque cycle draft → vérification traverse le lien réseau. Avec 200 Gb/s (25 Go/s), la latence ajoutée est de l’ordre de la milliseconde — acceptable, mais non négligeable. La meilleure pratique est de dupliquer le draft model sur chaque nœud, afin que la proposition et la vérification se fassent localement. Le draft ne pèse que 1 Go, la duplication est triviale.

Les retours d’expérience sur les configurations 2× DGX Spark sont encourageants. Un utilisateur des forums NVIDIA rapporte avoir exécuté DeepSeek V4 Flash 0731 sur deux machines avec un serving multi-agents atteignant 59 tok/s, contre 30 tok/s en configuration par défaut sur une seule machine. Le gain vient autant du parallélisme tensoriel que du speculative decoding intégré (module DSpark). Un autre test, rapporté par flowtivity.ai, confirme que le modèle tourne de manière fluide sur deux Spark avec 13B paramètres actifs, offrant des performances "frontier-level" pour des agents privés.

Le parallélisme tensoriel (TP) est recommandé pour les configurations multi-nœuds, mais il exige une interconnexion à très haute bande passante — le NVLink est préféré au PCIe. Sur le GB10, le lien QSFP 200 Gb/s est suffisant pour du TP à 2 nœuds, mais pour 4 nœuds, il faudra probablement passer à du pipeline parallelism, moins exigeant en bande passante.

Demain : le décodage spéculatif fusionné dans les checkpoints, la fin du draft model séparé ?

La tendance la plus intéressante de 2026 est la fusion du draft model directement dans le checkpoint du modèle cible. DeepSeek a ouvert la voie avec son module DSpark intégré à V4 Flash 0731 : plus besoin de chercher un draft model compatible, plus besoin de le configurer, plus besoin de gérer deux fichiers séparés. Le décodeur spéculatif est là, dans le modèle, prêt à l’emploi.

Qwen explore une voie complémentaire avec le MTP (Multi-Token Prediction). L’idée est d’entraîner le modèle à prédire plusieurs tokens à la fois, plutôt que de s’appuyer sur un draft externe. Les premiers résultats sont spectaculaires : sur un GPU B200, le MTP de Qwen3.8-Flash-Next atteint un speedup de 1,67× avec la quantification UD-Q4_K_XL, passant de 83,2 à 138,8 tok/s. Si cette approche est transposée au GB10, elle pourrait offrir des gains similaires sans la complexité d’un draft model séparé.

Pour l’utilisateur final, ces innovations signifient une simplification radicale. Fini le casse-tête du choix du draft model, du réglage de k, de la gestion du KV cache partagé. Le modèle arrive avec son décodeur spéculatif intégré, optimisé pour l’architecture cible. NVIDIA, de son côté, promet des mises à jour logicielles régulières pour le DGX Spark, avec des gains allant jusqu’à 2,5× en inférence. Si ces promesses se concrétisent, le DGX Spark pourrait bien devenir la machine de référence pour l’IA locale — non plus malgré sa bande passante limitée, mais grâce à des techniques qui transforment cette limite en opportunité.

Le speculative decoding n’est pas une solution miracle, mais c’est une solution intelligente. Elle ne change pas la physique de la mémoire, mais elle change la manière dont on l’utilise. Et sur une machine comme le DGX Spark, où chaque Go/s compte, cette intelligence fait toute la différence.

Sources

• QuelLLM.fr — Guide NVIDIA DGX Spark : prix, analyse
• QDNA.fr — DeepSeek local sur DGX Station/Spark avec vLLM
• Forums NVIDIA — 1x Spark : DeepSeek-V4-Flash-0731 @ 1,000 tok/s prefill, 59 tok/s multi-agent serving
• Forums NVIDIA — DeepSeek-v4-Flash-0731-DSpark-1M-NVFP4-KV-2x-DGX-Spark
• Forums NVIDIA — Agent Serving on 2× DGX Spark with DeepSeek V4 Flash 0731
• Flowtivity.ai — DeepSeek V4 Flash 0731 on Dual DGX Spark
• Unsloth — Fine-tuning LLMs with NVIDIA DGX Spark
• Canirun.ai — Qwen 3.5 0.8B
• NVIDIA — DGX Spark
• Tokios — Guide mémoire DGX Spark
• Tokios — Parallélisme tensoriel vs pipeline
• DeepWiki — emiluzelac/deepseek-v4-flash-0731-on-one-dgx-spark
• Banandre.com — MTP Qwen3.8-Flash-Next sur B200
• Blog Openzeka — Qwen3.8-27B sur DGX Spark
• Wccftech — Optimisations NVIDIA pour l’IA locale

Article recherché et rédigé automatiquement · Magazine Electrosens