Faire tourner des LLMs sur le DGX Spark
Oui, tu peux vraiment y faire tourner des LLMs locaux. Un modèle qui rentre en NVFP4 ou FP8 tourne avec assez de débit pour une équipe ou un agent en production. L'astuce est dans le choix de la précision et la config du moteur, pas dans la force brute.
Ce qu'est le DGX Spark
Le DGX Spark, c'est la petite machine d'IA de bureau de NVIDIA. Une superpuce GB10, de la mémoire que le CPU et le GPU partagent, et assez de capacité pour faire tourner en local des modèles que tu enverrais sinon dans le cloud. Pas de rack, pas de datacenter, juste à côté de ton bureau.
Le détail intéressant est dans le compute FP4. NVIDIA présente le Spark avec un petaFLOP FP4, mais sur sm_121 il manque le chemin d'instructions dont NVFP4 a besoin. vLLM prévient lui-même et retombe sur Marlin, qui déquantise les poids 4-bit vers BF16. Tu stockes donc en 4-bit, et ce gain mémoire est réel, mais tu calcules à un niveau plus élevé. Pour le compute pur c'est un inconvénient, pour la mémoire et la bande passante non, et sur ce matériel c'est là qu'est le gain.
- Puce
- GB10 superchip
- Mémoire
- 128 GB unified
- Compute
- SM12.1, pas de FP4 natif
- Gamme de prix
- ~€3.700 ex btw
Ce qui rentre dessus
La règle du pouce : la taille du modèle en milliards de paramètres, fois les octets par paramètre, c'est ce que tu dépenses en mémoire. BF16 coûte 2 octets par paramètre, FP8 un, NVFP4 un demi. Un modèle 30B en BF16, c'est donc environ 60 Go de poids, en NVFP4 plus que 15. À ça s'ajoute le KV cache, et il grandit avec ta longueur de contexte.
Avec 128 Go de mémoire unifiée tu as largement de la place pour la plupart des modèles open-weight, tant que tu ne fourres pas tout en BF16. Le choix de la précision n'est donc pas un détail, il décide si un modèle rentre et combien de contexte tu obtiens avec.
- BF16
- 2 bytes / param
- FP8
- 1 byte / param
- NVFP4
- 0,5 byte / param
Meilleure qualité, dévore la mémoire. Pour la codegen où ça doit être juste.
Le juste milieu. Divise la mémoire par deux, qualité à peine en baisse.
Place et débit au maximum. Très bien pour le RAG et les agents, attention pour la codegen.
À quelle vitesse
Deux chiffres comptent. Le prefill, c'est la vitesse à laquelle le modèle lit ton prompt, le decode, la vitesse à laquelle il crache ensuite des tokens. Avec des prompts courts tu remarques surtout le decode, avec un long contexte le prefill devient le goulot. Sur le Spark le decode passe bien à l'échelle, le prefill se cogne à un mur dès que ton contexte gonfle.
Sous pression la machine se comporte étonnamment posément. Envoie-lui plus de requêtes qu'elle ne peut gérer et elle les met proprement en file. Elle ne plante pas, elle ralentit. C'est exactement ce que tu veux pour un système sur lequel une équipe s'appuie le lundi.
Les chiffres exacts par modèle et longueur de contexte sont dans la suite de benchmarks, tournée sur un seul Spark avec un protocole de mesure fixe. Le raisonnement derrière ces trois chiffres est dans un essai à part.
- Decode @ petit
- 20,9 t/s/user
- Decode @ 25k
- 7,6 t/s/user
- Mur de prefill
- ~25k tokens
- Streams stables
- 25 parallel
Indication sur Gemma-4-26B-A4B en NVFP4. Ça varie par modèle et précision, les chiffres complets sont dans l'arena.
→ Vers la suite de benchmarks complèteQuel moteur
vLLM. C'est ce à quoi ça revient, en bref. C'est le moteur avec le meilleur support de NVFP4 sur le Spark, un chunked prefill correct, et un mode serve qui se comporte comme un vrai serveur d'inférence plutôt qu'un petit script de démo.
Il te faut quand même les bonnes flags. Chunked prefill activé, ton max-num-batched-tokens bien réglé, et l'utilisation mémoire ajustée à ton budget de contexte. Règle ça de travers et tu obtiens un serveur instable ou un débit qui n'a aucun sens. La config qui marche est dans le build log sur Gemma-4.
Combien ça coûte
L'achat est ponctuel, le courant continue de tourner. Un Spark tire environ 170 watts en charge. Ne compte pas sur du 24/7 à fond, il n'y arrive presque jamais en pratique. À environ 8 heures de vraie charge par jour tu tombes sur ≈€130/jaar de courant. Le coût marginal d'un token de plus est alors presque nul, juste du courant. Mais ne te crois pas riche : le vrai coût par token dépend de combien tu gardes la machine occupée, et il est loin d'être toujours inférieur à une API hébergée.
Le point de bascule dépend de ton volume. Si tu lances un prompt de temps en temps, une API cloud est moins chère. Si tu tournes jour après jour avec une équipe ou une charge de production, le matériel se rentabilise. Le calcul complet est sur la page des coûts.
- Achat
- ~€3.700 ex btw
- Courant en charge
- ≈170 W
- Courant par an
- ≈€130/jaar
- Par token en plus
- ≈€0,00
Courant basé sur ~8 heures de charge par jour à 0,26 €/kWh. Un Spark est rarement à pleine charge 24/7, donc tourner en continu surestime la facture.
→ La comparaison de coûts complète : local vs cloudPour qui
Pas pour tout le monde. Si tes données peuvent tranquillement aller vers un modèle hébergé, une API est plus simple et souvent moins chère. Le Spark devient intéressant dès que ça ne peut pas ou ne doit pas.
Pense aux PME et organisations qui travaillent avec des données personnelles, des documents internes ou des données clients qui doivent rester proches sous le RGPD. Là, la question n'est plus "quel est le modèle le plus rapide", mais "quelle partie a même le droit de sortir". Un Spark sous ton propre contrôle répond à ça bien plus facilement qu'un contrat avec un fournisseur cloud.
C'est aussi simplement agréable d'avoir ton inférence à la maison. Pas de rate limits, pas de changement de prix par trimestre, pas de modèle qui change sous tes pieds sans prévenir.
Reproduis-le toi-même
Tous les chiffres de ce site viennent d'un seul Spark, avec un protocole de mesure fixe : les mêmes prompts, les mêmes seeds, trois runs par mesure. Pas de cherry-picking, pas de benchmark marketing. La config, les prompts et la sortie brute sont ouverts sur GitHub.
Tu le fais tourner sur un autre Spark ou une autre version de vLLM et tu obtiens d'autres chiffres ? Fais-le savoir. C'est exactement le genre de retour qui rend toute cette suite meilleure.
À lire aussi
Gemma-4 sur le DGX Spark : là où le contexte fait mal
Neuf benchmarks, le mur de prefill en image, et la config vLLM qui a fini par marcher.
Lire la suite → BenchmarkGemma-4 : NVFP4 vs BF16
Les mêmes neuf tests, deux précisions. Là où NVFP4 double presque le débit.
Lire la suite → BenchmarkNemotron-3 : BF16 vs FP8 vs NVFP4
Trois précisions côte à côte sur le même modèle et le même Spark.
Lire la suite → QuantizationCe qu'est devenue la quantization après trois rounds de benchmarks
Le concept sous les chiffres : quelle tâche a le droit de tourner sur quelle précision.
Lire la suite → LensLes trois chiffres derrière un DGX Spark rapide
Decode, prefill et mise en file : la seule perspective qui expliquait chaque run de benchmark.
Lire la suite →