Qwen3.8-27B 两款「减推理 token」微调实测对比
Reddit 用户用 Aider 基准实测 ThinkingCap 与 Swift 两版微调，确认 token 降幅约…
近日，Reddit r/LocalLLaMA 社区用户基于 Aider 编程基准，对 Qwen3.8-27B 的两款去冗余推理微调版本——ThinkingCap-Qwen3.8-27B 与 Swift-Qwen3.8-27B 进行了横向对比，并加入原版 Qwen3.8-27B 作为参照。所有模型均以 Q8_0 精度在 llama.cpp 0.5.0 下推理，每个模型跑两轮以压缩误差。
实测目标与方法
两款微调模型都声称将推理 token 减少约 40%，同时尽量保持能力不退化。评测使用作者自建的 Aider 评测套件，累计测过约 20 个模型，最高分由 Qwen3.8-Flash 取得（>90%）。本次关注的指标包括：首次通过率（pass1）、重试通过率（pass2）、合法 diff 比例、中位完成 token、每用例耗时（秒）、每解题 token 数。
总体结果：性能持平，token 显著下降
实测数据如下：
- ThinkingCap-Qwen3.8-27B（xhigh）：首次通过 27.1%，重试通过 77.6%，合法 diff 100%，中位 token 7436，秒/用例 777，token/解题 12.8K
- Qwen3.8-27B（xhigh）：首次通过 27.1%，重试通过 77.6%，合法 diff 99.1%，中位 token 12547，秒/用例 1481，token/解题 19.3K
- Swift-Qwen3.8-27B（xhigh）：首次通过 30.8%，重试通过 75.7%，合法 diff 98.1%，中位 token 7301，秒/用例 750，token/解题 12.1K
关键发现：ThinkingCap 与原版 27B 在通过率上完全一致（巧合，误差范围内），印证了作者宣称的「性能几乎不退化」。Swift 的总体通过率略低约 2%，但首次通过率更高。两款微调版本中位完成 token 都比原版少近 5000 个，与官方宣称「约 40% 下降」高度吻合。ThinkingCap 平均 token 比 Swift 多 8.5%，因其在部分用例上仍会「过度思考」，而 Swift 的降幅更均匀。
编程语言细分对比
三款模型在不同编程语言上表现略有差异（首次通过 / 重试通过）：
- C++：ThinkingCap 11.5% / 61.5%；原版 7.7% / 69.2%；Swift 11.5% / 69.2%
- JavaScript：ThinkingCap 35.4% / 85.4%；原版 27.1% / 81.2%；Swift 37.5% / 81.2%
- Python：ThinkingCap 27.3% / 78.8%；原版 42.4% / 78.8%；Swift 36.4% / 72.7%
ThinkingCap 在 C++ 上比 Swift 弱（重试通过低约 8%），但在 JavaScript（+4%）和 Python（+6%）上反超。其他语言差异在统计上不显著（p > 0.05）。另一个细节是 ThinkingCap 是唯一拿到 100% 合法 diff 的模型，输出格式稳定性最佳。
结论与选型建议
两款微调都兑现了「减少推理 token」的承诺，性能差异处于噪声区间。选择上可参考使用场景：若主要写 JavaScript / Python，ThinkingCap 略优；若在意 C++ 通过率或更均匀的推理压缩，Swift 更稳妥；若希望输出格式最稳定，ThinkingCap 的零错误 diff 是加分项。