UkisAI Swift-Qwen3.8-27B / 思考量减少58.3%,速度提升1.95倍,同时保持xhigh准确率

Reddit r/LocalLLaMA 模型

摘要

UkisAI 对 Qwen 3.8 27B 模型进行了后训练,以减少不必要的思考令牌,从而在准确率损失不到1%的情况下,实现思考量降低58%和速度提升1.95倍,模型已开源并提供免费的研究API。

大家好,我们对 Qwen 3.8 27B 进行了后训练,使其更高效,通过识别与过度思考相关的令牌并对其进行惩罚,而不直接“攻击”推理长度,然后使用一些秘方(提示:On-Policy Distillation)修复了准确率,取得了显著成果(思考令牌减少58%,速度提升1.95倍,准确率损失低于1%),因此我们决定开源它并听取社区的反馈。模型链接:https://huggingface.co/ukisai/Swift-Qwen3.8-27b 我们还提供了一个免费的研究目的API(兼容OpenAI),感谢 Nvidia 慷慨提供的GPU。如果您没有足够的计算资源运行模型,可以使用它来尝试,限制为5RPM。https://ukisai.com/api/swift/v1/models 我们还制作了GGUF(Q1-Q8),社区也有一些不错的量化版本(Bartowski),具有更低/更高精度。社区还创建了出色的NVFP4、W4A16和无审查版本,您可以在Huggingface上找到。重要提示:我们的训练方法不是推理努力设置、聊天模板或令牌上限的替代品,而是互补的,针对一个完全不同的问题(过度思考和类似于“焦虑”的推理循环,先前在PTQ中见过,但据我们所知,在这种规模的LLM的BF16中也很突出)。与普遍看法相反,这些特定模式在正确针对时并不有助于答案质量。(我们的论点是:推理长度确实极其重要,不应强制缩短,而应优化。)以下的xhigh与中等努力基准表也证明了这一点。目标是保持xhigh的准确率,同时仅减少思考的不必要部分。我将概述我们的思考过程、研究、训练和基准测试。当我们运行量化后的Qwen 3.8 27B实例时,我们对随机推理循环非常困扰(在下文的论文中称为“过度思考错误”)。这些随机循环在中等和低推理设置中持续存在。我们记得Meta的一篇论文旨在针对PTQ中的这种现象,但直接使用时结果不一。我们考虑尝试是否在于正确针对关键词和调整参数,因此使用了我们的8xH100机器生成了大量不同(当然是分布外的)领域(编码、语言、视觉、代理)跟踪。然后,我们对过度思考的跟踪进行分组,找到它们之间的“共同分母”令牌,并针对最突出的令牌。然后,我们构建了一个这些令牌的推理时惩罚器,如论文所示,希望通过简单生成跟踪并进行交叉熵SFT来修复。这完全没有效果,但惩罚器似乎比论文中提供的令牌效果好得多,不仅适用于低精度模型,也适用于BF16。因此我们继续实验。我们使用识别的令牌构建了一个损失函数,并在先前生成的跟踪上运行LoRa SFT,推理似乎显著下降,但准确率也似乎跟随下降。推理减少似乎具有泛化性。经过大量调整(实际上自Qwen 3.8 27B发布以来),我们对推理减少感到满意。之后,我们寻找恢复准确率的方法。我们尝试了几种方法,包括RL(GSPO)、On-Policy Distillation和使用ThinkingCap 3.6 27B适配器块,直到我们对准确率损失感到满意。我们设法在几乎所有分布外内部测试中将其恢复到<1%的损失。然后我们进行了密集的基准测试,涵盖多种推理努力、精度变体等。我们遇到了几个问题,其中之一是获得可靠分数需要每个基准测试运行10次(基础5次 + 我们适配器5次,这是在Terminal Bench上Qwen 3.6 27B模型卡中的标准程序,我们遵循了)。运行后,性能收敛到在GPQA、MMLU、Terminal Bench 2.1、LiveCodeBench v6、ERQA、C-Eval、IFBench、HMMT25上,令牌减少40-60%,准确率损失<1%,但AIME26的准确率损失为4.6%,我们后来将其与训练过程中一个与数学推理相关的特定令牌被惩罚的错误联系起来,并计划在更新版本中修复。基准测试:(原始基准文件在这里 - https://github.com/UkisAI/Swift-Qwen3.8-27B-evals/)Swift-27B vs Qwen3.8-27B(BF16,所有基准测试运行x5,推理努力xhigh)基准测试 Qwen3.8-27B Swift-27B 中位令牌 GPQA-Diamond 88.4% 88.3% 减少58% LiveCodeBench v6 76.8% 81.6% (+4.8pp,由于LCB中的默认截断,这不是性能提升) 减少46%思考令牌 Terminal-Bench 2.1 66.7% 65.8% 减少39% MMLU-Pro 85.5% 85.0% 减少28% C-Eval 90.0% 90.6% 减少19% IFBench 73.5% 71.8% 减少51% AIME 2026 98.7% 94.0% 减少50% HMMT (Nov 2025) 99.3% 96.0% 减少46% ERQA (vision) 67.5% 66.3% 减少55% 令牌节省在每个推理努力中保持(平均思考减少):xhigh 41%,medium 23%,low 26%(尽管medium有1-4%的准确率损失,low有1-2%,我们需要进一步测试)。Swift在xhigh下与基础自身努力设置在GPQA-Diamond(198个问题 x 5个种子)上的比较:模型/努力 准确率 中位令牌 基础 xhigh 88.4% 6,642 Swift xhigh 88.3% 2,771 基础 medium 84.1% 1,753 因此,Swift在不到一半的令牌下保持xhigh准确率,并以约1.6倍的令牌击败基础medium 4个百分点。结束语:虽然我们热衷于完全开源,但作为新实验室,我们仍需保留部分训练和数据。许可证不是Apache 2.0,但只影响超过100万美元的公司。我们希望这不会给社区带来问题,但我们对此持开放态度。我们希望尽可能多地为社区做出贡献,并非常感谢对我们工作、量化或Swift模型请求的反馈。背景是,我们现在正在开发Swift 3.8 Flash Next,目前在保持xhigh准确率的同时,思考令牌使用减少了30%,这强烈表明我们的方法在Qwen模型家族中是可复制的。一旦我们有能力,将探索其他家族,并希望看到社区希望我们优先优化哪些。
查看原文

相似文章

ukisai/Swift-Qwen3.8-27b

Hugging Face Models Trending

Swift-Qwen3.8-27B 是 UkisAI 基于 Qwen3.8-27B 开发的推理高效版本,可将思考令牌减少 58.3%,同时保持几乎相同的性能。

peculiar-ragdoll 的 Dirk-Qwen 3.8-27B 对比 UkisAI Swift-1.5 Qwen3.8-27B

Reddit r/LocalLLaMA

一位 Reddit 用户在 Apple Silicon 和自建推理框架上,用一套自定义的领域特定评测集对两个基于 Qwen 3.8-27B 微调的模型变体(peculiar-ragdoll 的 Dirk-Qwen 与 UkisAI Swift-1.5)进行测试,发现 Dirk 的表现明显更锐利、token 效率更高,而 Swift 在难题上经常因 token 限制截断而直接失败。