llama-server在6GB内存笔记本崩溃的排查与修复
llama-server kept dying overnight on a 6GB laptop. The model was fine; system RAM wasn't
做本地部署的同学必看，详细拆解了llama.cpp内存泄漏和缓存机制导致的崩溃问题，给出了具体的排查思路和修复后的性能对比数据，极具实操参考价值。
I'm building a local agent for Windows that runs on Ollama (llama.cpp). I run the same task kit overnight on three PCs: a 24GB desktop, an 8GB laptop and a 6GB laptop.
我正在为 Windows 构建一个基于 Ollama (llama.cpp) 运行的本地代理。我在三台电脑上运行相同的任务套件过夜：一台 24GB 的台式机、一台 8GB 的笔记本和一台 6GB 的笔记本。
On the 6GB laptop, llama-server crashed three times in one night. At first I suspected the model or the quantization, but the Windows low-memory log pointed somewhere else: the culprit wasn't the model, it was memory pressure on the same PC.
在 6GB 笔记本上，llama-server 在一夜之间崩溃了三次。起初我怀疑是模型或量化问题，但 Windows 的低内存日志指向了其他地方：罪魁祸首不是模型，而是同一台 PC 上的内存压力。
Cause 1: llama.cpp's prompt cache
原因 1：llama.cpp 的提示缓存
llama-server keeps its prompt cache in system RAM, not VRAM. The default limit is 8 GB, and a single 40K-token state was about 1.3 GB. On a laptop with 24 GB of RAM, the runner grew to 12 GB. I now set the limit from the PC's RAM (4 GB on a 24 GB laptop).
llama-server 将提示缓存保存在系统 RAM 中，而不是 VRAM 中。默认限制为 8 GB，单个 40K token 的状态大约占用 1.3 GB。在拥有 24 GB RAM 的笔记本上，运行程序增长到了 12 GB。我现在根据 PC 的 RAM 设置限制（在 24 GB 笔记本上设为 4 GB）。
Cause 2: my own agent process leaking
原因 2：我自己的代理进程泄漏
It looked fine on my dev PC but leaked on every other PC: 18 GB after 12 hours on the 8GB laptop. Two reasons: I never dropped the network responses kept for browser tabs after they closed, and I shipped a Windows component definition that only matched my dev PC. I counted live objects by type, took two snapshots ten minutes apart and diffed them, and both showed up right away.
在我的开发 PC 上看起来没问题，但在其他每台 PC 上都发生了泄漏：在 8GB 笔记本上运行 12 小时后达到了 18 GB。两个原因：我没有在浏览器标签页关闭后丢弃保留的网络响应，并且我发布了一个仅匹配我的开发 PC 的 Windows 组件定义。我按类型统计了活动对象，取了两次相隔十分钟的快照并进行差异比较，两者都立即显现出来。
Before and after (same task, same model):
修复前与修复后（相同任务，相同模型）：
- 8GB laptop, agent memory: 3,280 → 5,434 MB in 101 minutes before the fix, 2,699 → 2,809 MB in 91 minutes after.
- 6GB laptop: with the fixes, zero runner crashes over 5 hours (the runner's memory leveled off around 9 GB after the first 5 minutes). Once, though, the runner stopped responding for a moment and I lost one task. I'm still fixing that one.
- 8GB 笔记本，代理内存：修复前 101 分钟内从 3,280 MB 增至 5,434 MB，修复后 91 分钟内从 2,699 MB 增至 2,809 MB。
- 6GB 笔记本：应用修复后，5 小时内零次运行程序崩溃（运行程序的内存在前 5 分钟后稳定在约 9 GB）。不过有一次，运行程序短暂停止响应，导致我丢失了一个任务。我仍在修复这个问题。
What I do now: when a local LLM looks unstable on a small GPU, I check who is using system RAM on that PC before changing the model size or quantization. VRAM estimates don't include any of this.
我现在采取的做法：当本地 LLM 在小 GPU 上表现不稳定时，我会先检查该 PC 上谁在使用系统 RAM，然后再更改模型大小或量化方式。VRAM 估算不包含这些内容。
For people building local LLM apps: how do you set llama.cpp's prompt cache limit (cache-ram)? Proportional to the PC's RAM, or do you turn it off?
对于正在构建本地 LLM 应用的人：你们如何设置 llama.cpp 的提示缓存限制（cache-ram）？是根据 PC 的 RAM 按比例设置，还是直接关闭它？
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力