没人聊 RAM。本地 LLM 的每一个遗憾，都是 RAM 问题

随便钻进一个本地 LLM 的讨论串，吵的都是 GPU。VRAM 跑分、24 GB 显卡、CUDA 对 ROCm、3060 还算不算平民神卡。而真正决定你的模型能不能跑起来的那个数字，安静地插在另一个插槽里——没有跑分，没有营销：这台机器到底插了多少 RAM。

VRAM 卖的是梦。RAM 决定模型到底启不启动——启动之后，上下文还能活下来多少。

写这篇文章的时候，我在手头这台机器上做了验证：Ryzen 台式机，32 GB 内存，GeForce RTX 3060（12 GB 显存）。拉取 llama3.1:8b——下载页写着 4.9 GB。看看它实际预留了多少：

整个论点都在这一屏里。一个「4.9 GB 的模型」，还没回答第一个 prompt，就预留了 7.0 GB——43% 的上下文税——还占着 12,288 MiB 里的 7,963 MiB 显存。权重从来不是预算。预算是上下文。

多出来的那些 GB 从哪来

llama.cpp 的内存笔记写明了下载页省略的算术：总内存 = 模型权重 + KV 缓存 + 计算缓冲区。只有第一项是常数。KV 缓存随上下文长度线性增长，计算缓冲区随 batch 增长。Ollama 包着 llama.cpp，同一条定律照样生效——所以在 32,000 token 窗口下，ollama ps 给 4.9 GB 的标签报出 7.0 GB，而且全部驻留在 GPU 上。

量化模型不是妥协。它是承认：内存一直才是真正的预算。

这也正是 GGUF 量化阶梯存在的理由。Q4 不是宗教；它是让内存算术能落在普通人手里的硬件上。两个「一模一样」的 8B 环境表现毫无相似之处，理由相同：同一个模型，上下文长度不同，机器不同。

没人在买卡之前会填的表

三档模型、两种内存、一张 12 GB 的卡和 32 GB 内存——正是成千上万开发者真实的配置：

模型档位（Q4）	下载体积	加载后 + 32k 上下文	12 GB VRAM	32 GB RAM
7–8B（llama3.1:8b）	4.9 GB	7.0 GB（实测）	100% GPU，约用 8 GiB	几乎无感
13–14B（qwen2.5:14b）	9.0 GB	~12 GB	开始 offload	从容
27–32B（gemma3:27b）	17 GB	~20 GB 起步	CPU 扛权重	它能跑的唯一原因

重读最后两行。只靠 VRAM，现实上下文长度下的 14B 已经是分段 offload 的活儿，27B 直接不可能。而在 32 GB 内存里，两者只是慢。这个差别——「不可能」和「慢」之间的差别——就是 VRAM 和 RAM 全部的实用差别。装得进 VRAM，就快。装得进 RAM，就能跑。两边都装不下，你就在往 NVMe 上换页，时间失去意义。

offload 走 PCIe，Ollama 的 FAQ 对代价说得很直白：放不进 GPU 的层在 CPU 上算，GPU 份额一缩，吞吐就塌。没有谁有意识地选择这个取舍。它一层一层悄悄发生，症状只是「本地模型也就那样」。

诚实的账本

写这篇文章时翻车或让我意外的清单，按顺序：

1. 43% 这个数字本身。我以为 8B 模型占的空间「差不多就是文件大小」。它对着 4.9 GB 的下载预留了 7.0 GB。连我都意外，那所有读参数表而不看 ps 的人都会意外。
2. 截图环节。第一次抓错了窗口，第二次才成功——就是上面那张。证据是流程，不是氛围；pull → 截图 → ollama rm 这个循环让磁盘保持诚实。
3. 没翻车的部分：GPU 一次都没溢出。12 GB 跑 32k 上下文的 8B 确实从容。卡没问题。跑偏的是围着这张卡的话语。

这些都不是说 GPU 不重要——截图里那行 100% GPU 正是生成感觉瞬间完成的理由。重点是：GPU 是第二个问题。Ollama 还是 llama.cpp 的选择，应该在你弄清什么装得下之后，而不是之前。

值得留下的经验法则

所需内存 = 模型文件 + 你真实上下文的 KV 缓存 + 让你继续当台电脑的 4 GB。Q4 的 7–8B，16 GB 很舒服；14B–32B，32 GB 不再是奢侈，而是主题本身。VRAM 为你在所用上下文下想要的速度买单；RAM 为你今后会加载的一切买单。

看一眼 ollama ps，参数表的宗教就安静地结束了。

所以，两个问题。装下一台机器的时候，你买 VRAM 是为了将要晒出的跑分——买 RAM 是为了真正会跑的模型吗？再诚实一点：凌晨两点拉的那些模型，早饭前你删掉了几个？我今天删了，就在写这篇文章的中间。去评论区告诉我我不是一个人——顺便说说，你的机器站在 RAM/VRAM 分界线的哪一边。