端侧 AI · 内存
本地 AI 内存不足时应该怎样提示用户
任务无法安全继续时给出可恢复动作，不猜统一 RAM 阈值。
主查询：本地 AI 内存不足提示 · 核验：2026-09-16 · 事实卡：MEMORY-01, BENCHMARK-01
先给结论
任务无法安全继续时，应当给出可恢复的操作路径，而不是猜测一个统一的内存阈值。系统无法在不掌握本机硬件的情况下推断出准确的 RAM 数值，因此提示内容只能围绕动作展开，让用户能够自行判断并采取相应步骤。在没有具体依据时，应避免给出可能误导的容量建议。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 失败分类
- 用户动作映射
- 清理后重试
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
要完成这一过程，需要记录和对比三类信息：失败分类，明确本次中断的具体类型；用户动作映射，梳理提示与用户实际执行的清理或调整之间的对应关系；清理后重试，验证用户在完成操作后再次运行的结果是否恢复正常。这些记录为后续判断提供事实依据。
- 记录真实 artifact
- 测未加载基线
- 测加载后状态
- 跑代表任务
- 跑最大承诺输入
- 连续运行并观察释放
最容易写错的地方
- 只显示未知错误
- 一直转圈后崩溃
常见的错误模式有两种：一是界面只显示“未知错误”，缺少可操作的指引；二是程序长时间处于转圈状态，最终发生崩溃。发布结论时应严格限定在已有记录范围内，不得依据外部信息补充新的内存容量、工具或兼容设备等描述，所有判断只能以已采集的事实卡 MEMORY-01 与 BENCHMARK-01 为准。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。