端侧 AI · 内存
本地 AI 长会话内存怎么测
在一个有序运行中覆盖多轮、媒体、取消和页面切换。
主查询：本地 AI 长会话内存 · 核验：2026-09-16 · 事实卡：MEMORY-01, BENCHMARK-01
先给结论
其重点是在一个有序运行中覆盖多轮、媒体、取消和页面切换，这一前提界定决定了后续一切动作都不能向外推断，所有证据与结论都必须严格收敛于本机本会话的实际执行轨迹，离开这组事实的扩展一律不算数，否则就会把外部条件误植为本地表现。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 固定长会话脚本
- 内存检查点
- 失败清理记录
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
串联的证据是固定长会话脚本、内存检查点与失败清理记录，这三者必须被同时记录并相互对照：脚本保证刺激一致，检查点给出每一阶段的本地内存读数，清理记录则把过程中实际发生的失败与回收原样留下，只有当这三份记录能够彼此对得上，本地内存的表现才能被认定为可重复的观察。
- 记录真实 artifact
- 测未加载基线
- 测加载后状态
- 跑代表任务
- 跑最大承诺输入
- 连续运行并观察释放
最容易写错的地方
- 每个任务都重启进程
- 只发布最终平均值
错误模式包括每次任务都重启进程以及只发布最终平均值，二者都会抹掉会话内部的真实波动，因此发布结论只能限于已有记录：进程级重启必须停止，每次检查点的逐点读数与清理事件都必须随结论一并公开，任何再加工或平均化都不得出现在正式记录里，并依据事实卡边界 MEMORY-01 与 BENCHMARK-01 加以限定。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。