1. 从万卡协同这个词说起为什么它曾经是噩梦如果你在AI基础设施这行待过几年听到万卡协同这四个字第一反应大概率不是兴奋而是头皮发麻。我在2021年前后参与过一个千卡级别的训练集群调优项目那时候光是让一千张卡稳定跑满三天不崩就已经让整个团队连续熬了两个星期。等到规模往万卡推的时候问题不是线性增长的是指数级爆炸的。先把这个概念说清楚。所谓万卡协同指的是把一万张甚至更多加速卡通过高速互联网络组织成一个逻辑上的超级计算单元让它们协同完成同一个大模型的训练或推理任务。听起来很美好但真正做过的人都知道这里面藏着一堆让人崩溃的工程难题。最核心的矛盾在于算力越集中通信开销占比越高。大模型训练里的集合通信操作比如AllReduce、AllGather、ReduceScatter随着卡数增加通信量会急剧膨胀。你有一万张卡每张卡算得再快如果数据在卡之间搬来搬去的时间超过了计算时间那这些卡就是在空转烧电费。业内有个说法叫通信墙说的就是这个事。第二个噩梦是故障率。假设单卡每小时故障概率是万分之一一千张卡的时候平均每十小时出一次故障还能忍一万张卡的时候平均每小时就出一次故障。你辛辛苦苦跑了两天的训练任务因为一张卡挂了整个任务崩掉checkpoint回滚两天白干。这种体验做过大规模训练的人都懂。第三个噩梦是拓扑与调度。一万张卡怎么连用什么样的网络拓扑胖树、Clos、还是别的带宽怎么分配哪张卡和哪张卡之间的通信路径最短这些问题如果设计不好实际有效算力可能只有理论峰值的百分之二三十。所以当华为昇腾960超节点这个概念出来的时候我第一反应是它到底解决了上面哪几个问题是通信是可靠性还是拓扑后来仔细研究了一下它的技术路线尤其是NPO光互联这个关键词我才明白它想干的事情——把万卡协同从需要顶级团队才能玩转的噩梦变成开箱即用的标配。这篇文章我就从一线工程视角把昇腾960超节点这套东西拆开讲清楚。它凭什么敢说把万卡协同变成标配NPO光互联到底解决了什么超节点这个架构和传统集群有什么本质区别以及如果你是一个正在规划算力集群的团队这套东西对你意味着什么。2. 超节点到底超在哪和传统集群架构的本质区别2.1 传统万卡集群的组网逻辑与它的天花板要理解超节点得先理解传统集群是怎么组网的。传统的AI算力集群本质上是服务器网络的堆叠。一台服务器里放8张卡服务器内部用PCIe或者NVLink这类高速总线互联然后服务器之间通过InfiniBand或者RoCE以太网连起来组成一个大的集群。这个架构的问题在哪层级太多每一层都有带宽衰减和延迟增加。卡到卡之间通信如果不在同一台服务器内就要经过卡→服务器内总线→网卡→交换机→网卡→服务器内总线→目标卡。这一圈下来延迟是服务器内通信的几十倍甚至上百倍。我举个具体的数字感受一下。服务器内NVLink的带宽可以做到几百GB/s延迟在微秒级而跨服务器的InfiniBand即便是最新的400G甚至800G单端口带宽也就50GB/s到100GB/s延迟在几微秒到十几微秒。看起来差距不大但集合通信是木桶效应最慢的那条链路决定整体速度。一万张卡做AllReduce跨服务器的通信占比极高整体效率就被拖下来了。这就是为什么很多集群理论算力很吓人实际跑出来的MFU模型算力利用率只有30%到40%。剩下60%多的时间卡在等数据。2.2 超节点的核心思路把跨机变成机内超节点SuperPod的核心思路其实很朴素既然跨服务器通信慢那我就把更多的卡塞进一个逻辑上的大机器里让它们之间的通信走高速总线而不是走网络。传统一台服务器8张卡超节点可以做到几十张甚至上百张卡在一个高速互联域内。华为昇腾960超节点按照公开的技术路线是把大量的昇腾910系列芯片通过高速互联总线组织成一个超节点节点内的卡之间通信走的是高带宽、低延迟的总线而不是传统的以太网或InfiniBand。这个变化带来的直接好处是节点内的集合通信效率大幅提升。原本需要跨机走网络的AllReduce现在变成了节点内的总线通信带宽上去了延迟下来了通信占比自然就降了。但这里有个关键问题一个超节点能塞多少卡塞得越多节点内通信越高效但物理上、散热上、供电上的挑战也越大。而且当规模超过一个超节点的容量时超节点之间还是要走网络。所以超节点不是银弹它是在节点内总线和节点间网络之间找一个更优的平衡点。2.3 昇腾960超节点的定位不是单卡升级是系统级重构很多人一听到昇腾960第一反应是哦新芯片。但如果你仔细看这个标题的措辞——昇腾960超节点重点其实在超节点三个字上。它不是单纯讲一颗芯片的算力提升而是讲一整套系统级的架构重构。我理解这套东西的定位是这样的它把万卡协同需要的几个关键能力——高速互联、统一内存编址、故障隔离、拓扑感知调度——打包成一个标准化的产品形态。以前你要自己攒一个万卡集群得自己选网络、自己调拓扑、自己写调度、自己处理故障现在这些东西被集成到超节点架构里你拿到的是一个半成品只需要做上层的适配。这就是从噩梦变成标配的真正含义。噩梦不是单点技术难而是系统工程太复杂需要太多跨领域的专家协作。标配的意思是这套复杂性被封装了普通团队也能用起来。3. NPO光互联把通信瓶颈从网络层拉到物理层解决3.1 为什么是光而不是继续堆电互联要讲清楚NPO光互联的价值得先讲清楚电互联的物理极限。传统的电信号互联无论是PCB走线还是铜缆都有一个绕不开的问题频率越高衰减越大功耗越高传输距离越短。你在服务器内用铜缆跑高速信号几厘米到几十厘米还行再远就不行了。而且速率越高驱动电信号的功耗就越夸张。有数据显示在高速率下电互联的功耗可能占到整个链路功耗的一大半。光互联的优势在于光信号在光纤里传输衰减极低可以传得更远而且速率提升时功耗增长远没有电互联那么陡峭。这就是为什么长距离通信早就用光纤了。但短距离、芯片间的互联以前因为光模块成本高、功耗大、集成度低一直没大规模用起来。NPO也就是Near Package Optics近封装光学是把光引擎放到靠近芯片封装的位置缩短电信号路径让光互联的优势能在芯片间、板间这个尺度上发挥出来。它和CPOCo-Packaged Optics共封装光学是同一个技术方向的不同阶段NPO相对更成熟、更容易落地。3.2 NPO在超节点里扮演的角色在昇腾960超节点这个架构里NPO光互联解决的是超节点内部以及超节点之间的高速互联问题。我打个比方。传统集群像是一个城市卡是居民网络是道路。居民之间要交流得开车上路路堵了就慢。超节点像是一栋大楼楼内居民走内部通道快得多。但如果楼和楼之间也要交流还是得走外面的路。NPO光互联的作用就是把楼内通道和楼间通道都升级成光速通道让数据传输的瓶颈尽可能小。具体来说NPO带来的几个实际收益带宽密度提升同样的物理空间里光互联能提供的带宽远高于电互联。这意味着超节点内可以塞更多卡或者同样卡数下互联带宽更充裕。功耗下降高速率下光互联的每比特功耗低于电互联对于万卡级别的集群省下来的电费是天文数字。传输距离延长光信号可以传得更远这让超节点的物理布局更灵活不用把卡挤在一个机柜里。3.3 光互联落地时的工程坑这里我要泼一点冷水。光互联不是没有代价的。我在实际接触光互联方案的时候踩过几个坑分享出来给准备上这套东西的团队参考。第一个坑是光模块的可靠性。光模块里有激光器激光器是有寿命的而且对温度敏感。大规模部署时光模块的故障率是运维的一大挑战。传统电互联的故障排查相对简单光互联一旦出问题定位起来更麻烦。所以超节点架构里故障检测和隔离机制必须做得很扎实否则万卡规模下光模块故障会成为新的噩梦。第二个坑是清洁和连接。光纤连接对灰尘极其敏感一个微小的灰尘颗粒就可能导致链路衰减甚至中断。大规模部署时光纤的清洁、插拔、管理都是细活。我见过因为一个光纤接头没插好导致整个训练任务性能下降一半的案例。第三个坑是成本。光模块、光纤、光交换机的成本目前还是高于电互联。虽然长期看功耗省下来的钱能回本但初期投入是实打实的。所以选型时要算总账不能只看采购价。提示如果你的团队第一次上光互联方案建议先在一个小规模子集群上跑通运维流程包括光模块监控、故障定位、清洁规范再往大规模推。不要一上来就万卡全光运维跟不上会非常痛苦。4. 万卡协同从噩梦到标配昇腾960超节点解决的四个核心问题4.1 通信效率集合通信的最后一公里前面讲了超节点和NPO光互联的硬件基础现在讲软件和系统层面昇腾960超节点是怎么把万卡协同做顺的。第一个要解决的是集合通信效率。大模型训练里数据并行、张量并行、流水线并行混合使用集合通信操作极其频繁。万卡规模下一次AllReduce涉及的数据量可能达到GB级别。如果通信效率上不去再强的算力也白搭。超节点架构在这里的优势是节点内通信走高速总线节点间通信走NPO光互联两层都做了优化。而且华为在软件栈上应该做了拓扑感知的通信调度让数据尽量在近距离传输减少跨节点跳数。这一点很关键因为集合通信的算法比如Ring AllReduce、Tree AllReduce在不同拓扑下的效率差异巨大。如果调度器不知道底层拓扑可能把本该在节点内完成的通信绕到了节点外白白浪费带宽。我个人的经验是评估一个万卡集群的通信效率不要只看峰值带宽要看实际训练任务下的通信占比。用profiling工具抓一下看看通信时间占总时间的比例。如果超过30%说明通信优化还有很大空间。昇腾这套东西如果能把通信占比压到15%以内那对训练效率的提升是实打实的。4.2 可靠性万卡规模下的故障是常态不是意外第二个核心问题是可靠性。前面算过万卡规模下故障是每小时级别的事件。所以超节点架构必须把容错做进设计里而不是靠运维事后救火。具体来说需要几个层面的机制硬件级故障检测卡、光模块、总线、供电每个环节都要有实时监控。一旦异常能快速定位到具体部件。任务级容错训练任务要支持checkpoint快速保存和恢复而且checkpoint的频率和开销要平衡好。太频繁影响性能太稀疏回滚损失大。故障隔离一张卡出问题不能影响整个超节点。要有机制把故障卡隔离出去让任务在降级状态下继续跑或者快速重启替换。这里有个实操心得checkpoint策略要根据任务特点定制。我见过团队用固定的时间间隔做checkpoint结果在故障高发期回滚损失巨大。更好的做法是根据训练阶段的稳定性动态调整比如训练初期不稳定时加密checkpoint后期稳定后放宽。4.3 调度与拓扑感知让每一张卡都跑在最优路径上第三个问题是调度。万卡集群里任务怎么分配到卡上直接影响通信效率。举个简单例子一个需要频繁通信的并行组如果被调度到了跨超节点的卡上通信就要走光互联延迟高于节点内。而如果调度到同一个超节点内通信走总线效率高得多。所以调度器必须拓扑感知知道哪些卡之间通信成本低尽量把关系紧密的任务放在一起。昇腾960超节点如果配套的调度系统做了这层优化那对用户来说就是无感的——你提交任务系统自动帮你选最优布局。这也是标配的含义之一复杂的事情系统做了用户不用操心。4.4 软件栈与生态硬件再强软件跟不上也是白搭第四个问题也是最容易被忽视的是软件栈和生态。万卡协同不只是硬件互联的问题还涉及编译器、通信库、训练框架、算子优化等一整套软件。硬件提供了高速公路但如果没有好的交通规则和导航系统照样堵车。昇腾这套东西的软件栈包括CANN类似CUDA的角色、通信库、以及和主流训练框架的适配。这块的成熟度直接决定了用户上手难度。我的观察是硬件参数可以很快追平甚至超越但软件生态的积累需要时间。所以评估这套方案时不要只看纸面算力要看实际框架适配情况、算子覆盖度、社区活跃度。注意如果你现在的训练代码是深度绑定某个特定生态的迁移到新平台时算子适配和性能调优的工作量要提前评估。不要假设换个硬件就能跑实际往往需要重写部分代码和重新调优。5. 算力约束下的现实思考不是所有团队都需要万卡5.1 从RTX 3090到万卡集群算力需求的真实分布聊完了昇腾960超节点这套高大上的东西我想拉回现实聊聊大部分团队真正面临的问题。网络热词里有个很有意思的组合rtx3090算力和分布式算力。这说明什么说明大量团队和个人其实是在用消费级显卡做AI而不是万卡集群。RTX 3090有24GB显存算力对于中小模型训练和推理是够用的。很多人用几张3090组个小集群跑微调、跑推理性价比很高。所以这里要泼一盆冷水万卡协同是给超大模型训练准备的不是所有团队都需要。如果你训练的是7B、13B级别的模型几张到几十张卡就够了超节点的优势体现不出来。只有当你的模型大到单卡放不下、需要模型并行或者数据量大到需要大规模数据并行时万卡协同的价值才真正显现。5.2 精度与算力INT8、FP16、FP32到底怎么选另一个热词是int8, fp16, fp32, fp64的区别和算力需求。这个问题看似基础但实际选型时很多人搞不清楚。简单说精度位数典型用途算力需求特点FP6464位科学计算、高精度仿真算力消耗最大AI训练基本不用FP3232位传统AI训练、部分推理精度高算力消耗大FP1616位主流AI训练、推理精度和算力平衡好最常用INT88位推理加速、量化部署算力消耗小精度有损失实际选型逻辑是训练优先用FP16或BF16推理根据精度要求选FP16或INT8。FP32在训练里逐渐被混合精度替代FP64在AI里基本用不上。INT8适合对延迟敏感、精度要求不极端的推理场景。这里有个经验不要盲目追求低精度。INT8虽然快但量化带来的精度损失在某些任务上可能是灾难性的。我见过团队为了提速把模型量化到INT8结果准确率掉了十几个点得不偿失。量化前一定要做充分的精度验证。5.3 分布式算力的另一种形态共享与出租热词里还有个人电脑GPU共享算力出租和分布式算力。这反映了一个趋势算力正在从集中走向分布再从分布走向共享。共享算力的逻辑是很多个人和小团队的GPU在大部分时间是闲置的如果能把这些闲置算力聚合起来理论上能形成一个巨大的分布式算力池。这个思路在概念上很吸引人但实际落地有几个硬伤网络带宽分布式算力的节点之间网络质量参差不齐大模型训练需要的通信带宽很难保证。信任与安全把任务分发到陌生节点上数据安全和任务可靠性怎么保证调度复杂度异构节点、异构网络调度难度远高于统一集群。所以目前共享算力更多用在推理和轻量级任务上大规模训练还是得靠专业集群。但这不代表这个方向没价值随着网络基础设施提升和调度技术进步分布式算力的应用场景会扩大。6. 如果你要规划一个算力集群我的实操建议6.1 先算清楚你的真实需求别被参数忽悠我见过太多团队一上来就说要建万卡集群结果实际模型规模只需要几百张卡。算力规划的第一步永远是搞清楚自己的真实需求。具体怎么算几个关键问题你的模型参数量多大训练需要多少显存你的数据量多大训练一轮需要多长时间你的迭代频率要求多高是每天出结果还是每周你的预算是多少包括采购、电力、运维、人力。把这些算清楚你才知道需要多少卡、什么精度、什么互联方案。不要看着别人万卡就眼红适合自己的才是最好的。6.2 互联方案选型什么时候该上光什么时候电就够了互联方案的选择核心看规模和通信模式。小规模几十张卡以内服务器内总线普通以太网就够了没必要上光。中等规模几百张卡可以考虑InfiniBand或高速以太网光互联可选但非必须。大规模千卡以上光互联的优势开始明显尤其是通信密集的训练任务。超大规模万卡光互联基本是必选项电互联的功耗和带宽瓶颈扛不住。选型时还要考虑运维能力。光互联的运维门槛高于电互联如果你的团队没有相关经验要么提前培养要么选择运维支持好的方案。6.3 软件栈适配迁移成本往往被低估硬件选型相对容易软件适配才是深水区。我的建议是在采购决策前先做软件栈的POC验证。拿你实际的训练代码在目标平台上跑一遍看能不能跑通、性能如何、需要改多少代码。这一步能帮你避免很多后期的坑。具体验证清单你用的训练框架是否支持目标平台你的自定义算子是否需要重写通信库的API是否兼容性能调优工具是否齐全社区和文档是否完善这些问题如果前期不搞清楚后期迁移时会被坑得很惨。6.4 运维体系万卡集群的隐形战场最后说运维。万卡集群的运维和千卡集群完全不是一个量级。几个必须建立的体系监控体系卡、网络、光模块、供电、温度全链路监控异常实时告警。故障响应故障定位流程、替换流程、任务恢复流程都要标准化。性能基线建立性能基线定期跑benchmark发现性能退化及时排查。容量规划根据业务增长预测算力需求提前规划扩容。我个人的体会是运维体系的成熟度决定了万卡集群的实际可用性。硬件买回来只是开始能不能稳定跑起来看的是运维。7. 写在最后标配不是终点是起点回到标题里那个说法——把万卡协同从噩梦变成标配。我的理解是昇腾960超节点这类方案确实在把大规模算力协同的门槛往下拉。NPO光互联、超节点架构、拓扑感知调度这些技术组合起来让以前需要顶级团队才能玩转的事情变得更多团队能够触及。但标配不等于简单。万卡协同涉及的工程问题依然复杂只是复杂性被封装到了更底层。对于使用者来说你需要理解的是这套系统的能力边界在哪、什么场景下用、怎么用得好而不是完全当黑盒。我在实际项目里的体会是再好的架构也替代不了对业务和系统的深入理解。工具越强大越需要知道什么时候该用它、什么时候不该用。万卡协同是给真正需要它的场景准备的用对了是利器用错了是负担。最后分享一个小技巧如果你正在评估这类大规模算力方案不要只看厂商给的benchmark数据一定要拿自己的真实任务去测。benchmark是理想条件下的数字真实任务的性能往往打折扣。用自己的任务跑出来的数据才是决策的依据。