Qwen en local n’est pas un Opus moins bon, c’est un autre outil

• Qwen 3.6 27B en local apporte une vraie valeur pour des tâches difficiles à envoyer dans le cloud, comme les données clients et la télémétrie interne, sans pour autant remplacer les modèles SOTA du cloud
• La force des modèles locaux ne réside pas dans la compétition au score avec les meilleurs modèles, mais dans le coût fixe, la protection de la vie privée et la réduction du risque fournisseur, avec un écart particulièrement net sur les usages intensifs et les fonctionnalités internes d’un SaaS
• Sur SWE-Bench Verified, Qwen 3.6 27B obtient 77,2 points contre 88,6 % pour Claude Opus 4.8, et affirmer que « le local n’est qu’à 12 % du SOTA » ignore la possibilité d’optimiser pour le benchmark ainsi que les écarts de domaine réels, par exemple avec Go
• Le matériel RTX 6000 Pro Blackwell 96GB acheté environ 12 000 dollars a amorti son coût rien qu’avec un cas de récupération de revenus ayant permis d’identifier une sous-déclaration de licences chez un client
• La plus grande limite reste le problème de boucle, avec sorties répétitives et hallucinations sur les tâches longues ; Qwen en local est donc mieux adapté au support client, à la maintenance ciblée, et à la lecture et l’explication d’une base de code qu’au codage long sans supervision

---

Contexte d’usage de l’IA et contexte business

• Une petite équipe exploite des produits centrés sur une infrastructure bas niveau et des primitives Linux comme OpenFaaS, SlicerVM, Actuated et Inlets
  • Basés sur des conteneurs, les microVM Firecracker, les protocoles réseau, les tunnels, la CLI et Kubernetes, principalement écrits en Go, avec un peu d’UI en React
• Les outils d’IA sont utilisés depuis l’époque de l’autocomplétion dans les onglets de VS Code, et aujourd’hui la majorité du code est produite par Claude ou Codex, avec très peu de code écrit à la main
• Superterm.dev a été créé pour gérer des flux de travail longs dans tmux, et sert à piloter les sessions, les notes, et le retour visuel des agents de code

Le point de bascule de l’intelligence frontier

• Un point de bascule s’est produit entre novembre 2025 et janvier 2026, période où de nombreux développeurs sur X estimaient que Claude Opus pouvait prendre en charge l’ensemble de leur travail
• Le coût des offres de codage haut de gamme s’est stabilisé autour de 200 USD par mois pour un particulier, avec un usage viable dans les limites hebdomadaires de 5 heures tant qu’on évite les tâches excessivement longues sans supervision

Pourquoi les modèles locaux sont intéressants

• 2026 est l’année où n’importe qui peut cloner une idée en une nuit avec un simple abonnement, et SlicerVM comme Superterm ont déjà connu des cas de copie
  • Dans un marché où le coût du logiciel tend vers zéro, le « gratuit et suffisamment bon » peut devenir décisif
• Les modèles de tête sont estimés entre 0.5 et 2T paramètres, à une échelle sans commune mesure avec le meilleur matériel local

• Benchmaxxing

  • Les benchmarks sont publics, donc il est possible de les optimiser par tuning, ce qui en fait des indicateurs absolus peu fiables
  • SWE-Bench Verified repose sur des problèmes Python, dont la plupart du code est mono-thread et synchrone, alors qu’un système distribué en Go mobilise channel, context et struct sur de larges zones d’exécution
  • Il est donc difficile de conclure, à partir du seul benchmark, que « le local est à 12 % du SOTA », car en production ce sont surtout les caractéristiques du langage et du système qui déterminent le succès ou l’échec

• Coût (Cost)

  • Dire que « le coût n’est pas le sujet pour les modèles locaux » ne correspond pas à tous les profils
  • Les offres de codage individuelles à 200 dollars par mois offrent un usage élevé et une intelligence de niveau SOTA, mais ces offres semblent elles-mêmes largement subventionnées
  • GitHub Copilot est passé d’un forfait à 39 dollars par mois avec 1 500 requêtes à une facturation au token, ce qui a provoqué une forte réaction négative
  • Dès que la facturation se fait au coût des tokens API, le point d’équilibre peut arriver vite
    • Uber plafonne les dépenses IA à 1 500 dollars par mois et par développeur et par outil
    • Sur la base d’un salaire médian de 330 000 dollars chez Uber, un développeur qui pousserait deux outils à leur plafond consacrerait environ 12 % de son salaire à ces usages
  • Pour les usages massifs, les boucles, l’analyse par agents et les fonctions embarquées dans un SaaS, les modèles open weight et locaux apportent une vraie valeur

• Souveraineté et vie privée (Sovereignty and privacy)

  • Dans certains cas, les données clients et les clauses contractuelles rendent difficile l’envoi des données vers une offre cloud
  • ChatGPT Pro et Claude Max peuvent être configurés avec une conservation de 30 jours, mais même ce niveau peut suffire à invalider certains contrats clients
  • Le retrait du modèle Fable 5 d’Anthropic du jour au lendemain pour les utilisateurs hors des États-Unis constitue un risque fournisseur
  • Les modèles locaux sont une réponse à la question : « et si le labo frontier faisait X ? »

L’analogie avec le forgeage d’une lame — la nature des modèles locaux

• Comme dans le traitement thermique de l’acier où dépasser une étape impose de recommencer depuis le début, un modèle local peut dépasser sa cible et tomber dans une boucle s’il chauffe trop
  • La seule solution consiste à arrêter le harness et à repartir avec un contexte vidé en espérant un résultat différent
• De même qu’on ne laisse pas le forgeage d’une lame sans surveillance, Qwen 3.6 27B n’est pas utilisé pour des tâches à long horizon

• Ce que je cherchais (What I was looking for)

  • L’objectif était de combiner vie privée, coût fixe et protection contre le risque fournisseur
  • La déception vient quand on traite un modèle local comme Claude ou Codex
  • Claude, avec une instruction courte (« do it and test it end to end »), peut produire une PR, faire une revue de code automatique et itérer efficacement en 5 à 15 minutes

Ce que m’ont appris les 3090

• Le point de départ en 2023 était une seule 3090, avant d’en ajouter une deuxième pour charger les modèles et disposer d’un contexte suffisant
  • C’est à ce moment-là que Qwen 3.5 a été vu pour la première fois comme un agent capable de faire un vrai travail utile
• Avec la consigne « explorer la machine sous tous les angles et rédiger un rapport forensique », le modèle a lu tous les fichiers un par un jusqu’à saturer le contexte et a halluciné des noms de fichiers et des tool calls (~/faas-netes→~/faaned)
  • En réduisant le périmètre à une simple consigne du type « jette juste un œil », il a produit un rapport clair à environ 40 à 50 tok/s
• Le modèle 27B ne tient pas en pleine précision sur une seule 3090, ce qui laisse comme principaux leviers la quantification des poids, la longueur du contexte et la compression du cache KV
  • Il est généralement admis que la partie keys du cache KV pose problème en Q4_0, et même dans la configuration la plus agressive on reste à keys en Q8_0 / values en Q4_0
• Même avec des essais sur vLLM + NVLink + tensor parallelism, la génération était 3 tokens par seconde plus lente qu’avec llama.cpp, avec en plus l’apparition de boucles et plusieurs minutes de chargement des poids
  • vLLM convient à la desserte concurrente à grande échelle, mais dans un contexte prosumer le temps de démarrage, la simplicité et la latence mono-utilisateur comptent davantage

La grosse dépense — adoption de la RTX 6000 Pro

• Une RTX 6000 Pro Blackwell (96GB VRAM) achetée environ 12 000 USD pour résoudre rapidement des tickets de support client
  • Le prix est ensuite monté à environ 15 400 USD, rendant l’ajout d’une deuxième carte difficile
  • Les lignes PCI, la bande passante, l’espacement entre cartes et la charge sur l’alimentation empêchent un simple ajout dans une machine grand public
• Le pari calculé a produit des résultats, mais ne remplace pas un abonnement Claude

Un support client facile, sans fuite de données

• Un outil CLI appelé diag a été créé pour que les opérateurs puissent capturer facilement un snapshot complet d’une installation OpenFaaS sur Kubernetes
  • Les dumps reçus sont ensuite analysés dans une VM éphémère air-gapped avec modèle local, générée par Slicer

• Récupération de revenus (Revenue recovery)

  • En injectant une base de télémétrie dans le modèle local, il a été possible de détecter chez un client plus de 12 mois de sous-déclaration de licences, avec un manque à gagner de 4 à 5 fois, et cette seule récupération a couvert le coût de la carte
  • Les dumps de télémétrie et diag ne sont envoyés dans aucune offre cloud, quelle que soit la politique de conservation des données
  • ChatGPT Pro et Claude Max permettent un paramétrage à 30 jours, mais même cela peut mettre en défaut les contrats clients
  • Les premiers modèles échouaient sur l’arithmétique (27.3K calculé comme 273,000) et interprétaient à tort une faible quantité de fonctions comme un signe de churn, malgré une exécution fréquente
  • En pratique, il vaut mieux les pousser vers l’analyse plutôt que l’interprétation

Setup actuel

• Le rig RTX 6000 fait tourner la dernière génération de Qwopus et le Qwen 3.6 27B de base, avec des changements au gré des nouveaux finetunes et point releases
  • Qwopus est un modèle finetuné sur Qwen, conçu pour ajouter un suivi de Chain of Thought afin d’améliorer le raisonnement et le code
  • Jusqu’à récemment, le mode thinking était complètement désactivé ; sa réactivation coïncide avec une hausse des boucles
• Le service repose sur deux instances indépendantes de llama.cpp pour conserver toute la longueur de contexte ; --parallel 2 divise le contexte par deux
• En speculative decoding (MTP), le taux d’acceptation atteint environ 93 %, et la vitesse passe d’un stable 67 tok/s à 130–200 tok/s, avec une sensation plus rapide que le cloud
  • Il est important de suivre les consignes de tuning de la model card ; Qwopus fonctionne au mieux avec thinking désactivé et une temperature très élevée, entre 0.85 et 1.0

Sorties répétitives et limites sur les tâches longues

• Le principal problème de Qwen sur des tâches longues est la boucle
• À la question des commandes à ajouter à faas-cli, le modèle a d’abord proposé des idées raisonnables, puis a répété la même liste de commandes pendant environ 30 minutes tout en consommant 600W
• Lorsqu’il devait ajouter --json à l’ensemble des commandes get et list, les une ou deux premières implémentations semblaient crédibles et incluaient même des tests, avant que la situation ne se dégrade
• Quand on lui a fait utiliser un reverse proxy Python pour éviter l’avertissement insecure TLS sur les endpoints distants http:// dans la sortie --json, la première version paraissait correcte mais son indentation était fausse ; ensuite, en essayant de corriger, il a cassé le fichier puis est resté bloqué dans une répétition improductive
• Un membre de l’équipe, Han, a connu des boucles similaires, en particulier lorsque le modèle ou l’agent arrivait à la limite de ses capacités sans demander d’aide
• À cause de ce problème, il est difficile de faire confiance à Qwen en local en dehors du support client et de l’analyse de télémétrie ou de dumps diag pour les renouvellements

Mesure et répartition des accès

• Au départ, un simple tunnel inlets était utilisé ; si deux agents se connectent à la même instance llama.cpp, leurs préfixes mis en cache s’invalident mutuellement et obligent à retraiter tout le prompt
• Dès que plusieurs personnes l’utilisent, on sort du prototype et il faut gérer qui utilise quelle instance, combien, quel modèle, le coût électrique et quoi faire en cas de départ d’un utilisateur
• Plutôt que d’éditer et déployer opencode.json à la main, un provider Toilgate pour opencode a été développé, avec un sélecteur allant du modèle de base aux variantes expérimentales de Qwopus
  • Toilgate est 100 % vibe-coded, et l’open sourcer représenterait une charge importante
• La consommation électrique est mesurée sur la prise avec deux Shelly Plus Plug 2 ; la RTX 6000 Pro consomme 600W en inférence tout en restant silencieuse, alors que deux 3090 montent à environ 750W au total avec beaucoup de bruit

• La mauvaise comparaison (The wrong comparison)

  • Comparer le coût d’entrée/sortie par million de tokens au tarif API de GPT-5.5 est aujourd’hui une mauvaise comparaison compte tenu des capacités réelles
  • Au final, la « local AI » devient surtout un problème opérationnel nécessitant identité, contrôle d’accès, metering, quotas, routage de modèles et supervision de la consommation électrique

Les usages qui ont vraiment aidé

• Il est important de spécialiser le modèle local et le harness pour des tâches bien définies
  • support client
  • maintenance à périmètre clair
  • tests end-to-end
• En ajoutant des consignes détaillées dans AGENTS.md, le modèle local a pu ajouter plus vite et plus efficacement de nouvelles CLI et les tester lui-même
  • Cet effet a été observé sur alexellis/arkade
• Même si les modèles locaux ont des limites pour écrire du code directement, ils sont efficaces pour lire rapidement une base de code et l’expliquer
• Agent Skills s’est aussi révélé utile, et un agent local a même réussi à configurer Slicer de zéro sur un nouveau mini PC
• Il faut généraliser l’approche consistant à exécuter la même tâche à la fois sur un modèle local et sur un modèle cloud
  • Comme dans cet exemple de comparaison sur une même tâche, les résultats sont parfois décevants, parfois étonnamment bons
• Les tâches longues sans supervision doivent être évitées, et même un matériel à près de 15 000 dollars ne résout pas ce problème

Conclusion actuelle et limites du choix des modèles

• Qwen en local n’est pas « proche du niveau d’Opus » ; c’est un autre outil, utile dans certaines tâches et certains workflows
• Qwen 3.5 est présenté comme le premier modèle à avoir produit des résultats réellement exploitables, et même s’il existe des rumeurs sur 3.7, l’attente porte davantage sur des améliorations itératives qu’une révolution
• Les modèles 70B sont jugés pour la plupart anciens et en retard de génération
• Qwen 35-A3B est populaire parce qu’il semble rapide sur MacBook, mais comme seuls 3B paramètres sont activés à la génération, le choix va ici à la qualité plutôt qu’à la vitesse
• Des modèles plus gros comme GLM 5.2, Kimi 2.7, Minimax M3 ou Deepseek V4 Flash sont techniquement possibles sur certaines machines locales, mais souvent hors de portée car même leurs versions quantifiées peuvent nécessiter 4 à 6 RTX 6000 Pro pour être chargées
• À ce stade, un modèle dense de 27B reste insuffisant pour écrire du code Go toute la journée, et ses limites de connaissance et d’attention apparaissent très vite en revue de code
• Qwen suit mal les consignes de concision et tend à écrire trop de détails en revue de code automatique, ou à halluciner des problèmes de concurrence et des race conditions, ce qui met rapidement fin aux expérimentations
• Le modèle moins cher et plus rapide Grok Coder Fast 1 a bien fonctionné pendant quelques mois avant d’être deprecated
• Des cas concrets sont détaillés dans le code review bot et dans OpenFaaS’s painless customer support and architecture review

[GN⁺]

Commentaires sur Hacker News

• Après avoir utilisé ces modèles longtemps, on se rend compte que ce n’est pas juste une question de « X est plus intelligent que Y » ou « Y est moins cher que Z ». Ce sont des outils différents, et la manière de prompter diffère aussi, ce qui ressemble beaucoup au fait de jouer d’un instrument
  Avec Claude, il faut parfois être volontairement moins explicite ou plus indirect pour donner une couleur à l’implémentation ou obtenir un résultat créatif. Et, aussi étrange que cela puisse paraître, on est récompensé quand on est gentil avec Claude, et on y perd quand on est brusque. Claude imite davantage le ton, donc mieux vaut éviter d’entrer dans une boucle négative
  Avec GPT, il faut être précis et réduire l’ambiguïté. GPT a tendance à résoudre l’ambiguïté avec une logique min-max du type « je vais faire X mais pas Y », et si on ne définit pas clairement le périmètre, il essaie de couvrir tous les cas limites et a tendance à surconcevoir
  Avec Qwen, il faut lui donner une structure puis lui faire remplir l’intérieur. Qwen aime le XML, le JSON et les listes, et il s’en sort bien si on lui montre beaucoup d’exemples de travaux précédents. Ce n’est absolument pas scientifique, c’est juste une impression, donc les résultats peuvent varier

  • Le fait que ce soit « pas scientifique, juste une impression », c’est précisément le problème. Ce serait bien d’avoir une fiche produit décrivant les forces et faiblesses de chaque modèle, avec un arbre de décision du type « pour ce genre de tâche, modèle X », « le modèle Y doit être utilisé de telle façon pour Z »
    Mais en apparence ils se ressemblent tous, et pour déterminer ce qui est un peu meilleur, et dans quel contexte, il faut soi-même mener des tests étendus, longs et peut-être coûteux
  • J’ai beaucoup testé le fait de relancer exactement le même prompt sur la même entrée, ou de fournir des entrées que je considère sémantiquement identiques mais avec une formulation ou une structure différente, pour voir à quel point les résultats divergeaient. Je l’ai beaucoup fait en particulier entre Sonnet et Opus, ainsi qu’entre différents modèles Qwen
    Je recommande à tout le monde de le faire : cela ne demande pas de données particulières en dehors de celles que vous utilisez déjà, et les résultats sont assez choquants. Il y a bien plus d’aléatoire ou d’instabilité qu’on ne le pense, et ce qu’on considère comme une meilleure technique de prompt, ou comme un résultat particulièrement bon ou mauvais, peut simplement être le fruit du hasard, ou venir de différences de comportement selon la version ou la taille du modèle. De petites différences dans l’entrée peuvent fortement biaiser le résultat. Dans l’entreprise, on appelle parfois certaines de ces choses des mots magiques : le simple fait de mentionner un terme technique précis, une référence ou une méthode peut nettement améliorer le résultat
    Il y a aussi la technique. Dans une boucle d’agent, quand le modèle est placé dans une structure d’autoévaluation où il lui est difficile de tricher ou de prendre des raccourcis, et que cela correspond à une structure ou à un domaine appris, il s’en sort extrêmement bien. Mais il est difficile de trouver le point optimal. Petit conseil : si vous demandez à Opus 4.8 de convertir un modèle PyTorch en ONNX ou en modèle quantifié, ou de le faire tourner sur un autre matériel, il devient vraiment excellent, comme si on activait une capacité spéciale. En revanche, impossible de lui faire rédiger et tester correctement, sans tricher, une formalisation EBNF d’un langage ou d’un format général
    Le pire, c’est que ces connaissances changent trop souvent, au point que, sauf à être soi-même la personne qui entraîne réellement le modèle, cela vaut à peine la peine d’aller très loin. J’aimerais que la stabilité des sorties soit davantage mise en avant dans l’entraînement pour rendre tout cela plus prévisible. Ce serait difficile à faire sans surapprentissage ni sans casser la boucle exploration-exploitation, mais si les LLM pouvaient exécuter des tâches par lots de façon plus stable, je dépenserais sans doute bien plus d’argent pour eux
  • Plus que de jouer d’un instrument, cela ressemble davantage à tirer sur une machine à sous et à imaginer le reste
  • Je suis d’accord en grande partie, sauf sur un point. Parler rudement à Claude au bon moment peut être extrêmement efficace. En particulier, lâcher une insulte en F semble parfois assez utile pour débloquer Claude quand il est coincé
  • J’ai demandé à GLM 5.2 de porter un ancien jeu C#/XNA vers HTML5, et il a pratiquement recopié le code, puis ajouté du code supplémentaire pour le faire fonctionner après avoir retiré uniquement la surcharge d’opérateurs absente en JS
    J’ai fait la même demande à Claude Sonnet 4.6, et le résultat donnait l’impression que le jeu avait été écrit en JS dès le départ. En plus, pour une raison quelconque, il en a fait un fichier HTML unique, supprimé tous les assets, puis généré dynamiquement les graphismes et la musique, en créant même un nouveau fond meilleur que l’ancien
    J’avais simplement demandé un portage du jeu, donc ça m’a surpris. J’ai plutôt aimé les choix faits, mais je n’ai aucune idée de la façon d’activer ou de désactiver ce comportement. Parfois on a besoin de créativité, et parfois on veut qu’il fasse exactement ce qu’on a demandé

• Cet article et les éloges qu’il reçoit me donnent une impression de roi nu. Dès cette phrase, ça n’a aucun sens
  “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
  Parmi ce qu’on pourrait à la rigueur qualifier de « primitives Linux de bas niveau », il y a peut-être les protocoles réseau. Et cela ressemble clairement à un texte généré par une IA. Ce ne serait pas gênant si le contenu était fiable, mais il ne l’est pas

  • Aujourd’hui, le bas niveau, c’est JavaScript au lieu de TypeScript
  • C’est vrai que cette phrase était excessivement condensée. Je l’ai reformulée, mais le sens reste le même
    Le texte n’a pas été généré par une IA ; je génère du code avec l’IA, mais j’écris moi-même les textes. Je serais curieux de savoir quelle partie n’est pas comprise. Cet article décrit notre propre expérience et notre parcours, et je peux volontiers étayer certains points précis

• Je continue de penser que la force de l’IA apparaît non pas quand elle devient un autre service cloud pour lequel il faut payer sans fin et qui se dégrade avec le temps pour satisfaire la cupidité des actionnaires, mais quand elle est utilisée en local, de façon sûre et privée.
  Je ne laisserai jamais ChatGPT ou Anthropic lier mes données de santé à leurs systèmes, mais je crois toujours à la capacité de l’IA à repérer des motifs dans les données que je pourrais manquer. C’est pourquoi il y a un besoin urgent d’un écosystème strictement local permettant d’exposer et de traiter ces données en toute sécurité et en privé avec des outils comme Qwen ou Gemma.
  Même chose pour la maison connectée et les assistants personnels. L’approche d’entreprise où les données stockées chez A sont accessibles par B, traitées par D et E, puis vendues à des annonceurs et des data brokers, sans même que je puisse les extraire ou les consulter sur mon propre matériel local, n’est pas viable pour ce type d’usage privé. Mes données doivent m’appartenir, être contrôlées et exposées selon mes conditions, et servir d’abord à améliorer ma vie, pas le compte de résultat de quelqu’un d’autre. Je veux que la technologie me rende du temps et améliore les résultats, et après avoir été suffisamment échaudé par la Big Tech, je rejette fermement l’idée qu’il y aurait une quelconque noblesse ou utilité publique dans le modèle économique de l’AI-as-a-Service.
  Les capacités existent déjà, et je pense que les personnes qui créent des outils locaux pour soutenir et libérer le potentiel des modèles locaux vont dans la bonne direction. J’aime voir ce qu’elles construisent.

  • Le point clé des modèles « locaux », c’est généralement qu’ils ont des poids ouverts, et parfois qu’ils sont aussi open source. On peut donc les utiliser en local, mais ils peuvent aussi être hébergés par des prestataires indépendants.
    En utilisant des modèles comme Qwen ou DeepSeek, on peut passer d’un prestataire indépendant à un autre sans être enfermé chez une seule entreprise, tout en bénéficiant potentiellement de meilleures garanties de confidentialité. Cela permet aussi d’utiliser le modèle sur des appareils incapables de l’exécuter directement, tant qu’ils ont une connexion internet.
    La force de l’IA réside dans les modèles open source. Il faut utiliser des modèles qui évitent le verrouillage fournisseur et permettent à la fois un usage local et un hébergement par des prestataires indépendants.

• Bon article. J’ai juste l’impression qu’il sous-estime la capacité d’amélioration.
  Les auteurs reconnaissent eux-mêmes qu’il n’est pas très pertinent de comparer les modèles locaux d’il y a un an à ceux d’aujourd’hui. En pratique, beaucoup situent en novembre dernier, avec Opus 4.5 — donc il y a 8 mois — le premier moment où le codage agentique est devenu largement possible même sur des modèles frontier hébergés.
  Alors pourquoi figer dès maintenant une idée de ce que les modèles locaux savent ou ne savent pas faire ? Dans un an, ce sera probablement différent quoi qu’il arrive. Penser qu’ils pourront gérer de longues tâches sur du matériel grand public ou professionnel relève peut-être d’un optimisme naïf, mais jusqu’ici ce sont les optimistes naïfs qui gagnent.

  • Oui. Si Opus 4.5 est devenu suffisant pour le codage agentique il y a 8 mois, à quel point les modèles à poids ouverts sont-ils en retard ? Plus de 8 mois ? De combien ? Atteindront-ils le niveau d’Opus 4.5 dans quelques mois, dans un an, ou jamais ?
  • Il manque surtout une comparaison des harness. Ça joue énormément. J’utilise forge, et même en tenant compte de toutes les limites des modèles locaux, j’ai été impressionné par ce qu’on peut faire avec.
  • Puisque l’auteur parle d’un modèle précis, je pense qu’on peut très bien laisser de côté la question de savoir comment ce modèle, ou les modèles locaux en général, vont s’améliorer avec le temps.
    C’est un peu comme acheter une voiture. On la conduit et on apprend à connaître ses caractéristiques ; on ne passe pas son temps à réfléchir à la manière dont elle ou des modèles similaires vont s’améliorer à l’avenir. C’est mon outil, et je veux en tirer le meilleur parti.
    Bien sûr, le coût technique pour changer de modèle local est très faible, mais tirer les meilleures performances d’un modèle demande quand même beaucoup de temps, et ces efforts pourraient ne plus servir avec une nouvelle version.
  • Je suis 100 % d’accord pour dire que Claude 4.5 a été un tournant pour le codage agentique. Ce modèle a complètement changé ma façon de voir les choses.

• Article intéressant. Personnellement, j’aurais aimé que l’auteur fasse mieux deux choses.
  Premièrement, il aurait dû utiliser vLLM plutôt que llama.cpp. Sur du matériel NVIDIA, l’écart avec vLLM est énorme dès qu’il y a de la charge multi-utilisateur et du caching. Quand il se plaint de l’usage par plus de deux personnes ou du fait que le cache disparaît, ma réaction a été : « forcément ».
  Deuxièmement, le budget consacré à une seule carte aurait été bien mieux utilisé sur SPARK. On peut avoir un cluster de 2 x GX10, pour un coût total qui reste aujourd’hui inférieur à la moitié de ce qu’il a payé, et faire tourner vLLM avec Deepseek v4 Flash. Par rapport à Qwen, la différence est énorme. Je ne l’ai jamais vu partir en boucle, et c’est le modèle le plus proche de Sonnet parmi tout ce que j’ai testé jusqu’ici. antirez semble être d’accord, puisqu’il a apparemment créé un fork ds4.
  Voici comment c’est configuré sur 2 GX10 : https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
  Les performances sont de 2K tokens/s en préremplissage, ce qui est très utile pour injecter de gros volumes de code source dans un contexte énorme, et d’environ 50 à 60 tokens/s en génération pour du code avec le harness pi.dev. Avec l’argent qu’il a dépensé, l’auteur aurait pu acheter 4 GX10, et comme vLLM s’étend presque linéairement en parallélisme tensoriel, il aurait pu doubler ces deux chiffres.

  • J’ai aussi essayé de faire tourner vLLM sur une 3090. Dans un schéma d’usage comme le nôtre, avec une à quelques personnes, la génération était environ 3 tokens/s plus lente, la flexibilité de quantification plus faible, et le démarrage prenait réellement plusieurs minutes au lieu de quelques secondes.
    Je réessaierai peut-être plus tard, mais je n’ai pas un temps infini à consacrer à bricoler, et je partage simplement mon parcours et mon jugement à ce stade.
    Pour du serving concurrent par lots, vLLM est le bon choix, et ce que dit barrkel plus bas est juste. Mais pour notre façon de l’utiliser, llama.cpp reste meilleur.
    La voie Spark/GX10 est vraiment un autre pari, et merci d’avoir partagé les chiffres. Il y a encore quelques mois, l’ambiance générale était que le GX10 ne servait qu’au fine-tuning et que ses performances étaient franchement faibles.
    Et cette carte n’a absolument pas été achetée pour remplacer un abonnement Claude Max. Pour le travail auquel elle est réellement destinée, j’obtiens en fait 140 à 200 tokens/s, et c’est ça qui compte.

• Le texte était long, mais je ne comprends toujours pas quel était exactement le propos central de l’auteur. À part ce qu’on peut déduire du titre.
  En revanche, j’ai compris que l’auteur est quelqu’un d’assez cool qui construit des choses physiques et des logiciels, et que d’autres gens lui donnent même de l’argent. Je ne sais juste pas si cela a un rapport avec le sujet suggéré par le titre.

  • De nos jours, tout est publicité. L’article n’était pas inutile, mais vu la quantité d’information fournie, deux paragraphes auraient suffi.

• Cet article résume bien les modèles locaux. Contrairement à l’image parfois exagérée d’un outil fantastique pour le codage et le travail local avec des agents, la réalité est qu’ils restent assez limités, faibles sur les tâches longues ou complexes, et ont tendance à tomber dans des boucles ou à oublier ce qu’ils faisaient
  Un point absent de l’article, c’est que cela coûte aussi assez cher. Il n’y a pas que le coût du matériel, il y a aussi l’électricité. Une machine en 3090 ou 5090 consomme beaucoup, et comme les modèles y sont assez lents, la consommation électrique par token augmente d’autant
  Le vrai point fort, c’est le contrôle, la confidentialité et la prévisibilité. Par exemple, pour des tâches répétitives comme le classement d’une photothèque ou vidéothèque, c’est très bien, et selon le prix de l’électricité cela peut aussi être avantageux en coût

  • Je pense que les modèles locaux sont une extension indispensable de l’ordinateur personnel. J’imagine que les premiers ordinateurs personnels ont dû recevoir des critiques similaires
  • Mon rêve, c’est un modèle local capable de traiter environ 80 % des tâches du quotidien. Par exemple : « Comment X Handler est-il connecté à Y storage ? », « Fais le commit de cette fonctionnalité, mais exclue la partie liée au paiement »
    Les appels d’outils doivent être fiables à 99 %, et surtout il faut pouvoir dire : « Cette tâche dépasse mes capacités », puis la transmettre à un modèle haute performance en ligne quelque part dans un immense datacenter
    De cette façon, l’appareil peut gérer toutes les tâches simples, collecter les données et comprendre le contexte du problème, puis, une fois le travail facile terminé, un modèle plus intelligent intervient pour résoudre le problème
    Quand un modèle local sait faire à 100 % une commande comme /commit, le fait qu’il appelle quand même un modèle en ligne donne vraiment l’impression d’être absurde. Cela dit, c’est surtout un problème de harness, donc en grande partie résoluble
  • Les modèles locaux sont vraiment excellents pour beaucoup d’usages, et je pense que la plupart des gens n’ont pas besoin de modèles de pointe. Quand je fais tourner un modèle Qwen sur une petite 4070 12GB comme agent d’e-mail personnel, la confidentialité passe avant tout
    Il s’en sort très bien, et pour les tâches de codage aussi, à condition de savoir l’utiliser plutôt que de lui jeter d’un bloc un plan grandiose
  • Depuis l’arrivée du changement MTP, j’obtiens 40 à 50 tokens/s avec qwen3.6:27b sur une 4090 limitée à 350W
    Cela donne environ 8,75 J/token au maximum
    Je ne sais pas où cela se situe par rapport au reste, mais j’imagine qu’une 5090 serait un peu moins chère à l’usage, puisqu’elle irait plus vite avec la même limite de puissance
  • Ça, c’est avec le matériel actuel. Mais qu’en sera-t-il du matériel futur ? Du matériel optimisé pour l’inférence ? Du matériel optimisé pour exécuter un modèle particulier ?

• J’ai trouvé intéressant que vLLM ait été présenté comme plus lent que llama.cpp
  D’après mon expérience, vLLM est nettement plus rapide que llama.cpp, et surtout il le surpasse largement en traitement par lots sous charge concurrente. Son inconvénient, c’est une flexibilité de réglage bien plus faible. Il y a très peu d’options pour exécuter des poids quantifiés, et le temps de démarrage est beaucoup plus long parce qu’il optimise le graphe de calcul. Du coup, pour un utilisateur seul qui expérimente avec un modèle un peu trop gros pour sa machine, vLLM peut être frustrant

  • On peut le dire comme ça : vLLM n’est pas un Llama.cpp en moins bien, c’est un autre outil
  • vLLM est excellent pour le batching continu et le serving de modèles en production, mais dans la catégorie prosumer c’est quelque chose de complètement différent et beaucoup moins polyvalent
    Dire qu’il a été « écarté d’un revers de main » est un peu fort, mais pour être plus précis, sur une machine avec 2x 3090 il lui a fallu plus de 4 minutes pour charger, et sur une requête unique il était plus lent de 3 tokens/s
    Le pire, c’est qu’après tout l’effort de configuration et de tuning, il tombait encore dans des boucles. J’espérais vraiment que le conseil qu’on entend partout — « utilise simplement vLLM » — serait une solution miracle
    Il faut faire attention à ne pas commencer à rabaisser llama.cpp comme certains l’ont fait avec Ollama. llama.cpp est un outil très compétent, et il correspond mieux à l’usage réel qu’on veut faire de ces cartes
    Pour une grande équipe cherchant à remplacer des abonnements Claude, vLLM est peut-être le seul choix, mais pour faire tourner quelque chose comme GLM 5.2 il faudrait probablement ajouter encore cinq cartes RTX 6000
  • Si je me souviens bien, le consensus général était : llama.cpp pour un utilisateur seul, vLLM pour plusieurs utilisateurs ou pour l’entreprise. C’est proche, mais pas pour le même usage
  • J’étais un peu déconcerté de voir des gens continuer à utiliser llama.cpp tout en se plaignant que les préfixes en cache se cassent quand plusieurs utilisateurs sollicitent le modèle, sans passer à vLLM

• Ils disent d’abord que « le modèle tourne trop chaud, dépasse l’objectif et part en boucle », puis plus loin expliquent qu’ils ont configuré vLLM comme dernière expérience, mais que même avec NVLink et le parallélisme tensoriel, la génération restait 3 tokens/s plus lente que llama.cpp
  Dans tous mes tests, faire tourner vLLM en valait la peine. C’est le facteur unique qui a le plus aidé sur les problèmes de boucle, d’agents qui deviennent bizarres, de perte de concentration sur la tâche, et de contexte long qui finit par devenir pratiquement inutile
  Avec des modèles FP8 et un cache non quantifié dans vLLM, l’expérience globale est meilleure d’un cran par rapport à n’importe quelle autre stack. Après ça, on peut arrêter de bricoler les réglages et se concentrer sur l’usage du modèle pour autre chose

  • Cette partie m’intéresse vraiment. Pas parce que je ne suis pas d’accord, mais parce que je veux éviter que les agents deviennent bizarres. Je me demande si vLLM est utilisé seul, pour une équipe, ou pour une application
    Et je me demande aussi si, pour que vLLM soit utile de cette façon, il faut selon toi un minimum de matériel. Je compte monter comme projet de week-end un serveur d’inférence domestique à partir de vieux composants de datacenter, et j’affine encore mentalement la configuration finale
  • Je me demande pourquoi utiliser un cache non quantifié plutôt que Q8

• À ceux qui veulent acheter et assembler leur propre machine IA, je recommanderais d’abord de se connecter à l’un des nombreux fournisseurs d’inférence et de tester directement divers modèles pendant un moment
  Cela coûte très peu, mais donne un assez bon aperçu de ce que vous pourriez obtenir avec votre propre matériel. Juste un conseil amical