一、为什么需要 Continuous Batching1.1 三种 Batching 策略对比① 静态批处理 (Static Batching) — 传统方式 ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ ← 生成长一直占着 │ Req B: [Prefill][D][D] │ ← 早就结束了slot 空着 │ Req C: [Prefill][D][D][D] │ ← 也结束了 │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → B/C 结束后必须等 A 完成才能处理新请求 → GPU 利用率极低大量 slot 空转 ② 动态批处理 (Dynamic Batching) — TGI/DeepSpeed ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ │ Req B: [Prefill][D][D] │ │ Req E: [Prefill][D][D][D] │ ← B 结束后 E 等到下一个 iter │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → 只在 iteration 边界检查请求状态 → 粒度还是太粗E 要等 1 个 iteration ③ 连续批处理 (Continuous Batching) — vLLM ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ │ Req B: [Prefill][D][D] │ │ Req E: [ ][Prefill][D][D][D][D] │ ← B 结束的下一 step 立刻插入 │ Req C: [Prefill][D][D][D] │ │ Req F: [ ][ ][Prefill][D][D] │ ← C 结束后 F 立刻插入 │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → 每个 step 都可以动态加入/移除请求 → GPU slot 始终被有效请求占满1.2 吞吐量对比Batching 策略并发 128 时吞吐量GPU 利用率静态批处理~1200 t/s25%-35%动态批处理~2500 t/s50%-60%连续批处理~5800 t/s85%-95%二、Continuous Batching 的核心机制2.1 迭代调度的本质Continuous Batching 的核心是一个迭代循环。每个 iteration即每生成一个 token都是一个独立的调度决策点2.2 三队列模型class Scheduler: def __init__(self, ...): # 三个核心队列 self.waiting: Deque[SequenceGroup] deque() # waiting: 新到达的请求尚未做 Prefill # 只有 Prefill 后才能开始 Decode self.running: Deque[SequenceGroup] deque() # running: 正在 Decode 的请求 # 每个 step 为它们各生成一个 token self.swapped: Deque[SequenceGroup] deque() # swapped: 被 swap out 到 CPU 的请求 # 显存不足时的临时中转站 请求生命周期: arrived → [waiting] → Prefill → [running] → Decode... → finished ↓ 显存不足 → [swapped] → 显存恢复 → [running]三、调度循环核心3.1 schedule()每步的调度决策class Scheduler: def schedule(self) - SchedulerOutputs: 每个 iteration 调用一次 决定这个 step 处理哪些请求 scheduler_outputs SchedulerOutputs() # ── Step 1: 处理已完成的请求 ── # 上一 step 生成的 token 可能触发 EOS # 完成的请求从 running 移出释放 KV Cache Block self._schedule_finished_seqs() # ── Step 2: 检查显存压力必要时抢占 ── if self._check_memory_pressure(): self._preempt_running_seqs() # ── Step 3: 从 waiting 队列补充新请求 ── # 这是 Continuous Batching 的核心 # 每 step 都检查能否加入新请求 self._schedule_waiting_seqs() # ── Step 4: 构建 batch ── # 将 running 队列中的请求组成一个 batch # 同时可能包含 waiting 队列中新请求的 Prefill self._build_batch(scheduler_outputs) return scheduler_outputs3.2 Continuous Batching 的精髓每步都可以插入新请求def _schedule_waiting_seqs(self): 关键逻辑每个 step 都尝试从 waiting 队列拉取新请求 这就是 Continuous 的含义 — 不是等到整个 batch 完成才换人 而是每个 token 生成完后都可以换人 # 计算当前显存余量 free_blocks self.block_manager.get_num_free_gpu_blocks() while self.waiting: seq_group self.waiting[0] # 判断显存是否足够做 Prefill required_blocks self._get_prefill_blocks(seq_group) if required_blocks free_blocks: break # 显存不够停止补充 # 从 waiting 移到 running self.waiting.popleft() self.running.append(seq_group) free_blocks - required_blocks # 标记这个请求这个 step 做 Prefill seq_group.set_schedule_type(ScheduleType.PREFILL)3.3 两种抢占策略当显存不足时vLLM 需要从 running 队列中抢占请求释放显存def _preempt_running_seqs(self): 显存不足时从 running 队列尾部抢占请求 两种策略SWAP 或 RECOMPUTE while self._check_memory_pressure() and self.running: # 取最后加入的请求FIFO 的反面LIFO 抢占 seq_group self.running.pop() if self.preemption_mode PreemptionMode.SWAP: # 策略 A: SWAP — 将 KV Cache 拷贝到 CPU self.block_manager.swap_out(seq_group) self.swapped.append(seq_group) elif self.preemption_mode PreemptionMode.RECOMPUTE: # 策略 B: RECOMPUTE — 直接丢弃 KV Cache # 下次恢复时重新做 Prefill self.block_manager.free(seq_group) self.waiting.appendleft(seq_group) # 放回 waiting 头部 策略 A: SWAP running → [GPU KV Cache] 拷贝到 CPU → swapped 恢复: swapped → [CPU] 拷贝回 GPU → running 优点: 恢复快只需拷贝不需重新计算 缺点: 需要额外 CPU 内存 策略 B: RECOMPUTE running → 丢弃 [GPU KV Cache] → waiting 恢复: waiting → 重新 Prefill → running 优点: 不占 CPU 内存 缺点: 恢复慢要重新算 Prefill策略恢复延迟内存需求适用场景SWAP低~5msCPU 内存 GPU KV Cache 大小显存压力大但不极端RECOMPUTE高~200ms无显存极端不足3.4 Prefill 和 Decode 的分离vLLM 的一个重要优化是Prefill-Decode 分离调度。一个 iteration 要么全做 Prefill要么全做 Decodedef _build_batch(self, scheduler_outputs): 判断这个 step 做 Prefill 还是 Decode # 如果有新请求从 waiting 进入这个 step 做 Prefill has_new_seqs any( sg.is_prefill() for sg in self.running ) if has_new_seqs: # Prefill step: 处理新请求的完整输入 # Prefill 是计算密集型GPU 利用率接近 100% batch self._build_prefill_batch() else: # Decode step: 为所有 running 请求各生成一个 token # Decode 是访存密集型GPU 利用率可能只有 30% # 这就是为什么 Continuous Batching 重要: # Decode step 可以塞入更多请求来提高 GPU 利用率 batch self._build_decode_batch()为什么要分离因为 Prefill 和 Decode 的计算特性完全不同Prefill首 token 生成: 输入: prompt几百到几千 token 计算: 并行处理所有输入 token GPU 利用率: ~95% (compute-bound) 耗时: 50-200ms Decode后续 token 生成: 输入: 上一步生成的 1 个 token 计算: 只处理 1 个 token GPU 利用率: ~20-30% (memory-bound) 耗时: 5-20ms → Decode 时 GPU 大量空闲 → Continuous Batching 利用这些空闲周期塞入更多请求四、连续批处理的数学模型4.1 吞吐量建模吞吐量 (batch_size × 1 token) / (decode_time_per_step) 传统静态批处理: batch_size 32 (固定) 每步所有 32 个请求都 decode包括已完成的空 slot decode_time ≈ 15ms (固定) 但实际有效请求平均只有 18 个 吞吐量 18 / 0.015 1200 t/s 连续批处理: batch_size 动态变化 (20-128) 每步所有 running 请求都 decode都是有效请求 decode_time ≈ 15ms (固定) 平均有效 batch_size ≈ 87 吞吐量 87 / 0.015 5800 t/s4.2 GPU 利用率建模Decode step 的 GPU 时间分解: ┌─────────────────────────────────────────┐ │ Kernel 执行 4ms (27%) ← 计算 │ │ 显存读取 10ms (67%) ← 访存 │ │ Kernel Launch 1ms (6%) ← 开销 │ └─────────────────────────────────────────┘ Total: 15ms GPU SM 利用率 ≈ 27% → 浪费了 73% 的 GPU 计算能力 Continuous Batching 的对策: 把更多请求塞进同一个 step → 显存读取量增加 (每个请求多读 KV Cache) → 但 Kernel 执行可以 batch 化 → SM 利用率提升到 60-80%五、实测数据5.1 测试环境GPU: NVIDIA A100 80GB × 1 模型: Llama-2-7B-Chat (FP16) vLLM 版本: v0.6.0 输入长度: 512 tokens (固定) 输出长度: 128 tokens (固定)5.2 不同并发下的吞吐量┌──────────────┬──────────┬──────────┬──────────┬──────────┐ │ 并发数 │ 静态 Batch│ 动态 Batch│ 连续 Batch│ 提升 │ ├──────────────┼──────────┼──────────┼──────────┼──────────┤ │ 1 │ 42 t/s │ 48 t/s │ 48 t/s │ 1.14x │ │ 8 │ 180 t/s │ 520 t/s │ 520 t/s │ 2.89x │ │ 16 │ 280 t/s │ 1050 t/s │ 1050 t/s │ 3.75x │ │ 32 │ OOM │ 2100 t/s │ 2100 t/s │ N/A │ │ 64 │ OOM │ 3500 t/s │ 3800 t/s │ N/A │ │ 128 │ OOM │ OOM │ 5800 t/s │ N/A │ └──────────────┴──────────┴──────────┴──────────┴──────────┘关键发现低并发1-8三种策略差距不大瓶颈在计算而非显存中并发16-64动态和连续批处理远超静态高并发128只有 Continuous Batching 能扛住吞吐量达 5800 t/s5.3 变长输出场景的对比真实场景中请求的输出长度是不均匀的这最能体现 Continuous Batching 的价值测试: 100 个请求输出长度分布 [32, 256, 64, 512, 128, ...] 静态批处理 (batch32): Step 0-31: 所有 32 个请求同时 Decode Step 32: Req 3 完成 (32 token) Step 64: Req 7 完成 ... Step 512: 最后一个请求完成 (512 token) → 大量 step 中有效请求远小于 32 连续批处理: Step 0-31: 32 个请求 Decode Step 32: Req 3 完成 → 从 waiting 立刻拉入 Req 33 Step 64: Req 7 完成 → 拉入 Req 34 ... → batch 始终保持满载场景静态 Batch 吞吐连续 Batch 吞吐提升等长输出 (128)1200 t/s2100 t/s1.75x变长输出 [32-512]650 t/s3200 t/s4.9x极端变长 [16-1024]380 t/s2900 t/s7.6x结论输出越不均匀Continuous Batching 的优势越明显。六、调度器实战代码6.1 完整推理循环from vllm import LLM, SamplingParams # 初始化 — vLLM 自动开启 Continuous Batching llm LLM( modelmeta-llama/Llama-2-7b-chat-hf, tensor_parallel_size1, gpu_memory_utilization0.90, max_model_len4096, # 调度相关参数 block_size16, # PagedAttention 块大小 enable_prefix_cachingTrue, # 前缀缓存优化 swap_space4, # CPU swap 空间 (GB) ) # 模拟变长请求 prompts [ 写一首关于秋天的诗, # 短输出 详细解释 PagedAttention 的工作原理, # 长输出 什么是 RESTful API, # 中等输出 用 Python 实现快速排序, # 中等输出 总结一下 TCP 三次握手, # 短输出 ] * 50 # 250 个请求 sampling_params SamplingParams( temperature0.7, top_p0.9, max_tokens512, ) # vLLM 内部自动 Continuous Batching # 250 个请求会被动态调度不需要手动分批 outputs llm.generate(prompts, sampling_params) # 统计吞吐量 total_tokens sum( len(o.outputs[0].token_ids) for o in outputs ) # vLLM 会打印吞吐量统计: # Throughput: 5234.5 tokens/s6.2 流式输出场景from vllm import LLM, SamplingParams llm LLM(modelmeta-llama/Llama-2-7b-chat-hf) # 流式生成 — Continuous Batching 在流式场景同样生效 sampling_params SamplingParams( temperature0.7, max_tokens512, streamTrue, # 流式输出 ) # 多个请求并发流式 for output in llm.generate(prompts, sampling_params, use_tqdmFalse): for chunk in output: print(chunk.outputs[0].text, end, flushTrue)七、性能调优建议7.1 最大化吞吐量的配置llm LLM( model..., gpu_memory_utilization0.92, # 尽量用满显存 max_num_seqs256, # 最大并发数影响 batch 上限 max_model_len4096, block_size16, swap_space4, # 给 swap 留空间 # 吞吐量优化: enforce_eagerFalse, # 用 CUDA Graph 减少 launch 开销 enable_prefix_cachingTrue, # 前缀缓存 max_num_batched_tokens8192, # 单 step 最大 token 数 )7.2 参数对吞吐量的影响参数推荐值影响gpu_memory_utilization0.90-0.92越高 → 可支持更多并发 → 吞吐越高max_num_seqs128-256并发上限受显存限制max_num_batched_tokens8192单 step token 上限block_size16影响显存碎片和 kernel 效率swap_space4-8 (GB)Swap 策略的缓冲空间enable_prefix_cachingTrue共享前缀的请求加速7.3 延迟 vs 吞吐量的权衡追求延迟 (交互式场景): max_num_seqs 16-32 # 小 batch每个请求更快 max_num_batched_tokens 2048 → 牺牲吞吐量换取低延迟 追求吞吐量 (批量推理): max_num_seqs 128-256 # 大 batch max_num_batched_tokens 8192 → 牺牲延迟换取高吞吐量八、总结Continuous Batching 的三个核心贡献每步动态调度每个 token 生成后都可以加入/移除请求GPU slot 不空转Prefill-Decode 分离利用 Decode step 的 GPU 空闲周期塞入更多请求抢占与恢复显存不足时优雅降级Swap 或 Recompute 都能恢复优化点贡献的吞吐量提升连续批处理vs 静态3-5xPrefill-Decode 分离1.5-2x抢占与恢复防 OOM 崩溃可用性保障这三者加上 PagedAttention 的显存优化共同构成了 vLLM 5800 t/s 的技术基石。下一篇预告下一篇进入大数据领域对 Iceberg、Hudi、Delta Lake 三大数据湖格式进行深度压测对比在写入吞吐、读取性能、Time Travel、Compaction 效率四个维度横评附选型决策树。往期回顾AI 推理优化系列—vLLM PagedAttention 解析显存利用率从 40% 提升到 90% 的秘密。llama.cpp Q4 量化原理拆解10GB 显存跑 70B 模型的秘密。Kafka acks 机制性能实测acksall 在百万级吞吐下的延迟代价有多大。GPTQ vs AWQ vs GGUF三大量化方案性能与精度横评。Kafka 深度解剖 2消费者组再均衡 Rebalance 全流程。觉得有帮助请点赞收藏。关注专栏「AI大模型大数据硬件编程」每周更新大模型推理部署的深度实战内容。
一、为什么需要 Continuous Batching1.1 三种 Batching 策略对比① 静态批处理 (Static Batching) — 传统方式 ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ ← 生成长一直占着 │ Req B: [Prefill][D][D] │ ← 早就结束了slot 空着 │ Req C: [Prefill][D][D][D] │ ← 也结束了 │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → B/C 结束后必须等 A 完成才能处理新请求 → GPU 利用率极低大量 slot 空转 ② 动态批处理 (Dynamic Batching) — TGI/DeepSpeed ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ │ Req B: [Prefill][D][D] │ │ Req E: [Prefill][D][D][D] │ ← B 结束后 E 等到下一个 iter │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → 只在 iteration 边界检查请求状态 → 粒度还是太粗E 要等 1 个 iteration ③ 连续批处理 (Continuous Batching) — vLLM ┌──────────────────────────────────────────────┐ │ Req A: [Prefill][D][D][D][D][D][D][D][D][D][D] │ │ Req B: [Prefill][D][D] │ │ Req E: [ ][Prefill][D][D][D][D] │ ← B 结束的下一 step 立刻插入 │ Req C: [Prefill][D][D][D] │ │ Req F: [ ][ ][Prefill][D][D] │ ← C 结束后 F 立刻插入 │ Req D: [Prefill][D][D][D][D][D] │ └──────────────────────────────────────────────┘ → 每个 step 都可以动态加入/移除请求 → GPU slot 始终被有效请求占满1.2 吞吐量对比Batching 策略并发 128 时吞吐量GPU 利用率静态批处理~1200 t/s25%-35%动态批处理~2500 t/s50%-60%连续批处理~5800 t/s85%-95%二、Continuous Batching 的核心机制2.1 迭代调度的本质Continuous Batching 的核心是一个迭代循环。每个 iteration即每生成一个 token都是一个独立的调度决策点2.2 三队列模型class Scheduler: def __init__(self, ...): # 三个核心队列 self.waiting: Deque[SequenceGroup] deque() # waiting: 新到达的请求尚未做 Prefill # 只有 Prefill 后才能开始 Decode self.running: Deque[SequenceGroup] deque() # running: 正在 Decode 的请求 # 每个 step 为它们各生成一个 token self.swapped: Deque[SequenceGroup] deque() # swapped: 被 swap out 到 CPU 的请求 # 显存不足时的临时中转站 请求生命周期: arrived → [waiting] → Prefill → [running] → Decode... → finished ↓ 显存不足 → [swapped] → 显存恢复 → [running]三、调度循环核心3.1 schedule()每步的调度决策class Scheduler: def schedule(self) - SchedulerOutputs: 每个 iteration 调用一次 决定这个 step 处理哪些请求 scheduler_outputs SchedulerOutputs() # ── Step 1: 处理已完成的请求 ── # 上一 step 生成的 token 可能触发 EOS # 完成的请求从 running 移出释放 KV Cache Block self._schedule_finished_seqs() # ── Step 2: 检查显存压力必要时抢占 ── if self._check_memory_pressure(): self._preempt_running_seqs() # ── Step 3: 从 waiting 队列补充新请求 ── # 这是 Continuous Batching 的核心 # 每 step 都检查能否加入新请求 self._schedule_waiting_seqs() # ── Step 4: 构建 batch ── # 将 running 队列中的请求组成一个 batch # 同时可能包含 waiting 队列中新请求的 Prefill self._build_batch(scheduler_outputs) return scheduler_outputs3.2 Continuous Batching 的精髓每步都可以插入新请求def _schedule_waiting_seqs(self): 关键逻辑每个 step 都尝试从 waiting 队列拉取新请求 这就是 Continuous 的含义 — 不是等到整个 batch 完成才换人 而是每个 token 生成完后都可以换人 # 计算当前显存余量 free_blocks self.block_manager.get_num_free_gpu_blocks() while self.waiting: seq_group self.waiting[0] # 判断显存是否足够做 Prefill required_blocks self._get_prefill_blocks(seq_group) if required_blocks free_blocks: break # 显存不够停止补充 # 从 waiting 移到 running self.waiting.popleft() self.running.append(seq_group) free_blocks - required_blocks # 标记这个请求这个 step 做 Prefill seq_group.set_schedule_type(ScheduleType.PREFILL)3.3 两种抢占策略当显存不足时vLLM 需要从 running 队列中抢占请求释放显存def _preempt_running_seqs(self): 显存不足时从 running 队列尾部抢占请求 两种策略SWAP 或 RECOMPUTE while self._check_memory_pressure() and self.running: # 取最后加入的请求FIFO 的反面LIFO 抢占 seq_group self.running.pop() if self.preemption_mode PreemptionMode.SWAP: # 策略 A: SWAP — 将 KV Cache 拷贝到 CPU self.block_manager.swap_out(seq_group) self.swapped.append(seq_group) elif self.preemption_mode PreemptionMode.RECOMPUTE: # 策略 B: RECOMPUTE — 直接丢弃 KV Cache # 下次恢复时重新做 Prefill self.block_manager.free(seq_group) self.waiting.appendleft(seq_group) # 放回 waiting 头部 策略 A: SWAP running → [GPU KV Cache] 拷贝到 CPU → swapped 恢复: swapped → [CPU] 拷贝回 GPU → running 优点: 恢复快只需拷贝不需重新计算 缺点: 需要额外 CPU 内存 策略 B: RECOMPUTE running → 丢弃 [GPU KV Cache] → waiting 恢复: waiting → 重新 Prefill → running 优点: 不占 CPU 内存 缺点: 恢复慢要重新算 Prefill策略恢复延迟内存需求适用场景SWAP低~5msCPU 内存 GPU KV Cache 大小显存压力大但不极端RECOMPUTE高~200ms无显存极端不足3.4 Prefill 和 Decode 的分离vLLM 的一个重要优化是Prefill-Decode 分离调度。一个 iteration 要么全做 Prefill要么全做 Decodedef _build_batch(self, scheduler_outputs): 判断这个 step 做 Prefill 还是 Decode # 如果有新请求从 waiting 进入这个 step 做 Prefill has_new_seqs any( sg.is_prefill() for sg in self.running ) if has_new_seqs: # Prefill step: 处理新请求的完整输入 # Prefill 是计算密集型GPU 利用率接近 100% batch self._build_prefill_batch() else: # Decode step: 为所有 running 请求各生成一个 token # Decode 是访存密集型GPU 利用率可能只有 30% # 这就是为什么 Continuous Batching 重要: # Decode step 可以塞入更多请求来提高 GPU 利用率 batch self._build_decode_batch()为什么要分离因为 Prefill 和 Decode 的计算特性完全不同Prefill首 token 生成: 输入: prompt几百到几千 token 计算: 并行处理所有输入 token GPU 利用率: ~95% (compute-bound) 耗时: 50-200ms Decode后续 token 生成: 输入: 上一步生成的 1 个 token 计算: 只处理 1 个 token GPU 利用率: ~20-30% (memory-bound) 耗时: 5-20ms → Decode 时 GPU 大量空闲 → Continuous Batching 利用这些空闲周期塞入更多请求四、连续批处理的数学模型4.1 吞吐量建模吞吐量 (batch_size × 1 token) / (decode_time_per_step) 传统静态批处理: batch_size 32 (固定) 每步所有 32 个请求都 decode包括已完成的空 slot decode_time ≈ 15ms (固定) 但实际有效请求平均只有 18 个 吞吐量 18 / 0.015 1200 t/s 连续批处理: batch_size 动态变化 (20-128) 每步所有 running 请求都 decode都是有效请求 decode_time ≈ 15ms (固定) 平均有效 batch_size ≈ 87 吞吐量 87 / 0.015 5800 t/s4.2 GPU 利用率建模Decode step 的 GPU 时间分解: ┌─────────────────────────────────────────┐ │ Kernel 执行 4ms (27%) ← 计算 │ │ 显存读取 10ms (67%) ← 访存 │ │ Kernel Launch 1ms (6%) ← 开销 │ └─────────────────────────────────────────┘ Total: 15ms GPU SM 利用率 ≈ 27% → 浪费了 73% 的 GPU 计算能力 Continuous Batching 的对策: 把更多请求塞进同一个 step → 显存读取量增加 (每个请求多读 KV Cache) → 但 Kernel 执行可以 batch 化 → SM 利用率提升到 60-80%五、实测数据5.1 测试环境GPU: NVIDIA A100 80GB × 1 模型: Llama-2-7B-Chat (FP16) vLLM 版本: v0.6.0 输入长度: 512 tokens (固定) 输出长度: 128 tokens (固定)5.2 不同并发下的吞吐量┌──────────────┬──────────┬──────────┬──────────┬──────────┐ │ 并发数 │ 静态 Batch│ 动态 Batch│ 连续 Batch│ 提升 │ ├──────────────┼──────────┼──────────┼──────────┼──────────┤ │ 1 │ 42 t/s │ 48 t/s │ 48 t/s │ 1.14x │ │ 8 │ 180 t/s │ 520 t/s │ 520 t/s │ 2.89x │ │ 16 │ 280 t/s │ 1050 t/s │ 1050 t/s │ 3.75x │ │ 32 │ OOM │ 2100 t/s │ 2100 t/s │ N/A │ │ 64 │ OOM │ 3500 t/s │ 3800 t/s │ N/A │ │ 128 │ OOM │ OOM │ 5800 t/s │ N/A │ └──────────────┴──────────┴──────────┴──────────┴──────────┘关键发现低并发1-8三种策略差距不大瓶颈在计算而非显存中并发16-64动态和连续批处理远超静态高并发128只有 Continuous Batching 能扛住吞吐量达 5800 t/s5.3 变长输出场景的对比真实场景中请求的输出长度是不均匀的这最能体现 Continuous Batching 的价值测试: 100 个请求输出长度分布 [32, 256, 64, 512, 128, ...] 静态批处理 (batch32): Step 0-31: 所有 32 个请求同时 Decode Step 32: Req 3 完成 (32 token) Step 64: Req 7 完成 ... Step 512: 最后一个请求完成 (512 token) → 大量 step 中有效请求远小于 32 连续批处理: Step 0-31: 32 个请求 Decode Step 32: Req 3 完成 → 从 waiting 立刻拉入 Req 33 Step 64: Req 7 完成 → 拉入 Req 34 ... → batch 始终保持满载场景静态 Batch 吞吐连续 Batch 吞吐提升等长输出 (128)1200 t/s2100 t/s1.75x变长输出 [32-512]650 t/s3200 t/s4.9x极端变长 [16-1024]380 t/s2900 t/s7.6x结论输出越不均匀Continuous Batching 的优势越明显。六、调度器实战代码6.1 完整推理循环from vllm import LLM, SamplingParams # 初始化 — vLLM 自动开启 Continuous Batching llm LLM( modelmeta-llama/Llama-2-7b-chat-hf, tensor_parallel_size1, gpu_memory_utilization0.90, max_model_len4096, # 调度相关参数 block_size16, # PagedAttention 块大小 enable_prefix_cachingTrue, # 前缀缓存优化 swap_space4, # CPU swap 空间 (GB) ) # 模拟变长请求 prompts [ 写一首关于秋天的诗, # 短输出 详细解释 PagedAttention 的工作原理, # 长输出 什么是 RESTful API, # 中等输出 用 Python 实现快速排序, # 中等输出 总结一下 TCP 三次握手, # 短输出 ] * 50 # 250 个请求 sampling_params SamplingParams( temperature0.7, top_p0.9, max_tokens512, ) # vLLM 内部自动 Continuous Batching # 250 个请求会被动态调度不需要手动分批 outputs llm.generate(prompts, sampling_params) # 统计吞吐量 total_tokens sum( len(o.outputs[0].token_ids) for o in outputs ) # vLLM 会打印吞吐量统计: # Throughput: 5234.5 tokens/s6.2 流式输出场景from vllm import LLM, SamplingParams llm LLM(modelmeta-llama/Llama-2-7b-chat-hf) # 流式生成 — Continuous Batching 在流式场景同样生效 sampling_params SamplingParams( temperature0.7, max_tokens512, streamTrue, # 流式输出 ) # 多个请求并发流式 for output in llm.generate(prompts, sampling_params, use_tqdmFalse): for chunk in output: print(chunk.outputs[0].text, end, flushTrue)七、性能调优建议7.1 最大化吞吐量的配置llm LLM( model..., gpu_memory_utilization0.92, # 尽量用满显存 max_num_seqs256, # 最大并发数影响 batch 上限 max_model_len4096, block_size16, swap_space4, # 给 swap 留空间 # 吞吐量优化: enforce_eagerFalse, # 用 CUDA Graph 减少 launch 开销 enable_prefix_cachingTrue, # 前缀缓存 max_num_batched_tokens8192, # 单 step 最大 token 数 )7.2 参数对吞吐量的影响参数推荐值影响gpu_memory_utilization0.90-0.92越高 → 可支持更多并发 → 吞吐越高max_num_seqs128-256并发上限受显存限制max_num_batched_tokens8192单 step token 上限block_size16影响显存碎片和 kernel 效率swap_space4-8 (GB)Swap 策略的缓冲空间enable_prefix_cachingTrue共享前缀的请求加速7.3 延迟 vs 吞吐量的权衡追求延迟 (交互式场景): max_num_seqs 16-32 # 小 batch每个请求更快 max_num_batched_tokens 2048 → 牺牲吞吐量换取低延迟 追求吞吐量 (批量推理): max_num_seqs 128-256 # 大 batch max_num_batched_tokens 8192 → 牺牲延迟换取高吞吐量八、总结Continuous Batching 的三个核心贡献每步动态调度每个 token 生成后都可以加入/移除请求GPU slot 不空转Prefill-Decode 分离利用 Decode step 的 GPU 空闲周期塞入更多请求抢占与恢复显存不足时优雅降级Swap 或 Recompute 都能恢复优化点贡献的吞吐量提升连续批处理vs 静态3-5xPrefill-Decode 分离1.5-2x抢占与恢复防 OOM 崩溃可用性保障这三者加上 PagedAttention 的显存优化共同构成了 vLLM 5800 t/s 的技术基石。下一篇预告下一篇进入大数据领域对 Iceberg、Hudi、Delta Lake 三大数据湖格式进行深度压测对比在写入吞吐、读取性能、Time Travel、Compaction 效率四个维度横评附选型决策树。往期回顾AI 推理优化系列—vLLM PagedAttention 解析显存利用率从 40% 提升到 90% 的秘密。llama.cpp Q4 量化原理拆解10GB 显存跑 70B 模型的秘密。Kafka acks 机制性能实测acksall 在百万级吞吐下的延迟代价有多大。GPTQ vs AWQ vs GGUF三大量化方案性能与精度横评。Kafka 深度解剖 2消费者组再均衡 Rebalance 全流程。觉得有帮助请点赞收藏。关注专栏「AI大模型大数据硬件编程」每周更新大模型推理部署的深度实战内容。
Simulink实现与工程部署指南)
