vLLM 与 SGLang：两个推理引擎到底在解决什么
——兼论 PD 分离的原理与最佳实践

00摘要：十条核心论断

如果只看一页，看这一页。每条论断都可在后文找到推导与证据；带「观点」标记的是本文判断，不是社区共识。

1. 两个引擎做的是同一件事：把 GPU 显存和算力换成「被服务的 token」。差别在于 KV Cache 的组织方式——vLLM 用分页（PagedAttention），SGLang 用基树索引（RadixAttention）。而基树是建在分页块之上的：树里存的是块索引，不是另一套内存分配器。二者是组合关系，不是竞争关系。这条如果理解错，后面所有对比都会看歪。
2. PagedAttention 的本质是「按需分配 + 引用计数共享」，把显存利用率从 20–40% 拉到 90% 以上。传统实现按最大长度预留连续空间，一个只用 100 token 的请求也占着 4K 的坑。分页后碎片趋近于零，直接换成更大的并发 batch。论文实测 Kwon et al., 2023
3. 连续批处理是吞吐的另一半，且和分页是两个独立创新。调度粒度从「一批请求」下沉到「每一个 forward step」：谁生成完了谁立刻出列，排队里的请求立刻补位。短请求不再被长请求钉住，吞吐基本不受请求长度方差影响。
4. RadixAttention 的本质是「跨请求、任意深度的自动前缀复用」。多轮对话、RAG、Agent 的每一轮都在重复上一轮的 prompt。基树把 prefill 从「全量重算」变成「只算增量」，并且默认开启——维护开销实测 <0.3%。论文实测 Zheng et al., 2023
5. 2025–2026 两个引擎已经在工程上收敛，选型依据应该是负载形状，不是「谁更快」。vLLM V1 把 prefill/decode 统一成 token 预算调度，chunked prefill 与前缀缓存默认开；SGLang 补上零开销 overlap 调度器、XGrammar 结构化输出、EAGLE-3/MTP 投机解码。观点任何「X 比 Y 快 N 倍」的说法都必须附带 batch 大小、命中率、模型三个前提。
6. PD 分离的动机不是「更快」，而是「解耦两个 SLO」。prefill 计算密集、decode 带宽密集，放在同一个 GPU 池里会互相干扰（一条长 prefill 插进 decode batch，整批的每 token 延迟全部被拉高），还被迫共享同一套并行策略。DistServe 报告：同 SLO 下可服务 4.48× 请求，或把 SLO 收紧 10.2×（>90% 请求达标）。OSDI 2024
7. PD 分离把「显存管理问题」变成了「网络问题」，这是它最容易被低估的代价。每个请求都要把整个 KV Cache 从 prefill 池搬到 decode 池，长 prompt 下是 GB 级。铁律：搬运 KV 的时间必须小于它替你省下的时间，否则净亏。Anyscale 实测：传输层从 RDMA 退回 TCP，吞吐劣化最高 19×。受控实验 Anyscale, 2026
8. P:D 配比是负载的函数，不是一个常数。配错会全面劣于不分离。长入短出 2P:1D；长入长出 1P:3D；多轮高命中 1P:2D。DeepSeek 线上是 4 节点 prefill : 40 节点 decode——那是他们的流量，不是通用答案。受控实验 Anyscale, 2026
9. vLLM 官方文档一句话说死了边界：「Disaggregated prefill DOES NOT improve throughput」。它买的是 TTFT 与 ITL 独立可调、以及尾部 ITL 可控；吞吐增益来自整套配置（池配比、路由、并行策略、缓存复用、负载形状），不是「把两阶段拆开」这个动作本身。官方文档 vLLM Docs, 2026
10. 落地路径必须是渐进的，直接上 PD 分离是最常见的错误。共址 + 连续批处理 + 前缀缓存 → 加 chunked prefill → 多副本时上 cache-aware router → 只有在「长 prompt + 高并发 + RDMA 就位」三条件同时成立时，才上 PD 分离。观点

01先建立共同语言：一次请求到底在干什么

后面所有的优化，本质上都是在对付下面这张图里的两个方块。理解它们的差异，比记住任何基准数字都重要。

四个必须分清的指标

一句话概括两个引擎的分工层次

它们都处在 AI 应用栈的最底层：上面是网关、Agent 框架、业务代码，它们决定「要问哪些 token」；引擎只负责「把 GPU 资源换成 token」。两者都提供 OpenAI 兼容 API，因此换引擎通常是一次配置改动，而不是一次代码重写——这一点决定了你完全可以在生产里同时跑两个引擎，用网关按请求类型分流。

02战场：KV Cache 才是那个决定一切的东西

不理解 KV Cache 的量级，就不会理解为什么「显存管理」能带来 2–4 倍吞吐差距，也不会理解为什么 PD 分离会变成一个网络问题。

KV Cache 是什么

Transformer 每生成一个新 token，都要拿它去和此前所有 token 做注意力计算。如果每次都重算历史 token 的 Key / Value 向量，代价是平方级增长。于是工程上把它们缓存下来，这就是 KV Cache——可以理解为模型的「短期记忆草稿纸」：prompt 越长、并发越多，草稿纸越大。

它有多大：一个可以自己验算的公式

KV Cache 字节数 ≈ 2 × 层数 × n_kv_heads × head_dim × 序列长度 × 每参数字节数

拿 Llama-3-70B（80 层、GQA 8 个 KV head、head_dim 128、bf16 = 2 字节）来算：

每 token： 2 × 80 × 8 × 128 × 2 B = 327,680 B ≈ 0.32 MB
单条 4096 token 的请求：≈ 1.34 GB
并发 32 条：            ≈ 42.9 GB  ← 一张 A100 40GB 直接装不下

三个由此推导出的工程动作

03vLLM 核心能力一：PagedAttention —— 把操作系统那套搬进显存

一句话：显存不够用，往往不是真的不够，而是被「预留」和「碎片」吃掉了。PagedAttention 用虚拟内存分页的思路把这两块浪费还给你。

机制：三张表解决一件事

操作系统怎么管理内存，vLLM 就怎么管理 KV Cache：把每个序列的 KV Cache 切成固定大小的块（默认 16 个 token 一块），用一张块表记录「逻辑位置 → 物理块」的映射。生成新 token 时按需申请新块，请求结束立刻释放。

三个直接后果

1. 碎片趋近于零，显存利用率从传统实现的 20–40% 提升到 90% 以上（vLLM 论文实测）。不是算得快，是不再浪费。
2. 共享成为可能：相同前缀的多条请求可以指向同一批物理块；beam search / 并行采样在分叉前共享，分叉时才触发写时复制（copy-on-write）。
3. 显存不够时可以整体换出：vLLM 的换出粒度是「整个请求」而非单个块，这样实现简单且在简化架构下开销更低（V1 在显存压力下默认选择重算而非换出）。

04vLLM 核心能力二：连续批处理与 V1 的统一调度器

分页解决了「能不能塞进来」，连续批处理解决「塞进来之后 GPU 有没有一直在干活」。这是两个独立的创新，缺一个都拿不到完整收益。

V1：把 prefill 和 decode 当成同一种东西来调度

vLLM 在 2025 年完成了核心架构重写（V1，2025 年 1 月发布，v0.8.0 起成为默认引擎，v0.11.0 完成 V0 代码移除）。最重要的一处变化是调度器：

调度决策 = { request_id: 本步处理多少 token }   ← 不再区分 prefill / decode
每个 step 在固定 token 预算（budget）内分配，chunked prefill 由此自然实现

这个「统一表示」带来三个好处，且都是默认开启、零配置的：

还有几处让 V1 变快的工程细节

• CPU 任务卸载：tokenization、多模态预处理、detokenization、流式输出移到独立进程，与 EngineCore 并行，避免 Python 侧拖慢 GPU。官方文档
• Persistent Batch：缓存输入张量、每步只打增量（diff），并用 Numpy 替代大量 Python 循环，压低调度开销。
• torch.compile + 分段 CUDA Graph：自动优化模型执行，同时保留动态 shape 的灵活性。
• 对称 TP 架构：请求状态缓存在 worker 侧，调度器只传增量，单卡与多卡行为一致。

综合效果：官方报告 V1 相对 V0 最高带来 1.7× 吞吐提升，多模态模型上更明显。

05SGLang 核心能力一：RadixAttention —— 让「重复的东西只算一次」

vLLM 问的是「显存怎么不浪费」；SGLang 多问了一句「这些显存里的内容，有没有可能根本不用再算一遍」。对 Agent、多轮对话、RAG 来说，第二个问题的答案往往是「一大半都不用算」。

机制：一棵以 token 前缀为边的树 + LRU

RadixAttention 把所有已计算过的 KV Cache 段组织成一棵基树（radix tree）：树的每条边是一段 token 序列，每个节点持有对应 KV 块的索引。新请求进来，先在树上找最长匹配前缀，命中部分直接复用，只 prefill 没命中的后缀。

和 PagedAttention 的关系：不要搞成二选一

基树里存的是分页块的索引，不是另一套内存分配器。也就是说 SGLang 的分页机制和 vLLM 是同类，基树是建在分页之上的一层索引。所以二者是组合关系。vLLM 同样支持前缀缓存（Automatic Prefix Caching，按块哈希），差别主要在两点：SGLang 的匹配是树结构、任意深度、默认开启、带缓存感知调度；vLLM 的 APC 更偏块级精确匹配。

06SGLang 核心能力二：结构化输出、零开销调度与投机解码

这三项加起来，构成 SGLang 在「Agent 型负载」上的实际优势。它们解决的是三类完全不同的开销。

压缩有限状态机：让 JSON 不再是「一个 token 一个 token 吐」

约束解码（grammar / JSON Schema / regex）的原理是：每步用一张掩码把不合法的 token 概率压到 −∞。朴素实现每步都要重算掩码，成本显著。SGLang 的压缩 FSM 做了一件聪明事：当 FSM 走到「只有唯一合法路径」的位置（比如 JSON 里固定出现的 ":{"），就一次性吐出整段 forced token，跳过逐步采样。

零开销调度器：把 CPU 的调度时间藏进 GPU 的计算时间里

另外三件值得知道的事

07正面交锋：能力对照与选型决策树

先说一句可能不受欢迎的话：2026 年的现实是两者已经高度收敛。真正的差异体现在负载形状上，而不是「谁更快」。

能力对照矩阵

08PD 分离（一）：为什么非拆不可

PD 分离（Prefill-Decode Disaggregation，也写作 P/D、xPyD）把两个阶段放到不同的 GPU 池。它解决的不是「算得慢」，而是「两个脾气完全相反的客人被塞进了同一间房」。

两阶段的硬件胃口是相反的

共址部署的两个具体病症

量化证据

注意这些数字的口径：全部是 goodput（SLO 约束下），不是 raw throughput。换成无约束的 token/s，PD 分离基本没有增益——这一点在下一章会被 vLLM 官方文档正面确认。

09PD 分离（二）：具体怎么拆

架构本身只有三个零件：一个会看请求的路由器、两池 GPU、一条传输 KV Cache 的通道。复杂度全在这条通道上。

vLLM 的实现：两个实例 + 一个 connector

vLLM 的 disaggregated prefilling 实现得很直白：跑两个 vLLM 实例，一个只做 prefill（kv_producer），一个只做 decode（kv_consumer），中间用 connector 搬运 KV。全部代码在 vllm/distributed/kv_transfer 下，由三个抽象组成：

Connector     —— 调度侧决定「发哪些 KV」，worker 侧按层异步存取
LookupBuffer  —— 在途 KV 块的暂存区，insert 非阻塞 / drop_select 阻塞
Pipe          —— 单向 FIFO，send_tensor / recv_tensor

启动方式（官方示例形态）：

# prefill 实例
vllm serve <model> --port 8100 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_producer"}'

# decode 实例
vllm serve <model> --port 8200 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_consumer","kv_rank":1}'

截至 2026 年，vLLM 提供 9 类 connector，常用的几个：

SGLang 的实现：一等公民 + 参考部署

SGLang 把 PD 分离当核心特性做，并公开复现了 DeepSeek 的线上规模部署（2025 年 5 月，LMSYS）：

几个配套的工程细节值得注意：attention 用 DP Attention 消除 KV 重复；MoE 用 DeepEP 的两种 dispatch 模式分别服务两阶段（prefill 走 normal dispatch 追吞吐，decode 走 low-latency dispatch 追延迟且兼容 CUDA Graph）；Two-batch Overlap 把通信藏进计算；EPLB 做专家负载均衡。

10PD 分离（三）：最佳实践

这一章是可以直接照着做的部分。核心原则只有一句：先证明你的瓶颈真的是「两阶段互相干扰」，再动手拆。

第一步：判断该不该上（三个条件必须同时成立）

第二步：先验算 KV 传输成本，别事后才发现

用第 02 章的公式：传输字节数 ≈ 2 × 层数 × n_kv_heads × head_dim × seq_len × 每参数字节数。Llama-3-70B bf16 下约 0.32 MB/token；FP8 KV Cache 可以直接砍半。

第三步：定 P:D 配比 —— 这是最容易搞错的一步

配比不是常数，是负载的函数。下面是 Anyscale 在 MI325X 上用 Ray + vLLM 跑 Qwen3-235B / DeepSeek-V3 的实测结论：

第四步：路由器决定成败

分离之后，「把请求发给谁」变成了一个独立的优化问题。路由器至少要会三件事：

• 按长度分流：低于阈值（如 4096 token）的短 prompt 直连 decode 池，跳过 prefill 跳数——这是很多生产部署的默认行为。
• 前缀亲和路由：让同一会话、同一批重复 prompt 落到已经持有对应 KV 的节点。实测价值很大：llm-d 的前缀感知路由在 Llama-3.1-70B / 4×MI300X 上给出 3× 输出吞吐、2× 更快 TTFT（相对 round-robin）。
• 传输 vs 重算的权衡：当大小为 S 的前缀在节点 i 上、而节点 j 队列最短时，系统至少有四个选择——路由到 i、等 i、从 i 搬到 j、在 j 上重算。判断条件可以简化为比较 T_transfer(S,i→j) + T_queue(j) 与 T_wait(i)、T_recompute(S)。

第五步：上线清单

必须上监控的指标

11反模式清单

按「症状 → 修正」排列。这里列的每一条，都是生产环境里真实发生过的。

战略层：方向错了，后面全白做

工程层：细节吃掉收益

运维层：上线之后才是开始

12结论与判断

以下明确区分「社区共识」与「本文观点」，请区别对待。

已经形成共识的部分

• 分页式 KV Cache 管理是标配，不是可选项。PagedAttention 之后的引擎基本都采用了「块 + 块表 + 引用计数」这套结构。
• 连续批处理是吞吐的基础，调度粒度必须下沉到 forward step。
• 前缀复用对 Agent 型负载收益巨大，且应当默认开启。维护开销已经被压到可以忽略（vLLM 0% 命中时 <1%，SGLang 树操作 <0.3%）。
• PD 分离的价值在于 goodput 与尾部延迟，不在于 raw throughput。这一点 vLLM 官方文档写得毫不含糊。
• 传输层质量是 PD 分离的生死线。RDMA 与 TCP 之间可以差一个数量级以上。

本文的判断（不是共识，供参考）

13参考来源

按证据强度分组。一手论文与官方文档优先；行业实测报告次之；二手综述仅用于交叉印证。

一手研究（论文）

• Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention（SOSP 2023）——PagedAttention 原始论文，显存利用率 20–40% → 90%+、吞吐 2–4× 的出处。一手
• Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs（2023，arXiv 2312.07104）——RadixAttention、压缩 FSM、前端 DSL；树操作开销 0.2s/74.3s、压缩 FSM 1.6×、重复预处理 −2.4×。一手
• Zhong et al. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving（OSDI 2024，arXiv 2401.09670）——PD 分离的奠基工作；4.48× 请求数 / 10.2× SLO 收紧；13B 单 A100 的 1.6 → 3.3 rps 测算。一手
• Patel et al. Splitwise: Efficient Generative LLM Inference Using Phase Splitting（ISCA 2024）——1.4× 吞吐 @ −20% 成本；2.35× 同成本同功耗。一手
• Qin et al. Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving（FAST 2025 最佳论文，arXiv 2407.00079）——KVCache 中心化、分层存储、早期拒载；模拟长上下文最高 +525%、真实负载 +75% 请求量。一手
• Yu et al. Orca（OSDI 2022）——连续批处理（iteration-level scheduling）的原始提出者。一手

官方文档

• vLLM Docs, Disaggregated Prefilling (experimental)（2026）——「DOES NOT improve throughput」原文；9 类 KV connector 清单与配置示例；Connector / LookupBuffer / Pipe 三抽象。官方
• vLLM Docs, vLLM V1 用户指南（2025–2026）——统一调度器、chunked prefill 与 prefix caching 默认开启、V0 移除时间线。官方
• vLLM Blog, Inside vLLM: Anatomy of a High-Throughput LLM Inference System（2025-09-05）——前缀缓存的哈希与引用计数实现细节。官方
• vLLM Blog, vLLM V1: A Major Upgrade to vLLM's Core Architecture（2025-01-27）——V1 设计动机与 1.7× 吞吐。官方
• SGLang 官方文档（sglang.org）——特性列表、硬件与模型覆盖、PD 分离与并行策略。官方

行业实测与工程报告

• LMSYS / SGLang Team, Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs（2025-05）——3 节点 prefill / 9 节点 decode，52.3k 输入 token/s、22.3k 输出 token/s 每节点，5× 于朴素 TP，$0.20/1M 输出 token。实测
• Anyscale, Achieving Up to 67% Cost Savings with PD Disaggregation Using Ray + vLLM on AMD MI325X（2026）——Qwen3-235B / DeepSeek-V3，1.3–2.3× QPS；P:D 配比表；RIXL；TCP 回退最高 19× 劣化。实测
• Hao AI Lab, Disaggregated Inference: 18 Months Later（2026）——生态综述：LMCache、Mooncake、Dynamo、llm-d 的分层关系；GB200 NVL72 上 3.8×/4.8×。综述
• AWS, Disaggregated prefill and decode for LLM inference on SageMaker HyperPod（2026）——按 4096 token 阈值条件路由、前缀感知与会话路由策略。工程
• llm-d 项目报告（2026）——前缀感知路由在 Llama-3.1-70B / 4×MI300X 上 3× 输出吞吐、2× TTFT（相对 round-robin）。实测
• NVIDIA Dynamo（GTC 2025 发布，2026-03 GA 1.0）——跨引擎的编排层，SLA-based Planner 自动伸缩 P/D 池。工程

二手综述（仅用于交叉印证，不作为唯一依据）

• Particula Tech、Packet.ai、Groundy 等 2026 年 PD 分离综述文章——用于交叉核对框架支持矩阵与成熟度判断；其中「8000 token 以上」「几百 QPS 以下不建议」等经验阈值来自这类来源，属于经验值而非实测结论。二手
• Sandbase 等 vLLM vs SGLang 对比文章——提供了 p95 延迟与 batch 吞吐的对照数字，但缺少完整测试条件，本文仅将其作为「结论依赖测量条件」的例证，未将其数字用于选型建议。二手