Rock Robot

Hermes en local avec 16 Go de RAM : 🤯

2026-06-30T00:00:00+02:00

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

	Local (llama.cpp)	SaaS (MiniMax)
Forces	Confidentialité des données stratégiques et personnelles ; zéro abonnement récurrent ; montée en compétence profonde sur le fonctionnement des LLM	Accessible partout (tant qu'on a de la 5G) ; contexte immense par défaut ; zéro configuration ; quotas généreux (217 €/an peu limitant)
Faiblesses	Bruit à maîtriser ; achat du matériel ; veille technique sur le moteur d'inférence	Coût annuel ; dépendance au réseau
Opportunités	Maîtrise qui permet de limiter les coûts futurs en cloud
Menaces	Problèmes de licence ; erreur d'achat matériel ; perte de temps importante ; panne hardware ; modèles veroles (déjà rencontré : spam de requêtes SQL et de macros Excel)	fuite de données

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.

OpenClaw en local avec Ollama - Rock Robot

2026-05-21T00:00:00+02:00

J’ai dû rédiger un CV pour un client potentiel ; c'était l’occasion de tester OpenClaw en local.

Je voulais profiter de l’occasion pour tester des modèles plus puissants sur ma carte graphique Nvidia RTX 2070, avec 8 Go de RAM.

À l'époque (oui oui, l'année dernière), elle faisait tourner vaillamment Llama 3.1 et Qwen3 en 8B. Quand on a besoin de faire un résumé, de rédiger un document ou de faire tourner un chat, il suffit d'un petit contexte de 4K qui tient facilement dans 8 Go de RAM. Mais ça, c'était avant le vibe coding

Est-ce qu'on peut faire tourner les agents OpenCode ou OpenClaw avec un LLM en local ?

Configuration de base d'Ollama avec Qwen3.5:2b

Je ne vous fais pas l'affront de faire un tuto sur l'installation d'Openclaw et d'Ollama. Il y en a plein sur Internet, donc je pars du principe que vous y êtes arrivés sans souci. Par contre je vais vous montrer ce que j'ai dû corriger.

Contrairement à OpenCode, OpenClaw sait régler la taille du contexte des modèles sur Ollama. D'ailleurs, il se moque pas mal de la taille de contexte par défaut d'Ollama (ce que je vous ai montré dans l'article précédent). On le voit à la taille du contexte affichée par ollama ps une fois qu’on lui pose une question : c’est la taille maximale du modèle.

Si vous voulez éviter de consommer toute la RAM de votre carte graphique, éditez votre fichier ~/.openclaw/openclaw.json et modifiez la valeur de contextWindow de votre modèle:

{
  "models": {
    "providers": {
      "ollama": {
        "models": [
          {
            "name": "qwen3.5:2b",
            "contextWindow": 65536,
          }
        ]
      }
    }
  }
}

Ici j'ai demandé un contexte de 65536 tokens.

Donc pour commencer, j'ai utilisé Qwen3.5 en 2b avec 64K tokens. Ça tenait en mémoire sans trop de problèmes, c'était rapide.

Honnêtement, ce modèle n'est pas bon. Il fait des fautes de français et n'est pas très pertinent mais surtout il part facilement en cacahuète :

Il boucle sur lui-même régulièrement ;
Quand il lance des commandes qui échouent, il n'arrive pas vraiment à corriger les problèmes.

J'ai donc essayé d'utiliser un meilleur modèle.

Tests avec Qwen3.5:4b

À l’époque, j’utilisais un modèle Qwen3 en 8b sans trop de problèmes, mais avec de grands contextes, ce n’est pas la peine d’y penser. Mais est-ce que Qwen 3.5 est vraiment meilleur que Qwen 3 ? Et est-ce que les améliorations permettent à un modèle 4B d’être aussi performant que le modèle 8B de la génération précédente ?

Cet article présente un graphique indiquant les performances en fonction des cas d'utilisation et des poids/génération des modèles :

Il ne parle pas de Qwen3:8b mais on peut voir deux choses sur le graphique :

Pour un agent, le modèle 4B est 30% plus performant que le 2B ;
Ce n'est pas trop la peine d'utiliser un grand contexte avec le 2B.

Donc j'ai essayé le modèle 4B en passant le contexte à 32K tokens.

Ça tient en VRAM, c'est rapide, mais dès qu'il lance une commande qui plante et affiche un log d’erreur... le contexte déborde. Si j'ai de la chance, la compression du contexte se lance automatiquement, sinon on est bon pour recommencer la session. Ça devient rapidement inutilisable.

Et là je me souviens que quelqu'un m'a parlé de TurboQuant 4 de Google qui compresse le KV Cache, donc normalement on pourrait utiliser un contexte de 64K dans 8Go de RAM

Compression du KV Cache

Le KV Cache est une technologie qui réduit considérablement (de 5 à 10 fois) le temps de traitement, mais cela se fait souvent au détriment de la consommation de mémoire.

En fouinant dans les logs d'Ollama, on voit la décomposition de l'utilisation de la RAM par Ollama :

msg="offloading 32 repeating layers to GPU"
msg="offloading output layer to CPU"
msg="offloaded 32/33 layers to GPU"
msg="model weights" device=CUDA0 size="2.0 GiB"
msg=msg="model weights" device=CPU size="1.6 GiB"
msg="kv cache" device=CUDA0 size="1.8 GiB"
msg="compute graph" device=CUDA0 size="1.0 GiB"
msg="compute graph" device=CPU size="126.6 MiB"
msg="total memory" size="6.6 GiB"

Ollama décompose ses besoins en RAM :

Les poids (model weights) : le modèle en lui-même ;
Le fameux KV Cache ;
Le graphe de calculs (compute graph) : stocke les résultats intermédiaires et permet de faire des optimisations de calculs.

Donc le KV Cache consomme pas mal de RAM et ça empire quand on augmente la taille du contexte.

Donc j'ai cherché si Ollama (et surtout llama.cpp, qui fait l'inférence) pouvait utiliser TurboQuant 4 de Google. Il y a un projet "Atomic llama.cpp", un fork de llama.cpp qui implémente l'algorithme, mais ce n’est pas utilisé par Ollama.

Par contre, dans cette discussion sur le projet GitHub de llama.cpp, certains intervenants trouvent que ce n'est pas si intéressant par rapport aux algorithmes de compression déjà implémentés dans llama.cpp. Donc, il existe déjà la possibilité de quantifier le KV Cache en 8 bits (q8_0) pratiquement sans perdre en pertinence. On peut aussi quantifier en 4 bits (q4_0), mais les pertes sont plus marquées ; en effet, les petits modèles seraient plus impactés que les grands.

Ok donc on peut déjà utiliser la quantification du KV Cache (même si elle ne sera pas aussi efficace que TurboQuant) mais qu’est-ce que ça représente réellement ? Et bien, pour vous faire une idée, il y a pas mal de simulateurs de consommation de VRAM sur Internet. Personnellement, je vous conseille celui-ci qui semble assez clair et complet.

En haut, vous pouvez mettre l’URL du modèle sur Hugging Face, mais vous pouvez, à la place, renseigner la taille du modèle, la quantification du modèle et la taille du contexte qui vous intéresse.

Dans les graphiques du dessous, vous avez une ligne par quantification du KV Cache et sur cette ligne :

À droite, la RAM consommée par le modèle, le KV Cache et le total ;
En couleur foncée : la consommation des poids du modèle (vous voyez que le foncé est identique sur les 3 lignes) ;
En couleur claire : la consommation du KV Cache quantifié (vous voyez que les barres diminuent en fonction de la quantification).

J'utilise le q8_0, déjà que les petits modèles ne sont pas super pertinents, on va éviter la quantification q4_0. Et avec le q8_0 j'ai déjà pu doubler la quantité de contexte.

Mais comment on fait dans Ollama ? C'est indiqué dans la doc. Il suffit d'utiliser la variable d'environnement suivante quand on lance ollama server :

OLLAMA_KV_CACHE_TYPE=q8_0

Finalement, j'ai rapidement atteint la limite de 8 Go de RAM pour utiliser les 64K de tokens : j’ai quand même dû éteindre Firefox.

OpenClaw et Reaction Resume

Une fois que mon OpenClaw avait suffisamment de contexte, j’ai créé ma base de connaissances. Ensuite je voulais qu’OpenClaw fasse la mise en page de mon CV tout seul.

Pour ça, j’ai trouvé un programme open source : Reactive Resume, également accessible en ligne sur le site https://rxresu.me. C'est un site qui permet de créer son CV section par section, d'utiliser des templates de CV et de faire un peu de mise en page. Il a un serveur MCP intégré et aussi un skill disponible pour les agents.

Alors je ne sais pas si OpenClaw a du mal avec le MCP, mais il n'arrivait pas à utiliser le serveur MCP quand je lui indiquais dans son fichier de configuration, ni quand j'ai installé le skill mcporter.

J'ai lu quelque part que les agents préfèrent les skills aux serveurs MCP, donc j'ai installé le skill resume-builder (écrit par l'équipe de Reactive Resume et, oui, je l'ai lu avant de l'installer). L'approche du skill est intéressante ; elle recommande à OpenClaw de créer un JSON selon un format disponible sur Internet et de faire une requête HTTP pour l'envoyer à Reactive Resume. Cependant, de mémoire, les petits modèles ont du mal à générer un JSON qui respecte scrupuleusement un standard. Je suis un peu sceptique.

Mais à partir de là, OpenClaw n'arrivait même plus à lire un fichier ; j’ai peut-être fait une erreur dans la configuration. Le LLM n'arrivait plus à appeler ses tools, pourtant, ils apparaissent dans l'interface textuelle en lançant /tools. Donc je ne suis pas sûr que l'interface soit fiable. Ça démontre un manque de rigueur dans la conception de l'outil.

J’ai beaucoup appris sur OpenClaw, et je pense qu’un simple utilisateur ne pourrait pas s’en sortir. Et je suis super emballé par le principe de déléguer des tâches à un agent. Mais pour un logiciel qui a pas mal fait la hype ces derniers mois, je trouve que ce soft marche très mal. La doc est très technique, mais elle manque cruellement d’explications de base sur le fonctionnement global.

Pour être honnête, j'ai craqué et fait le CV à la main sur l'appli.

Conclusion

Avec du temps et de la patience, on peut utiliser une carte graphique avec seulement 8 Go de RAM avec des agents IA, pour peu qu’on accepte de faire des compromis.

En l’état, je ne peux pas recommander OpenClaw : soit il a des permissions trop larges et pourrait poser problème, soit ses protections sont si strictes qu’il devient inutilisable. La doc est obscure. Peut-être que j'étais dans un cas particulier, mais je n'ai pas l'impression d'être le seul à galérer.

L'expérience avec OpenCode était bien plus agréable.

J’ai commandé une carte AMD 9060 XT avec 16 Go de RAM. Et oui, j’ai envie de tester ce que fait la concurrence même si c’est pas très hype. Et Ollama a intégré un nouvel agent, Hermes. Je vous en dis plus la semaine prochaine.

Vibe coding Open Source en local sur un ordinateur portable - Rock Robot

2026-05-07T00:00:00+02:00

Vibe coding Open Source en local sur un ordinateur portable.

Vu que mon expérience de la semaine dernière a épuisé mon quota de tokens sur Mammouth.ai, je voulais voir si je pouvais vibe coder en local sur de tous petits modèles avec un ordinateur portable doté d'une carte graphique AMD intégrée au CPU (un 7430U pour les curieux). J'ai eu plusieurs soucis mais aussi de bonnes surprises.

D'abord pour remplacer CUDA, j'installe l'équivalent de chez AMD : ROCm, qui a en plus le bon goût d'être Open Source. Ensuite j'installe Ollama, je cherche un petit modèle et je découvre Granite 4.1 avec 3 milliards de paramètres.

Je n'ai jamais entendu parler de ce modèle d'IBM. Il peut appeler des tools donc on peut s'en servir avec un agent. Par contre il ne raisonne pas, ça risque de donner des problèmes de pertinence, on verra ce que ça donne.

Je lance Open Code avec ollama code --model granite4.1:3b. Et là je vois que le contexte est limité à 4k, c'est bien trop peu pour un agent : 128K c'est confortable mais ça fera trop de calculs pour mon petit portable, je vais essayer 32K qui est le minimum recommandé.

Les logs de Ollama confirment que le modèle utilise 4096 tokens de contexte :

level=INFO source=routes.go:1848 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096

Il y a 3 façons d'augmenter la taille du contexte dans ollama :

l'application cliente peut le forcer lors de la requête en passant l'option num_ctx,
on peut créer son propre modèle (en définissant un Modelfile, un peu comme Docker et ses Dockerfile). qui reprend le modèle de base et surcharge num_ctx,
on peut rajouter la variable d'environnement OLLAMA_CONTEXT_LENGTH=32768 quand on lance ollama serve,

J'aurais préféré le configurer depuis Open Code mais il ne gère pas ce paramètre donc je me rabats sur la dernière solution.

Je relance Open Code et là tout est très lent. Puisque le contexte consommé dès le départ est d'environ 10k, je diminue la taille du contexte à 16384 tokens pour alléger un peu la RAM et les calculs.

C'est mieux mais j'ai l'impression que c'est le CPU qui fait tout le calcul. Je vois ces lignes dans les logs :

msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/local/lib/ollama /usr/local/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:0]" error="runner crashed"
msg="inference compute" id=cpu library=cpu compute="" name=cpu description=cpu libdirs=ollama driver="" pci_id="" type="" total="30.7 GiB" available="21.0 GiB"

Le GPU n'est pas trouvé. Ollama le confirme :

$ ollama ps
NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
granite4.1:3b    6fd349357287    3.4 GB    100% CPU     16384      4 minutes from now

De ce que j'ai vu sur Internet ROCm ne supporte que les cartes graphiques récentes, c'est à dire séparées du CPU. Par contre llama.cpp, la bibliothèque utilisée par Ollama pour l'inférence, gère aussi l'accélération en utilisant Vulkan, mais c'est encore expérimental donc pour l'activer, il suffit d'ajouter la variable d'environnement OLLAMA_VULKAN=1

Un redémarrage du serveur plus tard, le modèle se charge bien dans le GPU.

$ ollama ps
NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
granite4.1:3b    6fd349357287    4.6 GB    100% GPU     16384      4 minutes from now

Là je vois bien dans htop que le CPU n'est pas utilisé. Par contre nvtop ne marche pas aussi bien que dans l'environnement Nvidia : il déclare que la RAM allouée est de 512Mo et il détecte une utilisation de 100% du GPU mais pas le process ollama. En utilisant le paquet snap de nvtop à la place du paquet Debian 13, la RAM est correctement affichée, mais toujours pas d'affichage du process ollama.

Finalement si on discute avec le modèle en utilisant ollama run granite4.1:3b, l'utilisation est fluide, donc on peut utiliser un petit modèle de langue en local pour chatter. Par contre pour l'utilisation de Open Code, le système est beaucoup trop lent (11 minutes pour lire un fichier de 4Ko, 4 minutes pour une question sur ce même texte) et le modèle est loin d'être pertinent. J'ai testé aussi le modèle Gemma4:e2b de Google, le système est devenu encore plus lent, c'était là aussi inutilisable.

Vibe coding avec Mammouth.ai pour une carte des LLM - Rock Robot

2026-05-01T00:00:00+02:00

Zut je dois faire mon article linkedin mais je suis chez la famille avec juste mon ordinateur portable. Je veux faire une carte qui présente différents modèles sur une carte.

Le problème c'est que je n'ai pas de donnée... et que je ne sais pas emcore comment je vais intégrer ça dans une carte.

Pour génerer des données, j'ai testé la fonction Recherche de Mistral.ai, on peut en faire jusau'à 5 par mois gratuitement, et, des fois, ça marche pas mal : c'est un petit agent qui peut faire plein de recherches sur Internet et vous proposer une synthèse. Et c'est vraiment un agent : il lance autant de recherches qu'il a besoin. Pas comme la fonction "recherche sur le web" qui fait une pauvre recherche.

Donc notre petit Mistral nation arrive à me faire un Geojson pas trop mal, il arrive même à me placer les modèles sur la carte... mais le modèle a une cutoff en 2024 et du coup exit GLM, Kimi qui font le buzz cette année.

Bon, finalement une petite requête csur chatgpt me donne un Geojson de depart un peu plus exploitable.

Maitenant il reste à faire le viewer de carte. Je veux l'intégrer sur mon site mais je ne sais pas trop par quel bout le prendre. C'est pas très grave, c'est l'occasion de tester les agent de code.

Alors j'ai commencé à regarder Open Code plus Ollama mais là je suis chez la famille sur mon portable... donc pas de vrai carte graphique. Je voulais voir ce qu'on peut utiliser sur une machine un peu standard. Donc on va commencer par un service SaaS

Donc j'ai sortie mamouth.ai et son agent de code https://info.mammouth.ai/fr/docs/mammouth-code/ (c'est un fork d'OpenCode pour simplifier le déployement).

J'ai voulu testé Qwen3.5 30B-A3B (oui le 3.6 est déjà sorti mais il n'est pas diponible sur mammouth.ai aujourd'hui), c'est un relativement gros modèle mais en mixture of expert donc il fait 10x de calcul pour un résultat similaire à du 30B. J'aurais pu utiliser un modèle Claude de chez Anthropic, mais le but c'est de tester des solutions Open Source avant tout.

Le coût : avec un abonnement starter mammouth inclus $2 d'appels à des API. On peut en acheter plus hein. Mais là le but c'est de tester le vibe coding.

Donc au bout de mon quota de $2, j'ai un service qui marche mal, le gros de la structure est faite certes mais la moitié de ce que j'ai demandé ne marche pas et je n'ai plus de crédit parce que Qwen relançait en boucle la même opération. Ce n'est pas très grave parce que Mammouth a détecté un problème en causant un rate limite.

Mais quand même le petit agent a quand même bien dégrossi le travail, j'ai appris plein de trucs sur Pelican, le moteur de site statique que j'utilise. L'interface ne marche pas mais elle est propre... bien plus propre que ce que j'aurais fait dans un premier jet.

Alors mon impression : c'est pas mal pour dégrossir mais il faut être patient car c'est un peu lent et que ça va vite couter cher.

Comment choisir son modèle de langage Open Source - Rock Robot

2026-04-27T00:00:00+02:00

Capacités techniques (on peut trouver ces informations facilement):

Taille du modèle : Le nombre de paramètres du modèle par exemple: 30B, 8B ou B signifie millards (Billion en anglais). Les modèles plus grands ont généralement une meilleure compréhension du langage et peuvent générer des réponses plus cohérentes et contextuellement appropriées. Cependant, ils nécessitent plus de mémoire (RAM) pour fonctionner. Le modèle de 30B sont bon mais il faut du matériel haut de gamme, les 8B sont un bon compromis pour les tâches pas trop exigentes.
Mixture of experts : Les modèles mixture of expert (MOE) prennent beaucoup de RAM mais sont plus rapides car seul une partie des paramètres est utilisé à chaque passe. C'est souvent un bon compromis.
Formats de données acceptés : on parle de multi modale, certains modèles acceptent des images, très rarement on peut leur donner de l'audio ou des videos.
Quantification : un même modèle peut être livré avec des tailles paramètres différents, par exemple l'encodage "q4" permet de diminuer la RAM nécéssaire par 4 mais en perdant un peu de pertinence.
Reflexion/réponse flash : c'est la capacité à réfléchir et structurer sa réponse avant de répondre, ça améliore grandement la pertinence de la réponse au détriment de la vitesse.
Utilisation d'outils : la plupart des modèles récents sont capable d'appeler des fonctions, par exemple pour faire des recherches Internet, connaitre la date, envoyer des mails. C'est une fonctionnalité indispensable pour les agents IA
Taille de contexte : C'est la quantité de données (souvent texte) que le modèle peut retenir (exprimé en token). Pour des agents, ils faut de modèles capables de retenir un maximum d'informations, 32K est un minimum. Je vous ferai un article dédié.

Capacités opérationneles (là il faut un peu de recherche):

Performance : La capacité du modèle à accomplir des tâches spécifiques comme la génération de texte, la traduction, la réponse à des questions, etc. Les métriques de performance peuvent inclure la précision, la fluidité et la cohérence des réponses.
Données d'entraînement : La qualité et la diversité des données utilisées pour entraîner le modèle. Un modèle entraîné sur un large éventail de données sera généralement plus polyvalent.
Date de cutoff : Date à laquelle on a arrété de moisonner les données d'entrainement, le modèle ne connaitra pas d'information passé cette date.
Licence : Les conditions d'utilisation et de distribution du modèle. Certaines licences open source permettent une utilisation libre comme Apache, tandis que d'autres peuvent imposer des restrictions par exemple sur le nombre de clients de l'entreprise (Llama).
Facilité d'utilisation : La simplicité avec laquelle le modèle peut être intégré et utilisé dans des applications. Cela inclut la disponibilité sur des moteurs d'inférence (comme ollama).
Coût et ressources nécessaires : Les ressources informatiques nécessaires pour exécuter le modèle, y compris la mémoire, la puissance de calcul et le stockage. Les modèles plus grands peuvent nécessiter des ressources plus importantes.
Spécialisation : Certains modèles sont spécialisés dans des domaines spécifiques (par exemple, la médecine, le droit) et peuvent être plus performants dans ces domaines que des modèles généralistes. On peut avoir des informations en s'interessant aux benchs existant. Je ferais prochainement un article sur les bench pertinent selon votre metier, suivez-moi pour ne pas le rater
Biais : Les modèles peuvent reproduire des stéréotypes sociaux et raciaux.
Filtres et modération : certains modèles comme Grok sont connus pour ne pas avoir de filtres, on peut leur demander n'importe quoi.

Astuces

2026-04-25T17:50:00+02:00

Quelques lignes de commandes à garder sous le coude.

Générer une clé hexa de 16 caractères

openssl rand -hex 16

Envoyer un flux audio sur un autre autre ordinateur en réseau

Sous Linux on peut facilement envoyer le flux audio d'un ordinateur (le client) sur un autre ordinateur qui dispose d'un meilleur système de son.

Par exemple chez moi, mon ampli est de l'autre côté de la pièce, j'ai branché dessus un Raspberry Pi 3 qui pilote aussi l'imprimante 3D.

Il suffit de créer un tunnel audio entre les deux ordinateur avec Pulseaudio ou Pipewire.

Sous Debian 13, même si c'est pipewire qui gère le son, il faut installer le paquet pulseaudio-utils sur les deux ordinateurs :

sudo apt install pulseaudio-utils

Sur le serveur, celui est branché à l'ampli, il faut faire :

pactl load-module module-native-protocol-tcp port=4656 listen=<IP_SERVER>

Où <IP_SERVER> est l'IP du serveur (pas du client).

Sur le client (là ou tourne le programme qui emet le flux audio) :

pactl load-module module-tunnel-sink server=tcp:<IP_SERVER>:4656

Encore une fois où <IP_SERVER> est l'IP du serveur (pas du client).