Comment lancer un modèle de codage local avec llama.cpp ?

Résumer ce contenu avec :

Perplexity

ChatGPT

Claude

Grok

Mistral

Lancer un agent de codage local avec llama.cpp, c’est surtout assembler trois pièces propres : un modèle GGUF adapté, un serveur local stable, puis Pi branché sur l’API. Je détaille ici les réglages utiles, les pièges mémoire et le setup qui tient vraiment sur une machine grand public.

Pourquoi utiliser Mythos en local ?

J’utilise Mythos en local quand je veux garder un agent de codage réactif, privé et exploitable sans dépendre d’une API externe. C’est vraiment ça le point de départ. Je veux pouvoir lancer une tâche de dev, tester une idée, corriger un script ou générer un petit outil sans envoyer mon code ailleurs, sans attendre une réponse distante, sans surveiller chaque appel API.

Qwythos-9B-Claude-Mythos-5-1M est un modèle de 9 milliards de paramètres, dérivé de Qwen3.5, avec une orientation assez nette vers le raisonnement et le codage. Quand je dis “paramètres”, je parle des poids internes du modèle, ce qui lui permet de reconnaître des patterns, comprendre une demande, produire du code ou raisonner sur un bug. 9 milliards, ce n’est pas minuscule, mais ça reste dans une zone intéressante pour du matériel grand public, surtout avec llama.cpp et un format quantifié.

Le format est intéressant parce qu’il se place dans un bon compromis. Il est assez petit pour tourner sur une bonne machine perso, parfois même sur un laptop costaud, mais assez capable pour rendre service sur des tâches concrètes :

Générer une fonction Python ou JavaScript propre.
Corriger un script qui plante avec une erreur obscure.
Créer un petit outil CLI en Python pour automatiser une tâche.
Produire un mini jeu navigateur en HTML, CSS et JavaScript.
Relire du code interne sans l’exposer à un service cloud.

Je ne le vois pas comme un remplaçant des plus gros modèles cloud. Ce n’est pas le sujet. L’idée, c’est d’avoir un assistant local utile, rapide, maîtrisable, qu’on peut brancher dans ses workflows sans se poser mille questions à chaque exécution.

Chez des clients, je vois souvent la même tension. Ils veulent de la performance, mais ils ont aussi des contraintes de confidentialité, de budget et parfois de conformité. Le local devient très intéressant dès qu’on commence à industrialiser des tests, des générations de scripts, des revues internes ou des workflows répétitifs. À ce moment-là, chaque appel distant compte, en coût comme en exposition.

Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?

Le vrai sujet, ce n’est donc pas seulement Mythos. C’est aussi la façon de le servir proprement. Et c’est là que llama.cpp devient central, parce qu’il permet de lancer le modèle localement avec une configuration simple, stable et exploitable au quotidien.

Comment préparer llama.cpp et le cache ?

Je prépare d’abord llama.cpp, puis je fixe le cache Hugging Face sur un disque avec assez de place, sinon le setup devient vite pénible. Llama.cpp sert à exécuter des modèles au format GGUF en local. GGUF, c’est le format optimisé qu’on utilise souvent pour faire tourner des LLM sans dépendre d’une API distante. Et le gros avantage, c’est qu’on peut aussi exposer le modèle via un serveur compatible avec l’API OpenAI. Derrière, l’intégration avec Continue, Open WebUI, n8n ou vos propres scripts devient beaucoup plus simple.

Pour installer llama.cpp, je pars sur l’installateur officiel.

Commande : curl -fsSL https://llama.app/install.sh | sh

Si la commande n’est pas trouvée après installation, j’ajoute le dossier local au PATH. Le PATH, c’est simplement la liste des dossiers dans lesquels votre terminal cherche les commandes exécutables.

Commande : export PATH= »$HOME/.local/bin:$PATH »

Je vérifie ensuite que tout répond correctement.

Commande : llama help

L’objectif est simple : avoir la commande llama accessible depuis le terminal, sans bricoler à chaque session. Si ce n’est pas le cas, je corrige le PATH avant d’aller plus loin. C’est le genre de détail qui fait perdre 30 minutes plus tard pour rien.

Ensuite, je prépare le cache Hugging Face avec HF_HOME. Hugging Face utilise cette variable d’environnement pour définir l’emplacement racine du cache local. Autrement dit, c’est là que les modèles téléchargés vont être stockés.

Commande : mkdir -p /workspace/huggingface

Commande : export HF_HOME=/workspace/huggingface

Je rends ce réglage persistant dans le terminal, sinon il disparaît à la prochaine session.

Commande : echo ‘export HF_HOME=/workspace/huggingface’ >> ~/.bashrc

Sur une machine avec un petit disque système, c’est vraiment important. Un modèle de codage peut vite peser plusieurs dizaines de Go, surtout si vous testez plusieurs variantes. J’ai déjà vu des setups casser juste parce que le cache partait dans le home par défaut et saturait le disque au premier téléchargement.

Une fois llama.cpp installé et le cache placé au bon endroit, on peut lancer le modèle proprement avec les bons flags GPU, le bon contexte, et éventuellement la spéculation pour accélérer la génération.

Comment lancer Qwythos avec llama.cpp ?

Je lance Qwythos avec llama serve, en chargeant le fichier GGUF MTP Q6_K et en activant le GPU, le contexte long, flash attention et la spéculation MTP quand la machine le permet. La commande de base ressemble à ça :

llama serve \
  --hf-repo empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF \
  --hf-file MTP-Q6_K.gguf \
  --n-gpu-layers all \
  --ctx-size 100000 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 6 \
  --jinja \
  --perf \
  --port 8910

Le point important, c’est que –n-gpu-layers all demande à llama.cpp de charger autant de couches que possible sur le GPU. Si votre carte graphique a assez de VRAM, ça accélère beaucoup. Si elle n’en a pas assez, il faudra réduire ou laisser llama.cpp arbitrer.

–ctx-size 100000 donne une grande fenêtre de contexte. C’est utile pour du code, parce qu’on peut donner plusieurs fichiers, des logs, une spec, un diff Git, bref de la vraie matière. Mais ça coûte cher en mémoire, surtout côté KV cache. Le KV cache, c’est la mémoire utilisée par le modèle pour garder l’historique de la conversation pendant la génération.

–flash-attn on active flash attention quand le matériel le supporte. En gros, c’est une façon plus efficace de calculer l’attention, souvent plus rapide et moins gourmande. –cache-type-k q8_0 et –cache-type-v q8_0 compressent le KV cache en 8 bits, ce qui réduit l’empreinte mémoire sans trop dégrader l’usage en pratique.

–spec-type draft-mtp et –spec-draft-n-max 6 activent la génération spéculative MTP. L’idée est simple : le modèle propose plusieurs tokens candidats à l’avance, puis valide ce qui tient. Quand ça marche bien, on gagne en vitesse. –jinja applique correctement le template de chat du modèle, et –perf affiche les métriques utiles, notamment les tokens par seconde.

Une fois lancé, l’interface locale est disponible sur http://localhost:8910. L’endpoint compatible OpenAI est ici : http://localhost:8910/v1. Sur une RTX 4070 Ti Super avec 16GB de VRAM, j’ai observé environ 81,74 tokens/sec. Ce n’est pas un chiffre universel. Ça dépend du GPU, du contexte réellement utilisé, de la quantification et des réglages mémoire. Mais ça donne un repère honnête.

Réglage	Rôle	Impact mémoire	Quand le modifier
–n-gpu-layers all	Charge le modèle sur le GPU	Élevé en VRAM	Si vous avez des erreurs mémoire GPU
–ctx-size 100000	Augmente la fenêtre de contexte	Très élevé	Si vous travaillez sur moins de fichiers
–cache-type-k/v q8_0	Compresse le KV cache	Réduit	Si le contexte long consomme trop
–spec-draft-n-max 6	Règle la spéculation MTP	Variable	Si la vitesse ou la stabilité varie

Comment brancher Pi sur le modèle local ?

Je branche Pi sur le serveur llama.cpp en lui donnant l’URL de l’API locale, puis je sélectionne l’alias du modèle local dans Pi. Ici, Pi sert d’interface agentique de codage. Ça veut dire qu’il ne se contente pas de répondre dans un chat. Il peut piloter un projet, lire les fichiers, proposer des modifications, appliquer des changements, relancer une tâche, et utiliser votre modèle local comme moteur.

J’installe d’abord Pi avec la commande officielle :

curl -fsSL https://pi.dev/install.sh | sh

Ensuite, j’ajoute l’intégration llama.cpp. C’est elle qui permet à Pi de parler à un serveur compatible OpenAI local, exposé par llama.cpp :

pi install git:github.com/huggingface/pi-llama

Le petit piège classique, je l’ai vu plusieurs fois chez des clients, c’est le port. Le plugin cherche par défaut un serveur llama.cpp sur le port 8080. Dans ce setup, mon serveur tourne sur le port 8910. Je dois donc exporter l’URL exacte avant de lancer Pi :

export LLAMA_BASE_URL=http://127.0.0.1:8910/v1

Ensuite, le test logique est simple. Je crée un projet vide, je lance Pi, je sélectionne l’alias local qwythos-9b-mtp, puis je lui donne une petite tâche de codage. Pas besoin de commencer avec une refonte énorme. Je veux juste vérifier que la chaîne complète fonctionne.

Deux bons tests pratiques :

Demander à Pi de construire un petit jeu navigateur en HTML, CSS et JavaScript, par exemple un mini jeu de clic ou un snake très simple.
Demander à Pi de générer un outil CLI Python, par exemple un script qui renomme des fichiers ou analyse un dossier et sort un résumé.

Ces tests ne servent pas à sortir des chiffres magiques. Ils servent à voir si le modèle suit les consignes, structure correctement les fichiers, comprend les erreurs, et arrive à corriger ce qu’il vient de casser. C’est souvent là qu’on voit tout de suite si le setup est utilisable.

Le premier lancement est rarement parfait. Dans la vraie vie, le souci vient souvent d’un port mal configuré, d’une variable d’environnement oubliée, ou d’un modèle qui n’a pas fini de se charger. Je vérifie ça avant d’accuser le modèle.

Comment optimiser mémoire et vitesse ?

J’optimise d’abord la mémoire, puis seulement la vitesse, parce qu’un modèle rapide qui plante au moindre prompt long ne sert pas à grand-chose. Avec llama.cpp, je regarde surtout trois leviers : je réduis –ctx-size, je choisis une quantification plus légère, et j’ajuste le cache KV.

Le cache KV, c’est la mémoire utilisée par le modèle pour garder le contexte déjà lu. Plus votre contexte est long, plus ce cache grossit. C’est souvent là que la VRAM part très vite, surtout quand on pousse le contexte pour bosser sur du code.

Sur une carte avec 16GB de VRAM, comme une RTX 4070 Ti Super, Q6_K MTP est un très bon compromis qualité/performance. J’ai souvent vu ce réglage tenir proprement sur des workflows de dev, avec assez de qualité pour comprendre un projet et générer du code correct.

Sur un GPU 8GB, je préfère passer en Q4_K_M plutôt que de forcer un setup instable. Oui, Q4_K_M peut perdre un peu en qualité par rapport à Q6_K. Mais il consomme moins de mémoire, et dans la vraie vie, un modèle un peu moins fin mais stable vaut mieux qu’un modèle qui explose dès qu’on colle trois fichiers.

–ctx-size 100000 est confortable pour du code. On peut donner beaucoup de contexte, plusieurs fichiers, des erreurs, des extraits de docs. Mais c’est coûteux. Si la VRAM ou la RAM montent trop haut, je baisse d’abord le contexte. C’est souvent le réglage qui donne le plus gros gain immédiat.

J’utilise aussi ces options pour contenir l’empreinte du cache KV :

--cache-type-k q8_0 --cache-type-v q8_0

Cas	Réglage recommandé	Compromis à accepter
Machine 16GB VRAM	Q6_K MTP avec un contexte élevé si besoin	Bonne qualité, mais la mémoire peut monter vite avec un très long contexte
Machine 8GB VRAM	Q4_K_M plutôt que Q6_K	Un peu moins de qualité, mais beaucoup plus stable
Problème de mémoire	Réduire –ctx-size en priorité	Moins de contexte disponible dans le prompt
Besoin de contexte long	Garder –ctx-size 100000 si la machine tient	Consommation VRAM et RAM plus élevée
Besoin de vitesse	Alléger la quantification et éviter un contexte inutilement énorme	Réponse plus rapide, mais parfois moins précise

Et maintenant, vous le branchez sur quoi ?

Au fond, ce setup est assez simple : llama.cpp sert le modèle Qwythos Mythos en local, Hugging Face gère le téléchargement proprement, puis Pi vient se connecter à l’API locale pour en faire un agent de codage. Le vrai sujet, c’est le réglage. Q6_K MTP marche bien sur une carte 16GB, Q4_K_M devient plus raisonnable sur 8GB, et le contexte doit rester adapté à votre machine. J’aime bien cette approche parce qu’elle donne un assistant utile, privé et pilotable. Le bénéfice pour vous : coder avec un agent local sans exploser vos coûts ni sortir vos projets de votre environnement.

FAQ

À quoi sert llama.cpp dans ce setup ?
llama.cpp sert à exécuter le modèle localement au format GGUF et à l’exposer via un serveur local. Dans ce cas, il fournit aussi un endpoint compatible OpenAI sur http://localhost:8910/v1, ce qui permet à Pi ou à d’autres outils de dialoguer avec le modèle.
Est-ce qu’il faut forcément une grosse carte graphique ?
Une grosse carte aide, surtout avec un contexte long. Le setup Q6_K MTP est donné comme pertinent sur une RTX 4070 Ti Super avec 16GB de VRAM. Sur un GPU 8GB, il vaut mieux viser une quantification plus légère comme Q4_K_M et réduire le contexte si nécessaire.
Pourquoi définir HF_HOME avant de lancer le modèle ?
HF_HOME permet de choisir où Hugging Face stocke ses fichiers en cache. C’est important parce que les modèles peuvent prendre beaucoup de place. Je préfère le placer sur un disque avec de l’espace, par exemple /workspace/huggingface, plutôt que de remplir le disque système sans m’en rendre compte.
Pourquoi Pi ne se connecte pas à llama.cpp ?
Le cas le plus classique vient du port. Le plugin pi-llama cherche par défaut le port 8080, alors que le serveur de ce setup tourne sur 8910. Il faut exporter LLAMA_BASE_URL=http://127.0.0.1:8910/v1 avant de lancer Pi.
Quel réglage modifier en premier si la mémoire explose ?
Je réduis d’abord –ctx-size. Un contexte de 100000 tokens est confortable, mais coûteux. Si ça ne suffit pas, je passe à une quantification plus légère comme Q4_K_M et je garde les caches K/V en q8_0 pour limiter l’empreinte mémoire.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation très concrets. Si vous voulez mettre en place des workflows IA utiles, propres et mesurables dans votre business, contactez-moi.

Franck Scandolera

⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.

Pourquoi utiliser Mythos en local ?

Comment gérer les erreurs de LLM tool calling ?

Comment créer un assistant IA local pour coder ?