
【导读】
AI大模型的“智能涌现”,背后是算力规模的暴力美学。当数万乃至数十万GPU集群协同“思考”时,一张看不见、摸不着却至关重要的网络,正扮演着其“神经中枢”的角色。这张网络的性能,直接决定了万亿参数模型训练的效率与成败。
本文将以百度智能云的智算网络(HPN)为例,深度拆解其从万卡到十万卡规模演进的技术脉络。我们将穿透喧嚣的“参数战争”表象,直抵底层基础设施的核心——网络架构。这不仅是一部技术迭代史,更是一场关于拥塞控制、软硬协同与前瞻性布局的系统工程范例。
2023年,生成式AI的浪潮席卷全球,大模型参数量从千亿向万亿迈进,其背后是对计算资源近乎无尽的渴求。然而,分布式训练的效率并非GPU数量的简单堆砌。一个核心的性能瓶颈在于通信开销,即节点间同步海量梯度数据所需的时间。
为了在数千乃至数万GPU上协同训练一个大模型,业界普遍采用3D并行策略,即数据并行(Data Parallelism, DP)、流水线并行(Pipeline Parallelism, PP)和张量并行(Tensor Parallelism, TP)的组合 1。这三种并行方式对网络的通信需求截然不同:
●张量并行 (TP):对模型内部的算子(如矩阵乘法)进行切分,分布在多个GPU上。此过程涉及频繁的、小颗粒度的通信(如All-Gather、Reduce-Scatter),对网络延迟(Latency) 极为敏感,通常要求微秒(μs)级别的延迟。因此,TP通常被限制在通过NVLink高速互联的服务器内部(Scale-Up),或由高速RDMA网络连接的少数几个节点内 4。
●流水线并行 (PP):将模型的不同层(Layer)切分到不同的GPU上,形成一个流水线。其通信模式主要是节点间的点对点(Point-to-Point)通信,传递中间层的激活值。PP对网络延迟同样敏感,因为延迟会直接导致流水线“气泡”(bubble),降低GPU的有效利用率 4。
●数据并行 (DP):在每个GPU上保留一份完整的模型副本,并将训练数据分片(shard)后输入。每个训练步后,所有GPU需要同步梯度,这依赖于All-Reduce集合通信。DP的通信量与模型参数量成正比,因此对网络带宽(Bandwidth) 的要求极高7。
经典的通信开销模型 Tcomm=α+L/β (其中 α 为延迟,β 为带宽,L 为数据量)清晰地揭示了这一挑战。对于万亿参数模型,巨大的 L 值使得带宽 β 成为决定性短板。
当集群规模扩展至数万乃至十万卡时,硬件故障成为常态。单个H100 GPU的平均无故障时间(MTBF)约为50,000小时(近6年),但一个拥有16,384张卡的集群,理论上每3小时就会发生一次故障 8。任何一次故障都可能导致训练中断和回滚,严重影响有效训练时长。
因此,集群的有效算力不仅取决于理论峰值性能,还受制于故障率和故障恢复时间。业界常用**模型FLOPs利用率(Model FLOPs Utilization, MFU)**来衡量实际获得的有效计算量,通常只有35-45% 9。而由故障导致的时间损失(L(t))可以通过一个模型来估算:
L(t)=c/t+gλt/2
其中,c 是单次保存检查点(checkpoint)的时间,t 是两次检查点之间的时间间隔,g 是恢复时间与检查点时间的比率,λ 是集群的故障率 8。这个公式表明,在超大规模集群中,必须通过高速网络(降低c)和高可靠性(降低\lambda)来最小化时间损失,最大化有效算力。
在此背景下,传统数据中心网络已然失效。一场专为AI工作负载设计的网络革命势在必行。百度“百舸”AI异构计算平台及其高性能网络(HPN)的演进,为我们提供了一个观察这场革命的绝佳样本。
2023年初,业界仍沉浸在GPT-3.5(ChatGPT的基座模型)带来的震撼中。紧接着,OpenAI于3月发布了能力更强的多模态模型GPT-4,Meta则在2月开源了LLaMA模型,正式拉开了“百模大战”的序幕 10。这一时期的主流模型均为稠密(Dense)模型,其训练的核心挑战是如何高效地进行数据并行(DP),以利用数千张GPU的算力缩短训练周期。因此,网络设计的焦点集中在如何极致优化All-Reduce通信性能上。
面对AI训练中占据主导地位的东西向流量,百度并未简单套用传统网络拓扑,而是进行了一次精巧的物理工程创新。
●网络拓扑:采用标准的两层胖树(Fat-Tree)架构,Leaf层(接入)与Spine层(汇聚)之间严格遵循1:1无收敛比设计,这是实现大规模并行计算无阻塞通信的基石13。
●服务器配置:单机配置8张GPU卡,并采用“一卡一网口”模式,例如配置8张100Gbps网卡(如NVIDIA ConnectX系列),单机总出口带宽达到800Gbps 13。
●核心创新:“导轨”(Rail)优化:这并非一种新协议,而是一种物理布线策略上的“巧思”。集群中所有服务器上相同编号的网卡(例如,所有服务器的1号网卡)被物理连接至同一台接入交换机。由此,8台接入交换机形成了8条并行的“导轨”,每条导轨承载所有服务器同号网卡的流量 13。
这一设计的深层逻辑在于,主流分布式训练框架(如NVIDIA的NCCL)在执行All-Reduce操作时,最高频的通信模式之一就是同号GPU(及其关联网卡)之间的环形通信。“导轨”设计使得这些关键通信路径在物理上实现了单跳直达,从根本上降低了延迟和拥塞概率。

图1:8导轨优化的两层架构ROCEv2网络(引用自《智算中心网络架构白皮书》)
为进一步优化通信效率并实现模块化扩展,百度提出了**“AI-Pool”**的设计理念,可视为一种POD(Point of Delivery)化的早期实践 13。
●构成:一个AI-Pool由8台接入交换机(即8条导轨)及下联的服务器集群组成,典型配置可支持512张GPU卡 13。
●通信路径优化:
○同号卡通信:得益于“导轨”设计,AI-Pool内任意两台服务器的同号GPU通信仅需1跳。
○异号卡通信:传统路径需经Spine层(3跳)。但通过在通信库层面引入**“Rail Local”**技术,可将跨机、跨导轨的通信,巧妙地转化为“机内高速互联(NVSwitch) + 1跳网络路径”,极大提升了任意GPU间的通信效率 13。
选择基于标准以太网的RoCEv2技术,意味着必须在有损的以太网上构建一个无丢包的网络环境。百度通过精细组合和调优PFC、ECN及DCQCN这“三驾马车”,成功实现了这一目标13。
1.PFC (优先级流控):作为基础保障,是一种逐跳的链路层流控机制,通过发送PAUSE帧来防止缓存溢出丢包,但可能引发队头阻塞。
2.ECN (显式拥塞通知):一种更主动的端到端拥塞管理机制,通过在IP头中标记拥塞位,通知发送端主动降速。
3.DCQCN (数据中心量化拥塞通知):一种将PFC和ECN有机结合的先进拥塞控制算法,其核心是“用ECN来避免PFC的触发”,在保证无损的同时,最大限度减少了PFC带来的性能抖动。
在奠基阶段,通过对物理拓扑的深度定制、模块化架构的创新以及对RoCEv2协议栈的精细驾驭,百度构建了一个高度优化的、为AI而生的网络底座。
2023年下半年至2024年,大模型竞赛进入白热化阶段。Meta发布Llama 2,并于2024年3月宣布已拥有两个2.4万卡的GPU集群 13。文心一言的发布也标志着百度进入了万卡集群时代13。集群规模从“几千卡”跃升至“数万卡”,这不仅仅是量的变化,更带来了质的挑战。
在千卡规模,数据并行(DP) 是主要矛盾,网络优化的核心是All-Reduce。但进入万卡规模后,为了将巨大的模型装入显存并维持合理的批次大小(Batch Size),3D并行成为必需。例如,GPT-4的训练就采用了8路张量并行和15路流水线并行的复杂策略 14。这意味着网络中同时存在着对延迟极度敏感的TP和PP流量,以及对带宽要求极高的DP流量。网络必须从一个为单一通信模式(All-Reduce)优化的系统,演进为一个能够高效处理多种复杂通信模式的、更大规模的系统。
三层CLOS架构(TOR-Leaf-Spine)通过增加一个核心层,显著增强了网络的可扩展性,理论上可将集群规模从数千卡提升至数万卡,完美匹配了万卡集群的需求 13。
同时,在这一阶段,百度展现出成熟的双轨并行策略:
●InfiniBand HDR:针对性能要求最苛刻的旗舰级训练集群,部署基于200Gbps InfiniBand的万卡集群,利用其原生无损、极低延迟的优势 13。
●高密RoCEv2:在文心一言的万卡集群中,延续并大规模部署了RoCEv2技术,提供了更具成本效益和生态开放性的选择 13。

图2:8导轨优化的三层CLOS架构IB网络(引用自《智算中心网络架构白皮书》)
当集群规模达到万卡级别,传统的ECMP(等价多路径)负载均衡技术的弊端开始显现。ECMP基于数据流的五元组进行哈希,在AI训练大量同构RDMA连接的场景下,极易产生哈希冲突,导致局部链路严重拥塞,而网络总体带宽利用率低下13。
百度的解决思路是向上层延伸,将网络拓扑信息引入AI任务的调度决策中,这催生了两项关键技术:
1.亲和性调度 (Affinity Scheduling):AI调度器不再是随机分配GPU资源,而是进化为理解底层物理拓扑的“智能导航员”。它遵循“同TOR → 同POD/Unit → 同集群”的原则,尽最大努力将一个任务的所有计算实例放置在网络距离最近的节点上,从源头减少了跨越多级交换机的流量,降低了拥塞概率 13。

图3:HPN网络亲和性调度(引用自《百度AI网络的架构创新与优化之路》)
2.DLB动态负载均衡 (Dynamic Load Balancing):作为亲和性调度的补充,DLB在数据流层面进行更主动的动态调整,避免将大量同构流哈希到同一物理链路。
通过“亲和性调度”的宏观布局与“DLB”的微观调控,百度构建了一套组合拳方案,据称可将物理网络的“带宽有效性”提升至**95%**的水平 13。这标志着一个重要理念的落地:网络性能优化是需要计算、网络、调度等多域协同的系统工程。
在万卡RoCEv2集群中,除了基础的“三驾马车”,还需要更深度的优化来保证稳定性与性能。这包括:
●严格的端到端配置一致性:确保PFC、ECN、CoS等所有参数在路径上的每一台设备(网卡、交换机)都完全一致,以避免PFC风暴或死锁等问题 9。
●深度缓存(Deep Buffer)交换机:采用具备深度、动态共享缓存的交换机芯片,以吸收AI训练中常见的、由大量节点同时通信(Incast)造成的微突发流量 9。
●全面的遥测(Telemetry)监控:对PFC暂停帧、ECN标记、队列深度等关键指标进行高精度监控,是验证无损行为、快速排障和精细调优的前提 9。
进入2024-2025年,随着模型参数向万亿乃至更高规模冲击,训练稠密模型的成本变得难以承受。**混合专家(Mixture of Experts, MoE)**架构应运而生,并被应用于GPT-4、Mixtral、Llama 4等前沿模型中。
●什么是MoE? MoE的核心思想是“分而治之”。它将一个巨大的前馈网络(FFN)层替换为多个小型的“专家”网络和一个“门控网络”(Gating Network)。对于每个输入令牌(Token),门控网络会动态地选择一到两个最相关的专家来处理它。这样,模型可以拥有海量的总参数(所有专家的参数之和),但在处理每个令牌时只激活一小部分参数,从而在不显著增加计算成本(FLOPs)的情况下,大幅提升模型容量 8。
●MoE的网络需求之变:MoE架构从根本上改变了网络的通信模式。稠密模型以数据并行为主,通信瓶颈是All-Reduce。而MoE模型中,由于令牌需要被动态地从源GPU“路由”到托管所选专家的目标GPU,这引入了大量的All-to-All通信。All-to-All是一种全局性的“多对多”通信,其流量模式比环形的All-Reduce复杂得多,对网络的全局吞吐、拓扑均衡性和拥塞控制能力提出了远超以往的严峻考验。
●集群规模:支持单集群10万卡+,服务器接入带宽升级至3.2Tbps(8*400G),由NVIDIA ConnectX-7等先进网卡提供支持 13。
●自研交换机:百度长达十年的自研交换机之路在此阶段显示出巨大的战略价值。从25.6T到51.2T,再到规划中的102T芯片,自研硬件不仅带来了成本与供应链的控制力,更核心的是实现了功能的深度定制,为后续一系列软件定义创新(如交换机PingMesh、高精度Telemetry)提供了底层基石 13。
在十万卡集群中,ECMP的哈希冲突问题会被指数级放大。为此,HPN架构部署了一套由多种先进技术构成的、层次化的拥塞治理“组合拳”。
解决方案 | 工作机制 | 粒度 | 硬件依赖性 | 报告性能增益 |
|---|---|---|---|---|
自适应路由 (AR) | 网卡对数据包进行哈希,喷洒到多条路径,在接收端重组 | 逐包(Per-Packet) | 需智能网卡支持 | 相比ECMP-8QP提升达20% 13 |
HPN控制器 | 集中控制器计算全局无拥塞路径,通过PBR下发策略 | 逐流/逐任务 | 无特殊硬件依赖 | 2%-5%(集群训练) 13 |
DDC | 将IP报文切片成固定大小的信元,在交换矩阵内实现完美负载均衡 | 信元(Per-Cell) | 需支持DDC的交换机硬件 | 相比ECMP 1:1提升达140% 13 |

图4:HPN网络零拥塞网络管理(引用自《百度AI网络的架构创新与优化之路》)
这套从端侧智能(AR)、到网络中枢(HPN控制器)、再到架构革新(DDC)的解决方案组合,构建了一个强大的、可灵活适应不同硬件和成本模型的“技术工具箱”。
除了宏观架构的演进,百度HPN的竞争力更在于一系列深刻影响网络运维效率、突破物理限制和深度适配AI负载的关键技术。
●极致可观测性:赋予网络“感知力”
○超高精度Telemetry:实现了交换机侧1秒级和端侧10毫秒级的监控数据采集精度,能够清晰捕捉到导致训练抖动的毫秒级网络微突发13。
○交换机PingMesh:将PingMesh能力从服务器移植到交换机硬件中,构建了一个覆盖全网、100%可信的实时质量监控矩阵,实现网络质量问题的“秒级感知、1分钟定位” 13。
●突破物理边界:构建“广域超算”
○跨AZ RDMA:通过网络层、框架层和物理层的全栈优化,成功实现了在100公里距离内进行跨机房RDMA训练,且性能达到单数据中心内部的96%以上 13。
○空芯光纤 (HCF):前瞻性地引入空芯光纤,利用其近乎真空光速的传播特性,可将信号传输延迟降低约30%,是实现高性能长距离RDMA的物理层关键技术 13。
●拥抱前沿算法:让网络“理解”AI
○MoE模型优化:针对MoE模型引入的大量All-to-All通信,HPN实施了“流量差异化管理”,将All-to-All流量调度到独立的、高优先级的硬件队列中,并进行深度参数调优 13。
○PD分离推理加速:针对LLM推理的Prefill-Decode分离场景,HPN能够为其规划出专用的、收敛比为1:1的无阻塞网络路径,确保推理服务的高吞吐和低延迟13。

图5:HPN控制器方案示意图(引用自《百度AI网络的架构创新与优化之路》)
截至2025年9月,大模型技术的发展仍在加速,持续对智算网络提出新的挑战与机遇。
●超节点 (Supernode) 的影响:通过NVLink/NVSwitch等技术将多GPU(如16、32甚至更多)紧密集成(Scale-Up)的“超节点”设计,如百度的“昆仑芯超节点”,能够将对延迟最敏感的张量并行通信完全内化在节点内部3。这极大地简化了外部网络(Scale-Out)的部署复杂性,并缓解了全局网络的压力。未来网络的设计需要与超节点的规模进行协同权衡,找到一个覆盖TP域大小的成本效益“甜点区” 3。
●空芯光纤 (HCF) 的普及:HCF技术的成熟和产业化,有望将HPN的覆盖范围从数据中心内部延伸至整个城市乃至区域,形成一个真正意义上的、地理分布式的大模型“超级计算机” 15。
●GPT-5时代的思考:从静态路由到动态智能 OpenAI于2025年8月发布的GPT-5,其架构描述中提到了一个“统一的自适应系统”和一个“实时路由器”,能够根据任务复杂性动态选择不同的模型进行处理。这预示着未来的AI工作负载可能不再是当前相对可预测的集合通信模式,而是更加动态、异构和不可预测的。 这种变化对现有网络架构提出了深刻挑战:
1.流量模式的不可预测性:如果AI任务的通信模式在运行时动态变化,那么基于预先计算路径的HPN控制器方案可能会失效。网络需要具备更强的实时感知和自适应调整能力。
2.服务质量(QoS)的极致要求:一个复杂的Agent任务可能同时包含需要极低延迟的推理步骤和需要高带宽的数据处理步骤。网络需要能够为同一个任务中的不同数据流提供差异化的、动态的QoS保障。 发展方向与制约:这可能推动智算网络向更高阶的**AIOps(AI for IT Operations)**演进,即利用AI来实时管理和优化AI网络。然而,其制约因素在于,实现这种毫秒级的、全网范围的智能调度,本身就需要巨大的计算和通信开销,并对控制器的设计提出了极高的要求。物理定律(如光速限制)和能耗墙依然是最终的制约因素。
通过对百度HPN演进历程的深度拆解,我们可以观察到其成功的核心在于四大设计原则:深度负载-网络协同设计、拥塞治理的组合策略、垂直整合驱动创新加速、以及视网络与框架为一体。
展望未来,智算网络将朝着更加智能、开放、广域的方向发展。以HPN控制器为核心的AIOps能力将赋予网络“自愈”能力;以DDC等开放标准为代表的技术将打破厂商锁定;而以空芯光纤为基础的广域互联,将为训练更大、更强的AI模型,持续构建和强化其“神经中枢”。
1.Mixture of Experts package - NVIDIA Docs, https://docs.nvidia.com/megatron-core/developer-guide/latest/api-guide/moe.html
2.Megatron-LM - Hugging Face, https://huggingface.co/docs/accelerate/usage_guides/megatron_lm
3.NVIDIA/Megatron-LM: Ongoing research training transformer models at scale - GitHub, https://github.com/NVIDIA/Megatron-LM
4.Efficient LLM Inference: Bandwidth, Compute, Synchronization, and Capacity are all you need - arXiv, https://arxiv.org/html/2507.14397v1
5.NVLink & NVSwitch: Fastest HPC Data Center Platform | NVIDIA, https://www.nvidia.com/en-us/data-center/nvlink/
6.From Data to Experts: Mapping AI Parallelism to Network Requirements - DriveNets, https://drivenets.com/blog/from-data-to-experts-mapping-ai-parallelism-to-network-requirements/
7.6. Efficient Training of Large Models - GenAI! - Read the Docs, https://jiegroup-genai.readthedocs-hosted.com/en/latest/resource/
8.Hardware Failures Won't Limit AI Scaling, https://epoch.ai/blog/hardware-failures-wont-limit-ai-scaling
9.NVIDIA H100 Benchmarks for Large-Scale Training | CoreWeave, https://www.coreweave.com/blog/nvidia-h100-gpu-benchmark-results-what-we-learned-from-large-scale-gpu-testing
10.Llama (language model) - Wikipedia, https://en.wikipedia.org/wiki/Llama_(language_model)
11.Timeline of AI and language models – Dr Alan D. Thompson - LifeArchitect.ai, https://lifearchitect.ai/timeline/
12.Large Language Models: Evolution, State of the Art in 2025, and Business Impact | Proffiz, https://proffiz.com/large-language-models-in-2025/
13.智算中心网络架构白皮书(百度智能云&度小满).pdf
14.Everything We Know About GPT-4 - Klu.ai, https://klu.ai/blog/gpt-4-llm
15.GPT-4 - OpenAI, https://openai.com/index/gpt-4-research/