96.91%的HumanEval通过率，推理链长度却少了近四分之一。这组数字放在一起，像是一个产品经理在OKR里同时写了"降本"和"增效"——通常只能二选一，但这次似乎真有人做到了。
蒸馏的本质：把Claude的"脑子"塞进更小的躯壳
这个叫Qwen3.5-27B-Claude-4.6-Opus-Reasoning-Distilled-v2-GGUF的模型，名字长到像密码，核心动作却很简单：用14000条Claude 4.6 Opus风格的推理样本，教会Qwen3.5-27B怎么"想得更短"。
训练目标不是刷榜，而是迁移一种特定的思维模式——简洁的推理路径，而非最大化的基准分数。结果很直观：每token的正确解法提升了31.6%，相当于用更少的字数交卷，分数还差不多。
开发者把这种优化称为"推理链长度减少约24%"。换个场景理解：以前解一道题要写满三页草稿纸，现在两页搞定，步骤没漏，计算没错，只是删掉了"让我想想""这里可能需要""嗯，不对"这类内心独白。
HumanEval+上的1.24%：一笔明算账
模型在HumanEval+上的准确率比基座模型低了1.24%。这个数字被明确标注为"有意为之的权衡"，而非能力不足。就像编译器优化时关掉某些调试信息——不是不能保留，是算过账后觉得不值。
推理过程的透明性被保留下来。用户能看到模型内部的思考步骤，这对数学辅导、代码审查这类场景很关键。学生要知道老师怎么想的，不只是答案对不对；开发者要理解AI为什么给出这段代码，不只是能跑不能跑。
模型处理的任务类型很具体：需要分析推理的文本提示、数学题、编程挑战、结合推理要求的通识问题。输出包括结构化的思维链、直接答案、带推理可见的代码方案、经过多步逻辑验证的解法。
跨域迁移：数学课上学到的，编程考试也用得上
一个有趣的验证：训练数据主要来自数学、文字题、逻辑推导这些通用领域，但模型在编程任务上的表现与基座相当。这说明蒸馏转移的是底层推理模式，而非特定领域的解题技巧。
类比来说，就像有人专门练了怎么拆解复杂问题——先识别核心目标，再拆成组件，评估约束条件，最后顺序执行。这套方法解物理题能用，写代码也能用，甚至回邮件理逻辑都能用。
9B版本的存在让这种效率优化有了梯度选择。算力充裕时上27B，边缘设备或成本敏感场景切9B，同一套"简洁推理"的配方。
谁该关心这个模型？
离线分析场景是明确受益者。数学辅导系统需要一步步展示解题思路，代码生成工具需要解释为什么这样写，研究辅助需要可追溯的逻辑链条——这些场景对"推理可见"的需求，高于对绝对精度的执念。
成本结构也会变。API调用按token计费，推理链短24%直接等于账单金额打七六折。对于已经在大模型上跑通业务、现在进入"精细化运营"阶段的公司，这种优化比从零训练一个新模型更务实。
模型处理具体任务的方式值得细看：它减少了不必要的过渡短语和重复思考模式，代之以流线型的方法。不是变"笨"了，是学会了不说废话。
如果推理成本真的进入按分甚至按厘计价的阶段，"每token正确率"会不会成为新的核心指标？以及，当AI学会像优秀工程师一样写简洁的草稿，人类审稿的习惯是不是也该跟着改？
热门跟贴