团队要把一个开源模型跑起来，往往先撞上这个问题：同事说 Ollama 一行命令就能跑，运维说 vLLM 吞吐高，又有人提 SGLang 做结构化输出更快。三个都不是同类东西，硬比参数没意义。这篇按「你要解决什么」来拆：单机试用、线上高并发、复杂提示复用，各自对应哪一类框架，以及选错之后多久会撞墙。
团队要把一个开源模型跑起来，往往先撞上这个问题：同事说 Ollama 一行命令就能跑，运维说 vLLM 吞吐高，又有人提 SGLang 做结构化输出更快。三个都不是同类东西，硬比参数没意义，因为它们解决的其实不是同一个问题。
这篇按「你要解决什么」来拆：单机试用、线上高并发、复杂提示复用，各自对应哪一类框架，以及选错之后大概多久会撞墙。判断顺序比结论重要，所以下面每一节都尽量给出可执行的检查动作，而不是一句谁更好。
先把三者的定位摆正：它们不是同一条赛道
把三个名字放在一张表里比参数，是最容易做错的起手式。Ollama 的强项是把模型跑起来这件事本身变得简单，自带模型拉取、量化权重管理和命令行体验，服务端能力是顺带的；vLLM 强项是把模型跑成服务，连续批处理、显存分页管理和 OpenAI 兼容接口都是为线上流量准备的；SGLang 强项是把复杂请求跑快，前缀缓存、结构化输出约束、多轮与工具调用调度是它偏应用层的那一面。先认赛道，再谈选型。
| 框架 | 它主要解决什么 | 典型使用姿势 | 不擅长什么 |
|---|---|---|---|
| Ollama | 把模型在本机跑起来 | 本地命令行/桌面调用、离线小批量 | 高并发下的调度与吞吐 |
| vLLM | 把模型跑成稳定在线服务 | 多路并发请求、OpenAI 兼容接口 | 开箱即用的轻量体验 |
| SGLang | 把特定形态的请求压快 | 长系统提示词复用、JSON 约束输出、多轮 Agent | 不需要这些优化的普通场景 |
判断口径可以压缩成一句话：先问团队要的是能跑、能扛量，还是能压住某种特定请求形态。答案不同，选的就不是同一个东西，也就谈不上谁替代谁。
选型要看五个维度，不是看谁名气大
名气大不等于适配你的场景。真正会决定结果的，是下面五件事，建议逐条打分或至少逐条写清现状，再往下看结论。
- 并发规模：单人或小团队轮流用，还是几十上百路同时打进来，直接决定要不要批处理调度
- 请求形态：短问答、长上下文、JSON 约束输出、多轮 Agent，各自吃不同的优化点
- 硬件条件：单张消费卡、多卡张量并行、国产加速卡，支持度差别很大，先去 /compute/gpus 对一遍自己的卡
- 运维成本：是否接受容器与依赖编译、要不要做模型权重版本管理、出问题谁来查
- 迁移成本：接口是否 OpenAI 兼容、换框架要不要改客户端代码，这项常在选型时被低估
其中硬件这一项最容易翻车。很多人是先看别人跑得欢，再回头发现自己手里那张卡压根不在适配列表里，或者多卡通信没配好，进程起不来。这一类问题在纸面比对里看不出来，必须落到自己的机器上验证。
按场景对号入座：三种典型团队分别怎么选
举几个通用场景，不对应具体公司。第一种是个人或 5 人以内小团队做验证、内部工具、离线批处理，优先 Ollama，把时间花在业务上比花在框架上调参划算。第二种是已经有稳定流量、要压成本和延迟的线上服务，优先 vLLM，批处理与显存利用率是它存在的理由。第三种是请求里大量重复的系统提示词、固定 JSON 结构、多轮工具调用，值得单独测一遍 SGLang，但要在自己的真实流量上测，别信别人的转述。
还有一种边界情况：请求总量很低，一天就没几次调用。这种场景下优化吞吐几乎没有意义，优化的是「我今天能不能少踩一个依赖编译的坑」。把需求写清楚再选，比先选完再补理由靠谱。
一张对照表加三步落地动作
前面都是判断，这一节是可执行动作。建议按顺序做三步，并在最后留一个退出方案。
- 捞真实样本把最近一周的真实请求样本导出来，统计平均输入长度、平均输出长度、并发峰值、是否存在 JSON 约束。这是唯一可靠的选型依据，凭感觉选的都会返工。
- 同条件压一轮用同一份权重、同一张卡、同一批样本，把候选框架各压一轮，重点看首 token 延迟与总吞吐，而不是看单次问答快不快。单次问答快慢几乎没有参考价值。
- 留退出方案客户端统一走 OpenAI 兼容接口，哪个框架不合适就换，不至于重写一遍集成代码。这一步在选型阶段加，成本最低。
落地前还有一份自查清单，逐条确认能省掉大量返工：权重格式能不能直接被加载、显存够不够放 KV 缓存、量化档位会不会掉质量、多卡时通信有没有配好。数字类结论（各家吞吐、显存占用）会随版本和硬件变化，去 /models/deploy 用当前测算口径核一遍，别照搬别人截图里的数。
什么时候三个都不该选
有些场景压根不需要在这三者之间纠结。第一，只是偶尔调一次模型、没有数据合规要求，直接走官方 API 或聚合平台，运维成本接近零，参考 /official-api 的当前价格页按当时的数字核算即可。第二，要的是微调而不是推理，这三个框架都不是干这个的，去看看 /stacks/fine-tuning 里的服务商目录。第三，硬件是国产加速卡或特殊架构，先确认框架的适配分支是否存在，社区支持度差异很大，不确认就上容易卡在编译阶段。
选型不是选最强的那个，是选自己团队能一直维护下去的那个。下一步拿不准自己这套硬件和流量适合哪一类，可以先用站内的速度测试工具跑一轮基线，再回到价格与模型页核对当前口径，把判断建立在实测数据上，而不是别人的一句推荐。→
常见问题
Ollama 能直接换成 vLLM 吗，客户端要改多少？
如果客户端本来就走 OpenAI 兼容的接口格式，改动通常集中在地址、模型名和鉴权三处，业务代码基本不用动。要注意的是对模型名称的解析方式、流式返回的字段细节、以及采样参数的默认值不同，这些在切换后要重新对齐一遍，建议先拿一条固定请求做回归。
SGLang 是不是一定比 vLLM 快？
没有这个结论。SGLang 的优势集中在特定请求形态上，比如大量共享前缀、强约束的结构化输出、多轮工具调用，这些场景里它可能明显占优。但如果是请求彼此独立、格式自由的普通问答，两者差距经常很小甚至反超。判断依据只能是拿自己的流量压测，而不是看通用描述。
选错框架的代价有多大，什么时候该换？
如果接入层保持 OpenAI 兼容，换框架主要成本在重新部署和压测，一两天能完成，不用慌。真正贵的是已经围绕某个框架写了私有扩展、或者把权重格式绑死了。判断该不该换的信号是：并发一上来延迟就崩、显存利用率长期偏低、或者每次改提示词都要重启服务。
