DeepSeek-V3.2模型Token效率问题与GRPO算法缺陷分析

每当DeepSeek推出新模型时，总会引发业内的高度关注和广泛热议，但也难免会显露出一些小缺陷。

例如，当外国用户用英文提问时，模型在思考过程中却会切换回「神秘的东方文字」。实际上，DeepSeek模型对汉字「情有独钟」的现象早已存在，「极」字Bug就是一个典型案例。

而这次，随着新模型DeepSeek-V3.2的亮相，人们又发现了DeepSeek需要改进之处：其长思考版本（Speciale）显现出Token使用效率欠佳的问题。

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

在相同任务上，Gemini仅消耗2万Token，而DeepSeek-V3.2 Speciale却高达7.7万，意味着它需要3倍以上的Token才能输出相似质量的结果。

此外，Speciale版本输出的内容冗长且繁琐，但最终仍可能出错，这并非新问题，而是GRPO算法固有的缺陷。

来源：https://x.com/Compute_King/status/1996179050012794968

事实上，DeepSeek-V3.2在Token消耗方面的异常状况，已被众多用户和研究者察觉。有社区网友指出，Speciale版本确实具备强大的推理能力，但在实际应用中Token消耗速度极快，明显高于同类模型。他们评价称，若DeepSeek-V3.2 Speciale的生成速度能从当前的约30 tokens/s提升至100 tokens/s左右，那么其综合可用性和用户体验将得到显著改善。

独立AI模型分析及托管服务提供商Artificial Analysis表示：「DeepSeek V3.2在推理模式下比前代更加啰嗦，在运行AAII（Artificial Analysis Intelligence Index）基准测试时，输出Token消耗明显上升，达到8600万，而上一代仅为6200万。」

来源：https://x.com/ArtificialAnlys/status/1996110264102781332

「即使与Grok和Mistral相比，也能明显看到DeepSeek V3.2输出Token的延迟。」

来源：https://x.com/kurtqian/status/1995728391115362529

对于这种情况，DeepSeek在技术报告中坦诚承认并提供了数据对比。

报告中提到，DeepSeek-V3.2-Speciale的token使用效率显著低于Gemini-3.0-Pro。

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

DeepSeek技术报告：https://modelscope.cn/models/deepseek-ai/DeepSeek-V3.2/resolve/master/assets/paper.pdf

输出内容冗长繁琐，GRPO算法存在缺陷

GRPO算法随着DeepSeek的出现而成为强化学习的黄金标准，相信读者对此已不陌生。

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

早在今年3月发表的论文《Understanding R1-Zero-Like Training: A Critical Perspective》中，来自Sea AI Lab和NUS等机构的研究者揭示了GRPO算法的两大问题，认为GRPO会导致模型优化出现偏置。

论文标题：Understanding R1-Zero-Like Training: A Critical Perspective

论文链接：https://arxiv.org/pdf/2503.20783

Github链接：https://github.com/sail-sg/understand-r1-zero

在DeepSeek-R1-Zero的训练过程中，模型的响应长度在整个训练阶段持续增长的现象就已存在，而在DeepSeek-V3.2 Speciale中这一问题仍然延续。

以下是经典的GRPO损失函数，论文作者特意将影响优化过程的部分标红：

GRPO的目标函数结构中存在：

1. 长度偏置（Length Bias）

该偏置源于目标函数中对每个序列引入的归一化因子：

。

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

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

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

2. 难度偏置（Difficulty Bias）

该偏置源于优势函数中对优势函数进行标准化时所使用的分母：

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

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

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

作者推测，这种不一致可能源自预训练阶段：

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

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

由此可见，理论和实际实现之间总存在一些差异。等到DeepSeek-V4上线时，这个问题能否得到解决呢？