你装的 Ollama，在多用户场景下会慢 20 倍——但这不是它的错

Mon, 29 Jun 2026 20:00:00 +0800

你装了 Ollama，跑个 Qwen3 8B。一个人用，很流畅。

然后给团队搭了个内部 chatbot。三个人同时用——卡炸了。

你以为是模型太大，换了更小的模型。还是卡。

这时候你可能开始怀疑：是不是 Ollama 性能不行？

不是。问题根本不在于 Ollama 快不快。而在于你把它用在了它不被设计服务的场景里。

一个人 v.s. 三个人，不是「慢一点」，是架构决定的

先说一组数据。同一块 GPU，跑同一个模型：

并发数	Ollama（总 tok/s）	vLLM（总 tok/s）	差距
1	~62	~71	~1.1x
8	~82	~187	~2.3x
50	~155	~920	~5.9x
100+	封顶	继续涨	~15-20x

一个人用，Ollama 和 vLLM 几乎一样快。

两个人开始，vLLM 慢慢拉开距离。

五十个人？Ollama 的吞吐量基本封顶了——请求在排队，后来的等着前面的完成才能开始。vLLM 还在涨。

这不是 Ollama「性能不行」。「性能」这个词让你觉得是优化做得不够，换个版本、换个模型、换个量化格式就能追上。但这不是优化问题——是架构不为此设计。

Ollama 做推理的方式很简单：来一个请求，生成完，再来下一个。它不做 continuous batching。

什么叫 continuous batching？想象一个收银台。传统做法：排一队，一个一个结。轮到你才开始，结完才叫下一个。

Continuous batching 的做法：柜台一有空位，就让新人进来。不等前面的人全结完。柜台利用率直接拉满。

vLLM 就是这样调度请求的。每一轮推理迭代，它重新看一遍「现在谁还需要计算」，有空位就把新请求塞进去。GPU 利用率从 ~50% 拉到 85-92%。

Ollama 的设计目标从来不是「服务多用户」。它的价值是另一件事——让开发者用一条命令跑起一个模型。

1
2


ollama pull qwen3:8b
ollama run qwen3:8b

两条命令，从选模型到本地 API，全程不超过两分钟。这个体验就是 Ollama 的核心竞争力。