没人聊 RAM：4.9 GB 的模型在开口前先占走了 7.0 GB

■ space · 出租屋参观

4.9 变成 7.0 的那一夜

配置：Ryzen，32 GB RAM，一块 12 GB VRAM 的 RTX 3060。拉的是 llama3.1:8b，标着 4.9 GB。三条命令，一块屏：

$ ollama ps
NAME            SIZE      PROCESSOR    CONTEXT
llama3.1:8b     7.0 GB    100% GPU     32,768
$ nvidia-smi
   …  7963 MiB / 12288 MiB  …
$ free -h
Mem:  31 Gi

截图手工重打——像素留在测试机上；数字就是记录

「4.9 GB 的模型」占走了 7.0 GB，才回应第一条输入——一笔 43% 的上下文税 ——然后给自己留下 7,963 / 12,288 MiB。

权重从来不是预算。上下文才是。

VRAM 卖的是梦。RAM 决定模型到底跑不跑得起来——以及跑起来时还剩多少上下文。

户型图

每个加载的模型同时租两套房子。选一个模型档位，拧一下上下文旋钮，看着两边一起被填满。下面三行实测数字把旋钮钉在锚点上。

房间彼此不按同一比例画——每套房子只按自己的租约画

多出来的那些 GB 是什么

llama.cpp memory notes 写明了下载页省掉的算术： 总内存 = 模型权重 + KV 缓存 + 计算缓冲。只有第一项是常数。

Ollama 包着 llama.cpp ——同一条定律。 ollama ps：4.9 GB 的标签，32,000 token 的窗口，占到 7.0 GB，全部驻在 GPU 上。

把最后两行再读一遍。在 VRAM 上，14B 配真实上下文就成了分裂 offload 的活；27B，干脆不可能。在 32 GB RAM 上，只是 慢。

不可能对慢——RAM 与 VRAM 全部的实用差距。offload 沿 PCIe 走：Ollama FAQ 说得很直——GPU 份额越小，吞吐掉得越狠。

没人有意识地做这个取舍。它悄悄发生，一层一层——症状听上去只是 「本地模型都感觉被高估了。」

这就是量化梯子存在的原因：Q4 让算术落在人们已有的硬件里。两套「一模一样」的 8B 配置，上下文长度不同，整台机器就完全不同。

量化模型不是妥协。它是一句承认：内存从来都是真正的预算。

诚实的账本

写这篇东西时坏掉的或让我吃惊的事，按顺序：

1. 43% 这个数字本身。 我以为 8B 会占「差不多它文件的大小」。它对着 4.9 GB 的下载包占了 7.0 GB。连我都吃惊——那一定也吓到每个只看规格页、不看 ps 输出的人。
2. 截图那一局。 我第一张截屏抓错了窗口；第二张成了，收据区块重打的就是它。收据是工作流，不是氛围——拉取 → 截屏 → ollama rm 的循环，让磁盘保持诚实。
3. 没坏的地方：GPU 从头到尾没溢出。 8B 配 32k 上下文跑在 12 GB 上，真的从容。卡没问题；松动的是围着那块卡的舆论。

GPU 依然要紧——100% GPU 那一行就是生成感觉瞬时的原因。但 GPU 是第二个问题。选 runner 得排在 装得下什么 的后面。

值得留下的拇指法则

RAM = 模型文件 + KV 缓存（按你真实窗口算）+ 4 GB（当台电脑的钱）。 7–8B Q4：16 GB 从容。14B–32B：32 GB 才是重点。

VRAM 买给你想要的、在你所用上下文上的速度；RAM 买给你有朝一日要加载的一切。

看一眼 ollama ps，规格页宗教就悄悄散场。

给你下一台开发机留两个问题：VRAM 买给你要发的跑分，还是 RAM 买给你要跑的模型？还有，凌晨两点拉下来的模型，有几个熬到了早饭？我的没熬到。

出租屋参观到此为止 · 没有任何 fetch · 全程本地