ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

大模型连续批处理与迭代级调度架构演进

大模型连续批处理与迭代级调度架构演进 大模型连续批处理与迭代级调度架构演进在大语言模型LLM推理服务从传统的单次批处理演进到现代化高并发服务的过程中连续批处理Continuous Batching / In-Flight Batching / Iteration-Level Scheduling是将系统端到端吞吐量提升整整 10 倍的最具革命性的架构突破。在早期的标准静态批处理Static Batching模型中服务端将 $N$ 个用户请求打包为一个固定 Batch 一起送入 GPU 执行由于每个用户请求生成的文本长度极不相同例如用户 A 只需生成 10 个 Token而用户 B 需要生成 1000 个 Token用户 A 在第 10 步就已经生成结束但它必须在 GPU 显存中傻傻地等待用户 B 全部生成完毕第 1000 步后整个 Batch 才能整体退出在这期间GPU 的计算单元与显存带宽处于严重的空转与浪费状态。以Orca、vLLM 与 TensorRT-LLM为代表的连续批处理架构彻底打破了“请求级生命周期绑定”的枷锁将调度的最小颗粒度细化到了每一个迭代时间步Iteration Step。-------------------------------------------------------------------------- | 静态 Batching vs 连续批处理 (Continuous Batching) | -------------------------------------------------------------------------- | [传统静态 Batching (请求整体进出 )]: | | 请求 1 (10 步结束): [ 10 步 ] [---------------- 闲置空转 990 步 ----------------] | 请求 2 (1000 步结束): [ 持续生成 1000 步 ] | - 请求 1 占用的显存无法提前释放GPU 算力利用率极度低下 | -------------------------------------------------------------------------- | 升级为迭代级连续批处理 v | [迭代级连续批处理 (Iteration-Level Scheduling )]: | | 步数 1..10: [并发执行: 请求 1 (Step 1..10) 请求 2 (Step 1..10)] | | 步数 11 (切换): - 请求 1 吐出 EOS 结束立即释放显存并返回客户端 | | - 新请求 3 (Prefill) 瞬间无缝插入当前 Batch | | 步数 11..1000: [并发执行: 请求 3 (Step 1..) 请求 2 (Step 11..)] | | - Batch 内部始终保持满载零气泡系统整体吞吐暴增 8 ~ 12 倍 | --------------------------------------------------------------------------1. 迭代级调度器Iteration-Level Scheduler状态机在连续批处理架构中GPU 调度器不再把一个请求当作不可分割的单体而是将整个前向推理循环拆解为单步的step()推进在每一次step()启动前调度器执行精密的仲裁已完成序列淘汰Eviction检查当前 Batch 中是否有请求生成了结束符EOS或达到了最大长度max_tokens。若完成立即将其移出活跃 Batch并将最终结果流式推送给客户端就地释放其占用的物理 KV Cache 显存块新到达请求注入Admission Injection检查等待队列中是否有新的待处理请求。若当前 GPU 显存有足够的空闲 Page立即将新请求的Prefill 阶段注入到当前 Batch 中混合 Batch 前向传播Hybrid Forward Pass在一个单次 GPU 前向计算中同时执行老请求的单步 Decode 与新请求的 Prefill 计算。2. 调度器核心数据结构与 Rust 简化模型use std::collections::VecDeque; pub enum RequestPhase { Prefill, Decode, Finished, } pub struct SequenceTask { pub req_id: u64, pub prompt_tokens: Vecu32, pub generated_tokens: Vecu32, pub phase: RequestPhase, } pub struct ContinuousBatchScheduler { waiting_queue: VecDequeSequenceTask, running_batch: VecSequenceTask, max_batch_size: usize, } impl ContinuousBatchScheduler { pub fn schedule_next_iteration(mut self) - Vecmut SequenceTask { // 1. 清理上一轮已结束的任务 self.running_batch.retain(|task| !matches!(task.phase, RequestPhase::Finished)); // 2. 只要当前运行批次未满从等待队列无缝注入新请求 while self.running_batch.len() self.max_batch_size { if let Some(mut new_task) self.waiting_queue.pop_front() { new_task.phase RequestPhase::Prefill; self.running_batch.push(new_task); } else { break; } } // 3. 返回当前迭代步需要执行的所有活跃任务 self.running_batch.iter_mut().collect() } }3. 生产实测性能爆发在 8x A100-80GB GPU 集群上部署 70B 大模型进行高并发压力测试性能基准对比批处理调度架构平均每 Token 吐字延迟 (ITL)首字生成延迟 (TTFT)单卡综合吞吐量 (Tokens/s)传统静态批处理120 ms (剧烈排队)4.5 秒~ 320 tokens/s迭代级连续批处理22 ms (极致平稳)0.35 秒 (快 12 倍!)~ 3,850 tokens/s 数据表明连续批处理彻底消除了异构长度请求之间的相互牵绊让 GPU 显存与 Tensor Core 算力始终处于 100% 满负荷奔涌状态构成了现代大模型推理基础设施的真正基石。
返回列表