Exécuter Google Gemma 4 en local avec le Headless CLI de LM Studio et Claude Code

 (ai.georgeliu.com)
17 points par GN⁺ 2026-04-07 | 1 commentaires | Partager sur WhatsApp
  • Gemma 4 adopte une architecture mixture-of-experts qui n’active qu’une partie des paramètres, ce qui permet une inférence haute performance même sur du matériel modeste
  • LM Studio 0.4.0 introduit le nouveau Headless CLI (llmster), permettant de télécharger, charger, interroger des modèles et lancer un serveur API sans application desktop
  • Grâce aux API compatibles OpenAI et Anthropic, il est possible de servir Gemma 4 via un serveur local et d’utiliser Claude Code comme assistant de code entièrement hors ligne
  • Des réglages matériels fins, comme la longueur de contexte, le GPU offloading et les requêtes parallèles, permettent d’ajuster les performances et l’efficacité mémoire
  • L’inférence locale basée sur des modèles MoE permet des revues de code rapides et des tests de prompts sans coût d’API, et s’impose comme une technologie clé pour construire un environnement IA hors ligne pour développeurs

Exécuter Google Gemma 4 en local — intégration du nouveau Headless CLI de LM Studio avec Claude Code

  • Pourquoi exécuter un modèle en local

    • Les API d’IA cloud imposent des contraintes de coût, limitations de débit, confidentialité et latence réseau
    • Pour les tâches à itération rapide comme la revue de code, la rédaction de brouillons ou les tests de prompts, l’exécution locale de modèles est avantageuse
    • L’exécution locale offre les avantages suivants : coût d’API nul, aucun transfert de données vers l’extérieur et disponibilité permanente

    • Gemma 4** repose sur une architecture mixture-of-experts (MoE) où seuls 4B paramètres sur un modèle 26B sont activés**, ce qui permet des performances élevées même sur du matériel modeste

      • Sur un MacBook M4 Pro (48 Go), la vitesse observée atteint 51 tokens par seconde, avec une légère baisse dans Claude Code

  • La gamme de modèles Gemma 4

    • Google a publié 4 familles de modèles Gemma 4, optimisées pour différents matériels
    • La série E (E2B, E4B) utilise des Per-Layer Embeddings et prend en charge les entrées audio (reconnaissance vocale et traduction)
    • Le modèle dense 31B atteint 85,2 % sur MMLU Pro et 89,2 % sur AIME 2026
    • Le modèle 26B-A4B n’active que 8 experts sur 128 (3,8B paramètres), offrant une qualité de niveau 10B pour un coût de niveau 4B
    • Avec 82,6 % sur MMLU Pro, 88,3 % sur AIME et un Elo de 1441, il se rapproche du modèle dense 31B et rivalise avec des modèles de plus de 400B
    • Il prend en charge 256K de contexte, les entrées visuelles, l’appel de fonctions et le réglage du mode de raisonnement, ce qui le rend adapté à l’inférence locale

  • Les principaux changements de LM Studio 0.4.0

    • Introduction de llmster comme moteur d’inférence autonome, permettant une exécution complète en CLI sans application desktop

      • Le CLI lms permet de tout faire : télécharger un modèle, le charger, discuter avec lui et lancer un serveur
      • Principales fonctionnalités :
      • llmster daemon : gère en arrière-plan le chargement des modèles et l’inférence
      • Traitement de requêtes parallèles : plusieurs requêtes simultanées grâce au continuous batching
      • Stateful REST API : l’endpoint /v1/chat conserve l’historique de conversation
      • Intégration MCP : prise en charge locale du Model Context Protocol

  • Installation et téléchargement du modèle

    • Commande d’installation : 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • Lancer le daemon : lms daemon up
    • Mettre à jour le runtime : lms runtime update llama.cpp, lms runtime update mlx
    • Télécharger le modèle Gemma 4 26B : lms get google/gemma-4-26b-a4b
    • La quantification par défaut est Q4_K_M (17.99GB)
    • Après téléchargement, le charger avec lms load google/gemma-4-26b-a4b

  • Gestion des modèles locaux

    • Afficher la liste des modèles installés : lms ls
    • L’exemple de sortie comprend plusieurs modèles MoE, dont Gemma 4, Qwen 3.5 et GLM 4.7 Flash
    • Les modèles MoE permettent une inférence efficace en n’utilisant qu’une partie des paramètres actifs

  • Exécution des conversations et performances

    • Démarrer une conversation : lms chat google/gemma-4-26b-a4b --stats
    • Exemple de sortie : 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • Avec 51 tok/sec et une réponse initiale en 1,5 s, la vitesse est suffisante pour une interaction confortable

  • Vérification de l’état du modèle et de la mémoire

    • Vérifier les modèles chargés : lms ps
    • Exemple : 17.99GB de mémoire utilisée, 48K de contexte, 2 requêtes parallèles, TTL d’1 heure
    • Éléments clés visibles dans la sortie JSON (lms ps --json | jq) :
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • Estimation mémoire selon la longueur de contexte

    • L’option --estimate-only permet de prédire les besoins en mémoire
    • Le modèle de base nécessite environ 17.6GiB, puis 3 à 4GiB supplémentaires à chaque doublement du contexte
    • Il faut environ 21GiB pour 48K de contexte, et 37.48GiB pour 256K
    • Exemple de commande : 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • La relation linéaire entre longueur de contexte et mémoire est utile pour planifier la capacité

  • Ajuster le chargement selon le matériel

    • Longueur de contexte

      • À régler dans la limite de mémoire disponible, en tenant compte de la consommation de l’OS (4 à 6 Go)
      • Exemple : lms load google/gemma-4-26b-a4b --context-length 128000

    • GPU offloading

      • Les machines Apple Silicon utilisent une mémoire unifiée, ce qui permet d’utiliser tout le GPU avec --gpu=1.0
      • Sur les systèmes NVIDIA, on peut répartir la charge selon la VRAM disponible avec --gpu=0.5, etc.

    • Requêtes parallèles

      • Le continuous batching permet de traiter plusieurs requêtes simultanément
      • Dans l’interface graphique, le réglage Max Concurrent Predictions est disponible (4 par défaut)
      • Pour Gemma 4, sur un système 48 Go, 48K de contexte et 2 requêtes parallèles constituent un bon compromis

    • Déchargement automatique via TTL

      • --ttl 1800 permet un déchargement automatique après 30 minutes d’inactivité
      • La valeur par défaut est 1 heure, et il est possible de désactiver cette fonction avec 0 ou -1

    • Enregistrer les valeurs par défaut par modèle

      • Dans l’application desktop, My Models → icône de configuration permet d’enregistrer les paramètres par défaut pour le GPU, le contexte et Flash Attention

    • Décodage spéculatif (Speculative Decoding)

      • Peu efficace sur les modèles MoE ; il est recommandé de le désactiver pour Gemma 4
      • D’après des tests sur Mixtral, les tâches de code progressent de 39 %, mais les tâches mathématiques chutent de 54 %

    • Flash Attention

      • Permet de réduire la mémoire du cache KV et donc de mieux gérer les contextes longs
      • Sur Apple Silicon, son activation permet d’économiser de la mémoire

  • L’application desktop LM Studio

    • L’interface graphique visualise l’état du serveur, le chargement du modèle, les endpoints API et les flux de logs
    • Elle inclut le protocole Anthropic (POST /v1/messages)
    • Les capacités de vision permettent d’analyser des images
    • Exemple : lors de l’analyse d’une image Timezone Scheduler, 504 tokens ont été générés à 54.51 tok/sec
    • Résultats du monitoring système :
      • Utilisation mémoire : 46.69GB/48GB, swap 27.49GB
      • GPU utilisé à 90 %, CPU à 91°C, GPU à 92°C
      • Consommation électrique : 23.56W (CPU 11.06W, GPU 13.32W)
    • Grâce à la mémoire unifiée, il n’y a pas de copie de données entre CPU et GPU

  • Exposer le modèle via un serveur API

    • Démarrer le serveur : lms server start
    • API compatible OpenAI : http://localhost:1234/v1
    • Endpoint compatible Anthropic : POST /v1/messages
    • Changer le port : --port 8080
    • Le chargement JIT des modèles permet un chargement automatique à la requête, puis un déchargement automatique après le TTL
    • Flux de logs en temps réel : lms log stream --source model --stats
    • L’accès depuis d’autres appareils du réseau est possible, avec prise en charge de l’authentification par token API

  • Intégration avec Claude Code

    • Grâce à l’endpoint compatible Anthropic, Claude Code peut fonctionner avec un modèle local
    • Ajouter la fonction claude-lm à ~/.zshrc : 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • Tous les appels de modèles Claude Code (Opus, Sonnet, Haiku) sont redirigés vers Gemma 4
    • L’environnement est configuré avec 48K de contexte, une limite de sortie de 8K tokens et un usage strictement local
    • En lançant claude-lm, il est possible d’utiliser un assistant de code totalement hors ligne
    • C’est plus lent que le cloud, mais bien adapté à la revue de code, aux petites modifications et au travail exploratoire

  • Principaux enseignements

    • Les modèles MoE sont au cœur de l’inférence locale : Gemma 4 26B-A4B offre une qualité de niveau 10B pour un coût de niveau 4B
    • Le daemon headless permet un workflow entièrement basé sur le CLI
    • La longueur de contexte est la principale variable de consommation mémoire
    • --estimate-only aide à éviter les OOM
    • L’endpoint compatible Anthropic permet d’exécuter Claude Code entièrement hors ligne en local

  • Limites

    • lms chat n’affiche pas directement le nom du modèle
    • Le contexte par défaut de 48K est prudent ; il est recommandé de l’augmenter si la mémoire le permet
    • L’exécution locale de Claude Code ne remplace pas complètement l’API Anthropic, ce qui limite les très gros travaux
    • Sur un système 48 Go, une pression mémoire et l’usage du swap apparaissent ; 64 Go ou plus sont recommandés

  • Prochaines étapes

    • Des tests comparatifs sont prévus avec Qwen 3.5 35B, GLM 4.7 Flash et Nemotron 3 Nano
    • Récapitulatif de la procédure d’exécution : 
      curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get google/gemma-4-26b-a4b
lms chat google/gemma-4-26b-a4b --stats
    • Pour l’intégration avec Claude Code : ajouter la fonction claude-lm, puis lancer claude-lm
    • Peut servir à mettre en place un workflow IA local et à l’intégrer à des applications web ou à un environnement développeur

À lire aussi

1 commentaires

 
GN⁺ 2026-04-07
Réactions sur Hacker News

  • On peut utiliser directement llama.cpp server pour faire tourner un LLM localement et l’exploiter avec Claude Code ou d’autres agents CLI
    L’auteur a résumé un guide de configuration complet testé sur un MacBook M1 Max 64 Go avec des LLM récents à poids ouverts, dont Gemma4
    Le modèle 26BA4B était le plus intéressant sur ce matériel, avec une vitesse de génération de tokens (40 tok/s) presque deux fois supérieure à celle de Qwen3.5 35BA3B
    En revanche, les résultats au benchmark tau2 étaient inférieurs à ceux des variantes de Qwen (68 % contre 81 %), ce qui le rendrait peu adapté aux tâches complexes centrées sur les outils

    • Je me demande s’il n’y a pas eu de conflit de spécifications entre Anthropic et OpenAI dans Claude Code
      J’utilise mlx_vlm et vMLX, et j’obtiens des erreurs 400 Bad Request dans Claude Code
      Je voudrais savoir si le même problème apparaissait aussi avec llama-server

  • J’ai l’impression que les modèles locaux ont désormais dépassé le stade du simple « c’est possible » pour entrer dans une phase agréable à utiliser au quotidien
    Le flux LM Studio headless est particulièrement impressionnant. Il permet d’utiliser l’inférence locale dans de vrais outils
    Je développe un agent open source de coding en CLI appelé cloclo, qui prend en charge divers backends comme LM Studio, Ollama, vLLM, Jan et llama.cpp
    On se rapproche d’une combinaison idéale : les modèles locaux pour un usage quotidien personnel et peu coûteux, les modèles cloud pour les tâches à haute performance

    • Je me demande en quoi cloclo se distingue de pi-mono

  • Le point clé ici n’est pas tant Gemma 4 lui-même que le fait que le harnais (harness) soit désormais complètement découplé du modèle
    Claude Code, OpenCode, Pi et Codex fonctionnent tous avec n’importe quel backend
    Autrement dit, les agents de coding deviennent peu à peu une couche générique, et la concurrence se déplace vers la qualité des modèles et les coûts
    C’est une bonne nouvelle pour les utilisateurs, et une menace pour les entreprises qui dépendaient du harnais

    • Je pense plutôt l’inverse. Ce sont les modèles qui se banalisent, et le harnais et l’outillage deviennent la vraie source de gains de performance
      Par exemple, dans « Improving 15 LLMs at Coding in One Afternoon », il était dit qu’un simple changement de harnais apportait déjà de gros progrès
    • En réalité, on pouvait déjà connecter directement Claude Code ou OpenCode à un endpoint HTTP local

  • On peut le lancer très simplement avec la commande ollama launch claude --model gemma4:26b

    • Si on n’augmente pas la taille de la context window, l’appel d’outils ne fonctionne pas
    • C’est surprenant de voir que cela fonctionne de manière aussi simple, avec seulement ollama et claude installés
    • Chez moi, en revanche, cela n’a pas fonctionné. Claude entrait dans une boucle infinie sans répondre
      Nemotron, glm et qwen 3.5 marchaient bien, mais gemma posait problème

  • Cette approche pourrait aussi être utile pour l’automatisation des tests de logiciels web
    Avec Selenium ou Puppeteer, les tests cassent facilement dès que le design d’un site change un peu
    À l’inverse, ce type de modèle pourrait s’adapter aux changements et permettre des tests plus flexibles
    Cela semble particulièrement exploitable même avec de petits modèles

  • Le MoE n’économise pas réellement de (V)RAM
    Tous les poids doivent rester en mémoire, même si seule une partie est utilisée à chaque inférence
    Cela améliore donc les tok/s, mais pas l’utilisation de la VRAM

    • Moi aussi, cela m’avait embrouillé au début. Les experts inactifs ne sont pas calculés, mais ils restent chargés en mémoire
      Cette visualisation m’a aidé à mieux comprendre
    • Certains moteurs d’inférence permettent de déporter une partie des experts vers la RAM du CPU
      Par exemple, on peut faire tourner un MoE de 35B paramètres avec un GPU de 12 Go de VRAM + 16 Go de RAM
    • Il n’est pas nécessaire de garder tous les poids en mémoire en même temps
      On peut charger à la demande uniquement les parties nécessaires depuis la RAM, le disque ou le réseau
      Le MoE réduit alors le volume de données à échanger lors de l’étape d’inférence suivante

  • J’utilise Claude Code comme interface principale pour les tâches itératives de pipeline de données
    En particulier pour normaliser des publications réglementaires gouvernementales (XBRL) et les exposer via REST et MCP
    Le MCP est un aspect intéressant : au lieu d’appeler directement les clients, on déclare les outils de manière déclarative et le modèle décide quand les invoquer
    Par exemple, une requête comme « comparer la tendance d’endettement de cette entreprise sur 10 ans à la moyenne du secteur » est automatiquement décomposée en une séquence appropriée d’appels d’outils
    En revanche, dans l’usage conversationnel de MCP, la latence est bien plus sensible
    Une réponse en 2 secondes est acceptable dans un script, mais casse le flux d’une conversation
    J’ai donc mis en cache en mémoire les tables les plus utilisées pour obtenir des réponses sous les 100 ms
    Je me demande si d’autres ont observé ce même seuil critique de latence

    • J’utilise aussi MCP avec intérêt, mais la consommation de tokens peut vite grimper
      Dans une implémentation simple, cela peut consommer des dizaines de milliers de tokens de plus pour une fonctionnalité équivalente
      Il y a bien l’article explicatif d’Anthropic, mais il commence à dater
    • D’après mon expérience, 300 à 500 ms par appel d’outil est la limite supérieure pour que cela reste naturel
      Au-delà, les chaînes multi-étapes ralentissent, et le modèle ajoute des raisonnements inutiles qui gonflent le contexte
      En plus du cache, une stratégie efficace consistait à réduire les allers-retours en faisant renvoyer plusieurs données à la fois

  • Partage d’une méthode pour configurer Gemma 4 26B comme inférence locale pour Claude Code sur macOS

    • Je trouve que c’est une excellente synthèse

  • À l’avenir, on pourrait voir les grands laboratoires d’IA faire tourner aussi des LLM locaux pour réduire la charge du cloud, et ne réserver le cloud qu’aux calculs lourds

    • Mais je me demande si cela n’entrerait pas en conflit avec leur modèle économique

  • Je me demande à quel point le modèle Gemma 4 est performant sur les tâches de coding agentique, et quelle impression il laisse en pratique