可用性

3 秒看懂

可用性（Availability） 衡量分布式 AI 系统在任意时刻能被正常访问并按时完成计算任务的概率。在千卡 GPU 训练集群中，它通常体现为“全年真正干活的时间比例”。可用性不等同于“数据不丢”（那是可靠性），也不等于“坏了修得快”（那是可维护性），而是三者在工程上融合的结果：A = MTBF / (MTBF + MTTR)，即平均无故障时间与（无故障+修复时间）之比。一次小时级的训练中断，可能导致数十万乃至上百万美元的算力浪费，并将模型收敛延后数天。正因如此，可用性已从运维指标，上升为 AI 资本回报率的直接支撑点。

3 分钟产业解释

深度学习基础设施已经从“单机跑脚本”演进为万卡级异构并行系统，可用性的内涵也层层叠加：

• 硬件层面：GPU 显存中可纠正错误（CE）和不可纠正错误（UE）、NVLink/InfiniBand/RoCE 链路抖动、光模块失效、电源波动等，任何一点异常都可能通过同步通信放大为全局中断。
• 软件层面：CUDA OOM、通信死锁、调度器误驱逐、检查点保存与恢复的额外耗时，会直接拉低有效训练时间和吞吐。
• 运维层面：训练任务可用性 ＝（计划运行时长 − 故障中断时长 − 恢复耗时）÷ 计划时长。随着集群规模扩大，单点故障率呈乘数级上升，将可用性从 99% 提升到 99.9% 所需的工程投入常常指数级增加。

产业界据此拆解出两类目标：训练环节追求作业级高可用——允许秒到分钟级中断、自动恢复，侧重任务完成率；推理服务环节则追求服务级高可用——99.95% 以上 SLA、毫秒级切换与无感自愈。两者的技术路径几乎完全不同，前者的“状态重载”是核心难题，后者更依赖冗余路由和负载均衡。

技术原理

可用性的深层机制，是在庞大规模的并行系统中，建立故障隔离、检测与恢复的闭环，并尽力缩短这一闭环的每一段耗时。以下以千卡训练集群为例说明故障处理流：

1. 故障发生：某 GPU 出现显存 CE 错误超过阈值，或 NVLink CRC 误码率急剧升高。
2. 检测：NCCL 通信超时、DCGM 健康监测或节点带外管理模块捕捉到异常，将节点标记为 UNHEALTHY。心跳间隔通常设于 50 ms~500 ms；过短会消耗大量带宽，过长则拖长检测窗口。
3. 阻断传播：训练框架通过全局屏障或心跳广播故障信息，阻止错误梯度通过 AllReduce 污染所有副本。关键参数包括 NCCL 超时（如 NCCL_IB_TIMEOUT），设置不当会导致整组挂死或误杀。
4. 状态回滚：调度器决定回退到最近一次一致性检查点。检查点间隔决定了 RPO（恢复点目标：可能丢失的进度窗口），从数十秒到数十分钟不等。部分框架已利用分片快照实现秒级 RPO。
5. 动态资源重组：剔除故障节点的 GPU/节点，网络拓扑自动重协商，重新分配通信环。弹性训练逻辑（如 DeepSpeed、Megatron 的容错模式）允许单节点甚至单 GPU 粒度地退出和加入。
6. 作业接续：从检查点加载模型与优化器状态，继续训练。RTO（恢复时间目标）涵盖节点重调度+模型加载+网络重协商，业界顶尖水平在分钟级。

在此基础上，还有两种复杂的失效模式必须考虑：

• 关联故障：单颗 GPU 的 CE 错误若未及时屏蔽，通过梯度同步扩散至所有副本，导致整步计算失败，且故障根源极难定位。
• 落后者放大：分布式同步训练中，某个节点因散热降频或链路抖动而减速，全集群均需等待该“落后者”，导致集体吞吐急剧劣化，等效于可用性下降。此时需要系统能够自动识别并隔离慢节点（准故障），而非索性将整个作业标记为失败。

因此，现代训练系统的可用性架构强调柔韧性降级：即使存在若干劣化节点，集群依然能“带伤运行”，并将有效吞吐维持在较高水平。推理端则采用冗余+负载均衡的金字塔模式：入口网关进行健康检查与剔核，后端多副本扇出请求以隐藏尾延迟，模型热更新采用蓝绿部署或滚动发布以避免中断。

关键参数

评估和约束可用性，需要一系列量化指标，不同层级关注重点各异。

1. 可用性百分比（或“任务成功率”） 传统云服务习惯用“99.95%”（年停机约 4.38 小时）衡量。但对训练集群，更直接的是作业成功率，即能够顺利运行至计划 checkpoint 或收敛的任务占比。万卡规模下，即便基础设施可用性高达 99.9%，作业成功率仍可能仅约 85%~95%（2023 年产业界共同体估算，无统一官方数字）。

2. MTBF（平均无故障时间）
   GPU 单卡 MTBF 可达数万小时，但乘以千卡、万卡后，系统级 MTBF 骤降至数小时甚至更短。据部分云厂商在 2022 年技术大会分享，数千 GPU 的训练作业，平均无故障间隔在 2~8 小时区间（具体数字因集群硬件代际、散热方案差异显著，公开资料未见详细基准）。

3. MTTR（平均修复时间）
   包含故障检测（秒级）、隔离与资源重调度（分钟级）、模型加载与状态恢复（分钟级）。头部团队可通过预取检查点、热备节点等手段将 MTTR 压缩至 25 分钟，一般大规模训练集群则常在 1030 分钟。

4. RPO / RTO（恢复点/时间目标）
   RPO 即允许丢失的最大数据/训练进度窗口，等于检查点保存间隔。异步分布式快照可将 RPO 控制在秒级（如 30 秒），但对存储与网络带宽有极高要求。RTO 为从故障发生到完全恢复服务的时间，指标已见前述。

5. 有效训练时间占比（Goodput Ratio）
   实际计算时间 ÷ 总挂载时间，剔除检查点开销、通信等待、故障恢复等。业界顶级集群可超过 90%，但多数万卡训练项目在 70%~85% 之间（基于 2023 年行业分享与供应链估算，并无官方精准统计）。

6. 慢节点比例
   因降频、散热不足或链路抖动导致的隐性性能杀手。一般通过比照每步迭代的 p99 延迟与中位数比例来探测，超过设定阈值（如 1.5×~2×）即触发隔离。这项参数直接关系到“可用但不达标”的资源损失。

7. 心跳间隔与故障检测窗口
   心跳间隔决定故障检测的速度下限，常在 50 ms~500 ms 之间。通信库的超时配置（如 NCCL 的 NCCL_IB_TIMEOUT）则影响错误传播窗口：过大导致全集群 hang 住；过小则可能误杀瞬时抖动节点。

8. 计划内停机频率与时长
   固件升级、驱动更新、网络拓扑调整等计划内活动虽不被计入故障，但同样侵蚀训练效率。智算中心 SLA 中通常会区分“基础设施可用性”和“工作负载可用性”，后者扣除计划内停机的影响。

需要说明的是，上述部分绝对值（如集群 MTBF、有效时间占比的真实分布）多为产业界在技术会议上的口头分享或供应链估算，尚未见统一的独立第三方报告或官方财报披露。阅读时应视为经验区间，而非精确标尺。

技术路线

围绕 AI 可用性的技术路线，目前清晰分化为三大方向：传统无状态高可用、训练有状态高可用、推理服务高可用。

训练端正从被动容错向主动预测演进：利用 DCGM、GPU 串行号级别的故障预判信号，在节点完全失效前将其驱逐并替换。同时，非同步优化（如减少全局屏障依赖的分层同步、延迟同步）开始部分缓解“落后者”放大问题，但尚未成为主流。推理端则逐步引入异构资源池、跨 Zone 容灾和请求级重放，以支撑 99.99% 级别的 SLO。

需要指出，表格中提到的具体产品/项目名称为基于公开资料的典型举例，并非完整或官方的路线定义，仅用以说明技术趋势分野。

上游

可用性的物理根基来自上游硬件、网络、供电及散热设施的可靠性。

• GPU/加速器：显存 ECC 与行重映射、硅互联冗余、电源管理固件中的 predictive failure 告警（如 NVIDIA Xid 错误分类、page retirement 引擎），是单点故障检测的第一道防线。行业趋势是将更多的可靠性诊断集成进 GPU 带外管理通道。
• 网络芯片与光模块：InfiniBand 交换机、RoCE v2 网卡、硅光模块的比特误码率（BER）和前向纠错（FEC）能力，直接决定了同步通信的“干净”程度。Broadcom、NVIDIA（Mellanox）等厂商持续提升端口级自动关闭、自适应路由和冗余拓扑支持。
• 服务器与互连：NVSwitch、PCIe Retimer、背板信号完整性，构成机内/机间通信的物理层。任何接触不良或信号退化都可能表现为间歇性故障，加剧可用性下降。
• 电源与散热：不间断电源（UPS）、动态电压频率调节、液冷均温性（冷板/浸没）等，既影响故障率（高温下电子迁移加速），也影响性能一致性（降频导致慢节点）。电源异常是导致整个机架乃至多机架同时中断的主要因素之一。
• 基础软件：OFED 驱动、NCCL 通信库、PyTorch/TensorFlow 框架中的错误处理路径，同样属于上游生态。这些软件的可靠性补丁和配置建议（如 RoCE 的 PFC 死锁避免）直接决定上层容错策略的效果。

上游供应商将可靠性特性封装为可配置的管理接口和策略，供中游训练调度与监控系统调用。例如，GPU 的带外故障信号需要透传至调度器，结合训练框架的预迁移逻辑，才能将 MTTR 真正压到秒级。

下游

可用性的最终价值在下游应用中兑现，关键下游包括：

• MaaS（模型即服务）平台：提供推理 API 的厂商（如 OpenAI、Anthropic、国内基础模型创业公司）将可用性写入商业化 SLA。一旦推理 API 可用性低于 99.9%，将直接触发违约赔付或客户流失。
• 内部 AI 研发平台：大型科技企业的内部训练平台、标注与评测流水线，以“训练任务失败率”“模型迭代周期”作为核心研发效能指标。更低的故障恢复耗时意味着更快的实验周转，直接影响模型上线的时效竞争力。
• 终端业务应用：Chatbot、代码助手、推荐系统、搜索等产品，其用户体验强烈依赖后端推理的可用性。一次 10 秒的不可用就会造成明显的用户感知，而训练端的中断如果延迟了关键模型的发布，则转化为商业机会成本。
• 行业智算中心客户：政府实验室、科研机构、高校等租用大规模 GPU 集群，对“任务中断恢复时间 ≤ X 分钟”有刚性需求，并将其纳入采购招标条款。2023 年以来，部分招标文件已明确将可用性保障作为与裸算力同等重要的评分项（基于公开采购公告摘要）。

下游客户对可用性的具体要求和考核方式日趋细化，推动智算服务商将可用性从后台技术指标升维为前台商务承诺。这也反向要求整条产业链在可用性上的投入能够被量化和对外展示。

受益公司

需要特别注意：本节仅从产业分工角度说明哪些类型的公司在“高可用性 AI 基础设施”趋势下获得业务受益，不构成任何投资建议，亦不暗示值得买入或卖出。

• 芯片设计企业：NVIDIA、AMD、Intel 等 GPU/加速器厂商通过内置可靠性引擎（如 ECC 增强、故障预测、page retirement）来提升整卡溢价，并将“硅基可靠性”作为新一代产品的关键卖点。网络芯片供应商（如 Broadcom、NVIDIA Networking）受益于高端交换机与自适应路由方案需求。
• 云服务与超大规模平台：AWS、Microsoft Azure、阿里云、华为云、火山引擎等，其 AI 训练平台的高可用性 SLA 是争夺头部大模型客户的关键差异点。这些企业通常自研容错调度器、检查点加速方案，并将其作为平台核心竞争力包装为增值服务。
• 训练与推理框架维护者：PyTorch、DeepSpeed、Megatron、vLLM、Triton 等开源社区及背后商业支持实体，通过强化弹性训练、异步快照和推理冗余，间接巩固自身在开源生态中的影响力，部分公司则以托管服务或企业版形式变现。
• 专用基础设施创业公司：一批聚焦检查点加速（高速存储层）、故障预测与可观测性（AI4Infra）、容错编排层抽象的新兴企业，试图用纯软件或软硬一体方案解决“千卡万卡可用性鸿沟”。它们的客户通常是大型云厂或头部 AI 实验室。
• 网络与存储硬件商：Arista、Cisco、Pure Storage、Weka 等，当集群规模扩大到需要专用存储汇聚层和无损网络时，其高性能、高可靠产品线的渗透率会同步上升。

公开资料未见这些公司在“可用性”单一维度上的独立财务披露，因此无法量化其受益程度。所谓的“受益”指其在产业分工中的角色重要性提升，而非特定时期的股价或营收预测。

市场规模

目前，尚无独立的第三方报告专门统计“AI 训练/推理可用性解决方案”的精确市场规模，但可以从周边和间接数据进行定性框定。

• 据 IDC 2023 年底公布的数据，全球 AI 基础设施市场（含服务器、存储、网络）在 2023 年达到约 350 亿美元，并预计在 2027 年超过 700 亿美元。在这其中，与高可用性直接相关的特性（如冗余电源/散热、高可靠网络、故障管理软件）通常占总成本的 15%~25%（供应链定性估计，未获单个厂商确认）。
• 大模型厂商在算力租赁或自建集群时，若要将有效训练时间占比从 70% 提升至 90%，通常需额外投入 20%~40% 的硬件冗余与软件授权成本（基于 2023 年云厂商年分享的非正式数据）。
• 在智算中心招投标中，“高可用运维服务”已从 2022 年的可选附加项逐渐转为 2024 年的刚性加分项，部分项目将“中断恢复 SLA”直接写入合同条款，对应预算规模在千万人民币量级（据个别公开采购公告）。
• 创业融资端，2023 年至 2024 年一季度，多家以容错检查点、故障预测为主业的初创公司获得千万美元级以上融资（公开 Crunchbase/PitchBook 信息），侧面反映出资本对可用性赛道商业价值的认可。

综合来看，虽然尚缺精确的总市场规模口径，但可用性正成为 AI 算力产业链中增长最快的细分诉求之一。其市场可被视为 AI 基础设施总支出的一块“税基”——随着集群规模每扩大一倍，这一支出占比大概率会继续上升。

玩家对比

不同参与者对可用性的实现路径和侧重差异明显，可大致对比如下：

注：表中信息主要来自各厂商在 2022–2024 年间公开的技术博客、文档和会议演讲，不涉及任何内部机密。部分条目标注“未公开”，表示查阅公开资料未见明确数字。

竞争的关键不在于单一可用性数值的高低，而在于同等可用性水平下的成本、弹性粒度、以及对主流框架的兼容性。因此，趋势是各家都在走向“开放框架 + 专有运维套件”的组合，并试图以其差异化可用性能力锁定客户。

风险

过度将资源倾注于可用性也可能引发一系列商业与技术风险：

• 物理天花板与边际成本陡峭：宇宙射线造成的内存软错误无法根除；GPU 显存错误率随制程微缩反而可能上升。要将训练可用性从 99% 提升至 99.9%，所需冗余和自愈系统成本常见翻倍，继续提升到 99.99% 可能使总拥有成本（TCO）变得不经济，降低整体 ROI。
• 硬件碎片化与供应链短缺：在高端 GPU 供不应求时，同一集群中不同批次、不同固件的卡混跑会加剧间歇性故障，反而拉低可用性。这种情况下过度的软件补偿也可能引入新的不确定性。
• 开源与闭源方案的兼容风险：部分厂商将高可用性深度耦合在其专有调度器、存储层中，形成事实锁定。如果客户未来希望迁移至不同硬件或云平台，可能面临巨大的重构成本和回退风险。
• 运维复杂度与误判：自动化故障隔离、慢节点剔除等策略过于激进时，可能导致“假阳性”驱逐，将原本稍加恢复就正常的节点永久标记为坏节点，造成资源浪费。平衡误杀与漏过的阈值调优极需经验，难以标准化。
• 人才稀缺与组织挑战：理解全栈（从硬件错误码到分布式训练框架调试）的 SRE 或基础设施工程师极为稀缺。过度依赖企业自研“黑盒”容错方案，会导致团队难以在源头解决可靠性问题，提升长期维护成本。

因此，决策者需要在可用性提升和技术经济性之间寻找动态平衡点，而非一味追求数字的无限接近 100%。

误读纠偏

• 误读 1：“可用性 = 不出故障”
  实际强调的是服务持续可访问，允许故障的发生，但必须快速恢复并对应用保持透明。万卡系统“零故障”不切实际，工程的目标是让 MTTR 足够短，让上层应用无感或仅见瞬时抖动。

• 误读 2：“99.9% 与 99.99% 差别细微”
  一年内，99.9% 的停机时间为 8.76 小时，足以打断多次长训练作业；99.99% 为 52.56 分钟，才能接近“基本无缝”。然而，为这 0.09% 的跃升，常需引入大量冗余硬件和复杂自愈逻辑，导致总成本飙升，且可能因额外开销反而降低有效吞吐。行业应追求“有效产出最优”，而非单纯攀比可用性数字。

• 误读 3：“训练和推理的可用性是一回事”
  训练是强状态耦合，故障会损失进度且需回滚；推理通常可做到近无状态或弱状态，可通过冗余副本实现毫秒级切换。将训练的容错机制直接套用到推理，会造成过度设计、延迟恶化与资源浪费。

• 误读 4：“买最好的硬件就能高可用”
  高端硬件提升了 MTBF，但万卡系统的可用性瓶颈往往在软件栈和运维流程。没有配套的自动化检测、快照和调度策略，单靠硬件升级对整体可用性的改善十分有限，甚至因操作系统/驱动的不成熟而引入新的问题。

最新事件

• 2024 年 3 月，NVIDIA GTC 2024：NVIDIA 发布新一代 Blackwell 架构及其配套 NVLink 网络，特别强调“可靠性引擎”和“硅前故障预测”能力。在 H100/B100 集群中逐步推广 GPU 串行号级遥测，并与 Base Command 和 NeMo 框架实现更深度的故障预迁移联动（公开主题演讲与白皮书）。
• 2024 年 4 月，Meta 公开 Llama 3 训练细节：其 24 000 片 GPU 训练集群在超过 54 天的训练中，有效训练时间占比约为 84%。平均每 3 小时发生一次需要人工/自动干预的故障，团队通过改进检查点与弹性调度，将单次中断的平均恢复时间控制在 5 分钟以内（Meta 工程博客公开披露）。
• 2024 年 5 月，微软 Build 大会：Azure 宣布在其 AI 基础设施中引入“预测性节点退役”功能，利用机器学习预测 GPU 未来数小时内发生故障的概率，在故障前主动迁移工作负载，可将训练中断事件减少约 40%（现场演示数据，尚未见完整论文）。
• 2024 年 6 月，中国某超大规模智算中心招标：在公开的采购需求中，首次将“有效训练时间占比 ≥ 85%”与“单次故障恢复时间 ≤ 15 分钟”作为刚性 SLA 条款，并设定分档奖惩机制，标志着国内智算市场对可用性的要求正式从定性进入量化考核阶段（公开采购公告摘要，未涉及具体客户名）。

跟踪指标

持续衡量和跟踪 AI 集群可用性，建议体系化关注以下维度（许多指标可通过 DCGM、NCCL 日志、调度器导出数据获取）：

• 作业级成功率：计划内成功完成（不被故障中断且无需人工干预）的训练任务比例，按周/月统计。
• MTBF/MTTR 的趋势图：分 GPU 型号、分机架、分网络域分别统计，定位故障热点。
• 有效训练时间占比：实际 GPU 计算时间（CUDA kernel 执行）÷ 作业总挂载时间，包含检查点、重调度、通信停摆。可通过 Prometheus + DCGM 统计 DCGM_FI_DEV_GPU_UTIL 并结合任务生命周期计算。
• 慢节点比例与延迟离群值：单步迭代的 p99/p99.9 延迟与 p50 比值，超过 2× 的节点数占比，识别隐性可用性杀手。
• 检查点开销率：检查点保存/读取耗费的时间占总挂载时间的百分比；检查点失败的频率。
• 网络误码与重传率：IB/RoCE 端口的 symbol_err、link_down 事件计数，以及 NCCL 重传计数，用于早期发现链路劣化。
• 计划/非计划停机比：计划内维护（固件升级、网络调整）与故障停机时间之比，过高可能代表运维流程效率不彰。
• SLA 达成率：对照对外或对内承诺的可用性目标（如 99.9% 服务可用性、任务恢复时间 ≤ 10 分钟），统计达成百分比。

团队可利用开源监控栈（Prometheus + DCGM + Grafana）叠加以故障注入（Chaos Mesh/ Litmus）验证，建立“追踪 → 分析 → 改进”的飞轮。

信源

• 书籍：Google, Site Reliability Engineering (O’Reilly, 2016)，第 4、6 章；High Availability and Disaster Recovery (Springer) 基础数学部分。
• 技术博客与文档：NVIDIA Developer Blog 中“Resiliency in Large‑Scale AI Training”系列；DeepSpeed 官方容错与检查点文档；Meta Engineering Blog 的“Llama 3 Training Infrastructure”分享（2024）。
• 行业会议：OFC/SC 会议中关于光互联误码率与 AI 训练影响的论文；Microsoft Build 2024、NVIDIA GTC 2024 相关主题演讲。
• 公开数据与报告：IDC Worldwide AI Infrastructure Tracker (2023 Dec)；部分智算中心招标公告（2024）；供应链与行业分享中的估算区间。
• 开源工具：NVIDIA DCGM 文档；Prometheus/Chaos Mesh 在 GPU 集群监控与故障注入的实践案例。

警告：文中部分指标的具体数值（如有效训练时间占比、MTBF 区间）来源于产业界非正式分享和供应链估算，并非官方财务披露或独立第三方报告核实，引用时请谨慎，并建议结合自有集群的实测数据进行校准。