vLLM--连续批处理（Continuous Batching）
连续批处理（又称动态批处理 / 迭代级批处理）是 vLLM 高吞吐量的第二大核心支柱，与 PagedAttention 分块显存管理共同构成了 vLLM 的性能基础。
传统静态批处理的致命缺陷：1.一次性收集固定数量的请求，打包成一个批次
2.同时处理该批次的所有请求
3.必须等待批次内所有请求全部生成结束，才能处理下一批次
连续批处理的核心思想：不等整个批次结束，只要有任何一个请求生成结束，就立刻将新请求插入到这个空位上，让 GPU 永远不闲着。
完整工作流程：
1.预填充阶段：将多个新请求打包成一个批次，多个请求的 Prompt 会被拼接成一个大张量，一次性计算它们的 Prompt KV-Cache（计算密集型）
2.解码阶段：逐 Token 生成，每生成一个 Token 就执行一次调度（内存密集型）
解码阶段调度循环（每步执行）
1. 检查运行队列，将已生成结束的请求移至完成队列 2. 释放完成请求占用的所有物理块，归还至空闲块池 3. 从等待队列中取出尽可能多的新请求（满足：有空闲块 + 未超最大并发） 4. 对新请求执行预填充，计算其Prompt KV-Cache 5. 将新请求与未完成的旧请求合并成新的批次 6. 用新批次生成下一个Token 7. 重复上述步骤vLLM 调度器：连续批处理的大脑
三个核心队列：
- 等待队列：所有新到达的请求在此排队
- 运行队列：当前正在被处理的请求
- 完成队列：已生成结束的请求
设计细节
- 预填充与解码分离：预填充是计算密集型，解码是内存密集型；将多个新请求的预填充打包成大批次执行，最大化计算利用率
- 基于物理块数的调度：不是按请求数量调度，而是按空闲物理块数量调度；每个新请求需要的块数 =
ceil(Prompt长度 / block_size)；只要空闲块数足够，就可以调度该请求 - 抢占式调度（Swap 机制）：显存不足时，将低优先级请求的 KV-Cache 换出到 CPU 内存；有空闲显存时，再将其换回 GPU 继续处理；可支持远超 GPU 显存容量的并发数