Manuel DGX Spark

Auteur : @0xSero

Relecteurs : @alexocheema et @alexzfunk

Remerciements particuliers à : @MiaAI_lab

Si vous envisagez de faire tourner l'inférence en local, vous entendrez forcément parler de cette pépite. C'est une machine conçue pour servir l'IA localement, pensée pour être petite, épurée, silencieuse et relativement abordable (page du DGX Spark de NVIDIA).

Quand j'ai entendu parler du DGX Spark pour la première fois, je n'étais pas convaincu. Malgré ses 128 Go de mémoire, la bande passante de 273 Go/s me semblait trop faible. À titre de comparaison, une RTX 5090 offre environ 6,5 fois plus de bande passante (1 792 Go/s), tout en ne disposant que de 32 Go de VRAM.

Au lancement du Spark, les pratiques d'ingénierie d'inférence comme le décodage spéculatif étaient loin d'être aussi répandues, et la plupart des petits modèles étaient nettement moins performants.

À mesure que l'industrie de l'IA progresse et se développe, l'intelligence se compresse dans des formats de plus en plus réduits, ce qui permet enfin d'exploiter ces petites boîtes à leur plein potentiel.

1. L'ingénierie d'inférence est de plus en plus demandée.
2. Les LLM deviennent plus compétents en ingénierie d'inférence.
3. Une inférence de haute qualité améliore le système.

Désormais, le DGX Spark est capable de faire tourner des modèles très intelligents avec une vitesse équivalente à celle des services cloud, le tout depuis le confort de votre maison ou de votre bureau. Il existe une multitude de logiciels d'IA pour vous aider à coder, remplir vos déclarations d'impôts, étudier ou simplement vous divertir.

Par vitesse, j'entends le nombre de tokens par seconde qu'une seule personne perçoit. Le matériel cloud est bien plus rapide, mais les fournisseurs le partagent entre de nombreux utilisateurs et l'optimisent pour réduire le coût par token, si bien que chacun n'en obtient qu'une fraction. Chez vous, la machine vous appartient, donc toute sa puissance vous est dédiée. Plus de détails dans les notes avancées.

Les Sparks sont faits pour être reliés

Les DGX Sparks consomment très peu d'énergie. Ils tournent souvent autour de 95 W lorsqu'un modèle est chargé et en service.

De ce fait, ils nécessitent peu de refroidissement et sont plutôt silencieux comparés aux GPU dédiés. Vous pouvez en empiler de 2 à 4 sur un circuit électrique américain standard sans aucune crainte. C'est là tout l'intérêt, plus que l'efficacité brute : par unité de vitesse mémoire, un B300 de data center effectue environ deux fois plus de travail par joule (voir les notes avancées). Le Spark, lui, se branche sur une simple prise murale.

Chaque Spark intègre une carte réseau ConnectX-7 dotée de deux ports QSFP, offrant 200 Gb/s, soit 25 Go/s. Cela vous permet de relier les Sparks entre eux afin d'augmenter la mémoire et la bande passante mémoire effective.

Comment relier les DGX Sparks

Avec le parallélisme tensoriel, chaque matrice de poids est répartie entre les Sparks, et chaque Spark lit uniquement sa propre part, depuis sa propre mémoire, en même temps que les autres. La vitesse de lecture s'additionne donc (test de mise à l'échelle de NVIDIA) :

• 546 Go/s pour deux Sparks
• 819 Go/s pour trois
• 1 092 Go/s pour quatre

La mise à l'échelle est presque linéaire. Lors des tests de NVIDIA, l'écriture était 2 fois plus rapide avec deux Sparks et 3,7 fois plus rapide avec quatre (tableau 3). Si cela fonctionne aussi bien, c'est parce que la liaison ConnectX-7 offre une latence très faible et que CUDA peut transférer des données entre les Sparks directement depuis le code du GPU (plus d'explications ici).

La mémoire s'additionne de la même manière : 128 Go chacun, 512 Go pour quatre, dont environ 120 Go par Spark réellement utilisables pour les charges de travail IA.

La possibilité d'empiler les Sparks atténue son principal défaut, à savoir une bande passante mémoire plus faible. Sa faible consommation sur une prise standard le rend exceptionnel pour un utilisateur seul ou un petit foyer.

DGX Sparks reliés en vrai

Dense vs MoE

Il existe actuellement deux grandes architectures de modèles : sparse (creuse) et dense. Les modèles Mixture-of-Experts (MoE) comme Qwen3.6-35B n'activent que 3 milliards de paramètres par token généré, soit 9 fois moins que Qwen3.8-27B.

Cela rend les LLM sparse particulièrement adaptés au DGX Spark. Ils compensent parfaitement sa bande passante mémoire plus faible, offrant aux utilisateurs une expérience rapide malgré la taille totale du modèle.

Le MoE n'est pas seulement avantageux pour le DGX Spark. C'est aussi une meilleure architecture en data center. Ce qui a changé pour le local, c'est un seuil : on attend une certaine vitesse, et les modèles denses suffisamment intelligents étaient trop volumineux pour tourner aussi vite à la maison. Les modèles MoE ont franchi cette limite, ce qui les rend désormais à la fois utiles et rapides sur du matériel local. Les modèles denses y parviendront peut-être aussi un jour.

LLM denses vs MoE

Décodage spéculatif

Tout LLM compatible avec MTP, DSpark ou DFlash sera mieux adapté, car les modèles brouillons (draft models) sont généralement minuscules et demandent peu de calculs pour générer un token correct.

Cela améliore considérablement le débit que les Sparks peuvent atteindre, au prix d'à peine 1 à 2 Go de mémoire, une ressource dont le Spark regorge.

Comme le MoE, le décodage spéculatif est utile partout, pas seulement à la maison. Mais c'est leur combinaison qui a permis à l'IA locale de franchir un cap. Avant, les meilleurs modèles open source tournaient désespérément lentement sur le matériel domestique.

Comment le décodage spéculatif améliore le débit

Plusieurs agents simultanément

Un seul Spark peut traiter huit requêtes ou plus en même temps, chacune conservant une vitesse de conversation. Par exemple, Qwen3.6-35B, capable de coder, d'utiliser un ordinateur et un navigateur, de monter des vidéos et des images, et d'assurer un support général, peut gérer jusqu'à 8 sessions simultanées à environ 40 tok/s chacune.

Pour référence, avec l'abonnement ChatGPT Pro, GPT-6-Astra tourne à une vitesse moyenne de 37 tok/s.

Vitesses moyennes d'Astra

C'est possible parce que le Spark offre beaucoup de puissance de calcul par rapport à sa vitesse mémoire. Servir huit personnes implique toujours de lire le modèle une fois par étape, mais en effectuant huit fois plus de calculs, et le Spark a de la marge à revendre. En 16 bits, il délivre environ 100 TFLOPS pour 273 Go/s, soit près de 370 opérations par octet de mémoire lu. Un M3 Ultra offre environ 26 TFLOPS pour 819 Go/s, soit environ 32 opérations (chiffres d'EXO). Cela représente environ 11 fois plus de calcul par octet, sans même compter le matériel 4 bits du Spark, dont les Mac sont dépourvus.

Du vrai travail

Qwen3.6-35B sur un seul Spark a créé une vidéo qui a cumulé plus de 80 000 vues en une journée. L'opération n'a pris que 3 minutes : il a récupéré un dossier contenant 3 vidéos, les a assemblées et a accéléré le rendu 4 fois tout en maintenant le taux d'images sous la limite imposée par X.

https://x.com/0xSero/status/2072206209323802746

Coûts

Le DGX Spark était initialement affiché à 3 999 $, un prix ensuite revu à la hausse à 4 699 $. Les tarifs de tout le matériel informatique ont augmenté en 2026.

Le prix réel est encore plus élevé. La boutique officielle de NVIDIA est en rupture de stock. Le moins cher que je trouve tourne autour de 5 000 $, les modèles d'occasion se vendent environ 6 000 $, et le 21 septembre, j'ai vu le site de NVIDIA demander 7 999 $ pour la même machine que j'avais payée 4 699 $ cinq semaines plus tôt.

Tarification du GX10

Marketplace de NVIDIA le 21 septembre. Publication

4000$ - 4700%

Conseils d'achat

• N'importe quelle machine GB10 fera l'affaire. ASUS, Dell, MSI et d'autres vendent leurs propres versions basées sur la même puce. Elles font tourner les mêmes logiciels et les mêmes recettes. Vérifiez la taille du SSD : 1 To se remplit vite dès que vous gardez quelques gros modèles sous la main. Je prendrais 4 To.
• Achetez le câble en même temps que le deuxième Spark, vous en aurez besoin pour les relier.
• Certains OEM proposent des Sparks avec une meilleure circulation d'air

Consommation, bruit et facture d'électricité

Le bruit et la chaleur générés par les GPU dédiés ne sont pas à prendre à la légère : avec 4 RTX 3090, vous pouvez facilement consommer 1600 à 2000 W pour seulement 1/5e de la mémoire. J'ai dû sortir ma tour RTX Pro 6000 de mon bureau car elle transformait régulièrement la pièce en fournaise à 35 °C.

Un circuit domestique américain standard peut supporter en toute sécurité environ 1 440 watts toute la journée (code électrique américain). Au-delà, il faut tirer une nouvelle ligne, ce qui implique de faire appel à un électricien.

• Un Spark faisant tourner un modèle consomme environ 90 à 200 watts (ServeTheHome). Cela représente environ 12 $ par mois si vous le laissez allumé 24h/24.
• Quatre Sparks consomment environ 500 watts au total, auxquels s'ajoutent environ 240 W pour un switch. Comptez 66 à 100 $ par mois, et tout tient sur une seule prise.
• Ma configuration à quatre GPU atteint un pic de 1 600 watts. C'est plus que ce qu'un seul circuit peut supporter, et cela coûte environ 300 $ par mois.

D'où viennent ces chiffres. Chaque valeur correspond à un type de mesure différent, les voici donc côte à côte. Le coût mensuel suppose que la machine tourne à cette consommation 24 heures sur 24, à 18 cents le kWh :

Mes tests

Pourquoi quatre Sparks consomment plus de quatre fois 90 W. Le chiffre de 90 W correspond à un Spark servant un modèle seul. Lorsqu'un gros modèle est réparti sur quatre machines, chaque Spark travaille sur chaque mot et sollicite constamment sa liaison réseau, ce qui augmente sa consommation, à environ 125 W en moyenne selon mes relevés. Ainsi, 12 $ et 66 $ par mois correspondent à un fonctionnement à plein régime non-stop. Une utilisation réelle, avec des temps d'inactivité, coûtera moins cher.

L'électricité ne va pas devenir moins chère pour autant. Les tarifs résidentiels américains ont augmenté d'environ 5 % cette année, atteignant près de 18 cents le kWh, en partie à cause de tous les nouveaux data centers. En août, ma propre facture a doublé pour atteindre 1 000 $ par mois, avec la configuration GPU, deux Sparks et quatre climatiseurs qui tournaient en même temps.

Bruit du DGX Spark

Et le bruit ? Ma configuration GPU ressemble à un réacteur d'avion. Voici le maximum que mes quatre Sparks peuvent atteindre :

Quelques conseils pratiques :

• Utilisez-les avec toutes sortes de modèles d'IA, modèles mondiaux, génération d'images, etc.
• Posez-les sur la tranche. Les miens chauffent moins comme ça, en laissant de l'espace autour de la grille.
• Rejoignez les communautés Discord/Reddit/X pour obtenir de l'aide au débogage
• Configurez Tailscale sur l'ensemble de votre parc

Les six modèles que j'utilise vraiment

J'en ai testé des dizaines. Voici les six vers lesquels je reviens toujours.

Un token représente environ les trois quarts d'un mot, et tout ce qui dépasse 30 donne l'impression d'une conversation normale.

Pourquoi chaque chiffre précise une tâche. La plupart de ces recettes utilisent le décodage spéculatif, où un petit modèle assistant anticipe la suite. Le code et le JSON sont faciles à deviner, contrairement à la prose ; ainsi, un même modèle sur une même machine peut tourner deux fois plus vite sur l'un que sur l'autre. Des prompts plus longs ralentissent également le processus. C'est pourquoi chaque vitesse indiquée ici précise ce qui était généré et la longueur du prompt :

Pour mesurer cela correctement sur de nombreuses tâches, NVIDIA propose SPEED-Bench, qui teste le décodage spéculatif sur des prompts réels issus de 11 catégories, avec des longueurs d'entrée allant de 1K à 32K tokens. Je ne l'ai pas encore fait tourner sur les Sparks.

• Un Spark : Qwen3.6-35B, Qwen3.8-Flash-Next, Qwen3.8-27B
• Deux Sparks : GLM-5.3-Flash.
• Quatre Sparks : DeepSeek-V4.1-Flash.

Qwen3.8-Flash-Next sur deux Sparks créant des animations et un petit jeu. (21 septembre) Publication

Où les trouver. Chaque modèle possède une page officielle, et la section 6 contient une recette Spark testée pour chacun d'eux :

• Qwen3.6-35B, ou la version 4 bits de NVIDIA
• Qwen3.8-27B
• Qwen3.8-Flash-Next
• GLM-5.3-Flash, ou ma version pour un Spark
• DeepSeek-V4.1-Flash
• GLM-5.3, ou ma version 3 bits

Comment les gros modèles arrivent à tenir

La réponse tient en un mot : la quantification. Elle compresse les poids d'un modèle, mais avec perte : chaque poids est stocké sur moins de bits (disons 4 au lieu de 16), ce qui réduit le modèle au quart de sa taille, au prix d'une perte de détails. L'objectif est de se rapprocher autant que possible du comportement du modèle original tout en compressant les poids.

Plus vous compressez, plus la qualité se dégrade. Turboderp a mesuré cela pour Qwen3.8-27B. Chaque point représente une version compressée. Plus c'est à gauche, plus c'est petit ; plus c'est bas, plus c'est proche de l'original :

Divergence KL moyenne par rapport à la taille sur le disque pour les versions compressées de Qwen3.6-35B-A3B, issues de plusieurs fournisseurs. Échelle logarithmique. Graphique : https://huggingface.co/turboderp/Qwen3.8-27B-exl3

Deux formats comptent sur le Spark :

• NVFP4 est le format 4 bits de NVIDIA, et la puce du Spark le lit nativement. Qwen3.6-35B passe de 72 Go à 24 Go et tient sur un seul Spark avec de la marge.
• EXL3 vous permet de choisir exactement le nombre de bits à utiliser. GLM-5.3-Flash en 4 bits pèse 176 Go et tient sur deux Sparks. En 2 bits, il descend à 85 Go et tient sur un seul, bien qu'il perde un peu en précision.

Astuce :

4 bits est le compromis idéal pour les petits modèles, 3 bits pour les plus grands

Comment savoir si un modèle compressé reste bon. Les bonnes fiches de modèles indiquent à quel point la version réduite reste fidèle à l'originale. Deux métriques à surveiller :

• Accord Top-1 : la fréquence à laquelle le petit modèle choisit le même mot suivant que l'original. Plus c'est haut, mieux c'est. Mon GLM-5.3-Flash pour un Spark est d'accord environ 80 % du temps.
• Divergence KL : l'écart entre ses prédictions et celles de l'original. Plus c'est bas, mieux c'est. Mon GLM-5.3 non élagué en 3 bits obtient un score de 0,089. La version élaguée de 197 Go affiche 0,511. C'est le prix à payer pour tenir sur moins de Sparks.

6. D'un à quatre Sparks : la marche à suivre étape par étape

C'est la partie sur laquelle on m'interroge le plus. Avancez une étape à la fois. Chaque étape fonctionne indépendamment, arrêtez-vous donc là où vous êtes satisfait.

La plupart des recettes ci-dessous proviennent de MiaAI Lab, qui regroupe les meilleures configurations Spark dans des dépôts que vous pouvez cloner et lancer avec un seul script. Quelques-unes sont les miennes. Chacune précise sur quoi elle a été testée et à quelle vitesse elle a tourné.

Faites ceci une seule fois, sur chaque Spark :

1. Mettez-le à jour. Lancez les mises à jour dans le DGX Dashboard, puis redémarrez.
2. Accédez-y depuis votre ordinateur portable. Utilisez NVIDIA Sync ou un simple SSH. Pour y accéder depuis l'extérieur de chez vous, NVIDIA propose un playbook Tailscale.
3. Créez un compte et un token Hugging Face. La plupart des recettes téléchargent les modèles avec. Placez-le dans un fichier .env, jamais dans le dépôt.
4. Vérifiez votre disque. Les modèles sont lourds. Une recette pour un Spark nécessite entre 25 et 130 Go d'espace libre. Celle de DeepSeek pour quatre Sparks demande environ 476 Go sur le premier Spark.
5. Docker est déjà installé. DGX OS est livré avec, et presque toutes les recettes tournent à l'intérieur, ce qui vous évite d'installer des paquets Python à la main.

Étape 1 : un Spark

Commencez par LM Studio. Suivez le guide pas à pas de NVIDIA, téléchargez Qwen3.6-35B et commencez à discuter. Cela prend environ une heure. Cela vous confirme que la machine fonctionne avant de vous attaquer à plus complexe.

Passez ensuite à une recette. Les recettes utilisent vLLM ou SGLang, qui sont plus rapides que LM Studio et peuvent servir plusieurs agents simultanément. Choisissez-en une :

1. Qwen3.6-35B (4 bits NVFP4) MiaAI Lab 95 tok/s pour un utilisateur, 317 au total pour huit ~50 Go
2. Qwen3.8-27B (4 bits NVFP4) MiaAI Lab ~51 tok/s sur du code avec l'assistant DSpark, ~23 en chat ~24 Go
3. Qwen3.8-Flash-Next (4 bits NVFP4) MiaAI Lab 48,7 tok/s pour un utilisateur, 162,9 au total pour huit ~130 Go
4. GLM-5.3-Flash (2 bits EXL3) la mienne, ou la version un Spark de la recette de Mia 10 à 25 tok/s, contexte de 262K, vision ~85 Go

La première est la plus simple. Trois lignes suffisent :

1git clone <https://github.com/MiaAI-Lab/Unsloth-Qwen3.6-35b-NVFP4-DGX-Spark.git>
2cd Unsloth-Qwen3.6-35b-NVFP4-DGX-Spark
3./start.sh

Une fois lancé, vous obtenez une adresse de type OpenAI sur le Spark. Pointez Pi, opencode, Open WebUI ou l'outil de votre choix dessus.

Astuce :

si un modèle refuse de démarrer, c'est presque toujours un problème de mémoire. Fermez d'abord les autres modèles. Un Spark fait tourner un seul gros modèle à la fois.

Étape 2 : deux Sparks

C'est la configuration que je recommande le plus. Comme je le disais en août : "2 DGX Sparks et vous êtes tranquille."

2 dgx sparks

Le câble. Il vous faut un câble QSFP court entre les deux ports QSFP. N'importe lequel de ceux-ci fera l'affaire (guide des câbles) :

• Celui de NVIDIA : Câble QSFP 0,4 m pour DGX Spark, 99,99 $. Souvent en rupture de stock.
• Ceux mentionnés dans la documentation NVIDIA : Amphenol NJAAKK-N911 ou Luxshare LMTQF022-SD-R, 0,5 m, environ 159 à 187 $.
• Une option 200G moins chère : NVIDIA MCP1650-V00AE30, environ 84 $.

La liaison fonctionnera à 200 Gb/s quel que soit votre choix. N'utilisez ni l'USB-C ni le port 10 GbE pour cela. Ils sont bien trop lents.

Configurez la liaison. Suivez le playbook de NVIDIA pour relier deux Sparks. Il attribue une adresse à chaque port et vérifie la vitesse. Configurez ensuite un accès SSH sans mot de passe du premier Spark (le "head") vers le second (le "worker"). Toutes les recettes pour deux Sparks en ont besoin.

Je vous conseille de demander à Claude ou GPT de configurer cela pour vous, c'est plus simple.

Choisissez une recette :

1. Qwen3.8-Flash-Next (4 bits NVFP4) MiaAI Lab 52,1 tok/s pour un utilisateur avec MTP, contexte jusqu'à 1M
2. GLM-5.3-Flash (4 bits EXL3) MiaAI Lab 62,9 tok/s pour un utilisateur, 146,5 au total pour quatre, contexte de 850K
3. DeepSeek-V4.1-Flash (2,9 bits EXL3) MiaAI Lab 38,8 à 43,0 tok/s sur du code, contexte de 600K
4. GLM-5.3 (3 bits EXL3, élagué à 197 Go) ma fiche de modèle tient ; vitesse non mesurée pour l'instant

La plupart des recettes pour deux Sparks se ressemblent : copiez les paramètres d'exemple, renseignez les adresses des deux Sparks, téléchargez, lancez. Voici celle de GLM-5.3-Flash :

1cp .env.example .env     # définissez HEAD_IP et WORKER_IP
2./download.sh
3./start.sh

Attention :

relier les Sparks fonctionne, mais c'est là que les logiciels sont les moins aboutis. Suivez une recette testée et prévoyez un après-midi entier la première fois.

Étape 3 : trois Sparks

Trois Sparks ne nécessitent aucun switch. Chaque Spark possède deux ports QSFP, vous les reliez donc en triangle : A vers B, B vers C, C vers A. Soit trois câbles. NVIDIA prend en charge cette configuration sous forme d'anneau sans switch.

Trois Sparks vous offrent environ 384 Go. C'est suffisant pour ce que deux ne peuvent pas contenir :

• DeepSeek-V4.1-Flash à sa précision native. La recette de MiaAI Lab le fait tourner sur un triangle de trois Sparks à 51,0 tok/s pour un utilisateur, avec un contexte de 256K. Elle inclut une commande doctor qui vérifie SSH, Docker et les liaisons réseau avant le démarrage.
• GLM-5.3-Flash avec plus de marge. La recette EXL3 pour deux Sparks dispose d'un script start-tp3.sh pour trois.
• GLM-5.3, non élagué. Ma version de 293 Go nécessite environ la mémoire de trois Sparks.

La recette DeepSeek illustre bien le fonctionnement des plus grosses configurations. Elle comporte plusieurs étapes, et non une seule :

1./start.sh doctor    # vérifie ssh, docker, les liaisons et le disque
2./start.sh share     # partage le dossier du modèle avec les autres Sparks
3./start.sh serve     # démarre les workers, puis le head

Astuce :

certains modèles ne se divisent uniformément que par 2 ou 4. Vérifiez que la recette mentionne bien "3x" avant d'acheter le troisième.

Étape 4 : quatre Sparks

Quatre Sparks vous offrent environ 512 Go. Il existe deux façons de les relier.

Option A : un switch (ce que j'utilise). Chaque Spark est relié par un câble à un switch 200 GbE, de sorte que chacun n'est qu'à un saut de tous les autres. NVIDIA propose un playbook pour cela. Les switches utilisés par la communauté :

• MikroTik CRS812-8DS-2DQ-2DDQ-RM. Ses ports 400G se divisent chacun en deux liaisons 200G.
• MikroTik CRS804-4DDQ-hRM. Une option plus compacte (notes de montage pour quatre Sparks).
• Exxact propose une bonne liste de courses pour un cluster de quatre Sparks : switch, câbles et alimentation.

Comme je le disais en septembre : "Je ne pense pas qu'il y ait meilleure affaire sur le marché que 4 Sparks avec un switch MikroTik."

Option B : sans switch. Reliez les quatre en anneau, chaque Spark étant câblé à ses deux voisins. Les Sparks qui ne sont pas adjacents communiquent via celui qui se trouve entre eux. Cela économise l'achat d'un switch, mais la configuration est plus complexe :

• SparkRing est une pile logicielle complète pour les paires sans switch et les anneaux à quatre Spark. C'est un logiciel en version alpha, pensez donc à épingler une version précise.
• Cette recette GLM-5.3-Flash tourne sur un anneau de quatre Spark avec quatre câbles 100G courts et un NCCL patché. Environ 45 tok/s en moyenne, jusqu'à 100 environ une fois le système chaud.

Choisissez votre recette :

• DeepSeek-V4.1-Flash (natif) MiaAI Lab, start-tp4.sh 45,4 tok/s pour un utilisateur, 134,2 au total pour seize, contexte d'1 M
• GLM-5.3-Flash (NVFP4 4 bits) anneau sans switch ~45 tok/s en moyenne, ~100 à chaud

Mes meilleurs résultats personnels sur quatre unités sont de 118 tok/s pour GLM-5.3-Flash avec un assistant DFlash2, et de 83,8 à 95,3 tok/s pour DeepSeek-V4.1-Flash sur des prompts courts (post).

Des outils utiles à chaque étape

• \\sparkDash :\\ un tableau de bord web qui regroupe tous vos Spark dans une seule fenêtre. GPU, mémoire, réseau et tokens par seconde en temps réel. Plusieurs des vitesses mentionnées dans ce guide ont été mesurées avec cet outil.
• \\Les playbooks Spark de NVIDIA :\\ les guides officiels pour LM Studio, Ollama, vLLM, la liaison des Spark, et bien plus encore.
• \\local-ai-registry :\\ mes recettes et tous les tests de vitesse que j'ai réalisés.
• \\b12x :\\ le moteur mathématique ultra-rapide qui fait tourner de nombreuses recettes Spark. Vous ne l'installez pas vous-même ; ce sont les recettes qui s'en chargent. Voir les notes avancées ci-dessous.

Conclusion

Le Spark est une boîte à mémoire. Il héberge de gros modèles, les fait tourner silencieusement sur le courant domestique, et devient plus performant à chaque nouvelle unité ajoutée.

Si vous débutez aujourd'hui :

1. Achetez-en un et faites tourner Qwen3.6-35B depuis LM Studio dès le premier jour.
2. Passez à une recette dès que vous cherchez plus de vitesse ou que vous voulez lancer de nombreux agents.
3. Achetez le deuxième Spark et le câble lorsque vous voudrez utiliser GLM-5.3-Flash ou DeepSeek-V4.1-Flash. Pour la plupart des gens, c'est là qu'il faut s'arrêter.
4. Passez à trois ou quatre uniquement si vous visez les plus gros modèles ou si vous souhaitez en faire tourner plusieurs simultanément.

Est-ce que je les rachèterais ? Oui. Et si je devais tout recommencer, j'en achèterais deux dès le premier jour.

Avancé : comment la mise en réseau des Spark passe à l'échelle

Vous n'avez pas besoin de cette section pour utiliser un Spark. Elle sert à comprendre pourquoi les chiffres se comportent comme ils le font.

Quasiment linéaire, pour la génération

Chaque mot généré par le modèle implique de lire ses poids actifs depuis la mémoire. Répartissez le modèle sur plusieurs Spark et chacun lira sa part en même temps : les vitesses de lecture s'additionnent donc.

NVIDIA l'a mesuré. En passant d'un à deux puis à quatre Spark, le temps nécessaire pour générer chaque mot est passé de 269 ms à 133 ms, puis à 72 ms. Soit un gain de 2,0x avec deux unités et de 3,7x avec quatre (blog de NVIDIA, tableau 3).

On s'approche autant de la linéarité parce que la liaison ConnectX-7 offre une latence très faible, et que les échanges entre les Spark peuvent se faire directement au sein du code GPU. Cette explication pour Mac détaille davantage ce même principe.

Après chaque couche, les Spark s'échangent leurs résultats partiels avant que la couche suivante ne puisse démarrer. L'échange est minime, mais il se produit pour chaque couche et pour chaque mot. Chacun coûte un peu de temps, un coût fixe qui ne diminue pas quand on ajoute des Spark.

• La liaison est de 200 Gb/s, soit environ 25 Go/s. C'est un dixième de la vitesse mémoire propre au Spark. Ce n'est pas un problème car les échanges sont faibles.
• Elle utilise le RDMA. Les données passent directement de la mémoire d'un Spark à celle de l'autre, sans que le CPU ait à les copier. Chaque port QSFP apparaît comme deux moitiés de 100 Gb/s, et le logiciel doit utiliser les deux pour atteindre les 200 complets (détails). NCCL, la bibliothèque de NVIDIA dédiée, gère cela.
• La lecture passe moins bien à l'échelle que la génération. Dans le même test NVIDIA, la lecture d'un prompt de 32K tokens a été 1,6x plus rapide avec deux Spark et 2,1x avec quatre. La lecture déplace beaucoup plus de données entre les Spark à chaque étape.
• Les anneaux ajoutent des sauts. Dans un triangle à trois Spark, chaque unité est reliée par câble aux deux autres. Dans un anneau à quatre Spark, certaines paires communiquent via un voisin. Un switch place tout le monde à un seul saut de distance. SparkRing écrit son propre code d'échange (SIRCL) pour accélérer les anneaux.
• Les modèles à mélange d'experts ajoutent une seconde répartition. Les recettes combinent souvent le parallélisme de tenseurs avec le « parallélisme d'experts », où différents Spark hébergent différents experts.

Les deux autres moyens d'accélérer

• De nombreux utilisateurs simultanés. Le Spark lit le modèle une seule fois par étape et répond à tout le monde à partir de cette unique lecture. Ainsi, la vitesse globale grimpe bien plus vite que la vitesse pour un utilisateur seul.
• Un modèle de décodage spéculatif qui anticipe. MTP, DSpark et DFlash2 fonctionnent tous ainsi. Un petit modèle assistant rapide ébauche plusieurs mots, et le grand modèle les vérifie tous en une seule lecture. Quand les suppositions sont justes, vous obtenez plusieurs mots pour le prix d'un. C'est ainsi que GLM-5.3-Flash passe de 27 tok/s sur du texte libre à 65 sur des sorties structurées dans la même recette.

Qwen3.6-35B-A3B en 4 bits sur un Spark, avec un accélérateur activé. Source : test de vitesse local-ai-registry, août 2026.

L'IA cloud et l'IA locale sont deux mondes différents

Un GPU cloud est nettement plus rapide qu'un Spark. Mais les fournisseurs cloud partagent chaque GPU entre de nombreux utilisateurs, et ils choisissent un point d'équilibre entre le coût par token et la vitesse par utilisateur. La plupart privilégient le coût, si bien que chaque utilisateur reçoit moins de tokens par seconde que ce que le matériel pourrait offrir à une seule personne. InferenceX illustre ce compromis pour Qwen3.8-Flash-Next.

À la maison, ce compromis n'existe pas. La machine est à vous, vous pouvez donc consacrer toute sa puissance à une seule personne. C'est pourquoi un Spark peut paraître aussi rapide qu'un service cloud, même si son matériel ne l'est pas objectivement.

sm_121 : pourquoi l'écosystème logiciel du Spark est un monde à part

Chaque GPU NVIDIA possède un numéro de « capacité de calcul » (compute capability) qui indique au logiciel les instructions dont il dispose. Le GPU du Spark est 12.1, ou sm_121 (premières impressions de Simon Willison). Les RTX 5090 et RTX PRO 6000 sont sm_120, un cousin proche. Les puces de data center de NVIDIA, B200 et B300, sont sm_100 et sm_103, une famille différente.

Cela compte, car le code IA le plus rapide est écrit pour une seule famille à la fois. Au lancement du Spark, une grande partie de ces codes ne tournaient pas ou tournaient lentement (forum NVIDIA, ticket vLLM).

La solution est venue de développeurs écrivant du code spécifique au Spark :

• b12x de Local Inference Lab est une bibliothèque de kernels pour sm_120 et sm_121 : le DGX Spark, le RTX Spark, la RTX 5090 et la RTX PRO 6000. Elle couvre les opérations matricielles en 4 bits (NVFP4, MXFP4), l'attention pour les modèles de type DeepSeek, les couches à mélange d'experts et un chargeur de modèle rapide. Elle s'installe avec pip install b12x, et les recettes vLLM l'activent via des flags comme flashinfer_b12x. La recette Qwen3.6-35B l'utilise.
• SparkInfer est l'ancien nom de b12x. L'ancien lien redirige désormais vers b12x. Ma recette DeepSeek pour un seul Spark utilise son code d'attention à la fois pour la lecture et la génération. Ne le confondez pas avec sparkinfer de gittensor, un runtime distinct destiné aux cartes RTX (sm_120 uniquement).
• ExLlamaV3 est ce qui fait tourner les modèles EXL3. MiaAI Lab maintient un fork intégrant le portage Arm (GB10) et la prise en charge des modèles assistants.
• lil est le lanceur de Local Inference Lab. Il analyse la configuration de la machine et construit la commande vLLM adaptée pour un Spark isolé ou un groupe lié.

Avancé : le Spark comme machine de recherche

C'est l'aspect auquel je ne m'attendais pas. Le Spark est lent en génération, mais excellent en lecture. Or, la quasi-totalité du travail de recherche sur les modèles consiste à lire.

Le point fort du Spark : le prefill

Un modèle accomplit deux tâches distinctes :

• Le prefill, c'est la lecture de votre prompt. L'intégralité du prompt est traitée d'un coup, la limite est donc la puissance de calcul brute. Le GB10 n'en manque pas : jusqu'à 1 pétaflop de calcul en 4 bits.
• Le décodage, c'est la génération de la réponse, un mot après l'autre. Chaque mot exige de relire le modèle depuis la mémoire, la limite est donc la vitesse mémoire. C'est le point faible du Spark.

Ainsi, un Spark lit les prompts 13 à 41 fois plus vite qu'il ne génère de texte :

DeepSeek-V4.1-Flash sur quatre Spark : 3 360 tok/s pour lire un prompt de 32K tokens, 3 273 à 131K, tandis que la génération reste autour de 70 à 95. (20 septembre) Post

Pourquoi c'est exactement ce dont la recherche a besoin

Presque tout ce que je fais pour réduire la taille des modèles relève de la lecture, pas de la génération :

• La quantification (moins de bits). Les versions EXL3 et NVFP4 sont créées en faisant passer un texte d'exemple à travers le modèle et en mesurant la perte de chaque couche selon la largeur de bits. C'est de la lecture.
• L'élagage (moins d'experts). REAP fait passer un texte d'exemple dans un modèle à mélange d'experts et enregistre le taux d'utilisation de chaque expert. Les moins utiles sont supprimés. Mon GLM-5.3 de 197 Go conserve 168 experts sur 256. Là encore, c'est de la lecture.
• La vérification de la qualité. L'accord Top-1 et la divergence KL s'obtiennent en lisant le même texte avec le modèle original et le modèle réduit, puis en comparant leurs prédictions. Encore de la lecture.
• Les tests de contexte long. Vérifier qu'un modèle peut retrouver une information parmi 262 000 tokens revient essentiellement à effectuer une très longue lecture.

Mon propre flux de travail a évolué précisément pour cette raison. « Je fais désormais tourner tout mon élagage/exl3/benchmarking sur les DGX Spark, je garde les 6000 pour l'inférence. C'est plus lent, mais 2-3 jours contre 12 h, ça me va. » Le DeepSeek pour un seul Spark qui a dépassé les 100 000 téléchargements est un modèle élagué via REAP et compressé en EXL3.

En quoi cela sert vos objectifs de recherche

Si votre but est d'apprendre quelque chose sur un modèle, le Spark est parfaitement adapté :

• Il héberge les gros modèles. Vous pouvez évaluer un modèle de 300B sur une ou deux machines au lieu de louer un cluster.
• Il tourne pendant des jours sur le courant domestique. Les longs travaux de calibration et d'évaluation peuvent s'exécuter sans surveillance et sans facture salée.
• Il libère votre matériel rapide. Mes GPU servent les modèles pendant que les Spark effectuent le travail lent et minutieux.
• Vous pouvez calibrer sur vos propres données. J'ai élagué des modèles sur mes propres sessions d'agents et mes écrits, des données privées qui restent sur mon bureau.
• C'est un excellent hôte pour les agents de recherche. J'ai fait tourner quatre agents travaillant sur des objectifs de recherche simultanément sur les Spark, chacun à environ 120 tok/s.
• L'entraînement passe bien à l'échelle entre les Spark. Lors des tests de NVIDIA, le fine-tuning était 2x plus rapide sur deux Spark et 4x sur quatre, car les Spark ne se synchronisent qu'une fois par étape (tableau 5). Les playbooks de NVIDIA couvrent le fine-tuning avec PyTorch. Je n'ai pas chronométré l'entraînement moi-même.

Avancé : GB10, GB300 et le Spark comme mémoire supplémentaire

« GB » signifie Grace Blackwell : un CPU Arm et un GPU Blackwell réunis sur un seul boîtier, partageant leur mémoire via une liaison rapide appelée NVLink-C2C. Le GB10 du Spark est la plus petite déclinaison de ce concept, doté d'un CPU Arm à 20 cœurs conçu avec MediaTek.

Le GB300 est la version data center : un CPU Grace associé à des GPU Blackwell Ultra (B300). Il prend place dans les racks GB300 NVL72 de NVIDIA, et un seul GB300 propulse la DGX Station. Le GB10 n'est pas un morceau découpé dans un GB300. C'est la même architecture, miniaturisée, ce qui explique que le même logiciel tourne sur les deux.

Conclusion

Le DGX Spark s'est taillé une place de choix chez moi, et son support, son utilité et ses capacités progressent de jour en jour.

Sources et lectures complémentaires

• Mes posts : tout ce qui est daté ci-dessus se trouve sur mon profil X. Les vitesses proviennent de mes propres tests, publiés dans le local-ai-registry.
• Recettes : MiaAI Lab sur GitHub, mes modèles Hugging Face.
• Matériel et prix : page DGX Spark de NVIDIA, documentation matérielle NVIDIA, VideoCardz sur la hausse des prix, VideoCardz sur les prix de septembre, suivi des prix pi3g.
• Liaison des Spark : documentation clustering NVIDIA, blog de NVIDIA sur le passage à l'échelle, playbook avec switch, guide des câbles, guide de benchmarking NVIDIA pour deux Spark.
• Alimentation : test ServeTheHome, Tom's Hardware sur la consommation au repos, prix de l'électricité aux États-Unis (EIA via Utility Dive), code électrique américain sur les charges continues.
• Formats et logiciels : NVIDIA sur le NVFP4, ExLlamaV3, b12x, REAP, capacités de calcul.
• Vitesse cloud : InferenceX par SemiAnalysis.
• GB300 : spécifications GB300 NVL72, spécifications DGX Station, EXO sur Spark et Mac Studio.
• Pour commencer : les playbooks Spark de NVIDIA.
• Vue d'ensemble : State of Local AI: 2026.