为算力护航——腾讯星脉网络运营实践

1.前言

如果把传统数据中心网络看作高速公路，那么GPU网络就是拉力赛车专用赛道。这个专用赛道承载着成千上万个计算单元的通信流量，可以说在赛场上的每辆赛车都装载着原料，而赛道上出现的任何不利因素都会严重影响着生产，譬如路面不平导致原材料倾洒丢失就需要重新运输，道路拥塞会降低生产效率，道路中断导致生产过程中断。

为了使生产效率不受严重影响，除了在赛道建设过程中用质量更佳的材料提高良率外，还需要量身定制一套运营体系在减少意外导致的损失。本文将通过腾讯星脉网络运营体系中的两个系统来介绍腾讯在GPU网络领域的运营实践：a. 监控系统——GOM（Global Optimizid Monitoring）：全方位监控异常因素，使救援队能第一时间介入并恢复秩序，在星脉网络中实现监控100%链路覆盖，达到链路粒度百ms级状态跟踪，并联合排障系统进行秒级定位；b. 调度系统——GOR（Global Optimizid Routing）：为每辆拉力赛车提前规划线路减少路线冲突的可能，当出现路线冲突时参与仲裁对路线重新调整，使得网络拥塞秒级发现，1分钟内恢复，最终将集合通信带宽提升20%以上。

2.GPU网络的特性

● 丢包容忍度极低

AI训练使用的RDMA通信犹如高性能赛车，为了达到最高性能，自然希望每个模块都使用最先进的技术。但由于硬件资源不足等问题，用于保证可靠传输的丢包重传模块仅仅拿到老古董GBN算法。“廉颇老矣”的GBN算法在发现传输过程中出现丢包或超时，会简单地对过去一段时间发送的数据全部重新传输（无论重传的数据是否丢失），这会导致有效传输能力大幅下降。因此对于GPU网络集群来说，丢包已然属于一种故障。

图1 丢包重传示意图

● 流量拥塞风险大

传统网络就像城市里的柏油马路，许多车以相对较低的速度在路面上稳步前进。尽管每个链路上都会承担大量的流，但是单个流的流量都相对较小，而且流数量足很多，这样的链路相对均衡，不容易出现拥塞。而GPU网络更像一个赛车场，尽管流数量较少，但是每个流都相当大，如果出现轻微的不均，就很容易出现拥塞。

图2 流量拥塞示意图

● 故障冗余程度低

网络系统的设计一般会预留足够的冗余空间以承载突增流量或屏蔽故障，但是这些设计在RDMA通信面前如薄纸般容易被击穿。为了实现如前所述的无损传输等能力，单个节点涉及配置项数十条，整个集群只要其中某个节点配置出现问题就会对整体传输能力造成影响。再加上大模型训练中容易发生大流间的冲突，无法以简单的交换机缓存加以解决。最终，GPU网络的稳定性直接暴露在多种不利因素下，波动幅度大于传统数据中心网络。

图3 网络冗余示意图

● 单点故障爆炸范围广

AI训练每一轮迭代可以分为工匠打金子（计算）和赛车送金子（通信）的流程，赛车跑得慢了工匠也就只能干等着，金子产量就下降了。更大的问题在于所有工匠以同样节奏同样步调一起干活，一个工匠落后了，所有工匠都会停下来等着。这样的生产模式导致任意一辆跑车遇到故障走得慢了，都会拖慢整体生产效率。如果等待时间过久，大家就会终止手中的工作（任务中断），手头的半成品会作废，等下次重新开始工作时将重头来过（回溯记录点），导致更大的浪费。

图4 单点故障影响示意图

3.星脉网络监控系统—GOM（Global Optimizid Monitoring）

3.1.监控迎来新需求

挑战1：监控需要覆盖每个故障点

GPU网络中任何一条链路出现问题影响范围面广，而HPC多级网络集群链路数量达到10K+规模，端到端的多等价路径多达上百条，普通Fullmesh监控方式无法覆盖所有链路。发生在未被监控覆盖链路上的故障会使故障发现时长显著增加，定位难度也更大。

挑战2：秒级尺度不足以观察突发拥塞

大模型训练的流量模式为同步性更强、粒度更小的突发流。尺度更大的秒级、亚秒级监控已经无法满足对链路状态的测量需求。以链路吞吐指标为例，流量在一秒内产生多次持续时间为毫秒至数十毫秒的脉冲波动，在秒级尺度观察只能看到链路处于一个稳定的、毫无波动的低负载状态。这两种状态天差地别，在故障发现和定位的逻辑上也会得到不同的结果。

图5 带宽利用率在秒级（左）与毫秒级（右）统计粒度上的差异

3.2.星脉网络监控架构设计

网络故障是无法避免的，但是一套优秀的监控系统可以及时发现每一起事故，并通知交通管理员快速处理现场，以减少次生灾害的发生。此外，当道路出现拥堵时，该系统还可以发出预警信息，让调度员及时介入并做出响应。然而，传统的网络质量监控系统（如Pingmesh等）应对这些新挑战时显得有心无力。

针对GPU网络存在高事故率和次生灾害影响大的特点，我们设计了一套新的监控系统。该系统在原有Pingmesh类系统的基础上对探测流密度、探测频率、信息密度等方面改进，通过启发式生成主动探测流量，实现对星脉网络的100%监控覆盖，并利用探测流的交叉覆盖来实现动态高频率的质量指标采样。该监控系统主要包含以下模块：

● 无影灯控制器：集中式的探测流控制器负责维护集群网络完整拓扑、探测流覆盖的实时拓扑，根据对账结果决定探测流的生成和销毁。

● 高效数据平面：终端和汇聚平台分阶段将大量低频的信息密度极低的数据进行压缩，用以支撑巨量链路级别的数据存储，支持对关键集群提供重点保障的监控能力。

● 事件分析模块：分析平台用于将异常事件筛选过滤、多事件关联分析、故障模式匹配等功能。

图6 星脉网络监控系统架构

3.2.1.无影灯控制器：100%链路覆盖

图7 链路监控率统计

无影控制器用于控制生成INT探测流，每一个探测流将对应一条网络路径，这样使探测流集合所经过路径能够覆盖GPU网络的全部链路，控制器持续监控网络变更状态并实时更新探测流数量。大型GPU网络的链路规模可以轻松上万，采用随机探测的方式想要实现监控流量无死角覆盖难过中彩票，一个4K GPU卡规模的计算集群使用随机或者full-mesh方式探测需要则大概需要超过160K个不同的探测流。但是对于控制器来说这并非是一个抓瞎开图的游戏，每次生成新的探测流量都可以借助 INT（带内遥测）工具来识别出探测流量经过的网络节点，就像GPS一样绘制出每块区域的精确坐标，这些新的探测流可以在点亮地图的一处，借助之前探索的信息每一次新的尝试都可以将可能往黑暗的地方探索。在经历多次迭代收敛后，探测流将实现对集群中所有链路的全方位监控。另一方面，监控流量与业务流量在时间的分布上可能并不一致，通过近源端口对流量采样并拷贝的方式生成随路探测流量，在相同的时间空间上对刺探网络质量，业务流量将得到更有针对性的保驾护航。

3.2.2.高效数据平面：高采样率，高压缩率

与传统网络的流量模式不同，大模型训练的流量模式为同步性更强、粒度更小的突发流。尺度更大的秒级、亚秒级监控已经无法满足对链路状态的测量需求。以链路吞吐指标为例，流量在一秒内产生多次持续时间为毫秒至数十毫秒的脉冲波动，在秒级尺度观察只能看到链路处于一个稳定的、毫无波动的低负载状态。这两种状态天差地别，在故障发现和定位的逻辑上也会得到不同的结果。为了呈现链路的高频变化，数据平面支持动态调整采样频率，在执行业务重保时可以达到每秒百次的采样频率。

图8 业务流量的突发模式：毫秒级突发与同步突发

稳定的、低频变化的数据蕴含的实际价值较少，这些数据在压缩中往往又能达到极高的压缩比率，分析平台在执行数据存储前会根据指标特征将数据压缩后存储，压缩率可以达到1%。另一方面，运营中通常关注质量指标的最值和波动范围，据此特性数据平面将采样到的数据按照最值进行聚合然后上报，将一段时间窗口内的数据量压缩至固定大小，进一步减轻了数据上报和存储的压力。

图9 链路拥塞比率：超99.9%采样点无拥塞

3.2.3.事件分析模块

根据网络运营经验，质量波动事件会被分为显性异常以及隐性异常，依照异常类型赋予事件不同的等级。显性异常指的是网络指标有明确的预期内的安全范围，当指标超出约束的安全范围则必然会影响网络通信质量，就如同要求严格的机场跑道中出现一个大坑，属于不合预期的安全事故，需要尽快介入并恢复。在GPU网络中，显性异常主要指的是链路出现丢包的场景，出现频率低但影响大。而隐性异常指的是质量指标没有明确的异常区间，但其波动范围明显超出均值，出现频率较高，需要联合业务系统的异常指标进行判断影响面。

图10 链路中断视图

图11 链路拥塞视图

集群日常的维护行为如网络变更、隔离，或者服务器维护等操作都有可能引起质量指标的波动，这些波动并不希望被运营人员看见。而非网络类故障如服务器自身异常或操作系统异常等事件也不应以网络异常事件上报。这些异常可通过运维系统配置白名单以及模式识别策略的方式进行过滤。

当出现多节点、多链路的质量指标波动时，运营人员介入后往往观察到多个告警链路然后陷入迷茫。就如同多条个交通路口同时出现堵塞时，需要分辨这些堵塞是各自单独的事件还是因为拥堵传导或是流量都涌向某个特定位置导致的。分析器需要搜集所有的异常信号，分析其中的传导关系以及路径等价关系，然后将多个信号打包抽象成特定的拥塞模式上报。

3.3.最佳实践：端网监控联合实现故障定位

星脉网络监控系统为高性能计算集群运行增添重要保障，却仅仅是整个运营体系中的一小部分。当监控发现网络出现异常时，还需结合多个平台对异常点定位、业务受损确认、流量重调度等。

图12 GPU网络质量监控效果

3.3.1.联合业务流监控技术进行异常分析

网络监控负责交换集群的质量监控，监测结果反映网络的行为表现。对于网络运营来说，业务性能是否受到网络事件影响更加重要。譬如，由于业务的All-to-All流量模式导致服务器链路拥塞无法从网络侧恢复措施中受益（业务流量模式特征导致），而大象流在交换核心中因路径冲突导致的拥塞则可以尽可能避免（负载不均衡导致）。同样对于拥塞，上述两种情况呈现出不同的严重等级。所以，网络的质量异常往往还需要结合业务方的质量监控来确认异常的影响范围、影响程度，然后再定量地对施害流和受害流采取恢复措施。

针对AI训练的关键业务场景，通过对业务流量进行QP粒度监控可以快速、精准地判断业务流量是否符合预期。通过业务流路径识别，将业务流与具体网络链路关联，随后根据业务流健康状态赋予网络拥塞不同等级。由业务触发的拥塞告警为运营人员筛选出有效的异常事件，提高运营效率。

图13 业务流状态联合分析

3.3.2.联合业务故障信息进行故障定界

网络监控对业务的故障定界提供了关键参考，网络因素导致业务中断只占中断原因的一部分。通过计算中断业务的流量热点，并回溯热点链路的网络质量指标，输出故障汇总信息以帮助分析定位。假如业务的关联链路未呈现异常，那么故障更有可能是由其他非网络组件导致的，如服务器或上层应用内部错误等。

图14 业务故障自动定界

4.星脉网络的“领航员”—GOR（Global Optimized Routing）

网络上的流就像拉力赛车一样在GPU网络的赛道上飞奔，为了尽快完成训练任务，我们自然希望所有的赛车都能开足马力，全速前进。但是由于赛道宽度有限，如果出现一条赛道上有多辆赛车的情况，其上的赛车就不得不降低速度来避免发生事故。这对于GPU网络也是一样的，如果一条链路上有过多的流，这些流的流量很可能在短时间内超过链路总带宽，这时这些流就会降速，拖慢训练进程。为了避免这样的情况，拉力赛的参赛者需要和领航员同行，共同规划线路，发现风险，应对突发情况。而在腾讯的GPU网络中，我们也有控制和调度流量，避免流量冲突的“领航员”，这就全局优化路由（Global Optimized Routing，GOR），它会对星脉网络中的流量进行指引以避免发生拥塞。在赛场上，领航员要和车手商量好赛程，提前避免危险。而在赛车发动之后，领航员也要打起十二分精神，严格监控赛场情况，一旦发现异常，比如赛道上出现了赛车拥堵，领航员要能实时给出应对方案，避开拥塞。类似的，星脉运营也要有流量规划调整和拥塞监控的能力。前面的网络监控系统可以实现监控能力，因此GOR的主要任务就是实现流量规划调整能力。一方面在任务开始前对流量进行一定规划，避免一些显而易见的拥塞。另一方面则要在运行过程中实时进行监控网络状态，对拥塞做出反应，实现拥塞避免。

4.1.流量计划

拉力赛场往往相当开阔，有多条不同路线都能到达目的地，参赛者可以自行决定行驶路线。这种情况下行驶路线的策划就显得相当重要，赛手和领航员需要共同商定合理的行程，以避免遇到不好的路况。这和GPU网络是类似的，如果没有领航员协助规划，就只能任由流量随机选择路径，这样难免出现流量冲突和拥塞。作为GPU网络的领航员，GOR也会对流量进行规划以保证常规情况下流量不出现拥塞。这样的规划体现在两个方面。一方面，我们基于网络拓扑特性对节点通信进行规划，让流的“赛程”尽可能短，避免网络中同时出现大量的流。另一方面，我们也为不同的流规划不同的“赛道”，让这些流尽可能不发生冲突，以此来保证所有流都能够全速运行。

4.1.1通信规划，减少网络流量

拉力赛上不同的路线有不同的地形，领航员可以根据赛车手的能力选择合适的路线。在GPU网络中也有类似的情况，GPU网络架构可以简化地看作是一个clos网络，不同服务器进行通信时，流经过的跳数也是不同的，例如如果源目的服务器在相同的leaf组，也就是block内，那么此时流的跳数就比较少，只有2跳，而如果源目的服务器分布在不同的block，流量就会经过LEAF-SPINE-LEAF才能到目的服务器，需要4跳，如果大量流量到达了SPINE层，就会导致拥塞的可能性大大增加，这是训练任务中需要尽力避免的。

对多数赛车手而言，简单地形的线路总是好开的。因此对赛车的领航员来说，在同样可以完成比赛的前提下，选择最简单的路线可以获得更好的成绩。如下图所示，如果选择有复杂地形的路径，那无疑会影响赛车成绩，相比之下，选择全是简单地形的路径往往可以取得更好的成绩。换句话说领航员选择的路径应该具有亲和性，更适合赛车手的能力。这对于GOR这位GPU网络的领航员也是一样的，在完成训练任务要求的前提下，应该找出最亲和的通信方式。为了实现这一点，我们结合网络特征，实现了拓扑亲和性的特性。正如前面所说的，同一节点到其他不同节点需要的跳数是不同的，跳数越少我们就认为这两个节点越亲和，它们之间的通信约不容易遇到拥塞。而对于一个训练任务，如果我们尽可能让亲和的节点进行通信，就越容易得到好的训练效果，原生通信库没有网络拓扑信息因此无法进行亲和性优化，而GOR则可以基于网络拓扑对节点通信顺序进行编排，实现更佳的亲和性。统计结果显示，相比于原生NCCL通信库的通信顺序，使用拓扑亲和性后，SPINE层流量可以减少至多90%，大大减轻了链路负载，降低了拥塞出现的概率。

图15 亲和路径选择

4.1.2.路径规划，减少冲突可能

对于星脉网络领航系统，不仅要安排好“赛车”的赛程，更要对它们的路径进行合理规划，尽可能避免冲突的发生。GPU网络提供了远高于常规网络的广阔赛道来满足赛车行驶的需要。但其实现方式并不是拓宽单条赛道的宽度，而是将多条赛道拼合成一条，当流到达交换机时，会从多个可选路径中选出一个，如果多个流选择相同的链路，仍可能出现拥塞。网络中的交换机往往使用ECMP的哈希算法作为指导流量选路的“信号灯”，指示每个到达的流的路径选择，以期望将流量均匀地分配到每条链路上。但是对于GPU网络场景，其中的流往往大而少，在这种情况下，哈希算法仍可能出现不均和拥塞。为了避免这样的赛道拥挤，出现“塞车”的情况，我们一方面对通信顺序进行规划，让绝大多数流量都不进入上层网络。另一方面，利用ECMP哈希算法的特征，我们可以对流的源端口号进行规划，从而保证一对设备间的所有流量选择完全不同的链路，实现端侧均衡。

同时，尽管我们已经通过流量规划极大减少了冲突的可能，但在大规模网络中，流量冲突仍是可能发生的，因此我们需要进一步优化路径规划的能力。为了更好地控制流量的路径，我们不仅需要知道流量的“相对路径”，也需要对“绝对路径”加以掌握，这样才能在多用户以及all2all的场景下实现精准调度。GOR控制器整合了交换机哈希的模拟器功能，使我们可以精确地获取流的路径进而实现更准确的规划。如下图所示，在建立链路时，GOR可以根据建流信息，结合实时拓扑，发现网络中潜在的流量冲突，对这样的流提前进行规划，避免流量冲突，从而实现动态路径规划。

图16 路径规划示意图

4.2.流量调度

就像赛场上总的情况总是难以捉摸，经常发生预料之外的情况，尽管我们对流量进行了规划，尽可能地避免流量冲突，但很多时候流量冲突仍是难以避免的。一方面，在多用户场景下，不同用户互不知晓彼此的存在，各自进行流量规划，那么他们的流量难免会出现冲突。另一方面，对于GPU网络这样存在成百上千交换机级别的大规模网络，我们很难保证其中所有的链路始终保持正常，一旦有链路故障，“赛场”就会发生变化，拓扑变化会导致ECMP选路结果变化，初始的规划就会失效。因此GOR不仅要在赛前进行规划，还要在赛程中实时监控路况并发现拥塞并进行处理。一个直接的发现拥塞思路是观察链路的负载，如果链路负载高就说明链路拥塞。但在GPU网络中这样的现象很难观察到，因为实际业务中的训练流量具有非常明显的突发性，链路负载过高导致拥塞可能一次只会维持数十到数百毫秒，而我们常用的监控手段，如SNMP等方法一般也只能实现秒级监控，从这个统计粒度来看平均流量始终远低于链路贷款。这说明传统的监控手段很难准确定位GPU网络中的拥塞，我们需要更准确的手段，而星脉网络监控系统可以满足这一需求。得益于星脉网络监控系统提供的高频精确网络指标，我们可以精准地获取到网络中有哪些链路发生了拥塞，以及拥塞链路上的流信息。这时GOR就会承担“交通警察”的职责，找出当前最空闲的链路，在交换机上加载新的规则，把拥塞链路上的流量引导到空闲链路上，这样就消除了拥塞。下图是我们在现网上对一条拥塞链路的进行调度的效果，图中的链路有200Gbps带宽，我们从流量统计图中可以看出，调度前流量峰值约为120Gbps，仅有链路带宽的60%。但如果切换到ECN视角，可以看出该链路每秒有上千的ECN报文，流量会发生降速，可以说拥塞相当明显了。而在我们调度后，链路带宽下降到20Gbps，同时ECN数量也迅速归零。可见，我们的流量调度能力可以立竿见影地消除网络中的拥塞。

图17 拥塞调度效果示意图

4.3.现网实践

4.3.1.流量规划优化allreduce性能

Allreduce是大模型训练进行时最常用的通信操作之一，其特征在于单流较大且流数较少。这种情况下最容易出现的问题在于端侧bonding口流量不均，导致一张网卡的两个网口中一个较为空闲，浪费了网络带宽，而流量规划可以很好地解决该问题。下图是现网中使用流量规划前后的网络性能对比，可以看到，除了业务不常用的极小消息大小（8M及以下），网络性能相比不使用流量规划有了明显的提升，提升约为20%。可见流量规划对于提升allreduce性能有相当的帮助。

图18 流量规划优化效果

4.3.2.流量调度优化all2all性能

随着大模型的发展，诸如GPT4等新大模型在allreduce的基础上还会使用all2all通信。和allreduce不同，参与all2all的网卡彼此都有通信，因此会有相当数量的流，单凭流量规划不足以保证网络不拥塞，这时我们就要进行调度，将拥塞链路上的流量调度到空闲链路上，下图是我们在现网上进行all2all测试的结果，可以看到开启调度对于性能有明显的提升，幅度超过20%。

图19 流量调度优化效果

和流量规划不同，流量调度是一种被动的操作，也就是说要先等拥塞出现才能进行操作，进而消除拥塞。因此流量调度的反应速度也是一个需要考虑的问题，为此我们在一个现网模块进行了为期半月的实验，测试其中网络拥塞的持续时间，结果如下图所示。可见随着调度的启用，集群拥塞时间迅速降低，幅度超过80%，说明调度可以快速减轻网络中的拥塞。

图20 调度减少网络拥塞时长