DeepSeek-V3.2巨「吃」Token，竟然是被GRPO背刺了

　　DeepSeek 一发布模型，总会引起业内的高度关注与广泛讨论，但也不可避免的暴露出一些小 Bug。

　　比如老外用英文询问，它却在思考过程中切回「神秘的东方文字」。当然，DeepSeek 模型对汉字「情有独钟」的情况早已出现，「极」字 Bug 就是典型例子。

　　而这一次，随着新模型 DeepSeek-V3.2 的发布，大家又发现了 DeepSeek 需要优化的地方：其长思考版本（Speciale）暴露出一些 Token 使用效率不佳的问题。

　　根据多位研究者反馈，DeepSeek-V3.2 Speciale 在处理复杂任务时出现明显的 Token 消耗异常。具体表现为：

　　另外，Speciale 版本出现输出内容又长又啰嗦的问题，但最终仍然错的情况，这并不是新问题，而是 GRPO 算法本身的固有缺陷。

　　实际上，DeepSeek-V3.2 在 Token 消耗方面的异常表现，已经被不少用户与研究者观察到。有社区网友指出，Speciale 版本的确具备极强的推理能力，但在实际使用中 Token 消耗速度如喝水般迅速，显著高于同类模型。他们评价，如果 DeepSeek-V3.2 Speciale 的生成速度能够从当前的大约 30 tokens/s 提升至 100 tokens/s 左右，那么其综合可用性和使用体验都将获得大幅改善。

　　为了降低部署成本并减少推理时延，官方版 DeepSeek-V3.2 的训练过程中施加了更为严格的 token 约束，以期在性能与成本之间取得更优的权衡。DeepSeek 研究者们表示，token 效率仍将是未来一个至关重要的研究方向。

　　GRPO 算法随着 DeepSeek 的诞生而成为强化学习的黄金范式，相信读者们早就不陌生了。

　　我们对 GRPO 的方法基本原理曾有过系统的介绍，建议读者参考我们的科普文章。科普向：一文解构大模型后训练，GRPO 和它的继任者们的前世今生

　　当优势函数为正值时（表示对应的响应是正确的）：较短的响应会产生更大的梯度更新幅度，从而使策略在优化过程中更倾向于生成简短的正确答案。

　　当优势函数为负值时（表示对应的响应是错误的）：较长的错误响应所受到的惩罚反而更弱，从而导致策略在错误样本中偏向于生成更长的回答。

　　这解释了：即便不引入任何「显式鼓励长推理链」的机制，GRPO 训练出的模型也会自然呈现出响应长度不断增长的趋势，躲避惩罚，生成又错又长的回复。

　　这会导致当某些问题的回报标准差较小，尤其是题目过于困难，几乎所有回报都为 0 的时候，在策略更新过程中将被赋予更大的梯度权重，忽视了那些难度适中的实际问题。

　　我们从 DeepSeek-V3.2 的技术报告中发现，难度偏置已经被优化了，而长度偏置仍然被保留。这或许是 DeepSeek-V3.2 Speciale 超级耗 token 的罪魁祸首。

　　上述「长度偏置」问题其实由来已久，在 GRPO 的前身 PPO 方法中就早已存在。但是，在 PPO 的损失函数公式中其实并没有「长度偏置」这一项deepseek，而在 PPO 的大多开源实现中，却大都加入了这一项。

　　所有 token 会被打包进一个固定长度的上下文窗口，通过对上下文长度进行归一化可以有效提升数值稳定性。

　　但在 RL 微调阶段保持相同的实现方式会，按照响应长度对损失进行归一化。但响应长度不是常数且在不同样本之间变化剧烈，从而无意中引入了一个长度偏置。

　　由此可见，理论和实际实现之间总有些许的差别。等到 DeepSeek-V4 的上线，这个问题会不会就此解决呢？原文出处：DeepSeek-V3.2巨「吃」Token，竟然是被GRPO背刺了，感谢原作者，侵权必删！