SGLang 和 vLLM，拿自己的请求测一轮再选
场景：团队准备部署一个模型，收到 SGLang 跑分和 vLLM 吞吐两张图，要选框架。结论：别人榜单不能直接读，先让两边处理同一批业务请求再比。产出：6 步选型方法论 + 公平比较条件表 + 4 种请求形态建议 + 12 行错误速查卡。 适用版本：SGLang v0.5.19（2026-09-05）/ vLLM v0.25.1 稳定版（2026-07），vLLM 文档为 latest 开发预览，部署时仍须核对安装版本。
TL;DR
- 场景：团队准备上线一个模型，同时拿到 SGLang 和 vLLM 两张跑分图，要在两个框架之间做选型。
- 结论：别人榜单里的"快"不能直接读；公平比较需要固定模型/精度/模板/样本，分别做基线、压力、冷热缓存，再叠加迁移成本一起判断。
- 产出：公平比较条件表（共同条件 5 项）、4 种请求形态建议（短问短答 / 长资料追问 / 长答案 / 工具 JSON）、冷热缓存分开记录的三步法、12 行常见错误速查卡。
版本矩阵
| 项目 | 状态 | 说明 |
|---|---|---|
| vLLM Automatic Prefix Caching 文档可访问 | ✅ 已验证 | https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/ 返回 HTTP 200 |
| vLLM APC 官方列出长文问答与多轮对话为适用场景 | ✅ 已验证 | 文档原文 "Long document query" 与 "Multi-round conversation" 两段 |
| SGLang bench_serving 文档可访问 | ✅ 已验证 | https://docs.sglang.io/docs/developer_guide/bench_serving 返回 HTTP 200 |
bench_serving 支持 --request-rate / --max-concurrency / --disable-stream |
✅ 已验证 | 官方文档明确列出三个 flag 含义 |
| vLLM 稳定版 v0.25.1（2026-07） | ✅ 已验证 | 多方报告一致，当前 PyPI 稳定版 |
| vLLM v0.25.0 重大变化（MRv2 默认、legacy PagedAttention 移除） | ✅ 已验证 | 2026 年发布，558 commits |
| SGLang v0.5.19（2026-09-05） | ✅ 已验证 | 上一轮已核查，本轮沿用 |
| vLLM latest 文档为开发预览 | ✅ 已验证 | 原文 "latest 开发预览文档，部署时仍须核对安装版本" |
| "普通聊天用 vLLM，Agent 用 SGLang"作为分界 | ❌ 已驳斥 | vLLM 官方同样把多轮对话列为 APC 场景；"有没有 Agent"不能作为分界 |
| 别人榜单里的"快多少"直接拿来用 | ❌ 已驳斥 | 模板、采样、硬件、量化、版本不同，结果不可移植 |
| 把所有样本都替换成"你好"再压 | ❌ 已驳斥 | 测到的缓存命中和质量已不是原业务 |
| 冷热前缀一起统计 | ❌ 已驳斥 | 预热请求应单独标记，不进正式统计 |
| 只保留成功请求的延迟 | ❌ 已驳斥 | 超时样本应一起记录，不能从结果里抹掉 |
| 一边精调几天、一边只跑默认 | ❌ 已驳斥 | 比较的是调优 vs 默认，不是框架本身 |
| 仅凭吞吐榜单宣布框架"普遍更强" | ❌ 已驳斥 | 业务、流量、模型都会变；榜单不代替自测 |
| vLLM APC 文档存在 ⇒ 两套引擎性能相同 | ❌ 已驳斥 | 功能存在不等于性能相同 |
| 迁移决策只看"谁更快" | ❌ 已驳斥 | 接入改动、问题定位、升级回滚、团队熟悉度都要算 |
团队准备部署一个模型，有人发来 SGLang 的跑分，有人贴出 vLLM 的吞吐。两张图都很快，但你真正关心的是：客服请求什么时候能开始回答，晚高峰会不会排队，现有工具调用还能不能工作。
这些问题，不能从别人的一张总榜里直接读出来。要选框架，先让两边处理同一批业务请求，再比较你在意的结果。
先删掉一条过时的分工
"普通聊天用 vLLM，Agent 用 SGLang"太粗糙了。至少就前缀复用而言，vLLM 官方也提供 Automatic Prefix Caching，并列出长文问答和多轮对话的适用场景。不能用"有没有 Agent"作为两者的分界。
SGLang 的 RadixAttention 和 vLLM 的缓存机制，值得理解；但技术名词只是帮助你解释结果。真正落地时，还受具体模型、硬件、量化方式、后端实现和版本影响。
因此，第一轮比较可以很朴素：两边能否运行同一模型，并正确处理你实际使用的接口。工具参数、流式结束、结构化输出和聊天模板出现差异时，先修正或记录差异，再谈速度。
同一份权重，还不够让两次测试公平
同样的消息如果经过不同模板，会变成不同输入。看似相同的最大输出长度，也不意味着实际生成的 token 数相同。
准备一份实验配置，至少固定模型 revision、权重精度、GPU 与并行方式、分词器和模板、输入样本、采样设置与结束规则。引擎特有参数不必强行一字不差，但要公开记录，让别人知道测的是默认配置，还是各自调优后的配置。
可以先比较各自可工作的基线，确认质量和接口正确；再分别调优，比较达到相同服务目标所需的资源。把一边精调几天、一边只运行默认命令，不能据此宣布框架普遍更强。
让测试像你的流量，而不是像演示
如果业务主要是多轮客服，只发随机短文本会遗漏共享前缀；如果业务主要是长输出代码生成，只测短答案又会低估 decode 压力。
建议从实际流量中整理以下几种形态，比例按业务分布设置，不把它们当平均分配的配额：
| 请求形态 | 主要观察 |
|---|---|
| 不同用户的短问短答 | 基础调度和高峰排队 |
| 同一份长资料上的连续提问 | 冷、热前缀与首 token 等待 |
| 需要长答案的生成 | 输出阶段耗时与并发影响 |
| 工具或结构化输出请求 | 格式、语义正确性和失败处理 |
真实输入必须脱敏，并保留它的长度、顺序与复用关系。把所有样本都替换成同一条"你好"，虽然方便，测到的缓存和质量已经不是原来的业务。
冷缓存和热缓存各做一轮
第一条请求可能承担模型或内核预热，也可能尚未拥有可复用前缀。后续请求则可能利用已经留下的状态。两者应该分别标记。
比较前缀复用时，要明确哪些请求负责预热，哪些进入统计，还要确认两边的缓存起点相同。在专用测试实例上清理缓存可以帮助建立冷起点，不能顺手对在线服务执行清理。
SGLang 的压测指南列出了不同后端与端点、到达速率、并发限制和结果输出方式。工具支持多个引擎，不代表任意参数组合都适用于它们。开始前先看安装版本的帮助：
bash
python -m sglang.bench_serving --help本文没有在两套服务上执行对照，因而不给出获胜者。这里的命令只帮助你找到当前压测入口，也不能代替准备样本和检查结果。
吞吐更高，但用户等得更久，怎么办
把所有请求同时压过去，可以测到高负载能力，却未必接近真实用户的到达节奏。固定并发不断补请求，与按照一定速率发送请求，也会形成不同的排队情况。
测试时让两边承受相同的到达方式，并逐步提高负载。每一档一起看成功完成数、错误和超时、首 token 时间、完整响应时间，以及输出长度。不要只保留成功请求的延迟，把超时样本从结果里抹掉。
对于聊天应用，先提出可接受的等待目标，再看两边在目标内能接住多少请求。对于离线任务，整批完成时间可能更重要。目标来自你的产品需要，不来自某张跑分图擅长展示的指标。
输出质量也要留下来。更快返回一个格式不合格或工具选错的答案，未必替业务节省任何时间。
最后把迁移成本也放回决定里
如果两边都满足延迟和容量需求，接入改动、问题定位、升级回滚和团队熟悉程度就会影响选择。继续使用已经稳定的服务，也可以是合理结果。
一份有用的选型结论，应当能写成这样的句子："在这套模型、硬件和请求分布下，框架 A 在我们的等待目标内承载了更多有效请求；代价是这些接口和运维改动。"如果数据不足以支撑后半句，就先不要迁移。
这比宣布一个永远的赢家更有用：模型或流量变化后，你仍可以拿着同一批样本重测，而不用重新相信另一张榜单。
配图中的流程和记录表为方法示意，没有测量结果。两份官方文档检查于 2026-09-06；vLLM 来源为 latest 开发预览文档，部署时仍须核对安装版本。
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| 直接把别人榜单的"快多少"拿来选型 | 模板、采样、硬件、量化、版本不同，结果不可移植 | 用同一批样本、同一组配置分别跑一遍 | 自测后再下结论 |
| "普通聊天用 vLLM，Agent 用 SGLang" | vLLM 官方把多轮对话也列为 APC 场景 | 看 vLLM 官方 APC 文档 | 不要用"有没有 Agent"当分界 |
| 同一份权重但结果天差地别 | 聊天模板、分词器、采样、结束规则不同 | 把模板与参数写进实验记录 | 先统一再比 |
| 测出来 SGLang 更快，就宣布"普遍更强" | 一边精调、一边默认 | 记录两侧调优时间与参数 | 改用基线 vs 调优后对照 |
| 压测全用"你好" | 已脱离原业务，前缀不复用 | 抽查实际样本长度分布 | 按业务分布准备 4 类请求 |
| 冷热前缀一起统计 | 预热请求被算进首 token 时间 | 单独标记预热请求 | 预热不进正式统计 |
| 在在线服务上清理缓存 | 误把生产流量当测试 | 检查是否在专用测试实例 | 只在专用实例上清理 |
| 只保留成功请求的延迟 | 超时被掩盖 | 留存错误/超时计数 | 一起记录成功/错误/超时 |
| 固定并发不断补请求当成压测 | 与真实到达节奏不一致 | 看 --request-rate 是否设置 |
改用到达速率 + 逐步加负载 |
看到 --max-concurrency 高就觉得好 |
到达速率与并发上限是独立条件 | 同时看 request-rate 与 max-concurrency |
两个条件分别记录 |
| 跑分图更快的那个被默认胜出 | 没看产品可接受的等待目标 | 先定产品目标再比 | 让目标来自业务而非跑分图 |
| 输出更快但格式不对，宣布节省时间 | 质量没保留 | 留结构化/工具调用的格式与语义结果 | 把输出质量也记录 |
| 框架 A 跑分更快就迁移，没算运维成本 | 接入改动、升级回滚、团队熟悉度未算 | 列出迁移与运行成本项 | 都达标再算迁移值不值 |
| 仅看吞吐榜单宣布"普遍更强" | 流量、模型、硬件都在变 | 在目标流量下重测 | 保持样本可复用，定期复测 |
| vLLM APC 文档存在 ⇒ 两引擎性能相同 | 功能存在不等于性能相同 | 同输入同配置同负载自测 | 区分"有功能"与"够快" |
| 配图里看到"流程图"就以为有结果 | 配图是方法示意，未做测量 | 看配图角标"方法示意，非实测" | 数据来自自测，配图只是方法 |
作者 ：武子康的个人博客 发布日期 ：2026-09-12 核查依据 ：vLLM APC 官方文档（HTTP 200，2026-09-06 检查）、SGLang bench_serving 官方文档（HTTP 200，2026-09-06 检查）；vLLM v0.25.1 稳定版（2026-07）+ v0.25.0 MRv2 默认变更；SGLang v0.5.19（2026-09-05）。本文未在两套服务上执行对照，所有"快多少"属于"待自测"。