用腾讯星脉，给AI网络诊脉

我对AI的观点一直是：“支持客户做AI，云厂商专心做算力IaaS云”。最近参加了腾讯的一个交流会，听取专家介绍了“星脉2.0网络技术架构”，并了解该技术在如何助力AI模型训练任务，心有所想，就写下了这篇文章。

本文第一节是快速严谨的技术科普，介绍了AI大模型为什么必须重度依赖网络；第二节呼应上一节内容，介绍腾讯星脉2.0如何撑起了大模型业务；第三节是以前两节为证据，从我个人的主观角度讨论云厂商和硬件厂商的关系。

1. 分布式显存依赖高速网络

要介绍产品和技术，第一步是解析真实的技术需求。本节首先向甲方的技术工程师介绍，为什么AI算力云需要重度依赖网络，AI算力云依赖的网络和常规网络有什么区别。本节内容较多，所以我分成了五个小节。

1.a 介绍大模型训练任务的基础运行模式

从简单运维的角度看，GPU计算任务和常规计算任务差距并不大，只是计算芯片从CPU变成了GPU，主存储从内存变成了显存，还需要从外存读写一些持久化数据。

GPU计算任务甚至比常规任务更简单，向量和矩阵之间只做加法和乘法，更容易拆分成多个并行计算任务。我们可以通过数据并行、张量并行、流水线并行等方法，将一个大模型训练（以及部分大模型推理）任务拆分到一机多卡、多机万卡群集内并行工作。

当然了，这些简单拆分的并行计算任务都很脆弱，大模型训练系统多是娇贵的严格并行系统，有1%的丢包会导致GPU的利用率下降50%，而一个节点的卡顿可能会导致整个群集崩溃回滚。但群集规模越大则网卡的总数就越多，所以网络稳定性非常重要。

1.b 分布式显存池需要大量消耗IO

常见的分布式系统中使用的分布式存储指的是外部存储，比如HDFS、对象存储、数据库，这类分布式存储已经有成熟的技术方案。但是大模型训练任务（及部分推理任务）中，需要制作一个巨大的分布式显存资源池；GPU和本卡内的显存数据并不是绑定关系，每一个细粒度计算任务都会导致群集内多个节点的显存数据进行重新读写，这会带来巨大的数据吞吐和读写时延的挑战。

现在做大模型训练（和少数推演）任务普遍需要几千乃至几万片卡并行执行，本段落介绍一机多卡，主要是为了展示分布式显存池对IO的需求有多么夸张。

显卡分布式的第一步就是一机多卡，在同一主板不同显卡之间同步数据时，英伟达嫌弃PCIE只有160GByte的读写速率太慢了，干脆就开发了Nvlink接口，让H100的读写相加速率达到了900GByte，H800的速率也达到了400G。但一机多卡的卡总数有限制，当前普遍采用的是一机八卡，英伟达最新发布的SuperPOD也就72块卡。

1.c 为什么提高IO能节省算力资源

GPU计算任务和常规计算任务一样，需要从外部（包括磁盘类持久化外存储，也包括其他显卡显存里的中间结果）读取模型、参数和数据到本显卡的显存，然后计算芯片从显存内读取数据进行计算处理，计算结果也需要写入到外部后才能开始下一个工作任务。

在显存内没有数据可读取或旧数据未处理完成时，计算芯片就要等待显存的工作，陷入无事可做的闲置状态。因为计算芯片很昂贵，让计算芯片等待显存读写数据就是在浪费金钱和时间，很多“能节省n%算力资源”的宣传，都是因为其缩短了等待数据同步的时间。

万卡群集的IO瓶颈肯定不在主板上，而是内网带宽不够用（注意带宽相关的速率是bit，要除8才是byte）。因为GPU非常昂贵，所以我们有必要在网络设施上有大把砸钱，一个万卡群集的网络TCO成本能达到整个群集成本的10%以上。以腾讯星脉网络为例，一台8卡GPU服务器就是插了8块400Gb的网卡，单台服务器的带宽已经达到了惊人的3.2Tb。

1.d 万卡群集必须依赖高性能网络

现在大模型竞争这么激烈，企业客户需要尽快（以月为单位）迭代出更优秀的大模型，也非常适合在公有云上短期租赁万卡GPU群集，用强大的算力保证新模型尽快出炉。

万卡群集要维护一个分布式显存资源池，显存内的数据随时会全量读写，这就对网络的压力很大了，常规业务的网络IO平均利用率不超过30%，但是大模型训练群集的网络利用率普遍超过90%。

在万卡GPU群集中，实现“大带宽+低时延”的网络有两种技术方向，第一种是Mellanox主导的InfiniBand（简称IB）网络，第二种是使用RDMA over Converged Ethernet（简称RoCE）网络。Nvidia收购Mellanox，既让IB网络可以更快速更专注的配套GPU群集，也让IB网络变得昂贵又封闭。RoCE网络对公有云和大型互联网企业很友好，主流云厂商的技术不会比Mellanox差，RoCE网络不仅价格便宜，后劲也会更足一些。

云厂商不仅能提供满足物理条件的万卡高性能网络，也可以做很多软件技术革新。一个负载超过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网络的实践优势解读

GPT3.5是2022年底发布的，此后大模型业务才爆火起来，在这么短的时间里，市面上没有兼具中立性和权威性的GPU群集网络技术资料。我们只能拿着Nvidia和星脉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卡，但是这个GPU卡池的规模已经触及单体机房的供电上限了，稳妥起见只能说“理论上支持”。要是有人宣称能做更大规模卡池的技术实践了，大家一定要问问这哥们是怎么解决的供电能源指标问题。

星脉2.0的一个重大进步就是自研网络硬件，包括TCS9500交换机、硅光模块和CNIC算力网卡。自研硬件比上一代硬件的性能翻倍，单卡400Gb网络IO不是梦；硬件价格也更便宜，还可以大幅降低功耗TCO。此外，这些硬件还有较为广泛的可选供应商，不用担心被强势硬件供应商把持议价权和供货安全。CNIC网卡和下文提到的软件技术共同支持了主动网络拥塞控制。

星脉1.0就拥有TCCL高性能通讯库和TiTa端网协同协议，参考腾讯云在星脉1.0时期的线上文档，TCCL高性能通讯库完全兼容NCCL的功能与使用方法，竭力优化网络拓扑路径（即少走几次交换机），可以提高大约50%的带宽利用率。在星脉2.0发布后，这两个软件都获得了很大的能力升级，将处理拥塞变为在网卡端提前控制速度避免拥塞，将固定路径规划变为动态智能调参，最终让网络性能时刻处于最佳状态。

针对H800GPU卡Nvlink带宽偏小的现状，TCCL还开始将机内Nvlink部分流量卸载到网卡上，增强异构并行通信的能力（就是板载IO不够用，那我就走网络IO了）。看着这个技术，我就在想，要是星脉网络发展到了3.0、4.0、5.0……腾讯将这些技术展望方向称为“Eth-X超节点”，网卡性能再提高5倍10倍，网卡真就能比板载PCIE甚至比Nvlink的速度更快了。

星脉网络还将其GOM&GOA技术运营系统当做重要技术突破，我一开始对此不以为然，觉得这就是监控那点小事儿。但我咨询了一个确实在运维万卡群集的工程师，就发现这一条挺重要的。上一节科普内容就讲过，GPU群集是一个很脆弱的严格并行系统，任何一张卡的卡顿和假死，都会导致整个群集出现极大的性能衰减或者失败回滚。虽然这些训练任务可以设置检查点中途保存，但每次发现异常都是滞后发现，处理故障需要几个小时的时间。

星脉网络的工作已经延伸到通讯库和端网协同协议了，该网络能够掌握常见的大模型训练任务的网络IO用量。星脉网络在承接每一次任务时，就可以在时序和空间上先做好流量仿真预测，准确预估每个网卡的IO用量波形。GOM&GOA技术运营系统一旦发现实际监控的网络IO和仿真预测的数值有重大偏离，可以协助工程师们更快、更准的定位到故障点，甚至让一些小故障自动化处理。

3. 云厂商对硬件厂商的改造替代

前两段完成了对GPU群集依赖的高性能网络的知识分享，这个小段落结合《云计算行业进阶指南》一书，简单谈谈云厂商和硬件厂商的关联。本段内容和星脉网络并无直接关联，本段提到的云厂商也并非特指任何一家云，纯粹是我个人主观看法。

第一，云厂商很爱Nvidia，因为Nvidia凭空创造出了GPU卡池生意，给云厂商带来了新的营收增长点。如果没有这么昂贵的GPU，谁会舍得给网络砸这么多钱来支撑一个分布式显存池哪？下图节选自我的书稿143页：

第二，云厂商现在重点做对NvidiaGPU的适配，如果其他硬件厂商也大量生产高性价比的GPU，云厂商也非常愿意与其进行技术适配，毕竟引入更多的硬件供应商后，云厂商更有议价权、供货更稳定。

第三，云厂商离客户、离业务应用太近了，特别容易为客户提供技术服务。客户要买的不是硬件而是算力服务，硬件上电是服务的开始，不是服务的结束，星脉研发的TCCL、TiTa、GOM&GOA，这都是很有价值的技术服务性工作。

第四，云厂商拥有很强的用技术找出路的能力。比如用网络带宽增加GPU卡间互联带宽，如果网络带宽这条路走不通，云厂商可能会去推动PCIE6、PCIE7或者其他的高IO硬件早日落地，也可能会引进其他平替的零部件。

第五，我的书里写着RDMA网络价格太贵、需求量太小，读者粗看会认为和本文实际情况不符。但大家仔细看这段书稿，会觉得我是未卜先知。我当然没预测未来的能力，但基于逻辑推理出来常识，本就不是难事。

下图出自本书174页的书稿，这段稿子是我2023年初就定稿的。我当时不了解AI的技术细节，以为AI只是用网络来访问分布式外部存储，通过写作本文时的学习，我才知道AI会直接拿网络当内存来用啊。我虽然没等到RDMA网卡降价，但因为GPU卡太贵了，RDMA网卡的相对价格看起来就很便宜、可以大规模推广了。