ThinkingCap réduit le raisonnement des modèles Qwen sans tout casser

BottleCap AI publie ThinkingCap-Qwen3.8-27B, un modèle affiné pour penser plus court. Sur 12 benchmarks, il consomme 37,2 % de tokens de raisonnement en moins, avec une précision moyenne quasi stable.

BottleCap AI a publié ThinkingCap-Qwen3.8-27B, un affinage du modèle Qwen3.8-27B pensé pour réduire la longueur des traces de raisonnement. Sur 12 benchmarks, le modèle utilise en moyenne 37,2 % de tokens de réflexion en moins, pour une précision macro qui recule de 0,86 point. Le calcul est simple : moins de bavardage interne, mais pas au prix d’un effondrement des résultats.

Quand penser moins suffit souvent

La série ThinkingCap part d’un constat assez prosaïque : les modèles de raisonnement dépensent parfois plus de tokens qu’une question ne l’exige. BottleCap AI estime qu’une partie de ces étapes supplémentaires ne change pas la réponse finale. Cette version vise donc un objectif étroit : raccourcir les traces, sans toucher au style de réponse, aux consignes suivies ni au comportement de sécurité.

Le modèle repose sur Qwen3.8-27B et peut se brancher comme remplacement direct sur vLLM ou SGLang. BottleCap fournit aussi des builds FP8, NVFP4, GGUF et MLX. En clair, le modèle se veut exploitable en production, pas seulement exhibé sur une fiche de benchmark.

Des gains nets, mais pas uniformes

Les chiffres varient selon les tâches, ce qui évite de raconter une belle histoire trop lisse. Sur les benchmarks de connaissance et de multilingue, les économies sont les plus fortes : MMMLU descend de 1 656 à 571 tokens, soit -65,5 %, et MMLU-Pro baisse de 57,3 %. GPQA-Diamond passe de 12 772 à 7 267 tokens, soit -43,1 %.

Sur IFBench, la consommation de raisonnement recule de 46,4 %, avec une précision presque inchangée, de 79,75 % à 79,71 %. AA-LCR, un test de récupération en contexte long, gagne même 2,25 points de précision, de 81,75 % à 84,00 %, tout en utilisant 38,6 % de tokens en moins. La partie code suit la même logique : LiveCodeBench v6 progresse légèrement de 0,07 point, avec 20,3 % de raisonnement en moins.

Toutes les tâches ne sourient pas pareil. AIME 2026 perd 3,85 points, de 98,13 % à 94,27 %, pour une baisse de 30,2 % du nombre de tokens. Sur les benchmarks agentiques, l’écart reste contenu : τ²-bench cède 1,01 point pour une réduction de 30,9 %, et Terminal-Bench 2.1 perd 0,56 point, dans sa marge d’incertitude, avec 10,7 % de tokens en moins.

Le réglage d’effort reste utile, mais change un peu de profil

Qwen3.8-27B propose un paramètre d’effort de raisonnement, et ThinkingCap le conserve. BottleCap compare le modèle affiné au modèle de base en mode xhigh, puis à des modes medium et low. Dans ces configurations, la compression continue de s’appliquer : à medium, ThinkingCap réduit 60,2 % des tokens pour -9,90 points de précision, contre 52,1 % et -9,16 points pour le modèle de base ; à low, les chiffres passent à 62,3 % et -10,79 points, contre 55,4 % et -9,71 points.

Lorsque le raisonnement est désactivé, ThinkingCap accuse un retard de 5,7 points sur le modèle d’origine. BottleCap recommande malgré tout le mode xhigh, qu’il juge le meilleur compromis entre précision et coût en tokens. La promesse n’est pas de penser moins à tout prix, mais de penser plus court quand la marge le permet. Ce n’est pas de la paresse, c’est de l’optimisation.

Ce que dit la méthode de test

Les évaluations ont été menées sur un NVIDIA H200 avec vLLM 0.29.0, en utilisant les mêmes réglages de génération pour les deux modèles : température 1, top_p 0,95, top_k 20 et min_p 0.0. Les mesures de précision multi-seed sont rapportées avec un intervalle à 95 %, avec des graines allant de 32 sur AIME 2026 à 1 sur MMLU-Pro et MMMLU. MMMLU repose sur un échantillon fixe de 10 000 questions ; les 11 autres benchmarks sont exécutés en entier.

BottleCap indique aussi que le décodage spéculatif MTP, avec trois tokens brouillons, n’altère pas la précision sur AIME 2026. Le système accepte 53 % des tokens proposés, soit environ 2,6 tokens par étape. Là encore, la logique est la même : gagner du temps sans casser le reste.

Déploiement, formats et licence

Le checkpoint bf16 compte 28 milliards de paramètres et accepte à la fois du texte et des images. BottleCap publie cinq variantes quantifiées : FP8 de 31 Go pour Hopper et Blackwell, NVFP4 weight-only de 21 Go pour Hopper et Blackwell, NVFP4 W4A4 de 23 Go pour Blackwell uniquement, GGUF de 16 à 55 Go pour llama.cpp, LM Studio et Ollama, et MLX 4-bit DWQ de 21 Go pour les Mac Apple Silicon dotés de 32 Go de mémoire. Le modèle renvoie les traces de pensée dans un champ séparé, via la recette de Qwen3 avec le parseur qwen3_xml.

Le point de vigilance se trouve côté licence. Les poids sont publiés sous PolyForm Small Business 1.0.0, avec un accord BottleCap nécessaire pour un usage commercial au-delà du cadre petite entreprise. Les matériaux Qwen restent, eux, sous Apache-2.0. Autrement dit, la partie technique est ouverte dans l’esprit, mais pas franchement en libre circulation totale.

Points clés

  • 37,2 % de tokens en moins sur 12 benchmarks.
  • Précision macro : 86,65 % à 85,79 %.
  • AA-LCR gagne 2,25 points en contexte long.
  • AIME 2026 recule de 3,85 points.
  • Déploiement direct sur vLLM ou SGLang.
  • BottleCap impose PolyForm Small Business 1.0.0.

En chiffres

  • 37,2 % — baisse moyenne des tokens de raisonnement, sur 12 benchmarks, selon BottleCap AI.
  • 86,65 % à 85,79 % — précision macro avant/après, sur la même batterie de tests.
  • 28 milliards — paramètres du checkpoint bf16, d’après BottleCap AI.
  • 31 Go — taille de la version FP8 publiée pour Hopper et Blackwell.
  • 16 à 55 Go — plage de taille des builds GGUF pour llama.cpp, LM Studio et Ollama.

À lire