- ▸ Le test du quotidien : un Mac, ses Electron et un copilote local
- ▸ La taille n'est plus le seul critère
- ▸ D'où vient ce dilemme matériel
- ▸ Anatomie du choix : modèles, quantifications, vitesses
Faire tourner un grand modèle de langage en local sur un MacBook Pro M4 doté de 24 Go de mémoire impose un arbitrage permanent entre taille du modèle, vitesse de génération et place laissée aux applications du quotidien. Le retour d’expérience publié sur jola.dev tranche : seul Qwen 3.5-9B quantifié en Q4 tient la promesse d’un assistant exploitable. Trois variables, trois compromis, trois enseignements.
Points clés 1. Sur 24 Go de mémoire unifiée, plusieurs modèles tiennent en RAM mais deviennent inutilisables en pratique. 2. Qwen 3.5-9B en quantification Q4_K_S atteint environ 40 tokens par seconde, avec une fenêtre de contexte de 128 000 tokens. 3. Gemma 4B tourne sans contrainte mais peine à orchestrer des appels d’outils de manière fiable. 4. La cohabitation avec un environnement Electron pèse autant que la mémoire disponible dans le choix final. 5. LM Studio sert d’hôte ; l’intégration passe par un endpoint compatible OpenAI exposé sur localhost.
Le test du quotidien : un Mac, ses Electron et un copilote local
Imaginez un poste de développeur classique. Slack ouvert, un navigateur saturé d’onglets, un éditeur lourd, un client Docker, deux ou trois fenêtres Electron en arrière-plan. Sur un MacBook Pro M4 de 24 Go, le système consomme déjà plusieurs gigaoctets avant même qu’un assistant local n’ait été chargé. Reste, dans le meilleur des cas, une fenêtre étroite pour héberger un modèle de langage suffisamment musclé pour assister le code, dialoguer en streaming et appeler des outils externes. C’est dans cet espace contraint qu’un développeur a documenté son protocole de test, publié le 10 mai 2026 sur le carnet jola.dev. Son verdict, méthodique, mérite d’être disséqué : la mémoire unifiée d’Apple Silicon transforme la sélection d’un modèle local en équation à plusieurs inconnues.
La taille n’est plus le seul critère
L’auteur du retour d’expérience le formule sans détour : « You want the best model available that fits in memory and still gives you enough headroom to run your regular assortment of Electron apps, not to mention something where you can have at least a 64K context window, but ideally 128K or more. » La thèse est nette : tenir en mémoire ne suffit pas. Un modèle peut occuper l’espace alloué et rester inopérant — soit parce qu’il rame, soit parce qu’il échoue à utiliser ses outils, soit parce qu’il étrangle le reste de la machine. La performance utile dépend d’un triptyque taille-vitesse-fenêtre, et chaque arbitrage en sacrifie un autre.
D’où vient ce dilemme matériel
La question de l’IA locale n’est pas nouvelle, mais elle a changé de nature avec deux ruptures successives. La première remonte à l’arrivée de la mémoire unifiée chez Apple, quand les puces de la génération M ont rendu accessible l’inférence GPU sans avoir à dimensionner séparément RAM et VRAM. À partir de cette génération, les utilisateurs Mac ont gagné une option crédible face aux configurations Nvidia, sans pour autant disposer des capacités d’une carte graphique dédiée de très haut de gamme.
La seconde rupture tient à l’arrivée massive de modèles ouverts au cours des dernières années. Llama, Mistral, Phi, Gemma, Qwen, DeepSeek : un écosystème entier de poids librement téléchargeables a vu le jour, accompagné d’outils de quantification — la compression des poids en 3, 4, 5 ou 6 bits — capables de diviser par deux ou trois l’empreinte mémoire d’un modèle au prix d’une dégradation marginale de qualité.
C’est cette combinaison qui a fait émerger une catégorie nouvelle : la machine de développeur capable d’héberger son propre assistant. Le MacBook Pro M4 24 Go en est l’incarnation la plus accessible. Il ne joue pas dans la cour des stations 64 ou 128 Go, mais il représente le poste type d’un ingénieur logiciel équipé en 2026, et la cible de tout outil de productivité grand public sur Mac.
Le défi documenté sur jola.dev est donc de cartographier un espace de configuration restreint. L’auteur a testé une demi-douzaine de modèles dans la fourchette 4 à 24 milliards de paramètres, quantifications variées, et a confronté chacun à l’usage réel : génération de code, appel d’outils, dialogue maintenu sur de longs contextes, exécution en parallèle d’applications Electron lourdes.
Quatre options se sont rapidement disqualifiées. L’auteur cite « Q3, GPT-OSS 20B, Devstral Small 24B, which all technically fit in memory but were in practice unusable, and Gemma 4B that would run fine but really struggle with tool use. » Tenir en RAM ne préjugeait donc ni de la vitesse, ni de la qualité, ni surtout de la capacité à orchestrer un enchaînement d’outils externes. La problématique se déplace du seuil mémoire vers une matrice de contraintes croisées. C’est précisément cette matrice que le test permet de lire en creux.
Anatomie du choix : modèles, quantifications, vitesses
Le critère cardinal retenu par l’auteur tient en quatre dimensions mesurables : empreinte mémoire, fenêtre de contexte, vitesse de génération en tokens par seconde, fiabilité de l’appel d’outils. Aucun modèle testé ne maximise les quatre. Un seul réalise un compromis acceptable.
| Modèle | Quantification | Tient en mémoire | Vitesse | Outillage |
|---|---|---|---|---|
| Variante quantifiée Q3 | Q3 | Oui | Insuffisante | Inutilisable en pratique |
| GPT-OSS 20B | non précisée | Oui | Insuffisante | Inutilisable en pratique |
| Devstral Small 24B | non précisée | Oui | Insuffisante | Inutilisable en pratique |
| Gemma 4B | non précisée | Oui, large marge | Confortable | Difficile sur l’appel d’outils |
| Qwen 3.5-9B | Q4_K_S | Oui | ~40 tokens/s | Fonctionnel |
Le tableau dégage une frontière nette. En dessous de 9 milliards de paramètres, la machine respire mais le modèle décroche sur les enchaînements agentiques. Au-dessus, l’inférence ralentit jusqu’à rendre l’expérience inacceptable, alors même que le poids du modèle reste compatible avec 24 Go de RAM. Le compromis ne se lit donc pas sur une seule dimension : il faut intersecter taille utile et débit réel.
Le sélectionné final est explicite. Le Qwen 3.5-9B en Q4_K_S est, selon l’auteur, « the best model I’ve gotten working with a reasonable ~40 tokens per second, thinking enabled, successful tool use, and a 128K context window, running on LM Studio. » La référence interne au runtime, lmstudio/qwen3.5-9b@q4_k_s, lève toute ambiguïté sur la quantification employée : Q4_K_S, soit une compression 4 bits avec petit groupage. C’est le point d’équilibre habituellement recommandé sur Apple Silicon pour préserver la qualité des sorties tout en libérant plusieurs gigaoctets de mémoire au profit du reste du système.
L’intégration côté outils suit un schéma désormais standard. LM Studio expose un serveur HTTP local compatible avec le protocole OpenAI à l’adresse http://localhost:1234/v1 (ou http://127.0.0.1:1234/v1 selon les hôtes). N’importe quel client capable de parler à l’API OpenAI peut donc être reconfiguré pour pointer sur cette URL et consommer le modèle local. C’est cette interopérabilité protocolaire qui a fait basculer l’écosystème de la pure expérimentation vers l’usage de production.
L’auteur fournit deux exemples concrets de branchement. Côté OpenCode, la configuration s’écrit dans ~/.config/opencode/opencode.json et charge un schéma versionné disponible à https://opencode.ai/config.json. Le bloc utilise le connecteur générique @ai-sdk/openai-compatible, identifie le modèle par son slug lmstudio/qwen3.5-9b@q4_k_s et pointe sur l’endpoint local. Le bénéfice : pas de clé API, pas d’appel sortant, pas de coût marginal à l’usage.
Côté Pi, l’auteur réplique le même schéma dans ~/.pi/agent/settings.json et ajoute un drapeau dédié pour masquer la chaîne de pensée du modèle, considérée comme bruyante dans le flux conversationnel. La capacité « thinking enabled » fait référence aux passages internes de raisonnement explicite que Qwen 3.5 expose. Activés en arrière-plan, ils améliorent la fiabilité sur les tâches complexes ; affichés à l’écran, ils alourdissent l’expérience utilisateur.
Le test inclut un cas pratique parlant : la lecture du fichier ~/workspace/mixtli/.git/COMMIT_EDITMSG pour générer un message de commit. Ce type de tâche illustre la valeur d’un assistant local. Court contexte, accès à un fichier de travail jamais exposé en clair à un service tiers, latence négligeable. C’est sur ces cas-là que les 40 tokens par seconde changent l’usage : la suggestion arrive presque en temps réel sur des prompts courts, alors qu’un modèle 20 ou 24 milliards de paramètres patinerait sur la même machine au point de perdre tout intérêt opérationnel.
Ce que ça change pour un poste de développeur
L’enseignement le plus immédiat ne tient pas dans une métrique mais dans une nuance pratique. L’auteur écrit : « it’s surprisingly good for something that can run on a 24GB Macbook Pro while leaving space for lots of other things running too! » La promesse n’est pas la performance absolue. C’est la coexistence pacifique. Un développeur n’arrête pas Slack et Docker pour lancer une session d’aide au code. Le modèle local doit cohabiter, en silence, avec tout ce qui tourne déjà.
Cette contrainte transforme la grille de lecture. Sur un poste Linux ou Windows dopé à 64 Go et muni d’une carte graphique dédiée, le débat se résume au choix d’un modèle 30 ou 70 milliards. Sur le M4 24 Go, il se déplace vers la question du modèle juste suffisant. La sobriété devient un critère de sélection à part entière, et 9 milliards de paramètres apparaît comme un plancher fonctionnel — pas un compromis dégradé.
L’autre conséquence est budgétaire. Un poste M4 24 Go équipé d’un assistant local capable d’absorber les tâches courantes — relecture de diff, génération de messages de commit, recherche dans la base de code, complétion structurée — réduit la dépendance aux appels distants. Sur un volume mensuel élevé, l’économie devient visible. Elle n’élimine pas l’usage des modèles propriétaires hébergés, mais elle déplace la frontière des cas où l’on choisit l’un ou l’autre.
Vient ensuite la question de la confidentialité. Sur une machine personnelle ou un poste d’entreprise non rattaché à une politique d’IA cloud, l’inférence locale supprime la transmission de fragments de code à un tiers. Les équipes de développement opérant sur du code propriétaire trouvent dans ce schéma une réponse de premier niveau aux exigences de gouvernance des données, à condition d’accepter une qualité inférieure aux meilleurs services hébergés.
Enfin, la dimension thermique compte. Un M4 sollicité en permanence pour de l’inférence sur un modèle de 9 milliards de paramètres finit par chauffer et ventiler. Les sessions longues — agents qui tournent en boucle, batchs de génération continue — restent l’exception sur ce type de poste. Le modèle local sert mieux les micro-interactions de courte durée que les boucles agentiques continues. Cette répartition s’aligne assez naturellement avec les usages réels d’un poste de développement : courts allers-retours, prompts ciblés, suggestions instantanées, relectures ponctuelles.
La voix des sceptiques : un assistant utile, pas un égal des modèles SOTA
Toute lecture optimiste se heurte à un constat documenté par l’auteur lui-même. Il écrit, à propos de son modèle retenu : « 5 9B (Q4) is nowhere near being able to independently solve complex problems over longer period of time, like SOTA models are. » L’écart avec les frontières de l’état de l’art reste considérable, et pas en marge. Les modèles propriétaires les plus capables restent hors d’atteinte sur la planification multi-étapes, la qualité d’écriture argumentative ou la résistance aux hallucinations dans les domaines techniques pointus.
Plusieurs limites accompagnent cet écart. La fenêtre de contexte annoncée à 128 000 tokens reste utilisable, mais l’attention du modèle se dégrade au-delà de quelques dizaines de milliers, comme observé sur la plupart des modèles ouverts de la même classe de taille. Sur des bases de code importantes, le passage en RAG ou la sélection préalable d’extraits pertinents reste indispensable pour préserver la qualité des réponses.
L’appel d’outils, fonctionnel chez Qwen 3.5-9B, n’atteint pas la robustesse des modèles propriétaires de grande taille. Les boucles agentiques longues — où le modèle doit appeler dix ou vingt outils enchaînés sans dérailler — restent un terrain glissant. C’est précisément le cas d’usage le plus discuté en 2026, et celui sur lequel le local perd le plus de terrain face aux services hébergés.
Enfin, la durabilité du choix reste à vérifier. Le modèle retenu est aujourd’hui un compromis acceptable ; il sera dépassé dans quelques trimestres par un modèle de classe équivalente plus performant, ou rendu obsolète par une optimisation matérielle qui débloquerait des modèles plus volumineux confortables sur 24 Go. La photographie publiée sur jola.dev est valable au 10 mai 2026, mais elle n’est qu’une étape dans une trajectoire mouvante.
Et maintenant ? Trois pistes à surveiller
La première piste tient à la quantification dynamique et aux formats mixtes plus agressifs. Un modèle 9 milliards en Q5 ou Q6 sélectif, où les couches sensibles conservent une précision plus élevée, pourrait gagner quelques points de qualité sans franchir le seuil mémoire. Les runtimes pour Apple Silicon convergent vers ces approches.
La deuxième piste relève de l’architecture des modèles. Les variantes « mixture of experts » à faible activation, où seuls quelques milliards de paramètres travaillent à chaque token, ouvrent la perspective d’un comportement équivalent à un 30 milliards avec une empreinte mémoire bien plus contenue. Les générations 2026 promettent des trajectoires intéressantes dans cette direction.
La troisième piste est matérielle. La feuille de route Apple Silicon ne ralentit pas, et chaque génération relève le plafond utile. La question n’est pas tant de savoir si un poste 24 Go pourra héberger un meilleur modèle dans deux ans — il le pourra — que de savoir si le rapport entre les modèles ouverts et les modèles propriétaires se resserre ou s’élargit. Le retour d’expérience publié sur jola.dev est un instantané dans cette course longue.
FAQ
Quelle quantification choisir sur un M4 24 Go ?
La quantification Q4_K_S documentée pour Qwen 3.5-9B représente un point d’équilibre entre qualité et empreinte mémoire. Elle libère assez de RAM pour laisser tourner Slack, un éditeur lourd et un client Docker en parallèle, tout en maintenant une qualité de génération suffisante pour les tâches courantes de développement, selon le retour publié sur jola.dev le 10 mai 2026.
LM Studio est-il indispensable ?
Non. LM Studio est l’option retenue dans le retour d’expérience pour son endpoint compatible OpenAI accessible à http://localhost:1234/v1. D’autres runtimes locaux peuvent jouer un rôle équivalent. Le critère décisif est la compatibilité protocolaire avec les clients existants, pas la marque du runtime hôte.
Un modèle local peut-il remplacer un service hébergé ?
Pas sur les tâches longues ou agentiques complexes. L’auteur le dit en termes simples : son modèle retenu reste très loin des modèles SOTA pour la résolution autonome de problèmes étendus. Il remplit en revanche les micro-interactions du quotidien : génération de messages de commit, complétion structurée, relecture courte de diff, recherche dans une base de code.
La confidentialité des données est-elle préservée ?
Oui, pour la partie inférence : aucun fragment de code ne quitte la machine lors de l’appel local. La donnée du modèle elle-même, téléchargée depuis Hugging Face puis chargée par LM Studio, reste séparée du flux utilisateur. Cette propriété fait du local une réponse de premier niveau aux exigences de gouvernance interne sur le code propriétaire.
Sources
- jola.dev, « Running local models on an M4 with 24GB memory », 10 mai 2026 — https://jola.dev/posts/running-local-models-on-m4
