写点什么

一次快速响应的开源协作,让 DeepSeek-V3.2-Exp 性能满血回归

作者:Baidu AICLOUD
  • 2025-11-25
    北京
  • 本文字数:2189 字

    阅读完需:约 7 分钟

部署 DeepSeek-V3.2-Exp 时,百度百舸团队发现其长上下文性能明显低于官方报告。经排查,问题源于官方开源的 Inference Demo 中 RoPE 排布方式的一处细微错配。修正后,DeepSeek-V3.2-Exp 性能完全恢复。

本文完整记录了该问题从发现、验证与协同 DeepSeek 官方修复的全过程。



1.    DeepSeek-V3.2-Exp:稀疏注意力带来的效率提升

2025 年 9 月 29 日,DeepSeek 发布实验性模型 DeepSeek-V3.2-Exp。该模型在 DeepSeek-V3.1-Terminus 基础上集成 DeepSeek Sparse Attention(DSA)稀疏化策略,在保持模型能力基本持平的前提下,显著降低长上下文场景下的计算复杂度与推理成本。


具体而言,DSA 利用轻量化的 Lightning Indexer,将注意力的计算复杂度从 O(L^2) 降至 O(Lk)(k≪L),使端到端推理成本在 128K 长度下降低近 50%。在包括 MMLU-Pro、SWE Verified、BrowseComp 等 15+ 项公开评测中,V3.2-Exp 表现与 V3.1-Terminus 基本持平,验证了稀疏化未带来显著性能损失。

DSA(DeepSeek Sparse Attention)的核心在于通过稀疏化降低长上下文计算开销,其机制由两个紧密协同的组件构成:

  • Lightning Indexer:一个轻量级打分模块,用于为每个 token 预估其与历史 token 的相关性;

  • Sparse MLA(Multi-head Latent Attention):在 DeepSeek-V3 系列主干结构基础上,根据 Indexer 的打分结果,仅访问 Top‑k 个 latent 条目,执行稀疏化 KV 计算。


这种协同机制对底层实现的一致性提出了较高要求,任何关键信号的偏差都可能影响稀疏决策的准确性。

2.    性能异常浮现:基于开源部署的 V3.2-Exp 低于 V3.1-Terminus 与官方 API 表现

百度智能云于 10 月 8 日在百度千帆大模型平台上线 DeepSeek-V3.2-Exp 推理服务。然而我们观察到,该模型在 SWE Verified(Mini-SWE-Agent 模式)上的得分为 47.8,显著低于同配置下 DeepSeek-V3.1-Terminus 的 59.2,与 DeepSeek 官方报告中「性能基本持平」的结论存在明显差异。 



为排除外围因素,百度百舸团队尝试了多种推理后端(SGLang / vLLM)、调整了模型以及 Agent 的相关参数(如 temperature、迭代步数等)。结果均未改善性能,这表明问题并非来自外围配置或引擎实现。

同时,我们也对长上下文领域的常见评估集 RULER 进行了详细测试,发现在 niah_multikey_3 这一任务中,存在明显 badcase:在 128K 长度下,V3.2-Exp 的通过率仅 12.5%,而 V3.1-Terminus 为 81.25%。



为明确上面的问题与 V3.2-Exp 模型本身的关系,我们也通过 DeepSeek 官方 API 调用评测了上述两项任务,发现均能达到 V3.1-Terminus 水平。


  • SWE Verified 得分为 58.4,与 V3.1-Terminus 的 59.2 基本持平。


  • RULER 的 niah_multikey_3 任务在 24K 下通过率达 100%。(由于 Inference Demo 代码未做显存优化,太长的用例会导致 OOM,我们采用 24K 长度 niah_multikey_3 case 进行测试)

表格说明:niah_multikey_3_24k 测试,采样 16 条,其中 highlight 处为 badcase。


综合上述一系列对比实验,我们将现象及可复现路径反馈至 DeepSeek 团队。

3.    根因定位:Inference Demo 未按模块区分 RoPE 排布

11 月 17 日,DeepSeek 在 GitHub 更新 Inference Demo 代码(commit 8631a81 ),并说明:

此前版本的 Inference Demo 中,Indexer 模块的 RoPE 实现存在 layout 不匹配:Indexer 应使用 non-interleaved(分块)排布,而 MLA 使用 interleaved(交错)排布。该偏差可能导致性能下降。


具体而言

  • MLA 主干模块沿用 DeepSeek-V3 系列设计,要求 RoPE 输入为交错排布(interleaved);

  • Indexer 模块采用了分块排布(non-interleaved,即 Neox 风格)。这与 GPT-NeoX、Qwen 等模型一致,但与 MLA 不同。


原 Inference Demo 未区分这两种实现,Indexer 调用 RoPE 时默认走了 MLA 的交错排布,导致其对 token 位置的判断出现系统性偏移,进而影响 Top‑k 选择的准确性。

4.    DeepSeek 官方修复与社区协同落地

DeepSeek 的官方修复聚焦于:

  • 在 apply_rotary_emb 函数中新增 interleaved 布尔参数,支持两种排布模式;

  • 在 Indexer 调用处显式传入 interleaved=False,确保其使用分块排布;

  • 在 MLA 调用处保持 interleaved=True(默认),维持主干兼容性。


该方案仅修改十余行代码,不涉及模型权重或训练流程,属轻量级实现修正。目前,修复后的代码已更新至:

https://huggingface.co/deepseek-ai/DeepSeek-V3.2-Exp/tree/main/inference



在 DeepSeek 明确修复方案后,百度百舸团队依据其设计意图,在自研推理引擎中完成了对应逻辑的适配与验证。在自研推理引擎中同步适配 interleaved 参数调用,并进一步将该适配方案贡献至 SGLang(PR #13495 )。

开源代码地址:https://github.com/sgl-project/sglang/pull/13495

5.     性能全面恢复

验证结果显示,修复后性能完全恢复。用户可以在百度千帆大模型平台体验完整性能版的 DeepSeek-V3.2-Exp:


  • 在 RULER 的 niah_multikey_3 任务中4K  至 128K 全长度下通过率恢复至 100%,在 32K 至 128K 的条件下性能甚至超越了 V3.1-Terminus。


  • SWE Verified 得分提升至 59.6,与 V3.1-Terminus(59.2)基本一致。


作为 AI Infra 的长期建设者,百度智能云正在持续将生产环境中验证过的高性能推理组件回馈至开源社区。近期,百度百舸团队已向 SGLang 贡献包括本次 RoPE 适配在内的多项优化,后续还将开源更多经过大规模业务考验的代码,帮助开发者更高效、更稳定地构建生成式应用。

发布于: 刚刚阅读数: 3
用户头像

Baidu AICLOUD

关注

还未添加个人签名 2022-06-13 加入

适合跑AI的云

评论

发布
暂无评论
一次快速响应的开源协作,让 DeepSeek-V3.2-Exp 性能满血回归_百度百舸_Baidu AICLOUD_InfoQ写作社区