Ask HN : Quelqu’un a-t-il remplacé Claude/GPT par des modèles locaux pour le codage au quotidien ?

 (news.ycombinator.com)
6 points par GN⁺ 9 시간 전 | 2 commentaires | Partager sur WhatsApp
  • Des développeurs abandonnent complètement les modèles cloud pour des raisons de confidentialité des données et d’usage gratuit des LLM, et peuvent travailler sans aucun appel réseau externe grâce à des harness de codage hors ligne conteneurisés et sandboxés
  • Les principaux modèles utilisés sont Qwen3.6 35B-A3B (rapide grâce à 3b de paramètres actifs) et des modèles denses 27B, avec un compromis entre précision en codage et vitesse de génération de tokens
  • La combinaison Pi harness et llama.cpp est la plus souvent citée, et le fait que le tool calling fonctionne pour la première fois de façon cohérente sur des modèles locaux a fortement amélioré l’expérience d’usage
  • Par rapport à Claude Opus, les modèles locaux se situent au niveau de « junior qui a besoin d’être guidé vs senior qui conçoit avec vous », ce qui rend indispensables des prompts précis et une décomposition fine des tâches
  • Les modèles locaux actuels sont évalués comme étant à peu près au niveau de la frontière d’il y a 8 à 18 mois, mais offrent des avantages concrets : gratuité, confidentialité et absence d’inquiétude liée aux quotas

Cas de migration vers des modèles locaux et configurations matérielles

  • Qwen3.6 35B-A3B exécuté avec Pi harness sur un Mac Studio 128GB ou un MacBook avec 36GB de RAM, ayant permis de refaire entièrement la page d’accueil et le blog d’un site web basé sur Django + Wagtail
    • Sans accès à Internet, le modèle ne sait pas toujours comment faire sur un framework moins connu comme Wagtail
    • Pour les tâches complexes, certains utilisent Qwen3.5 122b, mais avec 10b de paramètres actifs il est nettement plus lent
  • Dans un environnement à mémoire unifiée Strix Halo 128GB, Pi est isolé dans un conteneur avec accès uniquement au répertoire de travail et sans identifiants
    • Gemma 4 31B est utilisé pour le chat et la traduction, Gemma 4 12B pour l’audio
    • De nombreux modèles sont disponibles, comme Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash et GPT-OSS 120B, mais pour le code le 35B-A3B est jugé optimal
  • Sur une machine double RTX3090 assemblée il y a 5 ans, des modèles Qwen et Gemma atteignent ~150tok/s en quantification UD-Q4_K_XL, avec traitement complet d’un contexte 300k en VRAM
    • Cela a remplacé un abonnement Claude à 100 $/mois, et pour un usage personnel la gratuité passe avant tout
    • Utilisée pour divers projets : launcher Android TV, portail d’administration k8s, intégration Home Assistant, gestion des courses et des repas, etc.
  • Avec une RTX 6000, la combinaison Qwen 3.6 27b + Open Code couvre 90 % du codage, mais les tâches très complexes et le polissage UI reviennent encore à Codex
    • À partir de 100k sur un contexte 256k, qualité et vitesse se dégradent, et après 150k cela devient sérieux
  • Sur RTX 5090, Qwen 3.6 27b (quantification Q6) + llama.cpp, avec GPU limité de 600W à 450W pour réduire le bruit
    • L’usage s’étend au travail quotidien : commits de branches, création de PR, rapprochement de factures avec Stripe CLI, analyse de charge Elasticsearch

Types de modèles et caractéristiques de performance

  • La distinction MoE vs modèle dense a un impact direct sur la qualité en codage
    • Qwen3.5-122B est en réalité un 122B-A10B MoE avec seulement 10B de paramètres actifs, alors que Qwen3.6-27B est un modèle dense où les 27B sont toujours actifs
    • On peut approximer la qualité équivalente dense d’un MoE par la moyenne géométrique des paramètres actifs et totaux, soit sqrt(35×10)≈18.7
    • À taille égale, les MoE ont une qualité inférieure mais sont plus rapides, et de gros MoE peuvent aussi tourner via offload sur la RAM CPU
  • Le niveau de quantification influence l’apparition de boucles et la précision
    • La quantification Q8 est plus lente mais réduit les boucles, ce qui fait gagner du temps au total
    • La partie K du KV cache y est particulièrement sensible, et F16 K + Q8 V réduit fortement les boucles
  • L’ajout d’un second GPU vise surtout à augmenter la capacité VRAM, pas la vitesse d’inférence
    • Gemma-4 31B dense et 26B MoE ont une qualité comparable en Q4, mais le MoE est environ 3× plus rapide (150tok/s vs 46tok/s)

Limites des modèles locaux et stratégies de contournement

  • Nécessité de prompts précis

    • Si l’on laisse des hypothèses ouvertes, le modèle choisit le chemin le plus court (par exemple du CSS dans le HTML), produisant un résultat qui n’est pas optimal du point de vue architecture
    • Si l’architecture n’est pas explicitée, il fait des modifications rapides et sales ; si on ne lui dit pas de supprimer les phrases de debug, il les laisse
    • Claude Opus infère l’intention de l’utilisateur, alors qu’un petit modèle Qwen n’exécute que ce qui est demandé ; il faut donc « activer » explicitement les connaissances de conception

  • Boucles et erreurs d’outils d’édition

    • Il se trompe souvent dans les appels aux outils d’édition et, au lieu de réessayer, consomme des tokens de raisonnement pour relire le fichier
    • Un simple retry manuel corrige souvent l’appel d’édition, mais le modèle suppose un problème plus fondamental et gaspille des tokens
    • Une approche d’édition fondée sur des hash (référence au hash de chaque ligne de code) peut réduire les erreurs, mais une fois la qualité du contexte épuisée, l’ensemble s’effondre autrement
    • Des règles dans AGENTS.md qui limitent les réécritures au profit d’éditions ciblées apportent une amélioration partielle

  • Gestion de la fenêtre de contexte

    • Une fenêtre de 65 000 est dépassée rien qu’en lisant la structure des fichiers de code ; il faut plus de 200k
    • Qwen3.6-35b gère correctement 128k sur ses 256k de contexte avec 16gb de VRAM
    • Qwen3.6-27B prend en charge un contexte d’un million de tokens, avec environ 100GB de mémoire nécessaires sur DGX Spark avec KV cache en f16

Problèmes de prompt caching et de préservation du raisonnement

  • Les modèles hybrides Qwen gèrent mal le prompt caching et retraitent tout le contexte à chaque tour
    • La plupart des modèles locaux ne sont pas entraînés à préserver le raisonnement complet entre les tours, ce qui impose un retraitement sans ce raisonnement après de longues chaînes d’appels d’outils
    • Qwen 3.6 a été entraîné à préserver le raisonnement, ce qui améliore la réutilisation du cache avec chat-template-kwargs = {"preserve_thinking": true}
  • Les LLM modernes n’utilisent pas seulement de la full attention, mais aussi de la local attention (fenêtre glissante, modèle d’espace d’état Mamba-2)
    • La full attention a un coût en O(n²) et gère mal un raisonnement dont les valeurs changent au fil du temps
    • La local attention stocke des instantanés et repart du dernier lors du recalcul du cache, avec toutefois des limites de stockage si ces instantanés sont trop volumineux
    • Qwen 3.5 et plus utilisent Gated DeltaNet, alternant couches d’attention et couches SSM
  • Vulkan est paradoxalement plus rapide que ROCm, et garder llama.cpp à jour est important pour résoudre les problèmes de retraitement
  • Les divergences de tokenization, où les tokens générés en autoregressif sont parsés différemment au prefill, restent difficiles à résoudre

Débat sur le coût et l’économie d’énergie

  • 2x RTX3090 coûtent environ 4 400 $, soit 3,6 ans d’un Claude à 100 $/mois, sans compter l’électricité ni les autres composants
    • Même dans 3,6 ans, les GPU à forte capacité mémoire resteront probablement chers
    • Dans certaines régions où l’électricité est coûteuse, le point mort peut tomber à environ un an
  • La consommation électrique est souvent plus faible que prévu
    • À 1,2kw en pleine charge, cela représente environ 0,12 $/heure, et encore moins avec du solaire
    • Contrairement au jeu vidéo, l’inférence sollicite peu la puissance, avec un système à 200W au repos et 350–450W en inférence
  • Concernant le moment d’achat du matériel
    • Ce n’est pas le bon moment pour acheter ; la prochaine bonne fenêtre serait plutôt dans 24 à 36 mois
    • Un Mac mini M4 Pro avec 48gb de RAM unifiée à environ 2 000 $ est recommandé comme machine d’inférence à budget contenu, capable d’environ 150tok/s et potentiellement utilisable pendant 10 ans
    • Une AMD R9700 avec 32gb de VRAM à environ 1 200–1 400 $ serait plus intéressante pour l’IA que 2x 9070
  • La location via abonnement cloud reste aussi une stratégie légitime ; tout le monde ne peut pas investir de grosses sommes dans du matériel

Évaluation face aux modèles frontier

  • Les modèles locaux sont régulièrement décrits comme ayant « la qualité des modèles de pointe d’il y a 8 à 12 mois »
    • Sur les benchmarks, Qwen 3.6 35B-A3B dépasse Claude 4 Opus, mais certains soupçonnent un possible benchmark gaming de certains modèles open source
    • Dans un test YouTube de browser OS, Qwen 3.6 a produit plus de fonctionnalités opérationnelles que Claude 4 Opus
    • Mais cela correspondrait aux modèles frontier d’il y a un an, et plusieurs contestent toute comparaison entre un MoE à 3B actifs et les Opus/Sonnet récents
  • Le débat porte largement sur une définition incohérente de « niveau Opus »
    • Le terme est utilisé depuis Claude 3 Opus en 2024, mais l’écart reste net avec les modèles récents comme Opus 4.8 ou 4.6
    • Un saut progressif des modèles frontier a eu lieu à partir d’Opus 4.5 et GPT 5.2 en novembre dernier, et « niveau Opus » désigne souvent en pratique l’après-4.5
    • Les plus grands modèles à poids ouverts exigent du matériel de type serveurs 8x H100, et les modèles domestiques n’y sont pas encore
  • Certains situent les modèles locaux entre Haiku 4.5 et Sonnet 4.5, avec de bons résultats à condition de les microgérer
  • L’écart entre frontier et local existera probablement toujours, mais pour beaucoup d’utilisateurs le local est déjà assez pratique

Harness et stratégies de workflow

  • Pi harness est la recommandation la plus fréquente, avec une logique de kit de développement agentique, comparé à « neovim pour le vscode de Claude »
    • Il fournit les outils de base (accès fichiers, édition, bash) et peut être étendu avec des adaptateurs MCP et de la recherche web
    • La commande /tree permet de revenir dans le contexte avant un appel d’outil raté, et /new réinitialise le contexte
  • Les workflows hiérarchiques et à répartition des rôles servent à compenser les limites
    • Répartition du travail où un modèle frontier rédige les specs, l’architecture et le plan d’exécution, puis un modèle local implémente
    • Des agents sont chaînés par rôle (chef de projet, agent de schéma, agent de codage), avec un orchestrateur et Playwright pour ne transmettre à l’étape suivante que les erreurs
    • Les tâches sont découpées en TODO atomiques et les fichiers de référence explicitement indiqués pour économiser le contexte
  • OpenCode modifie parfois le prompt système à chaque tour, ce qui le rend incompatible avec le KV cache, et sa configuration de prise en charge des LLM locaux est manuelle et complexe
  • Ollama est critiqué pour l’ajout de modèles cloud et sa monétisation ; llama.cpp et llama-swap sont préférés, et sur macOS llm-mlx est 10 à 15 % plus rapide

Exemples concrets de configuration

  • Dans un environnement AMD 7900xtx 24gb + 5950x + 64gb DDR4, Qwen3.6-27B-MTP-UD-Q4_K_XL tourne via llama.cpp Vulkan
    • Principaux flags : -ngl 99 (offload GPU de toutes les couches), -c 80000 (contexte 80K), --cache-type-k q8_0 --cache-type-v q8_0 (KV cache 8 bits), -fa on (flash attention), --spec-type draft-mtp (brouillon MTP)
    • Sampling : --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 (valeurs recommandées par Qwen pour le code)
    • Performances : génération ~65t/s, traitement du prompt ~600t/s, cold start ~30 secondes
    • Combinaison Crush harness + Headroom + recherche web Exa MCP ayant permis de résilier un abonnement personnel à Claude Code
  • Sur V100 32GB, Qwen3.6-27B-UD-Q4_K_XL + Pi avec fork llama-cpp-turboquant et patch MTP appliqué
    • 200 000 de contexte, --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 pour 45–60 t/s
  • Sur Strix Halo 128GB, Qwen3.6-35B-A3B atteint ~800tps au traitement du prompt et 50tps en génération, avec une consommation quasi nulle au repos
    • Regret de l’absence d’une version 122B, les modèles denses restant lents dans un environnement à mémoire unifiée à cause de la bande passante mémoire
  • Certains se plaignent aussi du manque de détails et demandent que soient précisés systématiquement quantification, paramètres, contexte, GPU, VRAM et harness

À lire aussi

2 commentaires

 
b89kim 1 시간 전

Quand j’ai utilisé Pi-coding-agent+Qwen3.6-27B-MTP-GGUF, j’obtenais des performances du niveau de Sonnet 4.5. C’était suffisant pour créer une application simple, et au besoin j’y branchais parfois une API gratuite (comme GLM5.1). La consommation électrique d’un GPU de classe 4090/5090 est certes élevée, mais avec un agent correctement conçu, il n’y a finalement pas souvent besoin de le faire tourner pendant des heures.
 
GN⁺ 9 시간 전
Avis sur Hacker News

  • Greenpants : la confidentialité des données et les LLM gratuits sont importants pour moi, donc j’utilise Pi coding harness dans un conteneur/sandbox et entièrement hors ligne
    Sur un Mac Studio 128GB ou un MacBook 36GB, j’utilise Qwen3.6 35B ; comme les paramètres actifs sont de 3B, c’est assez rapide. J’ai entièrement repensé mon site et mon blog avec Django + Wagtail, mais comme Wagtail est moins connu, l’agent ne le maîtrise pas toujours bien sans Internet
    Pour les tâches complexes, j’ai aussi utilisé Qwen3.5 122B, mais avec 10B de paramètres actifs il est bien plus lent. Par rapport à de grands modèles comme Claude, il faut poser les questions avec une très grande précision, et les hypothèses laissées implicites sont souvent traitées par la voie la plus simple, avec des choix d’architecture discutables comme mettre le CSS dans le HTML
    Les appels aux outils d’édition se trompent aussi souvent et tombent dans des boucles. Qwen3.6 35B a une culture générale globale, mais ressemble à un junior qu’il faut guider en permanence, alors que Claude Opus se rapproche d’un senior qui réfléchit avec toi à l’architecture. Si Opus apporte un gain de vitesse de 15x, Qwen entièrement hors ligne est plutôt autour de 5x, mais c’est malgré tout impressionnant vu que c’est gratuit

    • lambda : un peu pareil, je fais tourner Pi dans un conteneur et je le connecte à llama.cpp dans un autre conteneur
      J’autorise l’accès réseau mais je bloque les identifiants, et je limite l’accès au répertoire de travail et à ~/.pi. J’utilise un laptop Strix Halo avec 128GiB de mémoire unifiée et, comme je préfère ne pas programmer avec des outils propriétaires, je ne peux pas vraiment comparer sérieusement avec les frontier models
      Je reste encore sceptique vis-à-vis de l’IA, donc je passe souvent plus de temps à essayer de casser les modèles et à examiner leurs points forts et faibles qu’à les utiliser en pratique, mais pour le coding agentique je choisis le plus souvent Qwen 3.6 35B-A3B. Pour le chat général et la traduction, j’utilise souvent Gemma 4 31B ; pour l’audio, Gemma 4 12B
      Je garde aussi Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 et GPT-OSS 120B, mais dans cette configuration, pour le code, Qwen 3.6 35B-A3B est actuellement ce qui se rapproche le plus du sweet spot
    • geophile : j’ai quasiment la même expérience. Il faut planifier avec énormément de soin, découper en petites étapes indépendantes, et l’humain doit aussi écrire clairement la conception
      Si on laisse qwen remplir lui-même les détails, il se met à boucler juste avant la phase de rédaction. Le problème de l’impossibilité d’éditer était aussi étrange, donc j’ai modifié AGENTS.md pour limiter l’édition plutôt que la réécriture, et ça aide un peu
    • adyavanapalli : pour l’outil d’édition, il pourrait être intéressant d’envisager une approche basée sur des hash, où chaque ligne de code est hashée et les remplacements référencent ce hash
      L’approche est décrite ici : https://blog.can.ac/2026/02/12/the-harness-problem/. Je ne l’ai pas benchmarkée correctement, mais j’ai l’impression qu’elle réduit les erreurs d’édition, même si ça peut varier selon l’environnement

  • horsawlarway : pour un usage personnel, j’ai résilié mon abonnement Claude à 100 dollars par mois et je l’ai remplacé par pi harness pointé vers unsloth studio et des modèles Qwen/Gemma
    Sur une machine dual RTX3090 montée il y a environ cinq ans, je fais tourner unsloth/Qwen3.6-35B-A3B-MTP-GGUF et unsloth/gemma-4-26B-A4B-it-GGUF en quantification UD-Q4_K_XL ; les deux atteignent environ 150 tok/s et gèrent 300k de contexte complet en VRAM
    Ce n’est pas aussi bon que Claude, mais c’est gratuit, et pour un usage personnel cette différence n’est pas vraiment un problème. J’utilise aussi OpenClaw sur le même serveur d’inférence, et c’est un usage qui convient assez bien aux modèles locaux
    Par exemple, j’ai créé un lanceur alternatif pour Android TV, un portail d’administration pour des services k8s, des intégrations et automatisations Home Assistant, de la gestion des courses et des repas, ainsi que des workflows ComfyUI pour générer des assets 3D. Pour du logiciel qui rapporte de l’argent, je recommanderais encore des fournisseurs payants, mais les modèles locaux peuvent déjà faire des choses assez formidables

    • rootlocus : deux RTX3090, c’est environ 4 400 dollars, donc même sans compter l’électricité et les autres composants, ça représente 3,6 ans de Claude à 100 dollars par mois
    • kpw94 : si tu fais tourner gemma quantifié en UD-Q4_K_XL, ça vaut aussi le coup de regarder des modèles QAT comme unsloth/gemma-4-26B-A4B-it-qat-GGUF
      Voir https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF et https://blog.google/innovation-and-ai/technology/developers-.... La mise à jour du 9 juin a aussi ajouté le support MTP
    • twothreeone : j’ai essayé le même unsloth/Qwen3.6-35B-A3B-MTP-GGUF sur une seule 3090, avec 128k de contexte et une quantification Q4_K, et j’obtenais autour de 40–60 tok/s
      Ce qui m’a le plus dérangé, c’était la qualité de sortie sur des tâches de code réelles d’une complexité intermédiaire. Je devais sans cesse alterner entre « pousser via le prompt » et « implémenter moi-même », avec un coût cognitif élevé lié à ce changement de contexte, et je devais décider toutes les quelques minutes si c’était moi qui donnais mal les instructions ou si le modèle était en cause
      Il gère aussi mal le passage des détails d’implémentation de bas niveau à la conception de haut niveau, et n’arrive même pas facilement à rendre des tableaux. Je n’ai pas ces problèmes avec Claude, donc pour l’instant j’ai du mal à y voir un remplaçant ; j’espère que ce sera possible dans quelques mois. J’ai remplacé Claude CLI par aider, mais ce choix n’est peut-être pas optimal non plus

  • bluejay2387 : Je fais environ 90 % de mon code avec Qwen 3.6 27B, Open Code, des compétences personnalisées et Semble
    Ce n’est pas aussi intelligent que CC ou Codex, mais ça permet de faire la plupart des tâches. J’ai une RTX 6000, donc le TPS est largement assez rapide, et ce GPU était de toute façon destiné à d’autres usages
    Au départ, c’était pour voir jusqu’où on pouvait se rapprocher des modèles frontier, mais c’était suffisamment bon pour que je continue à l’utiliser. Pour les tâches vraiment complexes ou pour peaufiner l’UI, je reviens encore à Codex, et l’UI semble être le point faible principal de Qwen
    Je ne le recommande pas vraiment. Peu de gens ont une RTX 6000, et le coût représente plusieurs années d’abonnement à MAX CC ou Codex. Mais c’est prometteur, et dans quelques années ça pourrait devenir pratique
    Avec un contexte de 256k, j’ai réglé la cible de compactage à 75 %, et quand une conversation dépasse 100k, la qualité et la vitesse commencent à baisser ; après 150k, ça devient très problématique. J’ai aussi essayé Qwen 3.5 122B, mais il codait bien moins bien que 3.6 27B. Gemma 4 31B est bon pour d’autres tâches, mais pour le code Qwen passe devant, et Nemotron Super 120B m’a aussi surpris en étant moins bon que Qwen sur le code

    • heipei : Je fais tourner Qwen 3.6 27B Q6 avec llama.cpp sur une RTX 5090, et désormais je n’utilise plus que pi agent
      En local, je n’ai plus du tout à me soucier du prix au token, des quotas, des fuseaux horaires ou de la sensibilité des données. J’ai limité la puissance du GPU de 600 W à 450 W, et même pendant l’inférence il reste très silencieux
      Je m’en sers beaucoup, pas seulement pour coder mais aussi pour les petites tâches du quotidien. Je lui fais faire des choses comme commit sur une branche et créer une PR, récupérer les factures impayées et en retard via Stripe CLI pour les rapprocher avec un CSV bancaire, résumer la cause de la charge actuelle avec des identifiants Elasticsearch, ou trouver si la codebase prend en charge X et où c’est implémenté
    • bo1024 : Qwen3.5-122B est en réalité Qwen3.5-122B-A10B
      A10B est un modèle mixture-of-experts, donc seulement 10B de paramètres sont activés à la fois, tandis que Qwen3.6-27B est un modèle dense où les 27B de paramètres sont toujours actifs. C’est pourquoi, sur beaucoup de tâches, le modèle dense 27B peut être meilleur que 122B-A10B
    • user43928 : Au travail, on nous force à utiliser Qwen 3.6 27B, et je le trouve quasiment inutile
      Mieux vaut faire les choses soi-même ; soit il produit une implémentation bancale, soit il se trompe complètement en débogage. À part une recherche un peu plus intelligente, tout ce qui est en dessous de Sonnet donne l’impression de faire perdre du temps
      Je trouve aussi étrange d’utiliser Codex pour peaufiner l’UI. Codex est connu pour être mauvais sur l’UI et est très loin derrière Claude Opus. Altman a aussi posté qu’ils travaillaient à améliorer ce point dans le prochain modèle

  • pierotofy : La combinaison Llama.cpp + Qwen3.6-35B(MTP) + OpenCode est assez compétente sur une seule RTX 3090, et plus rapide que la plupart des modèles cloud
    En qualité, ça donne l’impression d’utiliser un modèle de pointe d’il y a 8 à 12 mois. J’ai résumé la configuration sur https://github.com/pierotofy/LocalCodingLLM/

    • jacobgold : Si on parle d’une « qualité de modèle de pointe d’il y a 8 à 12 mois », c’est excellent pour un hobby, mais pour qu’un développeur pro l’utilise comme outil principal d’agent de code, je pense que le seuil critique remonte à environ six mois, avec l’arrivée de Opus 4.6
    • trueno : J’ai un MacBook Pro M4 Max avec 128 Go et j’aimerais bien tester tout ça, mais je manque de temps
      Je serais curieux d’avoir des retours d’utilisateurs Mac avec une configuration similaire. Je vois beaucoup de débats sur le local, mais les points de référence changent sans cesse et la terminologie ne m’est pas familière. J’aimerais connaître des impressions objectives sur ce qu’on perd et ce qu’on gagne en passant au local
    • atomicnumber3 : Je n’ai désormais plus du tout envie d’utiliser Claude

  • codinhood : Je ne pense pas qu’il y aura beaucoup de « vraies » réponses à cette question. En ce moment, le coût d’opportunité à ne pas utiliser les modèles les plus récents et les meilleurs est trop élevé
    Même en réévaluant tous les mois, j’arrive à la même conclusion. Le temps, l’effort et l’argent nécessaires pour rapprocher les modèles locaux et l’écosystème d’outils de code de Sonnet/Opus dans Claude Code n’en valent pas encore la peine
    Si c’était rentable, ce serait déjà suffisamment disruptif pour faire la une. Je ne nie pas que quelqu’un ait peut-être résolu le problème, mais ça ressemble davantage à l’usage du rasoir d’Occam pour éviter de tomber dans un terrier sans fond

    • pyeri : Ce train du FOMO sur le coût d’opportunité finira par atteindre un point de saturation, et à mon avis c’est déjà le cas
      Les modèles de classe Mythos sont à la pointe du raisonnement, mais dans la plupart des domaines de problèmes que les développeurs cherchent à résoudre, ils n’apportent pas grand-chose. Il est probable qu’autour des versions 4.8 des familles Sonnet/Opus on atteigne finalement le niveau largement adopté en entreprise
      Les modèles locaux n’en sont pas encore là, mais on peut utiliser à bas coût via des API comme NVIDIA, OpenRouter ou Groq des familles comme DeepSeek, Kimi, GPT et MiniMax, et elles sont assez proches de Sonnet
    • mark_l_watson : Ça me semble être la bonne conclusion aussi. Je veux passer à un système en couches allant du local, à des API commerciales comme OpenCode + DeepSeek v4 flash, puis à DeepSeek v4 Pro
      De cette façon, on peut continuer à traiter ce qu’il faut tout en migrant progressivement davantage de choses en local. Même sur le même matériel, la configuration locale est bien meilleure qu’il y a deux mois, et par rapport à il y a six mois, le progrès est spectaculaire
    • gunapologist99 : Il vaut peut-être mieux penser à Pareto plutôt qu’à Occam
      Si tu crois vraiment qu’on y arrivera dans quelques années, mieux vaut commencer à expérimenter dès maintenant, et tu peux être assez surpris, surtout sur des projets courts ou petits, ou sur de gros projets bien modularisés

  • sosodev : Cette question couvre un éventail beaucoup trop large de capacités et d’attentes. Si on ne fait tourner qu’un modèle 8B tout en espérant du vibe coding ou du one-shot, ça va être compliqué.
    Si vous pouvez faire tourner un modèle d’environ 30B, il s’en sort plutôt bien sur des tâches au périmètre adapté et bien défini. Dans cette gamme, Gemma4-31B et Qwen3.6-27B semblent actuellement les meilleurs.
    Si vous voulez une inférence plus rapide, vous pouvez passer à un modèle MoE, mais sur la plupart des tâches ça baisse nettement. Pour des tâches de petite portée, le one-shot et le vibe coding sont possibles, mais c’est encore bien mieux avec du guidage.
    Si vous voulez des capacités de niveau frontier, il faut au moins 128 Go de mémoire et une grosse puissance de calcul, ou alors énormément de patience. La plupart des gens manquent d’argent ou de patience. Avec les modèles locaux, la patience ne consiste pas seulement à attendre les tokens, mais aussi à faire l’effort de tout configurer et de le faire tourner correctement selon son workflow et son matériel.

    • argee : Sur un MacBook M4 Pro avec 48 Go de RAM, j’utilise Gemma 4 26B A4B pour apprendre Rust et répondre à diverses questions.
      Je ne crois pas qu’il soit très bon en one-shot au-delà de changements vraiment mineurs dans l’IDE ou le harnais de test. Cela dit, si un humain garde les mains sur le volant, regarde la route et roule sous la limitation, c’est rapide et largement assez bon comme copilote sur des tâches à petit ou moyen contexte.
      Comparé à il y a quelques années, c’est impressionnant, et sans ça je n’aurais presque pas fait de codage avec l’IA. Je déteste l’idée de devenir stupide ou bloqué juste parce que la connexion Internet tombe.
    • user43928 : J’ai demandé à un petit modèle, en particulier GPT 5.4 Mini, de déplacer une modification de 10 à 20 lignes de code vers un autre fichier, et même au deuxième essai il a changé le code et introduit un bug.
      Je n’attendais pas une fiabilité parfaite, mais je pensais qu’en lui signalant la différence il saurait au moins corriger au deuxième coup. En réalité, il a affirmé avec assurance que le code était identique, tout en ajoutant encore un autre bug subtil.
      Je ne vois pas quel travail serait suffisant pour ce genre de modèle de pacotille. Il peut faire semblant d’être compétent pendant quelques minutes, mais le résultat finit quand même par être faux. À la rigueur, je le trouve bon pour une recherche un peu plus intelligente ou de l’autocomplétion.

  • mgsram : Après environ un an à utiliser des LLM locaux, je me suis maintenant stabilisé sur une combinaison Qwen3.6 27B dense GGUF, OpenCode et llmster (LM Studio) sur un Mac Studio avec 512 Go de RAM.
    J’ai aussi essayé Qwen 3.6 35B-A3B, mais la précision du modèle dense est un cran au-dessus, au prix d’un débit tokens/s plus faible. Qwen3.6 27B tourne en général autour de 25 à 40 tok/s.
    Au début je l’utilisais pour des outils simples, mais depuis 3 à 4 mois je m’en sers réellement pour du codage de niveau production sur une stack logicielle automobile en C/C++ et des outils Python. Le fait que ce soit plus lent m’aide même à avancer à un rythme approprié.
    Pour le développement neuf ou les réécritures, je travaille avec Sonnet pour produire la conception, l’architecture, le raisonnement et un plan d’exécution détaillé, puis je découpe tout ça en prompts précis. Pour le travail sur du code existant, il faut du jugement, et quand je sens les limites du modèle local je reviens à Claude Code.
    Récemment, avec Qwen 3.6, j’ai réécrit entièrement un service de gestion d’alimentation en C en me basant sur du code C++ existant, créé un parseur complexe de spécifications Excel, et un outil qui traduit du contenu CJK en anglais pour l’injecter dans un KG.

  • 3abiton : Puisque tout le monde parle de Qwen, moi aussi je fais tourner Qwen 3.6 35B Q8(MTP) avec Strix Halo et llama.cpp.
    J’obtiens environ 40 à 50 t/s et les performances sont vraiment bonnes. Je l’ai utilisé directement avec forge-code dans zsh, et sur de longs contextes au-delà de 150k la qualité baisse et il commence à oublier.

  • wsintra2022 : En lisant les commentaires ici, je n’arrive pas à distinguer ceux qui sont des bots cherchant à décourager le local au profit des fournisseurs d’IA, et ceux qui ont réellement eu une mauvaise expérience avec des modèles d’IA locaux.
    Faire tourner Qwen 3.6 27B quantifié en 8k sur un Mac Studio 64 Go, ce n’est pas une super-intelligence universelle de niveau frontier, c’est juste bien. C’est gratuit, privé, et le vrai tour de magie, c’est de faire passer un ingénieur expérimenté de paresseux à encore plus paresseux.
    J’utilise llama.cpp et opencode pour planifier et exécuter des modifications de code, puis je vais m’allonger dans un hamac, faire la vaisselle ou autre chose. Je vérifie ensuite via tmux et ssh. C’est ça, la partie vraiment bluffante.

    • epolanski : Dans le secteur de l’« ingénierie » logicielle, il y a tellement de ninjas du Leetcode du MIT qui produisent de la bouillie inutilisable en React+Tailwind avec des fuites mémoire que le niveau de base est extrêmement bas.

  • garethsprice : Sur une Ada 4000 avec 20 Go de VRAM, j’utilise OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM, et la génération tourne autour de 55 tok/s.
    Comme OpenCode attache beaucoup de contexte, en pratique c’est plus lent que ce que le chiffre laisse penser. On parle aussi beaucoup de Pi, donc je vais bientôt regarder ça.
    Je fais le plan avec Opus, je laisse l’agent local l’exécuter, puis je vérifie avec Opus. Ce n’est donc pas 100 % local, mais ces modèles deviennent de plus en plus une partie du workflow de production.
    Pour l’instant, à moins d’aimer bricoler ça comme hobby en y mettant du temps et de l’argent, ce n’est peut-être pas très intéressant. Ce n’est pas aussi bon qu’Opus ou d’autres modèles frontier, mais sur un périmètre où les tâches répétitives augmentent, c’est « suffisamment bon ».
    Pas besoin d’une Rolls Royce pour aller au supermarché : une Corolla d’occasion suffit. Ça rend possibles de nouveaux workflows qui coûteraient trop cher avec des LLM frontier. J’ai lancé pendant la nuit des tests de fuzzing via Chrome devtools MCP en simulant un utilisateur, avec vérification multimodale des captures d’écran, et quand je pense au coût de Claude + captures d’écran, c’est étonnant.
    La formule « 12 à 18 mois derrière le frontier » me paraît juste. Dans 12 à 18 mois, on pourra sans doute faire tourner localement un modèle de niveau Opus pour moins de 5 000 dollars, mais les modèles frontier auront eux aussi encore avancé.

  • arjie : Ce n’est ni local ni du codage conversationnel, mais je fais tourner DeepSeek V4 Flash avec deux RTX Pro 6000 Blackwell.
    La vitesse brute est de 160 tok/s, mais c’est un modèle de raisonnement. Mon usage, c’est l’écriture automatique de code et la revue automatique d’autres systèmes. Il m’arrive de faire écrire du code par Pi, et c’est très rapide, mais par habitude j’utilise surtout encore CC et Codex.

    • akersten : Je me demande où tu as réussi à trouver des RTX Pro 6000 Blackwell.
      Tous les sites que j’ai trouvés étaient soit en rupture de stock, soit réservés aux entreprises, soit franchement suspects.
    • leptons : Je me demande si tu as mesuré la consommation électrique de ce matériel. Le coût mensuel m’inquiète.

  • stymaar : fait tourner Qwen3.6-35B-A3B sur un Strix Halo 128GB Bosgame M5
    La VRAM est largement excessive pour ce modèle, mais Qwen n’a pas sorti de version 122B de Qwen3.6 qui conviendrait le mieux à son matériel. En revanche, la facture d’électricité est presque négligeable. Comme c’est à l’origine une puce de portable, ça consomme à peine au repos, et même pendant le traitement des prompts, ça dépasse seulement un peu les 120 W
    Qwen3.6 est étonnamment efficace, au point qu’il n’utilise Claude qu’occasionnellement, pour environ 10 % de ses besoins totaux. Même avec l’offre la moins chère, il reste sous son quota. Côté vitesse, c’est environ 800 tps en traitement de prompt et 50 tps en génération de tokens, sans speculative decoding

    • manmal : se demande s’il a aussi essayé la version dense 27B. Elle est bien meilleure pour le code

  • Kostic : pour un usage perso, fait tourner Qwen 3.6 27B ou Gemma 4 31B en reliant VSCode à llama.cpp, suffisamment bien pour pouvoir se passer d’un abonnement cloud
    Qwen tourne sur le premier GPU en q4@176k de contexte, avec MTP à environ 70~50 tok/s, ce qui est plutôt bon pour coder. Gemma utilise les deux GPU en q8@64k de contexte pour l’analyse de sentiment de documents, le résumé, la correction et la traduction à 25 tok/s
    C’est un peu lent pour des workflows par lots, mais ça reste exploitable. Il pense que ça pourrait encore augmenter si llama.cpp prenait en charge MTP en mode tensor split
    Au travail, comme ce n’est pas lui qui paie, il utilise toujours des LLM de pointe, et évidemment ils sont meilleurs. Il espère que d’ici un an, on aura des modèles 30B au niveau de Sonnet 4.6 / Opus 4.5
    Le traitement des prompts commence à 800 t/s puis redescend jusqu’à 400 t/s. Comme ses prompts initiaux font généralement 16k à 24k tokens, le traitement prend 60 à 90 secondes ; ce n’est pas idéal, mais c’est acceptable

  • jodoherty : utilise Gemma 4 31B sur une RTX Pro 6000 Blackwell via Pi pour tout le coding agentique
    Il trouve ça utile, et ce side project ressemble à la façon dont il cadre et traite les projets au travail : https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    Il faut appliquer une architecture réfléchie et beaucoup de TDD. L’idée est de traiter les parties difficiles tôt, puis de les encapsuler derrière une interface simple et facile à utiliser afin d’éliminer le risque technique
    Sur certains projets, c’est 2 à 3 fois plus rapide que d’écrire directement à la main, et sur les projets ennuyeux ou très larges, ça permet de rassembler et tester vite des idées, avec un gain de temps de 5 à 10x
    Son setup alterne entre vLLM avec nvidia/Gemma-4-31B-IT-NVFP4 et llama.cpp avec unsloth/gemma-4-31B-it-qat-GGUF, qui a MTP. La puissance GPU est limitée à 400 W. Actuellement, sa config llama.cpp sort 60 à 150 t/s selon le taux d’acceptation des brouillons MTP, et le prefill atteint 1500 à 4000 t/s selon la longueur et la profondeur du contexte

  • jborak : fait tourner Qwen3.6 27B MTP Q6_K sur llama.cpp avec quatre RTX 5070 et un AMD Threadripper 1950X de première génération, et l’utilise très bien comme driver quotidien dans Pi
    La vitesse est d’environ 50 à 60 tok/s. Il y connecte aussi d’autres applis comme OpenWeb UI, et récemment il a défini la gateway LLM Bifrost comme point d’entrée par défaut pour l’accès aux modèles
    Il a aussi essayé Qwen3.6 35B A3B, mais pour le code, le 27B lui convient mieux. C’est un modèle dense donc plus lent, mais la qualité lui paraît nettement meilleure. Le 35B A3B monte à 130~140 tok/s sans MTP, donc c’est incroyablement rapide
    Il n’est pas indispensable d’avoir quatre 5070 pour faire tourner Qwen3.6 27B ; trois, voire peut-être deux, peuvent suffire. En revanche, si on utilise MTP pour accélérer le 27B, le modèle de draft a besoin de son propre contexte, donc ça consomme plus de mémoire
    Il faut aussi garder en tête que le prompt système des outils est chargé dans le modèle à chaque conversation. Quand il lance Pi, le départ est très réactif, mais en interagissant via Hermes CLI, chaque prompt embarque beaucoup de contexte — skills, tools, etc. — qui reste jusqu’à la fin de la conversation, donc ça ralentit nettement
    La confidentialité est appréciable, mais le fait de ne pas avoir de quotas ni à se soucier de l’usage l’est tout autant. Si l’avenir est au « loop engineering », alors avec les modèles cloud on va brûler des tokens et de l’argent. Son système consomme 200 W au repos et 350 à 450 W sous forte charge d’inférence, et le décodage n’est pas très efficace, donc les GPU restent inactifs plus souvent qu’on ne le pense. Des avancées comme la diffusion pourraient peut-être accélérer le décodage et mieux utiliser les GPU inactifs

    • zakisaad : se demande pourquoi il a choisi des 5070 pour une config à quatre cartes
      À première vue, ça semble orienté calcul avec une VRAM insuffisante ; donc bien pour les joueurs, mais pas très adapté à l’exécution de LLM. Il utilise lui aussi une 5070 sur son desktop

  • cuttysnark : a obtenu un certain succès avec des modèles locaux reliés en workflow d’agents
    Chaque agent utilise des prompts différents et un modèle ollama différent selon son rôle. Un agent chef de projet ou schéma (qwen3:14b) n’utilise pas le même modèle qu’un agent de code (qwen2.5-coder:7b)
    Entre chaque étape, il y a un orchestrateur et des tâches Playwright, afin d’exposer les erreurs à l’agent qui a produit le bloc de code précédent. Seuls les blocs sans erreur passent à l’étape suivante
    La plus grosse amélioration a été d’ajouter une définition de service backend-for-agents pour que l’agent de schéma ne produise qu’un manifest basé sur les tâches avant de le passer à l’agent suivant. En résumé, il définit le workflow de façon à découper le travail pour que les agents ne fassent que des tâches très spécifiques, puis transmettent à l’étape suivante. Ça leur évite de perdre le fil, et ça crée aussi des points d’entrée pour un humain dans les flux qui réussissent à 25 % ou à 90 %

    • pianopatrick : pense que des benchmarks et compétitions de workflows de ce type permettraient de voir ce qui fonctionne bien
      Quelque chose du genre : « avec seulement ce GPU grand public, utilisez le modèle et le workflow de votre choix pour résoudre le mieux possible tel benchmark xyz ». Donner par exemple une heure maximum aux participants, puis noter le pourcentage de réponses, le taux de justesse et le temps total, dans un format type « The Local AI challenge »
    • sowbug : se demande s’il a essayé de faire concurrencer les agents entre eux
      Par exemple, donner la même tâche de code à deux modèles, ou au même modèle avec des seeds différentes, puis laisser un reviewer choisir le meilleur résultat. Il existe une théorie selon laquelle le cerveau humain fonctionne aussi comme ça, avec des milliers de mini-colonnes corticales qui voient les situations un peu différemment puis votent à la majorité

  • HappySweeney : Avec de l’Optane et beaucoup de RAM, j’ai essayé pendant la nuit un modèle proche du modèle complet pour écrire des fonctions, à environ 0,7 t/s.
    En ce moment, le test consiste à remplacer une fonction Scala par une fonction de transposition de matrice de bits utilisant AVX512. Les modèles cloud s’en sortent facilement, mais Kimi 2.6 et GLM 5.1 échouent lamentablement.

  • etoxin : Je n’ai pas encore réussi à remplacer complètement. Sur les projets pro, j’utilise openspec, et au lieu de dépenser une fortune pour reproduire du matériel local, je paie pour utiliser des versions hébergées des derniers modèles locaux populaires.
    La plupart des petits modèles locaux gèrent mal les appels d’outils, mais les plus gros commencent désormais à bien s’en sortir. Un point encore peu pris en compte côté local, c’est que les ingénieurs productifs font souvent tourner plusieurs chats CLI en parallèle avec git worktree. Moi, j’ai en général 3 worktrees et chats CLI ouverts.

  • blurbleblurble : À ce stade, je pense que la limite vient moins des modèles eux-mêmes que de l’utilisabilité des harnais alternatifs, auxquels il manque bizarrement des fonctions comme la gestion de file d’attente, l’interruption, les sous-agents ou les objectifs.

    • coder543 : Entièrement d’accord. Le fait qu’OpenCode ne cherche pas vraiment à bien prendre en charge les LLM locaux est aussi agaçant.
      On peut faire fonctionner OpenCode, mais la configuration est très manuelle et maladroite. J’ai écrit un script qui convertit automatiquement une configuration llama-server en configuration OpenCode, et ça aide, mais ce n’est pas idéal.
      J’ai sérieusement envisagé de créer encore un autre harnais de codage sur mon temps libre. J’ai quelques idées pour faire mieux.
    • horsawlarway : Pi est correct.
      J’ai utilisé les agents CLI de Claude, Cursor et Pi, ainsi que des harnais personnalisés faits maison, et même gastown ; Pi est simplement suffisant. Il fait le travail, les outils de base sont corrects, il s’intègre bien avec les autres outils et demande moins d’attention.
      Si l’on peut faire tourner des modèles autour de 30B à une vitesse correcte, beaucoup de gens seront assez surpris par Pi. Avec des extensions comme https://pi.dev/packages/pi-mcp-adapter?name=mcp et https://pi.dev/packages/pi-web-access?name=search, on obtient aussi des outils web, de la recherche perplexity, et un accès MCP pour piloter Chrome via https://browsermcp.io/ ou Firefox via https://github.com/mozilla/firefox-devtools-mcp.
      Ce n’est pas au niveau des meilleurs modèles subventionnés, mais c’est gratuit et reste compétent. Personnellement, j’utilise aussi beaucoup https://pi.dev/docs/latest/sdk, qui est très amusant, alors que d’autres fournisseurs facturent des milliers de dollars par mois pour ce type d’accès API.
    • Insanity : J’ai entendu de bonnes choses sur pi.dev, mais je ne l’ai pas encore essayé. Ça pourrait régler une partie des fonctions manquantes mentionnées.

  • _bobm : Quand on parle de modèles Claude/GPT, il faut réfléchir à ce que ce “modèle” est réellement.
    Il suffit de penser à la manière dont GPT peut envoyer les parties de raisonnement étape par étape, avec en plus un résumé sous forme d’en-tête Markdown du bloc de pensée lui-même. Si l’on observe l’endpoint API et le comportement de sortie, les prétendus modèles SOTA ne sont pas ce qu’ils semblent être, et ils ne sont absolument pas comparables aux modèles locaux du point de vue de l’infrastructure.
    À cette échelle d’exploitation, il y a une énorme orchestration, et ses contraintes mènent à une innovation dont on parle peu. Je ne pense pas que ce soit impossible à rattraper, mais servir un modèle local avec llama ou vLLM n’en est qu’au niveau A, B, C de l’alphabet.
    Ce qu’il faut réellement, à mon avis, c’est reproduire l’orchestration évoquée plus haut. Les “modèles” SOTA ne sont pas un unique modèle, mais une orchestration profonde de plusieurs modèles qui travaillent ensemble. Par conséquent, un modèle unique ne pourra pas les rattraper tant qu’il ne reproduira pas cette orchestration à l’entraînement et dans l’architecture.
    Je ne pense pas que le modèle lui-même, dans cette configuration orchestrée proposée au grand public, soit tellement supérieur à Qwen 3.6. Si l’on change de perspective, on commence à voir l’ampleur de la “magie”.

    • XCSme : Je ne vois pas pourquoi tu penses que les modèles SOTA sont une orchestration profonde de plusieurs modèles.
      J’aimerais aussi voir un exemple concret de GPT envoyant une partie de raisonnement accompagnée d’un résumé en en-tête Markdown.

  • cheekygeeky : Le développeur logiciel avec qui je travaille est la personne la plus intelligente que j’aie rencontrée, et il utilise OpenCode et Tmux avec des modèles open source.
    Pour le code, il préfère nettement DeepSeek et le qualifie de “plutôt bon”. Il le fait tourner sur un i9, 128 Go de RAM et deux 3090. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick : J’aimerais qu’il existe des benchmarks et compétitions pour ce type de workflow, afin de savoir ce qui fonctionne bien.
    Quelque chose du genre : “avec uniquement ce GPU grand public, et le modèle et workflow de votre choix, à quel point résolvez-vous bien le benchmark xyz”. J’aimerais voir une compétition de type “The Local AI challenge”, où les participants ont jusqu’à 1 heure et sont notés selon le taux de réponse, le taux de bonnes réponses et le temps d’achèvement.

  • bravetraveler : J’utilise ça presque “bio”, et le peu d’usage de LLM que j’ai est entièrement local.
    Sur un système Strix avec 128 Go, des variantes moins denses de Qwen ou Gemma produisent entre 50 et 80 tok/s. Je n’ai aucune intention de m’abonner à Anthropic/OpenAI, et même si c’était le dernier modèle local disponible, je n’en aurais pas besoin. L’usage d’outils à l’intérieur du modèle compense les inquiétudes liées à l’actualité.

  • GodelNumbering : En tant que personne qui discute avec des LLM toute la journée, je pense que la combinaison modèle frontier open source + bon harnais est déjà suffisante.
    Pour un déploiement local, il faudra encore une ou deux générations de matériel avant de pouvoir basculer complètement. Cela dit, comme les fabricants de matériel privilégient fortement les datacenters, ce moment pourrait ne pas arriver rapidement.

  • milchek : J’ai essayé sur un MacBook Pro 36 Go, mais ça n’a pas été très concluant dès qu’on dépassait des tâches très basiques
    Même avec de petits modèles, le contexte s’épuise vite et la lenteur posait problème. Pour obtenir des performances à peu près correctes, il semble qu’il faille 128 Go de mémoire, ce qui fait fortement grimper le coût du matériel
    Au final, la question est de savoir s’il vaut mieux payer un abonnement à des modèles frontier ou immobiliser cet argent dans du matériel. Bien sûr, si la confidentialité est importante, il n’y a pratiquement pas d’autre choix que de dépenser pour du matériel haut de gamme

  • acc_297 : Je me demande si appliquer du RLHF au quotidien à un modèle de taille intermédiaire, à chaque prompt, pour l’ajuster finement à mes habitudes d’usage personnelles pourrait aider
    Je ne sais pas si affiner manuellement le modèle l’abîmerait ou l’améliorerait. Ce serait bien si un retour assidu permettait de réduire certains tics des modèles généralistes, comme la flatterie excessive, la verbosité ou cette manie agaçante d’expliquer par des analogies, mais je ne sais pas si les retours sur prompts d’une seule personne suffiraient
    J’entends aussi dire que des agents internes affinés sur de la documentation maison ont des comportements bizarres et ne sont pas forcément plus utiles que les modèles standard. Ce serait bien de pouvoir éditer toutes les réponses de l’agent, puis l’affiner à partir des différences entre l’original et la version éditée
    Personnellement, je supprimerais beaucoup d’adjectifs pour épurer les réponses vers l’essentiel, mais en voyant les travaux de chercheurs en alignment comme Owain Evans, je crains que ce type d’ajustement ne pousse le modèle vers des tendances imprévisibles

    • htrp : Cursor fait ce genre de choses. Ils semblent sans doute utiliser Fireworks comme fournisseur : https://cursor.com/blog/real-time-rl-for-composer
    • rolisz : J’aimerais essayer quelque chose de similaire avec l’agent OpenClaw
      Il me semble que le travail d’Owain Evans relevait du SFT. Quelqu’un sur Twitter disait que le RL est moins vulnérable au phénomène qu’il a montré, donc j’aimerais bien expérimenter moi-même

  • heisenbit : Il faut un peu de travail de configuration, mais j’apprends beaucoup au passage
    Sur un M4 MBP 48 Go, j’utilise surtout qwen/qwen3.6-35b-a3b mlx, et il reste tout juste assez de marge pour un Docker dev-container et des tâches de base. Je le lance avec LM Studio et l’utilise dans VSCode
    Modifier le prompt système pour améliorer l’intégration des outils a fait une énorme différence. Avant ça, au lieu d’appliquer les changements, il régénérait le code, ce qui cassait souvent plus de choses que ça n’en aidait
    Pour éviter le bruit et la chauffe, je l’utilise la plupart du temps en mode basse consommation, même branché sur secteur. Les performances maximales doublent à peu près la vitesse, mais consomment plus du double d’énergie
    Ce qu’il a pu faire, c’était tout au plus une simple réorganisation d’une page, et il a échoué à séparer un store Pinia. GPT-5.4 réalise cette tâche sans problème. Je pense qu’en affinant davantage le guide d’usage des outils et les outils de support autour, les performances pourraient encore monter

  • nfrankel : J’ai essayé, et en théorie ça fonctionne : https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    Les résultats varient selon le modèle, et au bout du compte c’est l’ordinateur qui limite. Ma machine ne suivait malheureusement pas

  • K0balt : J’obtiens d’assez bons résultats avec qwen 3.6 27b dense
    Selon la tâche, c’est comparable à Claude Haiku 4.5, voire parfois au niveau de Sonnet

    • kadoban : Je suis curieux de savoir avec quels outils tu fais tourner ton workflow
    • kandros : Pour des tâches de code, je préférerais encore demander au boucher plutôt qu’à Haiku

  • jderekw : J’utilise AMD Lemonade sur mon équipement du quotidien
    J’ai commencé avec Ollama, puis je suis passé à LMStudio, et maintenant j’ai standardisé sur AMD Lemonade, qui aide à surveiller la cRAM, le CPU, le GPU et la gRAM. Grâce à la fonction multi-modèle de Lemonade, on peut facilement faire tourner une pile LLM, speech-to-text, NPU et génération d’images
    La plateforme fonctionne aussi sur des chipsets Nvidia, Apple, Intel et AMD

  • redox99 : Des modèles qu’on peut faire tourner à la maison, comme Qwen 35B, ne sont absolument pas au niveau d’Opus ou GPT 5.5
    Les modèles open source qui s’en approchent tournent plutôt autour de 1T de paramètres, donc autant oublier l’idée de les exécuter chez soi. C’est un peu comme conduire une vieille épave : il y aura toujours des gens pour dire que tant qu’on va de A à B, ça va, mais non, ça ne va pas
    À moins d’avoir un besoin absolu de confidentialité, de le faire pour le plaisir ou pour un cas très particulier comme l’avion, il n’y a pas de raison rationnelle. Si tu ne peux même pas mettre 20 dollars dans Codex malgré ses énormes subventions, autant utiliser des API de modèles chinois, qui écrasent ces petits modèles

    • pbasista : Je me demande sur quels faits objectifs ou benchmarks repose l’affirmation selon laquelle « des modèles qu’on peut faire tourner chez soi comme Qwen 35B ne sont absolument pas au niveau d’Opus ou GPT 5.5 »
    • xgulfie : Pas besoin d’une Ferrari pour aller au bureau

  • sj_tech : Sur un Mac Mini 128 Go, j’utilise Qwen 3.6 35B A3B avec GitHub Copilot Extension for VSCode pour du coding agentique
    C’est correct au vu de la taille du modèle, mais je le vois partir en boucle quand le problème devient trop gros. C’est utile pour gagner du temps sur des tâches qu’on sait déjà faire soi-même

  • julianlam : Sur un Framework 13 avec 32 Go de mémoire, je fais tourner Qwen 3.6 35B-A3B avec llama.cpp à 15 tok/s
    Il génère du code et du texte plus vite que je ne peux les lire

  • moezd : Pas encore. Sauf dans l’écosystème Apple pur, ou sans GPU correct, même avec beaucoup de RAM et de threads, on plafonne à 30–50 tok/s, et encore avec le thinking désactivé
    Sans ce genre d’optimisations, le modèle engloutit allègrement MCP, skills et descriptions d’agents, et on a le temps de regarder la peinture sécher avant de voir le premier token sortir
    Servir des modèles en local impose d’économiser chaque token de la fenêtre de contexte, ce qui va totalement à l’inverse de la direction dans laquelle Claude/GPT/Copilot tirent l’industrie

    • amarshall : Le thinking ne change pas la vitesse de sortie. La vitesse de sortie médiane des modèles Anthropic tourne autour de 40–60 t/s

  • mitchell_h : J’ai essayé, mais la fenêtre de contexte n’était pas assez grande

    • coder543 : Qwen3.6-27B prend en charge une fenêtre de contexte d’un million de tokens
      Bien sûr, il faut le matériel capable de la faire tourner, et sur mon DGX Spark, le modèle q4_k_xl avec l’intégralité du cache KV en f16 demande environ 100 Go de mémoire
    • lysace : Même constat. Ma RTX 4070 n’a que 12 Go, donc je me demande si 24/32 Go apportent vraiment une amélioration suffisamment utile
    • deadbabe : Il suffit de formuler le prompt de manière plus directe, au lieu de le laisser comme une question ouverte

  • drnick1 : Je me demande quel est actuellement le meilleur modèle de code qu’on puisse faire tourner sur un GPU grand public haut de gamme.
    En supposant qu’on ait une RTX 3090/4090, je me demande aussi quelle stack vous recommanderiez. Un combo du genre Llama.cpp + OpenCode ?

  • bijowo1676 : J’ai trouvé intéressante l’idée d’utiliser un modèle frontier coûteux pour rédiger et mettre à jour des documents Markdown comme les spécifications de l’app, les exigences produit ou l’architecture, puis de faire implémenter ces spécifications par un modèle moins cher ou local.
    Markdown compresse mieux l’information que des centaines de fichiers source et rentre donc mieux dans la fenêtre de contexte, mais il faut des 2e et 3e passes pour lisser les parties les plus grossières. Je me demande si quelqu’un a déjà essayé de travailler comme ça.

  • grmnygrmny2 : J’avais une objection éthique à l’usage des produits OpenAI ou Anthropic, ce qui me rendait aussi réticent à adopter les LLM tout court.
    Les modèles locaux règlent l’essentiel de cette objection morale, donc j’en utilise depuis environ un mois pour le travail et mes projets perso. Le matériel que j’ai, c’est des Mac 32 Go et un PC gaming avec une 3080 10 Go, donc ma limite se situe autour de Qwen3.6-35B-A3B dans diverses quantifications, mais ça suffit.
    J’obtiens environ 200~400 PP et 20~30 TG, et il m’a fallu un peu de temps pour apprendre à bien m’en servir. Pour certaines tâches, il faut le surveiller ou le recadrer, mais c’est assez utile.
    Je n’ai jamais utilisé CC, donc je ne peux pas comparer, mais il fait un bon assistant ou pair programmer, de l’embarqué en C++ jusqu’à Vue. J’aimerais pouvoir faire tourner du 27B, et il y a parfois des moments où ce modèle semble à deux doigts de comprendre quelque chose puis n’y arrive pas, mais c’est rare.
    Sur beaucoup de tâches, ça me fait gagner beaucoup de temps, et il est plutôt bon pour creuser et corriger des bugs même avec des consignes assez vagues. Pour le harness, j’utilise Pi.