post cover

技术热点落地：vLLM vs Ollama——LLM 部署从原型到生产的技术路径选择（2026-05-12）

技术热点落地：vLLM vs Ollama——LLM 部署从原型到生产的技术路径选择（2026-05-12）

本文面向有 AI 工程化需求的开发者，聚焦 2026 年主流的两种 LLM 推理框架 vLLM 和 Ollama，从实操角度给出选型和迁移建议。

适用场景与目标

你的团队是否面临这些问题？

  • 本地跑通了 Ollama，上线时不知道该怎么切换到 vLLM
  • 不确定 API 调用量在什么规模下该切换架构
  • 想用开源模型自建服务，但不知道成本和性能的平衡点在哪
  • 已经在用 vLLM 但并发一高就 OOM，不知道怎么优化

本文目标：给出一套可操作的”原型→验证→生产”三阶段部署路径，帮你做出正确工具选择、避坑、控成本。

最小可行方案（MVP）步骤

阶段一：本地原型（1天搞定，不花一分钱）

工具：Ollama + Docker

Ollama 是目前上手最简单的 LLM 运行方式，单命令启动，无需任何 GPU 配置。

# 安装（macOS/Linux）
curl -fsSL https://ollama.com/install.sh | sh

# 或用 Docker（推荐，方便清理）
docker run -d \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

# 拉取模型（推荐从 7B 开始，硬件要求最低）
docker exec ollama ollama pull llama3.1:8b

# 验证运行
curl http://localhost:11434/api/generate \
  -d '{"model": "llama3.1:8b", "prompt": "解释 KV cache 的工作原理", "stream": false}'

适合验证的场景：

  • 测试不同模型的质量（Llama 3.1、Qwen 2.5、Mistral）
  • 开发 RAG 原型
  • 内部工具的概念验证

硬件参考（阶段一只用 CPU 也行，但会慢 10-20 倍）：

模型参数最低显存（FP16）推荐显存（Q4量化）典型硬件
7B14GB5GBRTX 3060 / M1 Pro
13B26GB8GBRTX 4090 / M2 Pro
70B140GB38GBA100 / H100 多卡

阶段二：云上验证（2小时，$10 以内）

工具：vLLM + 云 GPU（半小时按量计费）

在正式迁移生产之前，需要用 vLLM 做一次真实吞吐量的基准测试。

# 在云服务器上（以 AWS G6 实例为例，1x A10G GPU）
pip install vllm

# 下载模型（推荐用 HuggingFace safetensors 格式）
# vLLM 原生支持 HuggingFace 格式，不需要转换

# 启动 vLLM 服务
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --gpu-memory-utilization 0.9 \
  --max-model-len 8192 \
  --port 8000

# 用 OpenAI 兼容 API 测试
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-8B-Instruct",
    "messages": [{"role": "user", "content": "用一句话解释 PagedAttention"}],
    "max_tokens": 100
  }'

压力测试脚本（用 wrk 或 locust）：

# locustfile.py — 保存到本地后运行
from locust import HttpUser, task, between

class LLMUser(HttpUser):
    wait_time = between(1, 3)

    @task
    def ask_question(self):
        self.client.post(
            "/v1/chat/completions",
            json={
                "model": "meta-llama/Llama-3.1-8B-Instruct",
                "messages": [{"role": "user", "content": "解释 RLHF"}],
                "max_tokens": 200
            },
            timeout=30
        )
locust -f locustfile.py --host=http://your-vllm-server:8000
# 在浏览器打开 http://localhost:8089，设置 50-100 并发用户

这个阶段要测出：

  • 单卡吞吐量（tokens/秒）
  • 50/100/200 并发下的 P99 延迟
  • 显存占用是否稳定

阶段三：生产部署（半天，Kubernetes + 监控）

# vllm-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama-service
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        resources:
          requests:
            nvidia.com/gpu: "1"
            memory: "24Gi"
          limits:
            nvidia.com/gpu: "1"
            memory: "24Gi"
        args:
          - "--model"
          - "meta-llama/Llama-3.1-8B-Instruct"
          - "--gpu-memory-utilization"
          - "0.9"
          - "--max-model-len"
          - "8192"
        env:
          - name: VLLM_WORKER_MULTIPROC_METHOD
            value: "spawn"
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
spec:
  type: LoadBalancer
  ports:
    - port: 8000
      targetPort: 8000
  selector:
    app: vllm-llama-service
kubectl apply -f vllm-deployment.yaml

# 水平自动扩缩容（HPA）
kubectl autoscale deployment vllm-llama-service \
  --cpu-percent=70 --min=2 --max=10

关键实现细节

Ollama 和 vLLM 架构差异（为什么性能差 3-10 倍）

Ollama 的设计：单进程 + GGUF 格式（通过 llama.cpp），追求极简启动，不擅长高并发。

vLLM 的核心竞争力：PagedAttention + 连续批处理（Continuous Batching）

Ollama 并发10用户:  ~100-200 tokens/s
vLLM 并发128用户:  ~2000-5000 tokens/s（3.23x 更快）

实测数据（来源：Kanerika 2026 评测，A100 GPU）：

场景OllamavLLM差距
单请求延迟1x0.8xvLLM 略优
50并发吞吐量1x3.23x显著优势
200并发稳定性崩溃稳定决定性差距

Ollama → vLLM 迁移的最小改动

两者的 /v1/chat/completions 接口完全兼容，迁移只需要换 base URL：

# 迁移前后只需改这一行
import openai

# 原来（Ollama）
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

# 迁移后（vLLM）
client = OpenAI(base_url="http://your-vllm-server:8000/v1", api_key="EMPTY")

# 其余代码完全不变
response = client.chat.completions.create(
    model="meta-llama/Llama-3.1-8B-Instruct",
    messages=[{"role": "user", "content": "Hello"}]
)

量化：用 Q4 量化降低 60% 显存占用

# vLLM 支持awq量化，显存直接砍半
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct-FP16 \
  --quantization awq \
  --gpu-memory-utilization 0.9
量化方式7B 模型显存质量损失适用场景
FP1614GB无精准场景
INT88GB<2%平衡方案
Q4_K_M5GB3-5%成本敏感
Q5_K_M6GB1-3%推荐方案

常见坑与规避清单

坑 1：Ollama 单机瓶颈被忽视

现象：本地测试完美，上线 20 并发就开始响应超时。
原因：Ollama 默认不支持连续批处理，单请求串行执行。
解法：并发超过 10 用户/秒 → 立即迁移 vLLM，不要在 Ollama 上浪费时间。

坑 2：vLLM 显存溢出（OOM）

现象：请求量增加后服务崩溃，dmesg 显示 GPU OOM。
原因：--gpu-memory-utilization 默认 0.9，但模型 + KV cache 实际占用会超出。
解法：

# 保险配置：降低到 0.85，给 KV cache 留足空间
--gpu-memory-utilization 0.85
# 同时控制生成长度
--max-model-len 4096  # 不需要 8K 就别开那么大

坑 3：模型格式混用

现象：Ollama 的 GGUF 模型无法直接给 vLLM 用，反之亦然。
解法：统一使用 HuggingFace safetensors 格式，从 HuggingFace 直接下载：

# vLLM
huggingface-cli download meta-llama/Llama-3.1-8B-Instruct

# Ollama
ollama pull llama3.1:8b  # 内部下载 GGUF

坑 4：冷启动延迟

现象：vLLM 首次加载模型需要 2-5 分钟。
解法：使用 Kubernetes 的 prePull 机制，节点启动时预先加载模型：

initContainers:
- name: model-downloader
  image: vllm/vllm-openai:latest
  command: ["python", "-c",
    "from vllm import LLM; LLM(model='meta-llama/Llama-3.1-8B-Instruct')"]
  resources:
    requests:
      nvidia.com/gpu: "1"

坑 5：Spot 实例中断导致服务不可用

现象：用 spot GPU 省钱，但实例被回收时服务直接中断。
解法：使用 vLLM 的检查点保存机制 + Kubernetes PDB（Pod Disruption Budget）：

spec:
  podDisruptionBudget:
    minAvailable: 1

成本/性能/维护权衡

选型决策树

日活用户 < 100?
├── 是 → Ollama（本地或单 GPU 云实例）
│        月成本：$0-300（看用什么机器）
└── 否 → 日活 100-5000?
         ├── 是 → vLLM 单卡（A10G 按量）
         │        月成本：$500-2000
         └── 否（5000+）→ vLLM 多卡 + 水平扩缩
                  月成本：$3000-10000+

每月 Token 消耗 > 10亿?
└── 是 → 考虑混合：简单请求用 Ollama，复杂请求用 vLLM

成本对比参考（2026年5月）

方案50并发用户/月200并发用户/月工程复杂度
托管 API（GPT-4o mini）~$500~$2000最低
Ollama 单机$0-300不推荐低
vLLM 单卡 A10G$500-800$1500-2500中
vLLM 多卡（2xA100）$2000-4000$6000-12000高
Ollama+vLLM 混合$300-600$2000-5000中高

关键洞察：大多数团队的跨点是 500-1000 日活用户，此时 vLLM 的 GPU 成本才低于托管 API。但 vLLM 的优势是数据不出境、无速率限制、无限 cost 透明度。

运维成本

维度OllamavLLM
部署时间<1小时4-8小时
监控复杂度低中（需 Prometheus/Grafana）
自动扩缩容不支持原生支持
故障恢复重启容器需要健康检查 + 重调度
版本更新频繁（社区驱动）稳定（基金会维护）

一周内可执行行动清单

Day 1-2：本地验证

  • 安装 Ollama，跑通至少 2 个模型（7B + 13B）
  • 用 ollama run 测试几个真实业务 prompt
  • 记录每个模型的响应质量和延迟

Day 3-4：云上基准测试

  • 在云上起一个 A10G 实例（按量计费，半小时约 $0.5）
  • 用 vLLM 部署同一模型
  • 用 locust 跑 50/100/200 并发，记录 P50/P95/P99 延迟
  • 确认吞吐量是 Ollama 的 2-3 倍

Day 5：架构决策

  • 根据压测结果和月预算选定方案
  • 如果选 vLLM：编写 Dockerfile，写好健康检查
  • 如果选 Ollama：写好 systemd 服务文件，确保崩溃重启

Day 6-7：生产准备（选做）

  • 配置 Prometheus 监控（关键指标：GPU 利用率、每秒 tokens、请求延迟）
  • 写好扩缩容策略（KEDA 或 HPA）
  • 建立 cost alert（GPU 利用率低于 30% 持续 1小时 → 缩容）

总结

Ollama 和 vLLM 不是非此即彼的选择，而是不同阶段的工具：

  • 原型验证阶段：Ollama 是正确答案——零门槛、立即上手
  • 流量验证阶段：vLLM 做基准测试，确认迁移ROI
  • 生产阶段：vLLM + Kubernetes 几乎是必选项

真正的成本节省来自于：不要在 Ollama 上为超过 10 并发的生产负载浪费精力，而是用节省下的时间先把业务价值验证清楚。

记住：2026 年 LLM 部署的核心竞争，已经不是”能不能跑起来”，而是”能不能高效、经济地在生产环境跑起来，并持续迭代”。