本文为工程实践复盘，客户信息已脱敏，文中数据均为项目复盘口径的脱敏示意值。

一、项目背景

我们的推理集群跑着几十个模型，卡量不小，显存 ECC 报错、NVLink 降速、PCIe 纠错这类硬件毛病隔三差五来一次。过去靠监控告警加人工摘流，等值班同学被叫醒、登录、确认、摘卡，往往已经有一批请求失败，重试也救不回那些长耗时任务。我们一直做的是出了事再救，没有半点预判，每次硬件抖动都是一次线上事故。

这件事的成本不低。一次没及时处理的多卡故障，可能让某条关键业务线的推理延迟飙升几分钟，上游超时连锁报警。值班团队被半夜叫醒的次数多到开始麻木，反而容易漏真告警。我们意识到，靠人盯硬件指标这条路走不通，必须让系统自己预判、自己挪流量。更麻烦的是，故障往往不是突然死，而是先亚健康再恶化，留给人的反应窗口很短。

最让我们下决心的是一次连续事故。某周末两块卡先后出现 ECC 抖动，值班同学处理完第一块刚睡下，第二块又恶化，等到发现时已经有十几分钟推理失败。复盘时发现，两块卡的异常指标早在前半小时就已经在监控曲线上露头，只是没人一直盯着。那一刻我们达成一致：这种重复劳动必须交给机器，人的价值在于处理机器判断不了的复杂情况，而不是守着曲线等坏消息。

二、落地场景

我们在每台卡上采集温度、显存 ECC、PCIe 报错、NVLink 状态、任务重试率等健康指标，用轻量模型识别故障前兆。一旦判定某张卡要出问题，自动把它从调度池摘掉，在途请求无感迁移到备用卡组，故障卡隔离等人工确认。整个过程不依赖人，值班同学只在确认邮件里看到一条已自动摘流的记录。

落地后我们把热备卡常备在池子里，平时空转，关键时刻顶上。降级策略是优先摘单卡、保整池，避免一次误判把半个集群摘空，那样反而制造更大事故。我们还把自动摘流事件接到了容量调度，摘掉后若备用不足会自动触发扩容申请，让人提前介入补卡。

为了不惊动人，我们给自动摘流设了一道安静机制：正常摘流只发邮件摘要，只有连续摘流超过阈值或备用不足时才拉群告警。这个设计后来被证明很关键，否则每天几十条摘流通知会把人逼疯，真有大事反而被淹没在噪声里。

三、关键技术挑战与解决思路

故障前兆特征提取比想象难。单看温度会误报，我们改成多指标联合：ECC 纠错次数连续上升加任务重试率抬升加 NVLink 降速，三者里两个以上同时异动才触发预摘流。这里我后来觉得，加一个近期是否有训练任务刚结束的上下文判断会更好，因为训练收尾时指标本来就会抖，容易被误判，这部分我们还在迭代。

请求无感迁移靠的是推理框架的会话保持和请求队列兜底，摘卡前先把该卡上的在途请求排空再下线，避免半路断流。备用容量调度要留冗余，我们按峰值的两成常备热备卡，宁可平时空转也不让请求没地方去。摘流的回滚也要快，误摘的卡确认健康后要在分钟级重新入池，不能晾在外面。

还有一个容易被忽略的点是模型的粘性。有些大模型会把会话状态绑在特定卡上，摘卡时如果直接杀进程，正在进行的多轮对话就断了。我们为此在迁移前先做一次会话快照，把状态迁到目标卡再继续，代价是迁移多花几秒，但用户体验上是连续的。这个细节是踩过一次对话中断的坑之后才补上的，属于那种不补不知道、补了才发现影响很大的设计。

案例片段（已脱敏）：GPU 健康巡检与摘流阈值的配置。

yaml health:  metrics: [ecc_correct, retry_rate, nvlink_down]  trigger: any_two_anomaly  pre_drain_seconds: 30  hot_standby_ratio: 0.2

一次真实事件里，某卡的 ECC 纠错在八分钟内从每天几次涨到每分钟几次，系统在第 7 分钟预判并摘流，那批在途请求全部迁到热备卡，业务侧只感知到一次轻微延迟抖动，没有失败。

四、效果数据

故障预测平均提前量约 8 分钟，请求失败率从月度千分之五降到万分之四。摘流误判率控制在 3% 以内，自愈恢复时长中位数约 90 秒。热备卡的额外成本约占集群算力的两成，业务侧认为这笔投入值。因硬件故障引发的连锁告警数量下降约八成。这些数字为示意值。

五、可复用经验总结

摘流不能太敏感，否则比故障还烦人。我们上线头几天阈值设太紧，一条偶发的 ECC 抖动就摘了三张好卡，半夜被叫醒三次才发现是误报，反过来影响了正常服务。后来改成多指标交叉确认加滑动窗口，误报基本消失。

硬件故障这事，预判的价值不在不坏，而在坏之前把流量挪走，用户体验到的只是一次轻微抖动。热备冗余别省，我见过团队为了省算力把热备压到 5%，结果真故障时备用不够，自愈反而拖垮了正常卡，得不偿失。

结语

自愈系统上线后，值班同学被叫醒的次数从每周好几次降到几乎为零，但真正的价值是业务侧再也感知不到硬件抖动。我们复盘时有一个共识：预判模型宁可少摘、不能误摘，误摘的代价是浪费算力加惊动人，而漏摘至多影响一小批请求。所以我把触发条件定得偏保守，靠多指标交叉把误报压下去。后续我们还想接训练任务的上下文，避免收尾期指标抖动被误判，让预判更准，也更少打扰人。