J'ai teste 7 modeles IA locaux. J'en ai garde 1.

Meta description : Benchmark complet de 7 modeles LLM locaux sur RTX 3050 6GB via Ollama (mars 2026) : qwen3.5, llama-server, translategemma, lfm2.5, functiongemma, ministral-3. Resultats bruts et decision finale.

Mots-cles : benchmark ollama modeles locaux 2026, qwen3.5 benchmark, translategemma ollama, petit LLM production, local llm rtx 3050

Depuis quelques mois, mes agents Claude Code utilisent deux petits LLMs locaux pour les taches repetitives : scoring, categorisation, generation de noms de branches, commit messages, security review. Tout ce qui ne justifie pas d'appeler l'API Anthropic.

L'architecture tient en deux modeles Ollama :

• MODEL_FORMAT : qwen2.5-coder:3b -- format strict, JSON schema, instructions courtes
• MODEL_SEMANTIC : qwen3-nothink:4b -- raisonnement, scoring, francais

Ca fonctionne. Et c'est justement pour ca que j'aurais pu ne rien toucher.

Mais quand j'ai appris que Qwen venait de sortir la serie 3.5 pour les petits modeles, j'ai eu le reflexe classique du dev : est-ce que je passe a cote de quelque chose de mieux ?

J'ai lance un benchmark complet. Deux jours de tests. 7 modeles ou configurations. 56 resultats directs plus 84 tests complementaires pour le moteur d'inference.

Voici ce que j'ai trouve -- et pourquoi j'ai presque tout jete.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Le setup

Materiel : RTX 3050 6GB VRAM, WSL2 Ubuntu (migration recente depuis Windows natif -- voir article 028).

Methode : 14 tests standardises couvrant 6 categories : instructions basiques (yes/no, binaire, choix multiple), scoring calibre, classification, generation (noms de branches, commit messages), JSON strict, code review securite, traduction.

Chaque test a un critere de passage precis et non ambigu. Pas d'interpretation. PASS ou FAIL.

Modeles de reference production :

C'est la barre a franchir.

Axe 1 : qwen3.5 vaut-il le coup ?

Trois tailles testees : 0.8b, 2b, 4b. Contre les deux modeles actuels.

Premier constat : qwen3.5:4b atteint le meme pass rate que les modeles actuels. Mais il est 2x plus lent. Et qwen3.5:0.8b et 2b sont en dessous.

Deuxieme constat, plus decisif : j'ai teste les synergies -- les cas ou les deux modeles travaillent ensemble (FORMAT genere, SEMANTIC reviewe).

La combinaison actuelle est toujours la meilleure. Migration annulee.

Un detail supplementaire : qwen3-nothink:4b a 6 "think leaks" dans les tests -- des residus de raisonnement qui s'echappent dans les reponses. Qwen3.5 n'en a aucun. C'est un avantage reel de la nouvelle serie, mais pas suffisant pour justifier la regression sur les synergies.

Le cas qwen3.5 : le mode thinking

Un test separate a revele un comportement important : avec qwen3.5, le parametre think: false d'Ollama est indispensable.

Sans lui, le modele passe 240 tokens minimum en reflexion interne avant de produire la moindre reponse. Pour une question binaire (oui/non), think ON prend 6 a 9 secondes. Think OFF : 200ms. Le resultat est identique.

Pour les hooks agents : think: false est obligatoire. C'est a retenir pour quiconque voudrait utiliser qwen3.5 dans un contexte de latence faible.

Axe 2 : llama-server, une alternative a Ollama ?

llama.cpp propose son propre serveur d'inference via Docker. L'idee : meilleure vitesse brute sur GPU, plus de controle sur les parametres GGUF.

J'ai teste les trois modeles cles sur les deux moteurs (execution sequentielle -- 6GB VRAM ne permet pas de faire tourner les deux en meme temps).

Le resultat sur qwen3-nothink:4b est sans appel. Sur llama-server, le modele produit des reponses vides sur presque tous les tests basiques. Le probleme vient du template de prompt -- le format attendu par le modele n'est pas correctement gere par llama.cpp avec ce GGUF specifique.

Pour qwen3.5, llama-server est plus rapide en pass rate mais 2.5x plus lent en debit (21.6 t/s vs 55.4 t/s Ollama).

Conclusion : Ollama reste. Le runner natif Ollama gere les specificites de chaque modele de facon plus fiable. Le gain potentiel de llama-server est annule par la regression sur mon modele semantique principal.

Axe 3 : les quatre nouveaux candidats

Parallelement au benchmark qwen3.5 et moteur, j'ai teste quatre modeles recents qui avaient l'air interessants sur le papier.

lfm2.5-thinking:1.2b (Liquid AI) -- 0/14

Le modele le plus rapide du lot : 186 t/s. Architecture hybride (convolution + GQA).

Probleme fatal : le parametre think: false est completement ignore. Chaque reponse commence par "Okay, let's see..." et consomme 100% du budget tokens en raisonnement. Aucune reponse structuree ne sort.

C'est une contrainte architecturale. Le template Ollama ne peut pas desactiver le raisonnement interne de ce modele. 186 tokens par seconde de pensee pure, sans sortie exploitable.

Resultat : 0/14. Inutilisable pour des hooks stricts.

functiongemma:270m (Google) -- 2/14

270 millions de parametres, 0.28GB. Le modele le plus leger teste.

Sur le papier : specialiste function calling. En pratique : refuse la plupart des taches hors de son domaine, produit des sorties vides sur les tests de generation et de categorisation. Il fait bien ce pour quoi il a ete concu -- mais ce n'est pas ce dont les hooks ont besoin.

2/14. Pas un modele de dialogue general.

ministral-3:3b (Mistral) -- 8/14

Le plus prometteur des trois elimines. 57% de pass rate, ce qui le place loin devant les deux precedents.

Son probleme principal : le formattage excessif. Sur presque toutes les taches de generation et scoring, le modele met du bold sur les reponses numeriques, ajoute des listes quand on attend un mot, entoure les valeurs de guillemets. Exemple : attendu 8, recu **8**. Attendu PASS, recu **PASS**.

Pour des hooks qui parsent les reponses au caractere pres, c'est eliminatoire.

8/14. Comportement de formattage incompatible avec une utilisation en production.

translategemma:4b (Google) -- 13/14

La seule surprise du benchmark.

translategemma est un modele de traduction specialise, entraine sur 55 langues. Je l'avais inclus dans le lot principalement pour tester ses capacites de traduction FR→EN dans le router d'agents. Je ne m'attendais pas a grand chose sur les taches generalistes.

Egal sur le pass rate. Plus lent (2x la latence), plus gros en memoire. Mais 13/14 sur un benchmark generaliste pour un modele dont ce n'est pas la vocation -- c'est inattendu.

Les forces observees : suivi d'instructions exemplaire, reponses concises, JSON output propre, security review detaille et precis. Le seul echec : test de scoring bas (attendu <=4, repondu 6) -- calibration legèrement optimiste.

Decision : adopte comme MODEL_TRANSLATE. Son domaine natif (traduction) combiné a sa discipline de format en font le meilleur candidat pour les taches de traduction dans le pipeline agent-router. Il remplace une traduction approximative faite par les modeles generalistes.

Le bilan

Deux jours de benchmark. Une seule modification a l'architecture :

Avant                       Apres
─────────────────────────   ─────────────────────────────────────
MODEL_FORMAT  : qwen2.5-coder:3b   MODEL_FORMAT    : qwen2.5-coder:3b  (inchange)
MODEL_SEMANTIC: qwen3-nothink:4b   MODEL_SEMANTIC  : qwen3-nothink:4b  (inchange)
(pas de modele dedie)              MODEL_TRANSLATE : translategemma:4b  (nouveau)

Tout le reste : rejete.

Ce que ces tests m'ont appris

Le pass rate ne suffit pas. qwen3.5:4b a le meme taux que les modeles actuels, mais les synergies revelee par les tests combinés montrent que la combinaison actuelle reste superieure. Un bon modele solo ne garantit pas un bon modele systeme.

Les modeles specialises peuvent surprendre. translategemma est concu pour traduire. Son architecture, ses donnees d'entrainement, sa discipline de format -- tout est optimise autour de la fidelite au sens et aux instructions. Ca se voit sur des taches qui n'ont rien a voir avec la traduction.

Le meilleur benchmarks est celui qui teste ce que vous utilisez vraiment. Aucun benchmark generique (MMLU, HumanEval, GSM8K) ne m'aurait dit si ces modeles fonctionnent correctement pour mes hooks. Les 14 tests que j'ai construits sont specifiques a mon usage : categories binaires, JSON strict, branch names en kebab-case, commit messages conventionnels. C'est ca qui compte.

Parfois la bonne decision c'est de ne rien changer. Deux jours de travail pour confirmer que l'architecture existante est toujours la meilleure -- ce n'est pas du temps perdu. C'est du temps investi pour ne pas faire une mauvaise migration.

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.