本地部署大模型的成败在装软件之前就决定了：先把显存账算清。可用显存 = 显卡显存 − 模型权重 − KV Cache − 运行时开销，只要 KV Cache 那一项没留够，模型加载得进去也会在上下文一长时报 CUDA out of memory 。 Ollama 适合单机/单用户起步，vLLM 适合多并发生产服务，二者不是替代关系而是阶段关系。
先算显存：权重和 KV Cache 是两笔账
很多人按「模型文件多大就得多大显存」来选卡，这条经验只对了前半段。加载模型后显存里至少还有三样东西：
- 模型权重：由参数量 × 每参数字节数决定，量化后直接缩小。
- KV Cache：随上下文长度和并发数线性增长，长对话、多用户场景下这才是吃显存的大头。
- 运行时与激活值：框架自身、 CUDA context 、临时张量，一般预留 1–2 GB 。
Hugging Face 上 GGUF 模型的卡面通常直接给出可用参照，例如 Qwen2.5-7B-Instruct 的 Q4_K_M 约 4.4 GB，官方建议 6 GB 内存 / 5 GB 显存起步，CPU 推理约 15 tokens/s 。这类数据是选型时最可靠的依据，比凭参数量估算准得多。
一个真实的反例：24 GB 显卡为什么会 OOM
社区里 Qwen3.8-19B 剪枝版的模型卡给过一组很有代表性的数字：一个 24 GB 显存的消费卡（RTX 3090/4090），装密集版 Q4 权重（21.5 GB）后只剩约 2.5 GB 余量，上下文一过 2k token 就开始崩或被迫把层溢出到内存；换成剪枝后的 Q4_0（17.79 GB）余量回到约 6.2 GB，可以稳定跑 8k–16k 上下文，并且生成速度从 34.2 tok/s 提到 83.2 tok/s 。
结论很直白：余量就是并发能力和上下文长度。挑模型时不能只问「装得下吗」，要问「装完还剩多少」。
量化档位怎么选：一张对照表
GGUF 命名里的 Q4_K_M、Q6_K、Q8_0 指的是权重量化位宽与策略。以 7B 级别的中文模型为例：
| 档位 | 7B 模型体积 | 建议显存 | 适用 |
|---|---|---|---|
| Q4_K_M | 约 4.4 GB | 5–6 GB | 默认首选，性价比最高 |
| Q5_K_M | 约 5.1 GB | 6–8 GB | 对推理质量敏感的任务 |
| Q8_0 | 约 7.7 GB | 8–10 GB | 接近无损，做评测基线 |
| FP8（W8A8） | 较 BF16 减半 | 视模型而定 | vLLM 服务端吞吐优先 |
经验规则：先按 Q4_K_M 起跑，跑通后再评估是否有必要升档。多数检索问答、摘要、代码补全场景，Q4_K_M 与 Q8_0 的主观差异远小于「上下文不够长」带来的体验损失。
Ollama 还是 vLLM：按并发量分界线选
| 维度 | Ollama | vLLM |
|---|---|---|
| 定位 | 本地/单机推理，开箱即用 | 生产级高吞吐推理服务 |
| 并发 | 1–2 路为主 | 连续批处理，可支撑数十路 |
| 模型格式 | GGUF 为主，ollama run 直接拉 | SafeTensors / compressed-tensors |
| 调优点 | Modelfile 设 temperature 、 system | PagedAttention 、 KV Cache 量化、 gpu-memory-utilization |
| 适合 | 开发联调、隐私敏感的小流量工具 | 对外的 API 服务、批量离线任务 |
vLLM 侧常用的三个启动参数是长期运维的抓手：--gpu-memory-utilization 0.90~0.95 控制显存占用上限，--max-model-len 限制单请求上下文，--kv-cache-dtype fp8 用 KV Cache 量化换更长上下文。 FP8 动态量化在模型卡中常标注为约 50% 显存节省、 1.3–1.8 倍推理提速，代价是通常 1%–2% 的基准掉点，且只用于推理、不适合继续微调。
从零跑起来的五步
- 盘硬件：用
nvidia-smi确认真实可用显存（注意共享显存不算），记下这个数字，后面所有估算都基于它。 - 定参数规模：显存 ≤ 8 GB 选 7B–8B；16 GB 可上 13B–14B；24 GB 可尝试 20B 级剪枝/量化版；48 GB 以上再考虑 70B 。
- 选量化：默认 Q4_K_M，装完后确认剩余显存 ≥ 4 GB，否则降一档参数规模而不是硬塞。
- 起服务：单机用
ollama run <模型>暴露 11434 端口；对外用 vLLM 起 OpenAI 兼容接口，先压 4 路并发看是否有 OOM 。 - 压测与定容：固定一段 8k 上下文的 prompt，逐步加并发，记录 tokens/s 的拐点，把拐点前的值写进运维文档作为容量上限。
显存速查：常见规模的经验值
- 7B / 8B：约 8 GB 内存或显存
- 13B / 14B：约 16 GB
- 20B 级（剪枝 + Q4）：24 GB 卡可跑，余量约 6 GB
- 70B：48 GB 以上，FP8 量化后约 40 GB 起
以上为社区模型卡给出的经验参考，实际以压测为准；CPU 推理速度通常是 GPU 的十分之一量级，只建议做功能验证。
什么时候不该本地部署
三种情况建议直接用云端 API，别在本地死磕：
- 峰值并发高但平均低：本地要为峰值配卡，闲置率极高，成本反而不如按量付费。
- 需要最强推理能力：同价位下本地能跑的模型通常比云端旗舰弱一档，复杂推理任务差距明显。
- 没有运维人力：驱动、 CUDA 、模型更新、故障恢复都是持续成本，小团队容易被拖住。
反过来，数据不出内网、需要离线可用、请求量稳定且可预测这三类场景，本地部署的经济性和合规性优势是压倒性的。
评论 (0)