为了适当 PD 差别式推理安排架构,百度智能云从物理收集层面的「4us 端到端低时延」HPN 集群创设,到收集流量层面的开发摆设和办理,再到通讯组件和算子层面的优化,明显晋升了上层推理任职的整个功能。

　　百度智能云正在大领域 PD 差别式推理根柢步骤优化的实行中,敷裕显现了收集根柢步骤、通讯组件与上层生意特点深度调和的主要性。

　　古板的推理任职均是会合式,公共是单机安排。纵然是众机安排,呆板领域也极度小,对收集的带宽和时延需求都不大。而今大领域 PD 差别式推理体例来说,对收集通讯的需求则发作了转化:

　　引入大领域的 EP 专家并行。EP 会从单机和双机的小领域,酿成更大领域,以是 EP 之间的「 Alltoall 通讯域」成倍伸长。这关于收集根柢步骤、Alltoall 算子等的通讯出力都提出了更高的哀求,它们会直接影响 OTPS、TPOT 等目标,从而影响最终的用户体验。

　　为了晋升大领域 PD 差别式推理体例的出力,百度智能云针对性地优化了收集根柢步骤和通讯组件:

　　物理收集层面:为适配 Alltoall 流量特意创设了「4us 端到端低时延」 HPN 集群,声援自适当道由效力彻底处置收集哈希冲突,确保安稳的低时延。

　　流量办理层面:优化 Alltoall 众打一 incast 流量导致的降速题目。对 HPN 收集中磨练、推理等区别类型流量实行部队办理,实行训推职业的互不作梗。通过自研高功能 KV Cache 传输库实行 DCN 弹性 RDMA 满带宽传输。

　　通讯组件层面:Alltoall 算子优化,比拟开源的计划,大幅晋升 Prefill 和 Decode 的 Alltoall 通讯功能。针对 batch size 级此外动态冗余专家编排,将专家平衡度统制正在了 1.2 以下,确保集群中一共 GPU 通讯时刻大致肖似。优化双流,实行最大水准的准备和通讯 overlap,整个晋升 20% 模糊。

　　百度智能云正在磨练场景下的 HPN 收集架构计划仍旧有着丰裕的经历,AIPod 行使众导轨收集架构,GPU 任职器配有 8 张网卡,然后每张网卡差异连到一个集聚组的区别 LEAF 上。正在 LEAF 和 SPINE 层面,通过 Full Mesh 的式样实行互联。

　　正在古板非 MoE 的磨练场景下,跨机通讯爆发的流量大无数都是同号卡流量。比如正在梯度同步时期爆发的 AllReduce 或者 ReduceScatter 或者 AllGather,PP 之间的 SendRecv 等。同号卡通讯最佳环境可能只源委一跳,以上图为例,每个 LEAF 换取机有 64 个下联口,以是 64 台任职器领域同号卡通讯外面上可能做到一跳可达。

　　领域再大,就只可源委 SPINE 或者最差源委 SUPER SPINE 来实行通讯。为了淘汰流量上送 SPINE,百度百舸正在职业更改的时期会主动实行任职器的亲和性更改。正在创筑职业的时期,尽量把统一通讯组下的 Rank 排布正在统一 LEAF 换取机下的任职器内,那么外面上大一面流量都可能收敛正在 LEAF 下。

　　关于推理任职来说,MoE EP 之间的 Alltoall 通讯流量形式与 AllReduce 等区别,会爆发巨额的跨导轨流量。固然关于 Prefill 阶段来说,可能通过软件实行层面规避掉跨导轨的流量,然而 Decode 阶段照旧无法避免跨导轨,这会导致众机之间的通讯不单是同号卡通讯,跨机流量大一面并不行一跳可达,会有巨额的流量上到 SPINE 或者 SUPER SPINE,从而导致时延补充。

　　关于 MoE 磨练的流量会越发繁复,归纳了磨练和推理的流量特点,既存正在古板的梯度同步爆发的 AllReduce 或者 ReduceScatter 或者 AllGather,PP 之间的 SendRecv,也存正在 EP 之间的 Alltoall 流量。这些流量不单会闪现跨导轨传输的题目,他们之间可以会存正在 overlap 导致彼此合扰。

　　鉴于 Alltoall 通讯的特色,咱们正在计划 HPN 收集的时期,会思虑优先确保跨导轨流量至众 2 跳可达,让 Alltoall 流量收敛到 SPINE 层,以这种式样尽量淘汰跨导轨的通讯时延。如下图所示:

　　LEAF 层一共开发齐备有一根线接入统一台 SPINE 换取机,如许可能让集群内 Alltoall 跨导轨流量齐备收敛到 SPINE 层,跨导轨通讯时延可能进一步从 5us+ 缩小为 4us。

　　这种源委优化后的 HPN 收集架构,能接入的卡数合键取决于换取机芯片声援的最大的下联口有众少。固然关于超大模子的磨练职业来说,这个集群领域可以不敷,然而关于推理来说,平日不必要那么大领域的呆板,是可能满意需求的。

　　同时,因为 Alltoall 通讯流量的特点,LEAF 到 SPINE 之间的通讯流量会成为常态。当流量必要通过 SPINE 传输的时期,会由 hash 遴选 SPINE 出口的历程,这时期有可以会爆发 hash 冲突,导致收集震颤。以是为了避免 hash 冲突,百度智能云基于自研换取机实行自适当道由。如下图所示:

　　假设 A 和 C 实行 Alltoall 跨导轨通讯,A 发出的流量一定要源委 SPINE,那么流量正在来到 LEAF 的时期,会基于 packet 做 hash,并连合链道的负载环境动态遴选最优的出口,将报文发送到众个 SPINE 上。

　　基于报文 hash 到区别的物理旅途,百度智能云实行了链道负载平衡,歼灭因 hash 冲突时延补充导致的功能震颤,实行安稳的低时延收集。

　　详情可参考:彻底处置收集哈希冲突,百度百舸的高功能收集 HPN 落地实行

　　正在推理任职中,EP 间的 Alltoall 通讯流量性情与古板磨练中的 AllReduce 完整区别,收集上众打一变成的 incast 流量极度常睹。这种 incast 的主要水准会跟着领域的增大而增大。incast 流量的突发,可以会变成接纳侧网卡上联的换取机端口向发送侧反压 PFC,导致收集降速。

　　古板的 Alltoall 实行,比如 PyTorch 内部移用的 Alltoall,是行使 send recv 去实行的,倘若行使 PXN 可能缩小收集上的发作众打一的领域,然而众打一照旧存正在,如下图所示:

　　以是无论 Alltoall 的算子实行式样若何,收集上的众打一都无法避免。此时倘若收集侧的堵塞统制算法的摆设不对理,对堵塞过于敏锐,就会爆发降速,进而对整个模糊变成影响。

　　以是无论是端侧网卡的摆设,或者是换取机的摆设,都必要针对 Alltoall 这种众打一 incast 流量做针对性优化,同时尽量避免集群内其他流量对 Alltoall 流量变成影响。

　　正在部队办理层面,通过端侧网卡将 EP 的流量做特意的优先级摆设,将 Alltoall 流量导入到高优先级部队。其他磨练的流量,比方 AllReduce 等行使低优先级部队。

　　正在资源层面,正在端侧网卡和换取机的高优先级部队上,预留更众的 buffer,分拨更高比例的带宽,优先的确保高优先级部队的流量。

　　正在堵塞统制算法摆设层面,高优先级部队合上 ECN 标识效力,让 DCQCN 算法对 Alltoall 流量微突发变成的堵塞不做出反映,从而处置 incast 题目变成的降速。

　　正在源委端侧网卡和网侧换取机配合调节后,可能保证 Alltoall 通讯流量的通讯带宽和传输时延,实行训推职业的互不作梗,并有用的缓解 incast 流量带来的非预期的降速而变成的功能震颤。

　　源委测试,正在咱们安排的推理任职中,Alltoall 历程的整个通讯时延有 5% 的下降。

　　正在 PD 差别式推理体例中,还存正在 PD 之间 KV Cache 传输的流量。比拟 Alltoall 固然他的带宽需求不算大,但为了避免二者的流量彼此合扰,平日咱们会让 KV Cache 的传输流量孑立走 DCN 收集,使其与 Alltoall 的流量完整隔脱节。

　　正在 DCN 收集的计划上,为了确保 KV Cache 流量的传输带宽,其收集架构收敛比采用 1:1。端侧网卡声援弹性 RDMA,行使 RDMA 订定确保 KV Cache 的高功能传输。

　　正在传输库层面,百度智能云行使自研的高功能 KV Cache RDMA 传输库,其接口计划与框架层深度定制,声援上层框架分层传输,也声援众层 KV Cache 的批量传输,便于正在框架层做准备与传输的 overlap。

　　通过以上计划优化,KV Cache 传输正在主网卡可能用满带宽,传输时刻可能完整被准备 overlap 住,不可为推理体例的瓶颈。

　　正在有了高带宽低时延的收集根柢步骤的根柢上,若何用好收集根柢步骤,是推理任职软件层面必要核心思虑的事故。

　　正在咱们对 PD 差别推理任职的 profile 剖释当中,挖掘了少少影响收集通讯出力的要害身分。

　　关于 Prefill 来说,因为输入的 batch size 较大,Alltoall 通讯算子的同号卡传输阶段为了均衡显存资源和功能,采用分 chunk 传输的式样,发送和接纳会轮回行使一小块显存,并对每次 RDMA 发送以及机内 NVLink 传输的 token 数做了限定。

　　通过现实观测网卡的传输带宽,挖掘其并没有被打满。正在此根柢上,咱们对收集传输的显存的巨细,以及每一轮发送接纳的最大 token 数等摆设,针对区别的 GPU 芯片,做了少少细密化的调节,使之正在功能上有进一步的晋升。通过优化,DeepEP 的传输功能有大体 20% 的功能晋升,收集带宽仍旧基础被打满。

　　关于 Decode 来说,DeepEP 的实行是众机之间的 EP 通讯,不分别机内和机间,一律采用收集发送。如许做的思虑是为了机内传输也不消磨 GPU 的 SM 资源,实行收集发送后算子即可退出。正在收集传输的时刻内做准备,实行后再移用 Alltoall 的接纳算子,以此来实行准备和通讯的 overlap。但如许做的差错是机内的 NVLink 的带宽并没有被高效的应用起来,收集传输的数据量会变大。

　　以是,百度智能云通过正在 GPU 算子行家使 CE 引擎做异步拷贝,正在不占用 GPU SM 资源的环境下,也能实行机内 NVLink 带宽的高效应用,同时不影响准备和通讯的 overlap。

　　EP 专家之间倘若闪现经管 token 不服衡的环境,将会导致 Alltoall 通讯算子的区别 SM 之间,以及区别 GPU 的通讯算子之间,闪现负载不均的环境,导致的结果即是整个通讯时刻会被拉长。

　　因为 EP 专家之间的负载平衡是推理任职引擎晋升模糊的极度主要的一环,源委百度智能云的大领域的线上实行的经历来看,静态冗余专家并不行很好的确保专家平衡。以是咱们特意适配了针对 batch size 级此外动态冗余专家,把专家平衡度(max token/avg token)基础统制正在了 1.2 以下,不会闪现鲜明的「疾慢卡」的环境

　　通讯和准备 overlap,遁匿通讯的开销,从来都是推理任职,或者大模子磨练中,极度主要的课题。

　　正在百度智能云的实行中,咱们正在线上大领域的推理任职中开启了双流。为了尽量遁匿掉通讯的开销,到达最好的 overlap 的功效,除了做 EP 之间的专家平衡以外,瞄准备算子也做了针对性的优化,比如瞄准备算子和通讯算子 kernel launch 的序次做合理排布,对二者所需的 SM 资源做合理的分拨,避免闪现准备算子占满 SM 导致通讯算子 launch 不进去的环境,尽可以的扑灭掉 GPU 间隙的资源浪掷。通过这些优化,整个的模糊可能晋升 20% 以上。

　　百度智能云正在大领域 PD 差别式推理根柢步骤优化的实行中,敷裕显现了收集根柢步骤、通讯组件与上层生意特点深度调和的主要性。这种调和不光是时间层面的立异,更是对现实生意需求的深远贯通和相应。