文 |围炉

最近AI圈出了个不大不小的瓜，DeepSeek刚发布的V3.2版本，号称推理能力又上了个台阶，结果没几天就被用户和研究者们集体吐槽，这模型的Token消耗简直离谱。

实测数据告诉你，这个模型的Token消耗有多夸张

有研究者拿它跟Gemini做对比，处理同一个复杂任务，人家Gemini只用了2万Token，DeepSeek-V3.2Speciale版本直接干到7.7万。

同样的输出质量，Token用量是人家的3倍还多。

这可不是个例，独立分析机构ArtificialAnalysis的测试显示，新模型推理模式下的Token消耗达到8600万，比上一代的6200万增加了不少。

普通用户的感受更直接，社区里有人说，这版本生成速度也就30tokens/s，Token消耗快得像喝水一样。

跟Grok、Mistral这些同类模型比，延迟特别明显。

不少人呼吁，至少得把速度提到100tokens/s才能用得舒服。

实验室数据亮眼归亮眼，到用户手里不好使也是白搭。

大家可能会问，好好的模型怎么会突然变得这么费Token？这就得从它用的GRPO算法说起了。

GRPO算法的“天生毛病”，长度偏置是怎么来的

GRPO是现在大模型强化学习后训练的主流算法，目标函数里有几个关键部分决定了模型的优化方向。

今年3月，SeaAILab和NUS的研究者发了篇论文，专门指出这算法有俩大偏置问题。

一个是长度偏置，简单说，就算没特意让模型写长句子，它自己也会倾向于生成更长的响应来躲惩罚。

结果就是回答“又错又长”，这毛病在DeepSeek-R1-Zero训练阶段就有了，新模型里照样存在。

另一个是难度偏置，模型会过分关注那些特别难的问题，反而忽略了普通用户常用的适中难度任务。

DeepSeek的技术报告说，V3.2版本已经优化了难度偏置，但长度偏置居然给保留下来了。

这可不就成了Token消耗异常的“罪魁祸首”嘛。

本来想通过优化让模型更实用，结果把最关键的问题给漏了。

这问题还得往前追溯，GRPO是从PPO算法发展来的，PPO理论上不该有长度偏置。

但多数开源实现为了预训练时上下文窗口归一化稳定，加了些跟长度相关的处理。

这些在预训练时管用的操作，到了RL微调阶段，因为响应长度不固定，样本差异大，就变成了长度偏置，成了GRPO继承的“历史包袱”。

其实这事儿不光是DeepSeek的问题，整个行业都头疼。

大模型要在推理能力和Token效率之间找平衡，太难了。

强化学习微调时，既要鼓励深度推理就得允许长链，又要控制Token消耗就得简洁，这俩需求几乎是对着干的。

Token消耗多少直接关系到真金白银，API调用费用、用户等待时间、能不能在边缘设备上跑，这些都是模型从实验室走向产业落地的关键。

DeepSeek现在遇到的困境，其实是所有大模型都要面对的坎儿。

那有没有解决办法呢？从现有技术报告看，算法上或许可以试试动态长度惩罚，根据任务类型调整长度权重。

优势函数标准化也能改进，比如加入任务难度因子。

工程上就得想办法提升生成速度，从30tokens/s往100tokens/s努力，可能需要优化并行计算策略，或者用知识蒸馏压缩模型，同时保住推理能力。

其他模型也有自己的招，有的搞“响应质量-长度”联合奖励模型，强化学习时同时优化准确性和简洁度。

还有的用自适应上下文窗口，根据任务复杂度动态分配Token预算，避免无效消耗。

这些思路都值得参考，说到底，大模型竞争不光是比谁推理能力强，更得比谁效率高。

希望DeepSeek下次更新能彻底解决长度偏置问题，也期待行业能找到更好的RL微调范式，让大模型真正从“能做”变成“好用”又“实用”。

毕竟对用户来说，花最少的Token解决问题，才是真的香。