题目
vLLM 等推理引擎采用 Continuous Batching 提升吞吐。它与传统 static / dynamic batching 有何不同?
参考答案
Static Batching(静态批处理):
- 请求凑齐一个 batch 后开始处理,等所有请求都生成完才结束该 batch。
- 痛点:batch 内各请求长度差异大,短请求生成完后只能空等长请求,GPU 利用率低。
Dynamic Batching(动态批处理):
- 凑批过程中允许新请求加入,但仍是”等整批完成”思路,缓解而非根治空等。
Continuous Batching(连续批处理,iteration-level scheduling):
- 调度粒度从”请求级”细化到单步迭代级(每个 decode step 都可调整 batch)。
- 某请求一旦生成结束(遇 EOS),立即从 batch 移除,腾出槽位给等待中的新请求。
- 新请求可在任意 step 加入 batch,无需等当前批次结束。
对比示例:4 个请求,长度分别为 50/80/120/200 token。
- Static:4 个请求全程占 GPU,短请求生成完后空等,总耗时 = 200 step。
- Continuous:短请求结束即退出,长请求继续,腾出槽位接新请求——GPU 始终满载,吞吐显著提升。
与 PagedAttention 配合:Continuous Batching 解决”请求来去自由”,PagedAttention 解决”显存零散碎片”,二者是 vLLM 高吞吐的两大支柱。
为何能提升吞吐:
- 消除空等:短请求不拖累长请求。
- 槽位复用:完成即退出,新请求立即接入,GPU 不闲着。
- 更高并发:同等显存可同时服务更多请求。
关键参数(vLLM):
max_num_seqs:单 batch 最大并发请求数(如 256)。max_num_batched_tokens:单 step 处理的最大 token 数。
面试加分点:
- 指出 Continuous Batching 来自 Orca 系统(OSDI 2022),是相对 static batching 的范式跃迁。
- 它解决的是吞吐,对单请求延迟无直接改善(甚至略增调度开销),是吞吐-延迟权衡中偏向吞吐的选择。
出处:vLLM 文档、Orca 论文《Orca: A Distributed Serving System for Transformer-Based Generative Models》(Yu et al., OSDI 2022)。
内容来源
整理自 vLLM 文档与 Orca 论文(Continuous Batching 原始出处)
本站内容整理自公开面经与开源仓库,仅供学习交流,严禁杜撰。