16GB 笔记本 AI 常驻栈的内存优化方法论
一句话结论：跑着一堆 AI 常驻工具（桌面 AI 客户端、反代、agent 运行时）的 16GB 笔记本，内存优化的正确姿势不是装优化器，而是先量化、再逐项处理、每一步可逆、收益必须可复现。文中数据来自一次真实优化过程的多轮实测。
方法论五条
- 先量后砍：动手前采基线（物理/可用/提交三指标），单点数据不下结论，必须同场景对照。
- 进程族拆解：按完整路径核对进程归属（同名进程可能属于完全不同的软件），不能按进程名批量结束。
- 可逆优先：每项优化配回滚脚本，回滚要实跑验证，不是「留了材料」就算过。
- 噪声带意识：相邻采样可用内存自然波动可达 ±0.3GB——小于噪声带的优化收益不可宣称。
- 诚实定性：「停用某个闲置服务后可用内存 +1GB」要用停用→恢复→再停用的三态对照证明，且要区分「机器空闲」和「优化工具自己正在跑」两种状态（后者是自干扰，不能用来判泄漏）。
实测案例：僵尸网关服务
发现一个废弃的网关服务：7 个进程、监听一个端口、后端指向已不存在的本地服务、所有功能模块被禁用、无任何配置引用——典型「卸载残留但还在自启」。
- 处置：备份任务定义 → 禁自启（保留定义）→ 优雅退出进程
- 受控收益（三态对照实测，非单点自报）：运行态比停用态多吃约 1.1–1.25GB 提交内存、0.9–1.4GB 可用物理内存
- 回滚验证：恢复脚本实跑成功（服务全部回来、端口恢复监听），再停用回去——完整闭环两次通过，全程 26 秒可恢复
这个案例的判断标准值得记住：不是「它占内存所以杀」，而是指向不存在服务 + 全功能禁用 + 无配置引用 + 完全可逆，四条同时满足才动手。
关于「对话秒出」的意外发现
顺手测了 AI 客户端的首字延迟（TTFT），结论反直觉：
- 内存不是首字延迟的主因——内存使用率 85% 时 TTFB 仍只有约 1 秒
- 上下文长度才是：实测每 1K token 约增加 18ms 首字延迟，长会话（120K+ 上下文）才是慢的大头
- 客户端冷启动的 9 秒卡顿与模型/内存无关，纯粹是前端加载慢
- 选「快模型」确实有效，但前提是先确认生产实际用的就是哪个模型（第一轮分析里「选错模型」的结论后来被日志证伪——这就是为什么每个结论都要有复核）
红线（踩过的坑变成的规矩）
- 不停活跃客户端、不按进程名批量清理
- 不关分页文件/内存压缩/Defender 来「腾内存」
- 不用 Standby 清空/EmptyWorkingSet 之类「刷数字」的假优化
- 「降到最低」只能在「不降体验」前提下逼近，不是无限压