ollama 和 vllm 对比

很多人本地部署时先在 Ollama 上把模型跑通了，觉得挺顺，等到要给团队或线上业务提供接口，才发现并发一上来就撑不住；也有人一上来就上 vLLM，结果光装环境、对权重格式就折腾好几天。这篇不站队，只按你的真实场景拆：什么时候该图省事，什么时候必须换高吞吐框架，以及换之前要做哪几步验证。

很多人本地部署模型的路子都差不多：先用 Ollama 把模型拉下来，一条命令跑通，觉得挺顺；等到要给团队或者线上业务提供接口，并发一上来就发现撑不住。也有人反过来，一上来就上 vLLM，结果光装环境、对权重格式、配并行参数就折腾好几天，还没跑到第一条推理。这两种翻车方式都很常见。

这篇不站队，只按你的真实场景来拆：什么时候该图省事，什么时候必须换高吞吐框架，以及换之前要做哪几步验证。判断标准会给清楚，也会说明什么情况下不适用。所有涉及具体数字的地方，都建议你自己跑一遍或者到站内对应页面核对当时的数值，别人博客里的数字对你的配置没有参考价值。

先分清两者到底在解决什么

最容易踩的坑是把它们看成升级关系——好像 Ollama 是入门版、vLLM 是进阶版，早晚要换。实际上它们解决的是两个不同阶段的问题：一个管「跑不跑得起来」，一个管「撑不撑得住量」。你的请求画像不同，答案就不同，跟哪个更先进没关系。

Ollama

把模型拉下来、一条命令跑起来，模型打包、量化分发、本地接口都替你办了，代价是调度策略偏保守，面向单机少量请求

vLLM

用一张卡顶住尽量多的并发，围绕显存分页和批处理做优化，代价是安装、权重格式、启动参数都得自己盯

请求画像

同时几个人在用、有没有峰值、在不在意首字延迟——这才是选型的真正依据

• 如果你只是自己用、或者小团队几个人轮流调用，Ollama 的省事是真省事，多花的那点时间比多占的显存值钱
• 如果你要把模型接进已有系统当后端服务，或者有明确的并发峰值，那就得认真评 vLLM
• 如果现在还在验证模型能力阶段，压根没到压并发的时候，先别急着换框架
• 如果团队里没人愿意维护服务端，性能再好的框架最后也会变成没人敢动的黑盒

易用性差在哪：装、跑、改三步对照

易用性差距主要落在三个动作上：装、跑、改。这三步里 Ollama 基本是顺着走，vLLM 每一步都可能卡住你。下面这张表按动作拆开对比，你可以对照自己最怕哪一步。

这张表里最容易被低估的是最后一行。Ollama 调错了顶多是效果差一点，服务还在；vLLM 参数给错往往直接启动失败，而且报错信息不一定直指根因。所以如果你打算上 vLLM，先把环境版本和权重格式这两件事确认死，再谈性能。

1. 确认驱动与环境版本先跑一次官方的环境检查命令，把驱动版本、CUDA 版本、Python 版本记下来，和你要装的框架要求逐条对照，不要凭印象觉得「应该够新」
2. 确认权重格式看看手上的模型是原生权重还是已经被打包成别的格式，如果是后者，先找对应的原始权重来源，别指望直接搬文件
3. 用一个最小例子跑通先用最短的提示词、最小的上下文把服务起起来，确认能出结果，再去调并发和批大小参数
4. 记录能跑通的那套配置把版本号、启动参数、模型路径写进一个文件，下次换机器或者重装时直接照抄，别相信自己的记忆

吞吐差在哪：并发一上来就现原形

低并发、单条对话的场景，两者体感差距不大，甚至因为 Ollama 的模型已经量化好，启动还更快。真正拉开差距是在并发上来之后：vLLM 靠连续批处理和显存共享，把多路请求塞进同一轮计算；Ollama 更接近按请求排队处理，一路堵着后面就得等。

• 长上下文场景：KV 缓存占用被放大，调度策略的差异会直接反映在延迟上
• 多轮会话场景：每轮都要重新算前缀，能不能复用缓存影响巨大
• 批量离线任务：一批请求同时打进来，吞吐差距最明显
• 持续高并发：偶发峰值两边都能扛，持续压着才见真章

但结论不要靠猜。把你自己的真实请求打一遍，量两个数就够了：首字延迟和整体每秒出字。方法可以参照 接口测速（/tools/speed-test） 里的思路，固定提示词、固定并发数、两个框架各跑一轮，把结果并排放。别人环境里的数字，对你的卡型和量化档位没什么参考价值。

先看硬件再选框架，别反过来

顺序很重要：先看手上的卡能支撑什么，再决定用哪个框架。反过来先选框架再去凑硬件，大概率是白折腾。显存是硬门槛，模型权重、KV 缓存、批处理都要占显存，量化档位直接决定你能跑多大模型、能同时接多少请求。

同一张卡跑同一个模型，两个框架能承载的并发不是一个量级，但具体能到多少，取决于量化方式、上下文长度和你要的延迟水平。这些数字可以在 部署测算（/models/deploy） 里按模型和卡型过一遍，别拿别人环境里的结论直接套。

• 只有单张消费级卡、显存紧张：先老实做量化，别指望换框架能变出显存来
• 显存够但并发要求不高：省事优先，没必要为了用不上的吞吐去扛安装成本
• 多卡场景才有必要考虑张量并行这类配置，单卡折腾并行基本是纯亏时间
• 没有独显或者跑在 Mac 上：两边优化空间都有限，得换部署思路而不是换框架

按场景选：一张对照清单

下面这张表把常见场景和推荐方向对应起来，你可以直接对号入座。注意这里的「推荐」是起点不是终点，真到要上量的时候还是得自己验一遍。

最后一行值得单独说：把接口层和推理后端解耦，是唯一能让你现在省事、以后也不被绑死的做法。业务代码只认 OpenAI 风格的调用，后端是 Ollama 还是 vLLM 只是一个配置项。

从 Ollama 迁到 vLLM 的落地步骤

真要迁的时候，别关掉旧的直接开新的。下面这套顺序的核心思路是：先量清楚需求，再小流量并行验证，最后才切。每一步都有验证动作，做完再进下一步。

1. 量清楚请求画像统计并发上限、典型上下文长度、有没有流式输出需求。这些决定启动参数怎么给，不给清楚就是瞎调
2. 确认权重来源如果原模型只有 Ollama 格式，先找到对应的原始权重或量化版本。这一步花的时间往往比装框架还长，提前排
3. 新旧并行跑两个服务同时挂上，把一小部分流量切过去，对比延迟和错误率。不要一次性全切，也不要只在测试环境跑跑就算
4. 留好回退开关Ollama 服务先别删，配置里留一个能快速切回的开关。真出问题时，五分钟能切回来比什么都强
5. 迁移后重测指标首字延迟和每秒出字重新量一遍，不要沿用迁移前的预期。换了调度方式，原来的数字就不再适用

什么情况下这两条路都不适用

有几个场景，纠结这两个框架本身就是走错方向了。判断标准很简单：如果问题不在「用哪个框架」，那换框架也解决不了。

• 只是偶尔问几个问题：直接调用云端接口往往比自己维护一套本地服务更划算，成本账可以看 买卡还是租卡（/compute/tco） 的估算思路
• 模型跑在 Mac 或没有独显的机器上：两边优化空间都有限，得换部署思路
• 团队里没人愿意维护服务端：vLLM 大概率会变成没人敢动的黑盒，这时候工具好用比性能好更重要
• 合规要求数据完全不出内网：前置问题其实是整体部署方案，而不是这两个框架谁更快

另外还有一种情况：你的瓶颈根本不在推理框架上，而在网络、存储或者上游业务逻辑。这种时候换框架的收益接近于零，先去把真正的瓶颈定位出来。

选之前先做一次自己的小验证

不管前面看得多明白，最后都要回到一次最小验证上。这套验证不需要多复杂，但要可复现：同一段提示词、同一个模型、同一个固定并发数，两个框架各跑一轮，把三个数记下来——首字延迟、整体每秒出字、失败率，其他指标先不用管。

同时把模型规格、量化方式和硬件配置一并记下来，否则这些数字之间没有可比性。反推配置是否合理时，可以参考 几张卡够用（/compute/sizing） 里的估算思路，但不要直接照搬别人的结论。验证结果无论最后选哪个，都比任何一篇对比文章更可靠。

• 固定变量：模型、量化档位、提示词、并发数、上下文长度
• 记录三个数：首字延迟、每秒出字、失败率
• 写明环境：卡型、显存、驱动版本、两边的启动参数
• 跑两轮以上：排除偶发抖动，别拿单次结果下结论

选型不是选更强的那个，是选你的团队在这个阶段能维护得住、并且撑得起真实请求的那个。