针对 DeepSeek V3.2 的推理引擎深度优化

本文整理自 2025 年 12 月 14 日的「百度百舸 X SGLang Meetup 北京站」的同名主题分享。

百度百舸基于万卡级生产系统实战经验，面向 DeepSeek V3.2 在推理引擎层面做了深度优化，加快推理速度，降低推理成本：通过轻量级 CP 让长文本推理的 TTFT 近乎线性降低，更创新研发 ESS 系统破解长文本推理的显存墙困境。

---

2024 年初，DeepSeek 发布系列 MoE 模型，推动 AI Infra 领域向大规模分布式稀疏模型部署方向演进。在部署模式上，已从传统的单实例单卡多副本架构，逐步过渡至单实例多机多 DP 部署；架构层面实现从集中式向 PD（Prefill-Decode）分离式的转型；并行策略也突破单一 TP 限制，迈向 EP、DP、TP、CP 的混合并行模式；模型结构则由 Dense Attention 逐步迭代为 Sparse Attention，适配稀疏计算需求。

这一系列技术变革带来了数十倍的吞吐性能提升，使大型算力卡的商业化应用具备盈利空间，但同时也引发了优化与运维层面的多重挑战。针对上述行业痛点与技术机遇，百度百舸在千卡至万卡级别的工业级生产环境中积累了丰富实战经验，形成了一套成熟的解决方案。该方案首先实现了千卡、万卡规模的 PD 分离系统部署，并在全集群范围内完成混合并行策略的全面支撑；通过自研 DP 与 EP 负载均衡算法，结合内部全局负载均衡调度系统，有效解决了负载不均问题；同时构建主动与被动双模式 KV Cache 传输机制，提升跨节点数据交互效率。

为应对分布式运维的复杂性，百度百舸打造了全面完善的可观测系统，实现对集群运行状态的全维度监控与故障快速定位。在硬件适配方面，方案通过一套统一代码逻辑，完成了对英伟达 GPU 与国产昆仑芯 XPU 的千卡级部署支持。目前，上述全栈系统已在 GPU 和 XPU 的千卡、万卡规模集群中，实现长达 10 个月以上的稳定运行，充分验证了其工业级可靠性与规模化部署能力。

针对 P 节点，我们设计并实现了轻量级 CP 上下文并行方案，使 TTFT（首词延迟）随节点数量增加实现近乎线性降低。该方案主要包含两部分核心设计：

第一，面向负载均衡的切分策略。在 Attention 计算场景中，按序列维度均匀切分会导致尾部计算量远高于头部，进而引发严重的负载不均衡问题。为此，我们采用逻辑双倍切分方案，将切分份数设置为 CP Rank 数的两倍，通过在各 Rank 上对负载进行重组，确保所有 Rank 的计算负载绝对均衡，有效规避了「快慢卡」现象对整体性能的影响。

第二，基于 DSA 结构的高效聚拢方案。业界传统聚拢方案（如 Ring-Attention 等）存在通信开销大的问题，且若通信与计算无法实现高效重叠，端到端性能收益将十分有限。而借助 DSA 特殊结构的特性，一方面 Latent 与 Index Key 的数据量显著减小，另一方面 DSA 各部分序列对应的 Attention 计算均具备局部性，无需通过 Ring 等复杂模式进行 CP（流水线并行）间的数据传输。基于此，我们仅需一次全局通信即可完成整个稀疏 Attention 的计算，既避免了复杂的通信 - 计算重叠设计，又大幅降低了通信开销。

实测数据验证了该方案的有效性：在 16K 输入长度下，TTFT 降低 75%；32K 输入长度下，TTFT 降低 80%；针对 128K 长序列，采用 32 张卡部署时，TTFT 可控制在 2 秒以内。

针对 Decode 节点，我们第一时间联合社区完成了多步 MTP（多步预测）的适配支持，使单机吞吐提升一倍以上。该方案基于 eagle 模式构建，可支持两步及以上的预测步部署，并通过优化实现了 CudaGraph 的高效适配。同时，针对原生逻辑子算子不支持多步 draft 模式的技术痛点，我们设计了创新的 reshape 解决方案，成功突破该限制。目前，相关技术实现的 PR（Pull Request）已合并至社区主干分支，感兴趣的开发者可通过以下链接查阅详情。

https://github.com/sgl-project/sglang/pull/11652。

DSA 架构的问世，推动推理场景从计算密集型向存储密集型转变。这一转型的核心在于，DSA 通过 token 粒度的稀疏计算，大幅降低了计算开销 —— 架构层面以轻量级 Indexer + 2K 维度稀疏 Attention 替代传统全量 Attention，使得计算量不再随上下文长度的增长而线性增加。经精确测算，128K 上下文长度下 DSA 架构的计算量，与 5K 上下文长度的全量 Attention 计算量基本相当。

在计算密集型问题得到解决后，存储密集型的瓶颈效应愈发凸显。尽管 DSA 仅选择 2K 个 token 进行 Attention 计算，但仍需完整存储整个序列的全量 Latent 数据；同时新增的 Index 缓存，进一步带来了超过 20% 的显存额外消耗。

实测数据表明，长序列场景下的推理吞吐会受显存限制出现显著衰减，衰减幅度可达两倍以上。例如，在 32K 上下文长度下，基于 H800 的最大批次大小仅能达到 12，吞吐衰减幅度超 7 倍；

为解决 HBM 显存容量不足的问题，一种直接且易于实现的方案是将 HBM 中的 KV Cache 卸载至 CPU 内存。该方案可彻底缓解显存容量带来的约束，但存在显著劣势：数据传输受限于 PCIe 带宽，导致时延无法满足实际应用需求。

针对这一痛点，我们开展了系列实验研究，重点分析了 Latent Cache 在时间维度的访问相似性，具体包括层间相似性（不同层、相邻部署间 Latent 的访问特征重合度）与层内相似性（同一层连续多步中 Latent 访问模式的稳定性）。

实验结果表明，上述两类相似性均超过 80%，这为局部 Offload 方案的落地提供了可行性基础。该方案的核心优势在于可减少 80% 的跨设备数据传输量，从而保障时延控制在合理范围；但同时也存在实践复杂度较高的问题，需要重新设计并管理 CPU 与 GPU 的协同显存池，实现两类存储资源的动态调度与高效协同。

局部 Latent Cache 卸载方案的核心挑战源于 decoder 的时延敏感特性，这对数据加载（load）与卸载（offload）的延迟提出了极为苛刻的要求，具体体现在以下三方面：

第一，传输速率难以达标。由于 Latent Cache 采用离散存储模式，且单块数据量仅为 656 字节（小块数据特征显著），经实测，该配置下 PCIe 带宽实际利用率仅能达到 11GB/s，远未发挥硬件潜在传输能力，无法满足低时延传输需求。

第二，Cache Miss 率过高。在多种局部卸载场景中，频繁出现大量 Cache 未命中情况，未命中的 Cache 数据需从 CPU 内存中获取，直接增加传输延迟。通过 FIFO 缓存策略测试显示，61 层模型的平均 Cache Miss 次数约为 300 次，最大 Cache Miss 次数可达 800 余次，对应 Cache Miss 率超过 45%。

第三，计算与传输串行导致额外开销。系统中计算过程与数据传输过程呈完全串行执行模式，即便 PCIe 带宽利用率较高、传输数据量较小，传输带来的额外开销仍会直接叠加至链路延迟中，进而影响 Token 生成效率（Throughput per Token，TPOE），导致整体吞吐量下降。在最坏场景下，该部分额外开销可使端到端延迟增加一倍以上，对应的吞吐量降低 50%。

为解决上述局部 Latent Cache 卸载面临的传输速率、Cache Miss 及计算-传输开销等难题，我们研发了 ESS（Expanded Sparse Server）系统，通过 GPU 与 CPU 两级缓存协同架构，高效破解存储容量瓶颈的同时，规避了容量拓展对计算性能的损耗。

ESS 系统的核心设计的是构建 GPU+CPU 两级缓存体系：在 CPU 端全量管理静态 Cache，存储完整的 Latent Cache 数据；在 GPU 端仅保留局部动态热数据，聚焦高频访问内容以提升计算效率，两级缓存通过二级索引实现高效关联与数据协同。该系统基于 SGLang 原生能力拓展实现，同时无缝兼容此前落地的 PD 分离架构，确保技术方案的兼容性与可扩展性，无需对现有集群架构进行大幅改造。

在解决存储容量问题的基础上，ESS 系统进一步优化计算性能损耗，形成差异化竞争优势：相较于业界主流卸载方案，ESS 无需对数据进行压缩处理，实现端到端精度无损的卸载模式，彻底规避了数据压缩与解压带来的精度损失及额外计算开销。同时，我们针对数据传输量、传输速率及 Overlay（通信-计算重叠）机制开展全方位优化，实现 Latent Cache 的实时卸载，有效控制传输延迟与额外开销，确保 Token 生成效率（TPOT）等核心性能指标几乎无损耗，兼顾存储扩容、传输效率与计算性能的三重需求。