Dans l’épisode précédent, j’ai installé une NVIDIA DGX Spark sur le LAN pour servir des modèles open source chez moi. Le matériel a tenu : un modèle à 70 milliards de paramètres, une API compatible OpenAI, aucun ticket cloud. L’agent, lui, n’a pas suivi.
Pour rappel, l’agent c’est Hermes : un logiciel qui parle sur Telegram, choisit des outils (terminal, fichiers, skills) et s’appuie sur le modèle pour décider. Le Spark ne fait que l’inférence. Le reste, c’est le harnais.
Avec Qwen 2.5 72B, le modèle inventait la date et des commandes qui n’existaient pas. Avec Llama 3.3 70B, il allait chercher la date pour de vrai, puis prenait un cron (un rappel système) pour un événement dans Synology. Changer de « cerveau » 70B n’a pas suffi : aucun des deux n’est allé lire le skill agenda que j’avais déjà écrit.
La conclusion de l’autre article tenait en une phrase. La suite n’est pas un modèle encore plus gros. C’est un agent qui ne peut plus prétendre avoir fait une action qu’il n’a pas faite.
Deux jours plus tard, j’ai quand même changé de modèle. Pas pour un 120B. Pour Qwen 3.8 27B FP8 : 27 milliards de paramètres, poids en 8 bits, environ 29 Go. Plus petit, plus récent, entraîné pour se servir d’outils plutôt que pour discuter dans un playground. Et cette fois, l’événement était vraiment dans l’agenda.
Spoiler, toujours le même sous-titre : c’est un succès. Ce n’est pas de la magie.
Pourquoi un 27B, après deux 70B
Le déclencheur, c’est un commentaire assez juste de Morgan sur Linkedin. Qwen 2.5 et Llama 3.3 sont une génération en arrière sur l’usage des outils. Qwen 3.8 27B, sorti à l’été 2026, a été post-entraîné pour le terminal, les appels de fonctions, le computer-use. Un 27B plus récent peut mieux choisir un outil qui existe déjà qu’un 72B de 2024.
Ça ne veut pas dire qu’il inventera tout seul le script d’agenda. Même leçon que l’autre article : le harnais fixe le contrat (quel skill, quel CLI, quelles interdictions). Le modèle l’exécute plus ou moins bien.
Sur 128 Go de mémoire unifiée, le calcul est plus simple. Un 70B en FP8 pèse environ 70 Go. Qwen 3.8 27B FP8 pèse environ 29 Go. Il rentre sans jouer des coudes. Llama et Qwen 2.5 restent en cache sur le disque, stoppés, pas supprimés. Un seul modèle allumé à la fois. On revient en arrière en une commande. Cette règle-là n’a pas changé.
Le serveur non plus : vLLM, l’image Docker NVIDIA, le flag --enforce-eager (sans ça, la compilation CUDA plante sur ce silicium trop neuf). Le contexte est servi à 64 000 tokens, parce que Hermes refuse de démarrer en dessous. Les poids sont dans /data/huggingface, pas dans le cache Hugging Face de l’hôte, qui appartient à root et n’est pas inscriptible. Détail de salon. Piège réel.
Ce qui a cassé, avant que ça marche
Un curl sur l’API qui répond « OK », tout le monde sait le faire. Ça prouve que le serveur parle. Ça ne prouve pas que l’agent tient. Derrière Hermes, deux pièges ont laissé Telegram sans une ligne, avant même qu’on parle d’agenda.
Le mode « thinking ». Qwen 3.8, par défaut, réfléchit à voix haute. Il écrit qu’il devrait lancer la commande date, en français dans le texte, sans appeler l’outil. Couper cette option dans Hermes n’a pas suffi. Il a fallu la couper dans vLLM, côté serveur. Le modèle n’est pas le client. Le client n’est pas le serveur. Encore une fois : le déterministe (la config) autour du non-déterministe (le LLM).
Le format des outils. Quand un modèle veut lancer une commande, il n’écrit pas une phrase : il émet un bloc que le serveur doit reconnaître. Qwen 3.8 n’utilise pas le JSON attendu par le parser « Hermes ». Il émet du XML à sa façon (<function=terminal>…). Avec le mauvais parser, vLLM générait une trentaine de tokens, Hermes les jetait, Telegram affichait « Empty response ». En passant au parser qwen3_xml, ces blocs deviennent de vrais appels d’outils. Sans ça, tu peux avoir le meilleur 27B du monde : l’agent voit du vide.
Le matériel était déjà bon. C’est l’alignement entre le modèle et ses outils qui a débloqué le test.
Le débit, cette fois mesuré
L’autre article évitait le tokens par seconde : le métronome à côté de la boîte n’est pas là pour ça, il rappelle le rythme du harnais. Un commentaire de Quentin sur LinkedIn a demandé le chiffre quand même. J’ai donc mesuré les deux modèles avec la même recette : vLLM, mode eager, une requête à la fois, température à zéro, le même prompt en français.
| Llama 3.3 70B Instruct FP8 | Qwen 3.8 27B FP8 | |
|---|---|---|
| Poids | 68 Go | 29 Go |
| Mise en route (32 tokens) | 2,78 tok/s | 7,73 tok/s |
| 256 tokens, trois fois | 2,83 tok/s | 7,78 tok/s |
| En flux / premier token | 2,86 tok/s / 0,53 s | 7,83 tok/s / 0,23 s |
| 512 tokens | 2,82 tok/s | 7,78 tok/s |
| Prompt long (environ 1 500 à 1 700 tokens) | 2,65 tok/s de bout en bout | 7,41 tok/s de bout en bout |
Qwen 3.8 est environ 2,7 fois plus fluide. Le premier mot arrive deux fois plus vite (0,23 s contre 0,53 s). Ce n’est pas un bench de labo saturé, ni un gros batch. La compilation CUDA, on l’évite : elle plante. C’est simplement le coût d’un 27B face à un 70B, en eager, sur un seul Spark.
Le prompt ne fait pas le même nombre de tokens (31 chez Qwen, 56 chez Llama) : les deux modèles ne découpent pas le français de la même façon. Ça ne change pas le rapport.
Pour un agent Telegram — une question, un outil, une réponse… 7,8 tokens par seconde, c’est confortable. À 2,8, c’était déjà de l’inférence chez soi. Ce n’était pas agréable à lire en direct.
Le test qui compte, rejoué
Même harnais, même skill CalDAV, même script. Le CLI s’appelle add_event.py : il vit dans l’environnement Python de Hermes, on le relance tel quel, on ne recode pas un python3 -c à chaque fois. Même piège à éviter : un cron n’est pas un événement de calendrier. Seul le modèle change.
Agenda. J’ai demandé d’ajouter « Test Qwen38 » le samedi 5 septembre 2026 à 18h00, trente minutes, dans mon agenda. L’agent a fait deux choses, dans l’ordre : ouvrir le skill caldav-integration, puis lancer le script. Trois allers-retours avec le modèle, environ 50 secondes. Dans Synology : 18:00–18:30, heure de Paris, le bon calendrier, le bon titre. Pas un cron. Pas un outil inventé. Pas le décalage de deux heures qu’on avait vu quand le fichier iCal embarquait tout l’historique IANA : ce correctif était déjà dans le script.
Heure. Il a lancé TZ=Europe/Paris date et répondu 16:50, heure de Paris. Le Raspberry Pi qui fait tourner Hermes est en UTC. Sans le fuseau dans la commande, tu te trompes deux fois : une fois à cause du modèle, une fois à cause de l’horloge de la machine.
Identité. Laissé à lui-même, Qwen se présente comme « un assistant Alibaba ». C’est écrit dans ses poids. Dans cette maison, le contrat dit de lire la config (hermes status). Il l’a fait : Hermes Agent, modèle Qwen/Qwen3.8-27B-FP8, endpoint local. Ce n’est pas de l’introspection. C’est un fichier.
Le jour, encore. « Quel jour sommes-nous ? » peut toujours tomber juste sans lancer date. Le 4 septembre 2026 n’était pas difficile à deviner dans une session déjà datée. L’heure, elle, oblige à regarder l’horloge. Je n’appelle pas ça une victoire.
En quoi c’est un succès
Trois choses ont tenu. Une seule est le modèle.
1. Le Spark sert un 27B récent comme il servait un 70B.
Même image Docker, même port, même bascule. 29 Go au lieu de 70. Les anciens poids sont toujours là. DeepSeek-V4-Flash reste hors course (recette cluster, trop gros pour 128 Go). L’architecture n’a pas changé : une machine, un modèle allumé.
2. Le débit devient tenable au quotidien.
7,8 tokens par seconde et 0,23 s avant le premier mot, ce n’est pas un cloud. C’est assez pour un agent qui parle, appelle un outil, et répond avant que tu ailles faire un café. Le 70B prouvait que c’était possible. Le 27B prouve que c’est usable.
3. L’agent a fini le travail que les 70B rataient.
Pas parce que 27 milliards ce serait « mieux » que 70. Parce que le modèle et le tuyau étaient d’accord : le mode thinking coupé au serveur, le parser XML qui correspond à Qwen 3.8, le skill déjà écrit, le CLI déjà là. Qwen 3.8 a choisi le skill. Il ne l’a pas inventé.
Un mot sur le « hint » Hermes. C’est un paragraphe dans le prompt système, pas dans le message que j’envoie sur Telegram. Il décrit la maison : cron n’est pas CalDAV, l’agenda passe par ce script, l’heure se lit à Paris. C’est le plan de l’atelier. Ce n’est pas lui dicter chaque phrase. Si tu dois ajouter une recette à chaque nouvelle question, tu n’as plus un agent. Tu as un mode d’emploi que tu tiens à jour à la main.
Ce qui n’a pas changé
Le skill reste un script réutilisable. Sans add_event.py, Qwen 3.8 aurait inventé une commande hermes calendar, comme les autres. Le 27B n’écrit pas tout seul dans Synology. Il exécute un contrat.
Couper des outils pour « simplifier » n’aide toujours pas. On l’avait déjà vu avec Llama : il se rabattait sur le web pour tout, y compris la date.
Le cloud n’est pas mort. Gemini reste un retour en arrière d’une commande. Le Spark a juste cessé d’être un labo : c’est le moteur par défaut de l’agent, chez moi, sur le réseau local.
Et le métronome n’a toujours rien à voir avec le 7,8 tok/s. Le heartbeat, c’est le harnais qui rappelle l’agent à l’ordre. Le GPU, c’est le cerveau. Quand les deux sont d’accord, l’événement est dans l’agenda. Quand ils ne le sont pas, tu as une belle phrase et un calendrier vide.
L’épisode 1 est ici : Un DGX Spark, deux LLM open source, zéro miracle.
Jérémy @ Code Alchimie
Envie d'en savoir plus sur mon activité ?
Rendez-vous sur code-alchimie.fr.