定州市网站建设_网站建设公司_后端开发_seo优化

1. 背景

超节点作为一种创新的硬件架构，通过构建大规模全互联的 Scale-up 网络，有效突破了传统 8 卡节点在通信上的「互联墙」瓶颈，为上层业务提供了极致的互联带宽与统一显存池化能力，从而实现大模型推理服务性能的跨越式提升。

结合新硬件架构的特性，AI Infra 团队可以基于对上层模型算法特性的深度理解，进一步做 AI 工程上的软件优化，充分释放硬件潜能，在吞吐量、首 Token 延迟（TTFT）、每 Token 处理时间（TPOT）等核心指标上实现突破性增长。 这些 AI Infra 优化不仅显著提升了系统整体效率，更大幅降低了硬件的 Token 的成本，成为企业落地大模型的关键胜负手。

本文将深入拆解百度百舸在超节点部署方案设计与软件优化方面的技术实践，聚焦推理引擎策略、核心算子调优、高效通信调度等关键维度，全面揭示软硬协同如何释放昆仑芯超节点的澎湃算力的底层逻辑与工程密码。

2.百度天池超节点部署方案

百度天池超节点将 32 张昆仑芯 XPU 全互联为更大的 Scale-up 域。在此基础上，为了规划 DeepSeek R1 模型在百度天池超节点的部署方案，我们综合考虑性能要求和资源使用，并在 SLA 与硬件资源上找到配置最优解。

在百度天池超节点上，百度百舸团队基于 SGLang 推理框架和 PD 分离的部署架构，对 DeepSeek R1 模型的推理服务进行深度适配与调优。

通过在部署层面对计算单元、并行策略与资源配比进行精细化规划，使模型计算特性与超节点硬件形态形成高度匹配，从而在严格满足 SLA 约束的前提下，最大化释放硬件算力效率，为后续推理全链路优化奠定基础。

• 在 Prefill 侧，在线服务通常要求 TTFT 控制在 1s 以内，因此需要核算 Prefill 的配置能否满足这个要求，如果不能满足，则需要使用并行策略满足要求。此外，在平衡时延时还需要考虑吞吐，如果吞吐不达标也会造成 Decode 打不满的情况，进而降低 Decode 的吞吐性能；
• 在 Decode 侧，对单步生成时延（TPOT, Time Per Output Token）要求更为严苛，需低于 50ms 以保证流畅的用户体验，因此需要设计合适的并行策略以及 EP 规模，平衡性能与成本。除此之外，在 PD 分离架构下，Decode 节点需要承载大量的 KV Cache，KV Cache 的预留空间直接决定了系统能支持的最大上下文长度（Context Length）和最大并发数（Batch Size），因此在确保每张卡能放得下模型权重以外，也要为 KV Cache 预留足够的显存容量。

综合上述计算特性与资源约束，我们制定了如下部署策略：

Prefill 阶段：

• 高并行度换取低时延，采用 16 卡作为一个计算单元，使用 TP4（Tensor Parallelism = 4） + SP4（Sequence Parallelism = 4）并行策略。由于 DeepSeek R1 规模巨大，单卡执行大 Batch 的 Prefill 计算耗时极易突破 1s 阈值。通过 TP4 + SP4 将计算负载切分到 4 张卡上并行处理，可以近乎线性地降低单次前向计算时间，从而在保证 TTFT 达标的基础上，留出算力余量来提升 Batch Size，实现高吞吐；
• 对于 128K 等超长文本，我们会采用 TP16 + SP16 或者 TP32 + SP32 等更大的 TP 规模，降低 TTFT；
• 开启 Chunk Prefill，避免长序列请求影响短序列请求的 TTFT。

Decode 阶段：

• 最大化访存效率与通信优化，采用 32 卡作为一个计算单元（占满一个 P900 超节点），使用 TP1（不切分 Tensor Parallel）和 EP32（Expert Parallel）并行策略。由于 Decode 阶段是访存敏感型，且算子计算密度低，过高的 TP 会引入频繁的跨卡 AllReduce 通信，导致通信开销占比过高，严重拖累 TPOT。因此，我们策略性地放弃 TP 切分（TP1），转而利用 P900 的 32 卡大显存池，通过数据并行（DP）和专家并行（EP）来保证计算密度和显存容量，最大限度减少小算子的通信损耗。

在资源配比与专家策略上：

• 采用 2P1D 架构。即 1 个 P900 超节点（32 卡）承载 2 个 Prefill 实例（各 16 卡）；另 1 个 P900 超节点承载 1 个 Decode 实例（32 卡）；
• 在专家并行（EP）配置：Prefill (EP16)：单卡承载 16 个专家，利用高计算密度掩盖专家路由开销；Decode (EP32)：单卡承载 8 个专家。通过扩大 EP 规模至 32 卡，将模型专家分散存储，大幅降低了单卡权重显存占用，从而为 KV Cache 腾出宝贵的显存空间，支持更长的上下文；
• 共享专家（Shared Experts）：在 Decode 阶段采用全 DP（Data Parallel） 策略，即共享专家在每张卡上都有一份完整副本，确保这些高频访问的专家无需跨卡通信即可直接调用，进一步降低 TPOT。

量化与精度策略：

• 量化方案：在算子层面，整体采用 A8W8C16 (Activation 8-bit, Weight 8-bit, Compute / Accumulation 16-bit) 的量化方案，在保证精度稳定性的前提下提升推理性能；
• MLA 优化：针对 MLA （Multi-Head Latent Attention）架构中的 FlashAttention （FA）算子，我们采用 FP16 精度，以确保长序列下注意力分数的数值稳定性，避免量化带来的精度溢出问题。

调度层面：

• 配合精细化 DP 均衡调度，最大程度的消除 idle batch 占比，避免因为调度问题导致 DP 负载不均，减少 Prefill 侧产生 idle batch 的比例，避免出现大量请求排队的问题，从而提高 Prefill 单卡吞吐。

3. 百度天池超节点推理性能优化

基于上述部署方案，在满足 SLA 约束的前提下，为进一步提高 Prefill 和 Decode 的吞吐性能，我们根据各阶段的特性针对性地实施了优化策略：

• 对于 Prefill 阶段，核心目标是降低 TTFT。由于其计算特性以大规模矩阵计算为主，整体属于计算密集型负载，在超节点架构下算子效率本身并非主要瓶颈。真正限制 Prefill 性能释放的，是计算与通信在时间轴上的串行排布。因此，Prefill 优化的核心思路是通过双流优化与通信优化，将通信开销掩盖在计算过程中，从而在 TTFT 达标的前提下提升整体吞吐；
• 而 Decode 阶段，核心目标是将 TPOT 稳定控制在 50ms 以下，这意味着 run batch 中每一层、每一个算子的执行时间都必须受到严格约束。在这一阶段，推理性能不再取决于单个算子是否足够快，而取决于整个执行链路中是否存在被放大的「微小空泡」。这就需要我们将 Decode 的执行流程进一步拆解为「主模型运行前的组 batch 过程、主模型运行、以及 MTP 投机推理」，再根据不同阶段的性能特征和瓶颈来源，采用相应的优化策略。

基于上述思路，下面将分别对 Prefill 与 Decode 两个阶段的具体优化方法与效果进行详细展开。

3.1. Prefill 优化

3.1.1. Prefill Overlap 优化

Prefill 阶段因上下文长度较长，attention 与 MoE 模块的计算耗时较长，而 MLP 模块中 dispatch 与 combine 两次通信的耗时，与 Attention、MoE 的计算耗时相当。并且在昆仑芯算子的实现中，计算算子与通信算子可在独立资源上并行调度，因此 Prefill 阶段可通过开启双流优化，利用计算耗时掩盖通信耗时，从而缩短整体执行时间。

以「4K 定长上下文、batch=2」的请求为例，开启双流优化后，会将总计 8K 的输入 token（4K×2）拆分为两个 4K 的 micro batch。在 run batch 过程中，两个 micro batch 的 attention 与 MLP 计算交替执行；与此同时，当第一个 micro batch 进行计算时，第二个 micro batch 可同步执行 dispatch 或 combine 通信操作，具体流程如下图所示：

这种计算与通信 overlap 的双流优化，在非超节点模式下虽能提升性能，但面对短序列场景时，计算耗时可能不足以完全掩盖通信耗时，便会导致计算资源的闲置，优化效果无法最大化体现。而在超节点模式下，通信耗时显著降低，attention 与 MLP 的计算耗时可完全覆盖 dispatch 与 combine 的通信耗时，便可减少性能空转（bubble），双流优化效果更优。

通过上述双流优化，Prefill 阶段的整体吞吐可提升约 20%。

3.1.2. Prefill 通信优化

由于 Prefill 采用 TP4，因此必然会引入通信过程，我们在通信策略优化的迭代过程如下图所示：

• 方案一：q_down 和 kv_down 不做序列切分，重复计算；q_up 和 kv_up 按照 num_head 切 TP；MHA 部分也按照 num_head 切分；o_proj 切 TP；最后使用 AllReduce；MLP 部分使用序列切分，MLP 计算完成后 AllGather 聚合结果。
• 方案二：采用 TP + SP，q_down 和 kv_down 采用序列切分；然后 AllGather 汇聚 BS；q_up 和 kv_up 切 TP；MHA 部分按照 num_head 切分；o_proj 切 TP；最后使用 ReduceScatter；进入 MLP 后使用序列切分。
• 方案三：在方案二的基础上，MHA 后使用 AlltoAll；o_proj 不做 TP 切分，采用序列切分。

使用方案一：

• q_down 和 kv_down 存在冗余计算，这部分单卡计算量是方案二和方案三的 4 倍；
• 通信的部分引入 AllReduce + AllGather，总通信量为:BS x 16128
  • AllReduce：
  • AllGather：

使用方案二：

• 通信的部分引入 AllGather + ReduceScatter，总通信量为:BS x 5772
  • AllGather：
  • ReduceScatter：

使用方案三：

• 通信的部分引入了 AllGather + AlltoAll，总通信量为:BS x 3468
  • AllGather：
  • AlltoAll：

可以看到：方案三的通信量最少，这也是我们所采用的 Prefill 通信方案。

3.1.3. Prefill 长序列优化

面向 128K 的长序列输入时，Prefill 的计算压力异常大。为此，我们充分利用了超节点更大 Scale up 域的优势，针对长序列 Prefill 使用了更大的 TP 范围（如 TP16 + SP16、TP32 + SP32）。借此，一方面可以减少单卡的计算量，缩短整体计算时间，从而降低 TTFT，另一方面可以降低单卡的显存使用量，提高 chunk size 的大小，从而进一步提高单卡吞吐。

在128K 长序列场景中，TTFT 可缩小 5 倍以上，单卡吞吐可提高 80%。

3.2. Decode 优化

Decode 阶段包含「主模型运行前的组 batch 过程、主模型运行、以及 MTP 投机推理」三个部分。基于各部分的业务逻辑分析，我们针对「主模型运行阶段」进行了主模型 Overlap 和算子优化，并针对「组 batch 和 MTP 投机推理」阶段进行了算子缝隙优化。

3.2.1. Decode 主模型 Overlap 优化

Decode 侧未开启双流优化，核心基于两方面考量：

• 受 TPOT 约束，Decode 侧的 batch 通常较小，并且 Decode 属于访存密集型，小 batch 下 GEMM 运算的 TFLOPS 本就较低，拆分 batch 不仅难以获得显著收益，反而可能出现负收益；
• 依托百度天池超节点更高的通信效率，通信耗时在单层执行时间的占比不足 15%，且与计算耗时差距显著。此时通过双流优化掩盖通信耗时的收益有限，不足以抵消算子效率下降带来的额外开销。

因此，Decode 侧未采用拆 batch 的方式，转而探索单流执行场景下的优化空间：寻找互不依赖、且可调度至不同资源并行执行（overlap）的算子组合。依此，我们将运行在 cluster 上的 combine 算子与运行在 SDNN 的共享专家（shared expert）计算进行并行调度：在 combine 算子执行期间，同步运行共享专家的计算逻辑，待二者均完成后，再执行路由专家与共享专家的结果合并。

下图中黄色表示运行在 cluster 上的算子，蓝色表示运行在 SDNN 上的算子。优化前所有的通信和计算算子都在一条 stream1 上运行；优化后 stream1 在 cluster 资源上运行 combine 通信算子的同时，并行的 stream2 在 SDNN 资源上运行共享专家，以实现资源的最大化复用。

通过上述主模型的 Overlap 优化，Decode 阶段的TPOT 降低约 7%。

3.2.2. Decode 主模型算子优化

百度天池超节点更大的 Scale-up 域为大规模并行计算提供了极致的通信效率，因此计算算子的耗时会更加凸显。

3.2.2.1. Decode 主模型计算算子优化

除了前面提到的部分计算算子可以被通信 overlap 之外，我们针对 Decode 单层执行的所有算子做了 Trace 分析，尝试找出哪些算子存在瓶颈，及其是否有优化空间。

该表格主要列举了：Decode 单层执行的所有算子中，attention 所有算子在 attention 整体时间的占比。

特别说明：

• 对照 DeepSeek 官方发布的在 H 卡的 decode trace 信息；
• 由于 DeepSeek 官方在 H 卡上 Decode 使用了双 micro batch overlap，而且 EP 规模与我们配置不同，因此我们只对比 attention 部分的算子占比；
• 虽然两个场景的 batch 大小不一样，但是输入长度一致，因此 attention 部分的算子占比也能说明各算子的性能表现。

通过对比和分析，我们看到：

• q_k_up_absorb: bmm 和 v_up_absorb: bmm 这两个矩阵的吸收算子，百度天池超节点算子占比明显高于 H 卡表现。经过进一步分析，我们发现这两个部分的小算子太多，于是我们进行了算子融合优化，最终合成一个 fc_batch 的算子，节省了一倍以上的算子执行时间；
  优化后的效果体现如下图所示：q_k_up_absorb: bmm 的算子占比从 7.422% 下降到 5.803%；v_up_absorb: bmm 的占比从 6.901% 下降到 4.910%。
• attn_mqa 算子的耗时显著高于其它算子，基于我们的过往经验判断，该算子具有一定的优化空间。对此，在做 fa 计算之前我们消除掉了不必要的 memcpy 操作和 reshape 等小算子；在 fa 计算之后，我们消除掉了量化 cast 操作，让后续 GEMM 算子的输入匹配 fa 算子的输出；
• 针对所有的 GEMM 算子，我们使用 autotune，让 GEMM 算子在不同的 batch size 和 sequence length 下自动使用最佳配置，保持最佳性能。

通过主模型的计算算子优化，attention 部分总体时延降低 11.5%，Decode 阶段的 TPOT 降低约 8%。

3.2.2.2. Decode EP 通信算子优化

我们在通信算子的优化措施主要包括两方面：

• combine 及 dispatch 的数据传输优化：针对不同 EP 规模与传输 token 数量，算子自动选择最优发送策略，充分释放硬件资源潜力；
• combine 算子优化：在 reduce 计算过程中，通过消除中间结果的冗余量化与存储步骤，直接提升 reduce 计算效率。

经过以上优化，再结合硬件性能提升，通信时间在单层执行时间的占比从 40% 降到 15%，而整个 Decode 要进行 59 次（ 58 个 MoE 层 + 1 个 MTP 层）这样的通信，耗时可被显著压缩。

下图展示了 dispatch 与 combine 在不同 token 数量、EP 规模场景下的通信时延。从数据可见：在 EP32、96token 的典型场景中（该场景满足 TPOT < 50ms)，dispatch 时延仅 80.419μs，combine 时延仅 105.466μs。

3.2.3. Decode 算子缝隙优化

3.2.3.1. MTP 层缝隙优化

MTP 投机推理是 Decode 阶段降低 TPOT 的成熟且高效的技术路径：通过在主模型前引入 draft 模型，从而在 Decode 阶段可一次生成多个 token，降低 TPOT、提升吐字率，优化用户交互体验。

在我们的 MTP 方案实现中，主模型运行结束后会执行 verify 校验 —— 对比本次主模型输出 token 与上一轮 draft 模型的预测 token：若二者一致，则说明上一轮 draft 模型预测准确，且主模型基于该预测 token 生成的 token 同样有效，此时可将两个 token 同步输出。

整体流程如下图所示，由于 verify 的校验逻辑涉及大量 CPU 的 H2D 和 D2H 等同步操作，当下图中 CPU 执行 D2H-1 操作时，需等待 XPU 侧执行完 D2H-1 后才能执行 D2H-2 操作，此时会造成 D2H-2 的启动 （Launch）开销无法被掩盖，因此产生算子缝隙，同理，后续 MTP 层由于也无法被提前启动，同样会产生算子缝隙。

对此，我们对 verify 的过程进行优化 —— 消除掉一些 H2D 和 D2H 操作，并将 verify 过程拆成两个部分：将无法消除掉的包含 H2D 和 D2H 的 verify2 部分移动到 MTP 层后面，剩余 verify1 的部分和 MTP 层可被提前启动，以此消除掉算子缝隙。

经过优化后，TPOT 可降低约 5%。

3.2.3.2. 组 batch 缝隙优化

Decode 阶段在运行主模型前需执行组 batch 操作，该过程包含大量 CPU 操作且难以剔除。为此，我们通过提前启动下一个 batch 的 XPU 算子，使组 batch 操作与本次 batch 的 XPU 运算（run batch）重叠执行，从而掩盖组 batch 的耗时。

具体方案如下图所示（同一种颜色代表一个请求）：

• Process: CPU 侧的组 batch + 主模型启动操作；
• Schedule: XPU 侧的主模型 + MTP 模型运算；
• Post Process: 请求完全结束后的 CPU 后续处理。

流程优化逻辑如下：当第一个请求的 XPU 算子执行时，提前启动下一个请求的组 batch 与算子启动流程，此时组 batch 耗时可被完全掩盖；第一个 batch 的 XPU 运算完成后，CPU 执行后续处理，随后触发已提前启动的下一个 XPU 算子。依此循环，组 batch 耗时可被彻底消除。

经过优化后，TPOT 可降低约 10%。

4. 总结与展望

百度天池超节点推理性能优化实战成效

百度天池超节点通过「PD 分离架构 - 硬件升级 - 软件深耕」的三阶优化路径，实现大模型推理性能的跨越式突破，充分验证了昆仑芯与百度百舸的软硬协同优势：

• 第一阶段以架构革新破除性能瓶颈，在大规模部署场景下，通过 EP 分离 + PD 分离的创新架构设计，直接实现推理性能 10 倍跃升，为后续优化奠定坚实基础；
• 第二阶段聚焦硬件潜能释放与软件深度适配，将传统 8 卡全互联架构升级为 32 卡超节点全互联，并通过算子融合、通信调度等全栈软件优化，彻底激活硬件算力。

在 4K 输入上下文场景下：

Prefill 阶段单卡吞吐达 4.1K，较 PD 分离架构下非超节点硬件形态的 P800 提升 45%；Decode 阶段单卡吞吐突破 1.006K，较前者实现了 168%的性能提升，且核心延迟指标 TPOT 仅为 47.6ms。

未来展望

在当前市场阶段，千亿参数级模型仍是主流。我们认为，32/64 卡规模的超节点能够很好的承载推理及训练对算力的需求 —— 它不仅通过大幅扩展 Scale-up 域显著提升了 EP 并行效率，更在成本控制上展现了极高的性价比。百度天池超节点是将极致性能与可落地性深度融合：以高稳定性、快速部署、极简运维构建高效交付闭环，真正实现「以 8 卡机的部署运维体验，兑现超节点的极致算力」。

未来，随着模型的发展与软硬件技术的日趋成熟，更大规模的超节点落地将是必然趋势。面对显存容量瓶颈、KV Cache 空间压力等挑战，我们将通过软硬件深度协同创新，持续支撑更大集群规模与更多样化模型部署需求。

在硬件层面，昆仑芯全新一代产品即将陆续面世，百度天池超节点的 Scale-up 域将进一步扩展至 512 卡规模，全力支撑万亿参数模型的极限挑战；而在软件层面，面向刚刚发布的 DeepSeek V3.2，以及未来大量模型的持续迭代，软件优化工作也将永不停歇。

通过硬件与软件的协同创新，百度智能云将不断突破超节点性能上限、下探每 Token 算力成本，既支撑企业快速落地超节点，更通过长期技术迭代与企业共同兑现超节点「越用越优」的业务价值。