★ FEATURED ARTICLE 2021年前后我参与过一个训练集群的稳定性专项。最初目标很朴素把每周的作业中断次数压下来。真正翻日志才发现问题根本不能笼统概括成机器坏了——有的是直接报错退出有的是默默算错却一路不报警还有的连跑十几个小时才在某个特定 kernel 上崩掉。那段时间我们把面向人工智能AI的硬件可靠性这个词翻来覆去地拆才意识到它和传统服务器的可靠性完全不是一个量级的问题负载是 7×24 满载、内存带宽长期饱和、片上 SRAM 动辄上百兆比特、工艺节点又压到 7nm 以下任何一点微小的物理扰动都会被放大成几天甚至几周的算力浪费。这篇就按我当时的拆解路径来写先讲清楚 AI 硬件为什么更容易坏、坏了更贵再讲失效机理、架构级加固、系统级兜底、验证评估最后给一份能直接抄的排查清单。适合做 AI 芯片架构、训练平台运维、系统软件和可靠性工程的同行参考刚入行的同学也能看懂大框架。1. 先弄清 AI 硬件可靠性到底在解决什么问题很多人第一次接触这个话题会下意识把它等同于服务器别宕机。这个理解放在传统业务上没错放在 AI 上就偏了。传统业务的可靠性目标是可用性——服务不中断请求有响应偶尔算错一个字段大不了重试一次。AI 训练的目标是计算结果的正确性与任务的完成效率一次静默的数值错误可能让一个跑了三周的作业白费而一次明确的宕机反倒是最友好的故障因为它至少能被感知。1.1 可靠性设计的目标是期望损失最小化不是失效率最小化这是我在项目里被反复纠正的一个认知。工程上我们习惯盯 FIT 数字觉得把失效率压到某个阈值就完事了。但 AI 场景下真正该算的是一笔经济账单次故障的代价乘以故障频次再加上为降低故障付出的面积、功耗、性能开销三者取得平衡才是合理设计。举个具体的对比。一颗 AI 加速卡上有 100 Mbit 的片上 SRAM假设没做任何保护按地面中子环境的典型软错误率 10⁻³ FIT/Mbit 估算整块 SRAM 的失效率大概是 0.1 FIT。折算成 MTBF 是 10¹⁰ 小时看起来几乎永远不会坏。可是故障一旦落在 softmax 的分母、LayerNorm 的统计量或者优化器的动量缓存上后果不是少算一个结果而是整个训练发散、需要回滚到几天前的检查点。把单次代价按几万卡时算进去这个几乎不会坏的概率就完全不划算了。反过来如果给这 100 Mbit 全部上三模冗余面积翻三倍、功耗翻三倍、时序还过不去同样不划算。所以真实的设计永远是在选择性加固把最关键的 5% 状态位保护到极致剩下的靠上层兜底。提示做可靠性预算时务必把错误被发现的时间延迟作为独立变量计入。一个 1 小时后被发现的错误和一个 3 周后才被发现的错误损失差好几个数量级但它们在最底层的 FIT 数字上完全一样。1.2 AI 负载把硬件推到了传统可靠性模型的边界之外传统数据中心服务器的可靠性模型建立在短时突发计算 大量空闲的负载画像上。CPU 大部分时间利用率在 20% 以下温度在阈值附近来回波动老化进程相对温和。AI 训练完全是另一回事加速卡连续几个月跑在 90% 以上的利用率和接近 TDP 的功耗上结温长期贴着温度墙供电电流持续拉满。这种负载画像带来三个连锁反应。第一是老化加速高温高压长期共存会显著加快偏置温度不稳定性和热载流子注入的进程器件参数漂移在两年内就能积累到肉眼可见的程度。第二是热循环疲劳虽然稳态温度高但作业切换、负载波动仍然会造成结温在几十度范围内反复变化焊点和封装材料在这种循环下会逐步产生微裂纹。第三是暴露窗口变长瞬态故障本质上是概率事件单位时间的翻转概率固定跑得越久累计被打中的概率越高。一台跑 8 小时的机器和一个跑 8 周的作业面对的风险完全不是一个量级。1.3 2021 年这个时间点的特殊性把时间锚定在 2021 年前后是有原因的。那两年模型参数从亿级跳到千亿级单次训练从几天变成几周甚至几个月单集群从几百卡扩到几千卡。这几个数字一乘故障就从实验室里的奇观变成了运维的日常。我算过一笔很直观的账假设单卡的统计失效率是 5000 FIT这个量级在加速卡上不算离谱整机加板卡加内存加电源一起统计那么 1000 张卡的集群总失效率是 5×10⁶ FIT换算下来平均每 200 小时就会出一次故障也就是八天多一次。如果集群规模扩到一万卡MTBF 直接掉到 20 小时一天至少一次。这个频率下坏了就重启的做法彻底失效必须从架构层面设计容错和快速恢复。这大概就是那几年行业把 RAS可靠性、可用性、可服务性从整机层面下沉到加速器内部设计的直接动因。1.4 四条主线别混着谈我把整个问题拆成四条互不相同的主线后面所有章节都围绕它们展开。瞬态故障来自外部辐射和封装材料的微量放射性元素特点是随机、可恢复、不损伤器件。永久故障与老化来自器件物理退化特点是随时间累积、不可逆。静默数据损坏不是一种独立失效机理而是前两者的一种结果状态——错误发生了但没人发现。环境与供电相关故障则是温度、电压、电流瞬变引起的时序违例和功能异常。这四类的检测手段和缓解手段完全不同混在一起谈必然抓瞎。失效类别典型诱因时间特征是否可恢复主要检测手段瞬态故障中子、α 粒子、电源噪声随机、瞬时是重算/纠正奇偶校验、ECC、CRC老化失效偏置温度不稳定、热载流子、电迁移缓慢累积、不可逆否只能降级老化传感器、频率裕量监测静默数据损坏上述两者未被检测的部分潜伏期长视场景端到端校验、结果比对供电与热异常负载瞬变、散热劣化突发或渐变多数可恢复电压监测、温度传感器2. 失效机理拆解AI 芯片到底会怎么坏做架构设计最怕的就是知道要加固但不知道在加固什么。这一节把物理层面的机理摊开讲因为只有理解了错误是从哪来的、以什么形态出现才能判断在哪个抽象层拦截成本最低。2.1 瞬态故障单粒子翻转在 AI 负载下的放大效应高能中子或封装材料中的 α 粒子穿过硅片时会沿轨迹电离出一串电子空穴对。如果这个电荷量超过存储单元的临界电荷存储的位就会翻转这就是单粒子翻转。存储单元越小、供电电压越低临界电荷越小翻转越容易发生。所以工艺越先进这个问题的绝对数量反而可能上升虽然单比特的截面在缩小但单位面积集成的比特数涨得更快。AI 芯片对这个特别敏感原因在于它的存储密度。一颗训练卡上寄存器堆、共享内存、各级缓存加起来可能有好几百兆比特的片上存储其中相当一部分没有完整的 ECC 保护。权重、激活值、梯度、优化器状态都在这些空间里来回倒腾。更麻烦的是放大效应。推理场景下一个权重位翻转可能只影响一个输出 token用户根本察觉不到。训练场景完全不同一个被翻转的梯度会通过反向传播影响参数更新进而污染后续所有 step 的优化轨迹一个在 LayerNorm 统计量上的翻转会让整层输出偏移然后被后续几十层的矩阵乘不断放大。我见过一次典型的案例某次作业在第 3000 步附近 loss 突然抬高一个台阶然后再也不降事后定位就是某一层的归一化统计量在某张卡上出现了偏差。这里必须引入一个概念架构脆弱因子。它的含义是在所有可能被翻转的位中真正会影响程序最终正确结果的比例。显然不是所有位都同等重要——被 mask 掉的 token、padding 区域、已经超出裁剪范围的梯度翻了也不影响结果。所以实际的软错误率是原始翻转率乘以架构脆弱因子。做架构评估时如果只看原始翻转率会严重高估风险导致过度加固只看最终结果又容易漏掉关键路径。我的经验是先做一轮架构脆弱因子分析把翻转后确实会改变最终 loss的位筛出来再做针对性加固性价比最高。还要注意多比特翻转。先进工艺下一次粒子入射可能同时影响物理上相邻的几个单元而这些单元在逻辑地址上可能恰好属于同一个纠错字。所以光有单比特纠错不够存储阵列必须做交织——把逻辑上相邻的位在物理上分开放保证一次扰动最多打到每个纠错字的一位。交织的粒度要考虑工艺的电荷扩散半径这个参数必须找工艺厂要不能凭感觉定。2.2 老化失效慢变量才是真正的隐形杀手老化是器件特性随时间退化的一类现象的统称主要机理有四种。偏置温度不稳定性指晶体管在栅极偏压和温度共同作用下阈值电压发生漂移表现为电路变慢高温加剧明显。热载流子注入是沟道中的高能载流子撞击栅氧界面产生缺陷同样导致阈值漂移和跨导下降它跟开关频率强相关。电迁移是金属互连中的大电流密度导致原子迁移长期下来形成空洞或小丘最终断路或短路跟电流密度的平方强相关。经时介质击穿是栅氧在电场长期作用下形成导电通路一旦发生就是硬失效。这四种机理有一个共同点都对温度和电压极其敏感。经验上结温每升高 10 到 15 摄氏度多数老化机理的退化速率接近翻倍供电电压每上浮 10%介质击穿和电迁移的寿命会显著缩短。AI 加速卡恰好长期处在这两个加速因子上所以它的有效寿命要按加速模型折算不能简单套用消费电子的经验。架构上应对老化的核心思路不是阻止退化而是感知退化并保留裕量。常见做法是在关键路径旁边放老化传感电路定期测量延时链的翻转速度反推当前的时序裕量再配合片上频率电压调节在退化后适度提高电压或降低频率维持功能。这套机制的价值在于把某天突然全片区报错变成缓慢降频但持续可用对长时间训练任务来说后者远比前者友好。2.3 静默数据损坏最贵的那种没报错静默数据损坏的可怕之处在于它绕过了所有检测机制直接以正确数据的身份参与计算。按检测结果可以把错误分成三类能纠正的、能检测但纠正不了的、完全检测不到的。第三类占比不高但造成的损失往往最大。我踩过一次典型的坑。某个多卡作业在跑到第二天时其中一张卡的 loss 曲线开始比其他卡缓慢偏高但没有任何错误日志。排查了两天才发现那片区域的 HBM 有一条链路的校验被关掉了某次固件升级后配置被重置一个比特的错误被反复读出但从未上报最终污染了那一路的数据并行分支。这类问题的定位成本极高因为它既不像宕机那样有明确时间点也不像数值溢出那样有确定性复现路径。从架构角度压制静默数据损坏只能靠端到端校验。数据在从内存读出、经过计算单元、写回内存的整条链路上至少要有一次端到端的完整性校验任何中间环节的局部保护都不能替代它。原因很简单局部保护只能保证这一段传输没错而错误可能在保护范围之外产生或者在校验后被重新引入。这条原则在互连设计里尤其重要后面还会展开。2.4 把故障率算成钱FIT、MTBF 与可用性不用数字说话的可靠性讨论都是耍流氓。基础单位是 FIT含义是每十亿器件小时发生一次失效。用它换算 MTBF 非常直接MTBF 小时数等于十亿除以 FIT 值。前面提过单卡 5000 FIT 对应 20 万小时约 22.8 年听起来很安全但一万张卡的集群MTBF 就是 20 小时。再往下算可用性。假设每次故障平均修复时间 30 分钟含定位、隔离、重启、恢复检查点那么一万卡集群的可用性大约是 20 除以 20.5接近 97.5%。这个数字放在在线服务上勉强能接受放在训练任务上就很难看——因为一次中断可能意味着几小时的算力回滚。真正要优化的是平均无故障时间与平均修复时间的比值。提升分子要靠架构加固降低分母要靠快速检测和自动恢复。我在项目里的体会是分母的优化空间往往被严重低估把故障定位时间从 4 小时压到 20 分钟对整体效率的提升可能比花大代价把 FIT 降一半还明显。3. 架构级可靠性设计在哪一层拦截成本最低设计加固方案时有个基本判断原则越靠近物理层拦截成本越高、收益越确定越靠近软件层拦截成本越低、代价是延迟发现。聪明的架构是在中间找那个拦截成本低、发现延迟短的甜点位置。3.1 存储层次是第一战场ECC 的选型与取舍片上存储是软错误的主要落点也是加固收益最直接的地方。最基础的是单比特纠错双比特检错码在 64 位数据上加 8 位校验开销 12.5%能纠正任意单比特翻转、检测双比特翻转。这个方案足够覆盖大部分场景代价是编解码延迟和面积。但只做单比特纠错在先进工艺下不够。前面说过多比特翻转如果交织做得好一个纠错字里最多被打中一位那单比特纠错就够用。问题是交织会打乱物理布局增加布线复杂度和延迟。我的经验是容量大、访问模式随机的共享内存可以接受交织带来的布线代价而对延迟极度敏感的寄存器堆和小容量缓存往往选择牺牲容量或直接用更高强度的保护。HBM 这类高带宽外部存储是另一个重点。它内部有片上纠错链路上还有循环冗余校验和重传看起来保护很完整。但实际部署时我建议重点核查三件事片上纠错是否真的开启且阈值配置合理、链路重传是否会导致明显的带宽抖动、以及巡检机制是否在跑。巡检的意义在于主动扫描内存把潜伏的单比特错误及时纠正防止它累积成双比特错误。很多团队忽略这一点结果就是单比特纠错能力被浪费掉了——因为没有巡检单比特错误会一直待在那里等到第二个比特翻在同一条纠错字上就变成了不可纠正错误。巡检频率需要权衡带宽占用和累积风险我的经验值是完整扫描周期控制在几小时量级比较合理。3.2 计算单元的容错不是所有加法器都值得做三模冗余计算逻辑的加固有个经济学问题。全芯片三模冗余意味着三倍面积、三倍功耗而且三模表决器本身也会引入延迟和新的失效点实际收益远没有理论值那么漂亮。所以现实中几乎没人对整颗 AI 芯片做全冗余。更务实的做法是分层加固。控制路径——指令译码、状态机、调度器、地址生成——这些逻辑面积占比小但错了就全乱套可以用双模冗余加比较器或者干脆锁步执行代价可以接受。数据路径——大量并行的乘加阵列——面积占比 80% 以上用冗余不现实转而依赖算法级手段。算法级手段里最有效的是校验和与重算。矩阵乘法天然适合做行列校验给输入矩阵附加校验行和校验列一次乘法就能同时得到结果的校验值与预期值比对即可发现计算过程中的错误。开销通常在 10% 以内检测覆盖率相当高。这套方法在容错计算领域是老技术但用在 AI 加速器上特别合适因为它的计算模式高度规整。另一个经常被低估的手段是结果比对。同一次前向计算用两种不同的累加顺序各算一遍结果应该在浮点误差范围内一致。这个方法不需要额外硬件只需要软件调度上多花一点算力适合用在推理这种对延迟不极端敏感的场景。训练场景里我用得更多的方式是检查点重算——把检查点之后的若干步重新算一遍与原始结果比对差异超过阈值就判定出了问题。代价是算力翻倍所以只在可疑时段启用。3.3 互连与片上网络链路可靠性决定集群能不能撑住单卡内部的片上网络和卡间的互连在可靠性上的地位经常被排在存储之后我觉得这是个误区。多卡训练里梯度同步是全网状的通信一条链路出问题可能导致整个通信组超时损失的是全部卡的算力。链路层的基本手段是循环冗余校验加重传。发送端算校验、接收端验证、出错就请求重发。这套机制本身很成熟真正容易出问题的是重传与流控的交互。基于信用量的流控在丢包重传时如果信用返还路径和重传路径出现竞争极端情况下会触发死锁。我在一个模拟项目里就遇到过类似的场景链路误码率在高温下升高重传变多信用返还延迟增加发送端误判接收端缓冲耗尽双方互相等待最后靠超时机制才解开但那一次已经是整组训练卡死了二十分钟。解决办法是给控制通路和数据通路做物理或虚拟通道隔离保证控制信息在任何拥塞情况下都能通过。片间互连还要考虑前向纠错编码的强度选择。编码越强纠错能力越好但延迟和带宽开销也越大。加速器之间的链路通常工作在很高的速率上延迟敏感所以多数方案选择轻量前向纠错 重传兜底的组合。这个组合的关键参数是纠错码能纠正几位、重传的超时阈值怎么定。超时定太短会频繁误触发重传定太长则故障恢复慢。我的经验是按链路的往返延迟加上三倍标准差来定同时保证重传缓冲区足够深。3.4 RAS 控制平面把散落的错误信息组织成可决策的信号前面讲的都是检测和纠正但检测出来之后怎么办才是真正体现架构功力的地方。一颗成熟的 AI 芯片需要一套完整的 RAS 控制平面做四件事分级、记录、隔离、降级。分级是把错误按严重程度分类。能纠正的单比特错误算一类可纠正但频次异常的算一类检测到但纠正不了的算一类会导致整片失效的算一类。分级的意义在于不同级别触发不同响应第一类只计数不动作第二类超过阈值就标记对应内存页或缓存行不可用第三类触发隔离或重启第四类直接报致命错误。记录是很多人做得最敷衍的一环。只记某类错误发生了 37 次没有意义必须记录地址、错误码、时间戳、当时的温度与电压、触发时的指令指针。有了这些才能判断是随机分布还是有热点区域是温度相关还是与特定访存模式相关。隔离和降级是最后的手段。隔离的粒度要尽可能细——能隔离到一个缓存行就别隔离整个 bank能关一个计算簇就别关整颗芯片。我在一个模拟项目里做过对比把故障隔离粒度从整片下线细化到按内存分区下线集群在同等故障率下的可用算力提升了将近 8%。这个数字看起来不大但放到万卡规模上就是几百张卡的产能。4. 系统级兜底架构解决不了的部分交给软件再强的架构加固也不可能把故障率降到零一定有一批错误会穿透所有硬件防线。这时候系统层的设计就成了最后一道闸门。这一节讲的三件事是我认为投入产出比最高的。4.1 检查点策略频率不是拍脑袋定的检查点是训练任务的事实标准但检查点该多久存一次绝大多数团队是靠感觉。其实这个问题有明确的最优解。设检查点写入耗时 C系统平均无故障时间为 M那么存在一个使总开销最小化的检查点间隔。直观理解是存得太频繁写入本身的开销占比高存得太稀疏每次故障都要回滚很长一段。在故障率相对稳定的假设下最优间隔约等于 2 倍 C 乘以 M 再开平方。代入具体数字。假设单次检查点耗时 5 分钟集群 MTBF 是 24 小时86400 秒那么最优间隔约等于根号下 2 乘 300 乘 86400约等于 7200 秒也就是 2 小时。如果 MTBF 掉到 8 小时最优间隔缩短到约 70 分钟。这个公式的价值在于它把要不要加密检查点从一个经验判断变成了一个可计算的问题当集群故障率上升时间隔必须跟着缩短否则回滚损失会快速吃掉收益。除了频率还有两个优化方向值得做。分层存储先把检查点快速写到本地高速存储再异步搬到远端持久化把写入延迟从分钟级降到秒级公式里的 C 直接变小最优间隔随之拉长。增量检查点只写变化的部分同样能显著降低 C。这两个手段叠加实际能把有效检查点开销压到原来的三分之一左右。4.2 热设计温度不只是性能问题更是可靠性问题散热设计在很多人眼里是别让芯片降频的问题其实它对可靠性的影响更深远。前面讲过结温每升高 10 到 15 度多数老化机理的退化速率接近翻倍。一颗常年工作在 85 度而不是 70 度的芯片两年后的参数漂移可能相当于别人四年。架构层面能做的是温度感知的调度。芯片上分布多个温度传感器调度器据此调整各计算簇的负载避免局部热点。这个机制听起来简单实现时有两个坑。一是传感器本身的精度和响应速度采样太慢跟不上负载变化采样太快又会产生大量中断。二是调度的抖动如果热点判定阈值定得太敏感负载会在簇之间反复迁移反而造成额外的热循环。我的经验是给迁移加一个滞回区间温差超过 8 到 10 度才触发迁移。系统层面则是散热链路的可靠性。风扇、泵、冷板、导热界面材料都是有寿命的部件而且它们的失效往往不是突发的是效率缓慢下降。所以除了温度监控还需要监控同等负载下的温度变化趋势。如果发现在相同功耗下温度逐月上升基本可以判定散热链路在劣化这时候主动维护比等到过温保护触发要好得多。4.3 电源完整性最容易被当成软件 bug的那类故障大电流负载的瞬变是 AI 加速卡面临的一个特殊挑战。计算阵列从空闲切到满载电流变化率极高供电网络上的寄生电感会感应出电压跌落。如果跌落超过时序裕量触发器可能采到错误值而这种错误在功能上表现为随机的、不可复现的数值异常——最容易被误判成软件问题。我经历过一次非常典型的排查。某个 kernel 在特定输入尺寸下偶尔产生错误结果重跑十次可能只复现一次。查了两周软件无果最后用示波器抓供电轨才发现那个输入尺寸恰好让计算阵列的启动节奏形成了周期性的电流尖峰与供电网络的谐振频率接近电压波动被放大了。解决办法是在调度上加一个错峰启动的约束把同时启动的计算簇数量限住让电流上升沿变缓。架构上应对这类问题的常规手段是去耦电容的合理布局和电压跌落检测电路。去耦电容要靠近负载放置中间的电感和电阻越小越好这点在版图阶段就要规划后期改不动。电压跌落检测则是在关键位置放比较器一旦检测到超阈值的跌落就触发流水线冲刷重算把静默错误转成可恢复的显式事件。这个设计的价值极高因为它的成本只有几个比较器和一点控制逻辑却能把最难查的一类故障变成最容易处理的一类。5. 验证与评估可靠性是测出来的不是想出来的设计完一套加固方案怎么证明它有效这是我在项目里花时间最多的部分。答案只有一个故障注入。没有经过注入验证的可靠性设计本质上是一种信仰。5.1 故障注入框架的四个必备要素一个能用的注入框架需要四样东西故障模型、注入点、工作负载、结果分类。故障模型定义注入什么。常见的有单比特翻转、多比特翻转、固定为 0 或 1、路径延迟增加、链路丢包。模型的选择要贴合实际机理不能图省事只做单比特。注入点定义注入到哪。寄存器堆、共享内存、缓存、控制状态机、互连链路覆盖越全越好。我的做法是先按架构脆弱因子排序优先覆盖高脆弱区域这样在有限的注入次数里能覆盖最多风险。工作负载定义在什么情况下注入。这是个容易被忽略但极其关键的点。用一个小矩阵乘的微基准测出来的覆盖率跟真实训练负载下的覆盖率可能差好几倍因为真实负载会访问更多的状态、走更多的分支。能用真实负载就别用微基准。结果分类定义怎么判断这次注入的影响。至少分四类被纠正、被检测但不可纠正、静默错误、无影响。其中静默错误的比例是核心指标所有加固设计的目标都是把这个比例压下去。5.2 加速老化实验的参数外推老化验证没法等两年只能加速。常用手段是提高温度、提高电压、提高开关频率然后在加速条件下测退化量再用模型外推到正常工作条件。温度项通常用阿伦尼乌斯模型电压项用艾林模型或幂律模型。这里有个容易犯的错误加速得太狠引入了正常工作下不会出现的新失效模式测出来的数据就没意义了。所以加速倍率要控制在一个合理范围内通常温度不超过额定最大结温电压不超过额定值的 1.2 倍并且至少做两组不同加速条件的实验来验证模型的一致性。只有两组数据的退化趋势在换算到同一基准后能对齐外推结果才可信。5.3 指标口径要统一否则没法跨团队对话最后一点经验可靠性指标必须有统一口径否则架构团队、运维团队、业务团队说的根本不是一回事。我建议至少明确这几个定义——FIT 值统计的器件范围包含哪些、是否含封装和板级、静默错误的统计口径是注入实验中未检测到的比例还是生产环境中事后定位到的比例、可用性是按整卡还是按作业完成率计算。指标定义口径常见误用FIT每十亿器件小时失效次数需注明统计范围不同范围直接横比静默错误率未检测到的错误数 / 总注入数与生产事故率混为一谈作业完成率成功完成作业数 / 提交作业数未剔除用户主动取消有效算力利用率有效计算时间 / 总挂钟时间忽略回滚造成的时间损失6. 常见问题与排查技巧实录这一节是我这几年攒下来的排查经验按故障表现组织遇到对应症状可以直接对照。6.1 训练 loss 突然跳变或出现 NaN怎么快速定位第一步永远是判断是单卡问题还是全局问题。多卡训练时先看 loss 曲线是不是所有数据并行分支同时异常。如果只有一路异常问题大概率在那张卡或那条链路上如果全部同时异常更可能是通信或全局状态的问题。第二步看异常发生前的窗口。我习惯把发生前 500 到 1000 个 step 的梯度范数、参数范数、激活值范围都拉出来看。常见模式有两种梯度范数在异常前几十步开始缓慢爬升那是数值稳定性问题比如某个归一化层的方差逼近零梯度范数一直是正常抖动然后在某一步突然爆掉那更可能是硬件层面的静默错误。第三步做针对性复现。从上一个检查点重启用相同的随机种子和数据顺序跑。如果能复现就是软件问题如果换一张卡就不复现基本可以锁定硬件。这一步的关键是要保留完整的数据加载顺序和随机数状态很多团队为了省事不存这些导致永远无法复现。第四步是隔离验证。把可疑卡下线跑一个长时间的算力自检程序同时对它的内存做完整巡检。如果巡检报告里出现了纠正错误的累积基本就确认了。6.2 静默错误的定位手法静默错误最难的地方是它不留下时间戳。我的做法是把检测点前移不等结果异常再查而是在训练流程里插入周期性的结果比对。具体做法是每隔固定的步数用两条不同的计算路径比如不同的累加顺序、不同的并行切分方式各算一遍前向比对输出。差异超过浮点误差阈值就报警。这套机制会消耗额外的算力所以我一般只在故障高发期或新硬件上线初期启用稳定后关掉。另一个有效手段是端到端校验和。在关键数据结构的头部附加一个校验值每次读写都验证。这需要软件栈配合改造成本不低但收益很实在它能把三周后才发现缩短到下次访问就发现。6.3 常见问题速查表现象可能原因排查动作处置单卡 loss 持续偏高无报错内存或链路静默错误完整内存巡检、链路误码统计隔离分区替换部件特定 kernel 偶发结果错误供电瞬变或时序违例抓供电轨波形、查负载启动节奏错峰调度加去耦高温时通信超时增多链路误码率随温度上升统计温度与误码相关性降频或加强散热长时间运行后频率自动下降老化导致时序裕量不足读老化传感器数据接受降频规划更换检查点写入越来越慢存储链路退化或碎片化监控写入延迟趋势分层存储增量写入随机重启无错误日志供电跌落或致命错误未记录检查供电监测与日志完整性补全 RAS 日志链路6.4 几条踩过坑才明白的心得别迷信供应商给的 FIT 数字。那是实验室条件下的典型值实际部署环境的温度、海拔、负载画像都不一样。我的做法是在自己的环境里跑一段时间的统计用实际故障数反推有效 FIT通常比标称值高不少按实测值做容量规划更靠谱。日志的完整性比日志的详细程度更重要。很多设计把日志写得很详细但故障一旦发生日志还没来得及刷到持久存储就断电了等于没有。所以关键错误必须走同步落盘路径宁可牺牲一点性能。降级策略要提前演练。我见过太多系统故障隔离逻辑写得很完善但从来没跑过真出事的时候隔离动作本身引入了新的问题。定期人工注入故障走一遍完整的隔离降级流程比写一百页设计文档管用。别把可靠性做成一次性项目。硬件上线时的故障率通常是最低的随着时间推移老化、散热劣化、固件漂移会让故障形态不断变化。要建立长期的故障数据采集和分析机制按季度回顾一次故障分布根据实际数据调整加固重点。最划算的投资往往在可观测性上。加一个温度传感器、加一条错误计数通路、加一段链路误码统计成本几乎可以忽略但它们决定了你出问题时是花二十分钟定位还是花两天。我在项目里推动的第一件事就是补全错误上报链路收益比任何一项加固设计都直接。我个人在实际操作中的体会是AI 硬件的可靠性从来不是靠某一项技术解决的它是架构加固、系统兜底、运维可观测性三层叠加出来的结果。硬件的加固决定了故障率的下限软件的容错决定了故障影响的边界而可观测性决定了你每次能从故障里学到多少。三者缺任何一环另外两环的投入都会大打折扣。如果让我给刚接触这个方向的同行一个建议那就是先别急着研究加固方案花两周时间把现有系统的错误日志链路理顺、把故障分类统计做出来你对问题的理解会比读十篇论文都扎实。
阅读完成 · 觉得有帮助？
