RAS 体系 ¶

引言与概述 ¶

在超节点系统不断向更高性能、更大规模演进的过程中，软件、硬件与网络互联技术的持续创新正在不断拓展系统设计的帕累托最优边界。然而，与性能与效率指标不同，RAS（Reliability, Availability, Serviceability，可靠性、可用性与可服务性）始终构成系统设计中的核心约束之一。一个在性能或成本上具有优势的方案，若无法满足基本的 RAS 要求，将很难在真实生产环境中长期成立。结合第一章所提到的超节点系统设计的帕累托前沿来看，RAS 能力是影响这个前沿推进的核心约束，并且这个约束随着未来超节点规模和所承载任务的扩展，其影响将进一步放大。例如，单次训练或推理任务往往持续数天甚至数周，属于长生命周期计算负载，而系统规模通常扩展至数百乃至数千 GPU 节点，并依赖强同步的数据并行或模型并行机制。在这种结构下，单个节点、单张 GPU、网络链路或软件组件的异常，都可能导致全局同步受阻甚至任务整体失败，从而带来进度丢失与算力成本浪费。随着系统规模的扩大，故障发生的统计特性也随之变化，由低频、离散事件逐步转变为运行过程中需要持续面对的常态因素。因此，RAS 的核心作用在于将这些不确定性约束在 Goodput 仍可接受的范围内，它不应被视为系统设计完成之后附加的一层保障机制，而应作为决定性能与效率能否长期稳定兑现的基础条件。

从 RAS 的定义上看，可靠性是指系统在给定运行条件下、在规定时间区间内无故障运行的能力，通常通过平均无故障时间（MTTF）或故障率来衡量。可用性是指系统在需要时处于可运行状态的比例，在超节点环境中不仅取决于硬件可靠性，还取决于故障检测机制、自动恢复能力以及是否支持局部失败而非全局失败。可维护性强调系统便于诊断、修复和维护的程度，通常体现在故障定位效率、日志完整性以及自动化分析能力等方面。在定义基础上，为了更准确地评估超节点系统的运行状态，需要引入与任务执行语义相关的指标体系，包括：作业 / 集群级 MTTF（首次导致作业中断的故障间隔）、作业级 ETTR（有效训练时间与墙钟时间之比）、Goodput（单位时间内实际完成的有效计算工作量），硬件 / 软件 MTTR （故障修复的平均时间），以及灰色故障检出率（性能退化超过一定阈值的事件中被自动识别的比例）。其中，灰色故障通常不会触发显式错误，而是表现为性能退化或长时间阻塞，例如通信操作卡顿或部分设备处于异常但未报错状态，导致算力空转并显著降低 ETTR 与 Goodput，是影响系统整体效率的重要因素。

随着系统规模与复杂度的提升，超节点 RAS 的实现方式也在持续演进，其整体趋势可以概括为从被动响应走向主动预防、从局部机制走向跨层协同。以表 1 所展示的 NVIDIA 的架构演进为例：在 Hopper（H100/H200）阶段，系统主要依赖传统 ECC 与基础遥测能力，通过有限的芯片级指标实现被动检测与故障响应；在 Blackwell（B200/GB200）阶段，引入 AI 驱动的 RAS Engine，融合更多硬件与软件数据点，实现预测性分析与主动维护；进一步，在 Rubin（Vera Rubin NVL72）阶段，相关机制扩展到跨 GPU、CPU 与网络的协同监控与联动处理，逐步具备系统级自检测与自修复能力。这一演进路径表明，仅依赖单一层面的可靠性机制已难以支撑超节点的稳定运行：一方面，需要在硬件层构建更强的错误检测与隔离能力；另一方面，也需要在软件层对这些信号进行组织与利用，使其能够支撑更及时的检测与更主动的处置，从而形成协同工作的整体 RAS 体系。

本章节从硬件 RAS、软件 RAS、可观测性以及 RAS 实践四个维度展开，对超节点 RAS 的关键技术与实践经验进行系统梳理。首先，在硬件层面，从芯片、网络以及服务器整机三个维度出发，分析错误检测、故障隔离、链路自愈以及基础遥测信号如何构成第一道防线；接着，在软件层面，讨论操作系统、以及训练与推理系统如何在此基础上构建可检测、可恢复与可降级的系统能力；随后，介绍面向超节点的可观测性体系，说明如何对多层级运行状态进行统一采集、对齐与关联，并形成支撑故障检测与分析的关键指标；最后，结合真实生产环境，讨论指标体系、遥测管线与故障演练如何形成闭环，使 RAS 从原则要求转变为可持续运行的工程实践。

硬件为中心的 RAS 系统 ¶

芯片 RAS ¶

芯片级 RAS 指在芯片内部通过硬件机制实现的可靠性、可用性和可维护性能力，其目标是在系统运行过程中及时发现、校正并处理各类硬件异常，从而降低故障对整体系统稳定性的影响。为实现这一目标，芯片内部各类存储单元与通信模块通常集成完备的错误检测、校正与处理机制。其中，错误检测通过奇偶校验、循环冗余校验（CRC）、纠错码（ECC）或状态机监控等技术及时识别异常行为；错误校正机制提供自动修复能力，例如通过 ECC 纠正单比特错误或触发重传机制恢复丢失数据；在检测到异常后，错误处理机制按照预定义的故障响应流程执行相应操作，包括告警上报、故障模块隔离、冗余路径切换、安全降级操作以及系统级恢复策略，以确保故障不会扩散并影响整体系统稳定性。同时，系统还具备日志记录与访问能力，所有故障事件都会生成结构化事件日志，记录时间戳、错误类型、错误定位、触发条件及处理动作等关键信息，并可通过带内或带外管理通道进行访问，以支持后续的系统诊断与运维分析。

芯片级 RAS 关键技术涵盖计算核心、存储子系统、通信链路以及电源与热管理等多个方面，通过多层次的可靠性设计提升芯片在复杂运行环境下的稳定性与可维护性。

• 在计算核心 RAS 方面，系统通过多种机制保证计算单元的持续可用性。计算核心冗余设计允许在检测到计算核心故障时自动启用备用核心，实现计算能力的无缝迁移与恢复；动态核心禁用机制在系统初始化阶段通过故障检测识别存在缺陷的计算核心，并对其进行隔离，从而避免潜在问题影响系统稳定性与可靠性。同时，系统还具备错误传播阻断能力，当检测到错误数据时会对相关数据块进行标记和隔离，防止污染后续计算，并在错误传播路径上设置屏障，阻止错误数据流向其他计算单元。

• 在显存 RAS 方面，系统通过多种技术保障数据完整性和存储可靠性。ECC（Error Correcting Code）是显存可靠性的重要基础，可实现单比特错误纠正、双比特错误检测（SECDED），更高级的 ECC 算法还可进一步提升显存可靠性和可用性。行重映射（Row Remapping）技术在系统启动时由 GPU 执行自检，当 HBM 内存检测到坏块时，可自动将故障行映射到备用行，无需重启 GPU，从而降低 HBM 显存故障率。与此同时，Patrol Scrubbing（内存巡检）机制会在系统后台周期性扫描内存，并利用 ECC 自动纠正软错误，与传统内存错误检测方式相比，该技术能够提前发现并修复潜在错误，从而显著提升数据完整性。

• 在链路与协议保护方面，系统通过多层通信可靠性机制保障数据传输稳定。错误检测与纠正机制使用 CRC（ECRC）和 FEC 技术对数据进行校验和纠错，确保数据传输可靠性；链路自愈能力通过链路重训练（Link Retraining）以及自动重传机制实现链路的快速恢复，从而保障高速互连链路的持续可用；同时系统还具备智能诊断与预测能力，可精确报告错误类型并提供详细的错误信息，用于系统级故障诊断，从而提升整体可服务性。

行业实证：NVIDIA Blackwell RAS Engine。 Blackwell 架构首次引入了专用的 AI 驱动 RAS Engine——一个嵌入芯片内部的专用微控制器，可在 GPU 运行时持续对数千个 SRAM 区域与寄存器文件执行预测性扫描与诊断。与传统 " 发现错误 → 报告 → 纠正 " 的被动模式不同，Blackwell RAS Engine 通过对历史错误模式进行建模，在硬件劣化导致不可纠正错误（UE）之前即触发预防性维护——例如将可疑 SRAM Bank 映射到备用资源、或主动隔离劣化互联通道。这一实践标志着芯片级 RAS 从 " 被动纠错 " 向 " 主动预防 " 的范式转变，为超节点集群的预测性运维提供了硬件基础。对于超大规模（数千 GPU）的超节点部署而言，当集群级 MTTF 因规模效应而大幅缩短时，芯片内置的预测性 RAS 能力将成为保障 ETTR 与 Goodput 的关键第一道防线 ¹ .

在电源与热管理方面，系统通过实时监控和保护机制保障芯片运行安全。芯片能够实时监控并获取电压、电流、功耗及温度等关键参数，并通过标准接口上报至系统管理单元，为系统级监控、功耗优化以及热管理策略提供精准数据支持。同时系统具备完整的电源保护机制，包括 OCP（过流保护）、OVP（过压保护）以及 UVP（欠压保护），以防止供电异常导致芯片损坏或系统宕机。系统同时采用智能温控策略，当芯片温度达到保护阈值时自动触发降频机制，而当温度达到最大阈值时则会执行自动关机，从而保护芯片及系统硬件的安全。此外，系统支持带内或带外的错误注入验证机制，用于验证 RAS 相关功能和故障处理机制的有效性。

网络 RAS ¶

链路级 RAS。链路级可靠性是网络 RAS 的基础，旨在保证数据传输本身的正确性与连续性。高性能交换芯片和互联链路采用端到端循环冗余校验（ECRC）进行错误检测，同时配合基于 ACK/NACK 的链路级重传（LLR）机制，实现错误数据自动重传。多通路 Lane Reduce 设计和基于单通道故障的动态降级（Dynamic Lane Downgrade）机制进一步提升链路容错能力，使单通道异常不会影响整个链路的稳定性，从而保证节点间数据传输的高可靠性。

互联子系统 RAS。 在链路或交换设备发生异常时，互联子系统级 RAS 能够提供系统级故障响应和隔离能力。通过高级错误报告（AER）机制，交换芯片能够准确识别和上报错误类型；下游端口隔离（DPC）防止故障扩散至其他链路或设备；链路带宽降级与动态管理策略在链路异常时及时调整流量分配；Completion Timeout（CTO）错误处理机制确保任务不会因链路异常长时间阻塞。子系统级故障处理确保网络能够在节点或链路出现问题时保持连通性和业务连续性。

光电融合 RAS。在大规模集群中，光模块、Retimer 及跨板铜缆构成的物理链路是网络故障的高风险区域。光电融合 RAS 通过光链路健康监控、误码率（BER）预警与劣化隔离，增强网络鲁棒性。网络 RAS 系统会持续采集光模块的发射光功率（Tx Power）、接收光功率（Rx Power）、温度、偏置电流等关键模拟参数，并对 Pre-FEC 与 Post-FEC BER 进行趋势分析。当 Pre-FEC BER 接近安全阈值且出现不可纠正趋势时，系统提前触发告警，并配合控制面启动流量排空与链路预隔离操作，从而在故障发生前主动应对，避免链路彻底失效才被动恢复。这种预测性机制不仅提升了链路弹性，还显著降低了因物理退化或流量突发导致的网络性能下降风险。

最后，网络可观测性是贯通链路级、设备级与互联子系统级 RAS 能力的关键支撑，用于实现多层级状态感知、故障定位与协同决策，从而将分散的可靠性机制整合为统一的系统级保障能力。相关可观测技术与实现细节将在后续章节中展开说明。

服务器 RAS ¶

在传统服务器领域，RAS 是衡量设备持续运行、抗故障、易维护能力的核心指标体系。下文首先介绍单节点服务器的 RAS 保障，然后再扩展到超节点服务器机柜的 RAS 支持。

单节点服务器 RAS ¶

单节点可靠性。 保障单节点可靠性一般首先从硬件设计和供应链物料选型着手，涵盖元器件与硬件可靠性、信号 / 链路传输可靠性、电源供电可靠性、散热系统可靠性以及关键部件容错能力等方面，通常通过采用企业级 CPU、低温飘电容、高可靠性长寿命存储磁盘或 SSD 等企业级规格元器件，选用支持 ECC 的内存等；电源设计时引入过流 / 过压、过温保护，采用高 Margin 电源方案；散热方面支持冗余风扇、智能 PID 调速的闭环温控措施；对关键信号选择差分布线或包地线等抗干扰手段来实现。

单节点可用性。 保障单节点可用性的典型方法以冗余设计为主，辅以设备协议层自愈能力。硬件冗余（如 N+1 或 N+N 电源、N+X 风扇、构建 RAID 存储阵列、双网卡绑定）；通过 CPU / 内存分区和坏块屏蔽实现故障隔离，利用内存 sparing 自动替换坏页及 PCIe 链路 retrain 实现自愈，以及多节点冗余技术来保障分布式系统的高可用，确保业务持续稳定运行。

单节点可服务性。 保障单节点可服务性主要经由故障精准诊断、远程管理与监控、故障日志与回溯、易维护易更换以及现场快速修复等实现。整机工程设计方案中支持热插拔的硬盘 / 电源 / 风扇 / PCIe 卡（部分平台甚至支持内存热插拔）是快速修复的必要前提。通过 BMC / IPMI、Redfish、KVM over IP 等带外管理方式，配合 UID 灯、故障定位灯及硬盘、电源、风扇状态灯等故障指示手段，借助 SEL 系统事件日志、硬件错误追踪实现故障记录与回溯，基于免工具拆装、前置维护、线缆理线优化等设计提升运维与修复的效率。随着服务器功耗的不断升高，降低数据中心和机房 PUE 的要求越来越紧迫，相应的液冷服务器市场占比越来越高，冷却液接口喷溅泄露、机内漏液、冷却液温度管理等的预防、检测和及时告警也是维护系统安全可靠、稳定运行的关键重要事项。

超节点 RAS 支持 ¶

超节点作为 AI 场景下训练和推理的核心高价值资产，物理上包含了关键的计算服务器，还包含各类核心交换设备、存储设备、高速互联总线、机柜、液冷系统、以及上层运维监控、算力调度软件系统等。超节点一般是以机柜为单位实现芯片级全域高速互联、算力 / 内存 / 存储池化为目标，涉及多维度不同产品的融合、异构共生、系统软件协作，难度和复杂度均远超传统单台服务器或通用计算集群的要求。

机柜级紧耦合全互联的 Scale-Up 算力池化系统的 RAS 设计除常规物理冗余、温度监管、功耗监控、物理互联可靠和易维护之外，还要围绕紧耦合、高密度、异构化、训推一体化的核心特性展开，目标缩减单点故障的影响面、保障业务连续性。

从系统工程与大规模 AI 训推实践角度出发分析，超节点的 RAS 前提是建立在可靠的物理单元设备的基础之上，须优先从物理底层消除高密度部署带来的基础设施故障风险，同时叠加超节点管理软件栈的平台系统来综合实现。具体包含（1）模块化与热插拔和（2）监控与遥测两个方面的内容。

模块化与热插拔。 模块化设计通过将计算、互联、供电与散热等功能解耦为标准化单元，使系统能够以“积木式”方式进行构建与扩展，从而在高密度部署条件下实现灵活扩展与故障隔离。在具体实现上，计算模块通常以集成 CPU / GPU / NPU、内存与本地存储的一体化托盘形式存在，或由多个托盘组合形成统一算力池；互联模块则包括 NVSwitch、IB / RoCE、灵衢 / UB 等高速交换单元，可独立部署，并根据工程目标选择全互联、交换式或其他拓扑结构，常见实现方式包括正交互联、Cable 直连及 Cable Tray；散热模块同时支持风冷与液冷方案，其中风冷采用分区冗余风扇与智能调速（至少 N+1 冗余），液冷则由冷板、CDU 及快接管路构成，并具备防泄漏能力，同时通过散热单元模块化降低故障扩散风险；供电模块包括机柜级冗余电源（1+1 或 2N）、支持 Redfish / IPMI 接入的 Powershelf 供电模组，以及支持 PMBus 监控并具备过压、过流与掉电保持能力的单机 PSU；监控与管理模块则由机柜级 RMC 与单机 BMC 组成，并结合集中运维平台实现统一管理。

在此基础上，系统通过标准化 FRU（现场可更换单元）设计支持热插拔与在线维护能力，使 GPU / AI 芯片模块、电源、风扇、液冷模块及互联交换模块等关键部件能够在不中断系统运行的前提下完成更换，单部件更换时间通常可控制在分钟级以内；对于液冷节点，还可支持电、网、液三总线一体化盲插，无需精确对准即可完成快速对接。同时，通过轻量化工程设计，将单个热插拔模块重量控制在 20–30 kg 范围内，使单人即可完成维护操作。

针对液冷系统的在线维护，还需进一步考虑运行安全性与系统连续性，例如通过支持带压插拔的快接头实现节点更换过程中的冷却液零泄漏，并结合分液歧管隔离阀设计，在单节点维护时不影响整体循环系统运行；同时，液冷快接接口与机柜结构协同设计，以避免插拔过程中的喷溅风险。

监控与遥测。 在监控体系上，超节点构建了从单节点到机柜级再到统一平台的分层架构，并通过细粒度遥测数据实现对系统状态的全面感知与分析。在单节点层面，依托 BMC 对 GPU、CPU、内存、网卡、磁盘与风扇等关键部件进行全覆盖监控，并支持一键日志收集与故障信息聚合，从而实现快速定位故障根因；在机柜层面，通过独立的 RMC 模块实现统一管理，涵盖资产管理（自动 U 位识别与资产信息上报）、环境监控（温湿度、烟雾、水浸传感器接入）、电源管理（机柜级功耗监控与分配）以及液冷系统的运行守护（包括漏液监控与告警、流量监测及泵组控制）。

在更高层面，超节点健康监测平台对来自各层级的数据进行整合，形成从物理层（芯片温度、电压、光模块功率、链路误码率）、链路层（带宽、延迟、丢包率）、系统层（资源利用率、固件版本）到业务层（训练与推理任务进度、精度变化）的全链路可观测能力，使故障能够精确定位到芯片、链路或核心计算单元。在此基础上，系统构建“告警—定位—根因分析—修复—验证”的闭环自动化运维体系，对常见故障实现自动修复，减少人工干预；同时，对关键部件进行全生命周期数字化管理，包括运行状态监测、老化与寿命预测、预测性维护以及退役管理，通过对历史数据的持久化存储（通常不少于 90 天），支持问题回溯与趋势分析，从而将运维模式由被动响应转变为主动预防。具体的可观测技术在后面的章节阐述。

超节点故障恢复 ¶

在超节点系统中，最核心的风险之一是单点故障引发的级联扩散效应，因此需要从通信、系统与资源调度等多个层面构建分层次的故障恢复机制，以在高密度、强耦合环境下保障端到端业务连续性。

在通信平面，系统通过多级容错机制提升互联可靠性与故障隔离能力，包括在链路层引入前向纠错（FEC）、逐包校验与动态路由能力，在链路发生异常时自动绕行或切换，避免单链路故障导致全局通信中断；在采用光互连的场景中，可通过单 Lane 故障降级运行或单激光器失效降级机制维持通信能力（具体实现依赖硬件平台能力，此部分描述可请光互联厂商介入给予建议）；在计算与通信协同层面，通过多卡通信状态同步与异常检测，在发生故障时重新触发通信子流程，从而恢复分布式执行（此部分描述可请 GPU 厂商介入给予建议）。

在系统恢复层面，超节点通常提供多级快速恢复能力，以实现不同粒度的故障隔离与修复，包括容器级基于镜像的快速重建、进程级的独立重启与状态恢复、资源单元级（如 Pod 或节点组）的快速重建，以及作业级的整体恢复与训练进程接续。这种分层恢复机制能够将故障影响限制在最小范围，避免不必要的全局中断。

针对长时间运行的大模型训练任务，断点续训（checkpoint / restore）机制是减少算力损失的关键手段。通过细粒度的迭代级 checkpoint、训练状态的实时或周期性持久化、多副本存储与一致性校验，可以在任务中断后快速恢复执行进度，但在实际部署中需要在 checkpoint 频率与训练性能开销之间进行权衡，以避免对整体效率造成显著影响。

在资源与调度层面，结合资源池化与弹性调度能力，系统可以在故障发生或负载波动时动态调整算力、内存、网络与存储资源分配，通过虚拟切分与弹性扩缩容实现资源的快速重构与复用，在保障高优先级业务服务质量的同时，提高整体资源利用率，并进一步增强系统在异常情况下的自适应恢复能力。

服务器 RAS 小结 ¶

超节点作为 AI 算力资源宝贵生产力，节点业务的连续性异常重要和关键。故障发生后，其关键业务节点故障平均恢复时长 MTTR 建议一般不超过 30 分钟。

超节点 RAS 设计应聚焦 “高密度紧耦合全互联” 的架构本质，构建多层纵深 RAS 体系，保障大规模训推任务的业务连续性、算力可用性与运维高效性。

一般性原则为基于 “硬件级 RAS 增强 + 软件栈容错优化” 的软硬协同设计。硬件面强化高速互联容错、基础设施冗余；维护层面采用模块化热插拔设计、全链路细粒度可观测、自动化运维闭环，降低高密度超节点的运维复杂度，保障大规模集群基础设施的运维需求；软件层面优化训推任务容错、断点续训、资源动态调度，实现 RAS 能力全栈覆盖。

最后，从未来发展趋势来看，超节点 RAS 需求是多维并不断发展的，已不仅仅局限于关注核心硬件资源、算力调度系统和运维监控管理系统的发现和解决问题，正逐渐从 “被动应对问题” 变成 “主动预判问题、动态适配需求、自动解决问题”，趋向实现更高级别的自动化运维中心，以支撑未来大规模训推任务的业务连续性。

软件为中心的 RAS 系统 ¶

如果说前面的硬件 RAS 讨论回答的是“系统底层能暴露哪些信号、拦住哪些错误、隔离哪些故障”，那么到了软件层，问题就会立刻变成另一种形态：这些底层能力如何被重新组织成作业还可以继续推进、服务还可以继续提供、运维还可以继续判断的系统行为。也正是在这一层，RAS 开始从一组器件能力，转变为一套持续约束 Goodput、尾延迟和恢复时间的工程组织。

操作系统层面的 RAS ¶

Checkpoint /Restore 在超节点 RAS 中的作用。 Checkpoint / Restore（C/R）是一种提升 RAS 的重要技术手段。其基本思想是在程序运行过程中周期性地保存执行状态，当系统发生故障时，可以从最近一次保存的状态恢复执行，从而避免从头开始重新计算。在超节点中，C/R 已经成为支撑训练与推理系统稳定运行的重要机制。真正的意义不在于“系统多了一项恢复功能”，而在于规模上来之后，系统终于需要为“中断之后如何继续”建立一条制度化路径：

• 在大规模模型训练场景中，checkpoint 主要用于周期性保存模型参数、优化器状态以及训练进度。当训练任务因节点故障、网络问题或系统维护被中断时，可以从最近一次 checkpoint 恢复执行，避免长时间训练任务的计算成果丢失，从而显著降低训练成本并提升系统可靠性。
• 在推理服务场景中，C/R 则可以支持更加灵活的服务管理能力。例如，在云环境中可以利用 checkpoint 技术实现推理服务的快速迁移、弹性扩缩容以及故障恢复；在 serverless AI 服务场景下，通过恢复预初始化的模型执行状态，可以显著减少冷启动延迟，从而提升服务响应速度与资源利用效率。

目前，C/R 机制既可以在操作系统层实现，也可以通过用户态工具实现。例如，NVIDIA 提供的 cuda-checkpoint 工具就是一种用户态实现方式。该工具通过 CUDA Runtime API 提供的能力保存 GPU 相关执行状态，并在恢复时重新创建 GPU context 并恢复设备内存，从而实现 CUDA 应用的状态保存与恢复。然而，仅依赖用户态机制实现高效且正确的故障恢复存在挑战：AI 工作负载的优化空间极为复杂，并且随着模型规模与训练框架的演进不断变化，使得在用户态框架中实现高效的容错机制变得十分困难。例如，当前主流的大模型训练框架 Megatron 已经集成了多种并发 checkpoint 优化技术，而相关代码规模已经占据框架代码库的重要部分。同时，许多新兴训练框架（例如强化学习训练框架）仍然缺乏成熟的容错机制支持。这意味着每个框架都需要独立实现并持续维护自己的 checkpoint 优化逻辑，增加了开发和维护成本。

相比之下，在操作系统层面提供统一的 C/R 支持可以显著降低开发负担。OS-level C/R 能够对应用框架保持透明，无需开发者显式实现复杂的故障恢复机制，也无需针对不同框架进行重复开发。此外，操作系统级支持还能够为更高级的系统功能提供基础能力，例如云环境中的快速实例迁移、弹性资源管理以及 serverless AI 服务中的快速启动等。因此，从系统基础设施的角度来看，在 OS 层提供通用且高效的 cC/R 机制具有不可替代的价值。

实现 OS-level GPU C/R 的挑战。 对于 CPU 程序而言，操作系统能够对程序执行状态进行较为完整的控制与观测。例如，操作系统可以直接访问和保存 CPU 寄存器状态、虚拟内存映射以及进程调度信息，并通过页表与 page fault 机制追踪内存访问状态。此外，操作系统内部许多机制本身就与 CPU 执行模型深度结合，例如 RCU（Read-Copy-Update）, Read-Copy-Write 等机制。这些能力使得操作系统可以通过已有机制较为完整地追踪进程的控制状态和数据状态，从而实现可靠的 C/R。

相比之下，GPU 对操作系统而言更接近一个“黑盒设备”。应用程序通常需要通过厂商提供的 API（例如 CUDA）与 GPU 交互，而操作系统本身并不直接管理 GPU 内部执行状态。应用程序可以向 GPU 提交复杂的 kernel 进行异步执行，这些 kernel 可能在 GPU 上进行大量计算并访问 GPU 设备内存。此外，CPU 与 GPU 之间还存在复杂的数据交换与通信机制，例如 PCIe 或 NVLink 数据传输等机制。因此，在实现 GPU 的 C/R 时，不仅需要考虑 CPU 侧的进程状态，还必须处理 GPU 设备内存、GPU kernel 执行状态以及 CPU–GPU 之间的数据一致性问题。这些因素都显著增加了 GPU C/R 的实现复杂度。

基础的 GPU C/R 和 并发 GPU C/R。 一种直接的实现方式是在进行 checkpoint 时暂停应用程序执行，然后复制所有相关执行状态。例如，一些现有工具（如 cuda-checkpoint）通常采用如下流程：当系统需要创建 checkpoint 时，首先暂停 CPU 进程执行，同时等待 GPU 上所有正在执行的 kernel 以及相关通信操作完成，从而使系统进入一个稳定状态。随后，系统将 CPU 侧内存状态以及 GPU 设备内存中的数据复制到 checkpoint 存储中。在恢复阶段，系统首先重新加载 CPU 内存数据与 GPU 设备内存数据，然后重新创建 GPU context 并恢复控制状态，最终使程序继续执行。

然而，这种“停止 - 复制 - 恢复”的方式会带来较大的性能开销。首先，在 checkpoint 阶段需要等待 GPU kernel 执行完成并进行大规模数据复制，这可能导致较长时间的 GPU stall。其次，在恢复阶段重新创建 GPU context 以及重新加载大量 GPU 内存数据也会带来显著的启动延迟。对于 GPU 资源利用率较高的 AI 训练或推理任务而言，这种停顿会对整体系统性能产生明显影响。

为了降低 checkpoint 带来的停顿开销，近年来研究开始探索 并发 C/R 机制。所谓并发 C/R，是指在应用程序仍然运行的情况下完成 checkpoint 操作，或者在恢复过程中允许应用程序与数据恢复过程并行执行。通过并发机制，系统可以在后台逐步保存程序状态，从而避免长时间暂停 GPU 执行。同时，在恢复阶段也可以在应用继续执行的同时逐步加载所需数据，从而显著降低恢复延迟。随着 AI 工作负载规模的不断增长，并发式 OS-level C/R 正逐渐成为提升系统可用性的重要技术方向。

代表性的研究工作。 近年来，学术界与工业界提出了多种面向 GPU 应用的 C/R 系统 :

• Singularity ² 通过设备代理（Device Proxy）架构实现了 OS 级 GPU C/R。该系统利用 LD_PRELOAD 拦截 GPU API 调用，并将其转发到独立地址空间中的代理进程，使主机进程保持相对“干净”的状态。这样可以直接使用 CRIU 工具对 CPU 进程状态进行标准快照，同时通过虚拟化 GPU 句柄以及 API 重放机制恢复 GPU 状态。相比传统的停止重启方式，Singularity 能够实现 work-conserving 恢复，使任务能够从精确的中断点继续执行而无需重新初始化或重复计算。此外，该系统还通过分布式屏障保证一致性，并利用内容去重、副本拼接（Replica Splicing）以及操作压缩（Squashing）等技术显著降低了 checkpoint 的存储开销与显存切换延迟。

• gCROP ³ 系统通过引入 GPU Restore Server，实现了 CPU 与 GPU 状态恢复过程的并行化，从而打破了传统工具串行恢复的限制。该系统利用 gmmap 技术实现 GPU 显存的按需加载，并结合基于 profiling 的预取机制，使 GPU 计算能够与数据恢复过程并行执行。同时，gCROP 还提出了多级 checkpoint 去重技术以减少镜像存储开销。通过这些优化，该系统能够将大型 GPU 应用的冷启动延迟从秒级降低到 100ms 以内。

• PhoenixOS (PHOS) ⁴ 指出，在 OS 层实现并发 GPU C/R 的核心挑战在于 GPU 缺乏类似 CPU 内存管理中的硬件脏页位（dirty bits），这使得系统难以准确追踪 GPU 内存的修改状态。为了解决这一问题，PHOS 通过 LD_PRELOAD 拦截 GPU API，并结合验证预测（Validated Speculation）、二进制插桩（Binary Instrumentation）、软写时复制（Soft Copy-on-Write）、软重传（Soft Recopy）以及按需恢复（On-demand Restore）等机制，实现了对 GPU 内存修改状态的高效追踪，从而显著降低了传统 C/R 方法带来的应用停顿开销。

• Gemini ⁵ 系统则主要关注 checkpoint 的存储与传输效率问题。该系统在操作系统层面引入内存级 checkpoint，并提出接近最优的 checkpoint 放置策略，以最大化副本可用性。同时，通过通信流调度算法将 checkpoint 数据传输隐藏在训练任务的网络空闲阶段，从而减少对训练性能的影响。Gemini 能够实现亚秒级的 checkpoint 检索速度，并支持接近每轮训练迭代一次的高频 checkpoint。与前述工作相比，该系统主要优化 checkpoint 的存储与获取效率，与 GPU 执行状态管理等技术方向形成互补关系。

训练与推理平台的 RAS 建设 ¶

如果说前文讨论的是芯片、网络、操作系统与运行时层面的 RAS 能力，那么落到训练与推理平台，核心问题就变成如何将这些底层信号组织成面向任务的诊断、恢复与经验闭环能力。随着大模型训练与推理规模持续增长，平台侧的可靠性问题也在从局部运维议题演变为系统性工程问题。在训练场景中，尤其是预训练任务，系统已经逐步逼近万卡级运行规模；在推理场景中，随着长上下文、高并发、多副本以及复杂并行策略的引入，平台同样面临越来越高的稳定性、可用性与可服务性要求。与此同时，大量中小规模任务长期并行运行，也在持续抬升整体运维与排障成本。

从系统视角来看，无论是训练任务还是推理任务，本质上都运行在一个高度耦合的分布式基础设施之上。这套基础设施覆盖服务器、GPU、网络、存储、调度系统、虚拟网络、训练框架、通信库以及上层任务编排等多个层级。计算、通信、数据读取、访存、checkpoint 与恢复等行为在同一运行过程中交错发生，使得用户最终观察到的异常现象，往往只是底层复杂问题在任务层的一种外在呈现。

例如，用户看到的可能只是任务中断、训练速度下降、通信超时、进程挂起、推理时延抖动或吞吐下降，但这些现象背后的根因并不一定发生在同一层。问题可能来自硬件故障、网络抖动、存储异常、驱动兼容性问题、运行时环境问题，甚至可能是多个层面共同作用的结果。也正因如此，训练平台与推理平台的 RAS 建设，已经无法继续停留在“告警加人工排查”的传统模式上，而必须逐步演进为一套面向任务、面向系统、面向经验闭环的整体能力体系。

当前面临的核心问题 ¶

结合现有平台实践，可以将当前平台侧 RAS 面临的主要问题概括为以下几个方面。

任务规模扩大后，故障影响半径显著放大。 当任务规模从单机或小规模多机扩展到数百卡、数千卡乃至万卡级别之后，单个节点、单条链路、单个存储路径或单个设备侧异常，都可能迅速被放大为任务级中断或性能退化问题。推理平台同样如此，一个局部组件的异常，也可能进一步演化为整体尾时延上升、吞吐波动或副本失衡。

大量异常难以通过单点告警直接定界。 当前系统中，部分故障能够通过硬件告警直接发现，但仍有大量异常并不存在清晰、明确的告警信号。特别是在通信挂起、慢任务、僵尸任务、异常退出、设备报错等场景中，即便系统已经暴露出异常现象，也往往难以依靠单一数据源直接判断根因位置。

数据分散，缺少按任务统一组织的诊断视图。 当前观测数据通常分散在告警系统、指标系统、日志系统、平台状态系统和作业系统等多个数据源中。这些数据源彼此独立，缺乏围绕任务视角进行统一关联与解释的机制，导致平台侧很难快速回答几个最关键的问题：究竟是哪一个任务受到了影响，影响范围有多大，对应哪些节点、rank、通信关系和存储路径，以及当前最可疑的故障点究竟位于哪里。

人工排障高度依赖经验，过程缺乏可复用性。 目前，大量排障工作仍高度依赖人工经验。经验本身当然有价值，甚至往往是解决复杂问题最有效的基础；但问题在于，这些经验通常分散在不同工程师的个人认知、即时沟通记录或零散文档之中，难以转化为可重复执行的流程与规则。这意味着相似问题每次出现时，排障过程都可能重新开始，缺乏稳定的方法论与持续复用能力。

跨层协作成本高，定位时间长。 当任务出现挂起、性能下降或中断时，排障过程往往需要服务器、网络、存储、平台、框架乃至算法多方协同推进。在缺少统一排障抽象的前提下，故障定位通常需要数小时甚至数天，这不仅直接影响用户体验，也显著提高了平台内部的服务成本。

用户缺少面向任务的统一入口。 即使平台底层已经掌握部分风险信号，用户通常也很难基于任务 ID 直接获得面向任务的诊断结果。对用户而言，平台缺少一个统一入口，用于快速查看该任务关联的服务器、网络、存储是否存在明显异常，也缺少一套真正围绕任务组织的 RAS 产品形态。

从这些问题可以看出，平台当前缺少的并不是更多单点工具，而是一套围绕“任务”组织观测、诊断与恢复的系统能力。换言之，平台需要的是一个真正以任务为中心的诊断与协调机制，能够统一关联节点、rank、通信关系、文件路径、checkpoint 行为、日志时间线与告警事件，并沿着明确的排查路径给出更稳定、更可执行的故障判断。

已有经验沉淀 ¶

从任务视角组织系统化排障。 现有实践中，一个最重要的经验是：排障能力只有真正回到任务视角，才可能具备稳定的解释力和可操作性。相比于简单新增一层告警，更关键的是将不同层级的数据源和检查手段组织成一条系统化的排障链路，使平台能够围绕任务对象完成故障定界、故障定位和经验沉淀。

这类方法的核心目标通常包括三个方面。首先，是判断问题究竟来自代码侧还是集群侧，并进一步区分服务器、网络、存储、基础服务等方向；其次，是在完成定界之后继续缩小范围，定位到具体的嫌疑节点、链路、通信组或路径；最后，是将一线排障经验逐步沉淀为可重复执行的流程、规则与案例。

从已有方法来看，较为有效的路径通常是：先建立任务与基础设施对象之间的关联关系，例如作业与节点、节点与 rank、rank 与通信组、节点与存储路径之间的映射；再根据故障表现区分初始化失败、性能下降、任务中断等不同场景；最后围绕服务器、物理网络、虚拟网络、通信层、存储层和基础服务等多个层面组织检查项，形成面向不同场景的诊断路径。

这类经验对未来 SuperPod 的启发非常明确：未来 RAS 系统必须天然以任务为中心，而不能仅仅以基础设施为中心。因为只有当基础设施指标被映射回任务语义之后，它们才真正对用户和平台具有可操作价值。

从事后分析走向在线检测与自动触发。 另一个关键经验是，平台能力必须逐步从事后排查演进到在线检测与自动触发诊断。相较于等待用户反馈或任务彻底失败之后再介入，更有效的方式是在任务运行过程中持续感知异常，并在识别到高风险信号之后自动触发后续诊断动作。

这种能力的重要价值主要体现在两个方面。第一，异常检测时机可以明显前移，从而减少问题扩散和现场信息丢失。第二，检测与诊断之间可以形成闭环：系统识别到可疑任务之后，不再停留在“发现异常”的层面，而是能够进一步保留现场信息、触发补充检查，并为后续定界与定位提供依据。

这说明未来 RAS 系统不应只是一个静态分析系统，而必须具备持续在线感知、自动触发诊断和自动保留现场信息的能力。对于长周期训练任务和大规模推理服务而言，这种能力几乎不可或缺，因为一旦错过故障发生窗口，后续定位成本往往会大幅上升。

观测能力需要向底层运行时与通信层持续下钻。 在实际排障过程中，仅依赖任务日志和硬件告警，往往无法解释大量“没有明确报错，但任务确实异常”的问题。一个重要经验是，平台观测能力必须能够在必要时继续下钻到通信事件、运行时行为以及设备侧细节，才能对复杂问题形成更有解释力的判断。

这背后反映出的事实是，大规模训练与推理中的很多问题，并不是简单意义上的“节点坏了”或“服务挂了”，而是发生在软硬件边界处的复杂系统行为。因此，真正有价值的 RAS 系统，既要能够告诉用户“哪里出了问题”，也要尽量回答“为什么会出问题”“如何复现”“如何规避”。

这也意味着，未来 SuperPod 的观测体系必须具备分层能力：既要有面向任务、面向用户和面向平台调度的高层抽象，也要能在必要时向下钻取通信、访存、设备和运行时层面的细节信息。

经验积累必须形成案例闭环。 从既有实践中还可以看到，许多线上高频问题都具有较强的复现模式。通信挂起、异常退出、设备报错、驱动与环境不匹配、混部兼容性问题等，往往并不是完全随机发生，而是会在不同时间、不同任务中反复出现。真正有价值的经验沉淀，不仅是记录问题现象本身，更包括候选根因、现场追溯能力、临时缓解方案以及长期修复动作。

这意味着平台 RAS 的目标不应只是一次次从零开始排障，而应当逐步把历史故障转化为未来的快速诊断与自动处置能力。对于 SuperPod 而言，案例积累不应被视为附属工作，而应被看作系统输入的一部分。

对未来训练与推理平台 RAS 设计的启发 ¶

基于上述经验，可以提炼出未来训练与推理平台在 RAS 方向上至少需要坚持的几项原则。

以任务为中心组织能力。 所有观测、告警、诊断和恢复动作，最终都应映射到任务对象本身，能够明确回答：哪一个任务受到了影响，影响范围有多大，当前任务是否还能继续运行，以及平台建议采取什么恢复动作。

以分层诊断替代单点告警。原子告警仍然重要，但它只能被视为诊断链路中的一个输入，而不应等同于诊断本身。未来系统需要同时具备规则排障、主动探测、在线诊断、案例检索与趋势分析等多层能力，才能形成真正可用的 RAS 体系。

以自动化方式沉淀人工经验。排障路径、判断规则、典型案例以及缓解动作都应逐步模块化，而不应长期依赖少数个体经验。只有这样，系统才能在规模增长的过程中保持稳定的可服务能力。

以关键指标驱动系统建设。 后续系统模块设计和阶段目标拆解，应围绕若干核心指标展开，包括：任务实际有效运行时长 / 有效训练时间占比，异常检测时延，故障定界准确率，故障定位时间

训练平台与推理平台共用方法论、分化实现形态 训练与推理在外部表现和恢复策略上存在差异：训练更强调长周期稳定性、checkpoint 保护与恢复效率，推理更强调服务连续性、时延抖动控制和快速隔离。但从方法论上看，两者底层是一致的：都需要从任务视角组织对象关系、建立异常时间线、关联多源数据，并基于影响范围与恢复代价选择处理动作。因此，未来平台可以在统一方法论之下，针对训练和推理分别设计不同的实现形态。

训练 / 推理平台 RAS 小结 ¶

综合已有实践可以看到，训练与推理平台 RAS 已经逐步形成了一条较为清晰的演进路径：从被动告警走向任务视角诊断，从人工排障走向经验沉淀，从事后分析走向在线检测与自动触发，从高层现象观察走向底层运行时与通信事件观测。

对未来的训练与推理平台而言，这些经验的意义并不在于简单复用某个已有工具，而在于确认了一条可扩展的系统建设路径：首先围绕任务建立统一观测与诊断抽象；其次围绕关键指标定义能力边界与建设优先级；最后将 RAS 能力内建到平台调度、通信、观测和恢复链路中，逐步形成面向超大规模集群的系统级可靠性基础设施。

可观测性和 RAS ¶

在超节点规模的分布式训练与推理系统中，RAS 的关键已不再局限于增强单点故障后的恢复能力，而在于系统是否具备足够细粒度、跨层次的可观测能力，以支撑准确的故障检测与根因分析。随着系统由硬件、驱动、操作系统、通信运行时、训练框架到调度平台等多层组件构成，任一层的异常都可能通过复杂的耦合关系表现为任务级性能退化或中断。若缺乏统一的观测与关联机制，系统往往只能识别到“通信变慢”或“训练卡顿”等表层现象，而难以定位其真实来源。因此，构建面向超节点的可观测体系，需要在多层级持续采集运行状态与异常事件，并通过统一时间线进行对齐与关联分析，将硬件信号、系统行为与任务语义进行融合，从而实现从现象到根因的映射能力。

超节点的 RAS 可观测指标 ¶

超节点作为分布式训练的基础设施，可以分为多个层级，包括硬件层（GPU、CPU、RDMA NIC 等）、系统软件层（GPU 驱动、操作系统、通信运行时如 NCCL）、分布式训练框架层（如 PyTorch）、应用层（具体模型与训练任务）以及调度器层（如 Slurm 或 Kubernetes）。这些层级之间高度耦合，单层异常往往会通过系统级联效应放大为全局性能退化甚至任务失败。因此，提升 RAS 的前提在于构建跨层可观测体系，对各层关键指标与异常事件进行持续采集，并通过统一时间基准实现对齐与因果关联分析。在具体实现上，不同层级分别提供不同粒度的观测能力：在硬件层，设备通常具备丰富的底层遥测能力，例如 GPU 的利用率与错误计数、RDMA 设备的队列与重传统计，以及交换芯片在平台与转发面提供的多维度 Telemetry 数据（包括温度、电压、光模块状态、端口速率、流控状态以及基于报文路径的时延、抖动与丢弃原因等），并支持对微突发流量（Micro Burst）与大流量（Elephant Flow）的检测；进一步，通过带内遥测（In-band Telemetry, INT）等机制，可实现路径级的细粒度性能观测与瓶颈定位。在系统软件与运行时层，则可观测调度延迟、I/O 行为、通信操作耗时等系统级与库级事件；在框架与应用层，则通过算子执行时间、训练吞吐、step time 等指标反映任务语义层的运行状态。通过将上述多层信号在统一时间线上进行关联，系统能够将底层设备状态与高层任务行为建立映射关系，从而支撑异常检测、根因分析与性能优化等 RAS 关键能力。下面给出各层关键观测指标与常用工具。

基于 eBPF 的全栈可观测技术 ¶

当前面临的核心挑战并不只停留于单层指标采集能力，而在于如何将这些跨层指标进行时间对齐与因果关联。例如，一次 AllReduce 操作耗时异常，可能源于 GPU kernel 执行抖动，也可能源于 RDMA 传输拥塞，甚至可能由 CPU 调度延迟导致通信线程未及时推进。若缺乏统一的跨层观测视图，运维系统只能看到“通信变慢”的表层现象，而无法判断根因所在。因此，提升 RAS 的关键在于构建自底向上的全局事件视图，将硬件计数器、操作系统事件、通信状态与训练语义进行关联分析。只有实现跨层事件融合与统一时间线重建，才能有效识别灰色故障、性能长尾与隐性退化问题，从而提升 ETTR 与 Goodput，并降低系统级 MTTR。

eBPF 是一种源自 Linux 内核的可扩展机制，允许在不修改内核源码、不重启系统的情况下，动态加载并运行经过验证的用户自定义程序。其核心设计目标是在保证安全性的前提下，为内核和用户态程序提供高性能、低开销的可观测与可扩展能力。eBPF 程序通常使用 C 语言编写，经 LLVM 编译为 eBPF 字节码后加载至内核。加载阶段会经过内核验证器的严格检查，包括内存安全、边界检查、执行路径有界性等验证，确保程序不会破坏系统稳定性。验证通过后，eBPF 程序可被附加到多种挂载点，例如 tracepoint、kprobe、uprobe、或网络数据路径，并以事件驱动方式执行。与传统内核模块相比，eBPF 具有显著优势。首先，它无需修改内核源码或重新编译内核，具备高度非侵入性。其次，程序运行在受限执行环境中，具备强安全保证。再次，借助内核 JIT 编译机制，eBPF 程序可以接近原生代码性能运行。因此，eBPF 在现代 Linux 可观测性体系中逐渐成为核心基础设施。

在分布式训练环境中，eBPF 的核心价值在于构建跨层、低侵入、统一时间线的可观测框架。它既可以观测内核态行为，也可以对用户态库进行动态插桩，从而整合不同层级的观测源，实现 cross-layer 事件关联。

内核态可观测能力。eBPF 原生支持对内核关键路径进行细粒度观测。例如可以挂载在调度器 tracepoint 上获取任务调度延迟、运行队列长度变化等信息；可以挂载在网络协议栈或 RDMA 子系统函数上观测数据包发送、重传及队列状态；也可以跟踪存储 I/O、页错误或内存回收行为。在分布式训练场景中，这种能力可以帮助判断异常是否源于操作系统层。例如，当训练出现长尾的单步耗时时，可以通过调度延迟、软中断占比或 I/O 等待时间判断是否存在系统抖动。当通信出现超时，可以进一步关联网络栈或 RDMA 驱动事件，从而区分网络异常与上层同步问题。

用户态可观测能力。通过 uprobe 机制，eBPF 可以在不修改应用程序源码的情况下，对用户态函数进行动态插桩。这一能力对于训练框架与通信运行时尤为关键。例如，可以对深度学习框架关键 API 进行插桩，采集算子执行开始与结束时间，从而构建算子级时间线；也可以对通信库函数进行插桩，获取 AllReduce、ReduceScatter 等集合通信操作的耗时分布与调用频率。由于无需修改框架代码，这种观测方式对现有训练流程影响极小，符合低侵入设计原则。需要注意的是，eBPF 主要用于函数级事件观测，而不替代完整的框架级 profiler。其优势在于可以与内核事件进行统一时间对齐，实现跨层关联分析。

硬件相关观测能力。eBPF 本身无法直接访问任意硬件寄存器或专有设备内部状态，但可以通过与 perf event 子系统结合，读取 CPU 性能计数器（PMU）。此外，在较新的内核版本中，通过 kfunc 等机制可以访问部分内核导出的函数接口，从而增强观测能力。在 CPU 场景下，eBPF 可以结合 perf_event_open 采集 cycles、instructions、cache miss 等计数器数据，并与具体进程或函数调用进行关联分析。在 GPU 或 RDMA 设备场景中，eBPF 通常通过观测驱动层事件或与用户态监控代理协同，实现间接关联，而非直接读取设备内部微架构计数器。因此，eBPF 在硬件观测方面的优势主要体现在“事件关联能力”，而非完全替代厂商工具。

基于 eBPF 的跨层事件关联。提升 RAS 的关键在于实现 cross-layer 观测指标的统一视图。eBPF 程序之间可以通过 BPF Map 进行高效数据共享，并通过 ring buffer 和共享内存将事件实时传递至用户态分析组件。这种机制使得不同挂载点采集到的事件可以在统一时间轴上进行对齐。例如，可以将一次通信操作的开始时间，与同一时间窗口内的 CPU 调度延迟、RDMA 重传事件和 GPU 利用率变化进行关联，从而识别性能退化的真实来源。相比传统孤立监控方式，这种跨层事件融合能够显著缩短故障定位时间，降低 MTTR。已有研究与系统实践表明，基于 eBPF 的细粒度性能分析框架能够在不侵入代码的情况下，将算子语义与底层系统行为进行关联分析，从而定位性能瓶颈 ⁶。这类工作验证了 eBPF 在 AI 基础设施可观测领域的可行性。

尽管 eBPF 在内核与用户态可观测方面具备明显优势，但在异构硬件环境中仍存在边界。首先，对于 GPU 设备内部执行状态、SM 级别调度或专有计数器，eBPF 无法直接访问。这主要源于 GPU 驱动与硬件实现的封闭性。在实际工程中，通常需要结合厂商工具如 DCGM 或 CUPTI，由用户态模块采集 GPU 指标，再与 eBPF 采集的系统事件进行时间关联。其次，在极端高频事件场景下，若不合理设计过滤策略，eBPF 可能引入额外观测开销。因此在大规模训练环境中，需要通过采样、聚合或分级触发机制控制监控成本。

围绕 GPU 可观测性的增强，已有研究提出两类思路。一类是协同模式，即通过跟踪 GPU 驱动相关内核事件获取粗粒度信息，同时由用户态轻量代理模块调用厂商 API 获取更细粒度指标，并通过共享缓冲区与内核态 eBPF 进行时间对齐。这种方法强调工程可落地性与稳定性。另一类是增强 GPU 可编程能力，通过在 GPU 内核执行路径中注入额外指令实现更细粒度观测。这类方法在研究环境中具有探索意义，但在生产环境中仍需综合考虑稳定性与兼容性。

总体而言，eBPF 并非替代所有监控工具，而是作为跨层事件关联的核心枢纽，与现有工具协同构建统一可观测框架。

基于超节点的模型训练和推理传统依赖 checkpoint 的被动恢复机制难以应对灰色故障、性能长尾与跨层耦合问题。构建统一、低侵入、跨层关联的可观测体系至关重要。eBPF 通过在内核态与用户态提供动态插桩能力，使系统能够在不修改训练代码的前提下采集关键事件，并通过统一时间线实现硬件、操作系统、通信运行时与训练语义之间的关联分析。尽管在 GPU 等异构硬件场景下仍需与厂商工具协同，但其作为跨层事件融合枢纽的角色具有独特优势。

面向未来的分布式训练基础设施，以 eBPF 为核心构建可观测与事件关联框架，有望实现快速故障定位、性能退化识别与预测性维护，从而提升 ETTR 与 Goodput，降低 MTTR，并在规模扩展条件下保持稳定、高效与可运维的系统运行能力。

RAS 系统最佳实践 ¶

综合前文硬件为中心与软件为中心两条路线的讨论，超节点的 RAS 体系最终要落到一条完整闭环上：预防 → 检测 → 恢复 → 复盘。只有当这条链路持续运转起来，RAS 才不再只是设计原则，而会真正变成系统每天都在执行的运行机制。以下从指标体系、Telemetry 管线和故障演练三个维度给出建议框架。

RAS 指标清单与目标值 ¶

上述目标值应视为工程起点而非终态。随着集群规模持续扩展，万卡级场景下的集群 MTTF 不可避免地缩短，系统设计的重心应从 " 延长 MTTF" 转向 " 压缩 MTTR + 提升灰色故障检出率 "。NVIDIA Blackwell RAS Engine 所代表的芯片级预测性 RAS 正是这一思路在硬件层的具体体现 ¹ .

Telemetry 管线与告警分级 ¶

端到端的 Telemetry 管线应覆盖 " 采集 → 汇聚 → 关联 → 告警 → 归档 " 五个阶段：

1. 采集层：各层按照前文观测指标表部署 Agent（芯片 DCGM、网络 perfquery/ethtool、OS eBPF、NCCL 插桩、框架 Profiler），以 ≤ 1 s 粒度输出时间戳对齐的指标流。
2. 汇聚层：通过 Kafka / NATS 等消息总线将多节点指标汇聚到集群级时序数据库（如 VictoriaMetrics / Thanos），保留 ≥ 7 天的全量原始数据和 ≥ 90 天的降采样聚合数据。
3. 关联层：利用统一事件 ID 和微秒级时间戳，将跨层事件在同一时间线上对齐；对 AllReduce 超时事件，自动下钻关联 GPU Xid、RDMA 重传、CPU 调度延迟等上下文。
4. 告警层：实行三级告警——P0（作业中断 / UE / 链路断连，立即触发自愈或值班响应）、P1（性能退化 >15% / CE 突增 / Pre-FEC BER 趋近阈值，5 分钟内响应）、P2（轻微抖动 / 温度预警，纳入日报复盘）。
5. 归档层：所有故障事件形成结构化 Incident Record（时间戳、根因分类、影响范围、恢复动作、耗时），输入故障知识库，用于后续根因建模与预测性维护。

典型故障剧本与演练计划 ¶

建议以季度为周期开展全规模故障演练，在每次演练后更新故障剧本、校准告警阈值、并将新发现的故障模式纳入知识库。演练结果应直接反馈到 RAS 指标看板，驱动指标目标的持续收敛。