J'avais été agréablement surpris lors du vibe coding avec OpenCode. OpenClaw, lui, m'avait laissé un goût amer dans la bouche.

Un peu comme quand tout le monde arrive à faire un truc et que t'es le dernier de la classe à ne pas y arriver.

Aujourd'hui je teste Hermes avec ma toute nouvelle carte graphique moyen de gamme. Voici mes pérégrinations.

Le setup

• Debian 13 (Trixie)
• AMD Radeon RX 9060 XT 16 Go
• CPU Ryzen 5 3700X
• 32 Go de RAM DDR4

L'objectif : faire tourner un assistant personnel capable de gérer des contextes conséquents, sans envoyer mes données dans un cloud dont je ne maîtrise pas la localisation juridique.

Étape 1 : Ollama, les bonnes premières impressions

J'installe Ollama, version 0.24.0, et je le configure en Vulkan (on rajoute la variable d'environnement OLLAMA_VULKAN=1). Premier test avec Qwen 3.5:9B, le modèle tient en VRAM avec un contexte de 64K, réponse fluide, latence acceptable. Je me dis que ce hard est enfin suffisamment puissant.

Je tente de monter en puissance. Gemma4:26B en IQ4_XS depuis Huggingface. Ollama télécharge, et l'éjecte le modèle au moment du chargement

llama_model_load: error loading model: error loading model architecture: unknown model architecture: 'gemma4'

Même scénario avec d'autres modèles et quantifications d'Onslaught. Ollama doit modifier la fiche de description du modèle pour que ça passe : il y a des modèles Gemma 4 disponibles sur ollama.com. Il faudrait que je trouve leur process de quantification des modèles... flemme.

Étape 2 : Le tests d'Hermes

Je bascule sur Hermes, je l'installe dans un docker. c'est plus

Premier constat : le mail comme frontend c’est… rustique. Pour la messagerie instantanée, je tente une passerelle Matrix auto-hébergée avec Conduit et Element. Après trois heures de batailles sur la configuration du reverse proxy traefik et des certificats Let's Encrypt, j'abandonne faute de temps. Je vais tester sur l’instance publique de Matrix.org (et je me note de remplacer traefix).

Les tools — ces fonctions que l'agent peut invoquer pour agir sur le système — s'enchaînent mal, et le modèle boucle sur une vérification inutile. Il refuse d'utiliser le serveur MCP configuré et veut impérativement utiliser curl pour faire des appels API.

Pire : à chaque redémarrage de la passerelle llama.cpp, l'historique de conversation est réinitialisé. Pas de persistance de session dans cette configuration. Ça fait bizarre d'avoir un salon de conversation où l’interlocuteur a tout oublié d'une ligne sur l'autre.

Ollama a cessé plusieurs fois de répondre à l'inférence alors que le reste de l’API fonctionnait. Obligé de le redémarrer. Ça c’est réglé en basculant de Vulkan à ROCm. Et là c'est une galère sans nom. N'utilisez pas Debian (pas pour l'instant) pour faire tourner ROCm : les paquets de la doc officielle on des conflits de version avec les paquets système, notamment rocm-info. C'est dommage que je n'aie pas pris de notes, mais mon conseil : si vous voulez utiliser ROCm, pour l'instant, passez sous Ubuntu.

J’ai deux astuces pour ollama cependant :

• La librairie de calcul ROCm n’est pas installée automatiquement, il faut réinstaller ollama.
• Si vous avez nvidia-smi installé, l’installeur n’installera pas ROCm, il pensera que vous avez une Nvidia.

Étape 3 : La tentation du SaaS

Fatigué, je cède. MiniMax, développeur chinois de LLM propose un service SaaS qui est réputé pour avoir un bon rapport quota de token/prix. En plus, le modèle est très fort en Agentic AI d'après les tests. Inscription, paiement par carte avec conversion EUR/Dollars : 217 € TTC crédités.

L'intégration dans Hermes est immédiate : une URL d'API, une clé, et l'agent reprend du service. Leur modèle M2.7 code, lit mes mails via IMAP, planifie des tâches dans Nextcloud. Le confort est radical.

Mais des anomalies surviennent. Au milieu d'une réponse en français impeccable, des mots russe apparaissent, parfois des caractères chinois.

Je n'ai pas investigué plus loin, je l'avais vu sur les vidéos de Minutora. Parfois je lui fais la remarque, il répond que c'était une blague et reparle bien français pendant un temps.

En tout cas, si je trouve que ce modèle n'est pas extrêmement rigoureux, mais débrouillard et plutôt intelligent, en plus de ne pas être cher.

Tout de même, ça me chagrine d'envoyer des données perso ou faire du travail stratégique pour l'entreprise avec un serveur en Chine (même problème avec les SaaS américains au passage). Pour l'open source, ça me dérange moins, les données sont déjà publiques.

L'erreur de conception découverte trop tard

Pendant une pause, je me suis dit "Mais il est bête ce modèle ? C'est comme s'il avait perdu la mémoire". Des commentaires sur LinkedIn me conseillaient de tester Qwen3.6:35B en q2_0. Des tests le placent juste en dessous de Minimax M2.7 en agentic AI, et davs certains cas Qwen3.6:27B est même au-dessus.

Quand ma curiosité reprend le dessus sur la flemme, je retourne aux tests locaux… pour passer sur llama.cpp.

Premier point, je n'ai pas réussi à compiler llama.cpp avec ROCm, j'avais les libs installées mais pas les sdk... qui refusaient de s'installer. Donc je teste la compilation avec Vulkan.

J'essaye le modèle Qwen3.6 27B en q2, il se charge en mémoire mais il est trop long à répondre… donc tant pis, je me rabats sur le Qwen3.6:35B-A3B qui est un mixture of experts, donc ça divise la quantité de calculs par 6 par rapport à un modèle classique :

build/bin/llama-server -fa 1 -c 65535 --port 13434 --host 0.0.0.0 -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-IQ2_XXS

Petite explication :

• -fa 1 : active l'attention flash, il faut un moteur spécial pour ça, qui a priori n'existe que pour Nvidia (initule pour moi mais c'est joli);
• -c 65535 : notre contexte de 64K, je n'avais pas assez de ram pour mettre plus
• --port 13434 : alors la doc préconise le port 8080... qu'on utilise tout le temps pour développer, Ollama utilise le 11434, Docker Model Runner le 12434... donc llama.cpp utilisera le 13434, normal non ?
• --host 0.0.0.0 : sur mon infra, Hermes est sur une autre machine que ma station de travail, donc la station de travail écoute sur le tout réseau local.
• -hf unsloth/Qwen3.6-35B-A3B-GGUF:UD-IQ2_XXS : Unsloth propose sur HuggingFace une pléthore de quantifications de modèles open source.

N.B.: En rédigeant l'article je me rends compte que j'ai oublié d'activer la quantification du KV Cache avec -ctk q8_0.

Et là ça marche bien. Les outils sont appelés. Il peut chercher dans sa mémoire tout seul.

J'ai l'impression que Qwen3.6 est plus concis et plus efficace que Minimax M2.7, c'est un peu déroutant. Je n'ai pas vu de problèmes de traduction comme sur Minimax.

Par contre, la première requête est très longue. Le prompt processing sur cette machine est très long (500 tok/s, donc avec un contexte de 50000 tokens... on attend plus d'une minute). Il faut que je trouve comment optimiser ça, c'est dans ma todo-list. A priori la bande passante mémoire de la RX 9060 XT (288 Go/s) devient le goulot d'étranglement pour cette étape. La génération est plutôt rapide avec environ 50 tokens/s.

Local ou SaaS ? Le bilan

Conclusion

Faire du bon vibecoding en local avec 16 Go de VRAM, c'est possible. Il faut cependant renoncer au confort d'Ollama, et se lancer dans la compilation et la configuration de llama.cpp donc retrousser les manches pour plonger dans les arcanes des LLM.

En tout cas maintenant je peux vibe coder de n'importe où en lançant ma station de travail éteinte grâce à Minimax, et je peux utiliser Qwen3.6 en local pour traiter des données sensibles.