端侧 AI · 运行时
端侧推理超时：UI 停止不等于计算停止
区分 UI 等待、应用取消、native 中断和最终清理。
主查询：端侧推理超时 · 核验：2026-09-16 · 事实卡：ARCH-01, BENCHMARK-01
先给结论
端侧推理超时的分析只能围绕用户界面等待、应用层主动取消、native 中断以及最终的清理动作这几条线索展开，不能向外延伸到尚未出现过的机制或行为。这些概念本身就容易被混在一起描述，只有把它们各自的边界讲清楚，后续的判断才有落脚点，否则就会把不同来源的信号错误地归到同一个原因上。进一步说，超时现象本身并不只意味着一次响应延迟，它往往牵涉到底层调用链上多个环节的不同反应。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 超时边界
- native 取消轨迹
- 超时后恢复
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
要把超时现象讲清楚，需要把三类关键证据放在一起看：超时边界究竟卡在哪里、native 取消轨迹是否被完整记录、以及超时发生之后系统是否还能恢复正常。每一次超时事件都应当对照这三项留下可比的痕迹，否则不同案例之间就无法彼此印证，结论也只能停留在“发生过一次”的层面。把这些证据串联起来描述，才能让一次超时既是一次孤立事件，也成为后续可以复用的样本。
- 选择运行时生态
- 确认支持的模型格式
- 封装应用接口
- 验证实际执行后端
- 测试取消与释放
- 保留回滚路径
最容易写错的地方
- 隐藏进度但任务继续
- 把超时都算模型失败
在端侧推理超时的实际表现中，常见的两类错误模式需要明确指出：一是任务仍在运行却把进度藏起来，使外界误以为已经停；二是只要触发超时就把责任算到模型头上。这两种处理方式都会掩盖真实原因，也违背现有事实卡 ARCH-01 与 BENCHMARK-01 的边界。因此，关于超时行为的发布结论，只能限制在“已被记录到的现象”之内，凡是超出这些记录的解释，都不应被写入结论。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。