Meilleurs LLM pour OpenCode - Testés en local

J’ai testé le fonctionnement d’OpenCode avec plusieurs modèles LLM hébergés localement via Ollama, et pour comparaison, j’ai ajouté certains modèles gratuits provenant d’OpenCode Zen.

OpenCode est l’un des outils les plus prometteurs de l’écosystème des outils de développement IA actuel.

TL;DR - Meilleurs LLMs pour OpenCode

Le vainqueur clair pour le local : Qwen 3.5 27b Q3_XXS sur llama.cpp

La version de 27b avec une quantification IQ3_XXS a fourni un projet Go complet et fonctionnel avec les 8 tests unitaires passant, un README complet, et une vitesse de 34 tokens/sec sur ma configuration 16 Go de VRAM (mix CPU+GPU). Cinq étoiles, sans réserve. C’est mon outil de prédilection pour les sessions OpenCode locales.

Qwen 3.5 35b sur llama.cpp — rapide pour le codage, mais à valider systématiquement

Le modèle 35b est excellent pour les tâches de codage agentique rapides — mais mes tests de carte de migration ont révélé un problème de fiabilité sérieux. Sur deux exécutions IQ3_S, il a produit 63–73 % de divergences de slugs, et dans la quantification IQ4_XS, il a oublié d’inclure les slugs de page entièrement, générant des chemins de catégorie qui maperaient 8 pages différentes vers la même URL. La qualité de codage sur la tâche IndexNow était réellement bonne, donc ce modèle vaut la peine d’être utilisé — mais ne jamais faire confiance à sa sortie sur des tâches structurées et respectueuses des règles sans vérification. La validation n’est pas optionnelle.

Surprenant : Bigpicle (d’OpenCode Zen)

Le plus rapide pour achever la tâche — 1 min 17 s. Plus important encore, c’était le seul modèle qui a fait une pause avant de coder pour rechercher véritablement la spécification du protocole IndexNow en utilisant Exa Code Search. Il a trouvé tous les points de terminaison (endpoints) corrects dès la première tentative. Si vous avez accès à OpenCode Zen, celui-ci surpasse largement ses attentes.

Bon, mais seulement avec un mode de réflexion élevé : GPT-OSS 20b

En mode par défaut, GPT-OSS 20b échoue — il rencontre des appels WebFetch aboutissant à une impasse et s’arrête. Passez en mode de réflexion élevé et il devient un assistant de codage réellement capable : analyse de drapeaux complète, logique de mise en lot correcte, tests unitaires passant, le tout fait rapidement. Gardez cela à l’esprit avant de le rejeter. GPT-OSS 20b a échoué sur les tâches structurées même en mode élevé.

À éviter pour le codage agentique : GPT-OSS 20b (par défaut), Qwen 3 14b, devstral-small-2:24b

Ceux-ci étaient autrefois mes préférés pour la vitesse dans les tâches de chat et de génération. Mais en mode agentique, ils ont tous de vrais problèmes. Qwen 3 14b hallucine de la documentation plutôt que d’admettre qu’il ne peut pas trouver quelque chose. GPT-OSS 20b (par défaut) se bloque lorsque WebFetch échoue. Devstral se perd avec des opérations de fichier basiques. Pour OpenCode spécifiquement, la qualité du suivi des instructions et de l’appel d’outils est bien plus importante que la vitesse brute.

À propos de ce test

J’ai soumis à chaque modèle exécuté dans opencode deux tâches/prompts :

1. Créez pour moi un outil CLI en Go qui appellerait les points de terminaison IndexNow de Bing et d'autres moteurs de recherche pour notifier des changements sur mon site.
2. Préparer une carte de migration de site.

Vous savez ce qu’est le protocole Indexnow, n’est-ce pas ?

Pour la deuxième tâche, j’ai un plan de migration de certains anciens posts sur ce site depuis le format d’URL de blog (par exemple https://www.glukhov.org/post/2024/10/digital-detox/) vers des clusters thématiques (comme l’URL de cet article : https://www.glukhov.org/ai-devtools/opencode/llms-comparison/). J’ai donc demandé à chaque LLM sur OpenCode de préparer une carte de migration pour moi, selon ma stratégie.

J’ai exécuté la plupart des LLMs sur Ollama hébergé localement, et certains autres sur llama.cpp hébergé localement. Bigpicle et d’autres très grands modèles de langage provenaient d’OpenCode Zen.

Résultats de chaque modèle

qwen3.5:9b

Échec complet sur la première tâche. Le modèle a suivi son processus de réflexion — identifiant correctement les services pertinents (Google Sitemap, Bing Webmaster, Baidu IndexNow, Yandex) — mais n’a jamais réellement appelé d’outils. Il a produit un résumé “Build” sans toucher à un seul fichier. Aucun appel d’outil du tout.

qwen3.5:9b-q8_0

Un pas vers le haut par rapport à la quantification par défaut : il a au moins créé un go.mod et un main.go. Mais ensuite, il est immédiatement bloqué, a admis qu’il devait ajouter des imports manquants, a essayé de réécrire tout le fichier en utilisant un heredoc shell — et a échoué. Le temps de construction était de 1 min 27 s pour quelque chose qui ne fonctionnait pas.

Qwen 3 14b

Hallucination classique sous la pression. Il a essayé de récupérer la documentation IndexNow trois fois de suite, chaque fois rencontrant un 404 d’une URL incorrecte (github.com/Bing/search-indexnow). Plutôt que d’admettre qu’il ne pouvait rien trouver, il a fabriqué une réponse qui semblait confiante — mauvais point de terminaison API, mauvaise méthode d’authentification. Quand je l’ai poussé à rechercher à nouveau, il a produit une deuxième réponse fabriquée pointant vers une autre URL qui renvoyait aussi un 404. Les informations qu’il a rapportées étaient incorrectes. C’est le mode d’échec que je veux le plus éviter.

GPT-OSS 20b

Au moins, le comportement était honnête et méthodique. Il a tenté une longue chaîne d’appels WebFetch — indexnow.org, divers dépôts GitHub, les pages propres de Bing — et a rencontré des 404 ou des blocages Cloudflare sur presque tout. Il a documenté chaque échec de manière transparente. En fin de compte, il n’a toujours pas pu rassembler assez d’informations pour construire un outil fonctionnel, mais contrairement à Qwen 3 14b, il n’a rien inventé. Il n’a simplement pas pu pousser jusqu’au bout.

GPT-OSS 20b (pensée élevée)

Une histoire significativement différente du mode par défaut. Avec la pensée élevée activée, le modèle s’est remis des mêmes appels de récupération en impasse et a réussi à construire un outil complet et fonctionnel — avec une analyse de drapeaux appropriée (--file, --host, --key, --engines, --batch, --verbose), des GET pour des URL uniques et des POST par lots pour plusieurs, selon la spécification IndexNow.

Quand je lui ai demandé la documentation et les tests unitaires, il a livré les deux. Les tests ont réussi :

=== RUN   TestReadURLsFile
--- PASS: TestReadURLsFile (0.00s)
=== RUN   TestReadURLsNoProtocol
--- PASS: TestReadURLsNoProtocol (0.00s)
ok  	indexnow-cli	0.002s

Rapide aussi — construction initiale en 22,5 s. La pensée élevée rend gpt-oss:20b réellement utilisable.

qwen3-coder:30b

L’échec le plus intéressant. Il a en fait compilé et exécuté l’outil contre de vrais points de terminaison, a vu de vraies erreurs API revenir de Bing, Google et Yandex, et a commencé à les corriger :

Error notifying Bing: received status code 400 ... "The urlList field is required."
Error notifying Google: received status code 404 ...
Error notifying Yandex: received status code 422 ... "Url list has to be an array"

C’est un bon instinct. Le problème : il tournait à 720 % CPU et seulement 7 % GPU — extrêmement inefficace pour un modèle de 22 Go. Cela a pris 11 min 39 s et la sortie finale était toujours “pas tout à fait ce qui était attendu”. Il a également créé un README.md, ce qui est une touche agréable. Pas un mauvais modèle, juste très lent sur ma configuration et il n’a pas totalement maîtrisé le format du protocole IndexNow.

qwen3.5:35b (Ollama)

Résultats solides mais lents. Il a créé un projet Go approprié, a écrit des tests, et tous ont réussi :

=== RUN   TestHashIndexNowPublicKey/non-empty_key
--- PASS
=== RUN   TestGetPublicKeyName/standard_root
--- PASS
=== RUN   TestGetPublicKeyName/custom_root
--- PASS

L’inconvénient : temps de construction de 19 min 11 s. Pour un modèle de 27 Go tournant avec une répartition CPU/GPU de 45%/55 %, c’est trop lent pour une utilisation interactive. La qualité est là, mais la latence tue le flux de travail.

Bigpicle (big-pickle)

Le performer en vue pour la première tâche. Avant d’écrire une seule ligne de code, il a utilisé Exa Code Search pour rechercher réellement le protocole IndexNow :

◇ Exa Code Search "IndexNow protocol API endpoint how to notify search engines"

Et il a trouvé les bons points de terminaison :

• Global : https://api.indexnow.org/indexnow
• Bing : https://www.bing.com/indexnow
• Yandex : https://webmaster.yandex.com/indexnow
• Yep : https://indexnow.yep.com/indexnow
• Amazon : https://indexnow.amazonbot.amazon/indexnow

Il a résolu proprement le problème d’import cobra (go mod tidy), et l’outil a été terminé en 1 min 17 s. La réponse de limitation de débit qu’il a reçue de Bing pendant les tests était en fait un comportement attendu pour une clé de test invalide — le modèle a correctement identifié cela comme “l’outil fonctionne”. Impressionnant.

devstral-small-2:24b

S’est trompé à un niveau basique : il a essayé d’écrire des commandes shell (go mod init indexnowcli, go mod tidy) directement dans le fichier go.mod, déclenchant des erreurs de parsing. D’une manière ou d’une autre, il a quand même réussi à construire un binaire (7,9 Mo), mais le CLI résultant était trop simple — juste indexnowcli <url> <key> sans gestion de drapeaux, sans support multi-moteur, rien. Cela a pris 2 min 59 s + 1 min 28 s pour obtenir un outil qui n’était pas vraiment utile.

qwen3.5:27b (llama.cpp, quantification IQ3_XXS)

C’est celui qui m’a le plus impressionné parmi tous les exécutables locaux. Exécuté comme Qwen3.5-27B-UD-IQ3_XXS.gguf sur llama.cpp (majoritairement CPU), il a créé un outil complet avec une couverture de test complète — les 8 tests passant — et un README approprié avec des instructions d’installation et une explication du protocole :

PASS    indexnow    0.003s

Moteurs pris en charge : Bing, Yandex, Mojeek, Search.io. Temps de construction : 1 min 12 s pour l’outil, 1 min 27 s pour les tests et la documentation. Vitesse : 34 tokens/sec. Qualité : 5 étoiles. Résultat incroyable pour un modèle quantifié tournant sur CPU+GPU.

qwen3.5:35b (llama.cpp, quantification IQ3_S)

Exécuté comme Qwen3.5-35B-A3B-UD-IQ3_S.gguf sur llama.cpp. Mes notes ici sont courtes : “excellent !” — ce qui dit tout. Le modèle plus grand au même niveau de quantification a fourni des résultats au moins aussi bons que la variante 27b, sinon meilleurs.

Résultats de la carte de migration

Pour la deuxième tâche, j’ai exécuté un lot séparé — 7 modèles, tous ayant reçu les mêmes instructions, structure de site et liste de pages. La contrainte était explicite : le slug (segment de chemin final) doit rester le même. Par exemple, /post/2024/04/reinstall-linux/ doit devenir /.../reinstall-linux/, et non autre chose.

J’ai mesuré le nombre de divergences de slug produites par chaque modèle — cas où le slug cible généré différait du slug source.

Modèle	Lignes	Divergences de slug	Taux d’erreur
minimax-m2.5-free	80	4	5.0%
Nemotron 3	78	4	5.1%
Qwen 3.5 27b Q3_XXS (llama.cpp)	80	4	5.0%
Qwen 3.5 27b Q3_M (llama.cpp)	81	6	7.4%
Bigpicle	81	9	11.1%
mimo-v2-flash-free	80	42	52.5%
Qwen 3.5 35b IQ3_S - deuxième exécution (llama.cpp)	81	51	63.0%
Qwen 3.5 35b IQ4_XS (llama.cpp)	80	79	98.8%

Une chose que tous les 7 modèles ont faite de manière identique : les anciennes URL au format 2022 avaient un préfixe de mois intégré dans le slug (par exemple, /post/2022/06-git-cheatsheet/ → slug 06-git-cheatsheet). Chaque modèle a supprimé ce préfixe et utilisé git-cheatsheet comme nouveau slug. Cela représente 4 divergences cohérentes dans les trois meilleurs modèles — donc leur baseline est de 4 erreurs chacun, et non zéro.

La véritable divergence commence au-dessus de cette baseline. minimax-m2.5-free, Nemotron 3 et Qwen 3.5 27b Q3_XXS n’ont violé la règle du slug que sur ces 4 chemins hérités — rien d’autre. Qwen 3.5 27b Q3_M en a ajouté 2 de plus (a renommé le slug de l’article cognee et a minuscule Base64). Bigpicle en a ajouté 5 de plus sur les 4, principalement en raccourcissant les longs slugs.

Les valeurs aberrantes sont dans une catégorie différente. Qwen 3.5 35b IQ3_S a systématiquement réécrit les slugs à partir des titres de page plutôt que de préserver la source (par exemple, executable-as-a-service-in-linux → run-any-executable-as-a-service-in-linux, file-managers-for-linux-ubuntu → context-menu-in-file-managers-for-ubuntu-24). La deuxième exécution était légèrement meilleure (51 contre 59) mais montrait le même comportement. Il a également halluciné un chemin source : il a discrètement changé comparing-go-orms-gorm-ent-bun-sqlc en comparing-go-orms-gorm-ent-bun-sql (suppression du c), donc les deux côtés de cette ligne s’accordaient entre eux — mais étaient tous les deux faux. mimov2 était tout aussi agressif pour raccourcir : gnome-boxes-linux-virtual-machines-manager → gnome-boxes, vm-manager-multipass-cheatsheet → multipass.

La quantification IQ4_XS du 35b est une catégorie d’échec totalement différente : 98,8 % de divergences de slug — mais le problème n’est pas des slugs incorrects, c’est que le modèle a oublié d’inclure les slugs du tout. Au lieu de /new-section/page-slug/, il a produit des chemins de catégorie comme /developer-tools/terminals-shell/ et /rag/architecture/. Huit pages source ont fini par être mappées vers /developer-tools/terminals-shell/ — toutes pointant vers la même URL, ce qui serait catastrophique si utilisé. /developer-tools/ seul a collecté cinq pages distinctes. La sortie est complètement inutilisable.

Pour cette tâche, le modèle Qwen 3.5 27b Q3_XXS quantifié plus petit a égalé les meilleurs performers — tandis que deux quantifications de 35b ont échoué lamentablement, chacune à sa manière.

Conclusion

Je suis heureux d’exécuter à la fois Qwen 3.5 35b et Qwen 3.5 27b localement sur llama.cpp avec des poids quantifiés — les contraintes matérielles sont réelles (16 Go de VRAM signifie des quantifications IQ3/IQ4), mais le flux de travail est solide.

Le 27b Q3_XXS est le conducteur quotidien fiable. Il suit les instructions avec précision, produit une sortie complète et est assez rapide pour une utilisation interactive. Sur la tâche de carte de migration, il a égalé les meilleurs modèles cloud.

Le 35b est capable mais imprévisible sur les tâches structurées. Pour le codage ouvert — écris-moi un outil, construis ceci — il performe bien. Mais lorsque la tâche a des règles strictes (comme “le slug doit rester le même”), il hallucine librement sur toutes les quantifications que j’ai testées : réécrivant les slugs à partir des titres, supprimant complètement les slugs, voire modifiant discrètement les chemins sources pour faire paraître sa sortie incorrecte cohérente. Si vous utilisez le 35b pour quelque chose qui produit une sortie structurée que vous prévoyez d’utiliser directement, intégrez une étape de validation dans votre flux de travail. Ne supposez pas que la sortie est correcte simplement parce qu’elle semble plausible.

Si vous êtes curieux de la vitesse à laquelle ces LLMs fonctionnent, consultez Meilleurs LLMs pour Ollama sur GPU 16GB VRAM.