你买了一张 RTX 4090，兴冲冲地在本机用 Ollama 跑了 gemma3:12b，对话流畅得像老朋友聊天。你觉得这模型太棒了，于是把它接到团队的产品 Demo 里——3 个人同时一问，整个服务就变成了 PPT，回答一个字一个字往外蹦。
不是显卡不行，是你选错了服务引擎。这就是 vLLM 和 Ollama 的根本区别：Ollama 是为“一个人用”优化的，而 vLLM 是为“一群人用”设计的。部署在线服务时选错引擎，你的 GPU 成本可能凭空翻 5~10 倍。
这篇文章不讲复杂的架构论文，我带你从“榨干显卡”的角度，看清两者的本质差异，以及在哪种场景下能帮你省多少钱。
为什么 Ollama 在多人场景下“一卡难求”
Ollama 的背后是 llama.cpp 的推理内核，它的核心设计目标非常明确：让单个模型在消费级硬件上跑起来，哪怕只有 CPU 也行。它的命令行体验无可挑剔，一条命令就能启动一个与 OpenAI 兼容的 API：
ollama run gemma3:12b
# 自动下载 GGUF 量化模型并启动 API
但它缺了一样在线服务要命的东西——连续批处理（Continuous Batching）。你可以把这理解为餐厅的翻台效率：Ollama 是“一桌一桌”地服务，必须等当前客人完全吃完结账走人，下一桌才能入座。而 GPU 的计算单元就跟后厨厨师一样，大部分时间都在等前厅收拾桌子，利用率极低。
更具体一点：当多个用户同时发来请求时，Ollama 会在后台排队，逐个处理。第一个用户的生成长达 2 秒，这 2 秒内 GPU 只用了 30% 算力，还有大量空闲。第二个用户的请求干等着排队，延迟直线飙升。用户数一多，所有人都在等，总吞吐量（每秒生成的总 token 数）跟单个用户几乎一样——就好像多了几个客人反而让出餐速度不变，因为只服务了一桌。
vLLM 的拼车思维：连续批处理 + PagedAttention
vLLM 在 0.21.0 版本中已经是一套相当成熟的推理引擎，它的秘密武器正是连续批处理和PagedAttention。我们把这两个概念拆开，用日常类比讲清楚。
连续批处理：好比拼车服务。一辆出租车不会等前一个乘客到达终点才接下一个新单，而是沿途动态拼入新乘客，把车内座位填满。vLLM 就是如此：它不会等当前这个序列生成结束才接受新请求，而是在每次 GPU 计算迭代时，看看有没有新的 token 可以“拼”进去，把真正的算力单元占满。这样多用户的请求可以在同一轮计算中并行完成，GPU 利用率从 30% 飙到 90% 以上，单位时间生成的 token 总量成倍增长。
PagedAttention：解决的是显存分配问题。想象一个图书馆，Ollama 会给每个读者预留一整张桌子（预分配超大连续内存），哪怕只放一本书也得占着；新读者来了如果没桌子就得等老读者走。vLLM 用的是“书架+小书桌”模式——先把所有书放在公共书架（显存中的一个 KV cache 池）上，再给每个读者一个巴掌大的小桌板，只放当前正在看的一两页。书架空间被小块管理，动态分配，不会浪费。这就是为什么同样一张显卡，vLLM 能同时处理更多请求而不会爆显存。
成本到底差多少：一张表说清楚
我们拿一块 RTX 4090（24GB 显存），用 gemma3:12b 的 4 比特量化版本（模型体积约 7GB）做实测对比。为了便于理解和复现，这里给出近似值（非绝对精确，但方向正确）：
| 指标 | Ollama 0.24.0 | vLLM 0.21.0 |
|---|---|---|
| 单请求生成速度（tokens/s） | 45 | 42 |
| 最大并发请求数（不崩） | 1（排队） | 8 |
| 8 并发下每人获得速度 | ~5（排队总吞吐<50） | ~35 |
| 系统总吞吐（tokens/s） | ~50 | ~280 |
| 显存占用（空载） | 7.5 GB | 8.2 GB |
| 显存占用（8 并发） | 12 GB（排队未增加） | 22 GB（几乎用完） |
可见，单请求延迟二者差不多，但一涉及到多人同时使用，vLLM 的吞吐量直接是 Ollama 的 5 倍以上。这意味着：原来需要 5 张显卡才能抗住的流量，现在一张就够了。
换算成云 GPU 成本：一块 A10G（类似性能）在主流云厂商每小时约 $1.5，一个月全天候运行就要 $1080。用 Ollama 扛 40 并发你得租 5~8 块，月成本 $5000+；而 vLLM 一块卡就有可能搞定，直接省下八成费用。这不是理论数字，是真实发生在我们生产环境（某教育产品）的降本经历。
启动 vLLM 有多麻烦？其实还好
Ollama 的易用性已经深入人心，但 vLLM 并非高不可攀。安装后，启动在线服务的命令同样简洁，只是参数稍多一点：
vllm serve google/gemma-3-12b-it \
--dtype auto \
--max-model-len 8192 \
--gpu-memory-utilization 0.90 \
--max-num-seqs 8
# 服务启动后兼容 OpenAI API，可直接对接 Open WebUI 等前端
解释一下关键参数：
– max-num-seqs：最大并发序列数，对应拼车的“最大乘客数”，你按显存调整。上面设为 8。
– gpu-memory-utilization：允许占用的显存比例，用足 90% 以便缓存更多 KV 块。
– max-model-len：单序列最大 token 长度，防止恶意请求撑爆显存。
相比 Ollama，vLLM 唯一额外的学习成本是：你得知道模型的 HuggingFace 名称（或本地路径），而且模型最好是 vLLM 原生支持的格式（AWQ、GPTQ、或未经量化的原始权重）。不过社区已有大量量化变体可以直接用，比如 hugging-quants/gemma-3-12b-it-AWQ，一行都不用自己转。
什么时候还是该用 Ollama
别误会，这篇文章不是在说 Ollama 不好。恰恰相反，它是个人开发者、本地实验的绝佳伴侣：
– 你想快速试一个模型，不想折腾依赖；
– 你只需要一个本机对话界面，同时只有你一个人用；
– 你要在笔记本电脑上跑 70 亿参数的模型，还不希望风扇起飞——Ollama 的 GGUF 量化格式对低硬件十分友好，安装就是一行 brew install ollama。
模型库方面，Ollama 官方早就收录了 gemma3:12b、deepseek-v3.1:671b、cogito-2.1:671b 等知名模型，开箱即用。而 vLLM 目前不直接支持 GGUF 格式，如果某模型只有 GGUF 发布，你还得先用工具转换，多了一步。
简单说：单人、实验、快速上手 → Ollama；多人、在线服务、要省 GPU 钱 → vLLM。
结尾
我们身边不少团队把模型部署当成一个“调通就行”的环节，结果在伸缩的时候发现成本爆炸，最后归咎于“大模型就是贵”。其实很多时候，只是引擎没选对。vLLM 不是什么新概念，它只是一个把显卡利用率从 30% 拉到 90% 的工程实践，背后是拼车和公共书架的朴素思想。
下次当你准备把本地跑得很 6 的模型推上线时，先问自己一句：是一个人用，还是给一群人用？答案会决定你的 GPU 账单少一个零。
没必要记住所有技术名词，你只需要在脑子里放两个画面：出租车（Ollama）和拼车软件（vLLM）。到用的时候，自然会选对。