凌晨一点十七分，城市大脑的某个视觉识别节点整体“失联”。我登录服务器检查，业务进程还活着，NPU状态看着也正常，但推理请求全部超时。后来追到设备侧日志才确认，是 HBM ECC 错误累积到阈值触发了设备异常复位——进程存活不等于设备健康，这是我在 CANN（Compute Architecture for Neural Networks） 工业级部署中踩过最深的坑。
这篇内容不是 CANN 教程，而是围绕异常处理和心跳监测机制，讲清楚三件事：CANN 的异常体系到底怎么分层、心跳监测从应用到设备的演进脉络、以及在真实工业部署中如何把这两套机制串成一套可上报、可定界、可止损、可恢复的完整链路。如果你正在用昇腾设备跑 7×24 推理服务，或者正准备把训练任务从单卡迁到集群，这篇值得花十分钟读完。其中大部分结论来自实际线上事故复盘，不是纯代码层面的理论推演。
1. 先聊一个工业级部署最怕的事：进程活着，设备没了
1.1 一个真实的事故现场：业务“假死”比崩溃更可怕
进程崩溃是有声的——退出码、core dump、监控告警都能立刻兜住。真正麻烦的是假死：应用进程还挂在系统里，健康检查接口还返回着“ACL_ERROR_NONE”，但底层的算子队列已经堵死，或者设备侧发生了内部复位而 Host 侧没有及时感知。这种情况下，调度平台看到的是“节点活、请求超时、卡在推理中”的诡异状态，代价往往是几十个业务实例同时堆积请求，把周边链路也拖垮。
CANN 的 Runtime 层在较新的版本里引入了更细的设备状态上报机制，不再只是“能不能打开设备”的二元判断，而是包含设备温度、HBM ECC 错误计数、AICore 利用率、任务超时状态等健康维度。但从我接触的大量线上案例看，绝大多数团队根本没有把这些状态接入自己的监控体系，只用了最基础的aclrtSetDevice返回值判断设备好坏，这中间隔着一整层的“状态认知”缺失。
1.2 为什么异常处理和心跳监测必须放一起聊
很多开发者把“异常处理”理解成 try-catch 和错误码判断，把“心跳监测”理解成定时发一个 HTTP 请求确认服务活着。这本身没错，但在工业级部署中，这两者的关系比表面看起来要纠缠得多。
异常处理解决的是“错误是什么、发生在哪一层、该用什么策略响应”，它回答的是质性问题。心跳监测解决的是“系统是否还在正常工作、活性下降到了什么程度”，它回答的是量性问题。前者依赖 CANN 暴露的异常模型，后者依赖设备健康状态的持续回传。二者必须形成闭环：异常触发状态变化，状态变化通过心跳暴露出来，运维系统根据心跳做出决策，决策又反过来调用异常处理接口执行复位或迁移。没有心跳的异常处理是无处安放的处理，没有异常处理的心跳是只能看不能动的手电筒。
2. CANN 对异常的分层态度：从错误码到设备状态机
2.1 错误码体系的三种“严重级别”，别只当它是一串数字
CANN 接口返回值aclError并不是一个无脑枚举，它背后暗含一套严重级别分层。我习惯把它分成三类：
| 级别 | 典型错误 | 处理策略 |
|---|---|---|
| 参数级 | ACL_ERROR_INVALID_PARAM、指针为空、维度非法 | 主动修复，立刻重试通常无效，应直接止损 |
| 资源级 | 内存开辟失败、Stream 创建失败、上下文拥塞 | 回退释放重试，配合退避策略 |
| 设备级 | 设备异常、HBM ECC 错误、AICPU 任务超时 | 必须走设备复位或任务迁移链路，普通重试只会叠加恶化 |
我在项目里维护了一整套错误分类函数，把所有aclError值映射到“可重试 / 可恢复 / 必须迁移”三类策略，而不是统一打印日志后退出。原因很简单：工业场景里一次误判的策略，可能让整个集群对一台故障设备反复重试，相当于在伤口上反复撒盐。
2.2 图编译期与执行期：异常感知的时机完全不同
CANN 的作业链路由三段时间组成：图编译（GE）、任务下发、算子执行。工业级部署中最容易被低估的异常发生在图编译期。
图编译期的异常大多以aclmdlCreateDesc、aclmdlLoadFromFile等接口的返回码报出，特点是可复现、可定位。但真正的坑在于：部分模型图编译过程会消耗大量 Host 内存和 NPU 资源，一旦失败，资源和上下文不会立刻释放干净。我们曾经在模型热更新时频繁触发图编译失败，持续跑了一天后，设备上残留的上下文把 HBM 吃满，最终导致整个容器组不可用。后来加了编译前资源预检和编译失败后的强制上下文回收，问题才彻底解决。
执行期异常则更隐蔽。算子执行出错虽然能通过ACL_ERROR_RT_*系列错误码感知，但触发到上报之间有一段窗口期。在这个窗口期，设备可能已经处于亚健康状态，继续下发任务会加速恶化。所以执行期异常不能只靠主线程的错误码轮询，必须结合下文要说的异步报告机制。
2.3 设备级异常分类：CANN 不只是给你错误码，还给了异常类型
CANN Runtime 用aclrtExceptionInfo来承载设备侧上报的异常信息，我把它理解成一颗“设备症状雷达”。它能区分出的异常类型比很多人以为的丰富得多，常见包括设备内部任务执行异常、设备看门狗超时、HBM 错误、AI Core 挂死等。
这里要注意一个设计理念：CANN 的异常上报并不是粗暴地在 Host 侧抛一个 error 就完事。它遵循了一种“事件通知 + 状态查询”的分离模式——异常发生时，Runtime 通过回调或事件机制通知业务侧“出事了”，但具体“出什么事、严重到什么程度、能不能恢复”，需要业务侧再去查询详细状态。
这个分离模式非常接近操作系统对硬件中断的处理方式：先快速响应，再慢速处理。理解了它，你就知道为什么aclrtSetDevice能成功不代表设备是你想象中的健康。
3. 心跳监测机制的三代演进：保活、感知、预测
3.1 第一代：业务侧自建心跳上报，简单直接但活性定义太窄
最早我们做多机推理集群时，心跳监测的实现非常朴素：每个推理进程起一个线程，每 5 秒向调度中心上报一次“我活着”。确认活着的方式，就是判断主线程是否还在正常循环里、最近一次aclrtSynchronizeStream是否超时。
这套方案满足了对“进程级活性”的监控，但存在两个致命盲区。第一，进程活着不代表推理链路通。推理线程阻塞在某个队列上时，心跳线程照样能跑，调度中心看到的是全绿。第二，业务侧自建心跳只覆盖应用层到 Runtime 之间的通路，完全看不到 NPU 设备本身的健康状态，无法提前感知 HBM 双 bit 错误这类硬件故障的前兆。
第一代心跳的本质问题是：它测量的是“业务线程的呼吸”，而不是“系统整体的血液循环”。
3.2 第二代： Runtime 侧健康状态查询与主动感知
CANN 在 Runtime 层提供了健康状态查询能力，典型如aclrtGetDeviceStatus和基于事件订阅的报告机制aclrtSubscribeReport/aclrtListenReport。这一代演进的关键在于把“设备健康”纳入了可观测范畴。
以aclrtSubscribeReport为例，它的工作方式类似信号注册，业务侧可以订阅某个设备或上下文上的异常事件。一旦设备侧发生异常，Runtime 会异步把事件推给业务侧的回调处理函数。这种机制的好处是实时性极强，不需要轮询，能在毫秒级感知设备异常，比业务侧自己写定时检查快了不止一个量级。
第二代心跳监测的常见落地方式，是把 Runtime 上报的事件进一步汇聚到 Prometheus 或自研监控平台。设备状态 Query 接口负责低频采样（例如每 30 秒一次），异常事件订阅负责高频感知（耗时毫秒级），两种手段结合，才能形成一张既不漏报又不频繁误报的设备心跳网。
3.3 第三代：亚健康识别与异常预测
第三代演进正在发生的方向，是把心跳监测从“它死了没有”推进到“它正在走向死亡吗”。
工业部署中真正的威胁不是瞬时崩溃，而是亚健康状态：某个 AI Core 的执行时间一天比一天长，HBM 的 ECC 单 bit 错误计数在缓慢爬升，任务的耗时标准差越来越大。这类状态在传统二值心跳里完全不可见，但如果在恶化到临界点之前介入，完全可以规避一次夜间大面积故障。
CANN 侧逐渐提供更细的运行时指标后，工程侧要做的是把这些指标变成趋势信号。比如给 ECC 单 bit 错误设置增长率阈值，24 小时内增长率超过 20% 就自动触发设备预迁移；给算子执行时间建立基线，连续 3 个窗口偏离基线超过 2 倍标准差就告警。这不是什么高深算法，但需要你跨出“只看状态码”的惯性，开始用时间序列的视角审视设备健康。
4. 工业级部署落地的完整链路：上报、定界、止损、恢复
4.1 上报：接住 CANN 异常信号的四种通道
要让异常和心跳机制真正工业可用，第一步是保证信号不丢。我在生产环境里同时接入了四条通道：
- 接口返回码：同步捕获每一次 CANN 调用的
aclError，这是地基。 - 事件订阅回调：用
aclrtSubscribeReport异步感知设备级异常，延迟毫秒级。 - 日志落盘：配置 ASCEND 日志级别并接入统一日志平台，作为复盘和定位的材料。
- 侧信道心跳：业务侧定时任务上报“推理链路是否全程跑通”，比如每次推理成功后递增一个计数器。
四条通道各有侧重。返回码管同步错误，事件订阅管设备异动，日志管事后分析，侧信道管“业务真实可用性”。任何一条通道单独出现都不能定性，四路交叉验证才敢下结论——这个思想贯穿了我们所有故障处理预案。
实现事件订阅的框架类似这样，伪代码附上供参考：
# 伪代码演示事件订阅的处理框架 def device_exception_handler(device_id, exception_info): # 第一优先：立刻停止向故障设备下发新任务（全局开关置位） pause_scheduler(device_id) # 第二优先：记录现场信息，供后续定界使用 capture_device_snapshot(device_id, exception_info) # 第三优先：触发设备级自检/复位决策 issue_recovery_decision(device_id) aclrt_subscribe_report(device_id, device_exception_handler)4.2 定界：芯片故障 / 网卡故障 / Host 侧故障，别当一回事
异常上报之后最忌讳的是把一个现象当成根因去处理。一次推理超时，可能是 NPU 芯片挂了，可能是 PCIe 链路抖动，可能是网卡流控丢包，也可能是 Host 侧内存争抢导致调用卡死。定界的核心是建立多维度证据的交叉矩阵。
我习惯用一个三栏矩阵来辅助判断：
| 现象 | 芯片层面 | 链路层面 | Host 层面 |
|---|---|---|---|
| 推理持续超时 | HBM ECC 错误计数是否增长 | PCIe 带宽是否异常 | CPU 负载和内存争抢是否严重 |
| 进程假死但设备正常 | 算子队列是否有堆积 | 网络连接是否断连 | 线程栈是否全部 Block 在锁上 |
| 设备主动复位 | 日志有无关键错误码 | 固件版本是否兼容 | 是否有 OOM Kill 等系统事件 |
这个矩阵不复杂，但如果没有提前定义好，线上出问题时团队各自的判断会天差地别。我们花了很长时间才把“看到现象不敢动”的团队状态扭转成“对照矩阵快速收敛”。
另外有一个容易踩的坑：不要轻易相信驱动日志里的“自动恢复成功”。设备复位的成功只代表重新枚举完成，不代表推理现场被完整恢复，任务上下文往往已经不可用。所以定界的下一步必须包含业务侧的任务级恢复，而不是在设备复位后继续沿用旧的执行流。
4.3 止损与恢复：设备复位、任务迁移、退避重试的组合拳
止损策略按严重程度递增，我总结成四个阶梯：
- 软止损：暂停向故障设备下发新任务，保留存量任务，等待恢复窗口。
- 任务迁移：将推理请求调度到同机其他卡或备用节点，要求推理服务无状态或具备状态热迁移能力。
- 设备复位：调用设备复位流程，或通过配套工具强制恢复。复位后必须重新加载模型和上下文，不能复用旧句柄。
- 节点隔离：如果故障在短时间内反复出现，把整个节点从服务发现中摘除，进入人工检测流程。
这四个阶梯最重要的是第一条——暂停下发。很多事故扩大化的原因不是设备坏了，而是负载均衡器仍然向坏设备疯狂投递请求，把单个设备故障放大成整厅节点雪崩。做工业级部署，第一课永远是“让故障的影响范围可控”，而不是“让故障不出现”。
恢复侧的经验：重试策略必须指数退避加抖动。我们对任务重试采用 1 秒、2 秒、4 秒、8 秒、封顶 30 秒的退避序列，同时加入 ±20% 的随机抖动，避免故障恢复后所有任务同时涌回来造成二次击穿。热启动或冷启动就是冻结加载大模型再恢复，冷启动相对更加可靠，但耗时更长，需要结合服务等级协议里的恢复时间目标来衡量。
5. 版本配套与工程陷阱：那些文档不写但你一定会踩的地方
5.1 CANN 与 PyTorch / Python 的版本配套，不是“能装上就行”
热搜里最常被问的就是cann pytorch python版本配套关系，这个提问方向本身说明了一大片人踩过坑。昇腾的软件栈是三段式的：CANN 是底层计算架构，torch_npu 是 PyTorch 的适配层，Python 版本决定了前面两者能否正常运行。三者之间没有“最新配最新”这么简单。
从我实际维护过的环境看，版本配套的核心原则是“以 CANN 版本为锚点，反向锁 PyTorch 和 torch_npu”。每次升级 CANN 前，先查昇腾社区发布的版本配套表，确认当前代码锁定的 PyTorch 版本在适配范围内，再检查 Python 版本是否匹配。第三方库对 Python 版本的依赖很敏感，比如某些科学计算库在高版本 Python 下的二进制不兼容，会让安装阶段通过、运行阶段才崩溃。
线上升级的顺序也很有讲究：先在测试环境做全链路回归，重点观察图编译是否出现新告警、算子的计算结果是否与旧版本一致（最好带阈值比对）、以及推理耗时基线是否有漂移。CANN 的算子实现更新后，同一模型的表现出现微小数值差异是正常的，但差异超过一定阈值就说明算子实现发生了变化，需要业务侧重新做模型验收。
5.2 我踩过且至今印象深刻的三个坑
讲三个真实踩坑记录，都是纯文档里不会明说的级别。
第一个是日志轮转。CANN 日志在异常高频触发时增长非常快，默认配置下可能把/home目录打满。我在测试环境见过日志文件膨胀到几十 GB 后，整机 IO 被打满、业务全部阻塞的情况。这个问题的解法分两层：一是通过环境变量限制日志级别和落盘路径，二是外部统一兜底做日志切割和定期清理，两条腿缺一不可。
第二个是多进程上下文隔离。在多进程推理架构里，每个进程创建的 context 如果不主动释放，进程退出时设备侧的内存不会立刻回收干净。短时间反复启停业务进程，HBM 碎片化会迅速恶化。这个问题在旧版本 CANN 上尤为明显，后来我们在所有推理进程退出前强制调用上下文清理接口，并且对进程启停频率做限流，才消掉这块隐患。
第三个是设备故障后句柄失效的隐蔽性。设备异常并恢复之后，旧 context 和 stream 可能看起来还有效，但实际已经与设备状态脱节。我第一次遇到时，设备复位后继续用旧 stream 下发任务，结果推理结果严重异常但没有任何报错。现在我们的恢复流程里强制要求设备异常后建立新的 context，废弃全部旧句柄，这是省钱省命的一条铁律。
5.3 健康检查工具的正确打开姿势
昇腾侧提供的npu-smi系列工具是排查设备问题最快的入口，但用法上有讲究。我会关注以下几项信息的“变化趋势”，而不是某个瞬间的快照：
- HBM 显存使用率：持续逼近上限时说明存在内存泄漏或模型加载未释放。
- 温度和功耗：长时间偏离基线意味着散热或固件问题。
- ECC 错误计数：单 bit 和双 bit 的增长率比绝对值更有诊断价值。
- AI Core 利用率：推理业务出现周期性打满或长期很低，都值得排查。
为了观察趋势，我给每个节点写了一个后台采集脚本，每 15 秒采集一次上述指标并写入时序数据库，用 Grafana 展示趋势曲线。这套东西代替不了 CANN 的异常事件订阅，但它能回答“设备死之前发生了什么”，这往往是事后复盘的黄金信息。
6. 往后看：异常处理与心跳监测正在“工业化”
6.1 从单点故障恢复到故障注入演练
我观察到的一个明显变化是：越来越多团队不再满足于“设备挂了能告警”，而是主动把故障注入作为部署流程的一环。做法并不复杂，就是周期性模拟设备失联、网络抖动、进程被 kill、设备复位等故障场景，验证监控链路和恢复策略是否真的生效。
为什么这件事值得做？因为异常处理和心跳监测这套系统本身也是一个软件系统，它同样会腐化。我曾经在一个集群里发现倒班交接后，监控平台的设备状态 key 命名规则悄悄改了，导致部分告警静默丢失三天。如果没有故障注入演练，这类“监控的监控失灵”问题根本不会被发现。
在昇腾社区的 CANN 挑战赛的内容里，我注意到有不少参赛项目开始把“推理服务的可观测性”和“故障自愈”作为优化主题。这其实是一个很好的风向标：异常处理和心跳监测正在从“运维的备用话题”变成“架构的核心设计项”。这也是这篇内容想传递的最核心观念——设备健康类基础设施，一开始就要从“挂了能发现”设计成“快要挂了能预判、挂了能自愈、恢复后能复盘”的完整闭环。
6.2 一个关于心跳频率的工程权衡
收尾前提醒一个容易翻车的小细节：心跳频率不是越高越好。
工业级部署经常有人把心跳周期调到 1 秒甚至更短，理由是“我要更快发现故障”。但实际上，CANN 的设备状态查询本身是有开销的，高频轮询会在设备侧产生额外负载，在推理服务高峰期反而可能引入性能抖动。同时，过短的心跳周期会让调度中心频繁处理抖动信号，把恰好超过阈值的瞬时毛刺误判成设备故障，触发无谓的任务迁移。
我的实践经验是设置两层心跳：粗粒度低频心跳保活（10 秒级），细粒度高频事件订阅做异常感知（毫秒级）。前者用于判断“业务进程是否整体健康”，后者用于感知“设备是否发生异动”。两个机制各司其职，而不是用一个高频心跳把两件事都干了。
故障恢复结束之后也别急着把所有任务压回去。等一个完整的心跳周期确认设备稳定，再把流量缓慢切回，这个“冷静期”通常被我设成 5 到 10 分钟。越大的集群越需要这层谨慎，因为它给的是系统层面的缓冲，而不是赌设备下一次一定正常。
CANN 这套体系里，异常处理和心跳监测的演进本质上是在回答一个问题：当复杂系统的局部已经偏离正常，全局如何尽早知道、准确定位、并且安全收场。理解了这条主线，再看具体的接口、工具和策略，你会觉得所有设计都有迹可循。我们这行解决问题从来不靠某一个神奇接口，靠的是把常规机制组合到位，并且给每个环节留好容错空间。
