SGLang 对比 vLLM：Agent 跑得慢，是你选错了缓存

Dev.to ML 2026-10-23T03:37:02.938272

如果你在生产环境里跑 LLM Agent，这周流传的那组数字你多半已经见过：多轮 Agent 负载下，系统提示词上下文为 8000 token 时，SGLang 的 RadixAttention 把首 token 延迟（TTFT）从 440ms 压到 38ms，提速 11.57 倍；带前缀缓存的 vLLM v0.6 则从 480ms 降到 92ms，提升 5.21 倍（模型为 Qwen2.5-Coder-32B-Instruct-AWQ）。数据出自 NextByteTech 在 Dev.to 上那篇对比 ollama、vLLM、SGLang 的 2026 年文章。

数据是真的，结论也大体正确：面对长上下文、多轮对话的 Agent 流量，SGLang 目前确实更胜一筹。但「大体」这个词恰恰藏着关键。这些加速只在你负载形状合适时才成立。换一种流量跑同样两个引擎，差距会缩小，甚至反过来。这篇文章要补上的，正是那篇基准测试没给你的决策框架：RadixAttention 到底在什么时候真正领先，什么时候两个引擎打成平手。

RadixAttention 为什么能在 Agent 负载里取胜

vLLM 的前缀缓存和 SGLang 的 RadixAttention 做的是同一件事：把算过的 KV 缓存复用到重复的提示词前缀上。区别在数据结构。

vLLM 的自动前缀缓存（APC）历来是对提示词里整块做哈希，再拿结果去匹配已缓存的块。当请求共享很长且完全一致的前缀时——典型形态就是「系统提示词 + few-shot 模板」——它很管用；可一旦前缀在序列中间分叉，或者重叠部分对不齐块边界，效果就打折扣。

SGLang 的 RadixAttention 改用一棵基数树（radix tree，即压缩前缀树）按 token 序列存放 KV 缓存。重复的前缀成了树上共享的路径，缓存可以按任意公共前缀为粒度复用，不再受限于对齐的块。多轮 Agent 对话恰好就是这个形状：同一段 8000 token 的系统上下文，加上一轮轮长起来的对话历史，每一轮都和上一轮共享一大段公共前缀。树上几乎整段都能复用，所以首 token 延迟能降到 38ms——预填充基本被整个跳过。

第二份 Dev.to 对比（ifnodoraemon 的 SGLang vs vLLM 架构对决）则把机制直接体现在指标里：在 4,096 token 的提示词、75% 前缀重叠、并发 64 的条件下，SGLang 的 KV 缓存命中率达到 78.6%，vLLM 只有 41.2%；中位首次 token 延迟（TTFT）分别是 85ms 和 380ms（相差 4.47 倍），P99 TTFT 为 280ms 对 1,250ms，吞吐量则是 5,430 对 3,120 tok/s。命中率的差距就是性能的差距。当负载存在大量前缀重叠时，基数树更细粒度的复用会直接体现在每一个延迟分位数上。

但有时两者打平

接下来的内容才真正有用。三个已公开的反例，展示了这种优势在哪些情况下会消失。

1. 无重复提示词流量：差距几乎消失

bex.co 2026 年 9 月的报告（SGLang Crossed 400,000 Production GPUs）在 Spheron 的 H100 上对 Llama 3.3 70B FP8 做了测试，50 个并发请求，提示词各不相同——这种流量没有可复用的共享前缀。结果：SGLang 为 1,920 tok/s，vLLM 为 1,850 tok/s，两者的 TTFT 相差不到 20ms。没有共享前缀，就没有缓存可共享；基数树无从发挥，两个引擎在功能上打成平手。

2. 短提示词下的原始吞吐：vLLM 可能胜出

同一份 bex.co 报告还包含 2026 年 5 月在单张 H100 上跑 Qwen2.5-7B 的结果：vLLM 的原始吞吐达到 23,500 tok/s，SGLang 为 16,800 tok/s——在每秒总 token 数上 vLLM 明显胜出。但 SGLang 仍保持 4 倍以上的 TTFT 优势（1.8s 对 7.8s），所以并不是每个维度都落后；只不过对于吞吐优先、对延迟不敏感的批处理负载来说，「SGLang 更快」这个结论就是错的。

3. 高并发场景：性能交叉点确实存在

bex.co 在 DGX Spark 上做的并发扫描测试发现：1–4 个并发请求时 SGLang 胜出，6 个以上并发请求时 vLLM 胜出。RunPod 博客中关于 SGLang 与 vLLM 的 KV 缓存对比（2 张 H100、DeepSeek-R1-Distill-Llama-70B、7k 上下文）得出结论：缓存命中大约带来 20% 的速度提升；而在全新上下文场景下，两个引擎表现相当。如果你的流量形态是大量短小、互不相关的提示词、高并发——也就是典型的聊天机器人服务场景——基数树的额外开销带不来任何收益，vLLM 的吞吐引擎反而占上风。

工作负载类型 胜出方（依据已公开结果）
多轮智能体，长共享系统提示词（8k token），中等并发 SGLang，大幅领先（TTFT 加速 11.57x vs 5.21x）
4k 提示词，75% 前缀重叠，并发 64 SGLang（中位 TTFT 4.47x，KV 命中率 2x）
独立提示词，无共享前缀，50 并发 持平（1,920 vs 1,850 tok/s，TTFT 差距在 20ms 以内）
短提示词，吞吐优先的批处理，1 张 H100 vLLM（原始吞吐 23,500 vs 16,800 tok/s）
短提示词，6+ 并发（DGX Spark） vLLM
全新上下文，无缓存复用（RunPod） 持平

决策清单

在切换引擎之前，先用下面四个问题衡量一下你的工作负载：

  1. 你实际的前缀重叠有多少？ 如果大多数请求都共享一段很长的系统提示词或对话历史（智能体、带固定指令块的 RAG、少样本模板），RadixAttention 更细粒度的复用就能发挥价值。如果每条提示词都是独立的，基数树就是纯粹的负担。

  2. 你的并发是多少？ 已公开的扫描测试显示存在一个交叉点：低并发时 SGLang 领先，并发升高后 vLLM 反超（一份报告显示在 DGX Spark 上大约在 6+ 并发处交叉——请用自己的硬件验证）。按你的实际流量来选型，而不是按基准测试的配置。

  3. 你的负载是预填充密集还是解码密集？ 前缀缓存只加速预填充阶段。如果你的输出很长、提示词很短，大部分时间花在解码上，缓存优势就缩水到可以忽略不计。RunPod 那个“缓存命中提升 20%”的数字是个不错的心理锚点。

  4. 哪个延迟百分位对你重要？SGLang 报告的最大优势在首字延迟（TTFT）和尾延迟（P99 在 75% 重叠场景下为 280ms，vLLM 为 1,250ms）。如果你的 SLO 针对的是批处理任务的端到端每秒 token 数，那这个优势可能对你没什么用——vLLM 的原始吞吐量优势体现了权衡的另一面。

结论

基准测试文章的核心数字——多轮智能体场景下 TTFT 38ms 对 92ms——在那个工作负载下是正确的，RadixAttention 的基数树设计对于共享前缀流量确实是更好的机制。但引擎跑的不是基准测试，而是你的流量。根据 bex.co、RunPod 和 Dev.to 上的第二篇对比，独占提示词服务、短提示词批处理吞吐和高并发聊天机器人场景下，两个引擎要么打平，要么 vLLM 胜出。先测量你的前缀重叠率和并发度，再选合适的缓存。

我们为构建真实产品的开发者撰写生产环境 LLM 基础设施和智能体系统的文章。在这里关注我们：https://t.me/qisuancloud 或试用我们的免费 GPU 顾问：https://qisuanai.com/advisor

查看原文