企业官网建设流程全解析

上海网站外包,三亚市建设局官方网站,wordpress多主题插件下载地址,汕头住房与城乡建设网站1. 背景超节点作为一种创新的硬件架构#xff0c;通过构建大规模全互联的 Scale-up 网络#xff0c;有效突破了传统 8 卡节点在通信上的「互联墙」瓶颈#xff0c;为上层业务提供了极致的互联带宽与统一显存池化能力#xff0c;从而实现大模型推理服务性能的跨越式提升。结…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 CacheKV Cache 的预留空间直接决定了系统能支持的最大上下文长度Context Length和最大并发数Batch Size因此在确保每张卡能放得下模型权重以外也要为 KV Cache 预留足够的显存容量。综合上述计算特性与资源约束我们制定了如下部署策略Prefill 阶段高并行度换取低时延采用 16 卡作为一个计算单元使用 TP4Tensor Parallelism 4 SP4Sequence 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和 EP32Expert 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 阶段采用全 DPData 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 定长上下文、batch2」的请求为例开启双流优化后会将总计 8K 的输入 token4K×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 切 TPMHA 部分也按照 num_head 切分o_proj 切 TP最后使用 AllReduceMLP 部分使用序列切分MLP 计算完成后 AllGather 聚合结果。方案二采用 TP SPq_down 和 kv_down 采用序列切分然后 AllGather 汇聚 BSq_up 和 kv_up 切 TPMHA 部分按照 num_head 切分o_proj 切 TP最后使用 ReduceScatter进入 MLP 后使用序列切分。方案三在方案二的基础上MHA 后使用 AlltoAllo_proj 不做 TP 切分采用序列切分。使用方案一q_down 和 kv_down 存在冗余计算这部分单卡计算量是方案二和方案三的 4 倍通信的部分引入 AllReduce AllGather总通信量为:BS x 16128AllReduceAllGather使用方案二通信的部分引入 AllGather ReduceScatter总通信量为:BS x 5772AllGatherReduceScatter使用方案三通信的部分引入了 AllGather AlltoAll总通信量为:BS x 3468AllGatherAlltoAll可以看到方案三的通信量最少这也是我们所采用的 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μscombine 时延仅 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 算力成本既支撑企业快速落地超节点更通过长期技术迭代与企业共同兑现超节点「越用越优」的业务价值。