LM Studio et Qwen : comment les LLM locaux se débrouillent en code sur un MacBook M4 Pro

Les modèles de langage locaux peuvent déjà servir à écrire et à modifier du code sans envoyer les sources dans le cloud, mais le confort dépend encore beaucoup de la tâche et de la marge matérielle. Une expérience sur un MacBook Pro avec M4 Pro et 48 Go de mémoire montre que l'association de LM Studio et de modèles modernes à poids ouverts donne déjà un résultat solide en mode chat, mais qu'avec de vrais agents, elle se heurte vite à la mémoire, à la chauffe et au temps d'exécution. Le point de départ est simple : les modèles cloud sont pratiques, mais ils ont des limites, dépendent du réseau et, principal défaut pour beaucoup de développeurs, les données, le code et les prompts partent vers des serveurs distants.

L'exécution locale promet confidentialité et contrôle total, mais impose de comprendre comment le modèle consomme la RAM et la VRAM, combien de mémoire reste pour le contexte et en quoi des formats comme GGUF et MLX diffèrent. Les tests ont été menés sur un MacBook Pro à puce M4 Pro avec 48 Go de mémoire unifiée, où le CPU et le GPU se partagent un même pool de mémoire. Cela permet de loger des modèles plus gros, mais signifie aussi que le modèle se dispute les ressources avec l'IDE, Docker et des dizaines d'onglets de navigateur.

Une partie distincte de l'analyse porte sur le choix du modèle selon le matériel. L'auteur conseille de regarder non seulement la taille en milliards de paramètres, mais aussi la spécialisation, la quantification, la prise en charge du function calling et le type d'architecture. Pour le code, il a retenu Qwen3-Coder 30B A3B Instruct en variantes MLX et GGUF, et l'a comparé à Qwen3-Coder Next, Qwen3.

5, Nvidia Nemotron-3 Nano et Gemma 4 26B A4B. L'article explique bien le sens pratique des sigles : par exemple, A3B renvoie à l'approche MoE, où seule une partie des paramètres d'un grand modèle est activée, si bien que la vitesse se rapproche de celle des petits modèles et la qualité de celle des plus gros. LM Studio a été choisi comme environnement d'exécution : il permet de télécharger facilement le modèle, de lancer un serveur local, d'activer CORS et de connecter des agents comme Claude Code, Open Code, Kilo Code et Aider.

La prévision de performance pour Qwen3-Coder annonçait environ 150 tokens par seconde, mais la mesure réelle dans LM Studio s'est établie plutôt autour de 82 tokens par seconde, ce qui ramène aussitôt la discussion de la théorie à la pratique.

Le plus intéressant commence avec les mesures. En mode chat classique, les modèles locaux ne ressemblent plus à un jouet, mais à un compromis de travail. Qwen3-Coder 30B A3B Instruct en MLX 4bit a bouclé l'ensemble du scénario en trois étapes en environ 2 minutes 9 secondes et atteint une note finale de 8,5 sur 10.

Gemma 4 26B A4B en GGUF a montré l'un des meilleurs équilibres : environ 2 minutes 23 secondes et un 10 sur 10 final. Les modèles qui raisonnent davantage ont donné de meilleurs résultats, mais au prix du temps : Qwen3.5 35B A3B a atteint 10 sur 10 en environ 5 minutes 43 secondes, et Qwen3.

5 27B a traîné jusqu'à presque une demi-heure. La conclusion de cette partie est sobre : en vitesse de réponse, les modèles locaux sont par endroits déjà comparables à ceux du cloud, surtout sans mode de réflexion, mais, dans le même temps, ils leur cèdent plus souvent en qualité. En revanche, les MoE récents paraissent nettement plus pratiques que les variantes denses.

En mode agent, le tableau change brutalement. Le contexte grossit, le nombre d'appels augmente, et les secondes deviennent des minutes, voire des dizaines de minutes. Aider avec le même Qwen3-Coder MLX 4bit a terminé le scénario en 2 minutes 50 secondes avec une note de 9,5, Open Code en 7 minutes 33 secondes avec un 9, mais Kilo Code avec ce même modèle a pris 15 minutes 5 secondes et n'a obtenu que 6 points.

Avec le Qwen3.5 35B A3B, plus lourd, Kilo Code a déjà tourné 57 minutes 3 secondes, même si la qualité finale est montée à 9 sur 10. Claude Code avec Gemma 4 26B a terminé l'expérience avec la note maximale de 10 sur 10, mais a consommé 21 minutes 14 secondes au total, et l'association Claude Code et Qwen3-Coder plantait tout simplement faute de mémoire pour le contexte.

En parallèle, le portable souffrait visiblement : le GPU chauffait jusqu'à environ 100 degrés, les ventilateurs ne se taisaient presque jamais et le swap gonflait par endroits jusqu'à 20 Go. Dans ce contexte, les agents cloud étaient tout simplement plus confortables : par exemple, Kilo Code avec Qwen3.5 Plus a donné 9 sur 10 en 6 minutes 53 secondes, et Claude Opus 4.

6 un 10 sur 10 en 12 minutes 15 secondes, mais en payant.

Le bilan est simple : les LLM locaux peuvent déjà être envisagés sérieusement pour le chat privé, les tâches ponctuelles de refactoring et les scénarios simples où le contrôle des données compte plus que la vitesse absolue. Mais si l'on veut un mode agent permanent sur un portable de travail, surtout à côté de l'IDE, du navigateur et de Docker, la pile locale reste pour l'instant un compromis. Le scénario le plus raisonnable tiré de cette expérience : prendre des MoE récents, utiliser des agents plus simples comme Aider ou Open Code et, si possible, déporter le modèle local sur une machine séparée, comme un Mac mini.