很多人本地跑模型时卡在同一个岔路口：先用 Ollama 起了个服务，用得挺顺，等到要给团队用、要接进业务系统时，才发现并发一上来就排队。也有人一上手就装 vLLM，结果连模型权重怎么放、显卡够不够都没想清楚，折腾两天服务还没起来。这篇不讲谁更先进，只给一套按自己场景判断的顺序，以及选定后具体要动哪些配置。
很多人本地跑模型时卡在同一个岔路口：先用 Ollama 起了个服务，用得挺顺，等到要给团队用、要接进业务系统时，才发现并发一上来就排队。也有人一上手就装 vLLM，结果连模型权重怎么放、显卡够不够都没想清楚，折腾两天服务还没起来。
这篇不讲谁更先进，只给一套按自己场景判断的顺序，以及选定后具体要动哪些配置。判断起点不是「哪个框架强」，而是「谁在用、几个人同时用、有没有人愿意维护」。把这三件事想清楚，选型基本就定了。
先搞清两者到底在哪一层不一样
最容易踩的坑是把两者当成同一层的东西比。Ollama 更像「装好就能用」的一体化运行时，自带模型管理、拉取、量化权重和 OpenAI 兼容接口；vLLM 是纯推理引擎，只专注吞吐与显存利用。一个是工具箱加运行时，一个是引擎，比较的前提是先看你的使用形态。
- Ollama
- 一体化运行时：模型管理、量化权重、接口一起给你，适合单机、单人、少量并发
- vLLM
- 纯推理引擎：模型权重、启动方式、并发调度都要自己配，换来的是高并发下的效率
- 关键差别
- 前者省事，后者省资源；省的事不同，不能直接比谁快
按使用场景先分一次岔
先别急着看参数，按使用场景分一次岔，能省掉大半纠结。单人本地问答、写文档、试提示词，Ollama 的学习成本优势明显，装完基本不用管；要接进业务系统、有稳定的并发和延迟要求，就直接按 vLLM 的路线规划，别等上线后再迁。
- 单人本地问答、写文档、试提示词：Ollama 装完即用，几乎不用维护
- 三五人小团队内部共用、偶发并发：先跑 Ollama，同时用压测脚本量出排队拐点再决定要不要换
- 要接进业务系统、有稳定并发与延迟要求：直接按 vLLM 规划，迁移成本前置
- 离线批处理、不追求交互延迟：选型重点从延迟转向批处理效率，两边都要重新算账
判断不适用的情况：如果任务本身是离线批处理、不追求交互延迟，选型重点会从延迟转向批处理效率，这时候单看「谁响应快」会得出错误结论。
显存与并发：先算账再选框架
先确定模型参数量、量化档位和上下文长度，再算权重占用加 KV Cache 占用，这两项决定你能开多少并发。把「显存够不够」和「并发撑不撑得住」分成两个问题看：前者决定能不能跑，后者决定要不要换框架。混在一起想，就会一直纠结。
| 要算的量 | 怎么估 | 影响什么 |
|---|---|---|
| 模型权重占用 | 参数量乘以量化后每参数字节数 | 决定能不能装下、能装几个实例 |
| KV Cache 占用 | 并发数乘以上下文长度乘以每 token 缓存 | 决定并发开多大、上下文能开多长 |
| 剩余显存 | 总显存减去上述两项 | 决定还有多少空间给批处理和临时缓冲 |
vLLM 靠显存分页和连续批处理把显存利用率做上去，同样的卡并发上来后每 token 成本更低；Ollama 单请求响应不一定差，但堆并发时容易顶到上限。卡本来就只够跑单实例小模型时，谈吞吐调度收益有限，先解决显存更实际。
运维方式与接口对接
运维成本是最容易被低估的一项。Ollama 一条命令拉起服务，模型路径、环境变量、端口都能快速改，适合一个人维护；vLLM 通常走容器或独立进程部署，启动参数、张量并行、服务化配置项更多，出问题排查链路更长，需要有人能看日志和调参。
- 谁维护：一个人顺手维护选 Ollama，有人专职看日志和调参再考虑 vLLM
- 接口能力：确认流式输出、工具调用、多模态输入这些能力业务是否真的用得上
- 下游兼容：如果已有 OpenAI 兼容调用，两边都能接，但要逐字段验证返回结构
- 回退路径：切之前留好旧服务，出问题能一键切回去
接口层面最容易出问题的不是连不上，而是连上了但行为不一致。超时时间、流式分块方式、错误码结构，这些下游代码可能已经写死依赖。判断不适用的情况：团队里没人愿意碰命令行和日志时，硬上 vLLM 的维护成本会吃掉吞吐收益。
性能怎么看：别只看别人的数字
吞吐和首 token 延迟是两回事，交互式场景看后者，批量场景看前者。不同机器、不同量化档位、不同上下文长度下的表现没法直接横向比，别人的数字只能当量级参考，不能当结论。
- 固定变量同一模型、同一量化档位、同一提示词长度，其余环境尽量不动
- 分档压测分别记下并发 1、并发 4、并发 8 时的首 token 延迟和每秒 token 数
- 找拐点观察延迟从哪一档开始明显上升，那个点就是你当前的并发上限
- 留基线把数据存下来，每次换配置或换框架再测一遍做对照
想先量出延迟基线，可以到 接口测速（/tools/speed-test） 跑一轮；模型与量化档位的对照关系，去 AI 模型库（/models） 核对当时的参数说明，具体数字以站内页面为准。
模型支持范围与权重格式
选之前先确认你要跑的那几个模型在两个框架里各自有没有现成支持，别先选框架再找模型。Ollama 依赖自己的模型注册表与格式，冷门模型、新出的架构不一定当天就有，需要自己转换或导入；vLLM 更贴近主流开源权重发布格式，新模型通常先在这类引擎里跑通，但权重加载和版本适配也会踩坑。
- 先查再选
- 拿你实际要跑的模型列表，逐个去两边文档确认支持情况
- 量化档位
- 同一模型不同量化档位占用差别很大，框架支持情况也可能不同
- 不适用情况
- 只用少数几个热门开源模型时，两边支持差别不大，这条不该成为决定因素
从 Ollama 切到 vLLM 的迁移清单
迁移不是把服务换一个端口那么简单，最容易出问题的是那些「看起来一样但实际不一样」的细节。按下面顺序走，能少返工。
- 确认权重与量化确认模型有对应权重格式，量化档位与目标显存匹配，不对就先换档位再谈迁移
- 测试环境起服务单独起一个环境，逐个验证接口字段是否被下游依赖，重点是流式、超时、返回结构
- 对齐提示词与上下文把模板、停止词、上下文长度上限对齐，这些差异最容易导致切换后输出变样
- 压测对比并保留回退和旧服务在同一批请求上对比，确认稳定性再切正式流量，切换期间保留旧路径
部署前的资源和显存测算可以用 部署测算（/models/deploy），不同开源模型在各类部署方式下的成本对照可以看 开源模型比价（/inference），具体数字以页面当时显示为准。
一张对照表收尾
| 你的情况 | 建议起点 | 理由 |
|---|---|---|
| 单人自用，模型在注册表里 | Ollama | 装完即用，维护成本接近零 |
| 小团队内部共用，并发不高 | Ollama，同时留切换方案 | 省事优先，压测出拐点再决定 |
| 稳定对外服务，有并发指标 | vLLM | 吞吐和显存利用率优先，接受运维投入 |
| 开发调试加生产两条链路 | 日常 Ollama，生产 vLLM | 两套并行是很多团队的实际做法 |
选型不是选哪个更强，而是选哪个和你的使用形态、维护能力匹配。下一步把你实际要跑的模型和并发量列出来，去站内对照支持情况、部署测算和实测延迟，再决定要不要切，比凭印象选省事得多。→
常见问题
Ollama 和 vLLM 能不能一起用？
可以，而且是常见做法。开发调试、个人试用走 Ollama，省去反复改启动参数；对外服务和对内压测走 vLLM。两边统一用 OpenAI 兼容接口，下游代码基本不用改，只需要把地址和模型名换掉。注意保持模型和量化档位一致，否则同一提示词在两边输出会有差别。
我只有一张消费级显卡，值得上 vLLM 吗？
看并发需求。如果只有你一个人用，Ollama 就够了，vLLM 的调度优势在低并发下体现不出来。如果是有几个同事共用、经常排队，先量出排队发生在几个人同时用的时候，再拿 vLLM 做一次对比压测。单卡跑大模型本身的显存上限是共同瓶颈，换框架解决不了显存不够的问题。
换成 vLLM 之后输出变差了，是什么原因？
先排查三处：量化档位是不是变了、提示词模板和停止词有没有对齐、上下文长度上限是不是被截断。同一份权重在不同推理引擎下的默认采样参数和模板处理方式不同，输出有差异很正常。建议固定一组测试提示词，两边各跑一遍对比，再逐项调整参数。
怎么判断该不该从 Ollama 迁走？
出现下面任意一条就值得评估：多人同时使用时有明显等待、业务对首 token 延迟有硬要求、需要按并发扩容而不是按机器扩容、需要更细的显存和批处理控制。反过来，如果只是自己用、偶尔慢一点可以接受，迁移带来的运维成本往往不值。
新出的开源模型在哪个框架上先能跑？
通常推理引擎路线会更快支持新的权重格式，Ollama 侧要等注册表或社区整理好导入方式。具体某个模型当前的支持情况，去 AI 模型库（/models） 看模型条目和部署说明，再到 追踪前沿论文与热门模型动态（/papers） 确认发布时间，别凭印象判断。
