Qwen3.6-27B : des performances de codage dignes d’un flagship avec un modèle dense de 27 milliards

 (qwen.ai)
7 points par GN⁺ 2026-04-23 | 4 commentaires | Partager sur WhatsApp
  • Publication d’un modèle multimodal dense de 27 milliards de paramètres, avec prise en charge conjointe des modes thinking et non-thinking ainsi que du traitement d’images et de vidéos dans un point de contrôle unifié
  • Les performances en agentic coding dépassent celles de l’ancien flagship open source Qwen3.5-397B-A17B sur les principaux benchmarks de code, et surpassent même des modèles comptant jusqu’à 15 fois plus de paramètres au total
  • Scores annoncés : SWE-bench Verified 77.2, SWE-bench Pro 53.5, Terminal-Bench 2.0 59.3, SkillsBench 48.2 ; ainsi que 87.8 sur GPQA Diamond et 94.1 sur AIME26 pour le raisonnement textuel et les évaluations STEM
  • L’adoption d’une architecture dense élimine la complexité de routage des MoE, simplifie le déploiement, et s’accompagne d’open weights, d’une API, d’un accès immédiat via Qwen Studio, ainsi que de l’intégration avec OpenClaw, Qwen Code et Claude Code
  • Le modèle montre qu’un modèle dense bien entraîné peut dépasser une génération précédente bien plus grande sur les tâches clés des développeurs, et étend aussi l’orientation agentic coding de la gamme Qwen3.6

Vue d’ensemble

  • Qwen3.6-27B est publié comme un modèle multimodal dense de 27 milliards de paramètres, avec prise en charge conjointe des modes multimodaux thinking et non-thinking
  • En agentic coding, il dépasse l’ancien flagship open source Qwen3.5-397B-A17B sur les principaux benchmarks de code
  • Grâce à une architecture dense sans complexité de routage MoE, son déploiement est plus simple, tout en offrant des performances de codage de premier plan à une échelle pratique et largement diffusable
  • Il est disponible immédiatement dans Qwen Studio, avec des open weights pour la communauté et un accès via API
  • Ses caractéristiques clés incluent un agentic coding de niveau flagship, un raisonnement textuel solide et des capacités de raisonnement multimodal

Performances

  • Qwen3.6-27B a été évalué face à des modèles de référence dense et MoE, avec de fortes améliorations sur les benchmarks d’agentic coding
  • Il est indiqué qu’il dépasse même des modèles jusqu’à 15 fois plus grands en nombre total de paramètres
  • Les évaluations couvrent le langage, les connaissances, le STEM et le raisonnement, la vision-langage, la compréhension de documents, la compréhension vidéo et les visual agents

  • Langage

    • Avec seulement 27 milliards de paramètres, il dépasse Qwen3.5-397B-A17B sur tous les principaux benchmarks de code
      • SWE-bench Verified 77.2 contre 76.2
      • SWE-bench Pro 53.5 contre 50.9
      • Terminal-Bench 2.0 59.3 contre 52.5
      • SkillsBench 48.2 contre 30.0
    • Il devance aussi largement d’autres modèles denses de taille comparable
    • Sur les tâches de raisonnement, il obtient 87.8 sur GPQA Diamond, un niveau compétitif face à des modèles plusieurs fois plus grands
    • Le tableau détaillé compare Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B et Qwen3.6-27B
    • Principaux scores de la catégorie Coding Agent
      • SWE-bench Multilingual 71.3
      • QwenWebBench 1487
      • NL2Repo 36.2
      • Claw-Eval Avg 72.4
      • Claw-Eval Pass^3 60.6
      • QwenClawBench 53.4
    • Principaux scores de la catégorie Knowledge
      • MMLU-Pro 86.2
      • MMLU-Redux 93.5
      • SuperGPQA 66.0
      • C-Eval 91.4
    • Principaux scores de la catégorie STEM et raisonnement
      • HLE 24.0
      • LiveCodeBench v6 83.9
      • HMMT Feb 25 93.8
      • HMMT Nov 25 90.7
      • HMMT Feb 26 84.3
      • IMOAnswerBench 80.8
      • AIME26 94.1

  • Configuration des évaluations de langage

    • La SWE-Bench Series utilise un scaffold agent interne ainsi que les outils bash et d’édition de fichiers, avec temp 1.0, top_p 0.95 et une fenêtre de contexte de 200K
      • Tous les modèles de référence ont été évalués sur un benchmark affiné corrigeant certaines tâches problématiques du jeu public SWE-bench Pro
    • Terminal-Bench 2.0 utilise le harness Harbor ou Terminus-2
      • timeout de 3 heures, 32 CPU, 48 Go de RAM
      • temp 1.0, top_p 0.95, top_k 20, max_tokens 80K, ctx 256K
      • moyenne sur 5 exécutions
    • SkillsBench évalue 78 tâches avec OpenCode
      • sous-ensemble autonome excluant les tâches dépendantes d’API
      • moyenne sur 5 exécutions
    • Pour NL2Repo, les autres modèles ont été évalués avec Claude Code
      • temp 1.0, top_p 0.95, max_turns 900
    • QwenClawBench est un benchmark d’agent Claw fondé sur une distribution réelle d’utilisateurs
      • temp 0.6, ctx 256K
    • QwenWebBench est un benchmark interne de génération de code front-end
      • configuration bilingue EN et CN
      • 7 catégories : Web Design, Web Apps, Games, SVG, Data Visualization, Animation et 3D
      • évaluation du code et de la cohérence visuelle via auto-render et juge multimodal
      • utilisation du système de notation BT ou Elo
    • AIME 26 utilise l’intégralité de AIME 2026 I et II
      • Il est précisé que les scores peuvent différer de ceux des notes Qwen 3.5

  • Vision-langage

    • Qwen3.6-27B prend en charge à la fois les modes vision-langage thinking et non-thinking dans un point de contrôle unifié
    • Il peut traiter des images et des vidéos en plus du texte
    • Il prend en charge le raisonnement multimodal, la compréhension de documents et les tâches de question-réponse visuelle
    • Le tableau comparatif présente Qwen3.5-27B, Qwen3.5-397B-A17B, Gemma4-31B, Claude 4.5 Opus, Qwen3.6-35B-A3B et Qwen3.6-27B

    • STEM et puzzles

      • MMMU 82.9
      • MMMU-Pro 75.8
      • MathVista mini 87.4
      • DynaMath 85.6
      • VlmsAreBlind 97.0

    • VQA généraliste

      • RealWorldQA 84.1
      • MMStar 81.4
      • MMBench EN-DEV-v1.1 92.3
      • SimpleVQA 56.1

    • Compréhension de documents

      • CharXiv RQ 78.4
      • CC-OCR 81.2
      • OCRBench 89.4

    • Intelligence spatiale

      • ERQA 62.5
      • CountBench 97.8
      • RefCOCO avg 92.5
      • EmbSpatialBench 84.6
      • RefSpatialBench 70.0

    • Compréhension vidéo

      • VideoMME(w sub.) 87.7
      • VideoMMMU 84.4
      • MLVU 86.6
      • MVBench 75.5

    • Visual Agent

      • V* 94.7
      • AndroidWorld 70.3

    • Remarque

      • Les cases vides (--) dans le tableau signifient qu’aucun score n’est encore disponible ou que cela ne s’applique pas

Utilisation de Qwen3.6-27B

  • La prise en charge d’Alibaba Cloud Model Studio est annoncée comme imminente
  • Des open weights sont disponibles sur Hugging Face et ModelScope, avec possibilité d’auto-hébergement
  • Des voies d’accès via l’API Alibaba Cloud Model Studio et via Qwen Studio pour un essai immédiat sont proposées
  • L’intégration avec des assistants de code tiers comme OpenClaw, Claude Code et Qwen Code est prise en charge
  • Le texte mentionne une simplification du workflow de développement et une context-aware coding experience

  • Utilisation de l’API

    • Cette publication prend en charge la fonctionnalité preserve_thinking
    • Elle permet de conserver le contenu de thinking généré à tous les tours précédents d’un message, et il est précisé qu’elle est recommandée pour les agentic tasks

  • Alibaba Cloud Model Studio

    • Prise en charge des API chat completions et responses compatibles avec le format OpenAI
    • Prise en charge également d’une interface API compatible Anthropic
    • Des exemples de variables d’environnement sont fournis dans la documentation officielle
      • DASHSCOPE_API_KEY
      • DASHSCOPE_BASE_URL
      • DASHSCOPE_MODEL
    • Des exemples de Base URL par région sont aussi indiqués
    • Le code d’exemple utilise qwen3.6-27b comme nom de modèle par défaut
    • extra_body inclut enable_thinking: True
      • preserve_thinking: True apparaît sous forme de commentaire
    • Un exemple de réponse en streaming montre comment collecter séparément le reasoning_content et le answer content
    • Pour plus d’informations, il est indiqué de consulter le lien API doc

  • Coding & Agents

    • Qwen3.6-27B dispose de capacités d’agentic coding et peut s’intégrer de manière fluide avec OpenClaw, Claude Code et Qwen Code

    • OpenClaw

      • OpenClaw est un agent de code IA open source auto-hébergé, anciennement appelé Moltbot ou Clawdbot
      • Connecté à Model Studio, il offre une expérience complète d’agentic coding dans le terminal
      • Le script de démarrage inclut Node.js 22+, l’exécution du script d’installation, la configuration de DASHSCOPE_API_KEY, puis l’exécution de openclaw dashboard ou openclaw tui
      • Lors de la première utilisation, il faut modifier ~/.openclaw/openclaw.json
        • Il est précisé de ne pas écraser l’intégralité du fichier
        • Ne fusionner que les champs nécessaires afin de préserver la configuration existante
      • L’exemple de configuration inclut l’enregistrement du provider modelstudio et du modèle qwen3.6-27b
        • api est openai-completions
        • la valeur de reasoning est true
        • les types d’entrée sont text, image
        • contextWindow vaut 131072
        • maxTokens vaut 16384
        • le modèle primary par défaut est modelstudio/qwen3.6-27b

    • Qwen Code

      • Qwen Code est un agent IA open source pour terminal, profondément optimisé pour la série Qwen
      • Le script de démarrage inclut Node.js 20+, l’installation de @qwen-code/qwen-code@latest, puis l’exécution de qwen
      • Des exemples d’utilisation des commandes /help et /auth dans une session sont fournis
      • Lors de la première utilisation, une invite de connexion s’affiche, et /auth permet de changer de méthode d’authentification

    • Claude Code

      • Les API Qwen prennent aussi en charge le protocole API Anthropic
      • Il est précisé qu’elles peuvent être utilisées avec des outils comme Claude Code
      • L’exemple de configuration comprend les variables d’environnement suivantes
      • La commande d’exécution est claude

Conclusion

  • Qwen3.6-27B démontre qu’un modèle dense bien entraîné peut dépasser une génération précédente bien plus grande sur des tâches importantes pour les développeurs
  • Avec 27 milliards de paramètres, il surpasse Qwen3.5-397B-A17B sur tous les principaux benchmarks d’agentic coding
  • Son architecture simplifie le déploiement et l’exploitation, et la gamme open source Qwen3.6 couvre désormais un éventail plus large de configurations avec l’ajout de Qwen3.6-27B

À lire aussi

4 commentaires

 
kaydash 2026-04-23

Il faut au moins une A3B pour pouvoir le faire tourner un peu en local, haha.
 
kirinonakar 2026-04-23

Les benchmarks semblent bons, mais à l’usage, ça ne me paraît pas encore être à un niveau vraiment exploitable comme agent de codage.
 
b89kim 2026-04-26

Je l’ai essayé et il n’y a pas de gros problème pour le coding agentique. En revanche, comme vous l’avez dit, en usage réel + pour du coding général, ses performances ne peuvent qu’être inférieures à celles des modèles avec davantage de paramètres. Les valeurs de configuration sont différentes de la 3.5 et un mode preserve_thinking a aussi été ajouté, donc gardez-le à l’esprit. Avec une quantification 4 bits du 27B, il n’y a pas eu de problème particulier pour une utilisation en local.
 
GN⁺ 2026-04-23
Réactions sur Hacker News
  • De mon point de vue, pour un modèle local quantifié à 16,8 Go, le résultat de pelican était vraiment excellent. J’ai résumé ça ici : https://simonwillison.net/2026/Apr/22/qwen36-27b/. Je l’ai fait tourner sur un M5 Pro avec 128 Go de RAM, mais la mémoire réellement nécessaire semblait être d’environ 20 Go, donc ça devrait aussi tourner correctement sur une machine avec 32 Go. La lecture traitait 20 tokens en 0,4 seconde, soit 54,32 tokens/s, et la génération produisait 4 444 tokens en 2 min 53 s, soit 25,57 tokens/s. J’ai même préféré ce résultat à celui de pelican que j’avais obtenu il y a quelques jours avec Opus 4.7. https://simonwillison.net/2026/Apr/16/qwen-beats-opus/
    • C’est presque trop réussi, au point que je me demande si ce n’était pas présent dans les données d’entraînement. J’aimerais voir d’autres tests pour comparer.
    • Je me dis à moitié pour plaisanter qu’un jour, les fournisseurs de modèles finiront peut-être par optimiser spécifiquement pour le célèbre test pelican riding a bicycle de Simon.
    • Le nœud papillon sur Qwen Flamingo est aussi d’une justesse remarquable.
    • De mémoire, j’ai rarement entendu utiliser le terme excellent à ce point pour le test pelican, mais ici ça semble mérité. C’est aussi intéressant de voir les modèles denses revenir sous les projecteurs après une période dominée par les MoE. Je me demande si, côté modèles fermés aussi, les gammes rapides vont vers le MoE et les gammes pro vers le dense.
    • À ce stade, les LLM ont probablement compris que le cadre d’un vélo est en gros un losange coupé en deux → ◿◸. J’espère ne pas ruiner le test en disant ça.
  • Depuis la sortie de Gemma 4 autour de Pâques, j’ai l’impression que l’écart entre les modèles en self-hosting et Claude s’est nettement réduit. Bien sûr, la différence reste importante, mais les anciens modèles locaux étaient tellement peu compétitifs que la situation est bien meilleure aujourd’hui. Et si Qwen 3.6 monte encore d’un cran par rapport à Gemma 4, c’est franchement enthousiasmant. Cela dit, les modèles locaux ont toujours tendance à partir dans des directions absurdes ou à échouer, donc je garde toujours Opus à portée de main. Malgré ça, chaque fois qu’un modèle local m’aide vraiment, j’ai davantage le sentiment que le code doit rester libre. Libre au sens gratuit, mais aussi au sens de liberté. Ma configuration repose sur une machine Ubuntu séparée avec une RTX 5090, et à l’instant où j’écris ces lignes, Qwen 3.6 27B utilise 29 Go sur 32 Go de VRAM. Je fais tourner Ollama dans une instance podman non root, et j’ai branché OpenCode dans mon éditeur comme service ACP, ce que je recommande vivement. ACP signifie Agent Client Protocol et, à mes yeux, c’est dans cette direction que le monde devrait aller. Et je suis reconnaissant à l’équipe Qwen de contribuer à améliorer les choses dans un monde rempli de Sam Altman.
    • Parmi les modèles que j’ai fait tourner en local sur mon M5 MBP, Gemma4 est celui qui ressemblait le plus à Claude.
    • Je partage aussi cet idéal de free et de local, mais au final l’essentiel reste une concurrence durable. Rien que le fait d’exercer une pression pour faire baisser un coût mensuel de 200 dollars à un niveau bien inférieur me satisfait déjà.
    • Je me demande jusqu’à quel point un modèle 27B peut réellement prendre en charge des tâches de programmation. Même Claude me laisse parfois sur ma faim, alors j’ai du mal à imaginer à quel point un 27B est utilisable en conditions réelles.
    • Je serais curieux de connaître le tokens/s sur une RTX 5090.
  • J’aimerais qu’à chaque annonce de modèle, on montre aussi clairement sur quel consumer hardware il peut tourner immédiatement, à quel coût et avec quel tok/s.
    • Pour exécuter nativement en 16-bit le modèle 27B distribué directement par eux, il faut du gros matériel. Un Mac ou un système Strix Halo 128 Go, plusieurs GPU grand public à grosse capacité, ou une carte workstation de type RTX 6000. C’est probablement pour ça qu’ils ne communiquent pas activement sur les machines grand public compatibles. La release d’origine qui produit ces résultats rentre mal dans un système grand public classique. La plupart des gens utiliseront à la place une version quantifiée avec moins de bits. Mais la quantification implique clairement des compromis, donc il est difficile d’espérer exactement la même qualité que celle mise en avant. Le précédent Qwen3.5 27B restait assez utilisable jusqu’en Q5 ou Q4, selon le niveau de dégradation acceptable, et sur un système à mémoire unifiée il fallait 32 Go de RAM supplémentaires, donc un Mac 64 Go était globalement adapté. C’était aussi faisable avec une NVIDIA 5090 32 Go ou deux GPU de 16 Go ou 24 Go, mais plus lent à cause de la répartition. Je pense qu’il faut rester prudent avec les affirmations disant que ça tourne sur iPhone ou sur des systèmes plus petits. Avec des quantifications extrêmes et divers bricolages, on peut parfois le lancer, mais la qualité de sortie est souvent inutilisable en pratique. On voit régulièrement passer des dépôts qui exhibent le fait de faire tourner ça sur du très petit matériel pour briller sur les réseaux sociaux, mais le résultat n’est souvent pas réellement bon.
    • Sur un M4 avec 32 Go de RAM, j’obtenais environ ~5 tokens/s. Je faisais tourner unsloth/Qwen3.6-27B-GGUF:Q4_K_M avec llama-server, et le modèle 35B-A3B tournait autour de 25 t/s. À titre de comparaison, sur A100 c’était environ 41 t/s et 97 t/s respectivement. Je n’ai pas encore longuement testé le 27B, mais le 35B-A3B déraillait souvent dès que le contexte dépassait 15k~20k tokens. On peut lui faire faire des tâches de base de manière stable, mais je ne dirais pas que c’est au niveau des modèles frontier.
    • Les combinaisons CPU/GPU capables de faire tourner des LLM en local sont en pratique quasiment infinies, donc la plupart des gens choisissent d’abord un système en fonction du budget et de l’objectif, puis estiment grossièrement l’usage VRAM à partir de la taille du modèle et de la quantification. Si on veut aller plus loin, on peut utiliser un calculateur de VRAM en ligne, par exemple https://smcleod.net/vram-estimator/. Avec un compte huggingface, on peut même renseigner sa configuration et voir par couleur les chances que chaque quant passe. Et le t/s dépend énormément de variables, y compris la taille du contexte, donc au mieux on n’obtient que des estimations. Aujourd’hui, les LLM locaux sont littéralement un ensemble de compromis à tous les niveaux, et il faut sans cesse choisir ce qu’on veut optimiser selon la tâche.
    • Qwen3.5-27B tourne sans problème sur une carte 24 Go en 4bit quant. J’en sers 10 développeurs avec deux Nvidia L4 et quelques flags vllm, à 20~25 tok/s, et jusqu’à environ 40 tok/s quand la charge est faible. Les développeurs sont satisfaits de ce niveau de performance, même s’ils ont demandé plus de GPU pour augmenter le débit.
    • Sur une RTX 4090D, j’obtiens environ 30 t/s, avec 42 Go utilisés sur 48 Go de VRAM. La quantification est UD-Q6_K_XL, et la discussion associée est ici : https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7
  • Des acteurs comme Qwen ou Minimax publient des modèles open source qui obtiennent des résultats de benchmark légèrement en dessous d’OpenAI ou Anthropic, mais comparables. Du coup, je me demande quel est exactement l’avantage concurrentiel actuel d’OpenAI ou d’Anthropic. D’autant plus que le prix au token de ces modèles ouverts n’est qu’une fraction de celui d’Anthropic Opus 4.6. https://artificialanalysis.ai/models/#pricing
    • En code, les derniers pourcents de différence de qualité comptent suffisamment pour justifier une prime. Ce n’est pas la même chose que produire en masse du spam ou des commentaires HN. Je pense que c’est aussi pour ça qu’il existe un écart de rémunération aussi fort entre un ingénieur moyen et un ingénieur P99. Et si les acteurs frontier maintiennent leur compétitivité malgré des coûts de R&D élevés, c’est bénéfique à long terme, parce que cela les force à créer de meilleurs produits et davantage de valeur ajoutée. Anthropic, en particulier, semble viser une position de fournisseur plus fiable. Même Ali héberge des modèles frontier payants, mais si on n’est pas une entreprise chinoise, est-ce qu’on a vraiment envie de mettre des charges de travail de développement de code en production chez un hébergeur chinois ? OpenAI a aussi un côté dérangeant, mais on soupçonne moins qu’ils pillent intégralement les secrets industriels. Anthropic m’inspire un peu plus confiance encore. Je pense que c’est là qu’apparaît la prime. Il existe trop de précédents historiques montrant que des sociétés d’hébergement chinoises peuvent mobiliser tous les leviers concurrentiels possibles puis partager avec l’État ou avec d’autres entreprises, et les gens intègrent ce risque dans le prix.
    • J’utilise à la fois Opus et Qwen, et dans l’usage réel l’écart entre les deux me semble bien plus grand que ce que montrent les graphiques de benchmark. Pour comparer aux modèles hébergés, il me semble qu’il vaut mieux regarder GLM en ce moment. C’est probablement ce qui se rapproche le plus des grands acteurs, et ils vendaient auparavant à des prix très bas, même s’ils ont commencé récemment à les relever.
    • Si ces résultats viennent des vampire attacks, alors il se peut que les modèles fermés cessent d’être aussi performants dès qu’ils apprendront à polluer les canaux par lesquels on leur aspire des réponses. Et quand on les utilise dans des workflows quotidiens, ils ne sont pas vraiment à niveau égal. Pour du raisonnement superficiel, peut-être, mais pour le code ou des tâches plus difficiles, l’écart reste important. En tout cas, parmi les modèles ouverts que j’ai testés, je n’en ai pas encore trouvé qui soit aussi bon que les modèles fermés. Si quelqu’un a une bonne configuration, je suis preneur.
    • À l’instant présent, je pense qu’il n’y a pas d’avantage concurrentiel. Mais dès qu’un écosystème commencera à vraiment s’intégrer, l’avantage apparaîtra.
    • Le prix élevé au token d’Opus est plutôt la preuve que les gens sont prêts à payer pour un modèle réellement meilleur. Les nouveaux modèles d’OpenAI et d’Anthropic sont nettement supérieurs à l’open source. L’open source n’est pas inutilisable, mais les modèles frontier sont clairement meilleurs, et le resteront probablement encore un moment. Si le temps d’un SWE vaut plus d’un dollar par minute, alors même une conversation à 10 dollars est rentable si elle fait gagner 10 minutes. Surtout en code, où de petites améliorations de qualité peuvent se traduire par un gain de temps important.
  • J’utilise Qwen 3.6 35B et Gemma 4 26B sur un M4 MBP, et même si on n’est pas au niveau d’Opus, ils accomplissent 95 % de ce dont j’ai besoin, ce qui est déjà incroyable sachant que tout tourne entièrement en local.
    • Je serais curieux de savoir quel type de travail tu fais, et avec quel harnais ou quelle approche tu relies Qwen ou Gemma. En d’autres termes, j’aimerais comprendre à quoi ressemblent ton workflow et ta stack logicielle.
    • C’est désormais suffisamment utile pour que, comme Codex réduit son propre travail, je délègue davantage de tâches à ces modèles locaux. Et sur mon M4, la version 122B a un débit bien meilleur que le dense 27B, donc j’en attends aussi beaucoup.
    • Tu utilises ça avec Ollama, ou avec autre chose ?
    • J’aimerais mieux comprendre ce que signifie exactement ce 95 %. Il y a deux questions derrière. Premièrement : est-ce que tu veux dire 95 % de la précision d’Opus 4.5 ou 4.6 en termes de qualité de sortie ? Deuxièmement : est-ce que tu veux dire 95 % de ses performances sur les appels d’outils ou les tâches agentiques, comme l’organisation d’un voyage ?
  • Je ne suis pas encore très familier avec les LLM locaux, donc hier j’ai passé un peu de temps à configurer et tester quelques modèles Qwen3.6-35B-A3B. De mémoire, c’était mlx 4b et 8b, ainsi que gguf Q4_K_M et Q4_K_XL. Le résultat sur mon M4 64 Go était plutôt impressionnant. Cela dit, si on se fie au tableau de TFA, ce nouveau modèle a l’air un peu plus intelligent, mais aussi plus gourmand en VRAM. Je me demande donc si la différence essentielle tient au fait qu’il soit dense. Et comme 27B est plus petit que 35B, j’espère voir bientôt arriver des quantifications avec des besoins VRAM encore plus faibles.
    • Le point clé n’est pas simplement le nombre de paramètres. Le 35B-A3B est un modèle Mixture of Experts, donc seulement environ 3B de paramètres sont activés à la fois. Les besoins de calcul réels se rapprochent donc davantage de ces 3B que de 35B, même s’il faut toujours un accès à haute bande passante à l’ensemble des couches 35B. Le nouveau modèle, lui, est dense, donc il sera probablement bien plus lent sur Mac. Par exemple, sur mon M4 Pro, j’étais à environ 9 tok/s en Q6 gguf, tandis que le 35-A3B montait à environ 70 tok/s en Q4 avec mlx — ce n’est pas une comparaison parfaitement équitable, bien sûr. En général, ce type de modèle dense s’exécute mieux sur un GPU dédié, et dès qu’on a assez de VRAM pour garder tout le modèle en résidence, le choix devient plus simple. J’estime qu’il faut environ 24 Go de VRAM ou plus pour être à l’aise, donc des NVIDIA 3090, 4090 ou 5090 devraient convenir.
  • Avec llama server en Q4_K_M, on obtient environ 91k context sur 24 Go, et si on fait le calcul, le KV-Cache représente environ 70 Mo par tranche de 1K de contexte. En Q5, il serait probablement resté de la place pour environ 30K tokens, ce que je trouve déjà assez impressionnant.
  • J’ai essayé de générer un pelican à vélo en SVG, et voici le résultat : https://codepen.io/chdskndyq11546/pen/yyaWGJx. J’ai aussi créé un dragon qui mange un hot-dog en conduisant une voiture, avec ce résultat : https://codepen.io/chdskndyq11546/pen/xbENmgK. Ce n’est pas parfait, mais rien qu’avec ce genre de résultats on voit à quel point les modèles sont devenus puissants.
    • L’image du dragon a des problèmes, comme l’œil unique ou la queue bizarre, mais le pelican est quasiment parfait, au point que c’est peut-être le meilleur que j’aie vu.
    • C’est devenu un benchmark tellement célèbre que je me demande si les modèles n’ont pas déjà été entraînés spécialement dessus.
  • Jusqu’ici, mes expériences d’inférence locale n’ont pas été particulièrement impressionnantes. Sur un M5 Pro avec 128 Go de RAM, j’obtenais autour de 11 tokens/s avec omlx, et au final il m’a fallu une heure pour produire quelques centaines de lignes de code non fonctionnel. Opus et Sonnet ont terminé correctement la même tâche en quelques minutes dans CC. Le modèle 3.6 35b que j’ai lancé hier dans Ollama avait l’air correct. Je compte tester d’autres harnais que Claude Code, mais pour l’instant j’ai l’impression que les modèles locaux sont tout simplement trop lents.
    • C’est un dense model, donc il est normal qu’il soit lent sur Mac. Si tu es sur Mac, tu devrais essayer la release Mixture of Experts de Qwen3.6, à savoir Qwen3.6-35B-A3B. Sur mon M4 Pro, j’étais à environ 70 tok/s. Si tu es beaucoup plus lent que ça, il est possible que tu utilises par erreur le format GGUF. Sur Mac, le format MLX, spécifique à Apple, est souvent plus rapide.
    • Sur mon MacBook M2 Max, avec la version MLX quantifiée en 8-bit, j’étais à environ 7 tokens/sec en génération.
    • J’ai eu l’impression qu’OpenCode exploitait mieux les modèles locaux que Claude.
  • Je me demande ce qu’on peut faire tourner sur un M4 Pro avec 48 Go de RAM.