在一台普通机器上跑大模型，先想清楚这三件事
显存怎么算、量化怎么选、推理后端怎么挑。踩过几次之后，我把顺序反过来了：先定并发，再定模型。
本地部署大模型最容易犯的错，是上来就挑模型。跑不动，再换一个更小的；还是慢，再换量化。来回折腾几轮，机器没变，人先累了。
后来我把顺序反过来了：先定使用场景（并发多少、上下文多长），再倒推显存，最后才选模型和量化格式。
一、显存不是”模型大小”决定的
很多人算显存只算权重，实际吃显存的大头还有两块：
- KV Cache：跟上下文长度、并发数成正比。上下文从 4K 拉到 32K，这部分可能翻好几倍，往往比模型本身更早把显存撑爆。
- 推理框架的额外开销：CUDA context、临时缓冲区、CUDA Graph 之类，通常要预留 1–2 GB。
粗糙的估算方式是：权重显存 ≈ 参数量 × 每参数字节数，再加上 KV Cache 那部分。用 4 bit 量化，7B 模型权重约 3.5–4 GB；但如果你要 32K 上下文、还想两个人同时用，真实占用会明显高于这个数。
所以判断标准不是”这卡能不能装下模型”，而是”装下模型之后，还剩多少给上下文和并发”。
二、量化的取舍：不是越低越好
常见的 GGUF 量化档位里，Q4_K_M 基本是默认答案：体积和质量的平衡点。往下走到 Q2、Q3，体积省得有限，但输出质量掉得很快，尤其是需要推理和代码的场景。
除非显存真的卡死，否则不建议为了省 1 GB 去用 2 bit 量化——那种情况更该做的是换个更小的模型。
另外两个容易踩的点：
- 量化格式和推理后端绑死。GGUF 是给 llama.cpp / Ollama 用的，vLLM 走的是另一套（AWQ、GPTQ 或它自己的量化）。选模型之前先定后端。
- 量化过的模型做微调，效果会打折。要训练就留一份全精度或者 16 bit 的，别在量化权重上直接训。
三、三个后端，各自适合什么
| 后端 | 适合 | 不适合 |
|---|---|---|
| llama.cpp | CPU / 混合推理、单机、追求简单 | 高并发 |
| Ollama | 本地试用、模型管理省心 | 生产级吞吐 |
| vLLM | GPU 上要高并发、连续批处理 | 小显存、纯 CPU |
我的用法是分层的：Ollama 拿来验证模型效果，一条命令换模型，最省事；真要压吞吐才上 vLLM，它有 PagedAttention 和连续批处理，但环境依赖重、配置项多，小机器上反而别扭。
# 先验证效果，别急着上框架
ollama run qwen2.5:7b-instruct
# 确认能用之后再考虑常驻服务
ollama serve四、几个真实翻车点
上下文长度是隐性杀手。 模型声明支持 32K，不代表你的机器能开到 32K。开满之后要么 OOM，要么速度掉到不可用。
并发一上来，延迟不是线性增长。 单路聊天很流畅，两个人同时提问就开始排队。这个体感差异只有在实际压测时才发现，看 benchmark 数字是看不出来的。
下载和磁盘空间。 一个 7B 的 GGUF 动辄 4–5 GB，试几个模型很快就占满。模型目录最好放在外接盘或者单独分区。
别在系统盘上跑。 临时文件、缓存、日志都往默认目录写，跑久了磁盘满，排查起来很费时间。
小结
顺序理清楚，本地部署其实没那么玄：先问自己几个人用、上下文多长，再算显存，最后选模型和后端。反过来做，八成要在”跑不动”和”质量不行”之间反复横跳。
至于值不值——如果只是偶尔用，云端 API 更便宜；如果数据不能出去、或者要反复调试同一条链路，本地这套迟早要搭。