高并发场景选推理框架，最怕看别人一句「某家更快」就换。两者差距会被模型结构、量化档位、批大小、上下文长度和调度策略一起拉扯。这篇不给你定论，给一套自己动手的比法：先想清楚自己的流量形状，再把压测参数固定住，最后把吞吐和延迟分开看，避免用平均值骗自己。
高并发团队选推理框架，最怕看到别人一句「某家更快」就动手换。SGLang 和 vLLM 的差距会被模型结构、量化档位、批大小、上下文长度和调度策略一起拉扯，同一组数字搬到另一个场景经常反过来。所以这篇不给定论，只给一套自己动手的比法：先想清楚自己的流量长什么样，再把压测参数锁死，最后把吞吐和延迟分开读，别用平均值骗自己。
顺序很重要。先定义指标，再搭压测台，再看功能匹配，最后才做决策和灰度验证。跳步的代价通常是：花钱花时间迁完了，才发现瓶颈其实在网关排队，或者你的长上下文前缀把性能差距抹平了。
先定指标：你要的是吞吐还是延迟
把目标分成三类再开口比：离线批处理盯总吞吐，在线问答盯首 token 延迟和单请求 TPOT，混合流量盯满载下的尾延迟而不是平均值。两个框架的连续批处理与分页 KV 缓存实现细节不同，小 batch 和大 batch 下的表现会分叉，因此同一组参数下的差距不代表你线上流量的差距。先把并发请求数、输入输出长度分布、是否共享长前缀、是否要流式返回写成一页纸。
- 离线任务：以单位算力每小时能出多少 token 为准，延迟可以牺牲，看的是总产出
- 交互式问答：以首 token 延迟和用户体感的出字速度为第一优先，吞吐退居其次
- 混合流量：看满载时的 P95、P99，平均值好看但尾部崩掉，用户照样骂
- 长前缀场景：多轮对话或固定系统提示词反复出现，前缀命中率会直接改吞吐排序
压测怎么搭：把变量锁死再比
压测的前提是变量可控。同一模型权重、同一量化方式、同一张卡或同一卡数、同一并行策略，任何一项变了，之前的结论就要作废重做。输入输出长度也别只测一种，至少三组：短输入短输出、长输入短输出、长输入长输出，长上下文最容易拉开差距。并发从低档逐档往上加到打满，画的是并发—吞吐—延迟三条线，而不是只报一个峰值吞吐。
- 量基线先用站内接口测速工具量出网络与网关的固定开销，把框架之外的延迟减掉，再去 /tools/speed-test 记录对照。
- 固定环境锁硬件、锁权重、锁量化、锁并行策略，把启动参数写进配置文件，每次只改一个变量。
- 跑梯度和长度按三组输入输出长度跑并发梯度，每档至少多轮，记录吞吐和 P95、P99，而不是单次峰值。
- 带真实前缀用线上采样的前缀结构压测，别只用随机 prompt，前缀复用的效果差异很大。
- 记录口径把监控指标定义、超时、并发上限一起记下，换框架后指标口径变了容易误判成性能退化。
| 对比维度 | 怎么测 | 读结果时注意 |
|---|---|---|
| 总吞吐 | 打满并发跑固定时长 | 别用单次最高值，取稳定段 |
| 首 token 延迟 | 低并发到中并发各测一轮 | 排队一上来就恶化，重点看拐点 |
| 尾延迟 | 记录 P95、P99 | 平均好不代表尾部稳，看长尾 |
| 长上下文 | 长输入短输出专项 | 显存与调度策略影响被放大 |
单卡小模型、请求稀疏时，压测结果重复性差，多跑几轮取分布比追求小数点后一位更有意义。这类情况下不适合拿压测数字做框架级判断。
功能匹配：性能之外哪些点会决定成败
速度之外还有几件事会直接决定你能不能上线。多轮对话或同一系统提示词反复出现，前缀缓存命中率对吞吐影响很大，测的时候要带着真实前缀结构跑。如果你要严格 JSON 或固定语法输出，先确认两个框架在你用的模型上都支持约束解码，再谈速度，否则约束开销或降级方案会把差距拉平。
- 前后缀复用
- 同一提示词反复出现时，命中率高的那边吞吐优势会被放大
- 约束解码
- 结构化输出场景，先确认支持范围，再比谁快
- 量化与并行
- 某些量化格式和新架构一边支持更早，选型先对一遍能不能跑起来
- 运维面
- 多副本、滚动升级、显存溢出后的降级行为，线上比峰值更容易出事
选型前先到 /models/deploy 和 /compute/gpus 把自己手里的模型加卡组合对一遍，确认能跑、能并行、量化格式被支持。如果团队只有一两个人维护推理服务，功能少但稳定的那一边往往比功能全的那一边更省心，这种情况下不适用「功能全就选它」的思路。
怎么选、怎么小步验证
决策时别问「谁更快」，改问「在我的流量形状下，谁的单位算力成本更低、尾延迟更稳」。成本口径可以到 /compute/tco 对齐，把卡、电、人力的账摊开算，而不是只比单次压测的吞吐。落地顺序建议：灰度环境用真实流量采样回放压测，再切一小部分线上流量做影子对比，最后才全量，每一步都留回退路径。
- 先在灰度用采样流量回放，验证吞吐和尾延迟是否和压测一致
- 再切少量线上流量影子对比，观察监控指标是否异常
- 全量前把回退清单列好：权重、分词器、启动参数、并发超时、监控口径
- 注意版本漂移：两个项目迭代都很快，任何一段对比都可能过期
- 判断前到 /benchmarks 看当时的公开口径，但以自己复现的结果为准
常见问题
SGLang 和 vLLM 在高并发下到底哪个吞吐更高？
没有放之四海的答案。差距取决于模型结构、量化方式、输入输出长度分布和并发水平，长前缀复用场景与纯随机 prompt 场景的排序都可能不一样。靠谱做法是锁定变量、按并发梯度自己压一遍，再看当时站内公开口径做参照。
只测一个并发数能下结论吗？
不建议。单点数据很容易被瞬时波动带偏，也看不出框架的调度拐点。至少要跑一条并发梯度曲线，看吞吐在多高的并发触顶、延迟从哪一档开始陡增，再结合你自己的峰值并发判断留了多少余量。
换推理框架要先准备什么？
先备好回退方案：旧框架的启动参数、镜像版本、并发与超时配置都留档，监控指标口径同步对齐。切换走灰度验证，先影子流量后真实流量，出现尾延迟变差能一键切回，不要在赶工期时做全量替换。
