In-flight Batching

3 秒看懂

一句话： 不等一个批次全部生成完，谁先”飞完”就立刻让新请求”插队”上 GPU，让算力永远不闲着。

类比： 传统批处理像一桌团餐——所有人吃完才能上下一桌；In-flight Batching 像旋转寿司——空出一个盘子立刻补上一盘新的。

3 分钟产业解释

为什么这项技术重要？

大语言模型（LLM）推理分为两个阶段：

传统静态批处理（Static Batching）的做法：凑齐一批请求，全部跑完 decode 才能上下一批。问题在于——不同请求的生成长度差异极大。短请求早早结束，但 GPU 必须为它做无效的 padding 计算，等最长的那个跑完。GPU 利用率被最慢的请求拖死。

In-flight Batching 的核心创新：以每次 decode 迭代为调度粒度（而非以整个请求为粒度），一旦某个请求生成完毕、释放了算力槽位，立刻从队列中拉入新请求填补。这使得 GPU 上的”有效工作”几乎恒定满载。

产业影响概览

• 吞吐量提升：相同 GPU 集群下，推理吞吐量可提升数倍（具体取决于工作负载长度方差，幅度一般在 2–8× 区间，[业界实测经验值，未统一口径]）
• 单位推理成本下降：每百万 token 的 GPU 成本显著降低
• H100/H200 等高端卡的价值被放大：算力越强，静态批处理的浪费越大，动态调度的收益也越大
• 已成为行业标配：主流推理框架几乎全部实现了这一机制或其变体

15 分钟专家深入

核心机制详解

In-flight Batching 的调度循环可以概括为一个 “检查-驱逐-填充” 的迭代过程：

每一步 decode 迭代:
  1. [检查] 所有正在 decode 的序列，是否有序列已生成 EOS / 达到最大长度？
  2. [驱逐] 将已完成的序列从 GPU 上移除，回收其 KV Cache 槽位
  3. [填充] 从等待队列中选取新请求，执行 prefill（可分块），
            将其 KV Cache 写入回收的槽位，加入当前 decode 批次
  4. [执行] 对当前批次中所有活跃序列执行一次 decode 步

这个循环的关键在于：批次的大小和成员是动态变化的，但 GPU 看到的每一拍都是一个”尽量满载”的计算任务。

与静态批处理的精确对比

静态批处理时间线（请求 A 短，B 中，C 长）:

时间 ──────────────────────────────────────────►
A:  [prefill][decode][decode][PAD ][PAD ][PAD ]  ← 浪费
B:  [prefill][decode][decode][decode][PAD ][PAD ]  ← 浪费
C:  [prefill][decode][decode][decode][decode][decode]

In-flight Batching 时间线:

时间 ──────────────────────────────────────────►
A:  [prefill][decode][decode]→ 完成，释放槽位
B:  [prefill][decode][decode][decode][decode]→ 完成
C:  [prefill][decode][decode][decode][decode][decode]
D:              ← A 的槽位释放后立即插入
E:                          ← B 的槽位释放后立即插入

静态批处理中，A、B 结束后的 GPU 时间被 padding 占据；动态批处理中，D、E 被立即拉入，GPU 上的有效 token 处理密度始终接近峰值。

Prefill 的”抢占”问题与 Chunked Prefill

一个微妙的工程问题：当新请求的 prefill 阶段很长（例如输入 4096 token），它会”霸占”整个迭代步，导致正在 decode 的请求被卡住，尾延迟（Tail Latency）飙升。

解决方案是 Chunked Prefill（分块预填充）：

• 将长 prefill 切分为固定大小的 chunk（如每块 512 token）
• 每个 chunk 与 decode 步交替执行
• 确保 decode 请求的单步延迟不会因新请求插入而产生尖刺

这一思想在 [Sarathi / Sarathi-Serve, Microsoft, 已正式发表于 OSDI 2024] 和 DeepSpeed-FastGen 中被系统化。NVIDIA TensorRT-LLM 的 in-flight batching 实现也支持类似的 chunked prefill 机制。

KV Cache 管理的协同优化

动态批调度使 KV Cache 的生命周期变得不可预测——请求随时插入和退出，传统的预分配连续内存方式会导致严重的内部碎片和外部碎片。

这催生了 PagedAttention（[vLLM, Kwon et al., SOSP 2023]）：

• KV Cache 被组织为固定大小的”页”（如每页 16 token 的 KV 向量）
• 通过页表（Block Table）映射到物理内存，不要求物理连续
• 请求完成时释放其页，立即可被新请求复用
• 内存浪费率从传统方案的 60–80% 降至接近 0（[vLLM 论文数据]）

技术原理

LLM 推理的两阶段计算特征

┌─────────────────────────────────────────────────────┐
│               Prefill（预填充阶段）                    │
│                                                       │
│  输入: [t₁, t₂, ..., tₙ] (N 个 token)               │
│  计算: 所有 token 并行处理，生成完整的 KV Cache         │
│  特征: Compute-bound, 算术强度 O(N)                   │
│  GPU 利用: SM 占用高, Tensor Core 满载                 │
│                                                       │
│  FLOPs ≈ 2 × N × L × d² (简化, L=层数, d=隐藏维度)    │
│  HBM 读取 ≈ L × (12d²) × W_byte (读模型参数,∼L·d²)   │
│  算术强度 ∝ N (随输入长度线性增长)                      │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│               Decode（解码阶段,每步）                  │
│                                                       │
│  输入: 1 个新 token + 已有 KV Cache                    │
│  计算: 计算 Attention + FFN, 生成 1 个输出 token        │
│  特征: Memory-bound, 算术强度 O(1)                     │
│  GPU 利用: SM 大量闲置, 带宽是瓶颈                      │
│                                                       │
│  HBM 读取 ≈ L × (12d²) × W_byte + KV_cache_大小       │
│  (每步都要读取全部模型参数 + 完整 KV Cache)             │
│  FLOPs 仅与单个 token 对应, 算术强度极低               │
└─────────────────────────────────────────────────────┘

调度状态机

                    ┌──────────────┐
                    │   等待队列     │
                    │  (Waiting)    │
                    └──────┬───────┘
                           │ 有空余槽位 且 可调度
                           ▼
                    ┌──────────────┐
            ┌──────│   Prefill     │
            │      │ (可分块执行)   │
            │      └──────┬───────┘
            │             │ prefill 完成
            │             ▼
            │      ┌──────────────┐◄────────────┐
            │      │   Decode      │             │
            │      │  (逐 token)   │── 继续生成 ──┘
            │      └──────┬───────┘
            │             │ 生成 EOS 或达 max_length
            │             ▼
            │      ┌──────────────┐
            │      │   Completed   │ → 返回结果给用户
            │      └──────────────┘
            │
            │  chunk 未完成 → 回到 Prefill
            └──────────────────────────┘

Batch 内的异构执行

一个迭代步中可能同时包含：

1. Decode 请求：正在逐 token 生成的序列
2. Prefill chunk 请求：新进入的序列在做 prefill 分块

调度器需要将这两类请求合理编排到同一个 GPU kernel launch 中。TensorRT-LLM 的做法是通过 padding 和 mask 将异构请求对齐到统一的 tensor shape 上执行；vLLM/SGLang 则通过 PagedAttention kernel 在 kernel 层面直接处理不同长度的序列。

关键公式：批次吞吐量

吞吐量 (tokens/sec) ≈ (B_eff × SPS) 

其中:
  B_eff = 有效批次大小（动态批处理下接近 GPU 最大承载能力）
  SPS   = 单步解码速度 (steps/sec)

静态批处理中:
  B_eff = min(B_max, 可用请求数)  但随请求完成而衰减
  有效 GPU 利用率随时间递减

In-flight Batching 中:
  B_eff ≈ B_max（持续, 只要队列非空）
  有效 GPU 利用率近乎恒定

技术演进史

技术脉络总结： Orca 定义了问题 → vLLM 证明了 KV Cache 管理的关键性 → TensorRT-LLM 将其产品化 → Sarathi/SGLang 解决了 chunked prefill 的细节工程问题 → 2024 年成为行业共识。

技术路线对比

注： 吞吐量倍数为不同工作负载下的经验区间，非单一标准测试结果。

上下游

上游：In-flight Batching 依赖什么？

下游：In-flight Batching 改变了什么？

关键指标

供需与市场数据

需求端：为什么现在最关键？

• LLM 推理成本已超过训练成本：据公开分析，头部 AI 公司推理计算量占比已达 60–80%（[行业共识估算]），推理优化的经济杠杆巨大
• Token 经济兴起：API 按 token 计费，每 token 成本的降低直接转化为利润空间或价格竞争力
• 长上下文趋势：128K–1M token 上下文窗口普及，静态批处理在长上下文下几乎不可用，动态调度成为必需

供给端：谁在提供？

市场规模关联

• 全球 LLM 推理市场（含自建和 API 服务）2024 年估计在 数百亿美元 量级（[多份行业报告交叉估算，口径不一]）
• 推理优化技术（含动态批调度、量化、Speculative Decoding 等）是该市场的效率乘数——不直接产生收入，但决定利润率

代表公司与资本映射

投资逻辑提醒： In-flight Batching 是通用的软件调度技术，不构成某一家公司的独占护城河。其资本映射更多体现在降低推理成本 → 扩大 AI 推理市场总量这一间接逻辑上。

投资逻辑

利好逻辑

1. 推理成本下行 → 需求弹性释放：动态批调度是推理成本下降的关键技术因素之一，低成本使更多应用在经济上可行（Agent、实时翻译、代码补全等），扩大总可服务市场（TAM）
2. GPU 价值最大化：同一块 H100，静态批处理 vs 动态批处理的吞吐量差距可达数倍。对于 GPU 云服务商，这意味着更高的每卡收入
3. 与量化/Speculative Decoding 协同：动态批调度 + FP8 量化 + Speculative Decoding 三者叠加，推理效率可提升一个数量级，使端侧/边缘推理也成为可能

风险与局限

1. 技术扩散快，非护城河：该技术已被所有主流框架开源实现，不存在排他性竞争优势
2. 边际收益递减：从静态到动态的提升是”从 0 到 1”，但进一步优化（chunked prefill、更激进的调度）的增量收益在递减
3. 硬件迭代可能颠覆：如果未来硬件的 prefill 和 decode 速度差异被消除（如通过专用硬件），调度优化的必要性可能降低

常见误读纠偏

❌ 误读 1：“In-flight Batching 就是传统的 micro-batching”

纠偏： 传统 micro-batching（如 PipeDream 中的流水线 micro-batch）是为了掩盖通信延迟，批的大小在编译时确定，运行时不变。In-flight Batching 的核心是运行时动态插入和驱逐请求，批次成员在每一步迭代都可能变化。两者解决的问题域完全不同。

❌ 误读 2：“连续批处理能降低单个请求的延迟”

纠偏： 连续批处理的核心收益是系统吞吐量（tokens/sec），而非单个请求延迟。事实上，如果为了吞吐量而将批次填得很满，单个请求的 ITL（inter-token latency）反而可能上升——因为每个 decode 步需要等待更多序列一起完成计算。正确的理解是：在给定延迟 SLA 约束下，连续批处理能最大化吞吐量；或在给定吞吐量目标下，最小化所需 GPU 数量。

❌ 误读 3：“动态批处理对 prefill 和 decode 效果相同”

纠偏： 动态批处理的收益主要体现在 decode 阶段——因为 decode 是逐 token 的、持续时间长的阶段，不同请求的长度差异主要在 decode 阶段体现。Prefill 阶段是一次性计算，本身不太需要”动态调度”。真正的挑战在于：如何在不停止 decode 的前提下，将新请求的 prefill 插入——这才是 chunked prefill 要解决的问题。

❌ 误读 4：“有了 PagedAttention 就不需要 In-flight Batching”

纠偏： PagedAttention 解决的是 KV Cache 内存管理问题（减少碎片、提高内存利用率），In-flight Batching 解决的是 GPU 计算调度问题（减少空闲时间、提高算力利用率）。两者互补而非替代。实际部署中，最优方案是两者结合。

学习路径

入门（1–2 小时）

1. 阅读 vLLM 博客文章中的连续批处理图解（vllm.ai 博客）
2. 理解 LLM 推理的 prefill / decode 两阶段特征

进阶（4–8 小时）

3. 精读 Orca 论文：“Orca: A Distributed Serving System for Transformer-Based Generative Models” [OSDI 2022]
4. 精读 vLLM 论文：“Efficient Memory Management for Large Language Model Serving with PagedAttention” [SOSP 2023]
5. 对比阅读 TensorRT-LLM 文档中 In-flight Batching 章节

深度（1–2 周）

6. 研读 Sarathi / Sarathi-Serve 论文（OSDI 2024，关于 chunked prefill 的调度优化）
7. 阅读 SGLang 论文（RadixAttention 与 prefix caching 的协同）
8. 动手实践：用 vLLM 部署一个模型，对比开启/关闭 continuous batching 的吞吐量差异（--disable-continuous-batching 参数）
9. 阅读 DeepSpeed-FastGen 的 SplitFuse 白皮书

推荐论文清单

一句话总结

In-flight Batching 是 LLM 推理调度的”旋转寿司”模式——以迭代为粒度动态插拔请求，使 GPU 算力从”等人齐开饭”变成”即来即服务”，已成为所有主流推理引擎的默认调度策略，是推理成本下行的核心技术因素之一。

延伸阅读与来源

• Orca 论文：Gyeong-In Yu et al., “Orca: A Distributed Serving System for Transformer-Based Generative Models,” OSDI 2022
• vLLM 论文：Woosuk Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention,” SOSP 2023
• TensorRT-LLM 官方文档：NVIDIA GitHub (github.com/NVIDIA/TensorRT-LLM) — In-flight Batching 章节
• DeepSpeed-FastGen：Microsoft DeepSpeed 博客, “DeepSpeed-FastGen: High-throughput Text Generation for LLMs via MII and DeepSpeed-Inference”
• Sarathi-Serve：Amey Agrawal et al., “Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve,” OSDI 2024
• SGLang：Lianmin Zheng et al., “SGLang: Efficient Execution of Structured Language Model Programs,” 2024
• FlashAttention：Tri Dao et al., “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness,” NeurIPS 2022

来源标注说明： 本文中具体的性能倍数（2–8×）为业界广泛引用的经验区间，非单一标准化基准测试结果。各框架的实际性能取决于模型架构、序列长度分布、GPU 型号、量化精度等多重因素，建议以自行实测为准。