Dans mon premier article sur l’IA locale, je laissais les LLM sur un bilan mitigé : certains modèles me semblaient capables de choses intéressantes, mais trop lents pour mon travail quotidien. Voici de quoi mettre des résultats concrets derrière cette impression, avec deux tâches confiées à plusieurs modèles sur un projet PHP que je connais très bien.
La machine reste la même, je le précise pour ceux qui voudraient comparer les performances avec une autre référence précise de machine : un Mac mini M4 Pro, CPU 14 cœurs, GPU 20 cœurs et 48 Go de mémoire unifiée. Pour ces essais, j’ai retenu OpenCode 2 comme outil de codage et oMLX comme moteur d’inférence pour les modèles locaux. Ce choix a notamment été guidé par leur excellente gestion du cache LLM : éviter de retraiter du contexte déjà envoyé au modèle est un élément clé dans la performance finale. Quand une tâche enchaîne les lectures de fichiers et les appels d’outils, un problème de cache peut rendre un modèle inutilisable. L’utilisation de Pi ou Claude Code comme harnais et d’Ollama ou LM Studio côté moteur d’inférence donnerait des résultats nettement différents.1
Les modèles retenus pour le test
Je suis parti de Qwen3.8 27B, la star du moment, puis j’ai élargi la sélection en cherchant un meilleur compromis entre qualité et durée. Les attentes étaient les suivantes :
- Qwen3.8 27B, en effort medium : la référence du LLM local constitue mon point de départ. Je sais déjà qu’il peut être assez bavard (donc lent), c’est pourquoi j’utilise le niveau d’effort « medium ».
- Swift 1.5 27B, en efforts medium et low : j’ai repéré cette variante de Qwen pour son fil de pensée annoncé plus court. L’idée est de voir combien de temps cela fait gagner, et à quel point cela affecte la qualité du résultat.
- Bonsai 2 27B, en version ternaire : sa plus petite empreinte mémoire me faisait espérer une exécution plus rapide. Je voulais aussi voir si cette variante conservait les capacités du Qwen dont elle est dérivée, selon ma compréhension du modèle. Malheureusement, les options d’optimisation disponibles pour les modèles précédents ne sont pas possibles avec ce modèle.
- Ornith 1.5 35B-A3B et LFM2.5 24B-A2B : après les premiers résultats encourageants de Qwen, j’ai voulu essayer des modèles que je supposais moins capables, mais beaucoup plus rapides. Si ces modèles sont capables d’atteindre un niveau de qualité suffisant, leur performance sera un atout certain.
J’ai ajouté GPT-6.1 Sol en effort medium comme point de comparaison non local. Il ne tourne évidemment pas sur le Mac ni dans oMLX. Au total, cela donne cinq modèles locaux, dont Swift essayé avec deux niveaux d’effort différents.
Les variantes exactes utilisées et leurs paramètres (obtenus via les recommandations officielles de leur page HuggingFace)
Qwen3.8-27B-oQ4e-mtp
temp: 1, top_p: 0.95, top_k: 20, min_p: 0,rep_penalty: 1, presence_penalty: 0
Lightning MTP : 3 tokens, TurboQuant KV Cache: 8-bitSwift-1.5-Qwen3.8-27b-oQ4e-mtptemp: 1, top_p: 0.95, top_k: 20, min_p: 0,rep_penalty: 1, presence_penalty: 0
Lightning MTP : 3 tokens, TurboQuant KV Cache: 8-bitTernary-Bonsai-2-27B-mlx-2bittemp: 1, top_p: 0.95, top_k: 20, min_p: 0,rep_penalty: 1, presence_penalty: 0Ornith-1.5-35B-A3B-oQ4e-mtptemp: 0.7, top_p: 0.95, top_k: 20,min_p: 0,rep_penalty: 1LFM2.5-24B-A2B-oQ5etemp: 0.1, top_p: 1, top_k: 50, min_p: 0,rep_penalty: 1.05, presence_penalty: 0
Le test : deux tâches à réaliser sur un projet que je connais bien
Afin d’évaluer la qualité de raisonnement des différents modèles, je les confronte à un projet web que j’ai développé sans IA avec une architecture et des design patterns assez classiques mais n’utilisant pas un framework connu existant. L’accès aux données se fait également par une API plutôt originale que les modèles n’auront probablement pas directement dans leurs connaissances (l’API FileMaker Server est très peu répandue et spécifique à ce projet).
Première tâche : comprendre le projet
La première demande consiste donc à explorer le dépôt puis à rédiger un fichier AGENTS.md, destiné à guider les prochaines interventions sur le code. Le document doit expliquer le rôle de l’application, son organisation, ses mécanismes internes et ses données, en renvoyant aux fichiers et aux symboles concernés. J’ai donné une consigne de longueur entre 800 et 1 200 mots.
Quand j’ai utilisé pour la première fois Claude Code, en juillet 2025, la première tâche que je lui avais confié était la même et il m’avait épaté : il avait tout compris au projet en une dizaine de minutes… est-ce que les modèles locaux seront au niveau ?
Pour évaluer le résultat, je me suis fixé d’avance un barème un peu arbitraire : Exactitude technique (30 points), compréhension et couverture (25), utilité pour intervenir (20), références au code et distinction entre faits et incertitudes (15), concision et respect des consignes (10)
Deuxième tâche : implémenter une fonctionnalité
Après la rédaction du fichier AGENTS.md, je lui demande d’implémenter une fonctionnalité simple qui nécessite cependant d’éditer à la fois une vue, un contrôleur et la couche modèle de données, en s’adaptant à la structure existante et à l’API qu’il ne connait initialement pas.
Mon barème arbitraire pour cette tâche : Parcours fonctionnel (40 points), intégration des données (20), validation et gestion des erreurs (20), protections (10), intégration dans le code existant (10)
Je n’avais pas prévu une difficulté d’évaluation : certains modèles ont eu l’idée de me poser une question assez pertinente sur les droits d’accès souhaités, ça mériterait peut-être des points bonus (pour Qwen et Ornith).
Les résultats
Quelques remarques préliminaires : LFM2.5 n’a pas réalisé la seconde tâche. Dans l’association oMLX–LFM2.5–OpenCode que j’ai testée, le cache ne s’est jamais déclenché. Le problème pénalisait suffisamment les performances pour que j’abandonne le test pour ce modèle, sans avoir identifié sa cause. Comme la qualité du résultat pour la tâche 1 n’était pas au rendez-vous, je n’ai pas insisté.
En ce qui concerne le temps passé par les autres modèles locaux sur la tâche 2 : ils ont tous eu besoin de compacter le contexte une fois pendant la deuxième tâche (le contexte max. était de 120k tokens).
Une seule exécution a été évaluée par configuration et par tâche. La première tâche a été évaluée en cachant les noms des modèles et en les mélangeant ; la seconde tâche n’était pas anonymisée. Pour le code, il s’agit d’une revue et d’un contrôle syntaxique, sans validation fonctionnelle de l’application.
| Modèle | Analyse /100 | Durée tâche 1 | Code /100 | Durée tâche 2 | Appréciation qualité / temps |
|---|---|---|---|---|---|
| GPT-6.1 Sol — medium, non local | 94 | 3 min 06 s | 94 | 4 min 23 s | La comparaison est injuste ! |
| Swift 1.5 27B — medium | 81 | 29 min 51 s | 77 | 41 min 13 s | Compromis local le plus convaincant de ces essais, mais une attente importante. |
| Qwen3.8 27B — medium | 80 | 50 min | 69 | 52 min 10 s | Bonne analyse du dépôt ; implémentation encore perfectible et longues durées. |
| Ornith 1.5 35B-A3B | 72 | 14 min 39 s | 47 | 28 min 08 s | Le plus rapide en local, mais le code livré nécessite des corrections. |
| Bonsai 2 27B — ternary | 67 | 45 min 13 s | 45 | 1 h 15 min | Attente très longue pour une qualité en retrait ; petite erreur dans le code livré. |
| Swift 1.5 27B — low | 75 | 34 min 28 s | 32 | 37 min 51 s | Une erreur dans l’implémentation en confondant deux variables, sans gain sur le temps cumulé face au medium. |
| LFM2.5 24B-A2B | 44 | 26 min 25 s | — | — | Analyse peu fiable ; abandon après la première tâche en raison du problème de cache. |
Ce que ces essais font ressortir
Swift en effort medium est clairement le gagnant. Il reste très proche de Qwen pour l’analyse du projet et obtient une meilleure note pour la modification du code, en prenant moins de temps sur les deux tâches. Pour bien interpréter les notes attribuées par mon barème, je dirais que la qualité obtenue dès le premier jet est tout à fait satisfaisante au delà de 65/100. Le réglage effort low n’a pas apporté le gain de temps attendu pour une qualité de résultat nettement inférieure…
Les statistiques d’oMLX donnent aussi un éclairage intéressant : Swift medium a produit environ 25 100 tokens sur les deux tâches, contre 42 100 pour Qwen. Leur débit moyen de génération est autour de 11,5 tokens par seconde (À taille de contexte égale, leur débit est identique : il atteint 25 tok/s quand le contexte est vide, puis diminue au fil de la génération). C’est la quantité de tokens nécessaire qui fait varier le temps d’attente quand on compare ces modèles ayant la même architecture. Il faudrait atteindre un débit d’au moins 50 tok/s pour utiliser confortablement un modèle.
Le test de Qwen sur la tâche 1 donne un exemple assez parlant du temps qui peut être perdu par un modèle trop bavard. Au bout d’environ trente minutes, il avait produit un résultat tout à fait satisfaisant. Mais il a ensuite passé vingt minutes à raccourcir le document, en plusieurs passes, de 1270 mots à moins de 1200 afin de bien respecter ma consigne de longueur.
Bonsai m’a déçu sur la vitesse : avec sa petite empreinte mémoire, j’espérais obtenir des résultats plus rapides. Malheureusement, son architecture un peu différente des modèles plus répandus ne peut pas profiter des mêmes optimisations (Lightning MTP indisponible, quantification du cache KV qui réduit trop la qualité du résultat). Il ne sera intéressant que si votre configuration dispose de moins de mémoire.
Seuls Swift 1.5 27B medium et Qwen3.8 27B medium ont livré un code ne nécessitant pas une seconde passe de correction. C’est impressionnant de leur part… il y a quelques mois, je n’aurais pas cru cela possible. Les modèles dérivés de Qwen3.8 ont aussi tenté de réaliser des tests de validation du résultat (mais le projet fourni ne pouvait malheureusement pas être testé sans son accès à FileMaker, indisponible ici). Cela relègue les modèles plus petits loin derrière.
Si j’en reviens à ma découverte de Claude Code en juillet 2025, lorsque je lui avais confiée la même tâche d’analyse du projet… je dois avouer que je suis vraiment épaté par le résultat de Qwen3.8 et de Swift1.5 : ils me semblent qualitativement encore meilleurs. C’est une appréciation de mémoire, pas une comparaison contrôlée avec le modèle de l’époque (Sonnet 4 ou peut-être Opus 4), mais elle explique pourquoi ces essais restent encourageants malgré la lenteur.
Quarante minutes, c’est trop long ?
Pour mon travail quotidien, ces essais ne changent pas encore le constat que je faisais la dernière fois : GPT-6.1 fait mieux et beaucoup plus vite, et l’attente reste difficilement praticable sur M4 Pro (surtout que pendant que le LLM local travaille, je dois laisser le maximum de RAM disponible pour lui). Le modèle Swift1.5 medium est néanmoins une piste locale intéressante.
Malgré la qualité encourageante que j’ai observée aujourd’hui, je vais attendre de nouveaux modèles ou des optimisations du moteur d’inférence avant de poursuivre ce genre de tests. La donne changera certainement après la sortie de nouveaux processeurs également.
Prochaine étape : trouver des tâches plus simples ou avec plus d’autonomie pour profiter de cette “intelligence” lorsque je ne suis pas devant mon poste à attendre son résultat ?
- Pour vous en convaincre, consultez l’excellente vidéo “10 harnais IA locale testés : la RÉDEMPTION d’OpenCode 2.0” réalisée par le développeur d’un harnais dédié à la bonne gestion du cache. Il rentre dans le détail très précis. Je pensais éviter OpenCode à cause de son précédent test mais les soucis de gestion du cache de la v1 sont largement résolus dans la v2 ↩︎