上午训练集群的监控告警还没处理完，手机就被“昇腾960”刷屏了。华为全联接大会2026启幕，汪涛在台上发布了昇腾960超节点，主题非常明确：加速大模型训练。我把发布会回放翻了一遍，又翻了各路技术博客，最大的感受是——这不只是一颗新芯片，而是把大模型训练的基础设施逻辑重新讲了一遍。
单看“昇腾960”这四个字，很多人会下意识去对比单卡算力、显存大小。但如果你真跑过千卡规模的大模型训练，就会明白：大模型训练卡的瓶颈从来不只是芯片算力，而是数据搬运速度。昇腾960这次直接把“超节点”这个概念推到前台，等于把答案从“芯片”搬到了“集群互联”。这篇文章不聊发布会上的漂亮话，我想从实际做训练工程的角度，拆一拆昇腾960超节点到底解决了什么问题、对搞训练的人意味着什么、如果我要迁移过去，该怎么下手。
1. 发布会现场传达的信号：昇腾960真正的看点在哪
1.1 汪涛发布的核心内容：芯片之外还有“超节点”这套组合拳
华为全联接大会历来是硬件风向标，这次汪涛发布昇腾960，表面上是一颗训练芯片的迭代，实际是三件事同时落地：新单芯片、新的超节点架构、面向大模型训练的整体加速方案。
昇腾960相对前代昇腾910系列，核心看点在两条线：一是单芯片的算力、能效和显存能力继续往上走；二是把互联带宽从“够用”拉到了“大模型训练不太需要担心通信”的水平。发布会现场提得最多的不是“多少TOPS”，而是“超节点”——这比单纯数算力重要得多。
从业内已透露的架构信息看，昇腾960单卡能力已经能支撑百亿级模型的片上训练，配合超节点后，面向千亿、万亿参数模型的分布式训练，集群规模和通信压力会明显减少。更关键的是，华为把整套训练方案从“卖卡”变成了“卖集群”，超节点直接以一体化形态交付，这在AI基础设施领域是一个很清晰的产品信号。
在我个人看来，昇腾960的核心价值排序是：互联架构大于单芯片算力，显存带宽大于标量算力。
1.2 为什么我第一反应是“训练基础设施的玩法要变了”
我很早以前带过一个60B模型的分布式训练任务，靠着几百张加速卡硬撑，最痛苦的不是矩阵乘法不够快，而是每跑一个step，所有卡要把梯度同步一遍，光通信就能吃掉三成到四成时间。后来我们花了很大精力做梯度压缩、通信计算重叠，效果也就那样。这里面的根本原因很简单：传统集群，卡和卡之间走的是网络，网络带宽和时延就是天花板。
昇腾960超节点想改变的就是这个天花板。它把几十张昇腾960用高速总线连成一个高带宽域，从训练框架的视角看，这批卡不再是“一堆通过网络相连的独立设备”，而是一张巨大的逻辑卡。分布式训练中的张量并行通信、MoE路由通信，在这个域内运行时的时延和带宽表现，和传统跨节点网络完全不是一个量级。
做训练基础设施的人都知道，这类架构一旦成熟，整个并行策略的设计逻辑都会变化。很多以前为了“减少跨节点通信”设计的复杂方案，可以变简单；很多以前不敢开的并行维度，可以重新打开。这就是我说“玩法变了”的原因。
2. 单芯片再强也绕不过存储墙：昇腾960算力账的另一种算法
2.1 算力、显存带宽、显存容量，大模型训练到底吃哪个
要理解昇腾960的价值，先得把大模型训练的资源账算明白。很多人只看“算力多少TFLOPs”，但做训练工程的人心里清楚，大模型训练是典型的“存储墙”问题。
一个很直观的事实：75B参数模型，如果按BF16精度存权重，光模型本身就要150GB；训练时还要存梯度、优化器状态，Adam优化器在混合精度下会给每个参数额外占用约12字节以上的显存。粗略一算，单个模型副本就需要几百GB甚至上TB的显存。单颗芯片再强，显存放不下，训练就寸步难行。
这就要靠显存带宽把数据不断喂给计算单元。打个比方，算力单位是“加工能力”，显存带宽是“原料输送速度”。工厂加工能力再大，原料送不过来，设备照样闲置。昇腾960这一类训练芯片，真正决定大批量训练效率的，一是HBM容量能不能把模型放得下，二是HBM带宽能不能让矩阵乘法单元吃饱。
2.2 用170B模型算一笔账：带宽不足会怎样
我经常用“算术强度”（Arithmetic Intensity）来评估一颗芯片能不能喂饱自己。一个简单的判断公式：如果芯片峰值算力是P，显存带宽是B，那么只有当加载1字节数据能支撑足够多的浮点运算时，计算单元才不会被饿着。
举个例子，一颗芯片FP8算力如果达到几百TFLOPs，显存带宽是几个TB每秒，那么临界算术强度大约在几百FLOP/B数量级。而大模型Transformer层的权重复用率特征，会导致实际算术强度常常落在几十到几百之间。一旦实际负载的算术强度低于芯片临界值，整个训练吞吐就会被显存带宽锁定，芯片算力再高也只能干瞪眼。
拿170B模型来说，即便用上张量并行，每个计算步骤都需要把大量权重和中间激活从HBM搬到计算单元。如果带宽不够，矩阵乘法单元的空闲率会很高，MFU（Model FLOPs Utilization，模型浮点利用率）直接掉到30%以下。昇腾960系列把显存容量和带宽同步抬升，本质是在解决这个“喂不饱”的问题。
所以，昇腾960单芯片真正值得关注的，不只是算力数字变大，而是显存容量是否足够承载更大模型副本、显存带宽是否能支撑更激进的批量大小。只有这两个指标一起涨，训练吞吐才会真正上涨。
2.3 昇腾960在单卡维度补齐了什么
从实际训练场景推断，昇腾960至少在三个单卡维度做了补强：显存容量、显存带宽、能效比。这三个维度直接决定了“一张卡能不能扛更重的活”，以及“一个超节点里能不能塞更多卡”。
显存容量的意义在于，有些中等规模模型可以直接做数据并行，每张卡完整存一份模型副本，不用把模型切得稀碎。显存带宽的意义在于，大批量训练时的吞吐上限更高。能效比的意义更实际：集群机柜的供电和散热是硬约束，能效比上不去，单卡算力再高也架不住大规模部署。
顺带提一句，如果你想验证这类单卡能力的差距，拿普通消费级显卡跑大模型训练也是可以做对比实验的。比如一些入门教程里用rx6750gre训练小模型，受制于显存和带宽，通常只能跑小参数量的微调，这个体验本身就是“存储墙”最直观的样本。昇腾960把容量和带宽拉高，就是要把这个墙往外推。
3. 超节点架构拆解：昇腾960凭什么把“机房变成一张卡”
3.1 Scale-out网络的天花板：为什么GPU越多越慢
先得说清楚传统大模型训练集群的麻烦在哪。标准的分布式训练集群，一般是一个节点内8张卡，通过PCIe或NVLink互联，节点和节点之间走以太网或IB（InfiniBand）。节点内的通信带宽能到几百GB/s甚至更高，但跨节点走网络后，单链路通常只有几十到几百Gb/s，时延也明显变差。
训练同步梯度时，通信量大致和模型参数量成正比。一个70B模型，每个step要同步的梯度数据是几十GB量级。如果拿一张卡跑一部分，所有卡最后都要做全局归约。网络带宽不够，通信时间就会随着卡数增加而快速膨胀。很多集群在几千卡规模下，通信可以占到整个训练耗时的50%以上，加卡不但不加速，反而变慢。
这就是Scale-out的天花板。堆节点数，能换来容量，但换不来持续增长的效率。传统解决思路是减少通信频率、增加计算量、用流水线把通信和计算叠起来，但这些都只是缓解，不是根治。
3.2 超节点的高带宽域：把张量并行的代价压到最低
昇腾960超节点的思路是换一条路：与其优化跨节点的Scale-out，不如先做一个超大规模的Scale-up域。把几十张昇腾960通过专用高速总线互联，让它们之间的通信带宽达到非常高的水平，时延也更低。这个域里跑集合通信，成本远低于跨节点网络。
对训练框架来说，这个域可以直接支撑更大的张量并行。以前受限于节点内8卡互联带宽，张量并行规模一般只能到8或者16。现在超节点内几十张卡都具备高带宽互联，张量并行维度可以拉到更大，单个Transformer层的权重切得更细，而通信代价却不像以前那样暴涨。对于稠密大模型和MoE模型，这等于打开了一扇以前关着的门。
MoE模型收益尤其明显。MoE训练中有大量的All-to-All通信，把专家分发到不同设备上时，如果跨节点走网络，通信会成为灾难；但如果在超节点的高带宽域内做专家并行，这个痛点基本被绕开了。昇腾960超节点这种“大域化”的设计，对MoE类大模型几乎可以算精准打击。
3.3 并行策略的新组合：DP/TP/PP如何重新分配
传统训练，大家默认的并行组合是“DP + TP + PP”：数据并行管复制模型副本，张量并行管切单层权重，流水线并行管按层切段。过去TP不敢开太大，因为跨节点通信扛不住；PP不敢开太浅，因为要让每个节点都有活干；DP开太多又会增加梯度同步压力。
昇腾960超节点改变的是这个三角关系。超节点内TP可以开大，PP可以缩短，DP可以跨超节点走。一个超节点内的卡可以先组成一个超大TP域，把模型一层的计算量完整消化；多个超节点之间再做数据并行或流水线并行，跨超节点的通信频率和通信量都能压下来。
从我接触过的训练框架经验来看，这种组合会让很多以前解得非常痛苦的调优工作大幅简化。以前MPI通信矩阵、拓扑亲和性、拥塞控制这些问题是训练性能工程师的噩梦，超节点把大域内的通信质量做大，剩下的网络通信都是跨超节点的低频操作，量级完全不一样。
4. 从工程实践看昇腾960超节点的真实价值
4.1 用训一个70B模型的时间账来对比
我给你算一笔非常粗略但方向正确的账。假设要训练一个70B参数的中等大模型，训练数据量大概4T token。按业界常用的估算公式，总计算量大约在1E24 FLOPs量级。
如果是一颗单卡算力很强的传统千卡集群，MFU可以做到40%左右，训练时间大约数以月计。但如果通信架构不给力，MFU掉到25%，训练时间直接翻倍。昇腾960超节点把域内通信成本降下来以后，MFU只要能多拉15到20个百分点，同样的训练任务，时间就是“几十天”对比“上百天”的差距。这在项目层面是决定性的。
当然，具体数字取决于模型大小、批量大小、并行策略和数据读取速度，但我见过太多团队辛辛苦苦堆卡，最后发现通信占了一半时间。昇腾960超节点最直接的价值，就是把这部分损耗大幅压缩，让芯片的算力真正变成有效算力。
4.2 MFU：比峰值算力更实在的指标
说到MFU，我觉得搞训练的人都该把它当成首要指标。MFU计算公式是：
训练总耗时的有效算力除以峰值算力。具体一点，就是看你的训练任务实际完成的浮点运算量，除以“峰值算力乘以总耗时”，得到一个百分比。
这个指标能一票否决很多“纸面漂亮”的硬件。峰值算力是卖点，MFU是真实使用价值。这些年我调过不少模型，峰值算力非常高的芯片，如果通信跟不上、算子库不全、显存带宽不足，MFU可能连30%都到不了。而昇腾960超节点在架构设计上是冲着“抬高MFU”去的，这种定位比单纯堆峰值数值得多。
再补一句：昇腾生态里的CANN库和MindSpore框架也在持续优化算子融合、通信算子实现，这也是直接影响MFU的因素。我看昇腾960超节点能不能成功，最关注的其实不是单芯片测试分数，而是它在真实大模型训练任务里的MFU能到多少。
4.3 运维视角：故障域和作业调度逻辑全变了
从训练平台运维的角度，超节点带来的是另一个层面的变化：故障域变大，作业调度逻辑也要变。
以前单卡故障，可能只需要把任务里的那一部分重调度；但超节点内部几十张卡是一个高带宽域，任何一个TP维度里的卡出了故障，整个超节点的训练都要暂停，影响面一下大了很多。所以昇腾960超节点这类架构，对可靠性要求更高，在线故障检测、热备切换、断点续训的自动化程度必须跟上。
调度也要更聪明。训练作业最好整集群地申请超节点资源，不要把一个作业的算力打散到不同超节点里。我们做平台化的时候，通常会把“节点亲和性”写得非常死，让一个大训练作业独占一个超节点，哪怕某些卡利用率暂时不高，也不能被打散。这些运营层面的变化，是昇腾960超节点带来的真实工程负担。
5. 想尝鲜昇腾超节点？迁移与选型的几条实在建议
5.1 先判断你的模型适不适合超节点架构
昇腾960超节点不是万能药，迁移前先做判断。
适合的典型场景有几类：超大稠密模型、MoE模型、需要长期大集群训练且通信占比高的场景。这些负载对Scale-up域的高带宽非常敏感，收益最大。
不太适合的情况也有：小规模推理、对延迟敏感的在线场景、只用数据并行微调中小模型、算子库覆盖不全的特殊结构。比如有些行业大模型，像证券金融领域做定制大模型时，往往会在基础模型上加很多自定义token格式和特殊训练目标。这类模型对第三方硬件平台算子覆盖和框架兼容性要求很高，如果昇腾生态还没覆盖到，迁移成本可能超出预期。
我的建议很实在：先用小模型、小数据量在昇腾平台上跑通一条完整链路，观察算子覆盖和通信行为，再决定要不要把核心训练任务迁过去。不要拿一个万亿参数模型直接赌迁移。
5.2 从PyTorch到CANN的迁移踩坑记录
昇腾平台和CUDA生态确实有一些迁移成本，特别是你习惯了NCCL、Apex、FlashAttention这些工具时。昇腾的对应层是HCCL、CANN算子库，虽然API设计尽量对齐，但实际使用中还是有一些坑。
第一类坑是算子兼容。PyTorch模型里经常会隐藏一些冷门算子，到了昇腾上找不到对实现，只能手写或用替代算子。我的建议是先做一个全量算子扫描，把不支持的算子列出来，分清哪些需要替代、哪些需要重构。第二类坑是分布式通信。NCCL的用法和HCCL大体相似，但超节点架构下的通信拓扑和默认组网方式不一样，需要专门做拓扑感知配置，否则通信模式可能不是最优。
第三类坑是混合精度细节。BF16的支持范围和自定义算子是否真的跑在BF16下，都要实测验证，不能用肉眼判断“好像没报错”。整体迁移策略上，我会坚持“先单卡、再单机、再超节点”的节奏，每往前推一步都要跑一遍基准测试和diff校验。
5.3 给团队选型的三个实操建议
第一，把基准测试做在前面。不要只看芯片标称参数，准备一个接近自己真实业务形态的模型，在昇腾960平台和现有CUDA平台各跑一次，记录MFU、训练吞吐、崩溃率。数据说话。
第二，留好兼容层。团队主力如果都是PyTorch工程师，尽量选择昇腾的PyTorch适配层方案，让团队用熟悉的上层接口开发，底层再慢慢下沉到CANN。这样前期迁移阻力更小，也避免技术栈被改得面目全非。
第三，重视团队学习成本。昇腾的调试工具、性能分析工具和CUDA生态不同，团队需要时间适应。给训练组留出1到2个月的熟悉周期，不要一上来就定死上线时间。我在实际项目里吃过这种亏，硬件到位但团队不熟，最后卡在优化阶段，比预期多花了很多时间。
昇腾960超节点是一个值得认真评估的方向，但选型从来不是看发布会参数，而是看你能不能把自己的模型跑得快、跑得稳。这个判断只能靠自己的实验和数据来做。
