Sealessland logo Sealessland

vLLM

vLLM 数据流与调度

把请求进入、continuous batching、PagedAttention、prefill/decode 差异，以及经典 decoder-only Transformer 主干放到一页里，方便随时回看。

模型结构图 调度轮次 KV Cache

Workflow

完整链路

1

请求入口

Request entry

Client / SDK

OpenAI API、LangChain、HTTP client 最终都会变成同一类生成请求。到 engine 之前，请求里已经带上 prompt、sampling params、max tokens、stop words、streaming 等元信息。

API Server -> Engine
生成请求 → API Server → 请求队列

服务层负责网络协议、参数校验、序列化和返回格式，engine 只管调度和执行。这样接入层不会把 GPU 绑死在单个请求上。

↓
2

调度与批处理

Scheduling & batching

Scheduler

核心状态至少有 waiting、running，以及必要时的 swapped。调度器每轮都要回答两个问题：谁能先拿到 block，谁继续保住当前 decode 的位置。

Continuous batching
Req A [10] → Req B [5] → Req C [8] → Req D [12]

不是等整批结束再换下一批，而是每轮 decode 后立刻重组 batch。老请求继续 decode，新请求只要还有预算就能插进来做 prefill。

Execution plan

本轮 batch size、token budget、显存预算、是否复用 CUDA graph，都会在这里定下来。真正限制并发的不是“请求数”，而是本轮能塞下多少 token 和 KV block。

↓
3

内存管理

PagedAttention KV cache

Page table

Page Table

Req A 页 1,2,3Req B 页 4Req C 页 5,6

GPU Memory

Page A [D,L,K,V]Page B [D,L,K,V]Page C [D,L,K,V]

逻辑 token 连续，但物理 KV block 不必连续，映射关系交给 block table。请求只关心“第 i 段历史在哪个 block”，不要求整个上下文是一整块连续显存。

↓
4

模型执行

GPU worker

GPU worker pipeline
Token Embedding → 读取 KV Cache → Transformer Layers → 生成 Token

真正的算力热点在这里。prefill 会把整段 prompt 过一遍 decoder stack；decode 只推进最后一个 token，但每层 attention 都要回头读历史 KV。

执行特性

prefill 更像大矩阵吞吐，decode 更像小步快跑。prefill 常见瓶颈是算力吞吐，decode 更容易被 KV 访存、kernel launch 和 batch 形状变化拖住。

↓
5

输出处理

Output processing

Logits 后处理

temperature、top-k / top-p、repetition penalty、bad words 过滤都在这里发生。到这一步，模型执行已经结束，剩下的是从 logits 选 next token。

采样策略
Greedy → Random → Beam Search

不同 sampling 策略决定结果的稳定性、多样性和额外开销。线上服务最常见的是 greedy 或随机采样，beam search 更适合离线场景。

状态更新与流式返回

next token 确认后会写回新 KV、更新 token ids、检查 stop condition。请求结束时对应的 block 会被回收，空出来的位置立刻能给 waiting queue 里的新请求。

Architecture

经典 Transformer Block 风格总览

Input Tokens prompt tokens / last token
Token Embedding token + position
N × Decoder Block
RMSNorm
Causal Self-Attention
Residual Add
RMSNorm
MLP / SwiGLU
Residual Add
Final Norm hidden state normalization
LM Head project to logits
Sampler top-k / top-p / temperature
Next Token stream and loop
Scheduler Gate 决定哪些 request 进入本轮 decoder
Block Table logical token index 对应 physical KV blocks
Paged KV Cache prefill 写入整段 K/V；decode 反复读取旧 K/V 并追加新 K/V。
Prefill

整段 prompt 一次通过 decoder stack，批量建立首批 KV。

Decode

每轮只新增一个 token，但会频繁读取历史 KV 并追加新 KV。

经典差异

prefill 更偏吞吐；decode 更偏缓存组织、调度补位和低延迟响应。

Flow

vLLM 主链路

Request ingress

请求进入

请求先被切成 token，并带着 sampling params 进入 engine；这时系统已经开始估算 prefill 成本。

  • Tokenizer 把 prompt 变成 token 序列。
  • 长 prompt 往往意味着更重的 prefill 负载。
  • 请求不会立刻独占 GPU，而是先进入 waiting queue。

Continuous batching

连续批处理

vLLM 每轮 decode 后都能重组 batch，而不是等整批完全结束再处理下一批。

  • running queue 优先保持 decode 连续推进。
  • waiting queue 会在显存可用时立刻补位。
  • 这样 GPU occupancy 更稳，尾延迟更小。

PagedAttention

分页 KV Cache

KV cache 被切成固定 block，逻辑 token 连续，物理显存不需要连续。

  • block table 负责 token 到 block 的映射。
  • 回收粒度从“大块”降到“页级别”。
  • prefix reuse 和长上下文服务更容易做。

Decoder execution

GPU 执行

真正的高密度计算发生在 decoder block；attention 会读历史 K/V，MLP 产出新 hidden state。

  • prefill 更像大矩阵吞吐。
  • decode 每轮只算一个新 token，但要反复读取旧 KV。
  • kernel 调度效率决定整个服务上限。

Streaming

流式输出

采样得到 next token 后，结果立刻回传客户端，同时新 KV 也被写回 cache。

  • sample 后马上可以 stream。
  • 完成请求释放 block，让 waiting queue 补位。
  • 整个系统形成 steady-state pipeline。

Scheduler

连续批处理轮次

T0

Running: A prefill, B decode, C decode

Waiting: D, E

系统优先保住已有 decode 的连续性，同时把 A 的 prompt 吃进去建立首批 KV。

T1

Running: A decode, B decode, D prefill

Waiting: E, F

B 还没结束，不能因为 D 新来就整批重排；D 只是在本轮剩余预算里补位。

T2

Running: A decode, D decode, E prefill

Waiting: F

A 可能接近结束，空出来的 block 和 token budget 让 E 可以进场建立自己的 KV。

T3

Running: D decode, E decode, F prefill

Waiting: queue 逐步清空

steady state 下，decode 在前面连续推进，新请求在后面持续补位，这就是 continuous batching 的实际形状。

为什么不是静态 batch

静态 batch 必须等一整批都结束才能换下一批，短请求会被长请求拖住。continuous batching 的核心就是每轮 decode 后都允许重组。

为什么 decode 优先级高

decode 已经在生成中，停它会直接伤害 token latency。prefill 通常更重，但它更容易被切成“插空补位”的工作。

实际约束是什么

不是单纯看请求数量，而是看本轮 token budget、空闲 KV blocks、显存余量，以及当前 batch 形状是否适合复用已有执行计划。

Memory

Paged KV Cache

B0 prefix reused
B1 prefix reused
B2 active
B3 active
B4 active
B5 new
B6 new
B7 new

vLLM 不是把一个请求的 KV 当成一整块连续大数组来维护，而是把历史拆成多个固定大小的 block，再通过 block table 把逻辑 token 顺序映射到这些离散 block 上。

1. Prefill 落盘

prefill 结束后，请求历史 token 对应的 K/V 会被按 block 写入 cache。长 prompt 不会强行占成一段连续显存，而是拆成多个固定大小的块。

2. Decode 查表

下一轮 decode 来了，attention 先根据 block table 找到这个请求历史 token 分别落在哪些 block，再把这些 K/V 组织成当前计算需要的视图。

3. 新 token 追加

本轮生成出一个新 token 后，它对应的新 K/V 会被追加到当前末尾 block；如果末尾 block 满了，就再申请一个新 block。

4. 请求结束回收

请求完成时只回收它占用的 block。别的请求即使夹在中间，也不用整体搬迁，所以碎片和搬运成本都更可控。

连续大数组思路

把一个请求的所有 KV 当成线性连续内存。好处是概念直观，坏处是扩容、回收、共享前缀都容易牵一发而动全身。

PagedAttention 思路

把 KV cache 看成很多固定大小的 block，请求只维护“逻辑位置 -> block id”的映射。扩容是加 block，不是重搬整段历史。

Block table

逻辑序列看到的是 token 顺序，底层实际拿到的是 block id 列表。attention 通过映射关系去找 K/V，而不是按连续地址整段扫描。

Prefix reuse

两个请求共享同一段前缀时，可以复用已有 block，不必把 prefix 再算一遍再存一遍。

回收方式

请求结束时只需要回收自己占用的 block，不需要搬迁别的请求的 KV，这也是它比连续大缓冲区更稳的地方。

vLLM 这套链路最后在优化什么

统一调度

请求调度与批处理

Token 并行

token 级别连续推进

PagedAttention

KV cache 分页管理

GPU 并行

算力与访存同时优化

存算发分离

接入、执行、输出解耦

高吞吐 / 低延迟

服务侧最终目标