用腾讯星脉，给AI网络诊脉
对AI的观点，其实一直很明确：支持客户做自己的AI，云厂商专心把算力IaaS云做好。最近参加腾讯的一个技术交流会，听了专家介绍“星脉2.0网络技术架构”，也了解了这套架构如何支撑AI模型训练，有些感触，正好借此机会整理成文字。
这篇文章分成三部分：第一节是快速但严谨的技术科普，讲AI大模型为什么离不开高性能网络；第二节呼应上一节，具体看看腾讯星脉2.0是如何解决这些问题的；第三节是个人视角的讨论，聊聊云厂商和硬件厂商之间到底是什么关系。
1. 分布式显存依赖高速网络
要理解产品和技术的价值，得先搞清楚真正的需求是什么。这一节面向甲方技术工程师，解释为什么AI算力云离不开高性能网络，以及这种网络和常规网络之间的差异。内容比较多，拆成五个小节来讲。
1.a 大模型训练任务的基础运行模式
从简单的运维视角来看，GPU计算任务和常规计算任务差距并不大：只不过计算芯片从CPU换成了GPU，主存储从内存变成了显存，仍然需要从外存读写持久化数据。甚至可以说，GPU计算任务反而更简单一些——向量和矩阵之间只做加法和乘法，天然适合拆分成多个并行任务。数据并行、张量并行、流水线并行……这些方法可以把一个大模型训练（甚至部分推理）任务，拆散到一机多卡、多机万卡的集群里同时跑。
但需要警惕的是，这些看似简单的并行计算任务，其实都很脆弱。大模型训练系统大多是典型的“严格并行系统”，1%的丢包就会导致GPU利用率下降50%，而一个节点的卡顿，甚至可能拖垮整个集群，造成回滚。集群规模越大，网卡总数就越多，网络稳定性的重要性，怎么强调都不过分。
1.b 分布式显存池的IO消耗有多大
通常提到分布式系统，我们想到的是分布式外部存储，比如HDFS、对象存储、数据库，这些技术已经很成熟。但大模型训练任务（以及部分推理任务）需要的是一套巨大的分布式显存资源池。GPU和本卡内的显存数据并不是绑定关系，每个细粒度的计算任务，都可能触发集群内多个节点的显存数据重新读写。这对吞吐量和时延的挑战，是传统业务难以想象的。
当前大模型训练普遍需要几千甚至几万张卡并行执行。先看一机多卡的情况——在同一主板的不同显卡之间同步数据时，就连英伟达都觉得PCIe的160GByte/s读写速率太慢，于是开发了Nvlink接口。H100的读写速率能达到900GByte/s，H800也能到400GByte/s。但一机多卡的总数终究有限，目前主流是一机八卡，英伟达最新的SuperPOD也就72块卡。
1.c 提高IO为什么能节省算力资源
GPU计算和常规计算一样：从外部（包括磁盘类持久化存储，也包括其他显卡显存里的中间结果）读取模型、参数和数据到本地显存，然后计算芯片从显存读取数据进行处理，处理完的结果再写回外部，才能开始下一轮工作。如果显存里没有数据可读，或者旧数据还没处理完，计算芯片就只能干等着。计算芯片的造价极其昂贵，让它等待显存读写数据，本质上就是在浪费金钱和时间。很多宣传中提到的“能节省n%算力资源”，背后的逻辑其实都是缩短了数据同步等待的时间。
万卡集群的IO瓶颈不在主板上，而是内网带宽不够用。注意带宽相关速率单位是bit，要除以8才是byte。GPU太贵，所以很有必要在网络设施上舍得花钱。一个万卡集群的网络TCO成本，可能占到整个集群成本的10%以上。以腾讯星脉网络为例，一台8卡GPU服务器，每块卡配一块400Gb的网卡，单台服务器带宽就达到了惊人的3.2Tb。
1.d 万卡集群必须依赖高性能网络
大模型竞争激烈，企业客户需要以月为单位快速迭代出更优秀的模型，在公有云上短期租赁万卡GPU集群，用强大算力快速出成果，确实是性价比很高的选择。万卡集群要维护一个分布式显存资源池，显存内的数据随时可能全量读写，这对网络的压力极大。常规业务网络IO平均利用率通常不超过30%，但大模型训练集群的网络利用率普遍超过90%。
实现“大带宽+低时延”网络，目前主要有两条技术路线：Mellanox主导的InfiniBand（IB），以及基于RDMA over Converged Ethernet（RoCE）。英伟达收购Mellanox，一方面让IB网络能够更紧密地配套GPU集群，另一方面也使它变得昂贵且封闭。RoCE网络对公有云和大型互联网企业很友好，主流云厂商的技术积累不见得比Mellanox差，价格更便宜，后续潜力也更大。
云厂商不仅能提供满足物理条件的万卡高性能网络，在软件层面也有不少创新。一个负载超过90%的繁忙网络极易发生拥塞，事后调整效率太低——前文已经举过例子，“1%的网络丢包会降低50%的GPU利用率”。减少拥塞有两个“盘外招”：优化网络拓扑，少走几次交换机；网卡主动调整发包频率以减缓拥堵。云厂商了解详细的网络拓扑和硬件实时负载，又有强大的研发团队，完全可以自研加速通讯库和拥塞控制协议。
1.e 网络IO开始干涉主板IO
网络IO确实是GPU集群的算力瓶颈，但更准确地说，不是网络IO拖慢了GPU集群，而是在海量资金加持下，网络IO开始承接新的任务了。以前网络IO直接拒绝承接“毫秒以下、GB以上”的需求，因为在有限预算下，只有主板总线才能达到这样的速度。但现在GPU集群爆炸式增长，单机都能提供3.2Tb带宽，加上RDMA压缩网络延迟，网络IO确实有底气挑战PCIe了。以前参加网络交流会，参会者从不关心具体业务；这次腾讯星脉的交流会，网络研发部门对AI应用的数据流向居然如数家珍，这是一个很有意思的变化。
基于这个观察，在这次交流会上看到两个重要的新概念：第一，异构并行通信——如果同一台机器内两张GPU卡的Nvlink带宽跑满了，一部分数据可以从网卡这边迂回过去；第二，通过网络IO的异常变化，快速定位集群内的异常节点。这些概念在落地过程中还有不少挑战，但网络技术从封闭保守走向拥抱业务，这个开端本身就很酷。
2. 星脉2.0网络的实践优势解读
GPT-3.5是2022年底发布的，此后大模型业务才真正爆发。短短时间内，市面上缺乏兼具中立性和权威性的GPU集群网络技术资料。目前只能以英伟达和星脉2.0公开发布的技术资料，作为分析高性能网络的重要参考。
腾讯在GPT爆发之前就已经在维护千卡规模的大模型，所以面对业务爆发并没有措手不及。去年7月就推出了星脉网络1.0，今年升级到2.0。腾讯云的星脉网络一直处在RoCE网络技术应用的第一梯队，不少技术指标和研发方向在整个行业都是首发首创。星脉1.0时代，AllReduce负载率就已经达到90%，跨LA的流量占比很低（意味着流量拓扑亲和性更好）。星脉2.0进一步追求更高的硬件功耗比，能够节省大量电力成本，通讯性能提升30%，集群训练时长降低10%，训练故障定位时长控制在10分钟以内。这些技术指标对很多工程师都有实际参考意义——上一节科普中提到的丢包和单点故障影响集群的问题，都是运维过程中的真实体验。
星脉1.0在去年4月就支持了万卡集群，去年12月已支撑数万卡规模的网络集群，稳定性业内第一梯队。星脉2.0理论上能支持10万+GPU卡，但这个规模已经触及单体机房的供电上限，稳妥起见只能说“理论上支持”。如果有人宣称能做更大规模的卡池且已经落地，不妨问问他们是怎么解决供电能源指标问题的。
星脉2.0的一个重要进步是自研网络硬件：TCS9500交换机、硅光模块和CNIC算力网卡。自研硬件性能相比上一代翻倍，单卡400Gb网络IO不是梦；价格更便宜，功耗TCO也大幅降低。而且这些硬件有广泛的可选供应商，不用担心被强势供应商把持议价权和供货安全。CNIC网卡和下面提到的软件技术，共同支撑了主动网络拥塞控制。
星脉1.0就拥有TCCL高性能通讯库和TiTa端网协同协议。参考星脉1.0时期的公开文档，TCCL完全兼容NCCL的功能与使用方法，通过优化网络拓扑路径（即少走几次交换机），能够提高大约50%的带宽利用率。星脉2.0发布后，这两个软件都得到了大幅升级：从被动处理拥塞变为在网卡端提前控制速度以避免拥塞，从固定路径规划变为动态智能调参，确保网络性能时刻处于最佳状态。
针对H800 GPU卡Nvlink带宽偏小的现状，TCCL开始将机内Nvlink的部分流量卸载到网卡上，增强异构并行通信的能力——板载IO不够用，那就走网络IO。看着这个技术，不禁让人想到，如果星脉网络发展到3.0、4.0、5.0……腾讯将这些技术展望方向称为“Eth-X超节点”，网卡性能再提高5倍10倍，网卡真的有可能比板载PCIe甚至Nvlink更快。
星脉网络还将GOM&GOA技术运营系统视为重要技术突破。起初不以为然，觉得不就是监控那点事吗？但咨询了一位确实在运维万卡集群的工程师后，发现这一条相当重要。上一节已经讲过，GPU集群是脆弱的严格并行系统，任何一张卡的卡顿或假死，都会导致整个集群性能大幅下降或失败回滚。虽然训练任务可以设置检查点中途保存，但每次发现异常都是滞后的，处理故障往往需要几个小时。星脉网络的工作已经延伸到通讯库和端网协同协议，能够掌握常见大模型训练任务的网络IO用量。在承接每一次任务时，可以提前在时序和空间上做好流量仿真预测，准确预估每张网卡的IO用量波形。GOM&GOA一旦发现实际监控与仿真预测有重大偏差，就能协助工程师更快、更准地定位故障点，甚至让一些小故障自动化处理。
3. 云厂商对硬件厂商的改造替代
前两节分享了GPU集群依赖高性能网络的相关知识，这一节结合《云计算行业进阶指南》一书，简单聊聊云厂商和硬件厂商的关系。这部分内容和星脉网络没有直接关联，提到的云厂商也并非特指任何一家，纯粹是个人视角的思考。
第一，云厂商很爱英伟达。因为英伟达凭空创造出了GPU卡池这门生意，给云厂商带来了新的营收增长点。没有这么昂贵的GPU，谁会舍得给网络砸那么多钱去支撑一个分布式显存池呢？
第二，云厂商现在重点做英伟达GPU的适配，但如果其他硬件厂商也能大量生产高性价比的GPU，云厂商非常乐意进行技术适配。引入更多硬件供应商，议价权更强，供货也更稳定。
第三，云厂商离客户、离业务应用太近了，天然适合提供技术服务。客户买的不是硬件，而是算力服务。硬件上电只是服务的开始，而不是结束。星脉研发的TCCL、TiTa、GOM&GOA，这些都属于很有价值的服务性工作。
第四，云厂商具备很强的通过技术找解决路径的能力。比如用网络带宽来增加GPU卡间互联带宽；如果这条路走不通，可能会去推动PCIe 6、PCIe 7或者其他高IO硬件早日落地，也可能引进其他平替的零部件。
第五，书中曾提到RDMA网络价格太贵、需求量太小，读者粗看可能会觉得和本文实际情况不符。但仔细看那段书稿，会发现其实更像是一种提前的判断。并非具备预测未来的能力，而是基于逻辑推理得出的常识，本就不是难事。
