vLLM 和 Ollama 怎么选：高并发场景实测对比

Q: Ollama 支持并发请求吗？

支持，但默认关着。OLLAMA_NUM_PARALLEL 默认值是 1，意味着同一个模型的多个请求默认是排队处理的，不是同时处理。手动调高这个值可以开并行，但受限于显存，调太高反而会因为频繁换入换出拖慢速度。

Q: vLLM 比 Ollama 快多少？

看并发量。单请求时两者接近，Ollama 有时首字延迟还更低。8 个并发请求时 vLLM 吞吐量大约是 Ollama 的 2.3 倍；50 个并发用户时 Ollama 的首字响应时间能拖到 3 秒以上，vLLM 还稳定在 150 毫秒左右；64-256 用户的极限测试里，vLLM 能到 Ollama 的 8-9 倍甚至更高。

Q: vLLM 部署比 Ollama 复杂多少？

复杂不少。Ollama 一条命令拉起服务，ollama run 就能用；vLLM 需要装 CUDA 环境、匹配 PyTorch 版本、算好显存配比，对新手不算友好，更适合有一定运维经验、且明确要扛并发的团队。

Q: 小团队内部用哪个更合适？

如果只是几个人共用一台机器、请求量不密集，Ollama 完全够用，省心。一旦这个内部服务开始接普通用户的请求，或者你发现请求经常在排队，就是该考虑 vLLM 的信号了。

AIEII

先说结论：一个人用、或者团队里三五个人零星调用，Ollama 完全够用，装好就跑，不用纠结。但如果你要拿本地模型接一个对外服务，哪怕只是给公司内部几十号人用的工具，并发请求一多，Ollama 的排队延迟会立刻暴露，这时候该换 vLLM 了。

这篇不讲两边怎么装，讲的是在什么并发规模下该切换，以及切换到底能换来多少实打实的性能。

先看两边在做的是两件不太一样的事

Ollama 的定位是"本地跑起来最省事"，背后是 llama.cpp，主打单机、低门槛，ollama run 一行命令就能对话。vLLM 的定位是"生产级推理服务"，核心技术是 PagedAttention（把显存里的 KV 缓存按页管理，减少浪费）加上连续批处理（continuous batching，新请求可以随时插入正在处理的批次，不用等上一批全部跑完）。

这两个设计目标决定了它们在单请求和多请求场景下的表现会走向完全不同的方向。

单请求场景：基本没差，Ollama 甚至更快

多个实测数据显示，在只有一个请求的情况下，Ollama 和 vLLM 的每秒 token 数差距在个位数到 20% 之间，Ollama 的首字响应速度往往还略胜一筹。一个针对 Llama 3 8B（FP16 精度，A100 显卡）的对比测试里，单请求场景下 Ollama 跑到约 45 tokens/s，vLLM 是 38 tokens/s。

这个阶段选 Ollama 完全说得通：部署简单、单请求还更快，没理由折腾。

并发一上来，差距就拉开了

问题出在并发。同样是 Llama 3 8B 的测试，8 个并发请求同时打进来时，vLLM 能跑到 187 tokens/s，Ollama 只有 82 tokens/s，差了 2.3 倍。

再往上，50 个并发用户的场景下，Ollama 的首字响应时间（time-to-first-token）会拖到大约 3200 毫秒，因为请求在排队等前面的处理完；vLLM 因为连续批处理能把新请求随时塞进正在跑的批次，首字响应稳定在 145 毫秒左右。

极限场景更夸张：在 Blackwell 显卡上跑 Llama 3.1 70B、用 NVFP4 量化，vLLM 能压到 8033 tokens/s，Ollama 只有 484 tokens/s，差了 16.6 倍。而在 64 到 256 用户的高并发区间，多份测试给出的估计是 vLLM 的聚合吞吐量能到 Ollama 的 8-9 倍。

差距的根源：Ollama 默认在排队，不是真并行

这里有个容易被忽略的配置细节：OLLAMA_NUM_PARALLEL 这个环境变量控制单个模型同时处理多少个请求，默认值是 1。也就是说，如果你没手动调过这个参数，Ollama 收到的请求本质上是排队串行处理的，即便你的机器显存完全够用。

配套的还有两个参数：OLLAMA_MAX_LOADED_MODELS（同时能加载几个模型，默认是 GPU 数量乘 3，或 CPU 推理时固定 3）和 OLLAMA_MAX_QUEUE（排队上限，默认 512，超过就直接拒绝新请求）。手动把 OLLAMA_NUM_PARALLEL 调高确实能开并行，但受限于显存，请求数一多就会出现模型频繁换入换出，实际收益有限，天花板明显低于 vLLM 的 PagedAttention 方案。

部署门槛：这是 Ollama 唯一能打回来的地方

vLLM 不是没有代价。它要求配好 CUDA 环境、匹配对应的 PyTorch 版本、还要自己计算显存配比（gpu_memory_utilization 这类参数），对新手不友好，出错排查也比 Ollama 麻烦。Ollama 就是 ollama run 一行命令的事，这也是为什么本地实验、单机原型、小范围内部工具依然应该优先选 Ollama。

该怎么选：按你的并发场景倒推

场景	建议
自己一个人用，本地跑模型写代码/问答	Ollama，装完就用
团队几个人零星调用，请求不密集	Ollama，够用且省事
内部工具，几十人共用，偶尔会撞车排队	开始评估 vLLM，或先把 `OLLAMA_NUM_PARALLEL` 调高应急
对外服务，几十到上百并发用户	直接上 vLLM，PagedAttention 和连续批处理是刚需
显卡是消费级卡、显存有限	两边都受限，但 vLLM 的显存利用率优势在多请求下依然更明显

我的判断

这不是一个"哪个更好"的问题，是一个"你现在的并发量到了哪个阶段"的问题。Ollama 的省心是真省心，但它的并行能力是被默认配置故意压低的，很多人吐槽它并发差，其实只是没打开 OLLAMA_NUM_PARALLEL；打开之后确实能缓解一部分，但架构上限还是够不到 vLLM。如果你已经在纠结要不要迁移，大概率说明你的请求量已经过了 Ollama 舒服区间的门槛，这时候花时间搭 vLLM 环境是值的，迁移成本会比继续忍受排队延迟低。