vllm和ollama哪个好

很多人卡在这一步：模型已经能在本机跑起来了，但一上多人用就慢、一换框架就报错，于是开始纠结到底该用哪个推理框架。这篇不给标准答案，给的是判断路径——先量清自己的并发和延迟底线，再对照三家的定位差异逐条排除，最后给一份可照做的选型与迁移检查清单。

模型已经能在本机跑起来了，但一上多人用就慢，一换框架就报错，于是开始纠结到底该用哪个推理框架。这个问题的难点不在技术本身，而在你还没量清自己的需求就去看别人的对比结论。先量并发和延迟底线，再对照三家定位逐条排除，比直接抄作业靠谱得多。

这篇不给标准答案，给的是判断路径。三个框架不是同一类东西，硬比谁快谁慢没有意义。你要搞清楚的是：这台机器同时有几个人用、团队里有没有人愿意调参、愿不愿意为换框架承担迁移成本。这三个问题的答案基本就能圈定方向。

先分清三者不是同一类东西

Ollama 的定位是装完就能用的本地运行器，模型下载、量化档位、服务进程全帮你包好了。vLLM 和 SGLang 是面向服务的推理引擎，默认假设你有显卡、要开 HTTP 服务、要撑并发。前者是给你省事的，后者是给你省算力的，方向不一样。

Ollama

本地运行器，下载即用，适合个人或小规模自用，可调参数少

vLLM

面向服务的推理引擎，需要自己配参数，适合要开接口撑并发的场景

SGLang

偏调度与运行时优化的推理引擎，在前缀重复率高的场景有针对性优势

判断的第一问不是哪个快，而是这台机器同时有几个人问。一个人自用，三者都能满足；超过几个并发请求同时在线，Ollama 的排队行为就会开始变明显。三家的取舍轴是省心和单位算力能扛多少并发，这两个方向基本对冲，不存在都占的选项。

吞吐这件事，别听结论自己量

吞吐不是单一数字，是并发数乘以单请求生成速度的组合曲线。同一张卡在不同并发下结论可能反过来，所以任何 A 比 B 快的说法都要带上并发前提。你不说清楚几个并发就开始比，等于什么都没比。

1. 固定变量先确定同一个模型、同一个量化档位、同一段提示词，三样都不能变，变了对比就不成立
2. 跑单并发记录首字延迟和整体完成时间，这是你的基线，不知道基线就没法判断换了框架有没有变好
3. 跑目标并发用你实际会遇到的并发数再跑一遍，看排队行为和延迟变化，这一步才能暴露真实瓶颈
4. 对照公开数据到 接口测速（/tools/speed-test） 量出基线，再到 AI 测评榜单（/benchmarks） 对照公开口径，注意对齐并发数与序列长度

不适用的场景很明确：单次推理、离线跑批、没有 API 需求的人，三家在体感上几乎没区别。这时候你该关心的是能不能跑起来、换模型方不方便，而不是吞吐数字。把精力花在错的维度上，是本地部署最常见的浪费。

易用性真正的分界线在哪

Ollama 的优势在于省去自己处理权重格式、服务启动参数与显存卸载策略，代价是可调的旋钮少，出问题时能看到的信息也少。vLLM 和 SGLang 需要你自己决定张量并行度、显存占用比例、最大序列长度等参数，换来的是可调空间和更接近生产环境的形态。

一个判断标准：如果团队里没人愿意读文档调参，也没有人负责服务稳定性，那省心优先；如果有人要写调度、要做监控，那可控性优先。到 基础设施术语速查（/ai-dict/category/infra） 先把这些参数名词认全，再决定要不要接。连参数名字都看不懂就上手服务框架，后面调优会很痛苦。

• 有没有人愿意在出问题时读框架文档、翻日志、调参数
• 服务挂了会不会影响别人，还是只有自己用不了
• 未来半年内并发会不会明显增长，增长后有没有加卡计划
• 团队里有没有人写过监控或调度相关的东西
• 换框架时上游应用要改多少处调用代码

按场景抄作业：四类常见需求怎么选

与其纠结哪个好，不如先对号入座。下面四类场景覆盖了大多数本地部署需求，先找到自己那一类，再往下看具体动作。找不到对应类别的，说明你的需求还不够明确，先回去量并发。

对外提供接口这类场景里，vLLM 与 SGLang 之间按你的模型类型和团队熟悉度选，别只看别人的对比表。有长上下文、结构化输出或多轮前缀复用需求的，重点对比两者在缓存复用和调度策略上的差异，这类场景差距往往比通用吞吐更明显。内部工具类需求，先量真实并发峰值，多数情况省心路线加一张卡够用。

SGLang 该怎么摆进这个对比里

SGLang 的关注点是请求调度与运行时优化，尤其适合前缀重复率高、多轮对话共享长提示词的场景。这也是它和 vLLM 对比时最常被提起的点。如果你的请求彼此独立、提示词完全不重复，那它相对 vLLM 的优势会被压缩，此时按团队已有技术栈选更实际。

不要只看 sglang vs vllm 的对比文章下结论。到 开源模型比价（/inference） 和 AI 模型库（/models） 核对你实际要跑的那类模型是否在支持列表里，支持范围比性能数字更致命。跑不起来的框架性能再高也等于零。

先算显存和并发，再选框架

顺序别搞反：先按参数量和量化档位算出模型要吃多少显存，再看剩余显存能放多少并发缓存，最后才决定用哪个框架。显存刚好卡在临界点时，换框架救不了你，降量化档位或加卡才是解，别把硬件问题当成软件选型问题。

• 按参数量和量化档位估算模型权重占用，这是硬性开销
• 扣除权重后看剩余显存能放多少 KV 缓存，决定并发上限
• 并发上限低于实际需求时，先降量化或加卡，别急着换框架
• 到 部署测算（/models/deploy） 做一遍显存与并发估算
• 到 几张卡够用：按模型算一遍（/compute/sizing） 看多卡方案
• 到 加速卡规格库（/compute/gpus） 对照手上卡的实际规格

不舒服的情况：如果你的卡是国产加速卡或较老的消费卡，先确认框架分支支持范围，支持度往往比性能更影响能不能跑起来。有些框架在特定卡上需要额外编译或根本不支持，这种坑提前查比事后返工划算。到 加速卡规格库（/compute/gpus） 对照一下你的卡在不在列。

换框架前先过这份检查清单

决定要换之后，别直接在生产环境动手。下面这些问题不提前确认，迁移当天大概率卡在某个环节。按顺序过一遍，能省掉大部分返工。

1. 权重格式确认模型权重能不能直接加载，还是需要转换，转换会不会带来精度损失，先在小环境验一遍
2. 参数映射对照原来的调用参数在新框架里叫什么名字，有没有行为差异，温度、最大长度、停止词逐个对
3. 接口协议检查是否兼容 OpenAI 风格，不兼容的话上游应用要改多少处，到 换模型前先比一比率和额度（/ai-nav/category/ai-api） 看同行一般怎么处理
4. 许可证复核换框架不改变模型本身的授权条款，商用边界要重新看一遍，到 安全与合规（/safety） 过一遍
5. 回退方案准备保留旧配置多久、怎么在一分钟内切回去，没有回退方案的迁移不要选在生产时段做

这份清单里最容易漏的是回退方案。很多人换框架时抱着一次成功的心态，出事才发现旧配置已经删了。留一条能立刻切回去的路，比迁移本身更重要。

最常见的四个判断错误

最后说几个反复出现的错误，对号入座看看自己有没有中。这些问题本质都是顺序搞反：先看结论、先买硬件、先追性能，而不是先量需求。

• 拿别人单并发测出的速度当自己的预期，忽略自己的并发峰值
• 为了跑分领先一截就换框架，忽略迁移成本和后续维护人力
• 把能跑起来等同于能提供服务，缺少超时、排队、失败重试的处理
• 先买卡再定框架，结果发现想用的框架对这张卡支持一般，顺序应该反过来

选框架的顺序是：先量并发和显存，再定省心还是可控，最后才在具体框架之间挑。