华为灵衢互联架构与昇腾960超节点发布：企业如何评估10万卡集群的互联收益与落地成本？

【软盟资讯·新闻导读】华为近期公开灵衢互联架构与昇腾960超节点，并称10万卡集群MFU可由20%提升至35%。这不是单颗芯片性能的简单比较，而是对超节点组织、集群通信、调度和数据中心交付能力的系统性考验。企业采购时，应先验证指标边界，再核算软件适配、网络存储、供电散热与长期运维成本。

先看真实瓶颈：大模型集群不只是“卡越多越快”

当训练任务从数百张或数千张加速卡扩展到更大规模时，系统瓶颈往往不再是单颗芯片的峰值算力，而是计算、通信、存储和调度之间的失配。

一次大模型训练通常需要频繁进行参数同步、梯度聚合、专家路由和检查点读写。加速卡在等待通信时，即使理论算力很高，也可能无法持续执行有效计算。集群规模越大，通信路径越复杂，链路拥塞、同步等待、任务负载不均和故障恢复都会放大。

因此，企业理解“10万卡集群MFU从20%提升至35%”时，不能把它理解为芯片算力提升了75%，也不能直接换算成业务吞吐量提升75%。它更接近于一个系统级效率指标，反映的是理论浮点能力中有多少被有效用于模型计算。

灵衢互联解决的是什么问题

从公开信息看，灵衢互联的定位不是单一交换设备或普通服务器内部总线，而是面向超节点和大规模集群协同的互联架构。华为将其描述为连接计算资源、组织超节点并扩展集群规模的基础能力。

从采购和架构评估角度，可以将其拆成三个层次：

柜内或节点内互联

这一层关注多个AI处理器如何组成一个相对紧密的计算单元。目标是降低处理器之间交换数据的开销，让并行训练或推理任务尽量在高带宽、低时延的域内完成。

这决定了一个超节点是否只是“多张卡放在一起”，还是能够被软件作为一个更完整的计算资源池使用。对于模型并行、张量并行和专家并行任务，节点内部的通信效率会直接影响任务切分方式。

超节点之间的互联

超节点并不是大规模集群的终点。模型规模继续扩大后，多个超节点需要协同工作。此时，互联架构要处理跨节点参数同步、专家流量、任务迁移和故障隔离。

公开报道提到，昇腾960超节点以灵衢UnifiedBus和Hi-ONE等技术为核心，并面向更大规模的处理器互联。不过，企业不应仅根据媒体摘要中的规模数字判断交付能力，仍需要求供应商提供正式规格、拓扑图、链路带宽、拥塞控制方式和实测数据。

集群级资源组织

集群级互联更接近数据中心基础设施问题。它需要把计算、网络、存储和调度系统统一起来，支持大规模任务的编排与故障处理。

这意味着采购对象不应只是“超节点服务器”，而应当是包含以下内容的整体方案：

• 计算节点和超节点硬件；
• 集群互联设备与光互联组件；
• AI框架、通信库和算子适配；
• 作业调度、资源隔离与监控系统；
• 高性能存储和检查点服务；
• 供电、散热、机房空间及交付工程；
• 备件、升级、驻场和故障响应能力。

昇腾960超节点的技术定位

昇腾960超节点的价值，不能只用“新一代AI芯片”来描述。其核心定位是把多个AI处理器组织成一个更大、更紧密的计算单元，再通过集群互联扩展到更大规模。

这种组织方式会改变传统算力采购的基本单位。

过去，企业可能主要比较单卡算力、显存容量、服务器数量和单机价格。超节点模式下，还需要比较：

1. 一个超节点能够承载哪些并行模式；
2. 超节点内部通信是否足以支撑目标模型；
3. 多超节点扩展时性能衰减如何；
4. 任务调度是否能够识别不同通信域；
5. 单个部件故障是否会导致整个超节点下线；
6. 软件升级是否需要整机或整柜协同进行。

公开资料还提到NPO等近封装光学方向，但目前给出的搜索信息并未完整呈现昇腾960超节点的正式产品规格、交付配置、功耗参数和价格。因此，企业不应将媒体报道中的峰值规模、时延或参数规模支持能力直接写入采购承诺，必须以厂商技术白皮书、测试报告和合同附件为准。

如何理解“10万卡集群MFU从20%提升至35%”

MFU通常用于衡量模型训练过程中，实际有效浮点计算与理论峰值浮点能力之间的关系。一个简化表达可以是：

MFU ≈ 有效模型计算量 ÷ 理论峰值计算能力

但在实际项目中，MFU的统计口径可能受到模型结构、序列长度、并行策略、数据类型、通信占比、批大小、检查点频率和测量窗口影响。

因此，20%提升至35%至少需要回答以下问题：

测试对象是什么

需要明确是单个超节点、多个超节点，还是完整的10万卡集群。不同规模下，通信开销和故障概率差异很大，不能用小规模测试结果替代大规模测试。

使用了什么模型和训练配置

稠密模型、混合专家模型和长上下文模型的通信模式不同。训练和推理也不能混为一谈。相同硬件在不同模型、不同并行策略下，MFU可能出现明显变化。

理论峰值如何计算

需要说明采用哪种数据精度、是否包含稀疏计算、理论峰值按芯片峰值还是系统可用峰值计算。若分母口径不同，两个MFU数字就不具备直接可比性。

测量窗口是否包含非计算环节

数据加载、通信等待、检查点保存、故障恢复和资源调度是否纳入测量，都会影响结果。企业还应要求提供稳定运行时间，而不是只看某个短时间窗口内的峰值。

35%能否外推到业务吞吐

不能直接外推。MFU提升通常意味着系统有效计算比例提高，但实际训练完成时间还取决于：

• 每步训练的通信量；
• 数据管道是否供得上；
• 存储读写是否形成瓶颈；
• 模型并行与流水线并行配置；
• 作业排队和资源碎片；
• 故障重试与检查点恢复时间；
• 软件栈是否完成针对性优化。

企业采购应建立五维评估框架

1. 性能：看规模扩展曲线，而不是单点峰值

建议供应商提供从单节点、单超节点到多超节点的分段测试结果，重点关注弱扩展和强扩展表现。

需要记录：

• MFU随集群规模增加的变化；
• 每步训练耗时和有效吞吐；
• 通信占总执行时间的比例；
• 网络拥塞和尾部时延；
• 作业启动、暂停和恢复时间；
• 节点数量增加后的性能衰减。

如果性能只在固定规模下展示，而没有扩展曲线，企业很难判断其对10万卡级任务的实际价值。

2. 兼容性：确认现有软件资产能否迁移

昇腾960超节点能否落地，关键不只在硬件本身，还在软件生态和迁移工作量。

采购前应逐项核对：

• 主流深度学习框架是否支持目标版本；
• 现有模型算子是否需要重写；
• 混合精度、分布式训练和推理服务是否稳定；
• 通信库是否支持目标并行策略；
• 编译器、运行时和驱动的版本耦合关系；
• 容器、镜像、日志和监控体系能否延续；
• 是否存在厂商专用接口导致迁移锁定。

对于已有GPU或其他加速卡环境的企业，还应将模型迁移、算子适配、测试回归和开发人员培训纳入预算，而不能只计算硬件采购价。

3. 部署复杂度：超节点规模越大，工程要求越高

大规模AI基础设施对机房工程提出更高要求。评估时至少要核算：

• 单柜功率和机房总供电容量；
• 制冷方式及冗余设计；
• 光纤布线距离、密度和维护空间；
• 网络设备、光模块和备件配置；
• 机柜承重、消防和动环监控；
• 分期建设时的扩容方式；
• 断电、链路故障和节点故障下的恢复路径。

如果企业无法一次性建设完整规模，应优先确认系统是否支持分阶段扩容，以及新增超节点后是否需要重构网络、调度和存储。

4. 运维能力：从“设备可用”转向“任务可恢复”

超大规模集群不可避免会遇到硬件、链路、软件和任务层面的异常。运维评估应从设备在线率扩展到作业恢复能力。

建议要求供应商说明：

• 故障检测和定位所需时间；
• 是否支持故障节点隔离；
• 任务是否能够自动重试或迁移；
• 检查点保存和恢复耗时；
• 软硬件版本升级是否支持灰度；
• 是否有统一的指标、日志和链路追踪；
• 服务等级协议如何覆盖超节点、网络和软件栈。

对训练型企业而言，缩短一次故障后的恢复时间，可能比追求更高的理论峰值更有价值。

5. 成本：用总拥有成本替代采购价

10万卡级别的方案，硬件价格只是成本的一部分。建议以三到五年为周期建立总拥有成本模型：

成本项目	重点核算内容
计算硬件	超节点、处理器、服务器、机柜及备件
网络互联	交换设备、光模块、光纤、控制器和备件
存储系统	训练数据、检查点、缓存和备份容量
数据中心	供电、制冷、机房改造、托管和能耗
软件与服务	许可、适配、驻场、升级和技术支持
人员投入	平台开发、模型迁移、运维和安全团队
机会成本	扩容周期、迁移停机和资源闲置

最终应计算“每个有效训练样本的成本”“每个有效推理请求的成本”或“单位时间可交付算力”，而不是只比较每张卡的采购价格。

训练、推理和算力服务，适用重点并不相同

大模型训练

如果企业的主要任务是大规模预训练，互联架构和超节点组织方式可能具有更高价值。训练任务通常对同步通信、并行效率和长时间稳定运行更敏感。

但前提是企业拥有足够大的连续任务规模，且模型、框架和算子已经完成适配。若训练任务规模较小，超节点的通信优势可能无法覆盖其部署和运维成本。

大规模推理

推理场景需要区分在线推理、批量推理和长上下文推理。在线业务更关注时延、弹性和故障隔离，批量推理更关注吞吐和资源利用率。

企业应重点测试首Token时延、每秒输出Token数、并发增长曲线、显存或内存占用、模型切换时间和服务降级能力。不能仅用训练MFU替代推理服务指标。

算力服务和公共算力平台

算力服务商需要关注多租户隔离、资源切分、计量计费和任务排队。大规模超节点如果只能以整块资源交付，可能造成中小任务资源浪费。

因此，算力服务场景应验证：

• 超节点能否进行合理的资源切分；
• 不同租户之间是否存在通信干扰；
• 调度器能否识别拓扑和亲和性；
• 是否支持优先级、配额和抢占；
• 故障是否会扩大到多个租户；
• 计量口径能否反映真实有效算力。

一份可执行的PoC验证清单

企业在签订大额采购合同前，可以将验证分为四个阶段。

第一阶段：资料核验

要求供应商提交正式技术资料，至少包括产品规格、互联拓扑、软件版本、支持模型、功耗散热、扩展边界、服务等级和保修条件。

同时，区分“已商用能力”“计划交付能力”和“路线图能力”，避免把未来功能当成当前交付承诺。

第二阶段：模型适配

选择企业真实业务中的代表性模型，而不是只使用演示模型。测试模型应覆盖目标参数规模、上下文长度、并行方式和典型算子。

记录迁移代码量、适配周期、精度变化、训练稳定性和推理结果一致性。

第三阶段：规模扩展

至少进行多档规模测试，观察计算、通信、存储和调度随节点数量变化的趋势。测试时应保留原始日志和配置，明确MFU、吞吐、时延和故障率的统计口径。

第四阶段：故障与运维演练

主动模拟链路中断、节点下线、存储抖动、驱动异常和任务中断，测试告警、隔离、重试和恢复能力。

如果方案只能在无故障环境下达到目标指标，就不能视为适合生产环境。

结论：先验证系统收益，再决定集群规模

灵衢互联架构和昇腾960超节点所代表的方向，是把AI基础设施的竞争从单芯片性能推进到“超节点加集群”的系统工程竞争。其潜在价值在于，通过更紧密的互联和更统一的资源组织，降低大规模模型训练中的通信等待与调度损耗。

但“10万卡集群MFU从20%提升至35%”应被视为需要核验的系统级公开指标，而不是企业可以直接复制的经营结果。它的适用条件、模型配置、测试规模和统计口径必须明确；对于不同模型、不同软件栈和不同数据中心环境，也不能简单外推。

对企业而言，合理的决策顺序应是：先明确训练、推理或算力服务目标，再验证真实模型和多档集群规模，随后核算迁移成本、机房改造、软件服务和长期运维，最后才确定采购数量。只有当性能收益能够覆盖兼容性和部署复杂度，超节点方案才具备实际落地价值。

【软盟观察】

华为此次发布释放出的信号，是AI算力基础设施正在从“买更多加速卡”转向“组织更高效的计算系统”。在大规模模型时代，互联、存储、调度和运维的重要性确实会持续上升，单纯比较芯片峰值参数已经不足以支撑企业采购决策。

不过，公开发布阶段的指标仍然需要经过第三方或企业自有场景验证。尤其是10万卡集群MFU这一表述，必须结合模型、数据精度、并行方式和测试周期理解，不能直接等同于业务收入、训练速度或单位算力成本的同比改善。对采购者来说，最稳妥的方式不是追逐最大集群规模，而是先用真实模型完成可重复的PoC，再以有效吞吐、故障恢复时间和三到五年总拥有成本作为合同验收依据。