---

Il y a une scène qui se répète dans les forums de développeurs NVIDIA depuis l’été 2026. Un nouvel acquéreur de DGX Spark débarque, liste fièrement les modèles qu’il a fait tourner, colle des captures de nvidia-smi et de llama-bench, et se fait immédiatement reprendre par un vétéran : « contexte ? batch ? quantification ? cache chaud ou froid ? » Sans ces quatre précisions, un chiffre de tokens/seconde ne vaut rien. C’est toute la difficulté d’un comparatif honnête sur cette machine : le GB10 n’est pas un GPU comme les autres, et les modèles qui brillent sur une RTX 5090 ne sont pas forcément ceux qui brillent ici.

L’objectif de cet article est simple : trier. Non pas lister les modèles « compatibles » — ils sont des centaines — mais confronter les familles qui comptent réellement en 2026 (Qwen, Llama, Mistral, DeepSeek, Gemma, plus les variantes MoE quantifiées) sur les critères qui décident de l’usage réel : débit en decode, débit en prefill, empreinte mémoire effective, fiabilité sur des tâches agentiques, et capacité à être fine-tuné sur la même boîte. Avec, à la clé, une grille de décision par usage.

128 Go unifiés, mais 273 Go/s : le vrai plafond du GB10

Commençons par le cadre matériel, parce qu’il explique tous les chiffres qui suivent. Le DGX Spark repose sur le superchip Grace Blackwell GB10, une architecture issue du datacenter logée dans un format desktop. Côté mémoire, la machine embarque 128 Go de LPDDR5X unifiée, partagée entre CPU et GPU sans goulot d’étranglement PCIe — c’est l’un des arguments marketing centraux de NVIDIA, et il est réel. Le lien CPU-GPU passe par NVLink-C2C, une interconnexion cohérente à faible latence.

Mais voici le point que beaucoup de débutants ratent : la capacité mémoire ne détermine pas la vitesse. Elle détermine quels modèles peuvent être chargés. La vitesse de génération, elle, dépend presque entièrement de la bande passante mémoire — de l’ordre de 273 Go/s sur cette plateforme. À chaque token produit, le moteur doit lire l’intégralité des poids actifs du modèle depuis la mémoire. Un modèle dense de 70 milliards de paramètres en FP8, c’est environ 70 Go à faire transiter pour chaque token. Divisez 273 par 70, vous obtenez un plafond théorique autour de 3,9 tokens/seconde. La réalité mesurée est cohérente avec ce calcul : les denses de cette taille rampent sur GB10.

À l’inverse, le prefill — la phase où le modèle « avale » votre prompt — dépend surtout du compute, pas de la bande passante. C’est là que le GPU Blackwell à 6 144 cœurs et son support FP4/FP8 natif font la différence. Un long prompt peut être traité à plusieurs centaines, voire plus d’un millier de tokens/seconde, tandis que la génération qui suit reste lente. Cette asymétrie entre prefill et decode est la signature du GB10, et elle structure tout le reste de cet article.

La thèse, donc : sur DGX Spark, le choix du modèle est d’abord un arbitrage entre poids actifs par token et bande passante. Le reste — la taille totale, le nombre de paramètres affiché sur la fiche — est secondaire.

Le protocole : comment on a mesuré pour que les chiffres ne mentent pas

Avant de comparer, il faut fixer la méthode. Les benchmarks publiés cet automne — notamment le comparatif tokenstead.ai sur les modèles locaux 2026, le guide ctala sur le déploiement local agentique et les retours du forum développeurs NVIDIA — convergent sur un protocole minimal. Le voici, tel qu’il faut l’exiger de tout tableau crédible.

Moteurs comparés. Trois familles : TensorRT-LLM (le plus rapide en FP8/FP4, mais couverture de modèles en retard), vLLM (la meilleure couverture, PagedAttention efficace), et llama.cpp (le plus souple, GGUF, offload CPU+GPU). Les versions 2026 de ces moteurs ont chacune leurs spécificités sur Blackwell, et le choix du moteur peut à lui seul changer le verdict d’un modèle.

Quantification. FP8, INT4 AWQ/GPTQ, GGUF Q4_K_M. C’est la variable la plus souvent omise, et la plus trompeuse : un modèle en INT4 peut afficher le double du débit d’un modèle en FP8 tout en dégradant gravement le function calling.

Longueurs de contexte testées. 4k, 32k, 128k. Un modèle qui tient 128k sans swap n’est pas le même que celui qui tient 4k.

Tailles de batch. 1, 8, 32. Le batch 1 mesure l’usage interactif ; le batch 8-32 mesure l’usage agentique multi-sessions.

Métriques retenues. TTFT (time to first token), prefill tok/s, decode tok/s, tok/s agrégés, empreinte RSS/VRAM réelle observée.

Et maintenant, les pièges qui font mentir la plupart des tableaux publiés :

1. Cache chaud vs froid. Un premier run après chargement du modèle est plus lent. Beaucoup de benchmarks publient le meilleur run sans le dire.
2. Quantification non précisée. « Qwen3 27B à 40 tok/s » ne veut rien dire sans le format de quantification.
3. Contexte court. Mesurer à 4k puis annoncer un usage RAG à 128k est une faute classique.
4. Batch 1 déguisé en usage agentique. Un agent qui lance dix appels d’outils en parallèle ne tourne pas à batch 1.
5. Tok/s mesurés sur le premier token. Le TTFT n’est pas le débit de génération ; les confondre est une erreur de débutant.

Un tableau qui ne précise pas ces cinq points doit être lu avec méfiance.

Dense vs MoE : le match qui décide de tout sur GB10

C’est le cœur technique du comparatif, et la raison pour laquelle le GB10 a une personnalité si particulière.

Reprenons le calcul de bande passante. Un modèle dense active tous ses paramètres à chaque token. Un modèle MoE (mixture of experts) n’active qu’une fraction de ses experts — les « paramètres actifs » sont bien inférieurs au total. Sur une machine limitée par la bande passante, cette différence est décisive.

Prenons les familles concernées. Les MoE comme DeepSeek-V3/R1, Qwen3-235B-A22B ou Llama 4 Scout/Maverick sont structurellement avantagés en decode : seuls les paramètres actifs transitent par la bande passante. Un modèle qui n’active qu’une vingtaine de milliards de paramètres par token, même s’il en compte plusieurs centaines au total, génère beaucoup plus vite qu’un dense de taille comparable en paramètres totaux.

La contrepartie est brutale : l’empreinte mémoire totale explose. Un MoE de 200B+ paramètres doit être entièrement résident en mémoire, même si une petite fraction seulement est active. Sur 128 Go unifiés, cela impose une quantification agressive — INT4, parfois moins — avec les dégradations de qualité que cela implique, notamment sur le routage des experts. Un MoE mal quantifié peut voir ses routeurs se dégrader et perdre précisément l’avantage qu’on recherchait.

Face à eux, les denses — Llama 3.3 70B, Mistral Large 2, Gemma 3 27B — saturent la bande passante à chaque token. Leur avantage : une qualité prévisible, un routage inexistant (donc pas de dégradation de routage), et une quantification souvent plus robuste. Leur faiblesse : le débit.

Le fait daté le plus parlant de l’été 2026 : sur un seul DGX Spark, la suite llama.cpp GGUF atteint jusqu’à 67 tok/s sur un modèle de type 35B-A3B — un MoE à 35 milliards de paramètres totaux mais seulement ~3 milliards actifs. C’est précisément le profil qui exploite la bande passante du GB10. À l’inverse, un dense de 70B en FP8 plafonne structurellement sous les 4 tok/s, comme le calcul le laissait présager.

La leçon est nette : sur GB10, le MoE n’est pas un luxe, c’est souvent la seule façon d’obtenir un débit utilisable sur un modèle de grande taille.

Le tableau qui tranche : tok/s prefill et decode par famille

Voici le comparatif chiffré central. Les chiffres proviennent des benchmarks datés de l’été et de l’automne 2026 — j’indique la source et la date pour chaque ligne, et je reste qualitatif là où la donnée manque plutôt que d’inventer.

Famille / modèle	Quantif.	Moteur	Contexte	Batch	Prefill tok/s	Decode tok/s	Source / date
Qwen3.8-27B (dense)	non précisé	non précisé	non précisé	1	non précisé	34–38	2026-08-20
Qwen3.6-27B (dense)	non précisé	non précisé	non précisé	1	non précisé	28–33	2026
Qwen3.6-27B — pic	non précisé	non précisé	non précisé	1	non précisé	163 (pic)	2026
Qwen3.6-27B — 10 agents	non précisé	non précisé	non précisé	multi	non précisé	136 (agrégé)	2026
MoE type 35B-A3B	GGUF	llama.cpp	non précisé	1	non précisé	jusqu’à 67	2026-08
DeepSeek-V4-Flash	IQ2_XXS	ds4.c	non précisé	1	410	~14	2026-08
DeepSeek-V4-Flash	FP8	vLLM (TP=2)	non précisé	1	non précisé	~41	2026-08
DeepSeek-V4-Flash	FP8	vLLM (TP=2)	non précisé	32	~1785	~350 (agrégé)	2026-08

Quelques précisions importantes sur ce tableau. Le chiffre de 163 tok/s pour Qwen3.6-27B est un pic, pas un débit soutenu — c’est exactement le genre de nombre qui trompe quand il est présenté seul. Le débit réaliste en session unique est de 28 à 38 tok/s selon la version (3.6 vs 3.8). À l’inverse, le chiffre de 136 tok/s avec 10 agents illustre la montée en charge : le GB10 tient le multi-sessions bien mieux qu’on ne l’attendrait d’une machine de cette taille.

Les deux lignes DeepSeek-V4-Flash méritent une lecture attentive, car elles montrent l’effet de la quantification et du clustering. En IQ2_XXS sur un seul Spark, le prefill est excellent (410 tok/s) mais le decode s’effondre à ~14 tok/s — la quantification très agressive casse la vitesse de génération autant que la qualité. En FP8 sur deux Spark en tensor parallel, on passe à ~41 tok/s en single-stream et ~350 tok/s agrégés à concurrence 32, avec un prefill à ~1785 tok/s. Le doublement matériel change complètement le verdict.

Où se situent les ruptures ? Retenez deux seuils. ~30 tok/s est le plancher pour un agent utilisable : en dessous, les boucles de raisonnement et les appels d’outils deviennent pénibles. ~10 tok/s est le plancher du chat confortable. Sur cette base :

• Les denses de 27B (Qwen3.6/3.8) tiennent le seuil agent à 28-38 tok/s : utilisables.
• Les MoE de type 35B-A3B atteignent jusqu’à 67 tok/s : confortables.
• Les gros denses de 70B sont sous le seuil de confort en single-stream.
• DeepSeek-V4-Flash en IQ2_XXS à 14 tok/s est à la limite du chat, pas de l’agent.

Et les modèles « compatibles » mais inutilisables en pratique ? Tous ceux qui, une fois quantifiés pour tenir dans 128 Go, tombent sous les 10 tok/s ou dégradent leur routage. La compatibilité n’est pas la performance.

TensorRT-LLM, vLLM, llama.cpp : qui gagne quoi sur cette machine

Le choix du moteur n’est pas un détail d’implémentation : sur GB10, il peut inverser le classement des modèles.

TensorRT-LLM offre le meilleur prefill et le meilleur decode en FP8/FP4, en exploitant au maximum le compute Blackwell. C’est le moteur des chiffres les plus flatteurs — les ~1785 tok/s de prefill en TP=2 viennent de là. Mais sa couverture de modèles est en retard sur l’actualité open source, et sa compilation est lourde : chaque nouveau modèle demande un travail d’adaptation. Pour un modèle bien supporté et un usage stable, c’est le meilleur choix. Pour expérimenter, c’est un frein.

vLLM offre la meilleure couverture de modèles et un PagedAttention efficace, ce qui compte énormément pour le RAG long contexte et le multi-sessions. Sa faiblesse sur GB10 : la dépendance aux kernels CUDA spécifiques à Blackwell, avec un comportement variable selon la quantification. Les chiffres de DeepSeek-V4-Flash en FP8 (41 tok/s single-stream, 350 agrégés) viennent de vLLM en TP=2 — c’est un très bon résultat, mais il faut que les kernels suivent.

llama.cpp est le plus souple : GGUF, offload CPU+GPU, et surtout le seul à faire tourner confortablement des modèles qui débordent des 128 Go. Son prefill est le plus lent des trois, mais sa flexibilité est inégalée pour l’expérimentation et les modèles exotiques. Le chiffre de 67 tok/s sur un 35B-A3B vient de llama.cpp.

Recommandation par usage : TensorRT-LLM pour un modèle de production bien supporté en FP8 ; vLLM pour le RAG long contexte et le multi-agents ; llama.cpp pour tout le reste, l’exploration et les modèles qui ne rentrent pas autrement.

Qualité perçue : ce que les tok/s ne disent pas

Passons des chiffres à l’usage. Un modèle rapide qui rate ses appels d’outils coûte plus cher en tokens totaux qu’un modèle lent mais fiable — parce qu’il faut relancer, corriger, reformuler.

Sur les tâches agentiques (appels d’outils, boucles de raisonnement, respect de schémas JSON), la quantification INT4 qui double le decode peut casser le function calling. Un modèle qui génère du JSON invalide une fois sur cinq est inutilisable en agent, quel que soit son débit. C’est un point que les benchmarks de tok/s ne capturent jamais, et c’est probablement la principale raison pour laquelle les utilisateurs de DGX Spark se plaignent de modèles « rapides mais inutiles ».

Sur les MoE quantifiés, la dégradation du routage est le piège spécifique : quand les experts sont quantifiés trop agressivement, le routeur envoie les tokens vers les mauvais experts, et la qualité chute de façon non linéaire. Un MoE en INT4 peut sembler correct sur des prompts courts et s’effondrer sur des tâches longues.

Sur le code (génération, refactoring, tests), les denses de 27B restent d’excellents rapporteurs qualité/prix, et Gemma 3 27B conserve une réputation solide en RAG court contexte — un modèle fiable, prévisible, sans surprise de routage.

La conclusion pratique : mesurez la qualité, pas seulement le débit. Un modèle à 30 tok/s qui réussit 95 % de ses appels d’outils bat un modèle à 60 tok/s qui en réussit 70 %.

Fine-tuning LoRA sur la même boîte : ce qui tient, ce qui ne tient pas

Le DGX Spark n’est pas qu’une machine d’inférence : on peut y fine-tuner. Mais les 128 Go unifiés sont partagés, et c’est là que les ennuis commencent.

Ce qui tient confortablement : les modèles de 7B à 14B, avec les bibliothèques habituelles (Unsloth, PEFT, torchtune). Mémoire pic raisonnable, temps par epoch acceptable. C’est le terrain de jeu naturel.

Ce qui tient en QLoRA : les modèles de 27B à 32B. La quantification 4-bit des poids permet de les entraîner, au prix d’une qualité légèrement inférieure et d’un temps plus long.

Ce qui tient très serré : les 70B en LoRA 4-bit. Possible, mais à la limite, avec peu de marge pour le contexte et le batch.

Le piège majeur : entraîner et servir en même temps. Sur 128 Go unifiés, un modèle d’inférence résident et un job de fine-tuning se disputent la même mémoire. Il faut choisir, ou accepter des ralentissements sévères.

Et un rappel qui change le classement : un modèle moyen fine-tuné bat souvent un gros modèle générique sur une tâche verticale. Un 14B affiné sur votre domaine peut surpasser un 70B générique — pour une fraction du coût en mémoire et en débit.

Un Spark ou quatre ? Ce que change le clustering

Le clustering de DGX Spark est l’un des sujets les plus mal compris. Voici ce qu’il permet, et ce qu’il ne permet pas.

Ce qu’il permet : agrégation de mémoire pour servir des modèles 200B+ (jusqu’à 405 milliards de paramètres sur deux Spark selon les données constructeur), et parallélisme tensoriel (TP) ou pipeline. Les chiffres de DeepSeek-V4-Flash en TP=2 le montrent : on passe de ~14 tok/s (single, IQ2_XXS) à ~41 tok/s single-stream et ~350 tok/s agrégés (double, FP8). Le pool de cache KV partagé atteint 1 105 096 tokens sur deux Spark — de quoi tenir un RAG massif.

Ce qu’il ne permet pas : effacer la latence d’interconnexion. Le parallélisme tensoriel ajoute un overhead de communication à chaque token, et certains modèles ne scalent tout simplement pas. La complexité logicielle grimpe aussi : configurer TP=2 en vLLM sur deux machines n’est pas trivial.

Le calcul économique : un cluster de 2 à 4 Spark face à une station unique ou à du cloud GPU à l’heure. Le cluster est pertinent quand on veut servir un gros MoE en local avec un débit soutenu et une confidentialité totale. Il est un piège quand on cherche simplement à faire tourner un modèle qui tiendrait déjà sur un Spark, ou quand la latence d’interconnexion pénalise un modèle peu parallélisable.

La grille de décision : quel modèle pour quel usage sur GB10

Récapitulons, de façon actionnable.

Agent local (function calling fiable, latence). Modèle : un MoE de type 35B-A3B ou Qwen3.8-27B. Moteur : vLLM. Quantification : FP8 si ça rentre, sinon INT4 AWQ en vérifiant le function calling. Piège à éviter : la quantification INT4 agressive qui casse les schémas JSON.

RAG long contexte (128k sans swap). Modèle : un MoE bien quantifié ou un dense de 27B, selon la qualité de retrieval. Moteur : vLLM (PagedAttention). Quantification : FP8 privilégié. Piège : mesurer à 4k puis déployer à 128k.

Code (génération et complétion). Modèle : dense 27B (Qwen3.8, Gemma 3 27B). Moteur : TensorRT-LLM si supporté, sinon vLLM. Quantification : FP8. Piège : sacrifier la qualité de code pour du débit.

Fine-tuning LoRA. Modèle : 7B–14B confortablement, 27B–32B en QLoRA. Bibliothèques : Unsloth, PEFT, torchtune. Piège : entraîner et servir simultanément sur les mêmes 128 Go.

Expérimentation. Modèle : tout ce qui rentre. Moteur : llama.cpp. Quantification : GGUF Q4_K_M. Piège : confondre compatibilité et performance.

Que devra corriger la prochaine génération de GB10 ? Trois choses : la bande passante (273 Go/s reste le vrai plafond), le support FP4 natif plus mature dans les moteurs, et l’écosystème — TensorRT-LLM doit rattraper sa couverture de modèles.

Et la question qui reste ouverte : le local redevient-il compétitif face au cloud en 2026 ? Pour un usage intensif et confidentiel, oui — le coût par token d’un Spark amorti sur un an peut battre le cloud GPU à l’heure, surtout avec un MoE bien choisi. Pour un usage sporadique, le cloud garde l’avantage. La réponse dépend moins de la machine que de votre profil d’usage. Ce qui est certain, c’est que sur GB10, le bon modèle n’est pas le plus gros : c’est celui dont les paramètres actifs tiennent dans la bande passante.

Sources

• DGX Spark Benchmarks: Which Local Model Wins in 2026 — tokenstead.ai
• Best Local LLM Deployment Guide for DGX Spark, GB10 & 96-128 GB Edge AI — ctala.github.io
• DGX Spark Release Notes — DGX Spark User Guide, NVIDIA Docs
• Systèmes DGX : conçus pour répondre aux demandes uniques de l’IA — NVIDIA
• DGX Platform: Built for Enterprise AI — NVIDIA
• I Clustered Two Nvidia DGX Spark AI Boxes in My Living Room — PCMag
• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blogs.nvidia.com
• AA-AgentPerf-Local: Benchmarking local AI agents on laptops and workstations — Artificial Analysis
• Matériel pour l’IA locale en 2026 : DGX Spark, Mac Studio M5 Ultra, RTX 5090 et Strix Halo comparés — contextstudios.ai