在 2G 内存的机器上跑通本地大模型：完整记录与读数

先说清楚结论：2G 内存的机器不适合跑大模型推理，我试过，最小程序化量化模型也很勉强。但这篇记录的是我为了搞清楚"到底要多少资源"而做的一轮测量，方法比结论有用。

一、我需要它做什么

需求很小：把结构化文本抽成 JSON，数据不能出机器。这个需求下，云端 API 直接出局（合规），规则引擎也试过（中文分句太乱）。所以只剩本地推理一条路。

模型要求也低：能稳定输出合法 JSON、中文不出乱码、指令跟随不跑偏即可。不需要它写诗。

二、内存这笔账怎么算

三块占用：

1. 权重。参数量 × 每参数字节数。fp16 是 2 字节，Q8 约 1 字节，Q4 约 0.5 字节。1B 参数在 Q4 下就是 0.5 GB 左右，加上运行时开销，1 GB 出个头。
2. KV 缓存。随层数、注意力头维度、序列长度、精度增长。上下文从 2K 开到 8K，这部分能吃掉几百 MB 到几 GB。这是我最初完全没预料到的一项——只按权重大小估内存，然后 OOM。
3. 运行时。加载器、CUDA/ROCm 上下文、以及计算用的中间张量。CPU 推理这块相对小，GPU 推理时显存里还要再留一份。

我把这三项分开测量了一遍，方法很简单：先加载、不生成，看常驻；然后固定输入长度生成，看峰值差。用 ollama ps 配合 free -m，各跑三遍取中位数。

三、量化不是免费的

同一份 7B 模型，Q4_K_M 和 Q8_0 在我的抽取评测集上差了几个点，但中文和数字相关的字段掉得比整体更明显。这个现象和我看过的其他报告方向一致：低量化对精度敏感任务的伤害更大。

我的处理是：先用最小程序化量化跑通全流程，确认瓶颈在模型还是在我的提示词；确认之后再回到 Q4_K_M / Q5 这一档找质量与资源的平衡。这个顺序省了我不少时间，因为一开始就纠结量化档位，很容易把提示词的问题误判成模型的问题。

另外几条与直觉相反的经验：

• 别用 Q2/Q3 追求"能跑"。质量掉到我无法接受，而这些档位省下的内存不足以让 2G 的机器真正跑起来，结果是"跑得动但不可用"。
• 上下文窗口要显式设小。很多工具默认给到 4K 甚至 8K，对内存吃紧的机器是白占。我按实际输入长度留 30% 余量设。
• 首次请求慢不等于卡死。加载权重和编译计算图都发生在这段时间，第二次就正常。我一开始误判成服务挂了，重启了三次。

四、如果只有 2G，我建议做的事

我最后没在这台 2G 机器上跑推理，改成了：服务端只放应用与数据，推理放在另一台内存宽裕的机器上，两边用内网打通。这样职责干净，也保住了"数据不出自己网络"这个目标。

如果非要在这台机器上处理文本抽取，务实的选择是：

• 用传统方法：正则 + 词典 + 有限状态，中文结构化字段抽取很多场景根本不需要模型。
• 用极小模型（1B 以下）+ 严格约束解码（限制输出词法，让它只能生成合法 JSON），把"格式正确"这件事交给解码器而不是模型。这是我后来觉得最值的一个技巧——能用约束保证的就不要靠提示词祈祷。
• 明确接受它只在你自己的评测集上"够用"，不要拿它做任何需要知识广度的事。

五、复现清单

# 1. 装（服务端，纯内网机器请自行导入二进制包）
curl -fsSL https://ollama.com/install.sh | sh

# 2. 只监听回环，不要暴露 0.0.0.0
OLLAMA_HOST=127.0.0.1:11434 ollama serve

# 3. 拉一个明确量级的模型，先看清磁盘
ollama pull qwen2.5:0.5b

# 4. 常驻内存读数：加载前后各测一次
ollama ps; free -m

# 5. 固定上下文，避免默认值偷吃内存
ollama run qwen2.5:0.5b --verbose
# 交互内 /set parameter num_ctx 2048

--verbose 会打出 tokens/s 和各类耗时，这是判断瓶颈在算力还是访存的最快方式。

六、下一步

想试约束解码（Grammar / Structured Output）。目前我是靠"提示规定格式 + 代码校验 + 失败重试"三段式，成本是重试。理论上约束解码能从根上消掉格式错误，等我跑通再写。