企业官网建设流程全解析

Batching 策略演进：从静态 Batch 到 Chunked Prefill

在大模型在线推理服务中，如何将来自不同客户端的并发请求高效打包（Batching），是决定整个服务吞吐量与响应延迟的核心命脉。

在传统的深度学习推理（如图像分类或 BERT 时代）中，请求通常具有固定的输入输出长度，静态批处理能够很好地跑满 GPU。然而对于自回归大语言模型（LLM），用户输入的 Prompt 长度可能从几个字跨越到数万字，生成的回答长度也完全不可预测。

如果依然沿用传统的批处理思维，推理系统就会遭遇严重的算力断崖与请求饥饿。回顾批处理技术的演进历程，才能深刻理解现代推理底座的架构演进逻辑。

+--------------------------------------------------------------------------+ | LLM Batching 策略演进历程 | +--------------------------------------------------------------------------+ | 1. 静态 Batching (Static Batching) | | -> 短请求必须等待最长请求完成，GPU 产生大量 Padding 气泡 | +--------------------------------------------------------------------------+ | 演进 v | 2. 连续批处理 (Continuous Batching / In-flight Batching) | | -> 迭代级别 (Iteration-level) 动态进出，消除生成气泡 | +--------------------------------------------------------------------------+ | 演进 v | 3. 分块预填充与混合调度 (Chunked Prefill & Mixed Scheduling) | | -> 将长 Prompt 切片，与 Decode 混合打包，彻底抹平首字延迟与吞吐毛刺 | +--------------------------------------------------------------------------+

阶段一：静态批处理的“木桶短板”与 Padding 气泡

在静态批处理（Static Batching）模式下：

1. 调度器收集到一组请求（例如 4 个请求），以其中最长的 Prompt 为基准，对其他较短的请求强行填充大量无意义的[PAD]占位符；
2. 整个 Batch 开始执行前向推理；
3. 当某个短请求提前生成完[EOS]终止符后，它无法提前退出！它必须在原地继续执行无意义的空转计算，直到整个 Batch 中生成最长的那一个请求彻底结束，整个 Batch 才能统一返回给客户端。

这种模式带来了双重灾难：

• 算力被 Padding 严重浪费：GPU 把大量浮点算力浪费在了计算[PAD]占位符上；
• 排队延迟雪崩：后面的新请求必须等前一个完整 Batch 全部执行完毕后才能被调度，系统的 P99 响应延迟极度恶化。

阶段二：连续批处理（Continuous Batching）的突破

为了解决静态批处理的短板，Orca 论文与 vLLM 提出了连续批处理（Continuous Batching / In-flight Batching）。

连续批处理将调度的粒度从“整个请求的生命周期”下沉到了单次 Token 生成迭代（Iteration-Level）：

• 每一轮前向传播（Forward Step）结束后，调度器检查是否有请求已经生成了[EOS]；
• 一旦某个请求结束，立刻将其从当前 Batch 中剔除并向客户端返回最终结果；
• 同时，调度器从等待队列中拉取一个新的就绪请求加入当前的 Batch 空位中。

这种动态插拔机制彻底消除了生成阶段的 Padding 气泡，让 GPU 的显存与计算单元始终处于高负载状态，将推理服务的并发吞吐提升了2 ~ 4 倍。

阶段三：Chunked Prefill 终结首字毛刺

虽然连续批处理解决了 Decode 阶段的空转问题，但在面对超长 Prompt 时，它又暴露出一个新的致命矛盾：

当一个长达 8192 Token 的 Prompt 请求进入调度队列时，如果调度器一次性对其执行 Prefill 计算：

• 这个大尺寸 GEMM 算子会独占 GPU 计算单元整整数十毫秒；
• 此时正在处于高速 Decode 阶段的其他 60 个并发请求被迫陷入暂停等待；
• 客户端会明显感知到正在流式打印的字符突然发生长达上百毫秒的顿卡（Inter-Token Latency 尖刺）。

Chunked Prefill（分块预填充）彻底解决了这个痛点：

1. 调度器设定一个全局的算力预算上限（例如单次 Step 最多处理 1024 个 Token）；
2. 如果新请求的 Prompt 长度为 4096，调度器将其切分为 8 个大小为 512 的 Chunk；
3. 在每一轮 Iteration 中，调度器只取该请求的一个 512 Chunk 进行 Prefill，并与当前正在 Decode 的其他请求混合打包成一个 Batch 一起提交给 GPU。

通过将大 Prefill 算子在时间维度上平滑切片，系统不仅彻底抹平了 Decode 流式输出的延迟毛刺，还将首字响应延迟（TTFT）与整体吞吐量优化到了物理硬件的最佳平衡点。