很多人挑本地推理框架时，先在本机用 Ollama 跑通了对话，就顺手拿去接业务，结果一上并发就卡成排队；也有人一上来照搬 vLLM 的部署方式，单用户试用反而折腾半天环境。这篇不评谁更好，只按「几个人用、要不要并发、显存多大、谁来维护」这几个条件，把两者的分界讲清楚，并给一套能自己动手验证的对照步骤。
很多人挑本地推理框架，路径都差不多：先在自己机器上用 Ollama 把模型拉下来跑通，对话顺了、效果也还行，就顺手接进业务里。结果一上并发就排队，几十秒才吐字。另一拨人反过来，一上来照搬 vLLM 那套部署方式，单用户试试效果，光环境就折腾半天。两种踩坑其实是同一件事：把两个设计目标不同的东西当成了替代品。
这篇不评谁更好，只按「几个人用、要不要并发、显存多大、谁来维护」这几条，把两者的分界讲清楚，再给一套你自己能动手验证的对照步骤。先记住一句：吞吐差异大多不是模型带来的，是调度方式和显存利用方式带来的。
先搞清两者设计目标不同，别拿同一把尺子量
Ollama 的默认目标是「一个人在本机把模型跑起来」：装完即用，模型拉取、切换、跑起来都顺手，优化方向是交互式对话的体验。vLLM 的目标是「把一张或多张卡的服务能力榨出来」，围绕批量请求调度和显存利用率做文章。目标不同，比较的维度就不该只有一个。
- Ollama
- 面向单机、单人、快速上手，把「能用」这件事的门槛压到最低，并发不是它的主战场。
- vLLM
- 面向持续服务，把同一张卡的并发吞吐做高，代价是部署和参数调优要自己扛。
- 吞吐
- 单位时间内服务完的请求数或总 token 数，多条请求同时来时才有意义。
- 首字延迟
- 从发请求到看到第一个字的时间，单用户体感主要由它决定，和总吞吐不是一回事。
所以比较前先问自己一句：你的场景是单人试用、内网小工具，还是要对外提供服务。什么情况下这套判断不适用——如果你只是在验证某个模型效果好不好，两个都能用，不用纠结；如果只是偶尔跑一次离线批处理，并发维度也可以先放一边。
吞吐差异怎么自己量出来，而不是听别人说
想比吞吐，最容易犯的错是变量没对齐：一个用默认量化、一个手动改过档位，或者最大输出长度不一样，测出来的差异根本不是框架带来的。先把权重、量化档位、最大输出长度、上下文长度这四个条件锁死，再开测。
- 固定变量同一份权重、同一量化档位、同样的最大输出长度和上下文长度，两边配置逐项对齐，配置差异记在表里，别只记结论。
- 单条请求打底先各发一条请求，记首字延迟和每秒出字数。这一步看的是单用户体感，通常两者差距没那么夸张。
- 并发逐档加压从低并发开始，逐档往上加同时请求数，记录每一档的总完成时间和是否报显存不足。找到那个开始掉速或报错的档位，它就是你这张卡的实际上限。
- 换框架重测同一张卡、同一批参数换成另一个框架再跑一遍，把显卡型号、显存、并发数、结果一起记下来。
显存怎么按模型和量化估算、单卡大概能扛多少并发，可以到 /models/deploy 用现成测算核对，比凭体感拍脑袋靠谱。测完你会发现，很多所谓「框架差距」其实是配置没对齐。
按场景对号：什么活该交给谁
| 你的场景 | 优先考虑 | 原因 |
|---|---|---|
| 单人开发、内网小工具、偶尔几个人用 | Ollama | 省下的是搭环境和维护的时间，资源占用也更好控制 |
| 对外接口、多用户同时用、要限流 | vLLM | 批量调度才有意义，否则并发压力只是换了种形式排队 |
| 先选型验证效果，再上服务 | 先 Ollama 后 vLLM | 验证阶段图快，服务阶段图吞吐，接口协议尽量保持一致 |
| 卡少又要高并发 | 先算卡再谈框架 | 换框架救不了硬件不够，先按模型算清卡数 |
- 少量用户、低并发、以对话为主：优先 Ollama，把精力放在模型选型和提示词上。
- 对外提供接口、有明显并发峰值：优先 vLLM，但先按目标并发反推显存和卡数。
- 既要试模型又要接业务：两边共用同一套接口协议，减少后期改动量，接入方式到 /ai-nav/category/ai-api 看。
- 不适用的情况：卡很少同时又要高并发，换框架解决不了，先到 /compute/sizing 按模型算一遍卡数。
从 Ollama 换到 vLLM 前，先过这张清单
决定换框架之前，别急着动手。真正卡住人的往往不是模型本身，而是接口、权重格式和回退方案这些周边问题。下面几项过一遍，能省掉不少返工。
- 接口与服务：确认现有调用方式能不能对上目标框架的接口，客户端要不要改，网关和鉴权放在哪一层。
- 权重与格式：确认要用的权重在目标框架上能正常加载，格式不匹配时先转格式，再谈部署。
- 显存与并发：按目标并发反推显存和卡数，长上下文请求单独算一遍，它比短问答吃显存得多。
- 许可证与合规：权重能不能商用、托管方式有没有额外限制，到 /safety 和模型库里核对说明。
- 回退方案：新服务稳定前不要直接切走老服务，保留可切回的路径。
吞吐是并发场景下的指标，单人用得好不好，是另一码事；先定场景，再选框架。下一步用你自己的卡和模型跑一遍并发对照，再拿结果去核对部署测算，选型就不是凭感觉了。→
常见问题
我小团队就三五个人的内部工具，是不是也得上 vLLM？
不一定。并发只有个位数、又没有对外服务要求时，Ollama 的维护成本更低，出问题也好排查。只有当多人同时请求开始排队、或者你要给别的系统提供稳定接口，vLLM 的批量调度才体现价值。先量一下你实际的并发峰值，再决定要不要换。
换个框架能让我的出字速度明显变快吗？
单条请求的生成速度更多由显卡、量化档位和模型大小决定，换框架的收益通常体现在多条并发时的总吞吐，而不是单条延迟。想提速度先看显存是不是吃满、有没有量化过、上下文是不是太长，这些在 /tools 里的换算工具能帮你先定位瓶颈。
两个框架能共用一套权重和客户端代码吗？
权重通常可以复用，但格式和加载方式可能要转换；客户端这边，只要两边都提供兼容的接口协议，改动的只是地址和少量参数。建议先在一个低风险场景里并行跑一段时间，比对结果一致性和稳定性，再决定整体切换。
