这两个项目经常被放在一起比，但它们回答的不是同一个问题。Ollama 回答的是"我怎么在自己机器上最快把一个模型跑起来"，vLLM 回答的是"我怎么用一张或几张卡把并发请求的吞吐做到最高"。选择之前先想清楚一件事：你到底有几个并发用户。
能力边界对比
Ollama 的定位是本地模型运行器。一条 ollama run qwen3:8b 就能对话，模型是 GGUF 格式，权重和配置打包成一个 Modelfile，拉下来就能用。它自带一套 HTTP API，/api/generate 单轮生成，/api/chat 多轮对话，/api/embed 做向量，/api/tags 列本地模型，/api/ps 看正在跑的实例，外加 /api/pull、/api/create 这些管理端点。同时它提供 OpenAI 兼容层，/v1/chat/completions 和 /v1/embeddings 都能直接接，很多客户端不用改代码就能用。
vLLM 是推理引擎。它不负责模型管理，也不做"一条命令跑起来"这件事，核心是调度与显存管理：PagedAttention 把 KV cache 切成页来管理，continuous batching 让新请求能插进正在跑的批次里，这两件事决定了它在高并发下的吞吐优势。模型用 Hugging Face 的 safetensors 格式，vllm serve 起一个 OpenAI 兼容服务，多卡用 --tensor-parallel-size 切。
一句话的区别：Ollama 把"模型 + 运行环境 + 接口"打包成一个东西；vLLM 只做推理这一层，上下都要你自己接。
横向对比
| 维度 | Ollama | vLLM |
|---|---|---|
| 上手成本 | 一条命令，分钟级 | 需要装 Python 环境、配显存参数 |
| 模型格式 | GGUF（含多种量化） | safetensors（原精度或 AWQ/GPTQ 等量化） |
| 并发模型 | 默认单请求排队，靠 num_parallel 提高并行 | continuous batching，为高并发设计 |
| 多卡 | 支持有限，主要靠模型切分 | 张量并行、流水并行，成熟 |
| 显存控制 | 自动按可用显存选层数 | 手动设 max-model-len、gpu-memory-utilization |
| 接口 | 自有 API + OpenAI 兼容 | OpenAI 兼容 |
| 空闲卸载 | keep_alive 到期自动卸载 | 常驻，不自动卸载 |
| 适合场景 | 单机开发、桌面端、内网小工具 | 服务端、批量推理、多用户 |
这张表里最有信息量的是"空闲卸载"和"并发模型"两行。前者决定了 Ollama 适合装在笔记本上、用完自动让出显存；后者决定了 vLLM 在十个用户同时提问时不会退化成排队。
具体配置
Ollama 有两个参数值得单独调。一个是 keep_alive，控制模型加载后多久没请求就卸载，默认 5 分钟，可以按请求传：
curl http://localhost:11434/api/chat -d '{
"model": "qwen3:8b",
"messages": [{"role": "user", "content": "用一句话说明 PagedAttention"}],
"keep_alive": "30m",
"stream": false
}'
另一个是并行数。Ollama 默认一次只处理一个请求，多来的排队。设 OLLAMA_NUM_PARALLEL=4 能让它同时处理四个，代价是显存占用按倍数涨——这个参数的直觉是"用显存换并发"，显存不够时设了也会退回串行。
vLLM 的关键参数是三个：--max-model-len 控制上下文长度上限（直接决定 KV cache 占用）、--gpu-memory-utilization 控制预分配的显存比例（默认 0.9）、--max-num-seqs 控制同时在跑的序列数。
vllm serve Qwen/Qwen3-8B --served-model-name qwen3-8b --max-model-len 16384 --gpu-memory-utilization 0.85 --max-num-seqs 32 --port 8000
--gpu-memory-utilization 0.85 而不是默认 0.9，是留一点余量给 CUDA context 和临时张量。卡上跑满之后出现的 OOM 往往不是模型本身要的显存多，是留给临时缓冲的那部分被吃掉了。
选型判断
按场景切最省事：
单人开发、桌面常驻、偶尔调用——Ollama。它的价值是"不用管"，模型仓库直接拉，切模型改个名字就行。
内网小工具、五到十个用户、请求不密集——Ollama 也够，把 num_parallel 调到 4 到 8，配一个前置的请求队列，效果和 vLLM 差距不大，但省了一整套部署。
服务端、请求有尖峰、多用户并发——vLLM。continuous batching 带来的差别在并发上来之后非常明显，Ollama 那边是排队，vLLM 那边是批处理。
需要跑 AWQ、GPTQ 这类量化权重，或者要上多卡张量并行——只有 vLLM。
需要按请求动态加载不同模型、跑完就释放显存——Ollama 的 keep_alive 机制更贴合，vLLM 更适合"一个服务一个模型"的常驻形态。
还有个混合用法值得一提：开发阶段用 Ollama 在本机迭代提示词，上线换 vLLM，两者都走 OpenAI 兼容接口，切换只改 base_url 和模型名。前提是别用只有一边支持的特性——比如 Ollama 的 Modelfile 里写死的系统提示词、vLLM 的 guided decoding，用了就绑定了。
不适合谁
Ollama 不适合做高并发 API 网关。它的设计目标不是吞吐，硬顶并发的结果是延迟抖动，而且缺乏细粒度的显存与批处理控制。
vLLM 不适合需要频繁换模型的小规模场景。每次换模型都要重启服务、重新编译图、重新加载权重，几十秒到几分钟不等，这个代价在实验阶段很难受。
两者都不适合"我只想调 API 不想管机器"。真要省事，托管服务比自建便宜，这个账要自己算清楚：一张卡的折旧、电费、运维时间，折算下来往往超过按量付费。