J’ai passé les dernières années à coller des API cloud sur des produits. Ça marche. Ça facture aussi. Et surtout, ça te laisse avec un trou dans le contrat : tes prompts, tes outils, tes données métier voyagent chez quelqu’un d’autre, et le modèle que tu as testé mardi n’est plus tout à fait le même jeudi.
Alors j’ai posé une NVIDIA DGX Spark sur le LAN. Pas un jouet USB. Pas un 7B quantifié jusqu’à l’os sur un laptop. Une vraie boîte d’inférence, dans le salon (ou presque), pour servir des modèles open source à 70 milliards de paramètres et les brancher sur un agent.
Spoiler, parce que le sous-titre de ce blog n’est pas là pour décorer : le hardware tient la promesse. L’agent, lui, ne devient pas magique parce que le modèle est plus gros.
Le métronome à côté de la boîte n’est pas là pour le tokens/seconde. Dans un harnais d’agent — ici Hermes Agent — le heartbeat est le tic qui réveille la session quand elle est idle, lui redonne un tour, et refuse qu’elle improvise entre deux battements. Le Spark fournit le cerveau. Le harnais tient le tempo.
Qu’est-ce qu’un Spark, concrètement ?
Oublie la slide marketing. Voici ce qui est sur la machine, une fois le couvercle (mental) ouvert :
- 1 GPU Blackwell GB10, compute 12.1, mémoire unifiée 128 Go avec le CPU. Il n’y a pas de « VRAM dédiée » à la
nvidia-smiclassique : CPU et GPU se partagent le même tas. - 20 cœurs ARM (Neoverse), architecture
aarch64. Ce n’est pas un PC x86 déguisé. - Ubuntu 24.04, kernel NVIDIA, CUDA 13, Docker + NVIDIA Container Toolkit. Le socle est un DGX, pas un tinkering du dimanche.
- NVMe ~3,7 To. Les poids, ça pèse. Compte ~70 Go pour un 70B en FP8, et le cache Hugging Face grimpe très vite si tu gardes plusieurs candidats.
La contrainte qui change tout : 128 Go, c’est large pour un 70B. C’est trop juste pour en servir deux à la fois, et c’est largement insuffisant pour un monstre type DeepSeek-V4-Flash (~150 Go, recette cluster à 2 nœuds). Un Spark, ce n’est pas un cluster. C’est un nœud, très dense.
Servir un modèle, pas « lancer Ollama et prier »
J’ai choisi vLLM dans l’image NVIDIA officielle, API compatible OpenAI, port unique. Pas d’installation pip sur l’hôte : tout passe par Docker. Les poids restent en cache, on allume un conteneur à la fois, on coupe l’autre. Rollback en une commande, zéro suppression.
Deux candidats sont descendus et ont réellement servi :
| Qwen 2.5 72B Instruct FP8 | Llama 3.3 70B Instruct FP8 | |
|---|---|---|
| Poids | ~71 Go | ~68 Go |
| Contexte natif | 32k (poussé à 64k) | 128k (servi à 64k) |
| Parser outils | Hermes | llama3_json |
| Verdict inférence | Ça tourne | Ça tourne |
Les deux ont exigé --enforce-eager. Sans ça, la compilation CUDA a crashé. Bienvenue dans le monde réel des stacks trop neuves sur du silicium trop neuf.
DeepSeek-V4-Flash ? Hors course sur un seul Spark. Les métadonnées Hugging Face tiennent en quelques mégaoctets. Les poids, non. Si quelqu’un te vend « le dernier modèle du moment » sur une machine de 128 Go sans regarder la recette, c’est du vent.
Le test qui compte : un agent, pas un playground
Un curl sur /v1/chat/completions qui te sort un haïku, tout le monde sait le faire. Moi, je voulais savoir si un 70B local tenait la route derrière un agent : date du jour, identité du modèle, et une vraie action (lire un skill, exécuter un outil, ne pas inventer le reste).
J’ai donc branché la boîte sur Hermes Agent, via Telegram. Mêmes outils, même skill agenda, mêmes pièges. Seul le cerveau change. Le heartbeat, lui, reste le même : c’est le harnais qui bat, pas le LLM.
Qwen 2.5 72B
Il parle bien. Il est même trop à l’aise. Sauf que :
- il invente la date au lieu d’appeler
date; - il se prend parfois pour un autre modèle ;
- pour l’agenda, il invente des outils qui n’existent pas (
hermes calendar, et autres noms sortis du chapeau).
Un 72B qui n’ouvre pas le skill et qui raconte qu’il a créé l’événement : c’est exactement le genre de mensonge confortable que tu n’acceptes pas dans un produit.
Llama 3.3 70B
Mieux sur le factuel. La date, il va la chercher. L’identité, après un détour, il arrête de jouer à un autre. Sur l’agenda ? Même maladie : outils inventés, ou pire, un cron déguisé en événement CalDAV. Le modèle te dit que c’est dans Synology. Ce n’est pas dans Synology.
Changer de cerveau n’a pas fait découvrir le skill. Ça a juste déplacé l’hallucination.
Et si on enlève des outils, pour simplifier ?
Mauvaise idée, testée. Un profil d’outils trop maigre, et Llama se rabat sur la recherche web pour tout : la date, le calendrier, le reste. Il échoue plus vite, avec plus de confiance. Moins d’outils ≠ plus de discipline. Ça rend l’outil restant trop attractif.
Ce que le Spark a vraiment prouvé
Trois leçons, sans enrobage.
1. L’inférence locale à 70B n’est plus un fantasme de labo.
FP8 + mémoire unifiée + vLLM, et tu as une API OpenAI chez toi. La souveraineté n’est plus un slide : c’est un conteneur qui écoute sur le LAN.
2. Un modèle plus capable ne répare pas une boucle d’agent mal cadrée.
Qwen et Llama sont tous les deux assez forts pour imiter l’usage d’un outil. Ils ne sont pas assez disciplinés, seuls, pour refuser d’inventer. Le skill doit être un CLI réutilisable, pas une recette « recode un python3 -c à chaque fois ». Sinon l’agent recommence à zéro, se trompe, et te ment.
3. Le matériel impose des choix d’architecture, pas des rêves.
Un modèle à la fois. Pas DeepSeek-V4-Flash. Pas deux 70B en parallèle. Un script de bascule, un cache conservé, et on arrête de croire qu’on va « juste ajouter le dernier papier de la semaine ».
J’ai aussi appris, dans la douleur, qu’un événement CalDAV « à 16h30 Europe/Paris » peut s’afficher à 18h30 si tu sors le VTIMEZONE historique IANA au lieu du bloc compact CET/CEST que Synology comprend. Ce n’est pas le LLM. C’est le monde réel, celui où les specs RFC et les NAS ne sont pas d’accord. Le déterminisme, encore lui, se cache dans les détails.
Alors, on jette le cloud ?
Non. On arrête de lui donner le monopole par paresse.
Le Spark me sert un Llama 3.3 70B quand je veux de l’inférence chez moi, sans ticket d’API, sans surprise de changelog. Qwen reste en réserve, prêt à être rallumé. Les deux ont un rôle de moteur. Le métier — skills, outils, fuseaux, secrets, validations — ça reste du logiciel. Du déterministe, autour du non-déterministe. J’en parlais déjà ici, avant d’avoir la machine : quand l’IA défie le déterminisme.
La suite n’est pas « un modèle encore plus gros ». La suite, c’est un agent qui ne peut plus mentir sur une action qu’il n’a pas faite. Ça, aucun GPU ne te le vend dans la boîte.
Jérémy @ Code Alchimie
Envie d'en savoir plus sur mon activité ?
Rendez-vous sur code-alchimie.fr.