你手上有一台或多台卡，准备把模型起成在线服务，同事说 vLLM 稳、朋友说 SGLang 快，两边给的数字还对不上。问题多半不在框架本身，而在模型结构、并发形态和压测口径不同。这篇给一套可落地的对比思路：先对齐测什么，再决定跑哪个，最后怎么验证不翻车。
你手上有一台或多台卡，准备把模型起成在线服务。同事说 vLLM 稳，朋友说 SGLang 快，两边给的数字还对不上。问题多半不在框架本身，而在模型结构、并发形态和压测口径不同，几个变量一错位，结论就完全反过来。
这篇不给结论，只给一套能落地的对比思路：先说清差异从哪来，再讲该测什么、怎么测，最后按场景判断选哪个。看完你应该能自己跑出一份站得住脚的对比，而不是转发别人的跑分截图。
先搞清两家的差异从哪来
两家框架的底层差别主要在调度与缓存思路：一侧偏前缀复用和结构化输出约束，另一侧偏通用的请求批处理与调度。差别听起来抽象，但落到你的业务上表现不一定一致——同一份权重换个框架，有的请求形态快一截，有的反而慢。
- 模型结构不同，注意力和 KV 缓存的占比就不一样，差距会被放大或抹平
- 量化档位不同，两个框架在低精度下的优化程度可能差一截
- 张量并行的切法不同，多卡通信开销的权重完全不同
- 上下文长度不同，长上下文才是两家差异最容易暴露的地方
- 如果你的请求几乎都是单轮短问、并发又很低，两者差距往往被网络和模型加载时间盖住，这时候别费劲比
把「谁快」拆成可复现的条件
所谓谁快谁慢，只在「某个模型 + 某种量化 + 某种卡 + 某种请求长度分布 + 某个并发档位」这组条件下成立。记结论的时候一定要把这几个条件一起记下来，缺一项，下次换环境就复现不了。
对比前先对齐测什么
别把延迟和吞吐揉成一个数看。这两类指标对框架的敏感度不同，混在一起看，很容易得出「A 更快」这种没法指导选型的结论。
| 指标类别 | 具体看什么 | 什么时候最影响体验 |
|---|---|---|
| 首 token 延迟 | 请求发出到第一个字返回 | 交互式对话、流式输出场景 |
| 单请求生成速度 | 每 token 或每秒输出多少字 | 长文本生成、代码补全 |
| 固定并发总吞吐 | 同一并发下每秒处理多少请求 | 有明确 QPS 指标的线上服务 |
| 长上下文显存占用 | 长输入下显存涨多少 | 大文档问答、长会话 |
- 压测输入要贴近真实：固定随机 prompt 会高估前缀缓存的收益，用业务日志里的真实长度分布更准
- 记录口径必须写全：并发数、输入输出长度、量化方式、卡型和卡数，缺一项结论就没法复现
- 每个指标单独出图，别只记一个「综合得分」
- 跑之前先想清楚你自己的延迟上限是多少，这决定了后面从哪个并发档位开始加压
一套能照做的对比流程
- 拉平基础条件用同一份模型权重、同一量化档位、同一张卡。先在低并发下确认两边都能正常起服务，并且输出结果基本一致，避免把配置错误当成性能差异。
- 阶梯加压找拐点从你的延迟上限反推起始并发，逐步加压，观察吞吐什么时候开始明显劣化。两家各自的拐点位置，比峰值数字更有参考价值。
- 只换框架这一个变量其他参数全部不动，至少跑两轮取稳定区间。单次跑出的峰值不要写进结论，那多半是抖动或者缓存刚好命中。
- 单独测一轮长上下文把长输入、长输出的请求拎出来单独跑，这是两家差异最容易暴露的场景，也是线上最容易踩坑的地方。
- 记录并留档把每轮的命令、参数和结果存下来，下次换模型或换卡可以直接对照。
压测脚本怎么写、指标怎么采，可以到站内的压测与性能对比相关页面参考现成方法，不用从零搭。
按场景选，别按名气选
选型不是选谁更快，而是选谁在你的场景下总成本更低。总成本包含的不只是吞吐，还有适配工作量、运维复杂度和排障难度。
| 你的场景特征 | 可以优先考虑 | 理由 |
|---|---|---|
| 请求前缀高度重复、输出有大量结构化约束 | SGLang 方向先试 | 这类正是它缓存与约束优化发力的地方 |
| 请求形态杂、要挂的模型种类多 | vLLM 方向先试 | 通用适配面通常更省事 |
| 团队已有现成的监控、脚本和排障经验 | 沿用团队熟悉的那套 | 人力成本往往比几个百分点的吞吐更值钱 |
| 模型很小、单卡就能扛住全部并发 | 先跑通再谈优化 | 这种规模下选型空间很小，别过早纠结 |
- 团队已有运维脚本、监控告警和故障处理经验落在哪个框架上，这个权重往往被低估
- 如果你需要频繁换模型做 A/B，适配和加载流程顺不顺比峰值吞吐更重要
- 不适用的情况：服务是离线批处理而不是在线，延迟指标基本没意义，先比总耗时和资源占用
- 不适用的情况：单机单卡、并发长期跑不满，两个框架都能满足，先选团队顺手的
别忽略升级和维护成本
框架本身也在迭代，接口和默认行为会变。选之前问一句：这个版本升级时，我的推理脚本和监控要改多少。改动大的那一边，长期维护成本会持续往上叠。
定下来之后要盯的两件事
选完不等于结束。上线后环境会变，权重会换，卡会扩，原来的基线很快就不适用了。
- 按固定周期复测一次延迟和吞吐基线，把结果留档，作为后续换模型、换卡、换框架的对照组
- 显存和并发的关系会随上下文长度变化，扩并发之前先在站内相关页面估一遍，别等 OOM 了再回头查
- 把两次复测之间发生的变更记下来，出问题时能快速定位是哪次改动引入的
常见问题
SGLang 一定比 vLLM 快吗？
不一定。差异主要来自请求形态而不是框架本身，前缀重复度高、输出有结构约束时一边可能明显占优，普通短请求并发低时两者可能看不出区别。正确做法是用你自己的流量分布压一轮，而不是照搬别人的结论。
两个框架能同时跑在一台机器上吗？
技术上可以，各自监听不同端口即可，但要注意显存和算力的争抢，共用一张卡时压测数据会互相污染。如果只是为了做对比，建议分时段跑，或者用不同的卡，保证变量单一。
压测需要压到什么并发才算够？
不要盯一个固定数字，而是从你的延迟容忍上限反推。做法是逐步加并发，记录延迟和吞吐，找到吞吐不再涨、延迟开始明显抬升的那个点，那个点之前的区间才是你实际能用的范围。
