Exécuter des modèles locaux avec 24 Go de mémoire sur un M4

(jola.dev)

1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp

Même sur un MacBook Pro M4 24 Go, il est possible de mettre en place une configuration de modèle local pour les tâches de base, la recherche et la planification
Qwen 3.5-9B Q4 atteint environ 40 tokens/s et prend en charge le mode réflexion, l’usage d’outils et un contexte de 128K
Il ne peut pas résoudre seul de longs problèmes complexes comme les meilleurs modèles, et nécessite donc des instructions étape par étape
Il a corrigé des avertissements Elixir Credo, mais a échoué à résoudre des conflits de rebase sans modifier les fichiers
Les modèles locaux ont l’avantage de fonctionner hors ligne et sans abonnement, mais impliquent d’importants compromis sur les performances et la configuration

Environnement d’exécution des modèles locaux et critères de choix

Des essais ont été menés pour configurer l’exécution de modèles locaux sur un MacBook Pro M4 avec 24 Go de mémoire. Même si les résultats diffèrent de ceux des meilleurs modèles du moment (SOTA), il a été possible d’obtenir une configuration capable de gérer des tâches de base, de la recherche et de la planification sans connexion Internet
Parmi les outils d’exécution locale figurent Ollama, llama.cpp et LM Studio, chacun avec ses propres limites et son catalogue de modèles
Le choix du modèle devait permettre de tenir en mémoire tout en laissant assez de marge pour faire tourner en parallèle des applications Electron classiques, avec une fenêtre de contexte d’au moins 64K, idéalement 128K ou plus
Les essais récents avec Qwen 3.6 Q3, GPT-OSS 20B et Devstral Small 24B montraient qu’ils tenaient en mémoire mais restaient difficiles à utiliser en pratique, tandis que Gemma 4B s’exécutait correctement mais montrait des limites dans l’usage des outils
Les paramètres de configuration vont de valeurs connues comme temperature à des options plus spécifiques comme K Cache Quantization Type, et les bons réglages varient selon que le mode réflexion (thinking) est activé ou non

Configuration de Qwen 3.5-9B quantifié en 4 bits

qwen3.5-9b@q4_k_s a été le meilleur modèle observé dans LM Studio, en réunissant environ 40 tokens/s, la réflexion activée, un usage d’outils fonctionnel et une fenêtre de contexte de 128K
Il se déconcentre plus facilement que les meilleurs modèles, entre parfois en boucle et interprète parfois mal les requêtes, mais pour un modèle capable de tourner sur un MacBook Pro 24 Go tout en laissant de la place pour d’autres tâches, le résultat restait très correct
Les réglages recommandés pour le mode réflexion et les tâches de code étaient les suivants

temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

Pour activer la réflexion, il faut sélectionner le modèle dans LM Studio, aller dans configuration, puis ajouter la valeur suivante dans le champ Prompt Template en bas de l’onglet Inference

{%- set enable_thinking = true %}

Ce modèle a été utilisé à la fois avec pi et OpenCode. pi semblait plus réactif, mais malgré l’avantage de pouvoir construire et personnaliser soi-même le harness, il manquait de valeurs par défaut raisonnables
Il est possible de passer plus de temps à ajuster pi qu’à travailler sur le projet lui-même

Configuration de pi

Dans ~/.pi/agent/models.json, l’endpoint compatible OpenAI de LM Studio et le modèle qwen3.5-9b@q4_k_s ont été enregistrés

{
  "providers": {
    "lmstudio": {
      "baseUrl": "http://localhost:1234/v1";,
      "api": "openai-completions",
      "apiKey": "lm-studio",
      "models": [
        {
          "id": "qwen3.5-9b@q4_k_s",
          "reasoning": true,
          "compat": { "thinkingFormat": "qwen-chat-template" }
        }
      ]
    }
  }
}

Pour masquer les blocs de réflexion trop dispersés, il faut ajouter "hideThinkingBlock": true dans ~/.pi/agent/settings.json

Configuration d’OpenCode

Dans ~/.config/opencode/opencode.json, LM Studio a été enregistré comme provider local compatible OpenAI, avec l’usage d’outils, une longueur de contexte de 131072 et un maximum de 32768 tokens

{
  "$schema": "https://opencode.ai/config.json";,
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1";
      },
      "models": {
        "qwen3.5-9b@q4_k_s": {
          "name": "Qwen 3.5 9B Q4_K_S",
          "tools": true,
          "context_length": 131072,
          "max_tokens": 32768
        }
      }
    }
  },
  "model": "lmstudio/qwen3.5-9b@q4_k_s"
}

Différences avec les meilleurs modèles

Un modèle comme Qwen 3.5 9B Q4 n’atteignait pas le niveau des meilleurs modèles pour résoudre seul des problèmes complexes pendant de longues périodes
Lui demander de construire une application entière d’un seul coup n’était pas une bonne approche, et l’on pouvait se retrouver avec un portable qui chauffe sans produire de résultat
Une méthode plus adaptée consistait en un workflow interactif, avec une communication claire étape par étape et beaucoup d’instructions
Avec un modèle local, l’utilisateur doit prendre davantage en charge la réflexion et la planification, et donner des consignes plus précises, mais il reste utile comme assistant de recherche, rubber duck ou aide pour retrouver immédiatement des détails de langage de programmation et des appels en ligne de commande
Ce n’est pas le gain de productivité x10 vanté par les grandes entreprises de l’IA, mais cela apporte une aide réelle et une expérience d’usage intéressante

Tâches réussies et tâches ratées

Correction d’avertissements Elixir Credo
- Après la mise à jour du linter Elixir credo vers la dernière version, des avertissements sont apparus dans le code, et il a été demandé à Qwen d’exécuter mix credo --strict et de proposer une solution sans modifier les fichiers
- Qwen a repéré dans quatre fichiers de test l’usage de length/1 pour vérifier qu’une liste n’était pas vide, et a proposé d’utiliser list != [] à la place de length(list) > 0
- Une fois la modification demandée, Qwen a effectué proprement quatre éditions en parallèle
- C’était une tâche simple qui aurait aussi pu être faite manuellement en alternant entre terminal et éditeur, mais le modèle a joué un rôle d’assistant pratique
Gestion d’un conflit de rebase sur une PR Dependabot
- Après une mise à jour de dépendances, une PR Dependabot présentait un conflit git. Dependabot refusant le rebase, la branche a été récupérée localement et rebasée avant de demander à Qwen de vérifier
- Le conflit était simple : il suffisait de choisir la version la plus récente pour chaque dépendance, et Qwen a recommandé de conserver sentry en 13.0.1 et tailwind en 0.4.1
- Mais lorsqu’il a fallu appliquer réellement les changements, Qwen a tenté d’exécuter git add mix.lock && git rebase --continue sans modifier le fichier, alors que les marqueurs de conflit étaient toujours présents
- Il n’a pas non plus compris que git rebase --continue ouvrait un éditeur, et OpenCode s’est bloqué ; il est toutefois possible que ce comportement ait été ponctuel

Avantages et limites des modèles locaux

Les modèles locaux impliquent d’importants compromis, mais ils offrent l’avantage de permettre de travailler dans l’avion sans connexion Internet
En supposant que l’ordinateur aurait de toute façon été acheté, le coût se limite à l’électricité consommée, sans abonnement nécessaire
L’entraînement des modèles conserve un coût environnemental important, mais les entreprises de modèles ouverts restent loin des plus gros contributeurs à cet impact, et l’usage de matériel personnel réduit la dépendance aux datacenters
Il y a aussi un plaisir à ajuster soi-même les paramètres et à expérimenter
Les LLM ont déjà eu un impact majeur et comportent aussi de nombreux aspects négatifs, mais ils semblent appelés à durer ; expérimenter avec des modèles locaux donnait l’impression d’interagir avec cette technologie d’une manière plus durable et plus positive

1 commentaires

GN⁺ 2 시간 전

Commentaires sur Hacker News

Faire tourner des LLM en local, c’est amusant et puissant, mais pour réellement terminer un travail, c’est souvent assez pénible
Il faut planifier à l’avance, rédiger des specs et tout préparer, alors que les gros modèles d’OpenAI ou Claude comprennent souvent tout de suite avec seulement quelques phrases
- Oui. Surtout ces 6 derniers mois, pour beaucoup de gens, l’abonnement aux modèles frontier est devenu une dépense de travail
  Si vous faites déjà du travail sérieux avec de gros modèles, vous pouvez simplement continuer à les utiliser
  En revanche, je vois les choses différemment pour la vision/OCR. Même les modèles à poids ouverts petits ou moyens sont proches du meilleur niveau actuel, et sur de gros traitements par lots, le coût des tokens de préremplissage est assez pénible
  On oublie aussi souvent que, même pour un petit LLM, si on veut l’utiliser comme un service personnel stable, il faut garder 16 à 24 Go de RAM/VRAM libres et le laisser tourner en permanence
- Aujourd’hui, faire tourner de gros modèles chez soi pour un usage hors ligne est devenu techniquement facile. On le doit beaucoup aux acteurs chinois qui publient des modèles haut de gamme
  Le vrai problème, au fond, c’est l’argent
J’ai l’impression qu’on est arrivé à un niveau presque vraiment exploitable
Gemma 4 31B donne l’impression d’être la nouvelle référence des modèles locaux. Bien sûr, c’est en dessous des modèles frontier, mais cela fait moins “expérience scientifique” que les modèles locaux que j’avais essayés jusqu’ici, comme GPT OSS 120B ou Nemotron Super 120B
Sur un M5 Max avec 128 Go de RAM, utiliser toute la fenêtre de contexte de 256K fait monter l’usage mémoire jusqu’à environ 70 Go, avec un surcoût système d’environ 14 Go
Une machine Panther Lake 64 Go avec une Arc B390 complète, ou une machine Snapdragon X2 Elite 48 Go, devrait pouvoir le faire tourner avec une fenêtre de contexte de 128K à 256K, et avec 32 Go on pourrait peut-être forcer une fenêtre de 32K
Rien que l’an dernier, voir ce niveau de performances sur une configuration haut de gamme proche du mainstream aurait semblé totalement irréaliste
- Gemma 4 est vraiment bon. Il a parfois trouvé juste là où Opus 4.7 s’était trompé, et même s’il reste un peu brut, je trouve régulièrement des usages où il est pratiquement équivalent
  Au final, le vrai critère, c’est : “qu’est-ce qu’on peut lui confier de façon fiable ?” Opus sait clairement plus de choses et peut faire des tâches plus complexes, mais si on lui fournit bien le contexte, Gemma est étonnamment bon
  L’écart entre ce que j’oserais confier à l’un ou à l’autre est étonnamment faible. J’ai eu de très bons résultats récemment dans des outils personnels et sur plusieurs projets, et c’est le premier modèle local auquel j’ai pu confier en mode agent l’implémentation de fonctionnalités sur un projet non trivial
  https://thot-experiment.github.io/gradient-gemma4-31b/
  C’est un outil relativement complexe, réalisé presque entièrement par Gemma 4 dans OpenCode, et je n’ai dû intervenir manuellement qu’environ 4 fois en quelques heures
  Q6_K_XL, contexte 128K @ q8, environ 800 tok/s en lecture, 16 tok/s en écriture
  J’attends turboquant et MTP dans llama.cpp, et si les rumeurs sont vraies, on pourrait monter à 256K et 25 à 30 tok/s
- Les petits modèles Qwen 3.6 gèrent un peu mieux le contexte que Gemma 4, mais Gemma 4 26B notamment est intelligent dans sa façon de proposer une solution très compacte et efficace pour cette catégorie
  J’avais même écrit un billet dessus [0] juste après sa sortie, car ses performances de benchmark étaient impressionnantes. Mais après l’avoir fait tourner dans des environnements de codage agentique avec des contextes plus longs, sa position dans mon classement a un peu reculé
  [0] https://gertlabs.com/blog/gemma-4-economics
- Pour la plupart des tâches d’édition, j’utilise plutôt le plus petit Gemma E2B, et il fonctionne étonnamment bien
  Mon flux consiste à faire la planification avec un modèle récent, puis l’exécution avec un petit modèle. Si le plan est suffisamment bon et ne laisse pas d’ambiguïtés que le petit modèle devrait interpréter, cela marche bien
- Ce serait bien de partager le temps jusqu’au premier token et le débit en tokens/s
- Je me demande si, en pratique, Gemma fonctionne mieux que qwen3
J’aurais aimé voir ce billet avant de passer tout un week-end à arriver à la même conclusion
J’ai fait un test artificiel sur le même portable : corriger une cinquantaine d’erreurs de lint dans un petit dépôt C++ de vibe coding. J’espérais qu’en traitant beaucoup de petites tâches, ça avancerait sans se bloquer trop souvent
GPT OSS 20B était utilisable, mais lent, ajoutait ou répétait souvent des phrases inutiles, et faisait fréquemment l’erreur d’énumérer des corrections sans avoir réellement modifié le code
Qwen 3.5 9B utilisé avec Opencode était bien plus rapide, a traversé la compression sans trop se bloquer sur la plupart des avertissements de lint, et a corrigé tous les avertissements avec les bonnes modifications
J’ai aussi essayé la quantification MLX 4 bits de Qwen 3.5 9B, mais ça a fini par planter par manque de mémoire ; en passant à un GGUF exécuté via llama.cpp, ça a tourné sans crash
Rien à voir avec les modèles frontier. C’est beaucoup plus lent, les informations de base sont souvent fausses, et ça ne sait pas traiter d’un coup des tâches un peu sérieuses
Je lui ai demandé un résumé de l’architecture du projet, et il a affirmé utiliser une bibliothèque qui n’existe nulle part dans le dépôt. Cela dépend sans doute des gens, mais il y a quand même un côté utile, et j’espère qu’avec le temps l’environnement local des LLM deviendra bien meilleur même sur du matériel raisonnable
- La phrase “rien à voir avec les modèles frontier” n’est pas répétée assez souvent
  Les LLM locaux sont formidables, mais si on lit beaucoup d’articles sur le sujet, on peut avoir l’impression qu’ils sont presque au niveau de Opus 4.7
  Sur HN, il existe un tout petit groupe très bruyant et très enthousiaste qui exagère énormément les capacités des LLM locaux
- Au lieu de qwen3.5 9b, il vaudrait mieux essayer qwen3.6.35 a3b. C’est complètement différent
- C’est assez surprenant que GPT OSS 20B tourne lentement sur du matériel Mac
  C’était l’un des modèles les plus rapides de cette taille que j’avais testés sur GPU local, mais je ne l’ai essayé que sur des cartes Nvidia
  En regardant ensuite, j’ai vu que c’était un MoE avec seulement 3,6B de paramètres actifs, ce qui explique beaucoup de choses
Il est utile d’avoir une vision réaliste de ce qu’on peut faire avec des modèles locaux, surtout des petits modèles comme le 9B utilisé par l’auteur
Un modèle 9B est au niveau d’un Sonnet 3.6 environ, donc il peut faire de l’autocomplétion et de petites fonctions, mais dès qu’il faut comprendre un gros problème, il perd le fil
Cela reste intéressant et amusant à explorer. Je construis surtout beaucoup de harnais d’agents locaux pour le plaisir
Mon projet actuel est un agent sans installation : https://gemma-agent-explainer.nicklothian.com/
Python, SQL et React s’exécutent tous entièrement dans le navigateur. Pour la meilleure expérience, je recommande Gemma E4B
C’est encore en développement actif, et Chrome est nécessaire à cause du support de l’API HTML5 Filesystem et de LiteRT. Cela dit, je devrais pouvoir le faire fonctionner sur la plupart des navigateurs basés sur Chromium
La différence avec la plupart des agents, c’est justement qu’il est sans installation. Le modèle tourne dans le navigateur via LiteRT/LiteLLM, avec de meilleures performances que Transformers.js. Il peut aussi avoir, de manière optionnelle, un accès en lecture à un répertoire sandbox via l’API Filesystem
Le projet est auto-documenté, donc si on demande dans le panneau d’aide en direct “comment le prompt système est-il utilisé ?”, il peut répondre en accédant à son propre code source
Cliquez sur “Tour” pour tout voir, et je prévois de le publier en open source la semaine prochaine
- Avec Sonnet 3.5, je faisais bien plus que de l’autocomplétion et de petites fonctions
- Sans vouloir chipoter, beaucoup de modèles 4 à 12B se situent quelque part entre GPT-3.5 et GPT-4o-mini
  Le problème, c’est que les benchmarks utilisés pour évaluer les modèles changent trop souvent, donc il est difficile de trouver de bonnes comparaisons. À noter au passage que Sonnet 3.6 est sorti environ un an après GPT-3.5
Si on veut être critique, il est vrai que ces modèles ne sont pas au niveau des meilleurs modèles actuels sur les tâches de codage complexes
Mais une grande partie du travail de bureau consiste à faire du traitement Excel, déplacer des fichiers, traduire des documents juridiques rébarbatifs, rédiger des e-mails, ou gérer de petites corvées sur PowerPoint
Pour ce genre de tâches, des modèles de 30 à 35B et plus suffisent largement, avec en plus l’avantage de garder les données de l’entreprise privées
- Je pense que la conclusion est un peu fausse. Que qwen3.5 9b soit loin des modèles actuels, c’est normal : c’est un 9B, et un modèle d’il y a un an, non ?
  Quand les gens parlent de modèles locaux, ils ont en tête les modèles sortis en avril cette année. Il s’agit de Qwen 3.6 27B et, si le GPU est un peu faible, de qwen 35b a3b
  Ces modèles peuvent sérieusement être comparés aux modèles les plus récents
- Excel et le juridique peuvent même être bien pires que le code, au contraire. Parce qu’il peut être encore plus difficile d’y repérer les erreurs
  L’exemple classique, c’est l’affaire London Whale de JPMorgan, où une erreur Excel a entraîné 6 milliards de dollars de pertes
J’envisage un MacBook M5 Pro 18/20 cœurs avec 64 Go de RAM, mais il est vraiment très difficile de trouver de vrais benchmarks de modèles
Par exemple, si quelqu’un pouvait indiquer combien de tokens/s on obtient avec les quantifications Q4 et Q6 de Qwen 3.6 35B/A3B, ce serait utile
- Il ne faut pas regarder seulement le débit en tokens/s, mais aussi le temps jusqu’au premier token
  L’inférence locale penche de plus en plus vers les modèles MoE, et beaucoup d’entre eux ont un débit en tokens/s correct mais un temps jusqu’au premier token catastrophique
J’ai posté sur Bluesky une configuration un peu au hasard que j’utilise sur un M2 Studio 32 Go, et j’aimerais avoir des retours
Je partage ça en espérant de l’aide, car j’ai du mal tant que je ne vois pas directement comment les autres s’y prennent
https://bsky.app/profile/mooresolutions.io/post/3mliilyf2i22...
Sur un M4 Pro 48 Go, je fais tourner un modèle quantifié qwen 3.6 9b, et c’est juste à peine utile pour du développement de base sur pi.dev/cc
Pour faire un travail réellement significatif, le bon compromis semble être un desktop 128 Go. Le problème, c’est qu’il est difficile de trouver ce type de machine en ce moment
Faire tourner du local, c’est amusant, mais il ne faut pas oublier que son propre temps n’est pas gratuit
Pour mes projets personnels, je migre de plus en plus vers OpenRouter, et même en utilisant sérieusement les plus gros modèles qwen, je reste sous les 2 à 3 dollars par jour
- Je me demande si vous avez choisi un modèle aussi petit pour obtenir un débit élevé en tokens/s
  Avec un M4 Pro 48 Go, vous pouvez faire tourner des modèles plus gros ; si l’intelligence du modèle est le facteur clé de son utilité, il pourrait être plus pertinent d’en utiliser un plus grand
- Avec la même configuration, j’utilise un modèle MoE 30B comme sous-agent outillé avec 65K tokens, et il produit du code plutôt correct
  Je suis d’accord sur le fait qu’un 9B dense n’est pas terrible
- Il y a beaucoup trop de bêtises en ligne disant que les modèles locaux sont meilleurs que quelque chose comme Opus 4.7. Pour l’utilisateur moyen, ce n’est pas vrai
  J’utilise la configuration maximale du tout dernier MacBook Pro M5 et j’ai aussi testé des modèles locaux, et on est presque au niveau du “ça marche à peine”
- Je suis curieux de savoir comment la version OpenRouter se compare à ChatGPT 5.5 ou Claude Opus 4.6
Sur une 4090 24 Go, j’exécute qwen3.6:27B avec un contexte d’environ 128K en profitant des optimisations mémoire récentes de valeurs activées turboquant/rotorquant
Je recommande fortement de monter à ce niveau de modèle. La combinaison q4_xl+rotorquant est vraiment bonne
Il y a aussi du code de référence à donner à un agent
https://github.com/rapatel0/rq-models
Je pense qu’il vaut mieux dépenser plusieurs milliers de dollars dans un Mac que dans des abonnements API
Les modèles locaux permettent de travailler n’importe où, n’importe quand, sans inquiétude de fuite de confidentialité

Exécuter des modèles locaux avec 24 Go de mémoire sur un M4

Environnement d’exécution des modèles locaux et critères de choix

Configuration de Qwen 3.5-9B quantifié en 4 bits

Configuration de pi

Configuration d’OpenCode

Différences avec les meilleurs modèles

Tâches réussies et tâches ratées

Correction d’avertissements Elixir Credo

Gestion d’un conflit de rebase sur une PR Dependabot

Avantages et limites des modèles locaux

À lire aussi

1 commentaires

Commentaires sur Hacker News