端侧 AI · 内存
端侧 AI GC 压力怎么和 Native 内存区分
把 managed allocation、native runtime 和媒体缓冲分开观察。
主查询：端侧 AI GC 压力 · 核验：2026-09-16 · 事实卡：MEMORY-01, BENCHMARK-01
先给结论
端侧 AI 的 GC 压力要单独看，必须把 managed allocation、native runtime 和媒体缓冲拆成三层各自观测，不能再向外推断诸如驱动、功耗或系统级回收行为，因为这些已超出本次记录的边界，任何外推都会破坏判断的独立性，也容易把不同来源的延迟混在一起，导致后面所有动作都失去判断依据。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- allocation trace
- GC 时间线
- 任务延迟序列
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
串联手头这些证据，必须按顺序记录与对比三组数据：allocation trace 用于看清每次分配发生在哪里、GC 时间线用于对齐回收阶段与分配阶段、任务延迟序列用于把回收动作映射到端侧任务卡点上。只有这三组同时摆在一起，才能确认压力究竟来自哪一层，而单独看任何一项都无法给出端侧 AI GC 压力的结论。
- 记录真实 artifact
- 测未加载基线
- 测加载后状态
- 跑代表任务
- 跑最大承诺输入
- 连续运行并观察释放
最容易写错的地方
- 把所有停顿归因模型
- 忽略 native memory
错误模式只能复述这两条：把所有停顿都归因到模型上，以及忽略 native memory 在同一时间段内的占用。发布结论只能限制在已有的 allocation trace、GC 时间线和任务延迟序列的记录之内，不得据此外推到模型选型、运行时参数或端侧 AI GC 压力的成因结论，凡超出 MEMORY-01、BENCHMARK-01 事实卡边界的推断一律剔除。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。