《解锁PD分离推理性能瓶颈：百度智能云的网络优化黑科技》

揭秘百度智能云PD分离推理的网络优化黑科技

　　 为满足PD分离式推理部署架构的需求，百度智能云在物理网络层面打造了「4us端到端低时延」的HPN集群，并在网络流量层面进行了设备配置与管理的优化。同时，在通信组件和算子层面也进行了针对性改进，大幅提升了上层推理服务的整体性能。

　　 百度智能云在大规模PD分离式推理基础设施优化的过程中，深刻体现了网络基础设施、通信组件与上层业务特征深度融合的关键作用。

　　 1.PD 分离式推理服务对网络的需求

　　 传统的推理服务通常采用集中式的架构，多数情况下是单机部署。即便存在多机部署的情况，机器的数量也相对较少，因此对网络带宽和时延的要求并不高。然而，对于当前大规模的PD分离式推理系统而言，网络通信的需求已经发生了显著的变化。

　　 随着EP专家系统的规模不断扩大，其架构将从单机和双机的小范围模式升级为更大规模的部署。这一变化使得EP节点间的“Alltoall通信域”显著增加。这无疑对网络基础设施以及Alltoall算子的通信效率提出了更高挑战，而这些因素将直接作用于OTPS、TPOT等关键性能指标，进而对用户的实际体验产生重要影响。

　　 PD分离式部署在实际应用中已逐渐成为一种主流架构，其中Prefill和Decode之间的KVCache通信显得尤为关键。KVCache的时延不仅关系到单个任务的完成效率，更是决定整个推理服务性能的重要因素。在当前技术环境下，如何优化KVCache的数据传输路径，减少不必要的延迟，已成为各大技术团队关注的核心问题之一。 在我看来，KVCache通信的优化不仅仅是一个技术挑战，更是一次推动行业进步的机会。通过引入更高效的压缩算法或利用更高带宽的网络连接，可以显著降低时延，从而提升整体的服务质量。同时，这也提醒我们，在追求高性能的同时，还需要注重系统架构的整体平衡，避免因单一环节的改进而引发其他问题。 随着人工智能应用场景的不断扩展，类似这样的技术细节将会被赋予更大的价值。未来，我们有理由相信，通过持续的技术创新与实践探索，KVCache通信的瓶颈终将被突破，为用户提供更加流畅、高效的智能服务体验。

　　 为提高大规模PD分离式推理系统的运行效率，百度智能云专门针对网络基础设施和通信组件进行了优化。

　　 物理网络层面:为适配 Alltoall 流量专门建设了「4us 端到端低时延」 HPN 集群,支持自适应路由功能彻底解决网络哈希冲突,保证稳定的低时延。

　　 在流量管理领域，针对Alltoall多打一的incast流量导致的性能瓶颈问题，我们正在探索更高效的解决方案。特别是在HPN（高性能网络）环境中，训练与推理任务往往会产生不同特性的流量需求，如何确保这两种任务互不干扰成为关键。为此，我们引入了先进的队列管理策略，为训练和推理流量分别设计了独立的资源分配机制，从而显著提升了整体系统的运行效率。 同时，通过自主研发的高性能KVCache传输库，我们成功实现了DCN（分布式计算网络）中基于RDMA技术的弹性数据传输，确保了在高负载下的满带宽利用。这一突破不仅优化了网络利用率，还大幅减少了延迟，为大规模模型训练和实时推理提供了坚实的技术支撑。 我认为，这种针对性的优化措施充分体现了现代数据中心在网络层面精细化管理的趋势。尤其是在AI加速发展的背景下，高效的数据传输和流量调度显得尤为重要。未来，随着更多创新技术的应用，相信我们可以进一步提升网络性能，满足日益增长的计算需求，助力各行各业的数字化转型。

　　 在通信组件的优化方面，我们对Alltoall算子进行了深度改进，与开源版本相比，显著提升了Prefill和Decode场景下的通信效率。特别是在动态冗余专家编排上，我们通过精细调控，将专家的负载均衡度严格控制在1.2以下，从而保证集群内各GPU的通信时间趋于一致，避免了资源分配不均带来的性能瓶颈。 此外，我们还引入了双流优化策略，有效实现了计算与通信的最大程度重叠，这一创新不仅提高了系统的运行流畅性，更带来了整体吞吐量约20%的增长。这种技术上的突破，无疑为大规模分布式训练提供了强有力的支持，同时也标志着我们在高性能计算领域迈出了坚实的一步。未来，随着更多类似优化措施的落地，相信能够进一步推动AI模型训练效率的跃升，助力行业向更高水平发展。

　　 下面我们逐一介绍百度智能云在以上几个层面的优化实践。

　　 2. 解决方案和最佳实践

　　 2.1.建设适配 Alltoall 流量特征的 HPN 网络设施

　　 百度智能云在训练场景下的 HPN 网络架构设计已经有着丰富的经验,AIPod 使用多导轨网络架构,GPU 服务器配有 8 张网卡,然后每张网卡分别连到一个汇聚组的不同 LEAF 上。在 LEAF 和 SPINE 层面,通过 Full Mesh 的方式进行互联。

　　 以下图为例,考虑一个训练场景下的 3 层架构 HPN 网络:

　　 2.1.1.训练和推理任务的流量特征

　　 非 MoE 训练任务的流量特征

　　 在传统的非MoE训练环境中，跨机器通信所产生的流量大多为同号卡流量。例如，在梯度同步过程中产生的AllReduce、ReduceScatter、AllGather操作，以及Pipeline Parallelism（PP）中的SendRecv通信等。在这种情况下，同号卡通信的最佳状况是可以仅通过一跳完成。以示例图为例，每个Leaf交换机拥有64个下联端口，因此在64台服务器规模下，同号卡通信理论上能够实现一跳直达。

　　 规模再大,为了降低网络流量的压力，百度百舸在任务调度时采用了智能的亲和性调度策略。在任务创建阶段，系统会优先将同一通信组内的Rank分配到同一个Leaf交换机所连接的服务器中。这种设计能够有效减少数据在Spine或SuperSpine间的流动，从而大幅优化网络资源的使用效率。从技术角度看，这一举措不仅提升了系统的整体性能，还为大规模分布式计算环境中的流量管理提供了新思路。 在我看来，这种基于硬件架构特性的优化手段体现了现代云计算平台对底层硬件资源利用的深刻理解。通过精确的任务调度，可以最大限度地发挥Leaf交换机的能力，避免不必要的跨层通信，这对于需要频繁交互的任务尤为重要。未来，随着数据中心规模的进一步扩大，类似的技术创新将成为提升系统效率的关键因素之一。同时，这也提醒我们，在追求技术创新的同时，充分考虑硬件特性和实际应用场景同样至关重要。

　　 MoE 推理流量特征

　　 在推理服务中，MoEEP间的Alltoall通信模式与AllReduce等模式存在差异，会引发大量的跨导轨通信流量。尽管Prefill阶段可通过软件层面的优化来消除跨导轨流量的问题，但在Decode阶段这一情况却难以避免。这使得多设备间的通信不仅限于同号卡之间，跨设备的流量大多无法实现单跳直达，往往需要经过SPINE或SUPERSPINE节点，进而造成时延上升。

　　 MoE 训练流量特征

　　 在MoE模型的训练过程中，流量模式相较于传统模型更为复杂，它融合了训练与推理的双重特性。在此过程中，不仅会出现传统的梯度同步操作，如AllReduce、ReduceScatter或AllGather，还会有Pipeline Parallelism（PP）阶段的SendRecv通信，以及Expert Parallelism（EP）阶段的Alltoall交互。这些通信流量不仅可能涉及跨硬件模块的数据传输，还可能存在重叠的情况，从而引发相互干扰的问题。

　　 2.1.2. 面向 EP 的 HPN 架构优化

　　 在设计高性能网络（HPN）时，考虑到Alltoall通信的独特需求，我们倾向于优先确保跨导轨的流量最多只需经过两跳即可到达目标节点，同时引导Alltoall流量集中汇聚到SPINE层。这种设计策略旨在最大限度地降低跨导轨通信的延迟，从而提升整体网络性能。从我的角度来看，这样的架构设计不仅能够有效应对大规模数据交换的需求，还能够在复杂网络环境中实现更高效的资源利用。特别是在当前数据中心规模日益扩大的背景下，这种优化方案显得尤为重要，它为未来更高性能的数据中心网络建设提供了宝贵的经验和技术支持。

　　 在现代数据中心网络架构中，采用LEAF层所有设备通过一根线接入同一台SPINE交换机的设计，能够有效实现集群内部的AlltoAll跨导轨流量汇聚至SPINE层。这种优化方式不仅提升了整体网络效率，还显著降低了跨导轨通信的延迟，将原本的5微秒缩短至4微秒。这一改进对于追求极致性能的应用场景尤为重要，尤其是在对延迟敏感的数据处理任务中，哪怕仅仅是1微秒的提升，也可能带来显著的竞争优势。 在我看来，这样的技术进步体现了当前数据中心网络设计向更高集成度和更低延迟方向发展的趋势。通过减少不必要的路径跳转，不仅可以降低设备间的通信延迟，还能减轻网络拥塞风险。未来，随着更多类似创新的涌现，我们有理由相信，数据中心的性能极限还将被进一步突破，从而更好地满足日益增长的计算需求。

　　 这种经过优化后的 HPN 网络架构,能接入的卡数主要取决于交换机芯片支持的最大的下联口有多少。虽然对于超大模型的训练任务来说,这个集群规模可能不够,但是对于推理来说,通常不需要那么大规模的机器,是可以满足需求的。

　　 2.1.3.自适应路由彻底消除 hash 冲突

　　 同时,由于 Alltoall 通信流量的特征,LEAF 到 SPINE 之间的通信流量会成为常态。当流量需要通过 SPINE 传输的时候,会由 hash 选择 SPINE 出口的过程,这时候有可能会产生 hash 冲突,导致网络抖动。因此为了避免 hash 冲突,百度智能云基于自研交换机实现自适应路由。如下图所示:

　　 假设A与C执行Alltoall跨导轨通信时，A发出的数据流必定需要通过SPINE转发。当数据到达LEAF节点时，系统会依据数据包进行哈希计算，并结合当前链路的负载状况，智能选择最佳出口路径，将数据分发至多个SPINE节点。

　　 百度智能云通过报文哈希的方式将流量分配至不同物理路径，有效解决了因哈希冲突引发的时延增加问题，从而减少了性能波动，确保了网络具备稳定且低时延的传输特性。

　　 详情可参考:全面攻克网络哈希冲突，百度百舸高性能网络HPN的实际应用案例

　　 2.2.Alltoall 和 KV Cache 流量的管理和优化

　　 2.2.1. 避免 incast 造成降速,不同类型流量的分队列管理

　　 Alltoall 多打一,不合理的配置造成降速

　　 在推理服务场景下，EP之间的Alltoall通信模式与传统训练中的AllReduce有着显著差异。在这种模式中，网络上的多对一通信（即incast）现象十分普遍，且其严重程度会随着系统规模的扩大而加剧。这种突发性的incast流量容易对接收端网卡的上联交换机端口形成压力，进而触发优先级流量控制（PFC）机制，最终可能导致整个网络性能下降。 在我看来，这种现象揭示了分布式计算架构在面对大规模推理任务时所面临的挑战。特别是在当前AI应用需求日益增长的背景下，如何有效缓解因incast引发的网络拥塞问题显得尤为关键。一方面，我们需要优化算法设计以减少不必要的通信量；另一方面，也应探索更高效的网络调度策略和技术手段来应对这类突发情况，从而保障系统的稳定性和可靠性。总之，通过技术革新和合理规划，我们能够更好地适应未来更加复杂的应用场景需求。

　　 在传统的Alltoall通信模式中，存在一种“流量多打一”的现象。例如，假设机器A和机器C中的GPU0、GPU2、GPU4、GPU6都需要向机器B的GPU0传输数据，那么在这种情况下，网络上将会出现8个发送方同时向同一个接收方传输数据的情形。

　　 传统的Alltoall操作，比如在PyTorch中使用的实现方式，通常会依赖于sendrecv来完成通信任务。这种实现方法虽然能够满足基本需求，但在大规模分布式训练场景下，网络中的“多对一”现象仍然不可避免。从理论上讲，采用更先进的PXN技术可以在一定程度上减少这种“多对一”的通信瓶颈，然而即便如此，“多对一”的问题依旧存在。 个人认为，在当前的技术背景下，尽管PXN技术提供了一种优化方向，但其实际效果可能仍需进一步验证。特别是在超大规模的数据中心环境中，如何有效缓解“多对一”带来的延迟与带宽压力，依然是一个值得深入研究的问题。未来或许可以通过结合硬件加速器以及更加智能的调度算法，来更好地平衡资源分配，从而提升整体系统的性能表现。同时，这也提醒我们，在追求高效能计算的同时，也应关注底层架构设计的合理性与灵活性。

　　 在Alltoall算子的实际应用中，网络中的多打一现象始终难以完全规避。这种情况下，如果网络侧的拥塞控制算法设置得不够合理，尤其是对拥塞反应过于敏感，就可能导致系统主动降低传输速度。这一过程不仅会增加通信延迟，还会显著影响整体的数据吞吐量，从而对系统的性能表现带来不利影响。 我认为，在设计和调整网络拥塞控制算法时，需要更加注重平衡性。一方面要确保网络能够快速响应真实的拥塞情况，避免因资源过度占用而导致的服务质量下降；另一方面也要防止算法过于保守，频繁触发降速机制，这可能会引发不必要的性能瓶颈。未来的研究方向或许可以聚焦于开发更智能的算法，使其能够在复杂多变的网络环境中找到最佳的平衡点，以提升大规模分布式计算任务的整体效率。

　　 推理训练任务中非 Alltoall 流量的干扰

　　 除此之外,如果集群内还存在其他流量,例如训练任务 DP(数据并行)之间的 AllReduce 或者 ReduceScatter 或者 AllGather,或者 PD(Prefill-Decode)之间的 KV Cache 传输,也会对 Alltoall 的流量造成影响,从而进一步降低推理引擎的整体吞吐。

　　 在现代数据中心网络中，无论是服务器网卡的设置，还是交换机的参数调整，都必须针对Alltoall这种特殊的多对一incast流量进行专门优化。这种流量模式在大规模集群计算中尤为常见，尤其是在高性能计算或分布式存储系统里，其性能直接影响到整个系统的效率。因此，除了优化Alltoall流量本身，还需要尽可能减少集群内部其他类型流量对其造成的干扰，确保关键任务能够稳定高效地运行。 在我看来，随着云计算和大数据技术的发展，网络资源的竞争变得日益激烈。在这种背景下，如何平衡不同类型的网络流量需求成为了一个亟待解决的问题。一方面，我们需要通过技术创新来提升硬件设备处理复杂流量模式的能力；另一方面，也要从软件层面入手，比如采用智能调度算法，合理分配带宽资源，从而最大限度地发挥现有网络基础设施的潜力。总之，在未来很长一段时间内，如何更好地支持Alltoall这类特殊流量将是衡量一个数据中心性能优劣的重要标准之一。

　　 针对这种情况,我们给出的解决方案如下:

　　 在队列管理方面，通过端侧网卡对EP流量进行专门的优先级设置，将Alltoall流量分配至高优先级队列。而其他训练流量，例如AllReduce等，则采用低优先级队列处理。

　　 在资源层面,在终端设备的网卡以及交换机的高优先级队列中，应预留更大的缓冲区，分配更高的带宽比例，从而优先确保高优先级队列流量的稳定传输。

　　 在拥塞控制算法的配置方面，高优先级队列选择禁用ECN标记功能，使得DCQCN算法不会对因Alltoall流量微突发引发的拥塞产生响应，进而有效应对因incast问题导致的性能下降。

　　 通过端侧网卡与网侧交换机的协同优化，能够确保Alltoall通信的带宽和时延表现，从而实现训练与推理任务的相互独立运行，同时有效应对因incast流量引发的意外减速问题，显著降低性能波动现象的发生。

　　 经过测试,在我们部署的推理服务中,Alltoall 过程的整体通信时延有 5% 的降低。

　　 2.2.2.DCN 支持弹性 RDMA 实现 KV Cache 满带宽传输

　　 在PD分离式推理架构中，除了PD之间的Alltoall通信外，还涉及KVCache的数据传输。尽管KVCache的流量带宽需求相对较小，但为了防止两种流量相互干扰，通常会将KVCache的传输任务独立部署于DCN网络，从而实现与Alltoall流量的彻底隔离。

　　 在 DCN 网络的设计上,为了保证 KV Cache 流量的传输带宽,其网络架构收敛比采用 1:1。端侧网卡支持弹性 RDMA,使用 RDMA 协议保证 KV Cache 的高性能传输。

　　 百度智能云自主研发了一款高性能的KVCacheRDMA传输库，在传输库层面进行了优化设计，并与框架层实现了深度定制化。该传输库不仅支持上层框架进行分层数据传输，还能够实现多层KVCache的批量传输，从而方便在框架层实现计算与数据传输的并行处理。

　　 经过上述设计优化，KVCache的数据传输已成功实现主网卡带宽的充分利用，且传输过程能够与计算任务完美重叠，不再对推理系统构成性能瓶颈。这一突破不仅显著提升了整体系统的运行效率，也进一步证明了硬件资源的高效整合对于提升AI计算性能的重要性。在当前AI模型日益复杂化的背景下，如何平衡计算与数据传输之间的关系显得尤为关键。这次优化无疑为行业提供了一个值得借鉴的成功案例，同时也提醒我们，在追求更高算力的同时，合理规划和优化系统架构同样不可或缺。

　　 2.3.提高推理服务组件的网络通信效率

　　 随着高带宽低时延网络基础设施的普及，如何充分发挥其潜力已成为软件服务领域的重要课题。这一基础设施为各行各业带来了前所未有的机遇，但同时也对软件设计提出了更高要求。例如，在线教育、远程医疗等领域的应用能否真正实现高效互动，很大程度上取决于软件能否有效利用这些网络特性。我认为，未来的软件开发不仅要关注功能的丰富性，更应注重优化用户体验，确保在网络条件允许的情况下，服务能够以最快速度响应用户需求。此外，开发者还需考虑到不同设备和网络环境下的兼容性问题，这样才能让优质网络资源惠及更多人群。总之，只有软硬件协同发展，才能最大限度地释放网络基础设施的价值。

　　 在我们对PD分离推理服务进行性能分析时，发现了一些制约网络通信效率的重要因素。

　　 2.3.1 Alltoall 算子的通信效率

　　 近期，社区开源项目DeepEP展示了其在推理系统中dispatch与combine过程的Alltoall高性能算子实现，这一成果令人印象深刻。从技术角度来看，该项目不仅优化了通信效率，还显著提升了整体性能。在我看来，这种专注于底层优化的工作对于推动深度学习框架的发展至关重要。尤其是在分布式计算日益普及的今天，高效的通信机制能够大幅降低延迟，提高系统的吞吐量。DeepEP的成功经验表明，持续关注细节并不断迭代改进是技术进步的关键。希望未来能看到更多类似的创新成果，为开发者提供更多强有力的工具支持。

　　 在Prefill场景下，当输入的batchsize较大时，Alltoall通信算子的同号卡传输阶段需要兼顾显存资源的平衡与性能优化。因此，该阶段通常采用分chunk传输的方式，通过循环利用一小块显存来完成数据交换。同时，为确保通信效率与稳定性，系统对每次RDMA发送以及机内NVLink传输的token数量进行了合理限制。这种设计不仅有效缓解了显存压力，还显著提升了整体计算任务的执行效率。 我的观点认为，在大规模AI模型训练过程中，如何高效管理显存资源是一个核心挑战。上述提到的分chunk传输方式是一种非常实用的技术手段，它能够帮助开发者在面对高并发任务时找到性能与成本之间的最佳平衡点。此外，对token数量的严格控制也体现了现代分布式系统设计中的精细化管理理念，这对于我们未来构建更加智能高效的计算架构具有重要的参考价值。

　　 通过对网卡传输带宽的实际监测发现，其并未达到完全饱和的状态。基于这一观察，我们针对不同类型的GPU芯片，在网络传输显存大小以及每轮发送接收最大token数等关键参数上进行了细致调优。经过一系列优化措施后，DeepEP的传输效率显著提高，整体性能提升了大约20%，而此时网络带宽也接近被充分利用。这一成果表明，尽管硬件条件存在一定的限制，但通过软件层面的深度挖掘与精准调整，仍能实现系统性能的大幅提升。这也提醒我们在面对技术挑战时，不仅要依赖硬件升级，更应注重算法与架构的创新，以期获得更大的突破空间。

　　 对于Decode而言，DeepEP的实现侧重于多机之间的EP通信，并未对机内与机间的通信进行区分，统一采用网络发送的方式。这样的设计初衷是为了避免占用GPU的SM资源，使得在完成网络发送后算子能够及时退出。在此期间，可以利用网络传输的时间执行其他计算任务，之后再调用Alltoall的接收算子，从而实现计算与通信的重叠操作。然而，这种方式的不足之处在于未能充分挖掘机内NVLink带宽的潜力，导致网络传输的数据量有所增加。

　　 因此,百度智能云在GPU算子内部采用CE引擎进行异步数据传输，这一方法能够在不消耗GPUSM资源的前提下，充分挖掘机内NVLink带宽的潜力，同时确保计算与通信之间的重叠操作不受影响。

　　 2.3.2 动态冗余专家编码,保证 EP 负载均衡

　　 在EP专家协作时，若出现处理token分配不均的现象，可能会引发Alltoall通信算子在不同SM（流多处理器）之间以及跨GPU通信算子间的负载分布不均衡。这种情况最终会导致整体通信时间被延长。

　　 为了实现推理服务引擎的负载均衡，提升整体吞吐量，百度智能云通过大规模线上实践发现，仅依赖静态冗余专家无法有效保证专家间的均衡分布。为此，我们特别开发了基于batchsize级别的动态冗余专家机制，使得专家均衡度（maxtoken/avgtoken）得以控制在1.2以内，从而避免了明显的“快慢卡”现象的发生。

　　 2.3.3 极致优化双流效果,整体吞吐进一步提升

　　 在推理服务或大模型训练中，如何实现通信与计算的Overlap并隐藏通信开销，始终是一个备受关注的重要课题。

　　 在百度智能云的实际应用中，我们在大规模推理服务里启用了双流技术。为了最大限度地减少通信延迟的影响，并实现最佳的重叠效果，我们不仅实施了专家均衡策略，还针对计算算子进行了深度优化。比如，我们调整了计算算子与通信算子的启动顺序，确保两者能够高效协同工作。同时，我们也合理分配了计算和通信所需的GPU资源，防止计算任务占用全部资源而使通信任务无法及时启动，从而有效减少了GPU运行中的空闲时间。经过这些改进，整体吞吐量提升了超过20%。 这样的优化措施无疑为云计算服务带来了显著的进步。它不仅提高了系统的运行效率，还进一步降低了延迟，这对于需要实时响应的应用场景尤为重要。未来，随着技术的不断进步，相信类似的技术优化会更加普遍，也将推动整个行业向更高性能的方向发展。

　　 3.总结

　　 百度智能云在大规模PD分离式推理基础设施优化的过程中，深刻体现了网络基础设施、通信组件与上层业务特征深度融合的关键作用。这种融合不仅是技术层面的创新,更是对实际业务需求的深刻理解和响应。