华为创造AI算力新纪录：万卡集群训练98%可用度，秒级恢复、分钟诊断

十三
2025-06-10
13:38:23

来源：量子位

金磊 发自 凹非寺

量子位 | 公众号 QbitAI

大模型的落地能力，核心在于性能的稳定输出，而性能稳定的底层支撑，是强大的算力集群。其中，构建万卡级算力集群，已成为全球公认的顶尖技术挑战。

但是，在华为，昇腾万卡算力集群，已经可以做到近乎“永不罢工”了：

• 训练可用度达98%：这就好比你开着一辆车，全年365天里，有358天无论刮风下雨都能一脚油门就出发，从不掉链子，有问题可以随时检修，几乎不会耽误你的任何行程。
• 线性度超95%：比如用1000台算力卡干活比用100台快9.5倍以上，叠加更多算力，训练速度近似等比提升，不浪费资源。
• 秒级恢复、分钟级诊断：不论训练还是推理，故障后几秒钟就可恢复；几分钟内定位到具体是哪台机器、哪个部件出问题。

或许有小伙伴要问了：AI算力需要如此24小时不间断的运作吗？

答案是肯定的，需要，且有必要。

因为小到我们用手机导个航，背后都会有几十个AI模型在发力来分析路况、预测拥堵；再如医院用AI辅助诊断癌症，系统得在瞬间处理掉成百上千的CT照片。

这些看似简单的智能应用，其实都离不开如 “超级大脑” 般的AI算力集群，需要它们全天候不停歇地运转着。

而要保证有这样的能力，高训练可用度、高线性度、快速消除故障，就相当于给AI发动机上了一份强有力的保险。

更严格来说，AI推理的可用度甚至还需要达到99.95%的程度。

那么华为又是如何做到这点的？

关于这一切背后的秘密，华为在今天首次把技术给公开了出来。

高可用的核心：三套“智能保险系统”

AI大集群出问题时，定位故障特别麻烦；毕竟系统规模庞大，软件和硬件组成的技术栈错综复杂，而且调用链条还很长。

要解决问题，首先得确定故障出在哪个大的领域，接着再在这个领域内部一步步排查，确定具体的故障位置。在整个故障诊断过程中，面临的挑战非常大。

以往技术人员进行故障定位时，短则需数小时，长则可能耗时数天。这一过程不仅对技术人员的专业技能要求颇高，且往往难以快速锁定故障设备及根本原因。

为此，华为团队针对AI大集群面临的复杂挑战，构建了三大基础能力。

首先是全栈可观测能力。

它像是给集群装了一套“火眼金睛”监控系统（故障感知），主要包含这几部分：

• 集群运行视图：实时查看集群整体运行状态，哪里 “卡壳” 一目了然；
• 告警视图：哪里出问题了，系统会主动 “打报告”，快速发出警报；
• 网络链路监控：盯着网络连接的 “血管”，确保数据传输顺畅；
• 告警接入和配置：统一管理各种警报信息，还能根据需求灵活设置提醒规则；
• 网络流可观测能力：追踪数据在网络中的 “流动轨迹”，哪里堵了马上能发现。

同时，华为还拿出了一套 “故障诊断组合拳”，包含四大核心能力：

1. 全栈故障模式库：就像一本 “故障字典”，收录了各种可能的问题模式，方便快速对照排查；
2. 跨域故障诊断：不管故障藏在哪个 “领域”（软件、硬件、网络等），都能跨区域 “联合破案”；
3. 计算节点故障诊断：精准定位计算单元（比如服务器）的具体问题，揪出 “罢工” 的节点；
4. 网络故障诊断：专门对付网络里的 “疑难杂症”，比如断网、延迟高、链路异常等。

这套组合拳让集群故障诊断更高效，就像给工程师配了 “智能侦探工具”，大大缩短了找问题的时间。

最后，是一套“钢铁韧带”自愈系统（容错设计）。

想要把超平面网络的厉害之处完全发挥出来，超节点的规模就得足够大。不过到现在，还没有哪个团队能用光链路搭建超节点并成功的。

于是，华为团队就琢磨出一套超节点光链路软件容错的好办法。

这套办法就像给超节点穿上了好几层 “防护铠甲”，用上 “超时代答”“绿色通道” 这些关键技术后，超节点基本不会出现大故障。

同时，又通过链路级重传、光模块动态调整Lane、重新执行HCCL算子、借轨通信、双层路由快速恢复、Step级重新调度等技术，让超节点对光模块突然中断这类故障的承受能力变得超强，能容忍超过99%的光模块闪断情况。

哪怕超节点里的光模块数量一下子增加了10倍还多，依靠软件提升可靠性的手段，再配合光链路压力测试技术，光模块闪断的概率能降低到和传统电链路差不多的水平，稳稳保障超平面网络不出问题。

而且，华为团队还打造出Step级重调度能力，以前遇到频繁的 HBM 多比特 ECC 故障，修复可能要花很长时间，现在1分钟内就能搞定，用户因为故障损失的算力也减少了5%，实实在在地省下了不少 “计算力”。

计算卡再多，也不影响效率

线性度指标，简单来说就是看算力卡数量增加后，训练任务的速度或效率能提高多少（比如完成时间缩短的比例）。

举个例子：如果算力卡增加2倍，训练速度也能接近2倍，说明线性度高；如果速度只提高1.2倍，就说明线性度差，资源没被充分利用。

为了让训练效率随着算力卡增多而 “更成正比地提升”，华为团队研发了四项关键技术：

1. TACO（拓扑感知的协同编排技术）：就像给算力卡 “排兵布阵”，根据硬件连接结构（比如网络拓扑）智能分配任务，避免 “通信堵车”。
2. NSF（网络级网存算融合技术）：把网络传输、数据存储和计算能力 “打包优化”，让数据在算力卡之间流动更顺畅，减少等待时间。
3. NB（拓扑感知的层次化集合通信技术）：针对大规模集群设计 “分层通信策略”，比如让同一区域的算力卡先快速协作，再跨区域同步，提升整体通信效率。
4. AICT（无侵入通信跨层测量与诊断技术）：不干扰正常训练的前提下，实时 “监控” 通信链路，快速发现哪里 “卡顿” 并修复，确保数据传输稳定。

通过这四项技术，华为让Pangu大模型的训练线性度（即效率随算力卡增加的提升比例）明显提高。

整体方案的思路大概如下图所示：

实验及理论分析结果显示，训练Pangu Ultra 135B稠密模型时，4K卡Atlas 800T A2集群相比256卡基线，线性度为96%。

训练Pangu Ultra MoE 718B稀疏模型时，8K卡Atlas 800T A2集群相比512卡基线，线性度95.05%；4K卡CloudMatrix 集群相比256卡基线，线性度96.48%。

具备秒级恢复的能力

在大规模AI集群运行时，经常会因为各种硬件或软件故障，导致训练任务突然中断。

目前行业里常用的办法是，在训练过程中定期保存 “进度存档”（CKPT），等故障修复后从存档点继续训练。

华为则凭借软硬件全方面的技术创新，打造了一套 “分层分级” 的训练任务故障快速恢复系统。

简单来说，就是针对不同类型、不同程度的故障，制定了对应的 “快速重启方案”，让训练任务能更快 “续上”。

不同层级的故障恢复能力可以参考下面这张图：

除此之外，华为采用了一系列提速 “黑科技”：比如优化数据集查找速度、缓存模型编译结果、加快通信链路建立、提升训练进度保存效率。

这些技术效果显著：如果是万卡规模的超大型集群，从故障中恢复训练，10分钟内就能搞定；要是用 “进程级重调度恢复” 方法，3分钟内就能接着训练；要是用更厉害的 “进程级在线恢复”，30秒就能重新开始训练。

而且，不管集群规模有多大，模型有多复杂，恢复时间基本不受影响，还能把因为故障导致的训练进度倒退时间，压缩到一次训练循环的时长。

这么一来，AI集群能用的时间大大增加，大模型训练的效率也快了很多。

在训练阶段后的推理，也有诸多问题亟待解决。

当千亿级MoE模型不断升级，模型部署的网络结构也跟着变了。以前单机8卡就足够跑一个推理实例，如今，大EP模型架构下，需要数十乃至上百张卡才能支撑推理运行。

但新架构带来个麻烦：用的设备越多，出故障的可能性就越大，而且一旦有问题，影响的范围会特别广。

只要有一个硬件出故障，整个Decode实例（可以理解成模型运行的一个 “小团队”）就没法工作了，直接导致AI推理业务出问题，严重的话整个业务都会停摆。

为了解决大EP推理架构容易出故障的难题，华为团队想出了一个分三步的 “保险计划”：

• 第一步是实例间切换，就像给业务准备了 “备用团队”，一个实例不行了，马上换另一个顶上；
• 第二步是实例内重启恢复，发现实例里有问题，快速重启内部程序，让它重新正常工作；
• 第三步是实例内无损恢复，即使出故障也不丢失数据，在不影响业务的情况下修复问题。

这三步方案需要芯片驱动、框架软件、平台系统各个层面紧密配合，组成一套完整的 “防护网”。遇到不同类型的故障，就用最合适的恢复方法，尽可能减少对用户的影响，让AI推理业务稳稳运行。

在实例内重启恢复技术中，通过构建带内快速故障感知和重调度机制，搭配参数权重预热和镜像预热技术，能把实例内部的重启恢复时间压缩到5分钟以内。

还有一项很厉害的TOKEN级重试技术，当遇到HBM KV Cache故障时，从故障发生到重新输出Token的整个恢复过程不到10秒。

对比业界通常需要10分钟才能恢复实例的情况，这项技术能将故障带来的影响降低60倍，几乎让用户感觉不到故障发生，极大提升了系统的稳定性和用户体验。

总结来看，针对AI算力集群的高可用性，华为团队创新性提出了“3+3”双维度技术体系，即故障感知诊断、故障管理、集群光链路容错等三大基础能力，以及集群线性度、训练快恢、推理快恢等三大业务支撑能力。

这六大创新均带来了非常可观的收益，比如万卡集群训练可用度达到98%、集群训推最快达到秒级快恢、集群线性度达到95%+、千种故障模式库与分钟级故障诊断等。

技术报告地址：

https://gitcode.com/ascend-tribe/ascend-cluster-infra/blob/main/HighAvailability/ascend-cluster-infra-ha.md

Read More