sglang vs vllm benchmark

你可能正卡在这一步：两台机器、同一份权重，网上一堆 SGLang 和 vLLM 的吞吐延迟对比，数字各自漂亮，落到自己的模型和卡上却对不上。这篇不给你一个「谁更快」的结论，而是给一套读基准、复现基准、判断基准适不适用的动作清单，让你用自己的业务请求量测出能拍板的数字。

你可能正卡在这一步：两台机器、同一份权重，网上到处是 SGLang 和 vLLM 的吞吐延迟对比，数字各自漂亮，搬到自己的模型和卡上却对不上。这篇不给你「谁更快」的结论，而是给一套读基准、复现基准、判断基准适不适用的动作清单，让你用自己业务的请求分布测出能拍板的那组数字。

核心思路只有一句：基准不是答案，是一份可复现的实验记录。别人的数字只在「同样的模型、同样的卡、同样的请求分布、同样的并发」这四个条件同时成立时才对你有效，绝大多数时候不成立，所以你要做的是抄方法，不是抄结果。

先搞清两家的基准到底在比什么

两家的基准差异主要来自四件事：输入输出长度分布、并发数、批处理调度策略、量化与并行配置。任何一项不同，对比就直接不成立。看到一组数字，先反推这四项，缺哪项就去原始测试脚本里找，找不到就当它没有参考价值。

前缀复用

多个请求共享同一段提示词前缀，缓存命中后省掉重复计算，SGLang 在这类负载上通常占优

连续批处理

请求边生成边进 batch，不等整批跑完，vLLM 的显存分页管理就是为这个场景服务的

首 token 延迟

从发出请求到吐出第一个字的时间，交互式产品最在意这个

单请求吞吐

一个请求独占资源时每秒能出多少 token，离线批量任务看它

整机总吞吐

所有并发请求加起来每秒多少 token，成本核算看它

站内基准与规格页怎么读，哪些数字能信

框架官方仓库的 benchmark 目录，给的是特定模型加特定卡的结果，只适合判断量级，不适合直接换算到你的机器。你可以拿它划一个区间，但别拿它当结论。真正的测算要落到自己的模型、量化档位和卡型上，到 /models/deploy 跑一遍估算，再回头和基准里的量级对齐，差一个数量级就说明变量没对齐。

另一个坑是只看显存。卡与卡之间不能只比显存大小，显存带宽和互联方式对长上下文吞吐的影响更大。先到 /compute/gpus 核对规格口径，确认你比较的两张卡是不是同一代、有没有走同一种互联，再谈速度差异。

在你自己的机器上复现一套可信对比

1. 锁死变量同一份权重、同一量化、同一上下文长度分布，只切框架，其他全不动。改一项就不是对比，是两次独立实验。
2. 先测单请求基线并发为一，跑够多次取稳定值，拿到首 token 延迟和每 token 延迟的下限。这一步排除冷启动和加载时间的干扰。
3. 逐级加并发从低并发往上加，记录整机总吞吐的变化，找到吞吐拐点出现在几路并发，而不是只报一个峰值。拐点之后的数字对你没意义，因为你不会长期跑在那个点上。
4. 按真实业务造请求短输入长输出的问答和长输入短输出的摘要，两个框架的结论经常反过来。用生产日志采样，不要用随机长度。
5. 四项全记显存占用、首 token 延迟、每 token 延迟、每秒总 token。缺一项就没法做取舍，因为成本和体验是分开算的。

什么情况下这份对比不适用

如果你的并发长期很低，两个框架的差距会被冷启动和模型加载时间吃掉，换框架带来的收益非常有限，这时候优化加载和缓存命中比换框架划算。判断方法是看你的峰值并发有没有稳定越过吞吐拐点，没越过就先别动。

团队没有专人维护推理服务时，部署复杂度、报错可查性、文档质量比峰值吞吐更重要。一个出问题能十分钟定位的框架，胜过一个快一点但报错看不懂的框架。反过来，如果业务重度依赖某一家特有的能力，比如前缀缓存或结构化输出约束，先确认它在另一家能不能实现，再谈速度。

• 并发长期处于低位：优先看加载与缓存，不动框架
• 没有专职维护人力：优先看排障成本与文档
• 重度依赖某家特有特性：先验证能否迁移，再比吞吐
• 模型规模接近单卡上限：显存管理策略的差异会被放大，需要单独测
• 上下文长度远超常规：带宽和互联的影响可能盖过框架差异

拍板前的对照清单

最后提醒一句：网上任何一组 SGLang 与 vLLM 的对比数字，都只是某台机器某个模型某个负载下的快照。你要复现的是它的实验设计，不是它的结果。把自己机器的四项硬约束写下来，按上面的顺序跑一遍，得到的数字才能拍板。