vllm 和 ollama 对比

很多人第一次搭本地服务，都会先在笔记本上装个 Ollama 跑通，感觉一切顺利；等到要给团队或线上用，才发现并发一上来延迟就顶不住，回头换成 vLLM 又是一堆参数和显存问题。这篇不给你一个「谁更强」的结论，而是把两者的定位差异、性能差在哪、以及按你的场景怎么落地选型讲清楚，让你少走一次重搭的弯路。

很多人第一次搭本地服务，都是在笔记本上装个 Ollama，拉个模型、问两句、跑通了，心里觉得这事挺简单。等到要给团队用，或者有个程序要持续调它，才发现情况变了：并发一上来延迟就顶不住，业务那边开始抱怨「怎么这么慢」。这时候回头换 vLLM，又是显存、又是权重格式、又是一堆启动参数，环境能折腾掉一整天。这篇不打算给你一个「谁更强」的结论，而是把两者定位差在哪、性能差距到底出在什么环节、以及按你的场景该怎么落地选型讲清楚，让你少走一次重搭的弯路。

先记住一个前提：这两个东西不是同一个赛道上的竞品。拿它俩比谁快，就像拿电动螺丝刀和台式钻床比谁有力气，看你拧的是螺丝还是打的混凝土。下面按定位、并发、硬件、部署动作、迁移时机、选型对照、许可证与运维几块拆开说，每一块都给出能直接拿去判断的标准。

先分清楚：一个像工具箱，一个像生产引擎

Ollama 的设计出发点是「让个人在本机把模型跑起来」。你装完它，拉模型、选量化档、显存不够自动往 CPU 或内存卸载，这些它都替你兜底，你不需要知道底层用了什么推理后端。vLLM 的出发点完全不同，它默认你有一块像样的加速卡、一台常开的机器、并且有一群用户或者程序要持续连进来，它的一切优化都围绕吞吐和并发调度展开。

Ollama 的默认假设

单用户、间歇调用、机器就是你的笔记本或一台小主机，先跑起来比跑得快重要

vLLM 的默认假设

多用户或高频调用、机器常开且显卡可用，单位时间能服务多少请求是核心指标

判断口径

问自己「使用者是谁」和「调用是持续的还是偶发的」，比问「哪个快」有用得多

常见误判

在个人机器上跑通 Ollama 就以为它能扛团队使用，这是最多人踩的坑

什么情况下这套定位判断不适用？如果你的目标只是本地试一个新模型、验证它中文水平行不行，那硬上 vLLM 是把时间花在环境上而不是模型上，得不偿失。反过来，如果你已经有明确的服务化需求、有固定的调用方，那继续用 Ollama 就是在给自己埋延迟隐患。

性能差在哪：不是「快慢」，是并发下的曲线

网上说 vLLM 比 Ollama 快很多，但很多人实际测下来发现单请求也没差到哪去，于是开始怀疑结论。分歧出在测法上：两者真正的差距不在单请求那条线上，而在同时来若干请求时的表现。一个是把请求排进队列挨个处理，一个是把多个请求拼进同一批算，并发一上来，曲线就分叉了。

• 单请求首字延迟：两者往往不像传说中差距那么大，尤其在小模型、少并发时，体感接近
• 高并发总吞吐：vLLM 的连续批处理会把长短不一的请求挤在一起算，这是它提升吞吐的核心机制，Ollama 在这块没有对应能力
• 显存利用效率：vLLM 对 KV 缓存做了分页式管理，减少碎片浪费；Ollama 更偏向把整块资源留给自己用
• 延迟抖动：Ollama 在并发变高时通常先出现排队和抖动，vLLM 的抖动曲线相对平缓，但代价是配置复杂
• 资源兜底：显存不够时 Ollama 能退回 CPU 或换量化档继续跑，vLLM 一般不给你这种退路，显存不够就是起不来

要确认具体数字，别凭印象，也别信别人的截图。先到 /tools/speed-test 量出你自己机器上的延迟和吞吐基线，再到 /models/deploy 按目标模型和量化档算一遍并发与显存需求。用你机器上的数字说话，比任何横向测评都准。

硬件和部署形态：谁对老卡和杂牌卡更友好

选型先过硬件这关，过了才有资格谈性能。Ollama 对消费级单卡、显存不大的机器友好度更高，它会在资源紧张时主动降级。vLLM 则更依赖一块有足够显存、且被其支持的卡，多卡并行、长上下文、大并发这些能力，都要在硬件到位的前提下才谈得上。

还有一类容易被忽略的情况：国产卡或非主流加速卡。不要默认两边都能跑，更不要默认「装得上就能跑得动」。先去 /compute/gpus 核对规格，再到 /compute/domestic 看哪些卡是真能租到、适配分支走到哪一步。如果卡本身不在适配列表里，讨论两者性能就没有意义，先解决能不能跑起来的问题。

真要上 vLLM：起服务前该定下来的四件事

决定用 vLLM 之后，别急着敲启动命令，先按顺序把四件事定下来。顺序错了，后面会反复返工。

1. 定模型与量化档先确定要用哪个权重的哪种量化格式，再决定显存预算。反过来先买卡再找模型，很容易发现想要的权重没有对应量化格式，只能重新挑。
2. 定并发目标估出峰值同时请求数和平均输出长度，这两个数决定了显存占用比例、最大批大小这类参数该往哪个方向调。没有这两个数，参数只能靠瞎试。
3. 定暴露方式想清楚是只给内网几个人用，还是要挂到公网。鉴权、限流、日志这三样早想早做，服务上线后再补，改动面会大很多。
4. 定排查顺序起不来时按「权重格式是否匹配 → 显存是否够 → 端口和网络是否通」的顺序查，别一上来就怀疑框架。具体的报错处理路径可以到站内的部署排错内容里对照。

这个流程不适用于临时验证场景。如果你只是想看某个模型在 vLLM 下能不能跑，那就用最小配置跑通即可，不要在这时候把并发、鉴权、日志一起搭起来，容易把问题混在一起。

真要用 Ollama：别把它当生产服务器用

Ollama 用起来舒服，但舒服的代价是天性上不为多用户服务设计。用它之前，先把下面几条做到位，能避免大部分「用着用着就卡」的抱怨。

• 提前把模型拉好放在本地缓存里，避免第一次调用卡在下载上，尤其是演示场景
• 给机器留出余量，它默认倾向于尽量占用显存，和别的程序抢资源时两边都会变慢
• 如果一定要对外提供，前面加一层转发做超时和重试，不要让业务代码直连
• 接受一个事实：并发上来后延迟会变差，这是设计取向决定的，不是配置没调好
• 适用范围是内部小工具、演示、个人助手这类场景；一旦出现「好几个人同时用就卡」的反馈，就是该评估迁移的时候

Ollama 能帮你把模型跑起来，但「跑起来」和「扛得住」是两件不同的事。

什么情况下上面这些约束可以先不管？纯本地个人使用、不对外提供服务、也不接自动化流程，那怎么顺手怎么来。一旦调用方从「我」变成「我们」，约束就回来了。

从 Ollama 换到 vLLM：什么时候换、怎么换不翻车

迁移这件事，最怕的是没想清楚就动手。先确认触发信号真的出现了，再确认迁移前提具备，最后按步骤切，才不容易翻车。

有一条经验值得单独说：不要为了性能换框架而顺手换模型。两件事分开做，先换框架、确认输出和原来一致，再考虑换模型。同时改两样，出问题时你分不清是哪个引起的，排查成本会翻倍。

一张选型对照：按场景对号入座

把前面几节的判断收成一张对照表，按你的实际情况对号入座即可。

这张表不是绝对的。如果你的并发其实很低，只是心理上觉得「上生产就该用 vLLM」，那上 vLLM 之后要付出的运维成本可能不划算。反过来，如果团队人数还会继续涨，早点评估迁移比临时救火省事。

容易被忽略的两件事：许可证和长期运维

技术选型讨论得热火朝天，最后卡在许可证或者没人值守上，这种情况并不少见。这两件事最好在动手前就想清楚。

• 框架本身的开源许可证和模型权重的许可证是两回事，商用前要分别确认，别只看其中一个
• 模型权重侧的商用边界，可以到站内关于开源权重许可证的内容里对照，别只凭「反正是开源的」下结论
• 运维成本要算进去：vLLM 需要有人管版本升级、显存分配、参数调整；Ollama 省心但天花板低
• 选之前先想清楚谁在半夜接报警，没人接的话，选再好的框架也扛不住线上问题
• 升级策略也要提前定，框架和权重版本捆绑升级时，先在小流量环境验证再推全量

这两件事什么情况下可以往后放？纯学习用途、不对外提供服务、也不涉及商用，那许可证和运维的权重可以降低。但只要涉及对外服务或者商业使用，就别省这一步。