腾讯星脉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网络价格昂贵、需求量小，读者粗略一看可能觉得与本文实际情况不符。但仔细审视那段书稿，会发现它更像是一种预判。并非拥有预测未来的能力，而是基于逻辑推理得出的常识，本就不难。
