J’ai vu un modèle de 27 GB s’effondrer en pleine inférence tandis qu’une alternative de 6,6 GB ronronnait tranquillement comme si elle avait tout son temps.
Ce moment-là—assis devant ma RTX 5070 Ti, fixant une erreur de segfault dans WSL2—a cristallisé quelque chose que je soupçonne depuis deux décennies dans ce secteur : le nombre de paramètres est une métrique de vanité. C’est ce qu’on retrouve dans les communiqués de presse et les pitchs aux investisseurs. C’est ce qui rassure les financiers. Mais ça ne rend presque jamais un modèle vraiment utile à votre bureau.
J’ai soumis qwen3.5:9B à 18 tests contre cinq modèles concurrents, spécifiquement pour du travail d’agent local—le genre de trucs réels où vous appelez effectivement des outils, parsez des données structurées, et obtenez des résultats assez vite pour ne pas avoir à faire une pause café entre deux. Le vainqueur ne faisait pas le poids.
Le benchmark que personne ne discute : l’appel structuré d’outils
Voilà ce qui sépare vraiment le bon grain de l’ivraie chez les agents locaux, et les ingénieurs d’Alibaba semblaient le comprendre mieux que la plupart.
Quand vous demandez à la plupart des modèles de langage d’utiliser un outil—par exemple lister un répertoire ou interroger une base de données—ils vont enfouir l’appel de fonction quelque part au milieu d’une réponse bavarde. Vous devez alors construire de la logique de parsing, de la gestion d’erreurs, des mécanismes de retry. C’est un vrai foutoir. Certains modèles font ça mieux que d’autres, mais la plupart vous demandent de bricoler une couche d’extraction.
« Seuls les modèles avec support natif tool_calls et quantization Q4_K_M fonctionnaient correctement. »
Qwen3.5:9B retourne un champ tool_calls propre et indépendant en JSON. Voilà. Pas de parsing. Pas d’acrobaties regex. Pas de rituels à la divinité Python. Les plus gros concurrents comme Qwen2.5:14B et Qwen2.5-coder:14B ont enfoui la même info en texte brut, vous obligeant à construire des couches d’extraction et à les déboguer à 23h.
J’ai testé ce scénario spécifique sur cinq modèles. Qwen3.5:9B a réussi 100% du temps. Gemma 4 E4B (un modèle de 9,6 GB) a nécessité 30 minutes de tuning Ollama pour passer de 3 appels d’outil à 14. Et encore, il sous-performait la constance du plus petit modèle. Les variantes 27B ? Des problèmes de stabilité qui rendaient le déploiement en production impensable.
Là où la VRAM devient le vrai goulot (Spoiler : c’est toujours ça)
Soyons directs : la mémoire GPU sur les cartes grand public est la vraie contrainte du travail IA local, pas la sophistication du modèle.
Qwen3.5:9B consommait 6,6 GB de VRAM sur ma RTX 5070 Ti, laissant largement de l’espace pour le KV cache et des contextes plus longs. Un modèle 27B quantisé Q4_K_M ? 16 GB—saturant complètement la carte. Et puis les crashs ont commencé. Le bug de segfault de TurboQuant dans WSL2 a empiré les choses, transformant ce qui devrait être une inférence triviale en cauchemar de débogage.
J’ai tenu des notes méticuleuses. Voici ce qui s’est vraiment passé :
Les défenseurs des plus gros modèles disent toujours « ajoute juste plus de VRAM ». Bien sûr, si tu as 8 000 dollars qui traînent pour une A100. Mais si tu fais tourner des agents locaux sur une GPU grand public—et soyons honnête, c’est le cas de la plupart d’entre nous—la VRAM est la contrainte dure. Pas la capacité théorique. Pas les scores de benchmark. De la vraie, vraie mémoire physique.
Qwen3.5:9B respecte cette réalité physique.
L’astuce d’efficacité en tokens que personne ne discute
C’est là que ça devient bizarre, et c’est aussi là que les vrais gains se font.
Qwen3.5:9B supporte un paramètre think=false qui désactive les tokens de raisonnement interne. Même tâche. Consommation de tokens différente. On parle de 1024+ tokens réduits à 131. Une réduction 8-10x. Ce n’est pas une erreur d’arrondi—c’est un changement de phase dans le comportement du modèle.
Pourquoi ça compte ? Parce
