Swift-Qwen3.8-27B : réduire le temps de réflexion de 58% sans perdre en précision
En bref
- Un modèle Qwen 3.8 27B optimisé réduit le temps de réflexion (tokens de raisonnement) de 40 à 60%, tout en préservant l'exactitude sur la plupart des benchmarks.
- La technique combine pénalisation de tokens en temps d'inférence et fine-tuning LoRA pour éliminer les boucles de raisonnement excessif, un problème observé notamment sur les versions quantifiées.
- Le projet rapporte moins d'1% de perte d'exactitude sur la majorité des tests (GPQA, MMLU, LiveCodeBench, C-Eval, etc.), sauf sur AIME26 (4,6% de perte, attribuée à un bug d'entraînement à corriger).
Ce que dit la source
Les créateurs décrivent un problème qu'ils ont rencontré lors du déploiement local de Qwen 3.8 27B quantifié : le modèle générait des boucles de raisonnement persistantes (« overthinking errors »), particulièrement aux niveaux de raisonnement médian et faible. Ils ont cherché à réduire ces boucles tout en maintenant l'exactitude, en s'inspirant d'une publication Meta sur la quantification post-entraînement (PTQ) puis en développant leur propre approche.
- Identification de tokens « overthinking » : l'équipe a généré des traces d'inférence sur plusieurs domaines (codage, langage, vision, agents) avec une machine 8xH100, puis isolé les tokens communs aux traces présentant un raisonnement excessif.
- Penalisation de tokens en temps d'inférence : une fonction de pénalité appliquée aux tokens identifiés s'est avérée plus efficace que la méthode proposée dans l'article Meta, et fonctionne aussi sur les modèles bf16 (non quantifiés).
- Fine-tuning LoRA avec loss personnalisée : après la pénalisation, un entraînement supervisé (SFT) utilisant les tokens identifiés réduit le raisonnement de manière généralisable, mais au prix initial d'une perte d'exactitude.
- Restauration de l'exactitude via RL et distillation : plusieurs méthodes testées (GSPO, on-policy distillation, adapter ThinkingCap) ont permis de récupérer <1% de perte d'exactitude sur la plupart des domaines.
- Benchmarks intensifs : tests répétés 10 fois (5x modèle de base + 5x avec adapter) sur GPQA, MMLU, Terminal Bench 2.1, LiveCodeBench v6, ERQA, C-Eval, IFBench, HMMT25, convergeant vers 40–60% de réduction de tokens avec <1% de perte, sauf AIME26 (4,6%, bug identifié).
Dans les commentaires
Débat limité mais positif. Un utilisateur confirme l'utilité du modèle malgré des préoccupations en termes de rapport coût-performance locale sur anciens MBP (token API vs inférence locale). Des questions légitimes soulevées sur les quantifications inférieures (Q4) et les boucles infinies restent sans réponse dans le fil.
- Un commentateur remet en cause l'intérêt économique de l'inférence locale sur ancien matériel (M1 Max 64GB) au regard du coût des tokens API auprès de fournisseurs tiers, suggérant qu'une stratégie token-cloud peut être plus rentable qu'une machine à 4–5k USD.
- La question de la performance sur des tâches long-horizon complexes reste ouverte, ainsi que le comportement exact sur les quantifications Q4 et l'interaction possible entre réduction de raisonnement et confiance du modèle en lui-même.
Notre lecture
Intéressant pour les équipes cherchant à réduire la latence et les coûts d'inférence locale sur Qwen 3.8 27B, notamment en contexte temps réel où le raisonnement excessif ralentit sans ajouter de valeur. L'approche est rigoureuse (benchmarks répétés, domaines variés), mais le sujet reste niche : utile si tu runs Qwen 3.8 27B localement, probablement du bruit sinon. Le bug AIME26 et l'absence de détails sur la performance long-horizon justifient d'attendre une version 1.1 avant une intégration critique. À tester en production limitée pour valider le gain réel sur tes charges.