機器之心報道

編輯：冷貓、陳陳

DeepSeek 一發布模型，總會引起業內的高度關注與廣泛討論，但也不可避免的暴露出一些小 Bug。

比如老外用英文詢問，它卻在思考過程中切回「神秘的東方文字」。當然，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 和它的繼任者們的前世今生

早在今年三月份公開的論文《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.20783Github 鏈接：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 的上線，這個問題會不會就此解決呢？