vLLM 和 SGLang：生成引擎在忙什么？

核对：2026-10-12 · 对照 vLLM v0.31.0（2026-10-05）与 SGLang v0.5.21（2026-10-02）的文档；源码链接固定到 2026-10-10 的 main commit。下面的数字是教学算例，没有跑框架性能排名。

一个模型用 generate() 能回答问题，为什么还需要 vLLM 或 SGLang？因为服务里不只有一个人在问：长短请求一起进来，有人中途关闭窗口，也有人反复问同一份文档。引擎要安排这些工作，而不是每来一条请求就从头独占 GPU。

先会 prefill、decode 和 KV cache即可。想逐步跟代码，配合一次请求怎样跑完；这篇重点看架构关系和选型。

从应用到算子，中间隔着几层

vLLM V1 的架构文档区分 API server、engine core 与 GPU workers：API server 处理输入输出，engine core 组织调度与缓存，GPU workers 执行模型；开数据并行（data parallelism）时还会多一个 DP coordinator。具体进程数量随部署而变。SGLang 也有自己的请求处理、调度与模型执行路径，不要把 vLLM 的类名原封不动套过去。

更具体地看，SGLang 固定版本的 Engine把 tokenization、调度与 detokenization 分开：

请求 → TokenizerManager → Scheduler → 模型执行
        ↑                                ↓
     返回文本 ← DetokenizerManager ← 输出 token IDs

TokenizerManager 管输入与请求结果，Scheduler 决定当前批次，执行路径完成 forward，DetokenizerManager 把 token 转回文本。图里省略了多卡拓扑与跨实例路由，不是在承诺每次部署都只有三个进程。这个拆法也帮你排错：GPU 没满、请求却很慢时，可以检查输入处理和输出回传，而不只盯着 attention kernel。

把两套实现放在同一张图里

先沿左边读一次 vLLM，再沿右边看 SGLang。箭头旁写的是交接内容：不是把完整模型或整个 KV cache 在每层之间来回复制。图只画普通自回归文本生成的主要职责；多模态和推测解码会有分支。图按一步一步画，但两边在兼容配置下默认让 CPU 排下一轮时 GPU 同时算这一轮（vLLM 叫 async scheduling，SGLang 叫 overlap scheduler）。

vLLM 的进程边界可查官方架构，执行入口可跟 EngineCore。它把 SchedulerOutput 交给 executor；worker 里的 model runner 再结合本地请求状态准备 token、位置与 attention 元数据，不是由调度器提前拼好全部模型输入张量。该固定 commit 在兼容配置下优先用 Model Runner V2，不支持的功能、缺少 Triton、部分 ROCm 模型默认设置，或显式配置，都可能改走旧的 GPUModelRunner。SGLang 这条路径核对到固定 commit：从 Scheduler.run_batch，到 worker 的批次转换与 forward，再到 ModelRunner。这些是阅读坐标，不是要求背下类名。

假设 request R 有 6 个 prompt token，其中前 4 个对应可复用的完整缓存块。Scheduler 不能简单说“命中了就结束”：它还要确认复用有效、剩余 2 个 token 有位置可写、本轮有预算。算完后采样出第一个新 token X；这不表示 X 的 KV 已经写好了。下一轮把 X 作为输入，才会生成它自己的 KV，再预测下一个 token。全前缀命中时如何得到下一 token 的 logits，还要看具体实现是否需要计算末位置等路径，不能把缓存直接当答案。

这里有两种容易混淆的“传递”：

• 控制消息：请求元数据、取消、批次计划、完成通知。API 和引擎间可能使用 IPC；不是每条消息都带一整份权重。
• 张量传输：TP collective、PP 的中间激活、跨设备或跨实例搬 KV。真正的带宽、同步和拓扑成本在这里具体计算。

模型执行再往下，还有哪些层？

PyTorch、Triton、CUDA / 厂商库可能出现在不同后端，不是每次执行都必经的一串“服务”。比如 CUDA Graph 主要减少 CPU 发起 GPU 工作的开销（为什么小 batch 时这笔开销显眼，见框架这一层），不会让 KV cache 免费，也不会消除 TP 的通信。FlashAttention 的 IO 优化与 paged KV 的内存管理同样不在一个层面：前者改变 attention 怎么计算，后者改变 KV 怎么分配和寻址。详见attention kernel 与缓存布局。

SGLang 的上述执行选择可以在固定版本的 ModelRunner中继续追。面试讲到自己没测过的后端，就说清阅读到哪一层，不把源码阅读说成调优经验。

多张 GPU，不是只有一种拼法

举个教学配置：总共八张 GPU，TP=2、4 个完整副本，就是每个请求由一个双卡组处理，共有 4 组独立安排请求。不能把它说成“每个请求自动用满八张”。是否比 TP=8 更合适，取决于模型放得下吗、KV 余量、单请求延迟、到达率和互联。先把显存账算清，再拿代表性负载验证。

卡数相同，TP8 和 DP8 在忙什么？

先看 dense 模型，不启用共享专家。TP8 是 8 张卡合作跑一份模型；DP8 / TP1 是 8 份模型分别接请求。 一组 TP8 也可以批量处理很多请求，不是“一组只能服务一个人”。差别在于一轮计算由谁合作完成。

假设权重恰好占 16 GiB、每卡 24 GiB，并把全部权重视为可均匀切分。下面只算权重，暂不计 KV、工作区和小型复制参数：

这是纯权重估算，不是可服务并发或吞吐结果。DP8 的单卡剩余 8 GiB，还得容纳缓存和运行时；不能全算成 KV。

权重放得下、目标是总吞吐时，可以先测副本方案；单卡容量不足，或者单请求计算太重时，再比较 TP / PP。TP 的矩阵变小不保证延迟线性下降：通信、kernel 效率和调度都可能抵消收益。vLLM 扩展指南给出了单卡、TP 与 TP+PP 的部署起点；实际选择仍要测自己的请求分布。

比较时固定总卡数、到达流量、输入/输出长度和缓存预热条件。不要只看离线 tokens/s：也看首 token 延迟（TTFT）、输出间隔、尾延迟、被拒请求和每卡显存峰值。一个吞吐更高、但排队更久的配置，不一定更适合交互产品。

部署时的 DP，不一定是互不相干的副本

训练里的 DDP 同步梯度；推理里的 data parallelism 通常分配请求。对于 MoE，还要看专家是否跨副本共享。按 2026-10-09 核对的 vLLM EP 部署说明，启用 EP 时，专家组大小为 TP × DP；attention 的复制或切分与专家分布不是同一件事。这是该框架的组合方式，不是所有系统的定义。

用一个虚构权重账：可切分的非专家权重共 6 GiB，路由专家共 42 GiB，部署在 4 张卡上。暂不计复制的小张量、量化元数据、KV 和 workspace：

第二种每卡少 4.5 GiB，但单次 attention 计算要在 TP 组内协作。第一种把 attention 留给各 rank；遇到远端专家，仍要交换激活。不能把第一种当成 4 套完全独立、互不等待的服务。 副本的缓存、请求队列和共享专家的调度要一起看。

这是容量估算，不是吞吐预测。比较时固定到达流量、输入/输出长度和缓存冷热，记录首 token 延迟、输出间隔、尾延迟与专家负载。若矩阵被切得过小，省显存也可能换来更多等待。

PP 的 KV 在哪里，边界传多少东西？

先限定为普通 decoder、按层做 PP，不叠加 cache offload 或 prefill/decode 分离。某张卡计算哪些层，就保存那些层的 KV；相邻 stage 传递边界激活，不需要每步把全部历史 KV 来回搬。

但“只传激活”不等于“传得很少”。设 hidden size 为 3072，BF16 每元素 2 字节：

这里尚未计额外 residual 张量、元数据、协议和同步。长 prefill 可以分块传，代价是调度与流水线行为随之变化；不能拿 decode 的小包去解释所有场景。

vLLM 的扩展指南建议无 NVLink 的某些配置优先考虑 PP，以减少通信；这不构成“PP 在所有 PCIe 机器上最优”的证明。单请求仍要依次经过各 stage，层间负载不均会让卡空等。若模型单卡已放得下，独立副本、量化后单卡、TP 和 PP 都应在相同流量下比较。分离式 serving 若迁移 KV，则又是不同的通信路径。

再算一个传输下限：假设边界有效带宽为 12 GiB/s，且忽略启动延迟。上表的 48 KiB 至少约需 3.8 微秒，192 MiB 约需 15.6 毫秒。前者很可能由启动和同步开销主导；后者已经不能忽略字节量。这个带宽是算例假设，不是 PCIe 或某款显卡的实测值。

PP 可以减少跨卡协作的频率，但也带来顺序依赖：只有一条请求、一个待生成 token 时，后面的 stage 仍要等前面的结果。增加 microbatch 能让不同请求同时占用不同 stage，却需要足够流量，也可能增加排队和缓存占用。因此“没有 NVLink”只是选型条件之一，还要看链路拓扑、prefill 长度、并发与延迟预算。

为什么请求结束一个，就能补进一个

只看一个理想化 decode 算例：两条已完成 prefill 的请求 A、B，还需生成 2、5 个 token。第三条 C 已准备好，还需 3 个。每轮最多放两条、各生成一个 token，忽略所有额外成本。

从 8 轮到 5 轮，是这个假设下的排程差别，不是实测加速比。真实 prefill、KV 容量和长上下文读写都要计入。Continuous batching 也不是让所有请求同时进来：超出预算时仍要排队、限流或拒绝。

vLLM 和 SGLang 的缓存怎么理解

两者都能做前缀复用，而且默认都开着（vLLM 的 --enable-prefix-caching，SGLang 的 radix cache），不能简单说“vLLM 管显存，SGLang 才管 cache”。今天还能比较的是索引结构、默认粒度和回收策略：

默认值不是通用承诺。实际选择可查 vLLM 的 runner 与异步调度条件、cache 配置，以及 SGLang 的 tree core 回退条件。部署时再核对启动日志里的最终配置。

实现细节可对照已有的缓存生命周期与页对齐算例，其中固定了 vLLM 与 SGLang 源码版本。SGLang 原论文解释了 RadixAttention 的背景；不要把论文发表时的功能边界当成今天的完整产品对比。

例如两个请求共享一份 2,000-token 说明，后面各有 100-token 问题。第二条请求可能少做共同前缀的 prefill，但生成新答案时依然需要使用前缀 KV。省的是重复计算，不是把历史从 attention 里删除。权重、adapter、token IDs、位置与多模态输入也必须兼容；“人看起来文字一样”不是充分条件。

多租户还要设计隔离。共同前缀带来的时间差可能泄露缓存是否命中，不能把缓存机制当成权限机制。vLLM 的 cache salt 说明提供了一种复用隔离手段，SGLang 的 OpenAI 接口也接受 cache_salt；服务端仍要决定可信分组，不能任由客户端声称自己属于别人的组。

HiCache：显存以外，也能存 KV

SGLang HiCache把 KV 放在 GPU、主机内存及存储后端等层次。GPU / 主机层归推理实例使用；跨实例共享要看存储后端及 namespace 的实际配置，不能把两台机器的 RAM 当成天然共享池。vLLM 现在也能这样分层：OffloadingConnector 把算完的完整块先放进 CPU 内存，还可以再接文件、对象存储等二级层，也可以改接 LMCache 或 Mooncake Store。两边默认都不开。

拿一笔假设成本判断：重算某段 prefill 需要 80 ms；把它的 KV 搬回 GPU 要 30 ms，查找与调度另需 5 ms，那复用有机会省约 45 ms。如果传输变成 100 ms，这次复用反而可能更慢。这里把各项按串行相加，只是解释取舍；实际异步重叠要用 trace 测。

所以除了 hit rate，还要看命中的 token 数、搬运量、恢复耗时，以及不命中时额外付了多少代价。很多短前缀命中，未必比少数长前缀命中更有用。

再加速之前，先定位瓶颈

在这次核对的版本中，两套引擎支持的机制有不少重合：分页管理 KV、默认开启的前缀复用、continuous batching 与 chunked prefill、CPU 调度与 GPU 执行重叠、CUDA Graph、EAGLE / MTP / n-gram 推测解码、xgrammar 等结构化输出、TP / PP / DP + EP、P/D 分离与 KV 分层存储，两边都有。但不能因此说两者只差默认参数。调度路径、缓存结构与功能兼容性也会影响取舍：前缀索引一个是块哈希、一个是 radix 树，基础默认粒度是 16 个 token 对 1 个 token，实际要看后端与模型；vLLM 每轮先排 decode，再把 prefill 分块塞进同一批，SGLang 默认有新 prefill 就先跑 prefill 批，要混合得开 --enable-mixed-chunk；vLLM 默认用 torch.compile，SGLang 默认不开；P/D 分离在 SGLang 是内置的 prefill / decode 角色加 router，在 vLLM 走 KV connector，文档仍标为实验性。

比较的仍是固定版本、模型、硬件和功能组合，不是记住“Agent 选这个，高并发选那个”。FSDP 属于训练状态分片，不是这张表里另一个生成引擎。

跑一个有意义的对照

不要只发一条“你好”。准备短问答、长文档、多轮共同前缀、突发流量，以及取消请求；记录输入和实际输出长度分布。各组固定权重、tokenizer、聊天模板、采样与硬件，单列冷启动（cold start）和预热后的结果。

开放到达的压测按计划持续发送，更容易看出排队积压；闭环压测会等前一条完成，系统变慢时实际到达量也会下降。两种都能用，但要说清是哪一种、发了多少、实际完成多少。相同 seed 也不保证不同引擎、batch 或 kernel 的生成逐字一致；另做质量与格式回归。

选型结果应该是一份可重复的记录：版本、配置、输入集、结果和失败样本。接下来读上线与反馈，看这个引擎怎么接进完整服务。

面试里怎样顺着讲，而不是报一串名字

可以先用一小段话把范围说清：

我会先按请求路径拆。应用负责权限、prompt 和流量入口；推理引擎（inference engine）维护请求队列、计算预算和 KV，安排每轮执行；worker 跑模型与底层算子，再把结果交回流式输出。接下来我会用输入输出长度、到达率和延迟目标判断瓶颈，再决定调 batch、加副本，还是做模型或阶段拆分。

这只是组织答案的方式，不是标准话术。随后挑一个自己熟悉的点往下讲：

读源码可以从请求对象一路追到 batch，再到缓存索引与模型执行，不必从第一个文件看到最后一个文件。更广的准备入口见 RE / MLE 与 inference 面试。本篇只做源码核对和教学算例，没有运行两套框架的 GPU benchmark。