ollama 和 vllm 部署同一个模型差多少

你可能已经用 ollama 在本地把模型跑起来了，单聊几句都挺顺；可一旦要接进业务、要顶住几个人同时提问，就发现响应开始排队、显存吃紧。这时听说 vllm 吞吐高，但换过去又要改部署方式、改调用代码。这篇不站队，只讲同一个模型交给这两个框架之后，到底在哪些环节产生差别、差别怎么量、什么情况下换了也不划算。

你可能已经用 ollama 在本地把模型跑起来了，单聊几句都挺顺；可一旦要接进业务、要顶住几个人同时提问，就发现响应开始排队、显存吃紧。这时听说 vllm 吞吐高，但换过去又要改部署方式、改调用代码。这篇不站队，只讲同一个模型交给这两个框架之后，到底在哪些环节产生差别、差别怎么量、什么情况下换了也不划算。

先把预期摆正：两者不是「同一件事的快慢版本」，而是两个出发点不同的服务形态。ollama 更像给单机开发者准备的随身工具，装完就能用；vllm 更像给线上服务准备的推理引擎，配置项多、要调的东西也多。同一个权重文件丢进去，加载方式、调度策略、显存管理全都不一样，所以「差多少」这个问题，得拆成好几个维度分别看，不能只问一句快不快。

同一个模型，为什么两个框架跑出来不像一个东西

先分清三个层次：第一层是权重文件本身，这部分完全相同，你从同一个来源拿到的文件是一样的；第二层是加载权重的方式，包括用什么精度、怎么切分、放哪张卡；第三层是请求调度与批处理策略。差别主要出在后两层，而不是模型本身。把这三层分开，后面看到的所有差异都能对上号。

权重层

同一份文件，这一层没有任何差别，别在这里找原因

加载层

精度、量化、张量并行切分方式不同，直接决定显存占用与能不能起来

调度层

请求怎么排队、怎么合并成批、显存块怎么复用，这是吞吐差距的主战场

推论也很直接：如果你只做单人单轮对话，两边体感接近，甚至可能觉得 ollama 更省心；但只要并发上来，调度层的差距就会被放大成几倍甚至更多的等待时间差。所以千万别用「我自己试聊了几句」的结论去判断线上表现，那个场景恰好落在两者差距最小的区间里。

吞吐、首字延迟、单请求速度：三个别混着看

这三个指标经常被混成一句「哪个快」，但它们衡量的东西完全不同，指向的结论也可能相反。跑批任务只关心单位时间总产出，交互产品只关心用户等待的那一下，两者对框架的偏好不一定一致。

• 交互式场景：优先看首字延迟和尾延迟，用户等的是开头那一下，不是总量

• 离线批处理：优先看总吞吐，单条慢一点无所谓，跑完就行

• 混合场景：两个都要量，但要知道瓶颈在哪一项，别拿总吞吐去解释用户卡顿

• 量之前先固定输入输出长度，长度一变所有指标都不可比

显存怎么分、并发怎么排：这是差距最实的地方

显存策略是最容易被误读的一块。有一类实现倾向于把可用显存尽量占住做缓存，跑起来后你看常驻占用会觉得很吓人；另一类更保守，占用看着低，但并发一高就顶不住。这两种数字不能直接横向类比，要比就比「同样的并发下谁先出问题」。

1. 确定模型与量化档位先把要部署的模型和量化格式定死，不同档位显存需求差别很大，到站内 /models/deploy 按你的模型做一次测算，拿到基准显存需求。
2. 对照卡数与并发拿基准需求去到 /compute/sizing 对照卡数与可支撑并发，估算你这张卡最多能同时服务几个请求。
3. 压测验证按估算值的七八成设并发上限，实际压一轮，看是否出现排队、超时或显存溢出，再回调。

并发能力还受显存缓存块管理方式影响。长上下文请求会明显挤压可同时服务的请求数，因为每个请求占的缓存空间更大。如果你的业务输入普遍偏长，别用短提示词测出来的并发数直接上线，那个数字会明显偏乐观。具体到某个模型的长度上限，到站内模型条目里核对当时的参数。

能不能加载、加得上：适配层面的差别

这一层最容易被忽略，但实际踩坑最多。两个框架对模型架构、权重格式、量化格式的支持范围并不一样，新模型发布后通常有先后顺序，有的框架能直接加载，有的要先转格式或者打补丁。

• 架构是否被支持：模型是不是用了新的注意力结构或者专家混合结构，决定了框架能不能认

• 权重格式是否匹配：同一份权重可能有多种保存格式，格式不对会直接加载报错

• 量化类型是否识别：不同量化方案需要框架内有对应算子，不识别就得换量化档

• 加载失败时按这三步顺序排查，先确认架构，再看格式，最后看量化，别一上来就换框架

多模态、超长上下文、专家混合这类结构，适配成熟度差异会被放大，同一个模型在一边能跑通、在另一边可能得等适配或者降级使用。想知道某个模型当时在两方面分别是什么状态，去站内 /models 看模型条目的支持情况，别只看名字对不对。

换到不同硬件，结论可能整个反过来

很多人是在自己的卡上测出结论，然后直接套到服务器上，这中间可能差出另一个世界。消费级单卡、数据中心卡、国产加速卡的支持程度不一样，某些框架在特定卡上还需要专用分支或者特定驱动版本。

还有一个反直觉的点：同一个框架在不同卡上的实际表现差异，可能大于两个框架在同一张卡上的差异。所以换卡和换框架这两件事最好别同时做，否则你根本不知道效果变化来自哪一项。先到 /compute/gpus 核对卡的规格与显存，再去 /compute/platforms 和 /compute/domestic 确认可租渠道，把硬件这一层先固定住。

自己动手量一遍：一份可照做的测试步骤

1. 定基线固定模型、量化档位、提示词长度与输出长度，两边用完全相同的参数。把配置文件存一份，标注清楚每一项设置。
2. 分档压测从单人开始，逐档加并发，每一档记录吞吐、首字延迟、尾延迟和显存占用。并发档次之间别跳太大，否则找不出拐点在哪。
3. 看稳定期连续跑一段时间，观察是否有显存持续增长、请求超时或服务重启。短时间跑得好看不代表长时间稳定。
4. 留证据把命令、配置、日志和结果表统一存档，后续换版本或者换卡可以复现对比。接口层面的延迟基线可以先到 /tools/speed-test 量一遍。

量的时候有两个常见错误：一是只测一轮就下结论，缓存还没热起来；二是两边的超时设置不一致，慢的那边被提前掐断，结果反而显得更快。把这两点避开，数据才有参考价值。测出来的具体数字不用记在文章里，回站内对照当时的页面即可。

什么情况下别折腾换框架

换框架不是免费的，调试成本、迁移成本和后续运维成本都要算进去。下面这几种情况，换过去大概率是白折腾。

• 只是个人本地问答、偶尔跑一次脚本：收益可能抵不上调试时间

• 瓶颈不在推理框架，而在磁盘加载、网络回传或前端串行调用：换框架也救不了

• 团队已有稳定调用链路：迁移前先评估调用协议、鉴权、监控和回退方案，别只对比一个吞吐数字

• 没人能长期维护新框架：部署方式一变，后续排障的人也得跟着换

判断标准可以简化成三项：并发人数、任务的时延敏感度、有没有运维能力。三项里两项不满足，就别迁。这条标准也有不适用的情况——如果你的业务本身就是给别人提供 API 服务，那吞吐和稳定性优先级会被抬得很高，这时候哪怕运维吃力，也值得认真评估一次。

真要迁移，按这份清单走

1. 清点调用方把所有走本地接口的脚本、应用、知识库工具列出来，逐项确认协议兼容性，别漏掉没人记得的定时任务。
2. 准备回退保留旧服务的启动方式与端口，新服务用另一个端口先并行跑，验证通过再切流量。
3. 对齐参数上下文长度上限、并发上限、超时时间逐项对照设置，默认值不一致会让压测结论失真。
4. 灰度观察先切一部分流量或一部分用户，看错误率与延迟分布再决定是否全量。相关工具与换算放在 /tools。

整份清单的核心就一句话：先并行、再切量、留退路。任何一步跳过，出问题的时候都会手忙脚乱。迁移过程中如果发现两边在某个参数上语义不一致，宁可按更保守的一侧设置，也不要赌默认值。