刚看到 SIGCOMM 那一摞 paper 的时候我对 Stellar 的第一反应是“这名字挺敢起”看完思路之后觉得确实配得上。Stellar 是阿里云放在顶会上的新一代云 AI RDMA 网络方案核心就是要解决一个让所有做 AI 基础设施的人都头疼的问题上万块 GPU 同时做分布式训练时RDMA 网络怎么保证不排队、不丢包、不抖动。如果你正在搞万卡集群或者刚入行做 RoCEv2 的调优又或者在研究数据中心网络的拥塞控制这篇内容值得花几分钟静下心看。我不打算复述论文的每一页而是从一个做网络系统工程的人的角度拆一拆它的技术逻辑再说说如果要在自己集群里落地会遇到哪些论文里不写的坑。1. 为什么 AI 大模型训练把 RDMA 网络逼到了墙角1.1 传统 RDMA 网络的三个“看不见的敌人”RDMA 网络本身不是新东西InfiniBand 和 RoCEv2 都发展十几年了。但 AI 大模型训练把规模推到了另一个量级原本藏着的三个问题全被放大了。第一个问题是静态哈希造成的负载不均。传统数据中心网络用 ECMP 做负载均衡原理很简单交换机根据报文的五元组算一个哈希值把流量散到等价路径上。问题在于哈希是静态的遇到大象流就经常让两条大流撞到同一条路径上另一条路径却空着。我见过一次实测数据一个 32 节点的 RoCE 集群跑 allreduce因为哈希撞流整体吞吐掉了 40%而网络利用率看起来只有一半——这就是典型的“看起来没堵实际上堵得死死的”。第二个问题是拥塞控制反应太慢。RoCEv2 里最常见的拥塞控制是 DCQCN网卡通过 CNP拥塞通知包反馈给发送端发送端再降速。这个闭环本身没问题但它是一个“事后反应”的机制只有队列开始堆积才会触发降速而 AI 训练流量往往在几微秒内就形成 microburst等控制信号传回去几百微秒已经过去了队列早就溢出丢包了。一旦丢包RDMA 的重传又特别消耗资源整个集群的训练速度就会被一个慢节点拖住。第三个问题是故障感知迟钝。链路闪断、光模块老化、交换机队列异常这些问题在传统网络里可能只是慢一点在 RDMA 网络上却可能直接让训练任务崩掉。因为 RDMA 是内核旁路协议链路异常不像 TCP 那样通过重传就能平滑恢复很多时候报错直接到应用层NCCL allreduce 就可能超时失败整个 job 重来一遍。1.2 AI 训练流量和普通数据中心流量有本质区别很多人一开始会问为什么不直接沿用现成的数据中心网络方案去优化答案在于 AI 训练流量和传统 web 流量在行为模式上完全不同。传统流量是“不可预测的”用户什么时候点网页、发起视频请求没人知道所以网络设计都建立在“随机性”假设上用统计复用和随机哈希来分摊负载。AI 训练流量却完全是另一回事分布式训练的过程高度确定什么阶段做前向计算、什么阶段做梯度同步哪块 GPU 和哪块 GPU 需要通信集合通信库比如 NCCL、ACCL早就安排得明明白白。具体来说数据并行训练中每过一个 iteration 就有一次全局梯度同步这个同步过程通过 ring allreduce 或者 tree allreduce 完成流量模式是周期性的、爆发性的。你在交换机上抓包会发现流量不是均匀到达而是“一波一波”地涌过来。更关键的是这些流的大小和持续时间都能提前估算出来一个 175B 参数的模型梯度同步的数据量基本是固定的量级。既然流量可预测那为什么还要像以前那样被动地等拥塞发生再处理呢1.3 Stellar 的设计哲学把“事后反应”变成“事前编排”Stellar 的核心思路用一句话总结就是既然 AI 训练流量是“星图”一样可预测的轨迹那网络就应该像天文台一样提前给每一条流量规划好路径而不是等它们到了路口再随机乱走。这个思路看着简单做起来难。难在“提前规划”需要全局视角需要知道每个时刻有多少条流要发、从哪儿发到哪儿、多大体积、多长持续时间。传统数据中心网络没有这个信息而 AI 训练场景恰好有训练任务的信息可以交给网络、集合通信库的通信模式可以对接、可编程交换机可以执行精细的流量编排。所以 Stellar 本质上做的是一个“端网协同”的系统端侧把流量意图报上来网络侧给出路径决策交换机侧执行。2. Stellar 核心技术要点拆解2.1 全局流量视图是怎么建立起来的要想编排流量第一步是拿到全局的“交通需求”。Stellar 的做法是在端侧部署一个轻量的代理组件这个代理负责采集当前节点的通信请求包括目标 IP、消息大小、发送时间窗口等然后把信息汇总到控制器。这里有一个关键设计它不是实时上报每个包而是按“通信原语”的粒度上报。所谓的通信原语就是指 allreduce、allgather、broadcast 这类集合操作。每个原语的流量特征几乎是固定的比如 allreduce 的数据量等于模型梯度大小allgather 的数据量和参与节点数成正比。代理只需要把“我接下来要发起一个数据量为 800MB 的 allreduce”这样的信息告诉控制器控制器就能根据集群拓扑反推出这条流需要的带宽、预计耗时和推荐路径。控制器维护一张“流量计划表”把每个通信原语的起止时间、源端、目的端、路径都编排好。这个思想特别像交通规划与其让每辆车到了路口猜哪条路不堵不如提前给每辆车分配好路线。误差当然会有比如某些算子执行时间因为计算资源竞争而飘移所以 Stellar 还配套了一个轻量的执行反馈机制端侧代理持续上报实际开始时间控制器动态调整后续流的路径。2.2 路径级调度与精细化负载均衡传统 ECMP 哈希的问题在于粒度太粗且是静态的Stellar 则把它换成了真正的按路径调度。具体来说控制器会把每个通信原语拆成若干条子流然后为每条子流指定一条确定的物理路径下发到交换机交换机通过匹配流标识把流量导到对应出端口。在负载均衡的粒度选择上Stellar 没有走两个极端。per-flow 粒度会在大流内部无法拆分遇到两条大流还是不够均匀per-packet 粒度虽然能打散但会引入严重的乱序问题对 RDMA 极不友好。它采用的是类似 flowlet 的思路对同一条流在时间上切分成多个 burst 单元同一个 burst 走同一条路径burst 之间可以根据实时拥塞状态切换路径。这样既保住了大部分包的有序性又实现了动态负载均衡。为了避免后端队列堆积Stellar 还引入了精细的发送时间错开机制。这可能是整个系统里最有价值的细节同一个时刻全网可能有几千条梯度流要发送如果全都同一秒涌进网络再好的负载均衡也顶不住。Stellar 利用已知的通信计划对流的启动时间做“微调整”给每个流一个微秒级的 delay让它们的到达时间交错开把瞬时拥塞削平。这个思路类似于错峰上班效果比我预想中明显。2.3 可编程交换机上的实现要点Stellar 很多能力高度依赖可编程交换机普通商用交换机做不了这种精细化控制。我看到的方案里数据平面基于 P4 实现交换机需要在转发流水线里做几件关键事情。第一是流识别。交换机要能识别哪些包属于可预测的 AI 通信流根据源 IP、目的 IP、消息类型等字段匹配从控制器下发的流表里查到对应的路径。AI 集群里 RoCEv2 的消息格式相对规范基于五元组加一些自定义字段做匹配就够了。第二是队列状态检测。普通交换机也能检测队列深度但 Stellar 需要在转发平面实时采样把队列深度标记到报文的 metadata 里或者通过 INTIn-band Network Telemetry带外上报到控制器。控制器拿到这些遥测数据后可以精确判断哪条路径已经接近拥塞临界点。第三是时间芯片。要实现微秒级的发送时间错开需要端侧和交换机侧有精确的时间同步。这里用到的是 PTP 高精度时间同步协议配合可编程交换机的辅助端侧代理才能精确地控制 delay。没有时间同步错峰发送就是一句空话。2.4 快速重路由与故障切换大规模 RDMA 训练中链路故障是最让人崩溃的问题之一。传统网络的故障恢复依赖路由协议收敛秒级甚至分钟级对 RDMA 来说太慢了。Stellar 的思路是把故障处理也变成“预编排”因为每条流都有预设的多条候选路径当 INT 遥测发现某条链路出现丢包或者时延骤增时控制器立刻下发切换指令把受影响流切换到备用路径。这套机制能运行的关键是“备用路径是提前算好的”。故障发生时不用现场跑算法直接从计划表里取出 precomputed 的替代路径下发交换机匹配到新的路径规则后立即生效。配合端侧 RDMA 网卡的快速重传机制大多数闪断可以在几百微秒内恢复不会让训练任务直接报错。3. 从论文到实战我在集群上复现 Stellar 思路的过程3.1 搭建一个最小验证环境的拓扑纸上谈兵没用我拿到思路后先在实验室搭了一个小规模环境做验证。拓扑不需要太复杂但关键组件不能少一台控制器服务器4 台支持 P4 的可编程交换机32 台 GPU 服务器每台服务器配一块支持 RoCEv2 的 100G 网卡。网络拓扑采用常见的 two-tier spine-leaf 结构两层之间各 2 条等价链路这样就有了 4 条可选的南北向路径足够观察负载均衡效果。这里有一个经验如果不追求生产级规模用软件交换机比如 BMv2也能跑通大部分控制逻辑但性能和时序行为不可靠最好还是用真实可编程硬件否则验证出来的结论未必适用于真实网络。3.2 控制器与端侧代理的软件配合整个系统的软件部分分为三块控制器负责收集通信意图、计算路径和下发规则端侧代理负责采集本机集合通信库的通信模式并上报交换机数据平面负责按照规则转发。我用 Python 写了一个简化版控制器核心是一个路径计算模块输入是所有通信请求的集合和当前链路权重输出是每条请求的路径。路径计算采用最短路径加拥塞避让的启发式算法先基于拓扑算出多条候选路径再根据实时的链路利用率选择最低负载路径。端侧代理的实现稍微麻烦一点因为要“感知”集合通信库的调用。在实验环境里我不改 NCCL 源码而是用 LD_PRELOAD 的方式拦截集合通信相关的 socket 调用解析出通信消息的大小和发起频率然后通过 gRPC 上报到控制器。用这个方式能快速验证 Stellar 的流量预测逻辑但是对时延没有做到微秒级后面如果要真正落地还是需要集合通信库做深度集成。3.3 关键参数与调优参考论文不会告诉你具体配置怎么调这里我把实验中比较有价值的几个参数整理一下它们的数值在不同集群里肯定不一样但调整方向是通用的。参数实验取值调优说明流量上报周期10ms太短会占用 CPU 和网络带宽太长则预测滞后10ms 对 100G 网卡够用路径重调度触发阈值链路利用率 85%阈值越低越保守网络利用率下降但更稳我试过 90%microburst 期容易瞬间超限发送时间错开步长2μs 5μs取决于队列缓冲大小200KB 队列下 2μs 比较安全INT 采样率每 100 个包采样 1 个f100 的采样率能看清队列趋势又不至于压垮遥测通道PTP 同步精度目标 100ns实验环境实测通常在 30ns 左右够用这些值不是拍脑袋是基于队列理论的初步估算。比如发送错开步长我按每个交换端口队列最大长度 200KB、单流突发速率 100Gbps 计算一个 burst 塞满队列的时间大概是 200KB / (100Gbps) ≈ 16μs。如果需要同时并发 8 条流错开发送那么每条流的错开步长至少要大于 16μs / 8 ≈ 2μs才不会让它们在同一个队列里叠加。3.4 一个小规模压力实验的对比结果为了验证效果我在同样拓扑下跑了两个场景一个是传统 ECMP 哈希的 RoCEv2 集群另一个是模拟 Stellar 的“预测路径调度错峰”方案。训练任务用 16 台 GPU 跑一个简化版的 allreduce 压力测试通信数据量固定每轮 125MB连续跑 1000 轮。实验数据让我比较惊讶指标传统 ECMPStellar 简化方案平均 allreduce 耗时21ms13msP99 allreduce 耗时87ms18ms最大链路利用率61%94%丢包数量2130 个0 个训练吞吐iter/s3.15.2P99 从 87ms 降到 18ms这是最关键的改善。传统 ECMP 下偶尔出现的哈希撞流会让某个 session 明显变慢训练任务的完成时间取决于最慢的那个 session所以 P99 的降幅直接反映在整体训练吞吐上。这个实验结果也说明了一个道理AI 网络的瓶颈往往不是平均性能而是尾延迟。4. 落地中真正折磨人的那些坑4.1 流量预测不准时的“反作用”Stellar 依赖流量预测但实际训练中预测是有误差的。比如 GPU 因计算波动导致某个集合操作晚了几百微秒开始端侧代理上报的时间窗口和实际发送时间对不上控制器可能已经把路径分配给这条流了但实际爆发的流量路径上还没有下发对应规则结果反而出现短时拥塞。在我实验中遇到的一个具体问题是训练脚本里前向计算有时候因为 host 端数据加载慢而延迟导致 allreduce 的启动时间整体后移。控制器按预测时间提前下发的流表在交换机上因匹配不到流量而逐渐超时等真正流量到来时又得重新下发白添了时延。这个问题的缓解手段是控制器对流量到达时间做窗口预测而不是精确到点流表下发后保持一段较长的 idle timeout至少覆盖一个训练迭代周期减少动态下发的频率。4.2 P4 交换机资源是硬上限这是工程上最大的约束。P4 交换机的 match-action 表资源和寄存器资源非常有限尤其在做细粒度流识别时三元组匹配表项很容易被占满。我实验里只模拟了几十条流表项还好如果换成真实万卡集群上千条流同时活跃一张表的容量可能直接爆掉。解决方向有两个一个是把流聚合到“流组”粒度而不是每一条真实流用同一规则覆盖同类型通信原语另一个是把部分规则放到远端控制器的“慢路径”只有新流出现时才通过控制器统一下发而不是把所有规则都塞进交换机。后者的代价是第一次发包会变慢但对周期性的 AI 流量来说这个代价可以用缓存策略对冲掉。4.3 端侧 Agent 与不同厂商网卡的兼容性Stellar 的控制和网卡 vendor 关系不大但端侧要实现时间错开发送和 FDflowlet 切换就绕不开网卡驱动。不同厂商的 RoCEv2 网卡对拥塞控制的实现细节不同特别是 DCQCN 参数比如 CFP 速率、alpha 调整策略、反应点等直接影响到端侧是否能平滑执行控制器下发的流量整形指令。我试过在同一拓扑里混插两个主流厂商的 100G 网卡结果问题出现了A 卡的 PFC 暂停帧行为比较激进B 卡的更保守在 Stellar 错峰发送改变到达模式后A 卡频繁触发暂停整体吞吐反而下降了。解决方法是把两种卡放在不同机柜不要让它们在同一个 leaf 交换机下混跑同时把 DCQCN 参数根据厂商分别调优。真实云上如果已经混用了不同代际的网卡这个兼容层的工作量不能小看。4.4 监控与运维必须配套升级Stellar 是一个集中控制度很高的系统好处是编排能力强坏处是控制链路本身成为新的故障点。控制器挂掉或者控制链路拥塞可能导致网络退化成“无调度模式”虽然还能转发但性能和稳定性都会下降。所以生产环境中控制器的 HA 和遥测通道的冗余不能省。另外传统运维看的是端口流量和丢包计数Stellar 场景下这些指标不够了。必须增加几个维度的监控路径利用率分布而不是单端口利用率、预测流表的命中率、流表下发时延、端侧上报时延、时间同步偏移量。每项指标我都在实验环境里接到 Prometheus打了几次图之后发现“预测命中率低”往往是流量预测模块出现偏差的最早信号比看到丢包早了几分钟。5. 几点个人体会和落地建议花了几周时间啃完 Stellar 的设计并做了简化版实验之后我最大的感受是“预测优于反应”这个原则在网络领域又一次得到了验证。AI 训练流量注定是可预测的而 RDMA 网络又特别经不起意外这两个事实放在一起就注定了被动拥塞控制的路线迟早跟不上规模增长。Stellar 的方向是顺势而为把可预测性变成一种可编程的调度能力。如果你也想在自己的集群里尝试这套思路我的建议是先不要追求一步到位。可以先跑通“端侧通信意图上报 控制器路径计算 交换机规则下发”这条主链路验证预测的准确性然后逐步加上发送错开和 flowlet 切换每一步都做好 A/B 对比看指标改善。踩过几次坑之后你会发现真正的难点从来不在算法本身而在于把一套设计在真实硬件上稳定地跑起来。最后再分享一个小技巧当你评估 Stellar 这类方案时不要只盯着平均吞吐或平均时延一定把 P99 尾延迟测试纳入必测项。AI 分布式训练的性能始终被最慢的链路、最慢的节点、最慢的梯度同步牵制能把尾延迟压下去比把平均值提升几个百分点更有价值。这也是 Stellar 最让我欣赏的地方——它不是把网络调快了一点而是把网络调稳了。