vLLM 推理优化实战PagedAttention 与连续批处理如何把吞吐提升 20 倍传统批处理在 LLM 推理上为什么效率极低大模型推理的低效往往不是算力不够而是算力被浪费了。自回归解码的生成特性与传统批处理的假设存在根本冲突——输出长度不可预测请求到达时间不同步KV Cache 按最大长度预分配——这三个冲突造成了三个典型的浪费浪费一padding。批内 4 个请求的输出长度分别是 10、50、200、500 token静态批处理要把全部 padding 到 500前三个请求约 90% 的算力都花在了算 padding 上。浪费二等齐。请求 A 在 0 秒到达请求 B 在 1.5 秒到达静态批处理要等批满才开跑A 白等了 1.5 秒。浪费三显存碎片。KV Cache 按最大可能长度预分配例如每个请求 2048 token实际平均只生成 200 token90% 的预分配显存空着而且这段连续空间无法给别的请求复用。实测数据触目惊心传统批处理下A100 上的 GPU 利用率往往只有 30% 左右显存利用率约 40%其余全部浪费在 padding、等齐和碎片上。理解 KV Cache自回归解码的显存瓶颈自回归解码第 t 步需要用到前 t-1 步所有 token 的 K、V 向量。不缓存就要重算前 t-1 步复杂度是 O(t²)缓存后每步 O(1)但用显存换时间KV Cache 显存 2 × num_layers × num_heads × head_dim × seq_len × batch × dtype字节以 Llama-70B 为例80 层、64 头、head_dim 128、seq_len 2048、batch 32、FP16KV Cache 约需 80GB——比模型权重本身还大。推理过程中还有两个阶段之分prefill 阶段一次性处理整个 prompt计算密集compute bounddecode 阶段逐 token 生成显存密集memory bound。两个阶段对资源的需求完全不同这也是传统单一批处理难以高效调度的深层原因。PagedAttention把 KV Cache 当虚拟内存管理vLLM 提出的 PagedAttention 借鉴了操作系统虚拟内存分页的思想。传统做法为每个请求预分配一段连续的 KV Cache 空间按 max_len而 PagedAttention 把 KV Cache 切成固定大小的物理块block典型值 16 token/块按需分配用块表block table记录逻辑序列到物理块的映射。这样做带来三个直接收益消除了预分配浪费和外部碎片显存按实际用量分配利用率从约 40% 提升到 95% 以上可并发请求数受限于总块数而非连续大块同等显存下并发能力提升 2-3 倍请求级抢占和优先级调度成为可能——长请求可以被挂起并恢复不会阻塞短请求。值得说明的是PagedAttention 的实现并不简单——传统 attention 假设 KV Cache 连续一次矩阵乘搞定PagedAttention 需要按块表分块读取再算 attention。幸运的是 vLLM 已经用 CUDA kernel 优化好了这部分开销使用者不需要关心底层实现。Continuous Batching请求随到随走连续批处理Continuous Batching解决的是等齐问题。静态批处理等批满才开跑一批内所有请求都完成才接新批GPU 大量空转。连续批处理改为迭代级调度每个 iteration 结束后移出已完成的请求释放其 KV Cache block 回池从等待队列拉新请求填入空位立即跑下一个 iteration批的成员每个 iteration 都在变但批的大小始终维持最大并发数GPU 持续满载。更关键的是 prefill 与 decode 的混合调度新请求入批先做 prefill计算密集老请求继续 decode显存密集同一个 iteration 里两类请求互相填补避免了prefill 阶段 GPU 满、decode 阶段 GPU 闲的割裂。实测效果A100 80G 部署 Llama-3-70B100 并发请求配置吞吐 (token/s)显存利用率P99 延迟GPU 利用率传统批处理12040%8.5s30% PagedAttention60096%5.2s70% Continuous Batching180096%4.8s85% 推测解码240096%3.1s88%一个值得深思的结论PagedAttention 和连续批处理没有增加任何算力只是把浪费掉的算力捡了回来——显存利用率从 40% 到 96%意味着同一张卡能服务的并发量直接翻倍。这就是 vLLM 能不换硬件就把吞吐提升 20 倍的根本原因。vLLM 部署与参数调优vLLM 把 PagedAttention 和连续批处理封装成了开箱即用的能力部署只需一条命令python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-3-70b-hf\--quantizationawq\--tensor-parallel-size2\--max-model-len4096\--gpu-memory-utilization0.9关键调优参数及决策逻辑 - **max_num_seqs**单批最大并发请求数。显存够就调大吞吐升但 P99 延迟会升排队久。高吞吐离线批处理可以调大256低延迟在线服务保持32-64 平衡。 - - **gpu_memory_utilization**显存占用比例默认0.9A100 可调到0.95榨干显存。 - - **block_size**每个 block 的 token 数默认16是验证过的甜点通常不动。 - - **max_model_len**按业务最长请求设而不是用默认最大值——预留过大的上下文窗口会浪费显存挤占并发空间。 - - **enable_chunked_prefill**长 prompt 场景必开。不开的话单个长 prompt 的 prefill 会独占 GPU 一个 iteration其他请求全部卡住。## 叠加优化推测解码与量化的组合拳vLLM 的优化手段可以正交叠加。推测解码Speculative Decoding用小模型快速生成候选 token大模型单次前向并行验证接受的 token免费获得单请求延迟可提升1.5-2 倍且精度无损。它与连续批处理互不干扰——一个优化单请求延迟一个优化系统吞吐组合后两个维度同时受益。 量化则从显存维度切入AWQ 或 GPTQ 的4-bit 量化能把 70B 模型从约 140GB 压到 40GB 以内精度损失低于3%让单卡 A100 就能跑 70B 模型。量化与 KV Cache 优化、批处理优化都是独立的维度可以全部叠加。 配置示例python from vllmimportLLM, SamplingParams llmLLM(modelmeta-llama/Llama-3-70B,max_num_seqs64,# 连续批处理并发数gpu_memory_utilization0.95,# 榨干显存enable_chunked_prefillTrue,# 长 prompt 分块speculative_modelmeta-llama/Llama-3-8B,# 推测解码num_speculative_tokens5,quantizationawq,# INT4 量化)## Prefix Caching 与语义缓存省下重复计算的算力对于固定前缀占比高的在线服务Prefix Caching 是又一个高性价比优化。典型场景客服机器人每个请求都携带相同的系统提示词角色设定 安全规则 业务规范可能长达几百 token。没有前缀缓存时每次请求都要重新计算这些前缀 token 的 KV 值启用前缀缓存后相同前缀的 KV 直接从缓存复用只需要计算新增的用户输入部分。 vLLM 启用前缀缓存只需一个参数--enable-prefix-caching。它通过哈希匹配 token 前缀命中时复用 KV显著降低 prefill 阶段的计算量。实测中固定系统提示词 短用户输入的场景prefill 时间可以缩短一半以上。更进一步的语义缓存Semantic Cache思路是相似问题Embedding 相似度0.95直接返回缓存结果避免重复生成。语义缓存的命中率在客服类场景可达15-20%适合高重复、低波动的问题分布——但要注意缓存带来的时效性问题涉及实时数据的回答不应走缓存。## 监控、成本治理与落地建议推理优化的效果最终要用监控数据说话。生产环境至少监控四类指标硬件资源GPU 显存使用率、算力利用率——显存过高触发 OOM算力过低说明优化不到位推理业务单请求延迟、TTFT 首字延迟、token 生成速度、吞吐量、推理成功率请求流量QPS、超时数、限流数异常日志OOM、推理报错、参数异常。配合 Prometheus Grafana 搭建看板设置阈值告警才能做到问题早发现、早定位、早修复。 成本治理是另一个常被忽略的维度单次对话平均成本、日/月成本趋势、按业务线分摊的成本归属都应该有可视化看板。量化、缓存、批处理这些优化手段的收益最终都要落到单位成本的服务能力这个指标上验证。推理优化没有终点模型在升级、业务在变化、硬件在换代优化的决策依据永远应该是当前负载下的实测数据。 落地建议按用 vLLM → 调 max_num_seqs → 叠加推测解码 → 叠加量化的递进路径实施。第一步直接换 vLLM 是 ROI 最高的动作——一天完成部署立刻拿到 PagedAttention 和连续批处理带来的吞吐提升第二步用实验找吞吐与延迟的甜点第三步几行配置叠加推测解码量化按显存需求按需添加。 三个核心权衡要牢记max_num_seqs 是吞吐与延迟的跷跷板在线服务偏小、离线批处理偏大block_size 在碎片与调度开销之间平衡16 是甜点chunked_prefill 在多租户在线服务上必开保证长 prompt 不饿死短请求。 最后提醒生产环境要接监控——Prometheus 记录 gpu_cache_usage、num_requests_running、TTFT 分布等指标配合自动扩缩容。推理优化的效果必须用生产负载下的实测数据说话而不是看单个 benchmark 数字。