Qwen 2.5 Coder 14B tourne de manière fluide sur une RTX 4070 de 16 Go, affichant entre 20 et 50 tokens/seconde selon la quantification, sans aucune facture d'API ni latence réseau. Cela ressemble à une victoire évidente pour les partisans du local-first. Puis, on regarde ce que fait réellement ce modèle lorsqu'on le laisse livré à lui-même sur une tâche de codage agentique, et le tableau se dégrade très vite.
La configuration que personne ne conteste
Avec la quantification Q4_K_M, Qwen2.5-Coder 14B nécessite environ 9 Go de VRAM, ce qui rentre confortablement dans l'enveloppe de 16 Go de la 4070. Sur une puce Ada de milieu de gamme comme la 4070, attendez-vous à environ 20 tokens/seconde dans cette configuration, d'après les benchmarks agrégés de la communauté et des fiches modèles. C'est un chiffre réel, pas du discours marketing. J'ai déployé des configurations similaires pour des clients évaluant l'inférence sur site afin d'éviter les casse-têtes de résidence des données, et le débit brut impressionne véritablement la première fois qu'on le voit.
Mais le débit n'est pas le produit. Ce sont les tâches accomplies qui constituent le produit.
Là où le score agentique de 2/5 fait réellement mal
Voici le chiffre qui change tout : les configurations locales de Qwen2.5 obtiennent environ 2/5 aux benchmarks de capacités agentiques, contre 4,5/5 pour Claude Code. Cet écart ne relève pas de la qualité brute du modèle de langage, mais de l'utilisation d'outils, de la planification multi-étapes et de l'auto-correction sans intervention humaine. J'ai vu exactement ce mode de défaillance en production : un modèle réussit parfaitement la première fonction, puis hallucine discrètement un chemin d'importation à la troisième étape, et personne ne s'en aperçoit jusqu'à ce que le pipeline CI plante deux heures plus tard.
C'est la variable cachée que la plupart des comparaisons « local vs cloud » omettent complètement. Un modèle qui exige une surveillance constante n'est pas bon marché. Il vous facture simplement dans une devise qui ne figure sur aucune facture : votre temps.
Le vrai calcul du TCO
J'ai donc conçu un modèle mensuel simple, en me basant sur un ingénieur basé à Montréal avec un taux horaire moyen de 65 USD, réalisant environ 60 tâches de codage par mois (environ trois par jour), en comparant l'électricité brute plus la dépréciation du GPU à la facturation à l'usage de l'API Claude Code.
La ligne liée à l'infrastructure directe est là où le récit du « local gratuit » l'emporte — 15,86 $contre 21$ relève de l'erreur d'arrondi. Mais dès lors que l'on chiffre les cycles de correction supplémentaires qu'un score agentique de 2/5 impose à un humain, la configuration locale finit par coûter environ 2,5 fois plus cher par mois, et non moins chère.
Pourquoi l'écart est structurel, et non un problème de Prompt Engineering?
J'ai d'abord pensé qu'un meilleur prompting ou un system prompt ajusté pourrait combler la majeure partie de cet écart agentique. Ce n'est pas le cas, du moins pas totalement. L'écart entre 2/5 et 4,5/5 reflète des différences architecturales dans la façon dont ces modèles gèrent l'orchestration d'outils, la rétention de contexte sur de longues boucles agentiques et la récupération d'erreurs — des capacités qu'Anthropic a spécifiquement développées pour Claude Code, et non un échafaudage accessoire qu'on peut ajouter à l'aide d'un meilleur prompt.
C'est la même leçon que j'ai retenue lors du déploiement d'un PLM il y a quelques années : l'outil qui « fait tout ce que promettait la présentation du fournisseur » dans des démos isolées nécessite souvent trois fois plus de supervision une fois qu'il tourne sans contrôle dans un vrai pipeline. Les LLM locaux sur GPU grand public en sont exactement là aujourd'hui pour tout ce qui dépasse les tâches de type autocomplétion.
Où le local l'emporte réellement?
Rien de tout cela ne signifie que l'inférence locale n'a aucun intérêt. Pour l'autocomplétion, la génération de code récurrent (boilerplate) ou la revue de code ponctuelle (single-shot) où un humain révise de toute façon chaque résultat, le déficit agentique de 2/5 importe peu puisque l'humain allait vérifier le travail de toute façon. L'équation économique s'inverse brutalement dès que la tâche exige une exécution autonome multi-étapes : refactorisation sur plusieurs fichiers, exécution de tests, correction de pannes et itération sans supervision. C'est précisément là que l'avantage d'orchestration de Claude Code se démultiplie, et que le coût temporel par tâche de la configuration locale annule ses économies par token.
Ce qu'il faut surveiller à l'avenir
La vraie question n'est pas de savoir si les modèles locaux rattraperont leur retard sur les benchmarks bruts — les scores de codage de Qwen sont déjà compétitifs sur HumanEval. Il s'agit plutôt de savoir si l'écosystème d'outils agentiques open-source (meilleurs ajustements pour l'appel d'outils, boucles de réessai structurées, frameworks d'orchestration locaux) pourra combler cet écart de 2/5 à 4,5/5 sans nécessiter la puissance GPU qui annulerait tout l'intérêt du local. Je ne l'ai pas vérifié de manière indépendante, mais les 12 prochains mois de sorties spécifiques aux agents chez Qwen et DeepSeek nous diront si le « local et autonome » est réellement accessible sur du matériel grand public, ou s'il restera une simple démonstration de salon.
Share: