053、连续批处理vLLM与TensorRT-LLM的高吞吐秘诀从一次生产事故说起去年冬天我负责的一个AI对话服务在晚高峰突然崩溃。监控显示GPU利用率只有30%但请求排队时间却飙到了15秒。翻看日志发现每次推理请求都在等前一个请求彻底结束——典型的“串行批处理”陷阱。当时用的还是HuggingFace原生的generate()接口每个请求独立申请显存、独立做KV CacheGPU在大部分时间都在做内存搬运真正的计算单元反而在摸鱼。这个问题让我意识到大模型推理的瓶颈从来不是算力而是显存带宽和批处理策略。后来切换到vLLM同样的硬件吞吐量翻了4倍。今天就把这两个主流方案——vLLM的PagedAttention和TensorRT-LLM的Inflight Batching——掰开揉碎讲清楚。连续批处理的核心矛盾传统批处理Static Batching就像在食堂打饭必须等所有人都点完菜厨师才开始炒。如果某个请求特别长比如生成1024个token其他短请求就得干等。更糟糕的是每个请求的KV Cache大小是动态变化的提前分配固定显存会导致大量浪费——这就是为什么你经常看到“OOM”但实际显存利用率不到50%。连续批处理Continuous Batching的思路是让GPU像流水线一样工作。每个请求的token生成是独立的当一个请求完成生成遇到EOS或达到max_tokens立即从批处理队列中移除同时插入一个新请求。这样GPU永远在处理“当前最活跃”的请求不会因为某个长请求而阻塞整个批次。vLLMPagedAttention的显存魔术vLLM的核心创新是PagedAttention灵感来自操作系统的虚拟内存分页。传统做法为每个请求分配连续的显存块比如2048个token的KV Cache但实际生成过程中很多位置是空的。vLLM把KV Cache切成固定大小的“页”Page每个页可以独立分配和释放。关键实现细节# 别这样写一次性分配所有显存kv_cachetorch.empty(batch_size,max_seq_len,2,num_heads,head_dim)# 正确做法按页分配动态映射block_size16# 每页16个tokennum_blockstotal_gpu_memory//(block_size*2*num_heads*head_dim)block_tabletorch.zeros(batch_size,max_blocks_per_seq,dtypetorch.int32)这里踩过坑block_size不是越大越好。我测试过8、16、32三种粒度16在显存利用率和调度开销之间平衡最好。太小如8会导致页表过大增加寻址延迟太大如32则内部碎片增多。调度策略的取舍vLLM使用“先来先服务饥饿预防”的调度器。每个请求有一个“优先级年龄”等待时间越长优先级越高。但要注意如果某个请求的prompt特别长比如8K tokens它会占用大量页导致其他请求被阻塞。我的经验是对prompt长度设置硬上限超过4K的prompt单独走一个低优先级队列避免“大块头”饿死“小个子”。TensorRT-LLMInflight Batching的工程艺术NVIDIA的TensorRT-LLM走的是另一条路在编译期就确定好批处理形状运行时通过“Inflight Batching”动态插入/移除请求。它的核心是多轮次调度Multi-Round Scheduling。工作流程拆解准备阶段每个请求的prompt被编码成固定长度的输入比如512 tokens不足的padding超出的截断。这里有个坑padding会浪费计算所以TensorRT-LLM允许“可变长度输入”但需要你在编译时指定最大长度范围。推理循环每一轮迭代调度器检查所有活跃请求。如果一个请求生成了EOS立即从当前批次移除同时从等待队列拉一个新请求进来。注意新请求的prompt需要先做prefill而prefill和decode的计算模式完全不同prefill是计算密集型decode是访存密集型。TensorRT-LLM的做法是把prefill和decode混合在同一个批次里通过MHAMulti-Head Attention的优化来平衡计算负载。显存管理TensorRT-LLM使用“KV Cache池化”技术。所有请求共享一个大的KV Cache池每个请求按需申请“slot”。当请求结束时slot立即回收。这比vLLM的页表更粗粒度但减少了地址转换开销。性能调优的实战参数# TensorRT-LLM的构建配置builder_config{max_batch_size:64,# 别设太大超过32容易触发显存碎片max_input_len:4096,# 根据业务场景调整对话场景2048足够max_output_len:1024,# 生成长度上限影响KV Cache预留max_beam_width:1,# 连续批处理下beam search会复杂很多scheduler_policy:max_utilization# 还有guaranteed_no_evict选项}这里踩过坑max_batch_size设成128后显存占用飙升到80GB但实际吞吐量只提升了15%。原因是GPU的SM数量有限批次太大时每个请求分到的计算资源太少反而增加了调度开销。64是个安全阈值对于A100 80G来说。两个方案的对比与选择维度vLLMTensorRT-LLM显存效率极高页级管理高池化管理部署复杂度低Python原生高需要编译、C运行时动态性强支持任意长度中需预设范围延迟抖动较大页表查找小编译优化硬件适配通用GPUNVIDIA专属我的选择原则快速验证用vLLM生产部署用TensorRT-LLM。vLLM的PagedAttention在显存紧张时优势明显比如在4090上跑13B模型而TensorRT-LLM在A100/H100上能榨出最后10%的性能特别是结合NVIDIA的FasterTransformer算子。连续批处理的隐藏陷阱1. 请求长度分布的影响如果业务中90%的请求都是短对话100 tokens但偶尔有长文档分析2000 tokens连续批处理会导致“长尾效应”长请求会持续占用KV Cache短请求虽然能快速完成但新请求的插入会被长请求的prefill阶段阻塞。解决方案是设置两个队列短请求队列优先处理和长请求队列低优先级单独分配资源。2. 显存碎片化vLLM的页表机制虽然灵活但频繁分配释放会导致显存碎片。我遇到过运行48小时后显存利用率从95%降到70%的情况。解决办法是定期执行显存整理defragmentation或者设置max_num_seqs限制并发请求数避免页表过于碎片化。3. 批处理与流式输出的矛盾很多场景需要流式输出SSE但连续批处理要求所有请求同步进行decode。vLLM通过“异步调度”解决每个请求的token生成是独立的但返回给客户端时通过队列缓冲。注意流式输出的延迟会略高于非流式因为需要等待当前批次的全部请求完成一轮decode。个人经验总结不要迷信理论峰值连续批处理的吞吐量提升不是线性的。我测试过从batch_size1到64吞吐量增长曲线在batch_size16后明显放缓。找到你硬件平台的“甜蜜点”比盲目增大批次更重要。监控KV Cache命中率这是vLLM的核心指标。如果命中率低于80%说明页表分配策略有问题可以尝试增大block_size或调整调度策略。混合使用两种方案我在一个项目中用vLLM处理短对话512 tokens用TensorRT-LLM处理长文档1024 tokens。两个服务通过消息队列连接整体吞吐量比单一方案提升了40%。永远留20%显存余量连续批处理在显存接近满时调度开销会急剧增加。我习惯把gpu_memory_utilization设为0.8剩下的留给系统和其他进程。最后说句实在话连续批处理不是银弹。如果你的请求长度非常均匀比如都是128 tokens传统静态批处理反而更高效。但现实世界的流量永远是长尾分布的——这也是为什么vLLM和TensorRT-LLM能成为主流的原因。下次你的GPU利用率上不去时先别急着加卡看看你的批处理策略是不是还在“串行排队”。