DeepSeek-V3.2 Speciale的Token消耗异常与GRPO算法缺陷深度解析

每当DeepSeek发布新一代模型，总会引发人工智能领域的高度聚焦与深入探讨，但同时也难以避免地会显露一些技术上的小瑕疵。

例如，当海外用户使用英文进行提问时，模型在内部思考环节却突然转换至「充满神秘感的东方字符」。当然，DeepSeek模型对于汉字「特别偏爱」的现象并非首次出现，此前广为人知的「极」字Bug便是一个典型案例。

而此番，随着全新模型DeepSeek-V3.2的正式亮相，社区再次发现了模型亟待优化的方面：其长思考版本（Speciale）凸显出Token利用效能不足的显著问题。

依据多位研究人员的反馈，DeepSeek-V3.2 Speciale在执行复杂计算任务时呈现出明显的Token消耗异常。具体表现如下：

在完成同一项任务时，Gemini仅耗费2万Token，而DeepSeek-V3.2 Speciale却消耗了7.7万Token，这意味着它需要付出超过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和它的继任者们的前世今生

早在今年三月公开发表的论文《Understanding R1-Zero-Like Training: A Critical Perspective》中，来自Sea AI Lab与新加坡国立大学等机构的研究者们，便深刻揭示了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）

此项偏置来源于优势函数中对优势值进行标准化处理时所采用的分母：

这将导致当某些问题的回报标准差很小，尤其是当题目过于艰深，几乎所有回报都为零时，这些样本在策略更新过程中会被赋予更高的梯度权重，反而忽略了那些难度更为适中的实际任务。

从DeepSeek-V3.2的技术报告中我们观察到，难度偏置问题已得到一定优化，但长度偏置仍然被保留下来。这或许是DeepSeek-V3.2 Speciale异常消耗token的根本原因。

上述「长度偏置」问题其实源远流长，在GRPO的前身PPO方法中便已存在。然而，在PPO的原始损失函数公式里，其实并未包含「长度偏置」这一项，但在PPO大多数的开源代码实现中，开发者却不约而同地加入了此项。

论文作者推测，这种理论与实践的脱节可能起源于预训练阶段：

所有token通常被整合进一个固定长度的上下文窗口，通过对上下文长度进行归一化处理，能够有效增强数值计算的稳定性。

但在后续的强化学习微调阶段，若延续相同的实现逻辑，依据响应长度对损失进行归一化。由于响应长度并非恒定值且在不同样本间波动剧烈，便在不经意间引入了长度偏置。

由此可见，理论构想与实际代码实现之间往往存在微妙差异。待到DeepSeek-V4正式发布之时，这一问题是否能够迎刃而解？