Utiliser des LLM locaux pour le codage agentique

• Dans un contexte de forte hausse des prix des modèles cloud phares, récapitulatif des méthodes pour exploiter des modèles locaux afin de poursuivre des tâches de codage sans surcoût
• Les modèles locaux n’atteignent pas les performances des modèles SOTA, mais leur rapport qualité/prix et le renforcement via un harnais déterministe (deterministic harness) permettent d’améliorer la qualité jusqu’à 6 fois
• Pour le codage, Gemma 4 offre un bon équilibre entre tâches générales et génération de code, avec prise en charge de Tools Use, Vision et Reasoning, ce qui le rend adapté à une intégration avec VS Code
• Présentation de toute la procédure de configuration pour lancer un serveur de modèles avec LM Studio et le connecter aux endpoints personnalisés de VS Code Copilot et Pi
• Si le matériel est insuffisant, les modèles gratuits d’OpenRouter peuvent servir d’alternative, tandis que les modèles locaux gardent l’avantage sur l’offline et la confidentialité

---

Contexte de la hausse des prix

• GitHub Copilot est passé d’un modèle à crédits à une facturation à l’usage, et même les modèles auparavant gratuits ne le sont plus
• GitHub étant un revendeur de tokens, la hausse des prix y est encore plus sensible. Les modèles phares sortent alors que les gains de performance ne suivent pas le rythme de l’augmentation des prix
  • Google Flash 3.5 est 3 fois plus cher que Flash 2.5
  • GPT 5.5 est 3 fois plus cher que GPT 5
  • Claude était déjà tellement cher que son prix a au contraire été revu à la baisse

La réalité et les points forts des modèles locaux

• Les modèles locaux n’égalent pas les performances des modèles SOTA comme Claude, GPT ou Gemini, mais il existe plusieurs nuances
  • Rapport performance/prix : avec les modèles cloud, le coût augmente de manière exponentielle par rapport aux gains de performance
  • Harnais déterministe : un meilleur outillage et de meilleures consignes peuvent améliorer jusqu’à 6 fois la qualité d’un modèle plus faible
  • Le piège des benchmarks : il est difficile de réduire un modèle à un chiffre unique, et chaque labo d’IA met en avant les benchmarks qui l’avantagent ; il faut donc évaluer directement sur sa propre charge de travail
  • Effet géopolitique : ce que les labos américains publient gratuitement n’est pas du meilleur niveau. gpt-oss-20b est trop ancien et Anthropic ne publie pas d’open weights. Gemma 4 est le seul modèle vraiment sérieux, et il faut aussi regarder les modèles compétents publiés par des labos chinois comme Qwen, Kimi ou GLM
• Du point de vue du phénomène de « brain rot », un modèle plus faible oblige davantage l’utilisateur à intervenir, ce qui est bénéfique pour la santé cognitive
  • C’est comme faire du vélo : c’est plus lent, mais meilleur pour la santé. Dans le travail intellectuel, « slow is fast »
  • L’objectif n’est pas de maximiser l’automatisation en déléguant la pensée à la machine. Il ne faut pas sacrifier sa pertinence future pour aller plus vite à court terme
  • Les techniques apprises avec des modèles faibles s’appliquent aussi aux grands modèles. Les manier, c’est comme jouer en mode difficile : une fois maîtrisé, on utilise les gros outils bien plus efficacement

Choix du modèle — Gemma 4

• Pour le codage, les modèles chinois dominent le classement Hugging Face, avec notamment Qwen, DeepSeek, Kimi, Llama et Gemma
• Gemma 4 se décline en plusieurs versions
  • E2B : le « E » signifie edge. Avec 2B de paramètres, il tourne sur la plupart des machines, mais le risque d’hallucinations ou de tâches inachevées est élevé
  • E4B : deux fois plus gros qu’E2B. Peu coûteux à télécharger et configurer, il est recommandé pour démarrer
  • 12B : sans décodeur, il comprend nativement les images, ce qui le rend plus rapide pour le frontend et le codage visuel. Il prend aussi nativement l’audio en charge, mais c’est peu important pour les charges de travail de codage
  • 26B A4B : architecture MoE (mixture of experts) où seuls 4B paramètres sur 26B sont activés. Plus intelligent qu’E4B, il convient aux cartes graphiques avec 8 à 12 Go de VRAM (modèle préféré de l’auteur)
  • 31B : le plus grand modèle open weights de Google. Ce n’est pas un MoE, donc il demande beaucoup de VRAM. Sur un APU AMD, sa vitesse de 1 à 2 TPS le rend inutilisable
  • Les variantes QAT (par ex. E4B QAT) consomment moins de mémoire tout en conservant une qualité presque identique. Unsloth travaille à d’autres optimisations

Composants nécessaires pour exécuter un modèle local

• Pour faire tourner un modèle local, il faut un harnais, un modèle, un runtime et un gestionnaire de modèles
  • Harnais (Harness) : VS Code Copilot, Copilot CLI, Pi, etc. C’est le composant déterministe (code traditionnel) qui entoure le modèle, lui-même probabiliste
  • Modèle : fichier de poids d’un réseau de neurones profond. La quantization (Q8, Q4, etc.) est comparable à la résolution d’une image, et les formats se distinguent entre GGUF, MLX, etc.

• Runtime (moteur d’inférence)

  • Llama.cpp : runtime open source le plus populaire, capable de charger GGUF et MLX. Il n’a aucun lien avec les modèles Llama de Meta, et LM Studio l’utilise en interne
  • MLX : runtime Apple, utilisé sur Mac M1, M2, etc.
  • ONNX Runtime : basé sur transformers.js, il permet une exécution dans le navigateur via WebGPU et prend aussi en charge iOS et Android
  • vLLM : projet open source issu d’UC Berkeley, surtout destiné aux serveurs haute performance, avec une configuration plus complexe

• Gestionnaire de modèles

  • Ollama : d’abord un CLI terminal, puis doté d’une GUI légère. C’est un wrapper Go autour de Llama.cpp. Open source
  • LM Studio : gratuit, mais pas open source. Il fournit un SDK (Python/TypeScript) et une API REST, avec contrôle de fonctions propres aux modèles locaux comme le chargement dynamique
  • Jan : alternative gratuite et open source proche de LM Studio, mais moins riche en fonctionnalités
  • La prise en charge d’une API compatible OpenAI est essentielle, car de nombreuses applications IA reposent sur ce standard de fait

Configuration du serveur LM Studio

• Le serveur se lance via un toggle dans le bouton « Developer ». En cas d’exécution sur une autre machine ou dans un conteneur, activer Serve on Local Network ; pour un accès depuis une web app, activer Enable CORS
• LM Studio utilise un chargement JIT (Just In Time), c’est-à-dire qu’il charge le modèle au moment de la requête. Le TTL permet de contrôler la durée de conservation en mémoire
  • Cold start : si le modèle n’est pas déjà chargé, la première requête prend environ 10 à 30 secondes de plus, comme un cold start AWS Lambda. Cela affecte l’indicateur TTFT (Time To First Token)
  • Fenêtre de contexte courte : avec les paramètres par défaut, la fenêtre de contexte peut n’être que de 4k, ce qui impose souvent une augmentation manuelle. La plupart des modèles VS Code Copilot disposent de 200 à 400k

• Longueur de contexte et réglages mémoire

  • Exigences VRAM selon la longueur de contexte : 262144 (max) = 25,74 Go, 4096 (par défaut) = 18,16 Go, 150000 (préférence de l’auteur) = 22,45 Go
  • Pour le codage, le prompt système occupe souvent 20 à 40k tokens, donc il faut charger au minimum 100k tokens
  • Si le contexte est trop grand, la vitesse de génération des tokens baisse. L’idéal est le point où le harnais compresse automatiquement le contexte
  • Il est préférable de faire tourner toutes les couches du modèle sur le GPU et de pousser au maximum le curseur « GPU Offload ». Faire tourner des couches sur le CPU implique des copies de données CPU-GPU, sauf sur Apple Silicon (UMA)

• Astuce de quantization du cache KV

  • Régler K Cache Quantization Type sur Q8_0 et V Cache Quantization Type sur Q4_0
  • Le principe consiste à garder les clés à une résolution plus élevée que les valeurs. Ce réglage fait passer l’exigence mémoire GPU de 28,75 Go par défaut à 22,45 Go
  • Il faut impérativement enregistrer le réglage, sinon le chargement suivant reviendra aux valeurs par défaut
  • VS Code Copilot n’a pas de notion de requête de fenêtre de contexte personnalisée ; LM Studio doit donc mémoriser ce réglage lors des appels REST API
• En dessous de 10 TPS, l’usage pour le codage devient difficilement supportable. On passe plus de temps à attendre le modèle

Connexion d’un endpoint personnalisé à Copilot

• Il faut une version récente de VS Code (1.122.1 au moment de l’écriture). Ajouter le modèle via le sélecteur de modèles → roue dentée → « Add Models » → « Custom Endpoint »
  • Donner un nom (par ex. « Local LM Studio »), saisir la clé API (ou appuyer sur Entrée si aucune n’est définie), puis choisir la forme d’API d’inférence
  • Parmi les 3 types d’API, seule Chat Completions fonctionne correctement
• Dans la configuration JSON, définir manuellement url, maxInputTokens, maxOutputTokens, etc.
  • Régler correctement l’option thinking (prise en charge par Gemma 4)
  • Le tableau supportsReasoningEffort varie selon le modèle ; la version 26B offre un contrôle plus fin qu’E4B
  • Pour 4B : maxInputTokens 64000 / maxOutputTokens 16000 ; pour 26B MoE : 100000 / 50000
• Au premier prompt, Copilot envoie un énorme prompt système et des définitions d’outils, ce qui provoque 2 à 5 minutes de délai lors de la première interaction. Chargement du modèle : 30 secondes, traitement du prompt d’entrée : environ 5 minutes
  • Cela n’arrive qu’une fois par session, car LM Studio applique un cache de prompt. Pi n’a pas ce problème, son prompt système étant plus petit

• Test rapide et environnement

  • Démonstration des performances de Gemma 4 26B A4B en générant un jeu Snake en one-shot, sans AGENTS.md ni SKILL
  • Environnement utilisé : Lenovo ThinkPad L16 Gen 2, AMD Ryzen 7 PRO 250 APU, 64 Go de DDR5 (5 600 MT/s), Aurora Linux. L’auteur estime que 32 Go suffisent aussi

Configuration de Pi

• La connexion au serveur local LM Studio est simple, et le réglage contextWindow correspond mieux à la façon dont LM Studio gère la configuration
• Définir baseUrl sur http://host.containers.internal:1234/v1 et api sur openai-completions
  • Pour 4B : contextWindow 64000 / maxTokens 16000 ; pour 26B MoE : 150000 / 50000, avec le mapping thinkingLevelMap

Récapitulatif des avantages et inconvénients des modèles locaux

• Avantages : fonctionnement hors ligne, meilleure confidentialité, temps de réponse rapide selon le matériel, le workflow, le modèle et les réglages
• Inconvénients
  • Les modèles open weights ne sont pas aussi intelligents que les modèles propriétaires phares, mais un harnais bien conçu avec les bons garde-fous (lint, tests, AGENTS.md) peut nettement améliorer la précision en codage
  • Faire tourner un LLM sur la même machine entraîne un ralentissement dû à la charge matérielle
  • Cold start, traitement initial du prompt (cache miss) et coût initial élevé du matériel
• Une fois à l’aise avec LM Studio, on peut utiliser directement Llama.cpp sans GUI. La plupart des harnais prennent en charge les endpoints personnalisés, ce qui permet de les relier à un LLM local

Alternative avec les modèles gratuits d’OpenRouter

• OpenRouter est un service unifié d’API et de routage qui expose des centaines de modèles via un endpoint et un compte uniques
• Copilot, Zed et Pi prennent tous en charge OpenRouter nativement ; il suffit de générer un token API pour les connecter
  • Pour éviter toute explosion des coûts, créer un garde-fou personnalisé plafonné à 1 $/mois puis n’autoriser que les modèles gratuits
  • Lors de la création d’une nouvelle clé API, il est recommandé de définir le crédit maximum à 0
• Inconvénients : les prompts et les données peuvent être utilisés pour l’entraînement (réglage ZDR disponible), une connexion Internet est nécessaire, et OpenRouter peut cesser de proposer des modèles gratuits
• Avantages : aucun téléchargement ni configuration locale, et aucun ralentissement de l’ordinateur pendant l’usage

• Mise à jour du 2026-06-09

  • Adoption de Deepseek V4 Pro, avec des performances presque au niveau de Claude Opus 4.8, une fenêtre de contexte 5 fois plus grande et un coût environ 17 à 86 fois inférieur
  • Il existait un écart de prix d’environ 3x entre Pi et OpenRouter, car OpenRouter envoyait les requêtes vers un endpoint plus cher (GMICloud)
  • L’auteur a ouvert directement un compte Deepseek pour les tâches complexes. Pour les tâches simples, la compréhension du fonctionnement et les situations où la confidentialité compte, les modèles locaux restent le premier choix

[click]

Au final, la conclusion a été qu’on est passé des modèles locaux à deepseek v4 pro.
Comme ce n’est pas simple non plus de changer de modèle à chaque tâche, la règle consistant à utiliser du local pour les tâches simples s’est révélée difficile à tenir.

[kirinonakar]

Il n’est pas forcément nécessaire que ce soit local : il existe de nombreuses alternatives d’abonnement peu coûteuses, comme opencode, ollama ou cursor.

[kurthong]

À l’ère des grands LLM, j’utilise un plugin que j’ai créé. Je l’avais déjà présenté une fois dans GN SHOW, et je pense que le fait de le concevoir et de l’utiliser ainsi selon ses propres besoins peut aussi être une bonne approche.

https://github.com/hang-in/tunaLlama