同一个开源模型，装到 Ollama 上跑得挺顺，换成 vLLM 却发现要改启动参数、还要算显存能不能装下；反过来，用 Ollama 给十几个人同时用，又慢到没法忍。问题不在模型，在两套框架的定位根本不同。这篇给一份对照思路：显存怎么算、并发怎么压、吞吐怎么量，以及什么情况下选哪个更省事。
同一个开源模型，装到 Ollama 上跑得挺顺，换成 vLLM 却发现要改启动参数、还要算显存够不够；反过来，用 Ollama 给十几个人同时用，又慢到没法忍。问题不在模型本身，在两套框架的定位根本不同：一个把「一个人马上能用」放在第一位，一个把「一张卡能扛多少路」放在第一位。
这篇给一份可落地的对照思路：先分清定位差异，再按显存、并发、吞吐三项逐条量，最后给一张按场景选框架的判断清单。里面提到的具体数字，都建议你拿自己的模型和卡到站内对应页面重新算一遍，别照搬别人的结论。
先分清定位：一个图省事，一个图扛量
Ollama 的默认假设是「这台机器就你一个人用」：拉模型、起对话、切上下文都在一条命令里完成，默认参数也是围着单人交互调的。vLLM 的默认假设是「这是一台要给外部提供接口的推理服务」：它把大部分精力花在请求调度和显存复用上，代价是端口、参数、显存池都得你自己管。
- Ollama
- 单机个人优先，装完即用，适合调试、离线跑批和单人问答
- vLLM
- 服务化优先，以批处理调度为核心，目标是把一张卡的吞吐压出来
- 选错的典型症状一：用 Ollama 给团队做接口，人一多就排队，延迟一路往上飘
- 选错的典型症状二：只想本地试一句话，却先得把 vLLM 服务起来、调好参数才能对话
- 判断口径：先问自己「这台机器最终是给几个人用」，再决定要不要为吞吐付出运维成本
显存怎么算：权重只是第一笔
很多人估显存只算权重，结果一启动就 OOM。实际上要留三笔账：权重本身、KV 缓存、框架运行开销（含激活值和临时缓冲）。权重看参数量和量化位宽；KV 缓存随上下文长度乘并发数线性增长，这一项才是两套框架拉开差距的地方。
| 占用项 | 随什么变化 | vLLM 的做法 | Ollama 的做法 |
|---|---|---|---|
| 权重 | 参数量 × 量化位宽 | 启动时一次性加载 | 启动时一次性加载 |
| KV 缓存 | 上下文长度 × 并发路数 | 用剩余显存预先划一块缓存池 | 按需增长，并发高时更容易触发换出 |
| 框架开销 | 激活值、临时缓冲 | 占用相对固定 | 占用相对固定 |
| 余量 | 并发波动 | 显存被预划走后余量偏小 | 余量更灵活，但吞吐上限也低 |
量化档位会同时影响「装不装得下」和「跑多快」，不同量化口径的实际占用到站内量化档位相关页面核对；具体能装下多大的模型、留多少余量，建议到 部署测算（/models/deploy） 页面按自己的卡和模型算一遍当时的数字。
- 第一步：算权重下限拿参数量和量化位宽估算权重占用，得到一个「绝对不能再低」的底数。
- 第二步：给 KV 缓存留位按你打算支持的最大上下文和目标并发数估算缓存大小，vLLM 要额外留出预划缓存池的空间。
- 第三步：留运行开销与余量再留一部分给激活值和框架本身，避免长上下文或并发峰值时被挤爆。
- 第四步：小并发先验证先用低并发起服务，看显存实际占用，再逐步往上加压，而不是一次拉到目标值。
并发与吞吐：差别在上限，不在单次速度
单人一问一答时，两套框架的体感差距其实不大，真正的分水岭在并发。vLLM 靠连续批处理把多路请求塞进同一轮前向计算，卡越闲越能塞；Ollama 在多人同时用时基本是排队串行，第二个人的请求得等第一个人的回复吐完。所以对比时要盯「上限」，不要盯「单条多快」。
- 量吞吐要两个维度一起看：tokens/秒 加 同时有多少路请求，只看单条延迟会被误导
- 压测前先量网络与接口本身的延迟基线，用 接口测速（/tools/speed-test） 排除掉网络抖动带来的干扰
- 用自己真实的任务文本压，不要用「你好」这类超短输入，长输入长输出才能暴露缓存和调度的差异
- 记录每路响应时间从哪一路开始明显变差，那个并发点就是你当前配置的实际上限
- 换框架前后用同一批请求、同一台机器复测，否则结论不可比
如果你关心不同框架在同一张卡上的实际表现，站内会持续收录相关的实测与价格追踪数据，具体数值到 价格追踪（/price-watch） 和相关评测页面核对当时的数字，别把这里的判断当成固定结论。
什么时候选哪个：一张判断清单
| 你的场景 | 更省事的选择 | 理由 |
|---|---|---|
| 本地试模型、调提示词、单人离线跑批 | Ollama | 装完即用，不必先起服务 |
| 对外提供 API、多人共用、要稳定吞吐 | vLLM | 批处理调度能把一张卡的吞吐压出来 |
| 显存本来就紧张、模型勉强装下 | 先别换框架 | 换框架救不了，先做量化或换更小的卡型 |
| 只想验证效果、不追求吞吐 | Ollama | 上 vLLM 只会增加配置和运维成本 |
有一条判断要提前说清楚：如果显存本身就装不下目标模型，换框架不会变魔术，这时候该做的是降量化档位或换更小的模型/卡型，而不是在 Ollama 和 vLLM 之间反复折腾。同样，如果你只是想看看模型回答得怎么样，也完全没必要为吞吐上 vLLM。
- 第一步：估显存按上一节的方法算权重、KV 缓存和余量，先确认模型能不能装下。
- 第二步：定并发目标明确这台机器最终要给几个人用、峰值大概多少路请求。
- 第三步：选框架用上面的对照表先定一个候选，别一上来就两套都搭。
- 第四步：压一轮真实任务拿自己真实的任务文本从低并发加到目标并发，看响应时间在哪一路明显劣化。
- 第五步：按结果收敛如果 vLLM 也撑不住目标并发，考虑加卡、降上下文或降量化，而不是继续调参。
框架选型先看给谁用、显存装不装得下，再看并发目标；顺序错了，调参调到天亮也没用。下一步想确认自己这台机器到底适合哪套框架，可以先去站内做一次部署测算，再对着评测数据压一轮真实请求，用当时的数字下结论。→
常见问题
同一个模型，换框架会让回答质量变吗？
框架本身不改变权重，正常情况下输出质量应当接近。差异往往来自采样参数默认值、上下文截断方式和量化档位不同。如果感觉明显变差，先对齐这几项再说；具体对照口径到站内量化档位选型相关页面看。
显存明明够，为什么还是跑不起来或很慢？
常见原因是 KV 缓存预分配的余量没留够、上下文长度设得远超实际需要、或者被其他进程占了显存。先把上下文调小、并发降到 1 试一遍，再逐步往上加，找到拐点比一次性拉满更靠谱。
怎么判断该不该从 Ollama 换到 vLLM？
看两个信号：一是多人同时用时响应明显变慢且排队，二是单卡利用率长期偏低却顶不住请求量。这两条同时出现，说明瓶颈在调度而不是硬件，值得折腾切换；只是自己偶尔用用，换了收益有限。
