自部署大模型：Ollama 与 vLLM 选型实战
"用 API 省心，但有时你必须自部署——数据合规、成本可控、离线、定制。本文讲清两条主线：Ollama（本地实验、个人开发的最优选）和 vLLM（生产级高吞吐推理），以及绕不开的量化、显存、硬件选型，帮你判断'这个场景该用 API 还是自建'。"
本文要点
- 主题聚焦：大模型、开源
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
绝大多数 AI 应用，直接调商业 API 是对的——省心、不用运维、模型最强。但有几类场景，你必须自部署开源模型：
- 数据合规：医疗、金融、内部数据不能出机房。
- 成本：调用量大到 API 账单不划算。
- 离线/低延迟：边缘、内网、对延迟敏感。
- 定制：要微调、要控制推理参数、要跑特殊模型。
这篇讲两条自部署主线：Ollama（开发/个人）和 vLLM（生产），以及绕不开的量化与硬件。
一、先判断：到底要不要自部署
自部署的隐性成本不小（GPU、运维、模型升级、可用性），决策前算一笔账：
| 维度 | 调 API | 自部署 |
|---|---|---|
| 启动成本 | 极低 | 高（GPU + 工程） |
| 运维 | 零 | 持续（升级、监控、故障） |
| 模型质量 | 最强（闭源旗舰） | 弱一档（开源旗舰） |
| 单位成本 | 调用量小时便宜，大时贵 | 大量时摊薄到很便宜 |
| 数据 | 出你的环境 | 完全自有 |
经验法则：调用量不大、没有合规要求 → 用 API。只有"量大到 API 贵"或"数据不能出去"成立时，自部署才划算。 很多人为了"省钱"自部署，结果运维成本远超省下的 API 费——别犯这个错。
二、Ollama：本地开发的最优选
如果你要在本机跑模型（开发、实验、离线工具），Ollama 几乎是无脑选。它把"拉模型、量化、加载、推理"全包了，体验像 Docker：
ollama pull qwen3:8b
ollama run qwen3:8b
# 或起一个 OpenAI 兼容的服务
ollama serve # 默认 11434,OpenAI 兼容 API
特点：
- 极简：一条命令拉模型、一条命令起服务，零配置。
- 自动量化：默认下 GGUF 量化版，消费级 Mac/PC 也能跑 7B–32B。
- OpenAI 兼容：把
baseURL指向 Ollama，你写给 OpenAI 的代码能直接跑。 - 生态丰富：主流开源模型（Qwen、Llama、Mistral、DeepSeek…）都有一键拉取。
Ollama 适合：本地开发、个人工具、原型、离线场景。不适合：高并发生产服务（它不是为吞吐优化的，并发一上来延迟就飙）。
三、vLLM：生产级高吞吐推理
当你需要一个真的服务（团队/产品用，多用户并发），vLLM 是当前最主流的开源推理框架。
它的核心优势是 PagedAttention + continuous batching：把多个请求的注意力分页管理、动态组批，GPU 利用率和吞吐远高于朴素推理。同样的 GPU，vLLM 吞吐可以是 Ollama 的数倍到十倍。
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 # 单卡
起一个 OpenAI 兼容的推理服务，你的应用代码几乎不用改（换个 baseURL）。
适用场景：
- 生产 API 服务：团队内多个应用共用一个模型服务。
- 高并发：vLLM 的 batching 让并发延迟可控。
- 需要定制：控制采样参数、加载 LoRA、跑特定模型。
代价：部署比 Ollama 重（Python 环境、GPU 驱动、显存管理、版本兼容），需要有人运维。vLLM 是"服务"，Ollama 是"工具"——按你的规模选。
四、绕不开的量化
开源模型原始权重很大（70B 模型 fp16 要 140GB 显存），消费级/单卡跑不动，所以要量化：把权重从 16 位压到 4–8 位，显存降一半以上，质量损失通常可接受。
主流量化格式：
- GGUF：llama.cpp/Ollama 用，CPU/GPU 混合，灵活，适合本地。
- AWQ / GPTQ：vLLM/Transformers 支持，GPU 量化，适合服务。
- fp8：新一代硬件（H100/4090）原生支持，质量近乎无损。
经验：
- 7B 模型 4-bit 量化后约 4–5GB 显存，消费级 GPU（如 4060/4090）能跑。
- 70B 模型 4-bit 仍需 ~40GB 显存，得上 A100/H100 或多卡。
- 优先选社区已量化的版本（官方或 TheBloke 等），自己量化是深水区。
五、硬件选型：显存是第一指标
跑模型的核心约束是显存，不是算力。一个粗略估算：
显存 ≈ 模型权重 + KV cache + 激活
权重 ≈ 参数量 × 每参数字节数（4bit 约 0.5B/GB）
选卡参考：
| 模型规模（4-bit） | 建议显存 | 典型卡 |
|---|---|---|
| 7B–8B | 6–8 GB | RTX 4060/3060 |
| 14B–32B | 12–24 GB | RTX 4090、A10 |
| 70B | 40–80 GB | A100 80G、多卡 |
注意 KV cache：长上下文/高并发下，KV cache 可能比权重还吃显存。vLLM 的 PagedAttention 正是优化这个。估算时别只看模型大小。
六、自部署的运维盲区
自部署不是"跑起来"就完，几个常被忽略的：
- 可用性：模型服务挂了，你的应用就挂。要有健康检查、自动重启、监控。
- 模型升级：开源模型迭代快，升级要测试（输出质量可能变）。
- 成本监控：GPU 按时计费（云上），闲置也在烧钱。没流量时能不能缩容？
- 安全：模型服务要不要鉴权？内网部署也别裸奔（被扫描到就成免费算力）。
小结
自部署大模型，两条主线分清楚：
- 本地/个人/开发 → Ollama：极简、自动量化、OpenAI 兼容。
- 生产/高并发 → vLLM：PagedAttention 高吞吐、可定制、需要运维。
决策上记住：先确认"量大到 API 贵"或"数据必须自有"成立，再自部署。否则为了自部署而自部署，运维成本会反噬。开源模型的意义不是"更便宜"，而是"数据自有 + 可定制 + 抗审查"——当这些对你足够重要，Ollama/vLLM + 量化 + 合适的 GPU，就是你的答案。
Related