Continuous Batching：为什么 batch 越大不一定越好
主线：10 个生成请求进 GPU——Static Batching 被最慢的 D(200 token) 拖死（batch 利用率 1/10），Continuous Batching 每个 decode step 重新组 batch：谁完成谁走、谁新到谁进、GPU 不等人，公开资料常给 10-20 倍吞吐提升（倍数取决于长度分布，见 ⑫）。左边 GPU batch 面板实时看每个 step 谁进谁出。
1x2x
待播放
三级进化：Static（等最慢）→ Dynamic（组好锁死）→ Continuous（每步重组）→ Chunked Prefill → batch 恒满（倍数随长度分布）
Chunked Prefill
保护 decode TTFT
光点 = 当前阶段 · 核心：batch 级调度 → step 级调度（~10ms）
GPU Batch 面板（实时进出）Step: —
就绪点 ▶ 播放，看 GPU batch 怎么从"等人"变"不等人"。推理调度
⚡ 运行时动作：正在发生什么💡 知识讲解：为什么这么设计
知识点一句话总结：Continuous Batching 的核心是把调度粒度从"一整批推理"精细到"一个 decode step（~10ms）"——每个 step 后重新组 batch（完成的退出、新的加入、OOM 的 swap 出去），消灭了静态批处理的"等人"时间（Static 的吞吐 = batch_size / max(sequence_lengths)，被最慢的拖死），吞吐提升常引 10-20 倍——但这个倍数没有普适性：它的分母是"静态批处理因等待最长序列而空转的时间占比"，长度分布越偏斜越高，长度接近时趋近 1，必须按自己的负载校准；Chunked Prefill 把长 prompt 切成 chunk 和 decode 混跑，保护 TTFT（max_num_batched_tokens 设 8192 或更高）；代价：调度器复杂度（μs 级）、Padding 开销、饥饿（需优先级队列）。