本地部署大模型，真正决定跑不跑得动的往往不是选哪个工具，而是下面两个数：你有多少显存（或统一内存），模型跑在哪个量化档位。工具只是外面那层壳。这篇把显存、量化、框架三件事拆开讲，避免一上来就纠结「Ollama 还是 vLLM」。
显存账
先算账，再选模型。很多人只算权重大小，结果第一轮长请求就 OOM。显存占用是三部分之和：权重 + KV cache + 激活和运行时开销。粗略的档位参考是：7-8B 的 Q4 模型要 6-8GB，14B 要 10-12GB，32B 要 20-24GB，70B 要 40-48GB，再留 15-20% 给 KV cache 和运行时。一个 14B Q4 模型权重约 10GB，硬塞进 12GB 的卡，上下文一开大、KV cache 一涨就炸。
判断瓶颈时要分清显存容量和显存带宽：容量决定能不能装下，带宽决定每秒出多少 token。买卡别只盯着显存大小，推理瓶颈常常在带宽。
量化档位
量化是拿精度换体积和速度。Q4_K_M 是多数场景的默认：体积约为 fp16 的四分之一，质量损失 1-2%。但「越小越好」是误区：对话类可以激进量化，代码和数学推理尽量 8-bit 或以上，Q2 除非显存极度紧张否则别碰。同样关键的教训是「装得下不等于够用」——Q2 能塞进显存，质量已经没了，要在自己的任务上评测，而不是只看它跑起来了。
三个框架的分工
Ollama、llama.cpp、vLLM 解决的是三个不同问题，选错框架比选错模型更浪费时间：
| 框架 | 定位 | 擅长 | 不擅长 |
|---|---|---|---|
| Ollama | 个人体验层 | 一条命令装好、OpenAI 兼容 API、快速试模型 | 高并发、批量服务 |
| llama.cpp | 推理引擎 | 量化最全、CPU/Apple 芯片友好、多卡张量切分 | 并发吞吐 |
| vLLM | 生产服务系统 | PagedAttention 连续批处理、高并发吞吐 | 单用户低延迟、AMD 支持不全 |
经验是「开发用 Ollama，生产上 vLLM」。两个常见错配：用 vLLM 跑单用户个人推理，它的批处理优势用不上、配置成本还高；用 Ollama 扛生产流量，它一次处理一个请求、不批处理，用户一多立刻排队。另一个容易忽略的点是模型文件格式不通用——Ollama 和 llama.cpp 用 GGUF 量化格式，vLLM 用 HuggingFace 格式加 GPTQ/AWQ 量化，不能互相换。
KV cache 与上下文
KV cache 是最容易被漏掉的显存项。上下文长度本身就是内存成本：权重装进 8GB 后，8k 上下文的 KV cache 可能把剩下的显存吃掉，实际只能开到 2k 就 OOM。要按真实使用的上下文长度量完整占用，而不是只看权重。服务端给 vLLM 设 --max-model-len 也要按实际需要，设成 128K 而你只用 8K，就是白烧显存。
并发与吞吐
单流 30 token/s 不代表十个用户每人 30，很可能是每人 3。批量（vLLM 的强项）是把单用户速度变成多用户容量的关键。要看并发下的吞吐，而不是单流速度。反过来，单机单用户场景，llama.cpp 反而比 vLLM 更快、开销更低。
安全与隐私
「本地部署」不等于「隐私」自动成立。要核实整条链路：运行时有没有遥测、更新检查、云端兜底把 prompt 传出去？模型文件从哪下载的、来源是否可信（社区上传的 GGUF 有供应链风险，优先 safetensors 变体）？服务端口有没有暴露到公网、加没加鉴权？模型是本地的不等于整条管线是本地。
值不值得
把这三件事的顺序理清——先算显存、再定量化、最后选框架——本地部署的纠结就少一半。选型的核心不是「哪个最好」，而是「你要解决什么」：个人玩票 Ollama，极限压榨 llama.cpp，对外服务 vLLM。多数团队实际是两三个一起用，本地验证一个、上线后换一个。