Mon cerveau local : le setup

Depuis quelques mois, je fais tourner ma propre stack d'inférence IA à la maison, sur un NVIDIA DGX Spark GB10.

C'est parti d'un problème assez simple. Je faisais tourner un agent Hermes sur un VPS avec Claude, mais quand Anthropic a durci ses conditions d'utilisation concernant l'usage de Claude dans des harness tiers (les frameworks d'agents comme OpenClaw ou Hermes), j'ai dû m'en passer.

J'ai testé plusieurs solutions, Claude via API et OpenRouter. Ça fonctionnait super bien, mais le problème était le coût. Quand je l'utilisais avec Claude Code, je payais mon abonnement mais j'avais un accès "illimité". En payant via API au token, on se rend vite compte qu'il ne faut pas faire n'importe quoi.

Je n'ai jamais apprécié le pay per use. C'est quelque chose qui me fait peur, qu'il faut monitorer en permanence. En tant que petite structure, voir chacune de mes requêtes me coûter quelques centimes, voire quelques euros, ça m'a vite refroidi et j'ai fini par arrêter.

C'est ce qui m'a amené à me renseigner sur l'inférence locale : certes il faut payer le hardware, mais une fois fait, on maîtrise complètement les coûts.

Cet article fait le tour complet du setup : le hardware, la stack logicielle, et comment un agent s'en sert au quotidien.

Pourquoi de l'inférence locale ?

Trois raisons, par ordre d'importance :

1. Un coût fixe et maîtrisé. Je ne vais pas vous vendre un calcul d'amortissement : à mon volume perso, une API coûterait objectivement moins cher que la machine. Ce que j'achète, c'est la tranquillité d'esprit. Consommer des tokens sans compteur qui tourne, ça change complètement le rapport à l'outil : on expérimente plus, on laisse des jobs tourner 24/7 sans se poser de question, on itère sans arrière-pensée.
2. La vie privée. Au moins je sais que mes données ne transitent pas chez une entreprise tierce.
3. L'apprentissage. Faire tourner vLLM soi-même, comprendre la mémoire unifiée, benchmarker des modèles : c'est un terrain de jeu qu'aucune API ne remplace.

Soyons honnêtes aussi sur ce que le local ne remplace pas : pour les tâches qui demandent le meilleur raisonnement possible, je passe encore par des modèles frontier. Le local et le cloud sont complémentaires, pas concurrents.

Le hardware : DGX Spark (GB10)

Le DGX Spark, c'est la machine "desktop AI" de NVIDIA construite autour de la puce GB10 Grace Blackwell : un CPU ARM et un GPU Blackwell qui partagent 128 Go de mémoire unifiée.

C'est ce dernier point qui change tout. Sur une config classique avec un GPU consumer, on est limité par la VRAM (24 Go sur une 4090). Ici, le modèle, le KV cache et le reste du système piochent dans le même pool de 128 Go. Concrètement, ça permet de servir confortablement des modèles de 30-70B paramètres en quantisé, avec du contexte long, sans gymnastique d'offloading.

Pourquoi le Spark plutôt qu'une autre machine ? Honnêtement, pas de grand tableau comparatif de mon côté : j'ai vu des gens que je suivais faire tourner des Qwen dessus avec un débit de tokens tout à fait correct, et ça m'a suffi pour me lancer.

La stack d'inférence

vLLM comme moteur

Le cœur du système, c'est vLLM qui sert unsloth/Qwen3.6-35B-A3B-NVFP4 (dispo sur HuggingFace). Le NVFP4 est particulièrement adapté au GB10 puisque c'est le format de quantisation natif de Blackwell. Faire tourner ce modèle proprement sur le Spark demande un peu de tuning ; si ça vous intéresse, écrivez-moi et je partagerai la recette.

Le service tourne via systemd, comme tout le reste du stack. Pas de Docker ici : sur une machine dédiée mono-usage, systemd suffit largement et simplifie le debug.

Les benchmarks

Voilà ce que ça donne en décodage, mesuré sur des générations de 500 tokens à différents niveaux de concurrence :

Streams	Decode (tok/s par stream)	Server (tok/s total)	Peak	TTFT
×1	89	84	113	117 ms
×2	87	182	193	175 ms
×3	62	178	235	297 ms
×4	57	203	307	218 ms
×6	62	199	276	2,94 s
×8	62	229	344	4,43 s

(Server = compteurs côté moteur ; Decode = tok/s mesurés côté client après le premier token. C'est pour ça qu'à ×1 le decode peut dépasser le total serveur.)

Quelques lectures de ces chiffres :

• En usage solo, c'est très confortable. 89 tok/s en décodage avec un premier token en 117 ms, on est largement au-dessus de la vitesse de lecture, et pour un agent c'est instantané en pratique.
• Le throughput serveur scale bien. De 84 tok/s à un stream jusqu'à ~229 tok/s (pics à 344) avec 8 streams en parallèle. Le continuous batching de vLLM fait son travail.
• Le débit par stream se stabilise autour de 60 tok/s dès 3 requêtes simultanées, ce qui reste très utilisable. Le vrai point de contention, c'est le TTFT qui décroche à partir de 6 streams (de ~220 ms à presque 3 s) : le batch sature et les nouvelles requêtes font la queue avant d'être admises. Pour des jobs d'agent en tâche de fond, on s'en fiche un peu.

Pour un usage perso (moi + les jobs planifiés d'Hermes), la machine est loin d'être saturée.

LiteLLM comme proxy

Devant vLLM, je fais tourner LiteLLM en proxy. Ça peut sembler être une couche de trop pour un seul backend, mais c'est en réalité la pièce qui rend le système flexible :

• Une seule API pour tout : mes clients (Hermes, Open WebUI, scripts) parlent à LiteLLM, qui route vers le modèle demandé. Changer de modèle, c'est changer un nom dans la requête, zéro modification côté client.
• Fallbacks : si le modèle local est indisponible (reboot, mise à jour), LiteLLM peut basculer sur un modèle cloud via OpenRouter.
• Observabilité : logs centralisés des requêtes, comptage de tokens, coûts.

Sécurité et réseau

La machine est derrière UFW avec une politique deny par défaut : seuls les ports nécessaires sont ouverts, et uniquement sur le réseau local et le tailnet.

Le point clé, c'est Tailscale : Hermes tourne sur un VPS, et c'est Tailscale qui route le trafic du VPS vers le Spark, comme si les deux machines étaient sur le même réseau. Résultat : le serveur d'inférence n'est jamais exposé publiquement, pas de port forwarding, pas de reverse proxy à sécuriser. Le VPS voit le Spark via son IP tailnet.

Hermes : l'agent qui consomme tout ça

C'est ici que le setup prend son sens. Le DGX Spark ne sert pas juste à chatter avec un modèle local : il alimente Hermes, l'agent que je fais tourner sur mon VPS et avec qui je discute sur Discord.

Concrètement, Hermes tourne à 100 % sur le modèle local, via Tailscale. Je m'en sers pour du suivi personnel (je lui envoie ce que je mange, il tient le journal), pour de la veille automatisée (un job vérifie si des places de concert se libèrent et me prévient), et pour de petites tâches de code. Rien de spectaculaire, mais c'est exactement le genre de charge de fond qui tourne sans compteur grâce au local.

Je détaillerai Hermes lui-même (configuration, jobs planifiés, intégrations Gmail et Calendar) dans un prochain article.

Local pour Hermes, frontier pour le reste

En pratique, la répartition est simple : Hermes tourne à 100 % sur le modèle local. Classification, résumés, suivi, petits scripts : le Qwen quantisé suffit largement, et mes données personnelles restent à la maison.

Pour le coding avancé et les tâches complexes, je reste sur Claude (via mon forfait Max). Un modèle local de 35B, aussi bien optimisé soit-il, ne remplace pas un modèle frontier pour du travail de fond sur une codebase. Chacun son rôle.

Ce qui marche, ce qui coince

Les plus :

• La facilité d'installation. Le stack complet (vLLM, LiteLLM, systemd, Tailscale) s'est monté sans galère majeure.
• La tranquillité d'esprit. Consommer des tokens sans se demander si ça coûte cher, ça change complètement le rapport à l'outil. On expérimente plus, on itère plus.
• La qualité et la vitesse du modèle. Ce n'est pas un modèle frontier, mais il est rapide (bon débit de tokens, TTFT très court) et largement suffisant pour les tâches d'agent.

Les moins :

• Le plafond de verre du modèle. On est loin d'un modèle frontier, donc je garde mon forfait Claude Max à côté. Le local ne m'a pas (encore) affranchi du cloud.
• Encore peu de cas d'usage câblés. La machine pourrait faire beaucoup plus. Pour un usage perso, il faut se forcer un peu à inventer les usages.

C'est d'ailleurs là que je vois le vrai potentiel de ce setup : en entreprise. Avec de vrais volumes (classification, extraction, résumés en masse, traitement de documents), le coût variable quasi nul change l'équation. De mon côté, je cherche justement des cas d'usage réels pour pousser cette machine dans ses retranchements : si vous avez des problématiques de ce genre dans votre structure, écrivez-moi, ça m'intéresse d'en discuter.

La suite

Trois chantiers devant moi :

• Câbler plus de cas d'usage dans Hermes. La machine tourne, autant la faire travailler.
• Continuer à benchmarker. De nouveaux modèles sortent en NVFP4 régulièrement, et des chiffres réels sur GB10, il n'y en a pas tant que ça en ligne.
• Surveiller le multi-Spark. Si GLM5.2 sur un petit cluster tient ses promesses, ça pourrait être la prochaine étape.