DeepSeek-V3.2模型性能与效率分析 - 新发布的DeepSeek-V3.2 Speciale版本在处理复杂任务时暴露出Token使用效率不佳的问题，在相同任务上，Gemini仅消耗2万Token，而DeepSeek-V3.2 Speciale消耗了7.7万Token，是前者的3倍以上[1] - 独立分析提供商Artificial Analysis指出，DeepSeek V3.2在推理模式下比上一代更啰嗦，在运行AAII基准测试时，输出Token消耗从上一版本的6200万显著增加至8600万[7] - 官方技术报告承认，DeepSeek-V3.2-Speciale的Token使用效率明显低于Gemini-3.0-Pro[13]，为了降低部署成本并减少推理时延，官方版DeepSeek-V3.2在训练中施加了更严格的Token约束[14] 模型基准测试表现对比 - 在AIME 2025基准测试中，DeepSeek-V3.2-Speciale的Pass@1分数为96.0，消耗23k Token，而Gemini-3.0 Pro分数为95.0，消耗15k Token[13] - 在HMMT Feb 2025测试中，DeepSeek-V3.2-Speciale获得99.2的高分，消耗27k Token，Gemini-3.0 Pro为97.5分，消耗16k Token[13] - 在CodeForces基准测试中，DeepSeek-V3.2-Speciale获得2701的评分，但消耗高达77k Token，而Gemini-3.0 Pro评分为2708，仅消耗22k Token[13] GRPO算法固有缺陷分析 - DeepSeek-V3.2 Speciale输出内容又长又啰嗦但最终仍然出错的问题，根源在于GRPO算法本身的固有缺陷[2] - 研究论文指出GRPO算法存在长度偏置，当优势函数为负值时，较长的错误响应所受惩罚更弱，导致策略在错误样本中偏向生成更长的回答[18] - 在DeepSeek-R1-Zero的训练过程中，模型的响应长度在整个训练阶段持续增长，这一现象在DeepSeek-V3.2 Speciale中仍然存在[16]，DeepSeek-V3.2的技术报告显示，难度偏置已被优化，但长度偏置仍然保留[18] 用户反馈与性能指标 - 社区用户反馈，DeepSeek-V3.2 Speciale具备极强的推理能力，但Token消耗速度如喝水般迅速，显著高于同类模型[5] - 用户评价指出，如果DeepSeek-V3.2 Speciale的生成速度能从当前约30 tokens/s提升至100 tokens/s左右，其综合可用性和使用体验将获得大幅改善[5] - 在对比测试中，DeepSeek V3.2-Speciale的平均耗时为613秒，消耗34501 Token，而Gemini 3 Pro仅耗时113秒，消耗12116 Token[7] 行业技术发展动态 - 与Grok和Mistral对比，DeepSeek V3.2在输出Token方面存在明显延迟[10] - GRPO算法已成为大模型后训练的黄金范式，但其在理论和实际实现之间存在不一致性，在PPO的大多开源实现中加入了长度归一化，无意中引入了长度偏置[21] - DeepSeek研究者表示，Token效率仍将是未来一个至关重要的研究方向[14]