NVIDIA DGX Spark · 5 November 2026

RTX Spark contre DGX Spark : même silicium GB10, mémoire plus rapide — ce que cela change vraiment quand on fait tourner des LLM chez soi

NVIDIA vend le même SoC GB10 sous trois étiquettes — DGX Spark, RTX Spark, nom de code N1X — mais les premiers retours créditent les portables RTX Spark d’une mémoire plus rapide et de fonctions absentes du boîtier de bureau. Derrière la fiche produit, une seule question opérationnelle : qu’est-ce que la hiérarchie mémoire du GB10 fait réellement à vos modèles, à votre contexte et à votre débit en tokens par seconde ? Décryptage technique, avec les chiffres sourcés, les trous documentaires assumés et les recettes à reproduire.

GB10, N1X, RTX Spark, DGX Spark : un seul silicium, trois étiquettes — et une mémoire qui n’est pas la même

Il faut d’abord poser la généalogie, parce que la confusion terminologique est le premier piège de ce dossier. Le SoC qui nous intéresse s’appelle GB10 — un « Grace Blackwell Superchip » qui associe un die CPU et un GPU Blackwell dans un seul boîtier. Ce silicium est commercialisé sous plusieurs noms selon le canal : DGX Spark pour la station IA personnelle vendue par NVIDIA, RTX Spark pour les machines PC/portables qui embarquent la même plateforme, et N1X comme nom de code côté puce. Trois médias concordants — MSN, Clubic et Les Numériques — décrivent bien « un seul silicium, trois étiquettes ». Mais il faut être honnête sur la nature de ce consensus : les trois semblent dériver de la même communication NVIDIA, sans recoupement par un benchmark indépendant. Aucune confirmation officielle NVIDIA de l’identité stricte GB10 = N1X = RTX Spark ne figure dans notre corpus. C’est une hypothèse solide, pas un dogme.

Le calendrier, lui, est plus ferme côté DGX Spark. La machine a été annoncée au CES de janvier 2025, puis reportée, avant une livraison effective en octobre 2025. Depuis, la gamme a beaucoup bougé : le 2 octobre 2026, NVIDIA a décliné son mini-supercalculateur en version 64 Go, commercialisée à partir du 23 octobre 2026 à 4 999 dollars, tandis que le modèle 128 Go grimpait au-delà des 6 000 dollars sur le marché — la flambée des prix de la mémoire LPDDR5X étant explicitement pointée par plusieurs médias, dont Hardware & Co et Generation-NT. Le 21 octobre 2026, NVIDIA a par ailleurs déployé sa mise à jour logicielle DGX Spark — October 2026 Release, avec la promesse que les systèmes partenaires à base de GB10 Grace Blackwell recevront les mêmes évolutions.

C’est dans ce contexte mouvant qu’apparaît l’énigme centrale : pourquoi la variante RTX Spark serait-elle créditée d’une mémoire plus rapide alors que le boîtier DGX Spark plafonne, dans la littérature NVIDIA, à 273 Go/s en LPDDR5X sur un bus de 256 bits ? La question n’est pas anecdotique. En inférence de LLM, la bande passante mémoire est souvent le vrai plafond, bien avant le nombre de TOPS. Comprendre cet écart, c’est comprendre ce que votre station peut réellement faire tourner.

273 Go/s, 256 bits, 128 Go unifiés : ce que la hiérarchie mémoire du GB10 fait réellement à vos modèles

Posons l’architecture telle qu’elle est documentée. Le GB10 embarque une mémoire unifiée LPDDR5X — c’est-à-dire un pool partagé entre le CPU et le GPU, sans copie explicite de l’un vers l’autre — sur un bus de 256 bits offrant 273 Go/s de bande passante. Le lien entre le die CPU (MediaTek) et le GPU Blackwell passe par NVLink-C2C, un interconnexion cohérente à très haut débit intra-boîtier. C’est cette architecture « mémoire unifiée » qui permet à un boîtier de la taille d’un mini-PC de charger des modèles de plusieurs dizaines de milliards de paramètres sans GPU discret à 80 Go de VRAM.

Mais voilà le point que les fiches marketing escamotent : en décodage autoregressif, chaque token généré impose de relire l’intégralité des poids du modèle. Le calcul est simple et impitoyable. Si votre modèle pèse P octets et que votre mémoire débite B octets par seconde, le débit théorique maximal est de B / P tokens par seconde — indépendamment de la puissance de calcul du GPU. C’est la loi du memory-bound.

Faisons le calcul à 273 Go/s, avec des hypothèses de taille de poids explicites (les tailles exactes dépendent de la quantification, on reste donc sur des ordres de grandeur) :

Modèle (poids approx.)	Taille en Q4	Taille en Q8/FP8	Débit théorique Q4 @273 Go/s	Débit théorique Q8 @273 Go/s
8B	~4–5 Go	~8–9 Go	~55–68 tok/s	~30–34 tok/s
70B	~35–40 Go	~70–75 Go	~7–8 tok/s	~3,6–3,9 tok/s
120B	~60–70 Go	~120–130 Go	~4–4,5 tok/s	~2,1–2,3 tok/s

Ces plafonds théoriques sont à comparer aux mesures réelles du magazine sur un seul DGX Spark : ~14 tok/s en single-stream sur DeepSeek-V4-Flash en IQ2_XXS (recette antirez ds4, août 2026), un prefill de 410 t/s, et jusqu’à 67 tok/s sur un 35B-A3B en llama.cpp. Le 35B-A3B, modèle à experts (MoE), illustre parfaitement la nuance : seuls les experts activés sont relus à chaque token, donc le débit effectif dépasse largement le plafond « dense ». C’est un levier majeur pour qui veut du débit sur GB10.

Si la mémoire du RTX Spark est effectivement plus rapide, l’écart se répercute proportionnellement sur ces plafonds : +20 % de bande passante, c’est +20 % de tok/s en décodage dense, à modèle et quantification identiques. Aucun chiffre officiel de bande passante RTX Spark ne figure dans notre corpus — on reste donc sur une hypothèse à valider, pas sur une promesse.

Ce que « mémoire plus rapide » veut dire concrètement : fréquence, largeur de bus et partitionnement CPU/GPU

Trois leviers physiques peuvent expliquer un gain de bande passante sur RTX Spark, et il faut les distinguer car leurs conséquences opérationnelles diffèrent.

1. Une fréquence LPDDR5X plus élevée. La bande passante d’un bus se calcule comme largeur × fréquence × 2 (DDR). À largeur constante (256 bits), passer d’une fréquence à une autre plus rapide augmente linéairement le débit. C’est le levier le plus simple à implémenter pour un OEM, et le plus probable sur une plateforme mobile où la consommation compte.

2. Un bus plus large (256 → 384 bits ?). Plus coûteux en routage et en consommation, mais plus efficace. Aucune source du corpus ne confirme un élargissement de bus sur RTX Spark — c’est une hypothèse, pas un fait.

3. Un partitionnement mémoire différent entre CPU et GPU. Sur une architecture unifiée, la façon dont le pool est alloué et cohérent (via NVLink-C2C) conditionne la taille de contexte tenable et la charge des couches. Un partitionnement plus favorable au GPU peut réduire les allers-retours et donc les latences, même à bande passante constante.

Attention à un point de rigueur : la capacité exacte du RTX Spark n’est pas confirmée par les sources officielles du corpus. Le chiffre « 128 Go » n’apparaît que dans des titres tiers, et une variante 64 Go existe bel et bien côté DGX Spark (annoncée le 2 octobre 2026, en vente le 23 octobre 2026 à 4 999 $). Les mini-PC GB10 de partenaires, comme l’Acer DGX / mini-PC RTX Spark, sont crédités de 128 Go de mémoire unifiée et livrés à partir du 8 septembre 2026, à 500 à 1 000 dollars sous le prix NVIDIA officiel. C’est un point d’arbitrage majeur : à silicium égal, la capacité et le prix varient fortement selon l’OEM.

Il faut enfin signaler une lacune documentaire béante : aucun whitepaper GB10, aucune note de version NVIDIA détaillant le partitionnement mémoire CPU/GPU, la taille du cache L2 ou le rôle exact du NVLink-C2C ne figure dans notre corpus. Toute affirmation précise sur ce point relèverait de l’extrapolation.

Benchmarks : ce qui est publié, ce qui manque, et comment mesurer soi-même sans se mentir

Soyons lucides : aucun chiffre tok/s, TTFT ou tenue de contexte 32k/128k n’est disponible dans le corpus pour le GB10, le RTX Spark ou le DGX Spark — ni de NVIDIA, ni de ServeTheHome, Phoronix, Tom’s Hardware, Level1Techs ou r/LocalLLaMA. Les seuls tests labo identifiés (Les Numériques) portent sur le CPU, pas sur l’inférence LLM. Les benchmarks publiés par le magazine (14 tok/s single-stream, 410 t/s prefill, 67 tok/s sur 35B-A3B, ~41 tok/s single-stream en TP=2 FP8, ~350 tok/s agrégés à concurrence 32) constituent la base la plus solide dont on dispose — et ils portent sur DGX Spark, pas sur RTX Spark.

Face à ce vide, la seule attitude honnête est de mesurer soi-même avec un protocole reproductible. Voici une recette concrète :

# 1. Débit brut en décodage, modèle 8B Q4_K_M
llama-bench -m llama-3.1-8b-instruct.Q4_K_M.gguf -p 512 -n 128 -ngl 99

# 2. Tenue du contexte : on monte progressivement jusqu'à 32k puis 128k
llama-bench -m model.Q4_K_M.gguf -p 32768 -n 128 -ngl 99
llama-bench -m model.Q4_K_M.gguf -p 131072 -n 128 -ngl 99

# 3. TTFT via vLLM (mesure de la latence du premier token)
vllm serve model --max-model-len 32768 --gpu-memory-utilization 0.90
# puis requête avec streaming et horodatage côté client

# 4. Bande passante effective pendant l'inférence
nvidia-smi dmon -s u -d 1   # utilisation
# et compteurs PMU pour la bande passante réelle

Les métriques à consigner systématiquement : tok/s en décodage, tok/s en prefill, TTFT, bande passante effective (Go/s), mémoire résidente, et tenue du contexte (le modèle répond-il correctement à 32k ? à 128k ?). Sans ces cinq axes, toute comparaison DGX Spark / RTX Spark est de la foi, pas de la mesure.

Diagnostic : êtes-vous limité par la mémoire, par le compute ou par le logiciel ?

C’est la question que tout possesseur de DGX Spark finit par se poser. Voici une grille opérationnelle.

Goulot mémoire. Signature : le débit en tok/s est proportionnel à la taille des poids et plafonne exactement au calcul B / P ci-dessus. Un 8B en Q8 qui tourne à ~30 tok/s sur 273 Go/s est en goulot mémoire pur — c’est normal, pas un bug. Le remède : réduire la quantification (Q8 → Q4_K_M) ou choisir un modèle MoE.

Goulot compute. Signature : le prompt processing (prefill) est lent mais le décodage est correct. Le GPU sature en calcul matriciel sur les longues entrées. Remède : activer Flash Attention, réduire la longueur de prompt, ou passer à un backend plus optimisé (TensorRT-LLM).

Goulot logiciel. Signature : débit anormalement bas, mémoire mal utilisée, offload mal réglé. Causes fréquentes : mauvais backend, quantification inadaptée, --n-gpu-layers trop bas (le modèle déborde en RAM CPU), cache KV non quantifié qui mange la mémoire.

Trois cas types pour fixer les idées :

8B en Q8 qui sature la bande passante : c’est attendu. Passez en Q4_K_M si le débit prime, ou acceptez ~30 tok/s.
70B en Q4 qui déborde en RAM CPU : vérifiez --n-gpu-layers 99 et la quantification du cache KV (--cache-type-k q8_0 --cache-type-v q8_0).
120B en Q4 qui exige un contexte réduit : à ~60–70 Go de poids, il reste peu de place pour le cache KV sur 128 Go. Réduisez --max-model-len ou quantifiez le cache.

Commandes de diagnostic :

# llama.cpp : contrôle de l'offload et du cache KV
llama-cli -m model.gguf -ngl 99 --flash-attn \
  --cache-type-k q8_0 --cache-type-v q8_0 -c 32768

# vLLM : contrôle de l'occupation mémoire
vllm serve model --gpu-memory-utilization 0.90 --max-model-len 32768

Quantification, découpage de contexte et batching : les réglages qui compensent l’écart de bande passante

Si le RTX Spark est réellement plus rapide en mémoire, un DGX Spark peut néanmoins combler une partie de l’écart par le réglage. Voici les trois leviers, avec leurs compromis.

1. La quantification. Le choix Q4_K_M vs Q5_K_M vs Q8_0 vs FP8 est un arbitrage débit/qualité. En règle générale : Q4_K_M pour maximiser le débit et la capacité, Q5_K_M comme compromis, Q8_0 quand la qualité prime et que la bande passante le permet, FP8 pour les backends qui le supportent nativement (vLLM, TensorRT-LLM). Sur un 70B, passer de Q8 à Q4 double virtuellement le débit et libère de la place pour le contexte.

2. Le découpage du contexte. Pour tenir 32k sur un 70B, plusieurs techniques : fenêtre glissante, RoPE scaling, et surtout cache KV quantifié en Q8 (--cache-type-k q8_0 --cache-type-v q8_0), qui divise par deux l’empreinte du cache sans dégradation notable. Sur les configurations multi-Spark du magazine, un pool de cache KV partagé de 1 105 096 tokens a été mesuré — preuve que le cache KV est un poste de consommation majeur.

3. Le batching. Le continuous batching de vLLM augmente le débit agrégé sans augmenter la bande passante par token : c’est le levier le plus rentable pour du serving multi-utilisateurs. Le speculative decoding avec un draft model 1B est l’autre grand levier : on génère plusieurs tokens candidats avec un petit modèle rapide, vérifiés par le grand modèle. NVIDIA documente d’ailleurs un workflow edge AI pour DGX Spark avec TensorRT Edge-LLM et des résultats de speculative decoding (blockchain.news, 30 octobre 2026) — signal fort que cette technique est au cœur de l’optimisation locale.

Configurations concrètes :

# llama.cpp : Q4_K_M + cache KV Q8 + Flash Attention
llama-server -m model.Q4_K_M.gguf -ngl 99 --flash-attn \
  --cache-type-k q8_0 --cache-type-v q8_0 -c 32768 -np 4

# vLLM : batching continu + contexte étendu
vllm serve model --max-model-len 32768 --gpu-memory-utilization 0.90 \
  --enable-prefix-caching

# Ollama : parallélisme et contexte
OLLAMA_NUM_PARALLEL=4 ollama run model

Un Spark ou plusieurs ? Quand le cluster de DGX Spark reste la bonne réponse

Un seul boîtier — même avec une mémoire plus lente — suffit pour beaucoup d’usages : servir un 8B en Q4 à un utilisateur, faire tourner un 35B-A3B en MoE à bon débit (jusqu’à 67 tok/s mesurés), prototyper. Mais dès que l’on vise du 120B+ en Q8/FP16, du contexte 128k, du serving multi-utilisateurs ou du fine-tuning LoRA distribué, le cluster devient la bonne réponse.

Les chiffres du magazine sont éloquents : 2× DGX Spark supportent jusqu’à 405 milliards de paramètres, offrent un débit single-stream de ~41 tok/s et ~350 tok/s agrégés à concurrence 32 en TP=2 avec vLLM sur DeepSeek-V4-Flash FP8, avec un prefill de ~1785 t/s. C’est un tout autre régime. La mise en réseau repose sur 200 Gb/s ConnectX-7 entre nœuds — le NVLink-C2C reste intra-boîtier, pas inter-boîtier — et les logiciels de distribution sont vLLM avec tensor parallelism, Ray et llama.cpp RPC. Les limites pratiques sont réelles : latence inter-nœuds, complexité opérationnelle, et un coût qui grimpe vite. Mais pour les charges lourdes, aucun boîtier unique — RTX Spark compris — ne rivalise avec un cluster de deux à quatre Spark.

Fine-tuning local sur GB10 : ce que la mémoire unifiée permet vraiment (et ce qu’elle interdit)

Le fine-tuning LoRA/QLoRA est l’un des grands arguments de la mémoire unifiée. Concrètement, sur 128 Go, un 8B en QLoRA tient sans difficulté, un 13B aussi, et un 70B en QLoRA reste envisageable avec un rank modéré, un batch size de 1 à 2 et du gradient checkpointing. Les bibliothèques de référence : Unsloth, Axolotl, Hugging Face PEFT, TRL.

Point crucial souvent oublié : la bande passante mémoire conditionne aussi la vitesse d’entraînement, pas seulement l’inférence. Chaque pas de gradient relit les poids et les activations. Un différentiel de bande passante entre RTX Spark et DGX Spark se traduit donc directement en temps par epoch. Sans benchmark public dans le corpus, on reste qualitatif : un gain de bande passante proportionnel se répercute approximativement proportionnellement sur le débit d’entraînement, à configuration identique.

Limite majeure : pas de NVLink inter-boîtier pour le fine-tuning distribué. Le cluster Spark est excellent pour l’inférence distribuée (TP=2), moins évident pour l’entraînement multi-nœuds, où la latence réseau pèse. Et l’absence de benchmarks publics dans le corpus impose la prudence.

Ce que ça change pour votre station : arbitrage entre débit, capacité et écosystème logiciel

La mémoire plus rapide du RTX Spark est un avantage réel en décodage — proportionnel, mesurable, mais non chiffré officiellement à ce jour. Elle ne compense cependant ni la capacité (128 Go vs variantes 64 Go, avec un écart de prix qui s’est creusé : 4 999 $ pour le 64 Go, au-delà de 6 000 $ pour le 128 Go), ni l’écosystème logiciel du DGX Spark (DGX OS, NGC, TensorRT-LLM, support NVIDIA, mises à jour comme l’October 2026 Release). Les mini-PC partenaires (Acer, livrés dès le 8 septembre 2026, 500 à 1 000 $ sous le prix NVIDIA) brouillent encore l’arbitrage.

Les critères de choix, en pratique :

Servir un 8B en Q4 à un utilisateur : le DGX Spark suffit, la mémoire plus rapide ne change pas la donne.
Viser un 70B en Q8 avec 32k de contexte et du batching : l’écart de bande passante pèse réellement, et le RTX Spark devient attractif.
Fine-tuner ou servir plusieurs utilisateurs : le cluster de deux à quatre Spark reste la réponse, quel que soit le boîtier.

Les questions ouvertes à surveiller : la confirmation officielle des specs RTX Spark (fréquence, bus, capacité), les benchmarks indépendants à venir (Artificial Analysis a lancé son AA-AgentPerf-Local le 29 septembre 2026, avec DGX Spark, Ryzen AI Halo, MacBook Pro M5 Pro et RTX 5090 au programme — de quoi combler le vide), et l’évolution des backends (llama.cpp, vLLM, TensorRT-LLM) pour exploiter au mieux la mémoire unifiée du GB10. En attendant, mesurez vous-même : c’est la seule vérité qui compte pour votre station.

Sources

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

📬 Restez à la pointe

Recevez chaque semaine les nouveautés de ce magazine par email.

💬 Une remarque, une correction ?

Aidez-nous à améliorer cet article. Nous prenons en compte vos retours.

RTX Spark contre DGX Spark : même silicium GB10, mémoire plus rapide — ce que cela change vraiment quand on fait tourner des LLM chez soi

RTX Spark contre DGX Spark : même silicium GB10, mémoire plus rapide — ce que cela change vraiment quand on fait tourner des LLM chez soi

GB10, N1X, RTX Spark, DGX Spark : un seul silicium, trois étiquettes — et une mémoire qui n’est pas la même

273 Go/s, 256 bits, 128 Go unifiés : ce que la hiérarchie mémoire du GB10 fait réellement à vos modèles

Ce que « mémoire plus rapide » veut dire concrètement : fréquence, largeur de bus et partitionnement CPU/GPU

Benchmarks : ce qui est publié, ce qui manque, et comment mesurer soi-même sans se mentir

Diagnostic : êtes-vous limité par la mémoire, par le compute ou par le logiciel ?

Quantification, découpage de contexte et batching : les réglages qui compensent l’écart de bande passante

Un Spark ou plusieurs ? Quand le cluster de DGX Spark reste la bonne réponse

Fine-tuning local sur GB10 : ce que la mémoire unifiée permet vraiment (et ce qu’elle interdit)

Ce que ça change pour votre station : arbitrage entre débit, capacité et écosystème logiciel

Sources

Laisser un commentaire Annuler la réponse