尧图网站建设 
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模式下调度器收集到一组请求例如 4 个请求以其中最长的 Prompt 为基准对其他较短的请求强行填充大量无意义的[PAD]占位符整个 Batch 开始执行前向推理当某个短请求提前生成完[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分块预填充彻底解决了这个痛点调度器设定一个全局的算力预算上限例如单次 Step 最多处理 1024 个 Token如果新请求的 Prompt 长度为 4096调度器将其切分为 8 个大小为 512 的 Chunk在每一轮 Iteration 中调度器只取该请求的一个 512 Chunk 进行 Prefill并与当前正在 Decode 的其他请求混合打包成一个 Batch 一起提交给 GPU。通过将大 Prefill 算子在时间维度上平滑切片系统不仅彻底抹平了 Decode 流式输出的延迟毛刺还将首字响应延迟TTFT与整体吞吐量优化到了物理硬件的最佳平衡点。 Batching 策略演进：从静态 Batch 到 Chunked Prefill
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模式下调度器收集到一组请求例如 4 个请求以其中最长的 Prompt 为基准对其他较短的请求强行填充大量无意义的[PAD]占位符整个 Batch 开始执行前向推理当某个短请求提前生成完[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分块预填充彻底解决了这个痛点调度器设定一个全局的算力预算上限例如单次 Step 最多处理 1024 个 Token如果新请求的 Prompt 长度为 4096调度器将其切分为 8 个大小为 512 的 Chunk在每一轮 Iteration 中调度器只取该请求的一个 512 Chunk 进行 Prefill并与当前正在 Decode 的其他请求混合打包成一个 Batch 一起提交给 GPU。通过将大 Prefill 算子在时间维度上平滑切片系统不仅彻底抹平了 Decode 流式输出的延迟毛刺还将首字响应延迟TTFT与整体吞吐量优化到了物理硬件的最佳平衡点。