简介：阿里云 HPN 7.0 架构技术分享文档，源自 AICon 2024 资深网络架构师席永青的现场演讲，面向 AI 基础设施、数据中心网络及大规模 GPU 集群研发和运维人员。内容系统剖析 GPU 集群对带宽、时延、连接数及稳定性的严苛要求，阐述网络架构从 CPU centric 到 GPU centric 的演进，并详解多轨+双平面拓扑、以 51.2T 交换芯片构建单层千卡/两层万卡集群、400G RoCEv2 RDMA、自研 HPCC 流控、ACCL 通信库，以及前端存储+VPC 网络与后端 GPU 互联网络的协同设计，给出集合通信和训练性能提升数据。同时涵盖端网融合、设备白盒化与 SONiC 开源生态，以及从 SDN 到计算定义网络的转型思路，帮助读者建立从底层硬件到调度运营的完整认知。压缩包内为 1 个 PDF，大小 5.76MB，图文结合，适合作为理解可预期网络与 AI 智算网络设计的核心参考。已有 101 人学习，适合希望掌握下一代高性能网络设计思路的工程师。 大模型训练跑得多了，你会发现一个特别诡异的现象：GPU 利用率时不时从 90% 断崖式跌到 20%，显卡监控全是绿的，日志里找不到任何报错，进度条就是卡着不动。排查到最后，问题往往出在网络——某条链路的一次微秒级拥塞抖动，让几千张卡的梯度同步屏障集体等待，整个集群都在给一条慢链路买单。这正是阿里云可预期网络 HPN 7.0 架构想彻底解决的根源性问题：大规模 AI 训练场景里，网络最怕的从来不是带宽不够，而是延迟不可预期。网络不再是"能通就行"的基础管道，而是直接决定 GPU 利用率、训练迭代耗时、甚至集群扩展上限的核心系统。
这篇文章我会从实际训练任务遇到的网络痛点出发，拆解传统数据中心网络在千卡万卡集群面前失效的根本原因，再把 HPN 7.0 的关键设计思路——拓扑、拥塞控制、负载均衡、故障收敛、端网协同——一层层讲清楚。不管是做 AI Infra、大模型训练平台，还是搞数据中心网络的读者，这里面提到的设计思路和踩坑经验，应该都能直接用得上。
1. 为什么大规模 AI 训练最怕"网络抖动"
1.1 同步并行逻辑下的木桶效应
先明确一个前提：现在主流的大模型训练，跑的是数据并行加 AllReduce 梯度同步。每一轮迭代，每张 GPU 算完自己的微批量数据，就要把梯度拿出来和其他卡做全局求和，等所有卡的梯度都聚合完成，权重更新完，才进入下一轮。
这个"全局同步屏障"就是问题的关键。它天然是一个木桶模型——整轮迭代的耗时，不取决于平均耗时，而取决于最慢的那一次梯度同步。哪怕全集群一万条链路里只有一条出现微小的拥塞抖动，拖慢了参与同步的一小撮流量，所有 GPU 都得停下来等它。我见过一次实际的训练任务，P99 时延从 100 微秒涨到 300 微秒，GPU 利用率直接从 85% 掉到 45%，整批任务吞吐几乎腰斩。这种放大效应，是传统网络设施在设计时完全不会考虑的。
所以可预期网络的第一诉求很明确：把网络时延的抖动压到极窄的区间。平均值再低都没用，P99、P999 才是决定训练效率的生死线。网络团队汇报"平均时延 50 微秒"没什么意义，训练平台团队更关心的是"99.9% 的情况下时延是否稳定在 100 微秒以内"。
1.2 AI 训练流量和 Web 流量的本质差异
很多人下意识觉得，网络优化嘛，不就是加带宽、减时延。但 AI 训练流量跟传统的 Web 流量、视频流量完全是两个物种。
- 方向性：Web 流量是"南北向"为主，客户端到服务器，流量模型散射状；AI 训练是"东西向"为主，服务器到服务器，而且是全集群的 All-to-All 通信。
- 流大小：Web 流量多数是小流，几 KB 到几十 KB；AI 训练里跑的是大象流，一个梯度同步就能产生几十 MB 甚至几 GB 的连续传输。
- 拥塞特征：Web 流量高峰是短时脉冲；训练流量是持续高水位，链路的平均利用率随便就能推到 90% 以上，根本没给网络留"喘息"的冗余。
- 敏感性：Web 页面多等 10 毫秒用户已经感知明显，训练流量对微秒级抖动都敏感——因为同步屏障会被瞬间放大。
这两种流量模型放在一张网上，用同一套转发策略，结果必然是灾难。传统网络设计目标是"尽力而为"，把报文送到就行；AI 训练网络的目标是"可预期"，不仅要送到，还要在确定的时间窗内送到。
2. 传统数据中心网络方案为什么带不动千卡集群
2.1 丢包与 PFC 带来的连锁灾难
传统 TCP/IP 网络最怕的是拥塞丢包。一旦队列满了，报文被丢弃，发送端要靠超时重传或者快速重传恢复。一次重传的代价是什么？在万卡集群里，一次尾部丢包可能导致整轮 AllReduce 等一个 RTT 甚至更多，放大到整个训练任务就是几百毫秒的停顿。
为了消除丢包，业界普遍引入了 PFC（优先级流控）机制，让交换机在队列快满时向上一跳发送暂停帧。PFC 确实把丢包变成了"无损网络"，但它引入了更隐蔽的问题：头阻塞（HOL blocking）。一条队列被暂停，可能堵住后面所有去往其他端口的流量；更严重的是，多个交换机之间的 PFC 暂停帧互相等待，可能形成环路死锁，整个子网吞吐瞬间归零。
我在实践中见过不止一次 PFC 风暴：明明链路带宽还有大量空闲，全网有效吞吐却掉到不足 10%；交换机上 PFC 计数疯狂跳动，但没有任何一条链路跑满。这种"网络看着没堵，实际已经瘫了"的现象，就是 PFC 流控副作用最典型的体现。
2.2 ECMP 哈希与大象流的随机碰撞
传统数据中心靠 ECMP（等价多路径）做负载均衡，核心是哈希——把报文的五元组哈希到某条等价链路上。哈希算法对大量均匀的小流效果不错，但碰到 AI 训练这种大象流就完全失控了。
原因在于，一条大象流的哈希结果基本是固定的，所有报文都会走同一条链路。如果两条大象流被哈希到同一条物理链路上，链路瞬间打满，而旁边的等价链路可能完全空闲。这种"冷热不均"是随机碰撞的结果，没有规律可循，也就无从优化。
后来业界有了一些改进思路，比如 Flowlet 切换——通过观察流的空闲间隔来动态调整路径。但传统交换机里的 Flowlet 实现是粗粒度的、局部的，每个交换机只根据自身看到的流量做决策，没有全局视野。在持续高负载的训练流量下，这种局部的"自适应"很快就退化成抖动式的路径漂移，性能反而不如不改。
2.3 传统架构缺乏全局视角
归根结底，传统数据中心网络的转发决策是"逐跳分布式"的。每个交换机只掌握自己的队列状态，看不到整条路径上的瓶颈在哪里，也不知道其他交换机面临的拥塞。一个拥塞点在某个角落形成，流量要绕很多跳甚至到端侧触发拥塞控制后才开始降速，这时候影响已经扩散了。
可预期网络要做的，恰恰是把这种"瞎子摸象"式的局部决策，升级为"上帝视角"的全局感知和全局调度。这就是 HPN 7.0 架构在设计理念上的根本转变——不是修修补补，而是从拓扑到转发、从拥塞控制到故障恢复，整条链路重新设计。
3. HPN 7.0 架构的关键设计拆解
3.1 拓扑简化：两层 CLOS 与高基数交换机的算账逻辑
HPN 7.0 在物理拓扑上做了一个大胆的减法：把传统三层 CLOS 架构压成两层，用高基数交换机替代大量低规格设备。
这里面的算账逻辑值得细说。传统三层拓扑每一层都引入一次转发时延和故障概率，而且跨 Pod 通信要经过三层交换，路径长度不可控。两层拓扑下，任何一个节点到另一个节点的跳数相对固定且更短，天然降低了时延抖动的产生点。
高基数交换机的作用则在于"横向扩展"的能力。单台交换机提供极高的端口密度和转发容量，让 Pod 内的东西向流量大部分在交换机内部完成交换，跨 Pod 流量则通过少量高端 Spine 交换机互联。拓扑层级少了，网络故障点少了，排障路径变短了，这是"可预期"的第一步。
我在评估这套架构的时候，最直观的感受是：网络团队终于不用再面对一张几百台设备、几千条链路、复杂到没人能说清全貌的拓扑图了。两层结构意味着每一条流经过的设备数量可数、路径可预期，这为后面的拥塞控制和快速故障收敛打好了物理基础。
3.2 GCN 全局拥塞通知：从逐跳感知到全局决策
HPN 7.0 最核心的技术创新之一，是 GCN（Global Congestion Notification，全局拥塞通知）机制。它解决的是传统 ECN（显式拥塞通知）最致命的缺陷——局部性。
传统 ECN 的工作原理是：交换机检测到队列接近拥塞，就在报文上打一个标记，接收端看到标记后通知发送端降速。问题在于，这个反馈是逐跳的，而且只在拥塞已经发生之后才生效，属于"事后补救"。
GCN 的做法是让网络具备全局拥塞视图。交换机把拥塞信息聚合上报到集中控制器或者通过带内机制广播，流量入口侧在拥塞尚未恶化之前就能感知到瓶颈位置。相当于给网络加了一个提前预警系统：不是等堵死了才开始疏导，而是刚看到车流变慢就引导后续车辆绕行。
这套机制的落地难度在于性能。万卡集群里的拥塞信息量是海量的，如果上报太频繁，控制通道本身就变成瓶颈；如果上报太稀疏，又失去了全局感知的时效性。HPN 7.0 的思路是分粒度处理：微突发拥塞靠交换机本地快速响应，持续拥塞则触发全局重路由。这个分级机制把"快"和"准"兼顾起来了。
3.3 Flowlet 级自适应路由：把大象流拆散
前面提到，传统 ECMP 哈希遇到大象流就抓瞎。HPN 7.0 在负载均衡上引入了更精细的 Flowlet 级自适应路由，核心思路是：不要试图用哈希一锤定音，而是动态观察流量特征，把一条大象流拆成多个 Flowlet，根据实时链路状态分散到不同路径上。
这里的关键参数是两个保护间隔：发送端在两条 Flowlet 之间至少间隔一个阈值（通常大于网络中最大时延差），接收端才能稳定区分不同 Flowlet，避免乱序重排带来的额外开销。HPN 7.0 在交换机侧基于数据包到达的 gap 检测和路径调度，不再依赖于端侧应用的配合。
实际跑下来，这种自适应路由最大的收益是链路利用率。传统哈希下，多路径的利用率方差可能达到 30% 以上，某条链路 100% 打满、旁边链路 60% 空闲的情况经常出现。Flowlet 级调度能让多路径利用率趋向均衡，把有效带宽挖掘出来。对训练任务来说，这直接换算成更短的迭代时间。
不过要泼一盆冷水：Flowlet 自适应路由对交换机芯片的转发能力要求很高，需要维护大量流的状态，做动态的路径选择，这比传统哈希转发复杂得多。这也是为什么 HPN 7.0 必须搭配自研或深度定制的高性能交换机——通用的商用芯片能力边界摆在那里。
3.4 快速故障收敛：毫秒级切换的工程极限
大规模集群里，链路故障和设备故障是常态，不是异常。一块光模块老化、一根光纤被误碰、一台交换机升级重启，都是训练期间大概率会碰到的事情。传统网络靠动态路由协议收敛，秒级甚至分钟级，对于训练任务来说等于任务中断。
HPN 7.0 的故障收敛策略是把故障检测和路径切换下沉到数据平面。链路断开、FEC 纠错超限、信号劣化这些物理层信号立刻触发硬件级切换，不需要等路由协议重新计算。配合两层拓扑的路径冗余设计，故障发生后流量在毫秒级切换到备用路径，对上层训练任务的影响被压缩到几乎透明。
这里还要提一个很容易被忽视的问题：训练通信库的超时参数。很多分布式训练框架默认的通信超时是 30 秒甚至更长，如果网络故障收敛时间在几十毫秒，训练根本不会感知到中断。但如果在传统架构下，网络收敛几十秒，超过了通信库超时阈值，整个训练任务就崩了。所以网络收敛速度的快慢，决定了上层训练框架能够容忍什么样的故障。
4. 架构之外：从网络工具到 AI Infra 系统思维
4.1 网络不再是"管道"，而是算力的一部分
HPN 7.0 这类可预期网络出现，背后是一个更深的行业变化：网络正在从"IT 基础设施"变成"算力基础设施的核心组件"。在 GPU 价格高企、算力供给紧张的背景下，网络性能直接决定了单位算力的产出效率。
算一笔简单的账：假设一个训练任务原本需要 30 天跑完，网络抖动导致 GPU 平均利用率只有 60%，实际耗时就是 50 天。如果可预期网络能把 GPU 利用率稳定拉到 90% 以上，同等硬件规模下，训练时间缩短近一半。这个价值远远超过网络设备本身的成本差异。所以看 HPN 7.0 不能只看网络指标，要把它放到 AI Infra 的整体 RO 里来评估。
从我接触的 AI Infra 团队来看，真正做得好的团队，任务调度器是感知网络拓扑的：知道哪些 GPU 在同一 Pod、哪些跨 Pod，把通信量大的 rank 尽量调度到拓扑邻近的位置，从源头降低跨网络通信的压力。网络优化不能只靠网络团队单打独斗，必须和上层训练框架协同设计。
4.2 可观测性是可预期网络的前提
"可预期"这三个字说起来容易，做起来的前提是你得能观测到所有影响预期的变量。HPN 7.0 配套的遥测体系需要盯紧几个关键指标：流的完成时间（FCT）、ECN/GCN 标记率、交换机队列深度、PFC 暂停帧计数、链路利用率方差、重传率。
我建议所有做训练平台的同学，把网络指标纳入训练任务的监控大盘，和 GPU 利用率、迭代耗时、通信耗时放在同一个面板。之前排查一个"诡异"性能问题，最后就靠流完成时间的分布图定位到一条光模块劣化的链路——这条链路平时能通，但纠错开销已经把有效带宽打了七折。没有细粒度的网络遥测数据，这种问题排查起来就是大海捞针。
可预期网络不只是网络设备的能力，更是一套完整的运营体系：从指标采集、数据聚合、阈值告警到自动定位，缺一环都不行。HPN 7.0 的架构设计从底层给这套运营体系提供了数据基础，但这层功能够不够深，还得看操盘团队积累的排障经验和样本库。
4.3 对 AI Infra 从业者的几点启发
聊了这么多 HPN 7.0 的技术细节，最后想跳出架构本身说几句对大模型训练工程化的思考。
- 系统设计要有全局视角：只看 GPU、只看网络、只看存储都是不够的，大模型训练是一个全链路系统，所有组件都在互相影响。HPN 7.0 的价值在于把一个传统上"被动响应"的组件变成了"主动设计"的组件。
- 稳定性压倒一切：训练场景不怕慢，就怕不稳定。一个抖动导致任务中断，重新拉起又要经历 checkpoint 加载、集群重新调度，这种隐性成本比表面上的性能损耗大得多。
- 软硬协同是关键：可预期网络往往需要端侧协议栈、通信库、交换机固件、管控系统一起配合才能发挥价值。指望换一台交换机就解决所有性能问题，是不现实的。
5. 落地实践中的真实挑战与经验备忘
5.1 运维复杂度并不会消失，而是转移了
HPN 7.0 把网络的转发逻辑变得更确定，但运维团队的技能栈要求反而更高了。GCN 的拥塞阈值怎么配、Flowlet 的间隔参数怎么调、故障切换策略怎么验证，这些都需要对网络和训练任务都有深入理解的工程师来把控，而不是照着厂商默认配置照抄。我自己踩过的坑是：某些监控工具默认采集周期太长，根本抓不到微秒级的拥塞脉冲，必须根据训练任务的实际流量模型来调整采样精度。
5.2 测试验证的思维方式要改变
传统网络上线前测的是打流吞吐、时延、丢包率这些基础指标。但可预期网络要验证的是"在真实训练负载下，P99 时延能否稳定"。我建议用真实的 AllReduce 通信模式做压测，模拟多任务并行、链路故障注入、背景流量干扰等场景，而不是只看空载或简单打流的结果。只有把故障注入和极端流量场景纳入常态化测试，网络的可预期性才是可信的。
作为长期和分布式训练基建打交道的人，我越来越认同一个判断：可预期网络是支撑下一代万卡甚至十万卡集群的必选项。HPN 7.0 的整套设计思路——拓扑简化、全局拥塞感知、智能负载均衡、毫秒级故障收敛——基本代表了行业对"AI 时代网络应该长什么样"的最新共识。它解决了传统网络在 AI 训练场景下的核心痛点，但更重要的是让更多人意识到，网络建设思维需要从"如何把带宽做大"转向"如何把行为做确定"。如果读到这里的你正在规划自己的 AI 算力集群，我建议把网络可预期性纳入第一优先级来考量，这个决策越早做，后面省的心力就越多。
本文还有配套的精品资源，点击获取
