技术热点落地：vLLM + Ollama 本地 LLM 生产级推理部署实战（2026-05-31）
适用场景与目标
适合的场景：
- 日均请求量在 10k～500k 级别的 AI 应用（客服摘要、代码审查、内容生成等）
- 对数据隐私有要求，不能将 Prompt 发送至第三方 API
- 需要控制单次推理成本，尤其在并发量上来后 API 费用不堪重负
- 团队已有 GPU 基础设施，希望复用自有算力
核心目标： 在有限 GPU 资源下，以最低工程成本搭建稳定、高吞吐的本地 LLM 推理服务；搞清楚 Ollama 和 vLLM 分别用在什么地方，避免”用 Ollama 做生产”或”用 vLLM 做原型”这类错位。
最小可行方案（MVP）步骤
阶段一：本地开发用 Ollama（Day 0~1）
Ollama 的价值是零门槛启动，3 分钟跑起来，不需要任何集群配置。
# macOS / Linux 安装
curl -fsSL https://ollama.ai/install.sh | sh
# 下载模型（以 Qwen2.5-7B-Instruct 为例）
ollama pull qwen2.5:7b
# 验证运行
ollama run qwen2.5:7b "用一句话解释为什么本地部署LLM越来越流行"
# 暴露 HTTP API（默认端口 11434）
ollama serve调用方式与 OpenAI 兼容：
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama", # OLLAMA 不验证 key，随便填
)
response = client.chat.completions.create(
model="qwen2.5:7b",
messages=[{"role": "user", "content": "总结这段文字：..."}],
temperature=0.7,
)
print(response.choices[0].message.content)阶段二：生产用 vLLM（Day 2~5）
当并发用户超过 3~5 人时，Ollama 的串行请求处理会成为瓶颈。实测 50 并发下 Ollama 吞吐约 155 tok/s，而 vLLM 可达 920 tok/s（6 倍差距）。
安装 vLLM：
# 需要 NVIDIA GPU + CUDA 12.1+
pip install vllm
# 下载 HuggingFace 格式模型（首次需要科学上网或镜像）
# 推荐用 Qwen2.5-7B-Instruct 或 DeepSeek-R1-Distill-Qwen-7B
huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/Qwen2.5-7B-Instruct启动 vLLM 服务：
python -m vllm.entrypoints.openai.api_server \
--model ./models/Qwen2.5-7B-Instruct \
--gpu-memory-utilization 0.85 \
--max-model-len 8192 \
--tensor-parallel-size 1 \
--port 8000阶段三：接入负载均衡（可选，Day 3~5）
用 LiteLLM Proxy 统一封装多个后端，实现自动路由和降级：
# litellm_config.yaml
model_list:
- model_name: gpt-4
litellm_params:
model: openai/gpt-4
api_key: os.environ/OPENAI_API_KEY
- model_name: qwen-local
litellm_params:
model: openai/qwen2.5-7b
api_base: http://localhost:8000/v1
api_key: "local"litellm --config litellm_config.yaml --port 4000现在应用只需调用 http://localhost:4000，在本地模型崩溃时自动降级到云端 API。
关键实现细节
GPU 显存估算公式
所需 VRAM ≈ (模型参数总量 × 每个参数的字节数) + (KV Cache 上限 × 并发数 × 2)
# 示例：Qwen2.5-7B，FP16 加载，32 并发，context_len=8192
模型加载：7B × 2 bytes = 14 GB
KV Cache：7B × 2 × 32 × 8192 × 2 / (1024³) ≈ 6.3 GB
合计 ≈ 20.3 GB → 推荐单卡 24GB VRAM（RTX 4090 / A5000）量化对照表（以 Qwen2.5-7B 为例）：
| 格式 | 精度 | VRAM 需求 | 速度 | 质量损失 |
|---|---|---|---|---|
| FP16 | 16位浮点 | ~14 GB | 基准 | 无 |
| Q4_K_M | 4位混合 | ~4.9 GB | +30% | <2% benchmark |
| Q8_0 | 8位 | ~9 GB | +10% | 可忽略 |
| AWQ | 4位激活 | ~5.2 GB | +35% | <1% |
Ollama 模型选择建议
# 优先用带 `:instruct` 后缀的指令微调版
ollama pull qwen2.5:7b-instruct-fp16 # 显式指定精度
# 查看已下载模型
ollama list
# 自定义 Modelfile（添加系统提示词）
cat > Modelfile << 'EOF'
FROM qwen2.5:7b
PARAMETER temperature 0.7
PARAMETER top_p 0.9
SYSTEM """
你是一个专业的技术文档助手，用简洁清晰的语言回答问题。
"""
EOF
ollama create tech-assistant -f Modelfile
ollama run tech-assistant "解释什么是 PagedAttention"vLLM 关键参数说明
--gpu-memory-utilization 0.85 # GPU 显存使用比例，留 15% 给 CUDA 框架
--max-model-len 8192 # 最大上下文长度，需要和模型支持范围匹配
--tensor-parallel-size N # 多卡并行（需要 N 张 GPU）
--enforce-eager # 禁用 CUDA graph，加速但增加初始化时间
--enable-chunked-prefill # 分块预填充，降低峰值显存，适合长上下文常见坑与规避清单
坑 1：Ollama 直接跑生产流量
现象： 单用户测试响应正常，5 个并发用户 P95 延迟从 0.8s 飙升到 45s。
原因： Ollama 使用 llama.cpp 内核，本质是单请求串行处理，无连续批处理（continuous batching）。
规避： 确认并发需求 > 5 用户/秒时，坚决换 vLLM。Ollama 定位是开发/个人工具，不是服务。
坑 2：GPU 显存估算不足导致 OOM
现象： 服务启动时或高负载时进程被 kill，显示 CUDA out of memory。
原因： 没算 KV cache 增长空间。实测当 max-model-len=16384 时，32 并发 KV cache 可占 12GB+。
规避：
# 监控启动时的显存占用
nvidia-smi --query-gpu=memory.used,memory.total --format=csv
# 用 --gpu-memory-utilization 留足余量，首 次部署用 0.75
python -m vllm.entrypoints.openai.api_server \
--gpu-memory-utilization 0.75 # 先保守坑 3：模型下载慢或中断
现象： huggingface-cli download 速度极慢，或断连。
规避：
# 方案1：设置镜像站
export HF_ENDPOINT=https://hf-mirror.com
huggingface-cli download ...
# 方案2：用 Ollama 的模型库代替（社区模型多，下载速度快）
ollama pull mistral:7b-instruct-v0.2坑 4：vLLM 冷启动时间过长
现象： 第一次请求 TTFT（首个 Token 生成时间）高达 20s+。
原因： vLLM 首次推理会做 CUDA graph 编译和 KV cache 预分配。
规避： 开启 enforce-eager 或在服务启动后发一条暖身请求：
# 服务启动脚本后加
import requests
requests.post("http://localhost:8000/v1/chat/completions", json={
"model": "qwen2.5-7b",
"messages": [{"role": "user", "content": "hi"}],
"max_tokens": 2
}, timeout=60)坑 5：多卡部署时张量并行效率
现象： 2 卡部署吞吐量不是单卡的 2 倍，只有 1.3 倍。
原因： 张量并行需要 AllReduce 跨卡同步，有通信开销；小 batch size 时尤其明显。
规避： tensor-parallel-size 只在 batch 够大（并发请求多）时使用。单卡 4090 够用就别上多卡。
成本/性能/维护权衡
硬件选型矩阵
| GPU | VRAM | 典型用例 | 性价比 |
|---|---|---|---|
| RTX 4090 24GB | 24GB | 单模型 7B FP16，13B Q4 | ⭐⭐⭐⭐ 最推荐 |
| A100 40GB | 40GB | 13B FP16 或 70B Q4 | ⭐⭐⭐ 贵但稳 |
| A5000 24GB | 24GB | 性价比替代 4090 | ⭐⭐⭐⭐ |
| Mac M3/M4 Pro | 集成 | Ollama 本地开发 | ⭐⭐⭐⭐⭐ 开发专用 |
成本对比（估算，月度）
| 方案 | 场景 | 月成本估算 |
|---|---|---|
| OpenAI GPT-4o Mini | 100k 请求/月 | ~$150（输入+输出） |
| Anthropic Claude 3.5 | 100k 请求/月 | ~$300 |
| Ollama + RTX 4090 自托管 | 100k 请求/月 | 电费~$30（4090 满载 ~400W） |
| vLLM + RTX 4090 | 100k 请求/月 | 同上，省去 API 费 |
结论： 请求量 > 30k/月 时，本地部署的 API 费用节省即可覆盖 GPU 硬件折旧。
维护成本
| 维度 | Ollama | vLLM |
|---|---|---|
| 更新模型 | ollama pull 一行 | 手动替换模型目录 |
| 监控 | 基础日志 | 需要接入 Prometheus+Grafana |
| 多模型切换 | 支持 | 需要重启 Pod 或配置多模型 |
| 自动扩缩容 | 不支持 | K8s + KServe 支持 |
| MLOps 生态 | 弱 | 成熟（HuggingFace TGI 兼容） |
一周内可执行行动清单
Day 1（今天）：
- 在开发机器上安装 Ollama，运行
ollama pull qwen2.5:7b - 用 Python 调用 Ollama 的 OpenAI 兼容 API，实现一个最小原型
- 记录：首次加载时间、显存占用、响应延迟
Day 2~3：
- 在 GPU 服务器（24GB+ VRAM）安装 vLLM
- 参考上述参数启动 vLLM 服务
- 用
ab或wrk做简单并发压测（10/30/50 并发），记录吞吐曲线
Day 4：
- 对比 Ollama vs vLLM 在目标并发下的 P95 延迟
- 确定生产选型：Ollama（< 5 并发）还是 vLLM（≥ 5 并发）
- 整理 VRAM 使用基线，形成运维文档
Day 5：
- （可选）部署 LiteLLM Proxy，实现 API 统一入口
- 配置健康检查和告警（内存、GPU 利用率、请求错误率）
- 估算月度推理成本，和当前 API 费用做对比
Day 6~7：
- 将推理服务接入真实业务流（先灰度 5% 流量）
- 设置每日 cost dashboard
- 记录第一周运营数据，决定是否需要扩 GPU 或切多卡
一句话总结： Ollama 是本地开发的瑞士军刀，vLLM 是生产推理的工业母机。搞清楚自己站在哪个阶段，用对的工具，不要让开发工具干生产的活。