
1. 昇腾960超节点发布先搞清楚它是什么算力圈今天讨论最猛的一件事就是华为正式发布昇腾960超节点。这不是一次简单的产品迭代而是把AI训练的算力供给粒度从“卡”和“台”直接抬到了“节点”这个级别。我在训练集群这边摸爬滚打了十几年第一反应不是参数多好看而是总算有厂商愿意把数据中心级的互联和调度问题当成一个真正产品化、正式发布的东西来交付了。对大多数做算法和应用的开发者来说“昇腾960超节点”这个名词可能有点绕。我尽量用大白话解释清楚它是什么、解决了什么问题、适合谁关注。如果你正在做大模型训练或者打算建设自己的AI算力基础设施这篇文章值得从头看到尾。1.1 从单卡到超节点算力供给方式的转变传统AI算力集群是怎么搭的买一堆加速卡插到服务器里每台服务器插上网卡连到交换机再用软件把几百张甚至几千张卡组合成一个训练集群。这个过程里大家关注最多的是单卡算力也就是一块芯片的峰值FLOPS。但集群规模一大你会发现真正决定训练跑不跑得动的东西早就不是单卡速度而是卡和卡之间的通信效率。超节点做的事情本质上是把一批芯片做成一个紧密耦合的单元整个单元对外可以当成一台超级计算机来用。单元内部拥有极高的互联带宽、极低的通信延迟甚至能做到内存统一编址和池化。华为昇腾960超节点就是以昇腾960为核心计算单元通过自研的高速互联技术把多个计算节点组成一个紧耦合的超节点对外提供统一的计算、内存、通信能力。打个比方单卡训练集群像一栋楼里的多台电脑互相之间靠网线传文件超节点则像是把CPU、内存、总线全部焊在同一块主板上数据在内部通道里流通速度和延迟完全不是一个量级。这个转变决定了大规模训练时的线性扩展率——也就是你加了一倍的卡训练速度到底能不能接近提升一倍。1.2 超节点不是简单堆机器很多人觉得超节点无非就是把几台机器塞进一个机柜再用高速线缆连起来。真不是这么回事。超节点最难的地方是让里面所有的NPU像一台机器一样协同工作。这涉及几个核心问题第一拓扑设计内部要做全互联All-to-All还是部分互联直接影响通信pattern的最优映射第二内存一致性怎么让多块NPU共享显存域而且不产生大量同步开销第三容错设计芯片和链路一旦出故障如何在任务运行中自动隔离和恢复第四调度方式如何把一个大模型的并行策略切分到超节点内部。这些环节随便哪个做不好超节点的实际效率都会大打折扣。华为敢把昇腾960超节点作为正式产品发布说明它不仅解决了单芯片算力问题更把内部互联、内存池化、故障管理、集群调度这些基础设施层面的东西一并产品化了。规模不是关键关键在软硬件协同的深度。这也是为什么我说这次发布的意义远超一颗新芯片本身。2. 为什么大模型训练绕不开超节点这种形态这两年做大模型的人应该都有体会训练千亿参数模型的时候真正让人睡不着觉的不是算力不够而是通信卡脖子。我见过不少集群GPU/NPU利用率上不去跑到一半全是等待同步的时间节点越多等待越严重。超节点这种形态正是冲着这个痛点去的。2.1 网络瓶颈才是真正的天花板大模型训练过程涉及三个维度算力、显存、通信。当卡数上升到千卡、万卡规模瓶颈基本不在芯片计算速度上而在通信网络里。拿一个万亿参数模型举例。每次训练迭代都需要做梯度同步一个万亿参数的模型梯度数据量随精度不同可能达到几十GB甚至上百GB。传统集群里的跨节点通信要经过网卡、交换机、光模块一条路径上的延迟和带宽损耗都会叠加。更要命的是像MoE混合专家模型这类架构每个token只激活少量专家但token需要在不同专家之间做路由也就是All-to-All通信流量碎片化且频率极高。这类流量走普通网络集群规模越大排队越严重。超节点把最频繁的通信约束在一个高带宽低延迟的内部网络中带宽可以做到比外部网络高出几十倍甚至更多延迟也能降低一个数量级以上。对外通信只需要处理超节点之间的低频交互。相当于把一条拥挤的城市道路变成了高速环线大部分车辆在内部快速流通只有少量车才需要上城市主干道。网络瓶颈被有效缓解集群利用率才有可能上去。2.2 内存池化和显存扩展的工程价值大模型训练还有一个硬约束显存不够用。模型参数、优化器状态、激活值、梯度都要占据大量显存。单卡显存再大放不下万亿参数模型也是白搭所以要做张量并行、流水线并行把模型切到多张卡上。但一切分通信开销就来了显存利用率也不均衡。超节点通过内存池化把这个问题柔和了很多。简单说超节点内部所有NPU的显存可以被看成一个统一的大内存池任务可以按需申请远端NPU的显存访问在软硬件层面被优化得足够高效让开发者感觉像在用一块超大的显存。这个特性对推理同样重要。大模型在线服务里长上下文和并发请求会产生巨大的KV Cache显存需求极高如果显存池化单个实例就能获得更大的内存资源不用频繁把参数和状态搬进搬出。对推荐系统这类高并发排序场景内存池化也能明显提升吞吐。可以说内存池化是超节点区别于传统集群的本质特征之一。3. 昇腾960超节点的核心技术与细节拆解接下来说点工程细节。需要提前声明昇腾960超节点的官方白皮书我应该没你看得全某些具体参数目前公开渠道能确认的不多下面有些点是根据昇腾产品路线和AI集群设计的工程惯例做的合理推断实际以官方发布为准。但架构逻辑和设计思路是可以聊的。3.1 昇腾960芯片层面的技术看点昇腾960作为超节点的基本计算单元从技术演进逻辑上看至少有这几个方向值得关注。第一是算力密度。AI芯片每一代的迭代核心就是单位功耗下能做多少有效计算。昇腾960大概率在AI核心规模、频率、算子执行效率上继续提升让单位芯片的训练吞吐比前代有明确增长。第二是HBM容量和带宽。大模型权重和激活值都堆在HBM里容量决定单卡能放下多大模型切片带宽决定数据搬运速度。超节点对单卡显存的要求不只是“够大”还要“够快”否则内部高带宽互联喂不饱计算单元。第三是多Die互联能力。单颗芯片的算力密度和内存带宽总有物理上限所以高端芯片普遍采用多Die封装。Die与Die之间的互联带宽直接影响芯片对外表现的是不是“一块芯片”。昇腾960如果在这个层面做文章那它在超节点内部的地位会更扎实。第四是能效比。超节点是高热密度系统功耗墙往往是部署的隐形天花板。芯片能效直接决定一个机柜能塞进多少算力、需要上多少液冷、交付周期多长。我看芯片先看能效再看峰值。3.2 超节点互联架构与集群调度超节点内部互联的核心指标就两个带宽和延迟。昇腾的方案是自研高速互联协议支持内存语义访问也就是让远处NPU的显存可以被本地指令直接读写而不是先发消息再等响应。这种级别的互联已经靠近NUMA内存共享的体验了和传统消息传递式的通信库模型完全不同。在集群层面多个超节点再通过高带宽网络互联配合调度系统把一个超大任务拆到多个超节点上跑也可以把多个中小任务调度到同一个超节点内部。最让我感兴趣的是“算力池化”的方向资源不再固定绑定物理拓扑调度器可以按任务需求动态切分一个超节点的部分计算单元给某个任务实现更弹性的资源复用。这对AI基础设施运营是个很大的变化。以前租算力是按“台”按“卡”租资源碎片化严重有了超节点之后理论上可以做到按“计算切片”交付利用率自然能上去。当然切片不能切得太碎否则互联优势就没了。3.3 软件栈与开发适配CANN和MindSpore硬件只是底子真正决定超节点能不能被用起来的是软件栈。昇腾生态里CANN是底层计算架构承担算子开发、图编译、集合通信等核心职责。对习惯了PyTorch的用户昇腾提供了torch_npu这类适配层能把常见模型相对平滑地迁移到昇腾上跑在训练框架层面MindSpore对昇腾硬件的亲和度更高优化也更深。昇腾960超节点最值得关注的是集合通信库和调度层。大规模训练中通信模式是工程师最头疼的部分。超节点内部拓扑是确定的如果集合通信库能感知拓扑自动把通信需求映射到最不冲突的物理路径上就能有效减少消息等待。配合编译层的自动并行能力开发者不需要手动设计每个通信原语框架会根据模型结构和资源拓扑自己规划切分和通信方案。此外调试和性能分析工具也很重要。昇腾生态里有性能分析工具可以看到算子的耗时、通信占比、内存占用分布。真到了调优阶段这些工具比参数列表更有说服力。超节点能不能发挥全部效率很大程度上取决于软件适配深不深这比芯片峰值算力更影响实际体验。4. 哪些场景真正需要昇腾960超节点超节点听起来很厉害但不代表所有AI业务都得用它。我自己见过很多团队买硬件的时候盲目追大结果利用率不到20%。选型一定要从真实场景出发。下面几个方向是比较典型的高价值场景。4.1 万亿参数大模型训练万亿参数模型是超节点最匹配的主场。尤其MoE模型每个token激活的专家数量有限但专家参数分布在不同卡上token需要在所有相关专家之间做All-to-All路由。这种通信模式频率极高、数据块小普通集群网络根本扛不住。工程上常见的做法是把专家并行完全限制在超节点内部一个节点或几个节点构成一个专家副本组因为内部带宽高、延迟低token路由到任何一个专家都能以较快的速度完成。跨超节点只保留attention等通信量相对可控的操作。这样规划下来整个训练系统的通信压力会被控制在一个可用范围内。如果你的团队接下来要训练一个体量在数千亿到万亿参数的模型并且已经做好MoE架构选型那么超节点应该进入你的考察清单。如果模型只有几十亿到百亿参数那不一定需要花这个钱。4.2 大规模推理与科学计算场景大模型推理往往被低估。在线对话类应用对延迟敏感用户请求会生成很长的上下文KV Cache占用会持续增长。传统多卡推理需要频繁切分模型、搬运参数延迟和QPS都不容易做高。超节点内存池化让单实例可以占用超大显存长上下文和并发请求都能更从容地处理同时减少参数在PCIe和网络上的来回搬运。科学计算和HPC也是潜在受益者。分子动力学、气候模拟、流体仿真这类应用有大量全局归约和周期性通信超节点内部的低延迟共享内存语义能把这些开销压下来。对这些场景峰值算力不是第一诉求低延迟、高带宽和超大可用内存才是。4.3 算力成本与ROI评估我建议团队做选型前先给自己的业务算一笔账而不是看厂商发布会的数字就拍板。第一步先做通信占比分析。用profiler采集当前训练任务中通信等待时间占总训练时间的比例。如果这个比例超过30%说明通信已经严重拖后腿超节点会有明显价值如果低于10%说明算力瓶颈还不在通信换超节点提升不会太大。第二步评估模型规模的长期趋势如果年底就要上万亿参数模型那现在考虑超节点是合理的提前布局如果模型规模增长预期有限普通弹性集群性价比可能更高。第三步算TCO。超节点价格高、功耗密度大但训练时间缩短、利用率提升带来的成本节省也很明显。比较时不能只看硬件采购价格要把电力、制冷、机房改造、运维人力、训练吞吐提升全部算进去。很多项目账面亏在电力而不是硬件采购。5. 部署超节点要踩的坑和实操心得如果你真的决定引入昇腾960超节点我提前说句实在话部署的挑战不在验收那天而在之后每一次扩容和排障里。下面这些坑是我做AI基础设施这些年积累下来的经验不算全面但每条都是真实付过学费的。5.1 电力与散热机房改造的真实账超节点的单机柜功耗很可能是传统机柜的几倍甚至更高。传统风冷机柜普遍在10千瓦到20千瓦左右而一个高密度AI机柜轻松上几十千瓦。这个量级不是简单加几个PDU就能解决的。我见过不少单位硬件都进场了才发现机房单机柜供电上限不够最后只能把机器拆开放到不同区域超节点硬生生被拆成了“超远节点”内部互联距离拉长性能优势打折。液冷基本是绕不开的选项。高功耗芯片用风冷很难压住温度带来的降频损失会抵消一部分算力。部署前一定要做热仿真确认冷量分配、管路走向、漏水检测、冗余水泵这些环节。机房承重也要复核高密度机柜整柜重量远超普通机柜老楼层的承重很可能不达标。电力冗余和UPS容量同样要提前规划。AI训练任务一旦中断重新加载checkpoint的时间成本很高所以供电可靠性直接影响业务可用性这不是可以省钱的地方。5.2 集群运维与故障恢复超节点内部连接数量多、链路速率高故障率的问题会变得更加突出。运维策略必须从“机柜级”下沉到“链路级”。我自己的经验是监控要盯三类指标一是NPU温度和历史热趋势提前识别散热劣化二是HBM的纠错计数可纠正ECC错误数量激增往往是显存颗粒老化、接近故障的信号三是内部高速链路误码率这个指标直接预示链路是否要坏。故障域设计也很关键。一个NPU坏了任务能不能自动隔离其他部分继续跑还是整个超节点都需要停机这决定了单次故障的影响范围。建议在部署前就做故障演练人为断掉一条链路观察调度器和训练框架的重启和恢复行为。别等生产任务跑到一半才发现恢复策略是空的。训练checkpoint的管理也要配套升级。一个超节点级别的checkpoint可能达到TB级别保存和重新加载都不是即时操作。建议做异步保存并且周期性地保留多个快照点防止写到一半系统故障导致checkpoint损坏。这个钱不能省。5.3 迁移与适配的注意点从其他平台迁移到昇腾和超节点一定要预期到工作量不要被“兼容PyTorch”这几个字迷惑。算子兼容性是最容易踩坑的地方模型里只要有一个不常用算子没有高效实现就会拖慢整个训练流程。混合精度策略也要重新验证Ascend和CUDA在FP16、BF16的算子实现细节上并不完全一致可能导致结果偏差或者性能回退。我的建议是先跑通再调优。第一步用小规模模型端到端跑通训练、保存、恢复全流程确认数据和模型精度没问题。第二步用性能分析工具跑一遍找出通信占比、算子耗时、内存瓶颈。第三步针对瓶颈算子依次优化中间和昇腾的技术支持保持沟通他们往往有一些针对特定模型的最佳实践。容器化和调度系统的适配也不能忘。Kubernetes加Device Plugin怎么把超节点资源切片、怎么和训练框架的分布式通信初始化对齐这些都要提前测试。很多时候业务没变变的是调度层结果任务一直起不来或者起了之后卡在不同节点上互相找不到。6. 超节点技术方向的影响范围昇腾960超节点发布影响的绝对不止买机器的几家大厂。对做AI开发的人、做算力运营的人、甚至整个产业链上下游都会有实质性变化。我从两个切面聊聊自己的判断。6.1 对AI开发者的影响从开发体验上讲超节点时代分布式训练的许多技术细节会被下沉到底层框架。以前做千亿参数模型你得自己决定是张量并行还是流水线并行手动写通信代码平衡显存和通信。有了超节点之后框架的自动并行能力会越来越强开发者可能只需要描述清楚模型结构和资源规模剩下怎么切分、怎么通信交给编译器和调度器处理。这对资深分布式工程师来说意味着核心技能在迁移从手工调通信转向设计模型架构、优化数据流对新入行的开发者来说门槛反而降低了不再需要先把分布式通信原理吃透才能跑大模型。当然底层技能依然有价值因为总有边缘场景需要手动介入。但趋势很明确模型的表达与算力的调度正在解耦开发者会从“指挥通信”慢慢变成“定义需求”。6.2 对AI算力产业的影响超节点式方案把算力交付方式从“卖卡”拉向“卖节点、卖服务”。对算力供应商来说不再只是卖出多少张卡而是能不能交付可用的算力切片、可靠的服务SLA。这种模式让算力资源更容易被共享也更容易被规模化运营。算力即服务的商业模型会更成熟用户按节点小时或者按计算切片计费比自建集群灵活得多。对供应链的拉动也很直接。高速互联模块、光模块、液冷方案、高功率供电设备超节点都会带来更高规格的新需求。所谓技术换代往往不是单点突破而是整个供应链一起升级。还有一个潜在的长期影响生态标准。超节点用到的互联协议、内存池化接口、资源管理接口如果使用规模足够大会慢慢形成事实标准。这会直接影响后续AI芯片设计和集群软件栈的走向。所以昇腾960超节点这次发布真正重要的意义不只是“又出了一款更快的芯片”而是用一个完整的系统形态把AI算力基础设施的架构标准往前推了一步。我个人在实际项目里最大的体会是算力选型这件事参数榜只能做参考真正要看的还是通信的pattern、内存的需求、系统的可靠性。昇腾960超节点值得重点评估但要不要用、怎么用必须回到你自己的训练任务和信息架构里去。先把profiler跑出来把模型通信占比测清楚再来决定上不上超节点这比看任何发布会都管用。