Qwen 3.8 27B : sur r/LocalLLaMA, certains ont arrêté de payer les API

Un modèle open weight de 27 milliards de paramètres tourne sur une seule GPU et, selon ses utilisateurs, suffit pour le travail quotidien. Voici ce qui est vérifié et ce qui relève de l'expérience personnelle.

Dans cet article

Ce qui est confirmé
Ce qui se dit
Pourquoi c'est important pour vous

Le post le plus discuté de ces derniers jours sur r/LocalLLaMA a un titre qui ressemble à une provocation : « Qwen-3.8-27B is good enough that I stopped using API » (en pratique : le modèle est suffisamment bon pour avoir remplacé les API payantes). Ce n'est ni un benchmark ni une annonce, c'est le témoignage d'un utilisateur, mais il aborde la question que de nombreuses PME se posent depuis des mois : un modèle qui tourne en local peut-il faire le travail d'un service cloud ?

Illustration d'une tour d'ordinateur avec carte graphique connectée par câble à une petite carte électronique sur une étagère — Photo :

Ce qui est confirmé

Qwen3.8-27B est un modèle de l'équipe Qwen d'Alibaba publié mi-août 2026 avec des poids ouverts sur Hugging Face, sous licence Apache 2.0 : il peut être utilisé à des fins commerciales. C'est un modèle dense de 27 milliards de paramètres, sans architecture mixture-of-experts, avec 64 couches qui alternent Gated DeltaNet et attention classique, un encodeur pour les images et un contexte natif de 262 144 tokens, extensible jusqu'à un million.

Dans la fiche du modèle, Qwen déclare, entre autres, 61,7 sur SWE-bench Pro et 73,0 sur Terminal Bench 2.1. Ce sont des chiffres du fabricant, pas des mesures indépendantes. Pour une utilisation en production, Qwen recommande des moteurs comme vLLM ou SGLang ; pour les tests en local, il existe des versions quantifiées pour llama.cpp, Ollama et LM Studio. Dans la bibliothèque d'Ollama, la version 27B quantifiée occupe 18 Go.

Rumeur

Ce qui se dit

L'auteur du thread raconte utiliser la quantification Q4_K_S avec le cache de contexte en Q8_0, au sein de l'agent de programmation Pi, avec peu d'outils (shell, lecture, écriture, modification de fichiers) et Docker comme sandbox. Selon lui, le modèle « pense énormément » et le regarder travailler est frustrant, mais laissé seul, il mène à bien des refactorings complexes en prenant des décisions sensées. Le point faible, écrit-il, est l'outil de modification de fichiers : le modèle doit souvent réessayer car il se trompe dans l'indentation.

Concernant les coûts, l'utilisateur estime qu'avec son matériel et son tarif électrique, un million de tokens lui coûte environ 2,4 centimes en entrée et 70 centimes en sortie, des chiffres qu'il juge comparables aux fournisseurs d'API les moins chers. C'est un calcul personnel, non vérifiable, qui n'inclut pas le prix de la machine.

Parmi les réponses, un autre utilisateur avec une GPU de 16 Go dit utiliser une quantification IQ4_XS avec des techniques pour étendre le contexte au-delà de 160 000 tokens et le considère désormais comme son unique modèle pour le développement, la sécurité et l'administration IT. Sur le même subreddit circulent des comparaisons entre le modèle officiel et des variantes communautaires plus rapides ; l'auteur du thread rapporte que l'une d'elles, lors de son test, finissait plus souvent en boucle.

Pourquoi c'est important pour vous

Pour une PME ou un MSP, la nouvelle n'est pas qu'un modèle local batte les meilleurs services cloud : personne ne le dit, pas même le thread. C'est que le seuil du « suffisamment bon » pour des tâches répétitives, comme les scripts, les petits refactorings et les automatisations d'administration, est aujourd'hui atteint avec une seule GPU de 24 Go, ou avec 16 Go en acceptant quelques compromis.

Données : le code et les documents ne sortent pas de votre réseau, ce qui simplifie la discussion GDPR avec les clients.
Coûts : vous payez le matériel et l'énergie au lieu des tokens ; cela est avantageux si l'utilisation est constante, moins si elle est occasionnelle.
Limites : le modèle réfléchit longtemps, il est donc lent pour les tâches interactives ; il doit être placé dans une sandbox et ses modifications doivent être révisées, comme celles de n'importe quel agent.

Une première étape réaliste consiste à installer Ollama sur une workstation avec GPU, à lancer ollama run qwen3.8 et à lui confier une tâche réelle mais à faible risque, par exemple un script de maintenance sur un repository de test. Si vous souhaitez comprendre quel mélange de modèles locaux et cloud a du sens pour votre entreprise, vous trouverez notre approche sur la page des services d'intelligence intelligence artificielle.

Sources : fiche de Qwen3.8-27B sur Hugging Face, thread sur r/LocalLLaMA, bibliothèque Ollama, qwen3.8.