Swift-Qwen3.8-27B 砍掉 58% 的思考长度还能保住精度到底靠谱吗

一个结论：Swift-Qwen3.8-27B 通过后训练优化，在思考 token 数量减少 58% 的情况下，速度提升了 1.95 倍，且大部分 benchmark 的精度损失在 1% 以内。它不是通过强行截断长度，而是识别并惩罚那些导致“过度思考”的 token，再配合 On-Policy Distillation 来修复精度。

这种所谓的“去冗余”优化到底怎么实现的

很多模型为了强行缩短推理路径会直接砍长度，结果导致逻辑崩掉。Swift-Qwen3.8-27B 的逻辑是先找出哪些 token 与“过度思考”相关，然后对其进行惩罚，而不是直接攻击推理长度。

这里有个关键点：开发者认为推理长度本身很重要，不能暴力缩减，但可以通过优化去掉那些像“焦虑循环”一样的重复思考过程。这种方法是和 chat template 或 token cap 互补的，不是替代关系。

实测数据能打吗

我看了一下他们对比 Qwen3.8-27B (BF16) 的数据（全部运行 x5，思考强度 xhigh），结论是大部分场景下精度几乎没掉，但 token 节省明显：

• GPQA-Diamond： 88.4% → 88.3%（精度微跌，但中位数 token 减少了 58%）
• MMLU-Pro： 85.5% → 85.0%（token 减少 28%）
• C-Eval： 90.0% → 90.6%（token 减少 19%）
• IFBench： 73.5% → 71.8%（token 减少 51%）
• AIME 2026： 98.7% → 94.0%（token 减少 50%）
• HMMT (Nov 2025)： 99.3% → 96.0%（token 减少 46%）
• ERQA (vision)： 67.5% → 66.3%（token 减少 55%）

值得怀疑的是，在 AIME 2026 和 HMMT 这类高难度数学题上，精度掉了 4-5 个百分点。虽然 token 省了一半，但这种损失在极端推理场景下可能影响最终答案。

实际部署和调用方式

如果你想试这个模型，目前有几种路径：

1. 直接拉模型： 已经在 Huggingface 开源，路径是

://huggingface.co/ukisai/Swift-Qwen3.8-27b

。
2. 量化版本： 官方提供了 GGUF (Q1-Q8) 版本，路径是

://huggingface.co/ukisai/Swift-Qwen3.8-27B-GGUF

；另外 Bartowski 也出了社区量化版。
3. API 试用： 有个 Nvidia 提供 GPU 支持的免费研究 API（OpenAI 兼容），但限制很死，只有 5RPM，路径是

://ukisai.com/api/swift/v1/models

。

针对不同 Effort 设置的分析

这个模型在不同思考强度下的表现有点奇怪：

• xhigh 模式： 平均思考量减少了 41%。
• medium 模式： 减少了 23%，但精度掉了 1-4%。
• low 模式： 减少了 26%，精度掉了 1-2%。

最能证明它价值的对比在 GPQA-Diamond 上：原版 Base 模型在 xhigh 模式下中位数 token 是 6,642 个，得分 88.4%；而 Swift 版本在 xhigh 模式下中位数 token 只有 2,771 个，得分 88.3%。这意味着它用不到一半的资源达到了几乎相同的效果。

总的来说，如果你对推理速度极度敏感且能容忍极小概率的精度波动，这个 Swift 版本比原版 Qwen3.8-27B 实用得多。但如果你在跑极其严苛的数学证明，建议还是对比一下 AIME 2026 的掉分情况再决定。