硬件故障会对 AI 训练和推理产生重大影响。静默数据损坏（SDC，指由硬件导致、未被检测到的数据错误）对 AI 系统的危害尤为严重——这类系统无论是训练过程还是生成有用输出，都依赖于准确的数据。本文将分享 Meta 在不同规模下，为检测 AI 和非 AI 基础设施中的静默数据损坏所采用的方法，这些方法有助于确保 Meta 旗下所有 AI 训练 和推理工作负载的可靠性。
Meta 的全球 AI 基础设施由大量硬件组件和服务器构成，这些组件和服务器通过网络架构连接，分布在全球各地的数据中心中。该架构整合了存储、计算和网络体系，并搭配了为训练或推理工作负载量身定制的专属文件系统和 PyTorch 应用。这一基础设施既支持大规模模型的训练，也能为文本生成图像、目标分割等先进 AI 应用提供支持。
自 2018 年以来，Meta 在硬件可靠性领域的探索取得了多项创新性发现：我们识别出了磁盘、CPU、内存、交换机、GPU、专用集成电路和网络中独特的故障类型，在发现故障模式方面常常走在行业前列。我们还制定了缓解策略，以确保基础设施平稳运行并保持可用性，从而服务数十亿用户和数千个内部用例。随着我们持续构建大型 AI 集群，理解硬件故障及缓解策略对于大规模 AI 模型的可靠训练至关重要。
大规模模型的训练需要在同步环境中使用数千个加速器，任何组件故障都可能中断甚至终止训练过程。我们的工作重点包括：通过检测和诊断减少训练期间的硬件故障，以及利用正常的服务器和加速器快速重启训练。这涉及优化故障分类、设备优先级排序、节点选择、集群验证和检查点恢复。
从运行 Llama 3 系列模型的经验来看，我们发现静态随机存取存储器（SRAM）、高带宽内存（HBM，GPU 专用的高性能内存）、处理网格（processing grids，指 GPU 中用于并行计算的核心阵列）和网络交换机硬件等组件的故障，会严重影响 AI 集群的可靠性——超过 66% 的训练中断都由这类故障导致。
AI 集群面临的部分挑战包括：
- 由于结构复杂且遥测数据（telemetry，指设备实时采集并上报的运行状态数据，如温度、电压、错误日志等）有限，加速器的可靠性可能低于 CPU；
- 网络结构复杂可能导致故障归因错误；
- GPU 软件栈中的错误可能需要大量配置调整才能修复。
因此，减少硬件和配置故障能显著提升集群效率。
关键问题
Meta 的静默数据损坏（SDC）检测机制严重依赖故障的可重现性，但在实际生产中，SDC 往往与数据、电压、温度等多种因素强相关，难以稳定复现。Meta 如何保证其检测机制（如 Fleetscanner、Ripple）在不可重现的 SDC 场景下依然有效？是否意味着某些“不可检测”的 SDC 仍会持续影响模型训练与推理？
Meta 承认 SDC 的检测确实受到数据依赖性、电气状态、温度变化与设备老化等因素的影响，导致某些 SDC 难以稳定复现。为此，Meta 并未依赖单一检测机制，而是构建了三层互补的检测体系，以最大程度覆盖不同表现形式的 SDC：
- Fleetscanner：通过周期性（每 45-60 天）的全集群微基准测试，捕获性能异常。虽然较慢，但能系统性地筛查硬件缺陷，尤其适用于在维护窗口中进行深度检测。
- Ripple：以毫秒至秒级的速度与工作负载协同执行测试，实现数天内完成全集群覆盖。其通过跨核心与线程的重叠测试指令，显著提升了检测速度，更适合捕捉间歇性、负载依赖的 SDC。
- Hardware Sentinel：这是一种与测试和架构无关的分析层方法。它通过监控内核空间的应用异常，直接识别核心级别的静默数据损坏，无需依赖故障复现。后文也指出，该方法在跨架构、应用和数据中心的检测效果上，比基于测试的方法高出 41%。
Meta 通过组合机制大幅提升了 SDC 的检出率，尤其是 Hardware Sentinel 在不可复现场景下具有独特价值。然而，文中也暗示“未知的未知”故障仍然存在，且 SDC 的数据依赖性使得 100%检测在工程上不可行。因此，Meta 的策略是“尽可能检测，并为未能检测的 SDC 设计韧性架构”，例如通过算法容错（Algorithmic fault tolerance）来减轻未被捕获的 SDC 影响。
Meta 提出的多种 SDC 缓解策略如超检查点、梯度剪裁、三变量计算训练架构等，虽然能提升系统韧性，但往往以显著增加计算开销、存储负担或架构复杂性为代价。这是否意味着 Meta 在硬件可靠性上的投入实质上是以“牺牲整体计算效率与成本”为代价？在追求 AI 规模化的同时，这种“可靠性税”是否可持续？
Meta 明确认识到提升硬件可靠性会带来计算、存储与架构复杂性的开销，但将其视为规模化 AI 训练与推理的必要投入，而非纯粹的“代价”。后文指出，Meta 通过以下方式在可靠性与效率之间寻求系统性平衡：
- 分层实施策略，按需引入开销：
- 对于训练任务，采用“超检查点”（Hyper-checkpointing）时，会权衡检查点频率与存储/恢复开销，通常只在关键训练阶段或高故障风险集群中提高频率。
- 三变量计算训练架构虽然引入影子节点与冗余计算，但仅用于对故障特别敏感的大规模同步训练，并非全域启用。
- 算法与硬件协同优化：
- 梯度裁剪等算法级策略，以极小的计算开销防止 NaN 传播，属于“高性价比”的韧性增强。
- 参数脆弱性因子（PVF） 分析允许将关键模型层映射到更可靠的硬件上，而非全面提升所有硬件的可靠性，从而实现精准的资源分配。
- 长期演进与标准化降低成本：
- Meta 通过推动行业合作如与 Google、微软、AMD、NVIDIA 等制定测试架构与标准，旨在降低全行业的可靠性实现成本。
- 其自研的MTIA（Meta 训练与推理加速器） 采用“工厂到集群”的全生命周期可靠性设计，在芯片设计阶段就植入健康监测与预警机制，从而减少后期运维中的检测与修复开销。
Meta 并未将可靠性视为“静态税赋”，而是作为一个持续优化的系统工程问题。虽然短期内某些策略会增加开销，但通过分层设计、算法协同、行业合作与芯片级内建韧性，Meta 致力于在确保训练稳定与推理正确的前提下，将可靠性相关的额外开销控制在可接受且持续降低的范围内。
后文也强调，对于大规模 AI 集群而言，“因 SDC 导致的训练无效或推理错误所带来的资源浪费与业务风险，远高于预防与检测机制的投入”。
- 硬件可靠性：GPU 本质上比 CPU 更不可靠，单个 GPU 故障就可能导致整个训练过程终止。
- 网络复杂性：网络基础设施结构复杂，排查网络问题耗时较长。
- 软件配置：与 GPU 相关的软件需要大量配置，过程中容易出现错误。
| 故障类型 |
占比 |
| GPU 散热问题（GPU Thermal） |
1.4% |
| NCCL 监控程序（NCCL Watchdog） |
1.7% |
| 网络接口卡（NIC）故障 |
1.7% |
| GPU 系统进程（GPU SysProc）故障 |
4.1% |
| GPU SRAM 故障 |
4.5% |
| 故障 GPU（Faulty GPU） |
35.3% |
| 主机维护（Host Maintenance） |
7.6% |
| 交换机/线缆（Switch/Cable）故障 |
8.4% |
| 软件漏洞（Software Bug） |
12.9% |
| GPU HBM3 相关故障 |
17.2% |
我们在基础设施中观察到的硬件故障或错误，大致可分为三类：
1.1 静态错误（Static errors）
硬件故障通常表现为二元状态：设备要么能启动，要么无法启动。在大规模设备集群中，这类静态错误很容易识别。
如果设备无法启动或枚举（enumerate，指系统识别并初始化硬件设备的过程），通过简单的健康检查就能验证其是否存在及配置是否正确。随着大型训练集群的配置复杂度和设备规模不断增加，这类故障的发生频率会更高，但它们的优先级排序、根本原因定位和修复过程相对简单，因此在大规模场景下仍可管理。
1.2 瞬态错误（Transient errors）
瞬态错误的核心特征是“可复现性差异”，包括负载依赖型故障如热失控导致的设备问题，或部分可观测故障如不可纠正错误引发的随机崩溃。
缓解这类错误需要先理解其触发条件；而我们的大规模设备集群有助于优先级排序和模式匹配，从而为这些触发条件设置“陷阱”——一旦触发，设备就会被标记为需要缓解或修复。超大规模基础设施中可靠性、可用性与可维护性（RAS）遥测技术的进步，极大地改进了这一过程。工作负载敏感度、温度范围、频率、制造参数等因素都会导致这类错误的发生。
缓解瞬态错误的另一种方法是：在非生产阶段通过人工负载模拟触发条件，让故障更容易复现。此外，将瞬态状态记录为“持久化”（sticky）状态值，可为硬件故障提供遥测指示。尽管瞬态错误的发生频率低于静态错误，且更难检测，但凭借 Meta 的设备规模和大量工程投入，我们已能检测到这类故障场景。
1.3 静默错误（Silent errors）
静默错误（又称静默数据损坏，SDC）指硬件计算出错但未留下可检测痕迹，导致应用程序使用错误结果的情况。这类错误通常由芯片缺陷引起，除非观察到显著异常，否则可能长期未被发现。要检测它们，需要大量工程投入和高成本的遥测系统，才能将数据损坏追溯到具体设备。由于缺乏遥测数据且错误会持续影响应用，这类故障对大规模服务的危害极大。
多个案例（例如某次计算错误导致 Spark 应用中出现数据行缺失）表明，超大规模基础设施中静默错误十分普遍。
过去，与软错误（soft error，指由外部因素如宇宙射线导致的临时数据错误）相关的位翻转（bitflip，指数据位从 0 变为 1 或反之的错误）发生率已降至每百万台设备 1 次；但随着加速器芯片密度的提升，静默数据损坏的发生率已升至每千台设备 1 次左右，远高于宇宙射线引发的软错误。
二、静默数据损坏（SDC）带来的主要挑战
在超大规模基础设施中，SDC 因“数据依赖性”带来巨大挑战——要覆盖所有可能的数据值以测试 SDC，需要的测试空间呈指数级增长，在实际中完全不可行。这类故障还与设备电压、频率、工作温度和生命周期相关。
例如，某台设备可能在使用数月后才出现计算检查失败的情况，这表明设备已进入“损耗期”（wear out，指硬件因长期使用导致性能下降或故障概率上升的阶段）。因此，在设备整个生命周期内，必须通过一致、定期且频繁的随机状态空间测试，才能识别出这些计算偏差。
三、从 1 个 SDC 到数百个 SDC：我们如何扩展检测方法？
3.1 创新的 SDC 检测机制
为保护应用免受静默数据损坏影响，Meta 采用了多种检测机制，相关细节已在《Detecting Silent Errors in the Wild》和《Hardware Sentinel》两篇论文中详细阐述。
1. Fleetscanner（集群扫描器）
Fleetscanner 通过针对性的微基准测试（micro-benchmarks，指用于检测硬件特定功能的小型、高效测试程序），在大规模设备集群中捕捉性能异常值，从而识别硬件缺陷。
这些基准测试的特征会被整合到遥测系统中，用于非基准测试场景下的检测。该方法会在固件升级、硬件维修等维护操作期间运行定向测试，并定期安排测试任务，确保每 45 至 60 天覆盖所有设备。尽管它能在主机上提供专门的测试，但对于部分 SDC 而言，检测速度可能过慢。
2. Ripple（涟漪检测工具）
Ripple 与工作负载协同部署，测试执行时间仅需数毫秒至数秒，因此能在数天内实现全集群覆盖。它会在多个核心和线程间重叠执行测试指令，检测速度比 Fleetscanner 更快。
3. Hardware Sentinel（硬件哨兵）
这是一种创新的、与测试和架构无关的方法，通过分析内核空间（kernel space，指操作系统内核运行的内存区域，用于管理硬件和系统资源）中的应用异常来检测 SDC。
它无需分配专门的测试资源，仅在分析层面运行，就能识别出与核心相关的异常并将其判定为静默数据损坏。在不同架构、应用和数据中心环境中，Hardware Sentinel 的检测效果比基于测试的方法高出 41%。
上述三种机制相结合，实现了目前行业内领先的大规模集群覆盖能力，能有效检测并保护我们的基础设施免受 SDC 影响。
四、AI 硬件中的静默错误
上文描述的方法已在全集群范围内部署并完全投入生产，可检测 AI 和非 AI 基础设施中的 SDC。但训练、推理等 AI 应用在应对 SDC 时，面临着独特且更严峻的挑战。
4.1 训练工作负载中的 SDC
训练工作负载中的 SDC 会导致计算错误，同时影响前向传播和，进而导致训练偏离预期路径，影响训练效果。尽管有时人们认为 AI 训练工作负载对 SDC 具有“自恢复能力”，但这种能力仅适用于极少数 SDC 场景。
在大多数实际情况下，自恢复能力远远不足：
- SDC 会在迭代过程中持续存在；
- 而且 AI 训练中数据值的量化（quantization，指将高精度数据转换为低精度数据以提升计算效率的过程）会增加每比特数据的信息量，这会加剧 SDC 的影响，导致训练工作负载的偏离速率不断上升。
以下是两种最常见的、由 SDC 导致的训练偏离场景：
场景1：非数字值（NaN）传播
当 SDC 导致某个可表示的值变为错误表示形式时，就会在训练计算中生成非数字值（NaN，指无法表示为有效数字的特殊值，如 0 除以 0 的结果）。
一旦生成 NaN，它就会在后续计算中不断传播，影响训练迭代、加速器域（accelerator domain，指由多个加速器组成的计算单元）、主机域（host domain，指运行训练控制程序的主机），最终波及整个集群。
这种大范围的“NaN 污染”可能导致集群瘫痪，而其根源（通常是单个加速器上的少数特定计算）在集群的庞大规模下可能难以追踪。要解决这一问题，必须识别并隔离存在问题的加速器和节点。
场景2：梯度方差损坏
当 SDC 影响梯度计算时，会导致梯度爆炸、梯度消失或陷入局部最小值。
这种损坏虽在数值范围内，但会被错误地判定为正确结果，进而在同步训练中影响整个集群。损坏的值会作为“正确值”在集群中传输，导致训练看似在推进，实际却毫无改进。随着时间推移，SDC 的影响会不断累积，导致梯度出现严重偏离，可能使算法陷入局部最小值，或引发梯度爆炸/消失。
检测这类 SDC 难度极大：一方面，它们的影响十分隐蔽；另一方面，观察到其效果可能需要数周甚至数月时间。
与 NaN 传播不同，这类损坏不会触发 NaN 陷阱，因此更难追踪和修复。结果就是，SDC 会导致计算资源和训练迭代被大量浪费。若无法检测，根本原因将始终不明，除非识别并隔离存在问题的设备，否则后续训练仍会面临风险。
4.2 推理工作负载中的 SDC
在推理应用中，SDC 会导致输出结果错误；由于推理操作的规模庞大，这类错误会影响数千名推理服务使用者。持续存在的 SDC 可能直接影响推荐引擎、大型语言模型（LLM）输出等系统的决策。这些损坏还可能绕过隐私或完整性相关策略，因为它们不受边界限制。
因此，推理阶段的损坏会大幅降低投入大量计算资源训练出的模型的效用，使得看似无风险的推理场景在大规模应用下出现严重问题。
五、SDC 的影响
无论是训练集群还是推理集群，SDC 都会在数千个组件中引发复杂的故障排查场景。
在训练中，显性故障（如设备离线）会直接导致集群停滞，但 SDC 会制造“训练正常推进”的假象，从而掩盖故障根源。
- 对于 NaN 传播，若未识别出存在问题的节点，即使从检查点重启训练，最终仍会失败；
- 对于梯度方差损坏，这种“假象”会持续更久，直到方差累积到一定程度，此时重启训练也无济于事。
因此，SDC 会导致严重的计算效率低下，其时间层面的影响比显性故障更大。
在推理中，故障排查需要在每个子阶段采集高成本的遥测数据。在识别出存在问题的节点前，推理集群无法投入使用，且存在重复损坏的风险。异常检测工具（anomaly detectors）较易识别大幅偏离，但小幅偏离则需要大量排查工作。这一过程通常需要数百名工程师参与，导致生产用例停滞，影响服务生产的可靠容量。
六、AI 工作负载中 SDC 的特点
- 持续性（非瞬态）：重启设备或服务无法消除 SDC，最终仍会再次遇到。
- 量化加剧难度：高阶多比特翻转（指多个数据位同时发生错误）比低阶比特翻转的影响更大；量化过程中，数据位数减少且每比特信息量增加（通常也不只是“单个比特”翻转），这会进一步增加 SDC 的检测难度。
- 非宇宙射线导致：SDC 的危害远大于单一服务故障——它会影响整个集群，而非服务的某个局部环节。
七、AI 硬件中 SDC 的检测与缓解策略
Meta 在基础设施中部署的、用于应对 AI 训练工作负载中 SDC 的缓解策略，可分为“基础设施策略”和“栈策略”两类：
7.1 基础设施策略（Infrastructure strategies）
这类策略在集群层面的运营排查中应用，聚焦于通过物理和网络基础设施管理、缓解 SDC，确保硬件和系统级组件具备足够的鲁棒性，能有效处理错误。
（1）归约排查（Reductive triage）
该策略通过在规模逐渐缩小的集群上运行小型训练迭代，执行二分查找（binary search），以隔离 NaN 传播的根源。其目标是找到一个能复现 NaN 问题的小型集群，从而将存在问题的节点隔离，以便进一步调查。之后，用新节点重组集群，即可从保存的检查点恢复训练。
但该方法依赖于 SDC 的可复现性——由于 SDC 受数据、电路和温度变化影响，复现并非总能实现。对于梯度方差损坏，可采用类似的“拆分排查”方法，但即便超参数保持一致，其效果也会因训练数据和集群规模而异。
（2）确定性训练（Deterministic training）
该方法通过运行一个已知有效的模型，执行少量训练迭代，验证是否存在 NaN 或梯度偏离。它有助于检测与数据无关的计算故障，因为对于特定的数值集和训练输入，该方法能保证计算结果的正确性。
（3）超检查点（Hyper-checkpointing）
该方法通过提高检查点的创建频率，更快地识别和隔离存在损坏问题的节点。它能在维持训练吞吐量的同时，将 NaN 传播限制在特定加速器或主机范围内，从而加快排查和隔离过程。
7.2 栈策略（Stack strategies）
这类策略需要与工作负载协同，在软件栈层面进行调整和增强，包括在应用和软件层实现错误检测与纠正机制，以更有效地处理训练过程中的 SDC。
（1）梯度裁剪（Gradient clipping）
该策略通过在训练工作负载中强制实施梯度裁剪，将梯度值限制在指定范围内，从而缓解 NaN 传播。对于超出范围的计算结果，会进行裁剪；在此过程中，可通过根据操作数符号将 NaN 设置为最大值或最小值，来检测 NaN。
尽管该方法对部分格式表示的 NaN 有效，但在某些情况下可能引入局部错误。
（2）算法级容错（Algorithmic fault tolerance）
这是一种鲁棒性较强的方法，将容错能力集成到训练算法中，以应对多种数据损坏情况，减少对检测和排查的依赖。正如在 CPU 训练中所验证的，该方法能以极小的开销提升计算效率。实施该方法需要了解常见的缺陷模式，并在整个软件栈中投入工程资源，同时对训练工作负载的保障范围进行调整。
（3）三变量计算训练架构（Tri-variate computational training architecture）
该方法在同步训练中使用“影子节点”（shadow nodes，指与主训练节点并行运行、用于验证计算结果的备用节点）来缓解 SDC。
训练步骤会在随机迭代中在不同节点上重复执行，验证无误后再确认训练进度。若影子节点与主节点（live nodes）的结果不一致，训练会暂停，仅对这些节点进行调查，其余节点则更换新节点后继续训练。该方法需要多个影子节点池、一个随机训练节点池，以及从同一检查点开始的指定训练步骤。它能提供鲁棒的训练保障，但需要对算法进行大幅修改，且会增加数据传输量和基础设施开销。
（4）参数脆弱性因子（Parameter vulnerability factors, PVF）
该方法通过识别机器学习架构中的脆弱层（vulnerable layers，指易受 SDC 影响的模型层）和抗干扰层（resilient layers，指不易受 SDC 影响的模型层），将脆弱层映射到抗干扰硬件（如具备 ECC 纠错功能的内存），抗干扰层映射到非保护硬件，从而优化资源分配。
这种动态评估需随架构演进不断调整。由于抗干扰能力通常需要在面积、功耗或性能上付出代价，PVF 能实现“针对性抗干扰设计”，尤其适用于推理场景。
（5）偏离检测（Divergence detection）
该机制为每个神经元维护一个分布图谱，通过检测神经元输出是否偏离典型分布，识别推理过程中的损坏。尽管该方法成本较高，但可通过设置特定采样率，应用于大规模推理场景。通过记录特定工作负载下每个神经元的行为，能在执行过程中检测到损坏。
尽管我们已对上述方法进行优化，使其能在我们的基础设施中有效运行，但需注意的是：这些方法提供的抗干扰能力水平不同，且各有特定的运行条件和工程/基础设施开销。根据训练和推理工作负载的规模与强度，有效协调这些策略，可减轻 SDC 对 AI 应用的不利影响。
八、性能故障与未知未知（Unknown Unknowns）
尽管 SDC 是超大规模场景下的主要挑战，但 Meta 也在开发检测性能退化的解决方案。例如，ServiceLab 是一个大规模性能测试平台，能在超大规模场景下识别微小的性能退化；此外，Fleetscanner 已发现数百个性能异常值，这些异常值与 SDC 一同被视为一种“新兴故障模式”（emergent fault mode）。
目前的机制虽能检测并处理静态、瞬态和静默故障，但硬件故障的所有变体仍未被完全覆盖。“未知未知”（指无法预见的故障类型）需要在整个基础设施和芯片生命周期中，以及从硬件到软件、再到应用的全栈中采用灵活的解决方案，才能实现一流的可靠性运营。
九、迈向行业领先与标准化的历程
Meta 在 SDC 领域迈向行业领先的历程始于 2016 年（识别集群中的常见问题），2018 年实现 SDC 检测的规模化，2019 年部署检测框架；2020 年，检测机制被集成到加速器中，Meta 发表论文《Silent Data Corruptions at Scale》；2022 年，Meta 推出“FleetScanner 和 Ripple”，并发起学术奖励招标（RFP），为 5 个获奖项目提供资金支持。
2023 年，Meta 与谷歌、微软、ARM、AMD、英伟达、英特尔等行业领军企业合作，共同提升服务器抗干扰能力，定义测试架构和指标；Meta 还与开放计算项目（Open Compute Project，一个推动数据中心硬件标准化的开源社区）的合作伙伴联合发起招标，选出 6 个跨领域 SDC 研究项目的获奖者。
2024 年，Meta 的集群在生产环境中部署了先进的 AI SDC 检测方法，并通过在主要会议和论坛上发表论文、举办教程和演讲，分享研究成果，解决大规模场景下的可靠性挑战。
Meta 正全力推进“Meta 训练与推理加速器”（MTIA）系列产品的研发。在这一过程中，我们的目标是将从集群运营中吸取的所有经验应用于 MTIA 的架构和设计，打造行业领先的集群可靠性实践。
通过“从工厂到集群”（factory-to-fleet，指覆盖芯片从出厂到集群部署全生命周期的管理和优化）的方法，并在全软件栈中持续优化可靠性解决方案，我们旨在开发出一款同类领先、兼具可靠性与高性能的产品，将其纳入我们的 AI 硬件基础设施组合，为大规模 AI 应用提供动力。
10.1 从工厂到集群（Factory to fleet）
要尽早发现未知问题，关键在于全面掌握芯片从工厂到集群的全生命周期视图。从设计到部署的每个阶段都需要创新：
- 在设计和架构阶段，重新优化面向大规模场景的 RAS 解决方案、生命周期调试接口（lifecycle debug hooks，指芯片中用于在全生命周期内排查故障的硬件接口）和遥测架构，为 Hardware Sentinel、Fleetscanner、Ripple 等工具提供支持。
- 在验证和集成阶段，通过创新的良率分析（yield analysis，指对芯片生产合格率的分析）、制造诊断和基于集群特征反馈的检测，在设备出厂前预防故障。
- 在 AI 芯片集群中，用户空间诊断结合定期测试、覆盖测试图谱和控制参数，能带来显著收益。
- Hardware Sentinel 等大规模分析工具可检测早期损耗和数据损坏；强大的固件接口和调试架构能在集群规模故障发生时，快速向设计和架构团队反馈信息。
10.2 栈级抗干扰能力（Stack-level resilience）
“从工厂到集群”的解决方案为芯片提供了全生命周期的抗干扰能力，但抗干扰能力需要超越芯片本身，延伸到固件、编译器、内核和操作系统层面：
- 对于指令异构性的正确性不变性，以及用于异常追踪的增强遥测，需要投入资源构建抗干扰架构。
- 精细化的固件控制机制能在检测到故障时提升遥测数据的质量。
- 在软件和应用层面，本文提及的梯度裁剪、算法级容错等技术，对于在数据损坏场景下保障安全性至关重要。
从 SDC 应对经验来看：
- 对于许多 SDC，在线软件抗干扰和与测试无关的分析方法能以极少投入实现规模化应用；
- 而基于测试的方法仅适用于特定指令。
硬件故障对 AI 训练和推理生产环境的影响显著。随着集群规模和半导体复杂度的增长，故障复杂度将呈指数级上升。解决方案必须涵盖“从工厂到集群”的协同，以及栈级抗干扰能力。对于 AI 应用而言，将可靠性作为核心设计考量至关重要。
本文深入探讨了Meta在大规模Transformer模型训练场景下保障硬件可靠性的前沿实践。对于更多AI基础设施与系统工程深度解析，欢迎关注云栈社区的技术分享。
发表于 昨天 00:32
|
查看: 0|
回复: 0
