DeepSeek-V3.2优化挑战：长思考版本Token效率问题暴露

每当DeepSeek发布新的模型，总是能吸引业内的高度关注与广泛讨论，然而，这也常常伴随着对新模型潜在问题的曝光。

例如，有用户发现，DeepSeek模型在处理英文输入时，会意外地切换到使用中文，这显示出模型在跨语言处理上的不足。此外，DeepSeek对汉字的偏好也早已为人所知，'极'字Bug便是一个典型例子。

随着新模型DeepSeek-V3.2的发布，特别是其长思考版本（Speciale）的出现，研究者们又发现了需要优化的地方：Speciale在处理复杂任务时存在明显的Token消耗异常。

据多位研究者反馈，在相同任务上，Gemini只需消耗2万Token，而DeepSeek-V3.2 Speciale却使用了7.7万Token，才能达到类似的质量输出。这意味着，Speciale需要三倍以上的Token才能实现相同的效果。

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

实际上，DeepSeek-V3.2在Token消耗方面的异常表现已经引起了不少用户与研究者的关注。有社区网友指出，Speciale版本虽然具备强大的推理能力，但在实际使用中Token消耗速度惊人，显著高于同类模型。他们建议，如果DeepSeek-V3.2 Speciale的生成速度能从当前的大约30tokens/s提升至100tokens/s左右，其综合可用性和使用体验都将得到大幅改善。

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

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

这种情况在DeepSeek的技术报告中也有提及，并进行了数据对比。报告显示，DeepSeek-V3.2-Speciale的token使用效率明显低于Gemini-3.0-Pro。

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

输出内容冗长且存在GRPO算法缺陷

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

我们曾对GRPO的基本原理进行过系统介绍，建议读者参考我们的科普文章。

早在今年三月份公开的论文《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的罪魁祸首。