端侧 AI · 运行时
端侧 AI 中断任务怎样恢复
只持久化可安全恢复的任务状态，其余路径显式重启。
主查询：端侧 AI 任务恢复 · 核验：2026-09-16 · 事实卡：ARCH-01, BENCHMARK-01
先给结论
在端侧 AI 任务的恢复设计中，只能依据已经明确记录的事实进行判断，无法向外推断未被记录的机制。可安全恢复的任务状态被单独持久化，其余执行路径不进入恢复通道，而是在中断后显式重启。这一边界限定了讨论只能围绕已持久化的内容展开，不去假设未记录的恢复能力。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 持久任务 schema
- 中断 fixture
- 恢复与重启结果
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
用于支撑判断的证据包括持久化任务的 schema 定义、用于模拟中断的 fixture，以及在同一条件下分别记录的恢复结果与重启结果。恢复路径与重启路径的产出需要分别落档并放在一起对比，仅在已有记录的范围内说明二者差异，不引入其他来源的指标。
- 选择运行时生态
- 确认支持的模型格式
- 封装应用接口
- 验证实际执行后端
- 测试取消与释放
- 保留回滚路径
最容易写错的地方
- 持久化 native handle
- 把部分输出当完成
已被记录的错误模式有两类：一是把 native handle 这类不适合跨中断重用的对象一并持久化，导致恢复阶段出现不可预期的状态；二是把部分输出误记为任务已完成，从而跳过应有的恢复或重启流程。发布层面的结论只能建立在以上已记录的内容之上，对未记录的兼容性、性能、覆盖范围等不作延展。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。