LM Studio et Qwen : comment les LLMs locaux gèrent la programmation sur MacBook M4 Pro

Les modèles de langage locaux peuvent déjà être utilisés pour écrire et éditer du code sans envoyer le code source vers le cloud, mais le confort d'un tel travail dépend toujours beaucoup de la tâche et du matériel disponible. Une expérience sur un MacBook Pro avec M4 Pro et 48 GB de mémoire montre que la combinaison de LM Studio et des modèles modernes avec des poids ouverts fournit déjà des résultats tangibles en mode chat, mais en mode agent complet, elle se heurte rapidement aux limitations de mémoire, à la chaleur et au temps d'exécution. Le point de départ ici est simple : les modèles cloud sont pratiques, mais ils ont des limitations, une dépendance au réseau et le principal inconvénient pour de nombreux développeurs — les données, le code et les prompts sont envoyés aux serveurs distants.

L'exécution locale promet la confidentialité et le contrôle total, mais nécessite de comprendre comment un modèle consomme la RAM et la VRAM, combien de mémoire reste pour le contexte et comment les formats comme GGUF et MLX diffèrent. Les tests ont été menés sur un MacBook Pro avec puce M4 Pro et 48 GB de mémoire unifiée, où le CPU et le GPU partagent un pool de mémoire commun. Cela aide à accueillir des modèles plus grands, mais signifie simultanément que le modèle entre en concurrence pour les ressources avec l'IDE, Docker et des dizaines d'onglets du navigateur.

Une partie distincte de l'analyse se concentre sur le choix d'un modèle pour le matériel. L'auteur suggère de ne pas seulement regarder la taille en milliards de paramètres, mais aussi la spécialisation, la quantification, le support des appels de fonction et le type d'architecture. Pour la programmation, il a utilisé Qwen3-Coder 30B A3B Instruct dans les variantes MLX et GGUF, et l'a également comparé avec Qwen3-Coder Next, Qwen3.

5, Nvidia Nemotron-3 Nano et Gemma 4 26B A4B. L'article explique bien la signification pratique des abréviations : par exemple, A3B indique une approche MoE, où seule une partie des paramètres d'un grand modèle sont activés, ce qui rend la vitesse plus proche des petits modèles tandis que la qualité s'approche de celle des modèles plus grands. LM Studio a été choisi comme runtime : via celui-ci, les modèles sont facilement téléchargés, un serveur local est configuré, CORS est activé et des agents comme Claude Code, Open Code, Kilo Code et Aider peuvent être connectés.

La prévision de performance pour Qwen3-Coder promettait environ 150 tokens par seconde, mais la mesure réelle dans LM Studio s'est avérée être plus proche de 82 tokens par seconde, ce qui ramène immédiatement la conversation de la théorie à la pratique. La partie la plus intéressante commence par les mesures. En mode chat normal, les modèles locaux ne ressemblent plus à un jouet mais à un compromis fonctionnel.

Qwen3-Coder 30B A3B Instruct en MLX 4bit s'est adapté à environ 2 minutes 9 secondes pour tout le scénario en trois étapes et a atteint une note finale de 8,5 sur 10. Gemma 4 26B A4B en GGUF a montré un des meilleurs équilibres : environ 2 minutes 23 secondes et une note finale de 10 sur 10. Les modèles plus réfléchis 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, tandis que Qwen3.5 27B s'est étendu jusqu'à presque la demi-heure. La conclusion de cette partie est sobre : les modèles locaux correspondent déjà parfois aux modèles cloud en termes de vitesse de réponse, particulièrement sans mode de réflexion, mais sur le même laps de temps, ils accusent souvent du retard en qualité.

Pendant ce temps, les modèles MoE récents semblent notablement plus pratiques que les variantes denses. En mode agent, le panorama change radicalement. Le contexte augmente, le nombre d'appels augmente, et les secondes se transforment en minutes ou même en dizaines de minutes.

Aider avec le même Qwen3-Coder MLX 4bit a complété le scénario en 2 minutes 50 secondes avec une note de 9,5, Open Code en 7 minutes 33 secondes avec une note de 9, mais Kilo Code avec le même modèle a pris 15 minutes 5 secondes et n'a atteint que 6 points. Avec le plus lourd Qwen3.5 35B A3B, Kilo Code a pris 57 minutes 3 secondes, bien que la qualité finale se soit améliorée à 9 sur 10.

Claude Code avec Gemma 4 26B a terminé l'expérience avec une note maximale de 10 sur 10, mais a dépensé un total de 21 minutes 14 secondes, et la combinaison Claude Code avec Qwen3-Coder a réellement échoué en raison d'une mémoire insuffisante pour le contexte. En parallèle, l'ordinateur portable a souffert notablement : le GPU s'est chauffé à environ 100 degrés, les ventilateurs s'arrêtaient à peine, et l'espace d'échange dans certains scénarios s'est gonflé jusqu'à 20 GB. Face à cela, les agents cloud semblaient trivialement plus pratiques : par exemple, Kilo Code avec Qwen3.

5 Plus a donné 9 sur 10 en 6 minutes 53 secondes, et Claude Opus 4.6 — 10 sur 10 en 12 minutes 15 secondes, quoique moyennant frais. La conclusion est simple : les LLMs locaux peuvent maintenant être sérieusement considérés pour le chat privé, les tâches uniques de refactorisation et les scénarios simples où le contrôle des données importe plus que la vitesse absolue.

Mais si vous avez besoin d'un mode agent constant sur un ordinateur portable de travail, particulièrement aux côtés de l'IDE, du navigateur et de Docker, la pile locale reste un compromis. Le scénario le plus raisonnable de cette expérience est d'utiliser des modèles MoE récents, d'utiliser des agents plus simples comme Aider ou Open Code, et quand c'est possible, d'exécuter le modèle local sur une machine séparée comme Mac mini.