1. 项目概述：为什么 vllm 的优化配置值得单独一篇大模型推理服务跑起来容易，跑得快很难。很多人第一次接触 vllm，照着 README 里三行代码启动一个推理服务，发现吞吐量确实比朴素实现高不少，于是以为“开箱即用”就够了。等真正接到生产流量，或者要跑大规模离线批量任务时，才会意识到：vllm 的性能上限，很大程度上由 configuration/optimization 这一层决定。我最初接触 vllm，是在某个内容平台的语义向量生成项目里。当时要在一个工作日内完成千万级的短文本向量化，GPU 显存有限，第一批任务用默认配置跑，显存直接打满，吞吐量远低于预期。后来花了两天时间把官方文档里 optimization.md 相关的参数逐个过了一遍，才明白这引擎的设计哲学——每个优化项背后都对应一套内存管理和调度策略，如果你不理解它为什么要这么设计，配置起来就只能靠猜。这篇文章就是围绕 vllm 文档中 optimization 相关的核心内容展开的，目标很明确：讲清楚 vllm 性能优化背后的几个关键机制，包括 PagedAttention 显存管理、Continuous Batching 动态调度、KV Cache 量化、并行策略、精度选择等，然后给出可以直接套用的配置思路和排障经验。适合正在部署 vllm 的算法工程师、后端开发，以及准备做 LLM 推理优化的技术人员。你要是已经把 vllm 跑起来了但觉得性能还有瓶颈，这篇应该对你有帮助。2. vllm 优化机制的核心思想：先理解内存和调度，再谈配置vllm 被广泛使用，核心不是“能跑模型”，而是它的推理调度机制比传统方案高出一个量级。优化配置之所以重要，是因为几乎所有性能参数都围绕两个底层机制展开：PagedAttention 和 Continuous Batching。你不理解这两个机制，配置参数就是摸着石头过河；理解了，再看文档里每个参数就都有明确指向了。2.1 PagedAttention 到底做了什么传统的大模型推理框架在显存管理上有一个通病：预分配。比如某个请求最多生成长度为 2048 的序列，框架就会按这个上限预留完整显存块。但实际请求可能只输出几十个 token 就结束了，预留的显存就白白浪费了。更糟糕的是，不同请求的序列长度差异很大，显存碎片化严重，导致 GPU 利用率怎么也提不上去。vllm 借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的物理块（block），每个块可以存储固定数量的 token 对应的键值对。逻辑上每个序列是一段连续空间，物理上这些块可以分散在显存的不同位置。需要用哪个 token 的 KV Cache，就通过 block table 索引过去，跟操作系统的页表一样。这套机制就是 PagedAttention。这个设计带来的直接好处：显存利用率接近真实需求，而不是按最大可能长度预分配。理论上，同样的显存，vllm 能承载的并发请求数远多于传统方案。在实际测试中，同样的模型和显存，vllm 的吞吐量相比 naive 实现往往有几倍的提升，主要就来自这里。2.2 Continuous Batching：把“等”的时间变成“算”的时间传统推理服务通常采用静态批处理：攒够一批请求，一起前向传播，等这批全部生成完毕，再处理下一批。问题很明显：批内的请求长度参差不齐，短请求早早就结束了，但必须等待长请求完成，GPU 在“等待”时段就闲置了。vllm 的 Continuous Batching 是迭代级调度。每个 forward step 之后，已经结束的请求立刻移出批次，新到达的请求马上加入。这样 GPU 一直在处理存量请求，不需要等整批结束。配合 PagedAttention 的细粒度显存管理，每一迭代的批大小几乎都能打满显存预算。这也是为什么你会在配置里看到max_num_seqs和max_num_batched_tokens这类参数——它们本质上是在控制“每一迭代放多少个序列进来”以及“一次前向最多吃多少个 token”。这两个值设多高，直接影响显存占用和调度延迟之间的平衡，后面我会细说。2.3 优化配置的本质：在吞吐量和延迟之间找平衡理解上述机制后，一切优化配置都可以归纳为一个问题：在有限显存里，如何让 GPU 每个迭代的计算尽量满、调度开销尽量低、首 token 延迟尽量小。这三者之间存在矛盾。追求吞吐量，就要把显存尽量填满，批次尽量大，但这会让每个请求排队时间变长。追求首 token 延迟（TTFT），就要让新请求尽快进入计算，但频繁插队会打乱预填充和生成阶段的整合。追求单请求生成速度（TPOT），就要减少同批内的序列数，但 GPU 利用率会下降。所以你看 vllm 的配置文档，它给了一大堆可选参数，但没有一个“万能配置”，因为不同业务场景对这三者的权重完全不同。这也是我建议所有使用 vllm 的人，先想清楚自己的核心指标再动配置的原因。3. 核心参数逐项拆解：每个配置的作用和取舍逻辑vllm 的配置文件里参数很多，但真正直接影响推理性能的，核心就十几个。我按内存管理、调度策略、精度策略、并行策略四个维度分组来拆，每组都给出我实测时的调参经验。3.1 显存控制三件套：gpu-memory-utilization、max-model-len、block-sizegpu-memory-utilization是第一个要看的参数，默认0.9。它控制 KV Cache 最多能占 GPU 显存的比例。剩余部分留给模型权重和计算过程中的临时激活值。很多人一上来就把它设成 0.95 甚至 0.98，以为显存用得越满越好。实际这个值太大，激活值显存不够时会出现 torch 层面的 OOM，而且这种 OOM 比较难排查，因为报错不在 vllm 的日志里，而是在 CUDA 层。我建议先按 0.85 起步，观察nvidia-smi里显存峰值是否逼近上限且不 OOM，再逐步上调。如果发现 vllm 启动时报 “No available memory for the cache blocks” 之类的问题，说明显存不够，优先调小这个数，而不是调大。max-model-len控制模型接受的最大序列长度。它直接影响单个序列最多占用多少 block，进而决定 KV Cache 能容纳多少并发序列。比如某个模型上下文窗口支持 32k，但你的业务实际最多用 4k，那就把max-model-len设成 4096 或 8192 而不是 32768。这样每个序列占用的 KV Cache 少了，能并发执行的请求数大幅上升，吞吐量会有非常明显的提升。block-size是 PagedAttention 的物理块大小，默认 16，指每个块存储 16 个 token 的 KV Cache。这个值小，显存分配更灵活，碎片更少，但 block table 的索引开销更大；值大，索引开销小，但显存可能浪费。实测下来，16 是个稳妥的默认值，一般不需要动。除非你的模型比较小、显存不大，想降低调度开销，可以试试 32，但提升有限。3.2 调度相关的三个关键参数：max-num-seqs、max-num-batched-tokens、enable-chunked-prefillmax-num-seqs默认 256，表示一次迭代最多处理的序列数。设太小，连续批处理的效果打折扣；设太大，批次过大导致单次 forward 太慢，每个请求的生成延迟上升。如果是离线批量任务，可以适当提高；在线服务则要结合延迟要求来调。max-num-batched-tokens限制一次前向最多处理的 token 总数。这个值是控制“计算量”的关键，默认在低版本中是 2048，新版本会按显存自动调整。如果预填充阶段的序列很长，且这个值太小，一个长序列的预填充就要分成多次迭代完成，虽然不会出错，但会产生不必要的调度开销，降低吞吐量。如果你的场景是长文档摘要这类输入很长的任务，建议把这值调大，比如 8192 或 16384，让长 prompt 的预填充一次完成。enable-chunked-prefill是 vllm 较新版本才支持的功能。传统机制里，预填充阶段和生成阶段不会混合到同一个迭代里。如果来了一个很长的 prompt，预填充占用了整个迭代，生成阶段的请求就得等，造成延迟抖动。开启 chunked prefill 后，长 prompt 会被切成块，穿插到生成迭代的空闲 slot 里，这样可以显著降低长输入场景下的延迟波动。代价是总吞吐量会轻微下降。如果业务中既有长输入又有短输入混合，这个选项值得开。3.3 量化与精度配置：FP8、INT8、AWQ、GPTQ 怎么选vllm 工程化做得好的一个表现是量化支持非常全。文档里 optimization 部分专门有一节讲 KV Cache 量化和 weight 量化，配置参数主要是-q或--quantization，以及--kv-cache-dtype。先说 KV Cache 量化。KV Cache 在长序列、大并发场景下占据显存大头，将其量化为 FP8 可以节省约一半显存，而模型质量损失通常非常小。我的实际经验是，在 7B 到 70B 规模模型上，FP8 KV Cache 对输出质量的影响基本可以忽略，但显存占用下降明显。比如原来只能并发 8 个请求的场景，开 KV Cache FP8 之后能上到 12 到 16 个。参数写法是--kv-cache-dtype fp8。Weight 量化方面，vllm 支持常见的 GPTQ、AWQ、FP8、INT8 等。选择标准很简单：你的模型本身有没有量化版本。比如开源社区很多模型已经出了 AWQ 或 GPTQ 版本，直接用--quantization awq加载即可。FP8 量化则需要 GPU 支持（H 系列等），而且需要原始权重先转换。我建议在工程实践中优先选择社区验证过的 AWQ 量化权重，兼容性好，速度提升也稳定。在 4090 这类消费卡上，AWQ 相比 FP16 通常有 1.5 倍以上吞吐提升。需要特别提醒：量化不是免费的午餐。小模型量化后精度下降更明显，比如 1B 以下的模型，AWQ 量化后输出质量波动较大。7B 以上模型则风险小很多。生产环境上线前，建议准备一组标准测试集，量化前后对比输出质量再做决定。3.4 并行策略：数据并行、Tensor 并行、Pipeline 并行怎么搭配vllm 文档里和并行相关的主要是--tensor-parallel-size和--pipeline-parallel-size，多机多卡部署时还会涉及分布式推理配置。Tensor Parallelism 是把一个模型切到多张卡上，每张卡负责一部分层或一部分注意力头。这是 vllm 最常用的并行方式。比如 70B 模型在 4 张 80G 显存的卡上跑，通常会用--tensor-parallel-size 4。注意：TP 会带来 GPU 间通信开销，不是卡的张数越多越好。实测中，2 卡到 4 卡通常有接近线性的吞吐提升，8 卡以上收益就明显递减。Pipeline Parallelism 是把模型按层切分，每张卡负责其中若干层。vllm 对 PP 的支持相比 TP 要弱一些，因为它和 Continuous Batching 的调度耦合较深。一般来说，单机多卡优先选 TP；跨多机时，通常优先保证 TP 在节点内，再考虑节点间的数据并行。多副本数据并行方面，vllm 通过推理服务网关或前端负载均衡来做，它本身专注单引擎的高吞吐。若单引擎吞吐已达瓶颈，再部署多个副本，前面加一层负载均衡，这是常见的扩展路径。4. 实战配置：两种典型场景的参数组合讲完参数，直接给配置组合。下面是我在两类场景里反复验证过的方案，你可以作为起点再微调。4.1 离线批量推理场景：追求吞吐量，可以牺牲部分延迟离线批量任务，比如大规模知识库向量化、批量文本分类、离线摘要生成，核心指标是总处理时间。延迟要求宽松，但显存利用率要拉满。实测配置建议：参数设置说明--gpu-memory-utilization0.92~0.95离线任务可激进占满显存--max-num-seqs256 或更高提高并发序列数--max-num-batched-tokens8192 或 16384长输入场景适当调大--max-model-len按业务实际长度设置不要贪大--kv-cache-dtypefp8显存减半，提升并发--quantization根据模型选 AWQ/FP8有量化权重优先用--enable-chunked-prefill视情况关闭离线任务追求吞吐优先在某个离线摘要项目中，我处理一批 4 万篇长文档，用默认配置跑了 6 个多小时。调整了以上参数后，实际耗时降到了 2 小时左右，主要收益来自三块：max-num-batched-tokens调大后预填充效率提升、KV Cache FP8 后并发数提高了近一倍、量化权重让单位 token 的算力开销下降。如果你追求更进一步，还可以考虑把--max-num-seqs设成 512，但要盯着显存使用率，如果 preemption（抢占）比例过高，说明超过了实际承载能力，反而会拖慢整体速度。4.2 在线服务场景：TTFT 和 TPOT 优先在线服务，比如聊天助手、实时翻译、RAG 问答，核心指标是首 token 延迟（TTFT）和单 token 生成延迟（TPOT），要求响应平滑，不能出现明显的排队抖动。实测配置建议：参数设置说明--gpu-memory-utilization0.85~0.90留出余量避免显存抖动--max-num-seqs64~128控制排队长度--max-num-batched-tokens4096~8192适当限制单步计算量--enable-chunked-prefill开启（长输入混合时）减少长 prompt 引发的抖动--max-model-len尽量匹配业务上限避免长尾请求失败在线场景还有一个容易被忽视的点：--max-prompt-length或服务端的超时控制。如果允许单个请求的 prompt 很长，它会在预填充阶段占住大量调度资源，导致后面所有请求的 TTFT 飙升。所以在线场景通常要做输入长度限制，超出直接拒绝或截断，保护整体服务水平。我曾经优化过一个 RAG 问答服务的 vllm 配置，最初 TTFT 的 P95 是 2.8 秒，用户体验明显不好。把max-num-seqs从 256 调到 96，同时开启 chunked prefill 后，TTFT 的 P95 降到 1.1 秒，TPOT 稳定在 50ms 左右。表面上看并发序列数降低了，但因为请求排队轮转更快，用户体验反而明显提升。这个案例很典型：在线场景不要只看显存是否打满，要看延迟分布。4.3 显存不足时如何评估是否值得升级 GPU很多人在配置 vllm 时发现显存不够用，第一反应是换更大的卡。但有时候并不一定需要，先算一下账。KV Cache 的显存需求大约等于：总显存 × gpu-memory-utilization − 模型权重占用的显存。模型权重显存大约是参数量 × 字节数。以 7B 模型为例，FP16 权重约 14GB，INT8 约 7GB，FP8 约 7GB。如果一张 24GB 的卡，gpu-memory-utilization=0.9，可用显存 21.6GB，FP16 权重下 KV Cache 大约只有 7.6GB。你算一下这个值，再对照实际业务并发需求，就知道瓶颈在哪了。如果 KV Cache 太少导致并发上不去，优先考虑换量化方案（权重量化 + KV Cache 量化），而不是直接换大卡。因为换卡要额外花钱、改环境，而量化通常能让你在现有卡上就获得 1.5 到 2 倍的并发提升。在某个项目里，我帮同事优化一个基于 13B 模型的服务，原本要上 2 张 4090 才能满足需求，后来改成 AWQ 量化加 KV Cache FP8，单张 4090 就抗住了，第二张卡直接省下来。5. 常见问题与排查技巧实录vllm 排障和其他框架不太一样，它的错误信息有时候很含蓄，更多时候是“能跑，但性能不对”。下面这些是我和身边朋友实际踩过的坑，整理成速查表。5.1 典型问题速查表现象可能原因解决思路启动时报 “No available memory for the cache blocks”gpu-memory-utilization 过低或 max-model-len 过大调高利用率（注意别超），或调小 max-model-len运行中 torch.cuda.OutOfMemoryError激活值显存不足，模型过大或 batch 太大调低 max-num-seqs，或换量化权重服务整体吞吐低，GPU 利用率却不高max-num-seqs 设置太小，批次一直不满调大 max-num-seqs 和 max-num-batched-tokens部分请求延迟突然飙升长 prompt 预填充阻塞了生成请求开启 enable-chunked-prefill 试试输出质量明显下降量化精度设置不当，或小模型量化换回 FP16 对比测试后决定显存占用逐渐增长，疑似泄漏长连接推理服务的内存碎片定期重启服务，或检查 vllm 版本升级多卡 TP 模式吞吐不升反降Tensor parallel size 设过大，通信开销过高降为 2 或 4，观察扩展比preemption 过多，日志大量显示抢占显存不足、调度过于拥挤调低 max-num-seqs，或增大 KV Cache 空间5.2 preemption 的高发场景和避坑preemption 是 vllm 在显存不足时，把一个序列的 KV Cache 从显存里移走（换出到 CPU，或者全部重算）的机制。它有两种策略：recompute 和 swap。recompute 是把被抢占序列之前生成的 token 全部丢弃，等显存有空位再重新计算；swap 则是把 KV Cache 换到 CPU 内存里，等需要时再换回。从实际效果看，swap 通常比 recompute 更平滑，但 CPU 和 GPU 之间的 PCIe 传输会成为瓶颈。如果频繁出现 swap，吞吐量会显著下降。配置参数上，vllm 的--swap-space控制 CPU 侧 swap 空间大小，但这是兜底机制，不要指望靠它解决显存不足。我排查 preemption 的经验是：先看日志统计里 preemption 次数。如果次数超过总请求数的 5%，说明批次配置偏大或显存预算偏紧，应该调低max-num-seqs或调低gpu-memory-utilization给 KV Cache 更多空间。有些场景换到 FP8 KV Cache 后，preemption 直接降到接近零，这是因为每个序列占的 block 数减半了，同等显存能容纳的序列数翻倍。5.3 性能监控：不要只看 nvidia-smi很多人调 vllm 性能时喜欢盯着nvidia-smi看显存占用。但显存占用高并不代表吞吐高，也可能是批次太小、显存预分配导致的假象。vllm 自带 metrics 服务，在启动时加上--metrics相关的参数（vllm 服务默认暴露 Prometheus 格式的 metrics），可以看到更关键的指标，比如：当前正在处理的请求数preemption 次数各阶段平均耗时（预填充时间、解码时间）吞吐量（tokens per second）我的建议是至少记录三个指标：请求排队时间、preemption 次数、生成吞吐量。这三个指标能帮你判断瓶颈在调度层、显存层还是计算层。比如排队时间长，但生成吞吐量很高，说明是请求到达速率超过了处理速率，需要加副本而不是调参数；preemption 次数多，优先调显存和 batch 参数；生成吞吐量低但 GPU 利用率高，考虑推理引擎本身的能力边界。我遇到过一种情况：GPU 利用率看着有 90% 以上，但吞吐量就是上不去，后来发现是max-num-seqs设太大，导致每个迭代里序列很多但每个序列都很短，单次 forward 的小矩阵运算多了，GPU 算力浪费在调度和 kernel 启动上。把序列数降下来、batch tokens 设得更合理，吞吐量反而涨了。这种反直觉的问题，不靠 metrics 分析很难定位。5.4 换卡和换模型时的配置迁移还有一个常见问题：模型从 7B 换成 13B，或从单卡换成多卡，配置能直接沿用吗？答案是最好不要。模型尺寸变了，权重显存、KV Cache block 数量、激活值显存都会变，直接沿用旧配置往往会出现 OOM 或性能下降。我建议每次换模型或换 GPU 环境后，用一个固定 prompt 集做一次压测，观察显存占用和吞吐，然后按上面说的参数分组逐项微调。不要迷信旧配置在多场景下的通用性。vllm 的配置本来就是性能调优的起点，不是终点。6. 一些值得深入的方向和补充思路vllm 的 optimization 文档中还有一些容易被忽略但值得研究的内容，简单展开一下，供有精力的读者深入。6.1 投机解码（Speculative Decoding）的实际收益vllm 支持 speculative decoding，核心思路是用一个小模型草拟多个候选 token，再由大模型并行验证。如果小模型草拟的 token 与大模型一致，大模型一次 forward 就能生成多个 token，相当于解码速度翻倍。这个方案对单请求低延迟场景非常有效，但对小模型的质量要求较高。在实际测试中，小模型和大模型分布越接近，收益越明显。如果两者差异过大，草拟准确率低，大模型频繁拒绝，收益反而被额外计算抵消。想尝试的话，可以在启动参数里指定 draft model 相关配置。这个方向适合对单 token 延迟有极致要求的场景，比如实时对话。6.2 结构化输出对 KV Cache 和调度的影响如果你的业务要求模型输出 JSON 或特定格式，vllm 提供了结构化输出相关的限制机制。它和优化配置的关系在于：结构化限制会改变生成阶段的行为——模型在每一步生成时会被约束选择合法 token。虽然这让输出更符合格式预期，但也略微增加了单步计算量。在性能敏感场景，要评估这部分额外开销是否值得。我的经验是，格式错误造成的下游解析成本往往更高，所以结构化输出通常利大于弊。6.3 版本升级对配置的隐性影响vllm 迭代非常快，版本升级时默认值经常变化。我遇到过从 0.4 升到 0.6 后，原本跑得好好的配置突然 OOM 的情况，原因是新版默认启用了更激进的内存复用策略。所以每次升级后，建议先小流量灰度，对比压测结果，不要直接全量切。这个习惯可以帮你避开很多坑。7. 个人经验总结与建议说了这么多，最后聊点纯个人经验。vllm 的优化配置本质上是一个“显存换吞吐”的工程优化过程，没有脱离场景的参数组合，也没有永远最优的配置。但有几个原则我每次都会先确认：第一，先量化你的业务长度分布。很多人跑 vllm 不统计 prompt 和 completion 的实际长度分布，全凭感觉设置max-model-len，试来试去性能上不去。花五分钟统计一下业务数据，把最大长度和尤其是 P95 长度搞清楚，配置就有了量化依据。第二，每次只动一个参数。vllm 参数之间相互耦合，一次调好几个参数，出了问题根本不知道是哪一步引起的。我的习惯是搭一个标准压测脚本，固定测试集和并发模型，每次改一个参数记录吞吐和延迟，最后汇总再综合调整。这个方法虽然慢，但最可靠，不玄学。第三，定期看官方更新。vllm 团队对调度和显存管理的优化一直没有停过，很多新版本的默认行为比旧版好得多。如果生产环境有条件，保持每三个月左右的版本升级节奏，同时用你的压测脚本验证，能得到持续的性能收益。最后给一个小技巧：在 vllm 服务启动参数里加上--verbose或看日志中的调度统计，启动后观察前几百个请求的调度行为。如果日志里频繁出现 preemption 相关提示，就不要急着加大并发，先把显存配置凑稳再说。很多时候性能问题不是参数不够激进，而是基础配置不匹配。希望这篇经验能让你少走一些弯路。你的业务形态如果和我的场景差别很大，欢迎拿文档中的参数继续交叉验证，vllm 的优化空间远比表面看到的更大。
1. 项目概述：为什么 vllm 的优化配置值得单独一篇大模型推理服务跑起来容易，跑得快很难。很多人第一次接触 vllm，照着 README 里三行代码启动一个推理服务，发现吞吐量确实比朴素实现高不少，于是以为“开箱即用”就够了。等真正接到生产流量，或者要跑大规模离线批量任务时，才会意识到：vllm 的性能上限，很大程度上由 configuration/optimization 这一层决定。我最初接触 vllm，是在某个内容平台的语义向量生成项目里。当时要在一个工作日内完成千万级的短文本向量化，GPU 显存有限，第一批任务用默认配置跑，显存直接打满，吞吐量远低于预期。后来花了两天时间把官方文档里 optimization.md 相关的参数逐个过了一遍，才明白这引擎的设计哲学——每个优化项背后都对应一套内存管理和调度策略，如果你不理解它为什么要这么设计，配置起来就只能靠猜。这篇文章就是围绕 vllm 文档中 optimization 相关的核心内容展开的，目标很明确：讲清楚 vllm 性能优化背后的几个关键机制，包括 PagedAttention 显存管理、Continuous Batching 动态调度、KV Cache 量化、并行策略、精度选择等，然后给出可以直接套用的配置思路和排障经验。适合正在部署 vllm 的算法工程师、后端开发，以及准备做 LLM 推理优化的技术人员。你要是已经把 vllm 跑起来了但觉得性能还有瓶颈，这篇应该对你有帮助。2. vllm 优化机制的核心思想：先理解内存和调度，再谈配置vllm 被广泛使用，核心不是“能跑模型”，而是它的推理调度机制比传统方案高出一个量级。优化配置之所以重要，是因为几乎所有性能参数都围绕两个底层机制展开：PagedAttention 和 Continuous Batching。你不理解这两个机制，配置参数就是摸着石头过河；理解了，再看文档里每个参数就都有明确指向了。2.1 PagedAttention 到底做了什么传统的大模型推理框架在显存管理上有一个通病：预分配。比如某个请求最多生成长度为 2048 的序列，框架就会按这个上限预留完整显存块。但实际请求可能只输出几十个 token 就结束了，预留的显存就白白浪费了。更糟糕的是，不同请求的序列长度差异很大，显存碎片化严重，导致 GPU 利用率怎么也提不上去。vllm 借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的物理块（block），每个块可以存储固定数量的 token 对应的键值对。逻辑上每个序列是一段连续空间，物理上这些块可以分散在显存的不同位置。需要用哪个 token 的 KV Cache，就通过 block table 索引过去，跟操作系统的页表一样。这套机制就是 PagedAttention。这个设计带来的直接好处：显存利用率接近真实需求，而不是按最大可能长度预分配。理论上，同样的显存，vllm 能承载的并发请求数远多于传统方案。在实际测试中，同样的模型和显存，vllm 的吞吐量相比 naive 实现往往有几倍的提升，主要就来自这里。2.2 Continuous Batching：把“等”的时间变成“算”的时间传统推理服务通常采用静态批处理：攒够一批请求，一起前向传播，等这批全部生成完毕，再处理下一批。问题很明显：批内的请求长度参差不齐，短请求早早就结束了，但必须等待长请求完成，GPU 在“等待”时段就闲置了。vllm 的 Continuous Batching 是迭代级调度。每个 forward step 之后，已经结束的请求立刻移出批次，新到达的请求马上加入。这样 GPU 一直在处理存量请求，不需要等整批结束。配合 PagedAttention 的细粒度显存管理，每一迭代的批大小几乎都能打满显存预算。这也是为什么你会在配置里看到max_num_seqs和max_num_batched_tokens这类参数——它们本质上是在控制“每一迭代放多少个序列进来”以及“一次前向最多吃多少个 token”。这两个值设多高，直接影响显存占用和调度延迟之间的平衡，后面我会细说。2.3 优化配置的本质：在吞吐量和延迟之间找平衡理解上述机制后，一切优化配置都可以归纳为一个问题：在有限显存里，如何让 GPU 每个迭代的计算尽量满、调度开销尽量低、首 token 延迟尽量小。这三者之间存在矛盾。追求吞吐量，就要把显存尽量填满，批次尽量大，但这会让每个请求排队时间变长。追求首 token 延迟（TTFT），就要让新请求尽快进入计算，但频繁插队会打乱预填充和生成阶段的整合。追求单请求生成速度（TPOT），就要减少同批内的序列数，但 GPU 利用率会下降。所以你看 vllm 的配置文档，它给了一大堆可选参数，但没有一个“万能配置”，因为不同业务场景对这三者的权重完全不同。这也是我建议所有使用 vllm 的人，先想清楚自己的核心指标再动配置的原因。3. 核心参数逐项拆解：每个配置的作用和取舍逻辑vllm 的配置文件里参数很多，但真正直接影响推理性能的，核心就十几个。我按内存管理、调度策略、精度策略、并行策略四个维度分组来拆，每组都给出我实测时的调参经验。3.1 显存控制三件套：gpu-memory-utilization、max-model-len、block-sizegpu-memory-utilization是第一个要看的参数，默认0.9。它控制 KV Cache 最多能占 GPU 显存的比例。剩余部分留给模型权重和计算过程中的临时激活值。很多人一上来就把它设成 0.95 甚至 0.98，以为显存用得越满越好。实际这个值太大，激活值显存不够时会出现 torch 层面的 OOM，而且这种 OOM 比较难排查，因为报错不在 vllm 的日志里，而是在 CUDA 层。我建议先按 0.85 起步，观察nvidia-smi里显存峰值是否逼近上限且不 OOM，再逐步上调。如果发现 vllm 启动时报 “No available memory for the cache blocks” 之类的问题，说明显存不够，优先调小这个数，而不是调大。max-model-len控制模型接受的最大序列长度。它直接影响单个序列最多占用多少 block，进而决定 KV Cache 能容纳多少并发序列。比如某个模型上下文窗口支持 32k，但你的业务实际最多用 4k，那就把max-model-len设成 4096 或 8192 而不是 32768。这样每个序列占用的 KV Cache 少了，能并发执行的请求数大幅上升，吞吐量会有非常明显的提升。block-size是 PagedAttention 的物理块大小，默认 16，指每个块存储 16 个 token 的 KV Cache。这个值小，显存分配更灵活，碎片更少，但 block table 的索引开销更大；值大，索引开销小，但显存可能浪费。实测下来，16 是个稳妥的默认值，一般不需要动。除非你的模型比较小、显存不大，想降低调度开销，可以试试 32，但提升有限。3.2 调度相关的三个关键参数：max-num-seqs、max-num-batched-tokens、enable-chunked-prefillmax-num-seqs默认 256，表示一次迭代最多处理的序列数。设太小，连续批处理的效果打折扣；设太大，批次过大导致单次 forward 太慢，每个请求的生成延迟上升。如果是离线批量任务，可以适当提高；在线服务则要结合延迟要求来调。max-num-batched-tokens限制一次前向最多处理的 token 总数。这个值是控制“计算量”的关键，默认在低版本中是 2048，新版本会按显存自动调整。如果预填充阶段的序列很长，且这个值太小，一个长序列的预填充就要分成多次迭代完成，虽然不会出错，但会产生不必要的调度开销，降低吞吐量。如果你的场景是长文档摘要这类输入很长的任务，建议把这值调大，比如 8192 或 16384，让长 prompt 的预填充一次完成。enable-chunked-prefill是 vllm 较新版本才支持的功能。传统机制里，预填充阶段和生成阶段不会混合到同一个迭代里。如果来了一个很长的 prompt，预填充占用了整个迭代，生成阶段的请求就得等，造成延迟抖动。开启 chunked prefill 后，长 prompt 会被切成块，穿插到生成迭代的空闲 slot 里，这样可以显著降低长输入场景下的延迟波动。代价是总吞吐量会轻微下降。如果业务中既有长输入又有短输入混合，这个选项值得开。3.3 量化与精度配置：FP8、INT8、AWQ、GPTQ 怎么选vllm 工程化做得好的一个表现是量化支持非常全。文档里 optimization 部分专门有一节讲 KV Cache 量化和 weight 量化，配置参数主要是-q或--quantization，以及--kv-cache-dtype。先说 KV Cache 量化。KV Cache 在长序列、大并发场景下占据显存大头，将其量化为 FP8 可以节省约一半显存，而模型质量损失通常非常小。我的实际经验是，在 7B 到 70B 规模模型上，FP8 KV Cache 对输出质量的影响基本可以忽略，但显存占用下降明显。比如原来只能并发 8 个请求的场景，开 KV Cache FP8 之后能上到 12 到 16 个。参数写法是--kv-cache-dtype fp8。Weight 量化方面，vllm 支持常见的 GPTQ、AWQ、FP8、INT8 等。选择标准很简单：你的模型本身有没有量化版本。比如开源社区很多模型已经出了 AWQ 或 GPTQ 版本，直接用--quantization awq加载即可。FP8 量化则需要 GPU 支持（H 系列等），而且需要原始权重先转换。我建议在工程实践中优先选择社区验证过的 AWQ 量化权重，兼容性好，速度提升也稳定。在 4090 这类消费卡上，AWQ 相比 FP16 通常有 1.5 倍以上吞吐提升。需要特别提醒：量化不是免费的午餐。小模型量化后精度下降更明显，比如 1B 以下的模型，AWQ 量化后输出质量波动较大。7B 以上模型则风险小很多。生产环境上线前，建议准备一组标准测试集，量化前后对比输出质量再做决定。3.4 并行策略：数据并行、Tensor 并行、Pipeline 并行怎么搭配vllm 文档里和并行相关的主要是--tensor-parallel-size和--pipeline-parallel-size，多机多卡部署时还会涉及分布式推理配置。Tensor Parallelism 是把一个模型切到多张卡上，每张卡负责一部分层或一部分注意力头。这是 vllm 最常用的并行方式。比如 70B 模型在 4 张 80G 显存的卡上跑，通常会用--tensor-parallel-size 4。注意：TP 会带来 GPU 间通信开销，不是卡的张数越多越好。实测中，2 卡到 4 卡通常有接近线性的吞吐提升，8 卡以上收益就明显递减。Pipeline Parallelism 是把模型按层切分，每张卡负责其中若干层。vllm 对 PP 的支持相比 TP 要弱一些，因为它和 Continuous Batching 的调度耦合较深。一般来说，单机多卡优先选 TP；跨多机时，通常优先保证 TP 在节点内，再考虑节点间的数据并行。多副本数据并行方面，vllm 通过推理服务网关或前端负载均衡来做，它本身专注单引擎的高吞吐。若单引擎吞吐已达瓶颈，再部署多个副本，前面加一层负载均衡，这是常见的扩展路径。4. 实战配置：两种典型场景的参数组合讲完参数，直接给配置组合。下面是我在两类场景里反复验证过的方案，你可以作为起点再微调。4.1 离线批量推理场景：追求吞吐量，可以牺牲部分延迟离线批量任务，比如大规模知识库向量化、批量文本分类、离线摘要生成，核心指标是总处理时间。延迟要求宽松，但显存利用率要拉满。实测配置建议：参数设置说明--gpu-memory-utilization0.92~0.95离线任务可激进占满显存--max-num-seqs256 或更高提高并发序列数--max-num-batched-tokens8192 或 16384长输入场景适当调大--max-model-len按业务实际长度设置不要贪大--kv-cache-dtypefp8显存减半，提升并发--quantization根据模型选 AWQ/FP8有量化权重优先用--enable-chunked-prefill视情况关闭离线任务追求吞吐优先在某个离线摘要项目中，我处理一批 4 万篇长文档，用默认配置跑了 6 个多小时。调整了以上参数后，实际耗时降到了 2 小时左右，主要收益来自三块：max-num-batched-tokens调大后预填充效率提升、KV Cache FP8 后并发数提高了近一倍、量化权重让单位 token 的算力开销下降。如果你追求更进一步，还可以考虑把--max-num-seqs设成 512，但要盯着显存使用率，如果 preemption（抢占）比例过高，说明超过了实际承载能力，反而会拖慢整体速度。4.2 在线服务场景：TTFT 和 TPOT 优先在线服务，比如聊天助手、实时翻译、RAG 问答，核心指标是首 token 延迟（TTFT）和单 token 生成延迟（TPOT），要求响应平滑，不能出现明显的排队抖动。实测配置建议：参数设置说明--gpu-memory-utilization0.85~0.90留出余量避免显存抖动--max-num-seqs64~128控制排队长度--max-num-batched-tokens4096~8192适当限制单步计算量--enable-chunked-prefill开启（长输入混合时）减少长 prompt 引发的抖动--max-model-len尽量匹配业务上限避免长尾请求失败在线场景还有一个容易被忽视的点：--max-prompt-length或服务端的超时控制。如果允许单个请求的 prompt 很长，它会在预填充阶段占住大量调度资源，导致后面所有请求的 TTFT 飙升。所以在线场景通常要做输入长度限制，超出直接拒绝或截断，保护整体服务水平。我曾经优化过一个 RAG 问答服务的 vllm 配置，最初 TTFT 的 P95 是 2.8 秒，用户体验明显不好。把max-num-seqs从 256 调到 96，同时开启 chunked prefill 后，TTFT 的 P95 降到 1.1 秒，TPOT 稳定在 50ms 左右。表面上看并发序列数降低了，但因为请求排队轮转更快，用户体验反而明显提升。这个案例很典型：在线场景不要只看显存是否打满，要看延迟分布。4.3 显存不足时如何评估是否值得升级 GPU很多人在配置 vllm 时发现显存不够用，第一反应是换更大的卡。但有时候并不一定需要，先算一下账。KV Cache 的显存需求大约等于：总显存 × gpu-memory-utilization − 模型权重占用的显存。模型权重显存大约是参数量 × 字节数。以 7B 模型为例，FP16 权重约 14GB，INT8 约 7GB，FP8 约 7GB。如果一张 24GB 的卡，gpu-memory-utilization=0.9，可用显存 21.6GB，FP16 权重下 KV Cache 大约只有 7.6GB。你算一下这个值，再对照实际业务并发需求，就知道瓶颈在哪了。如果 KV Cache 太少导致并发上不去，优先考虑换量化方案（权重量化 + KV Cache 量化），而不是直接换大卡。因为换卡要额外花钱、改环境，而量化通常能让你在现有卡上就获得 1.5 到 2 倍的并发提升。在某个项目里，我帮同事优化一个基于 13B 模型的服务，原本要上 2 张 4090 才能满足需求，后来改成 AWQ 量化加 KV Cache FP8，单张 4090 就抗住了，第二张卡直接省下来。5. 常见问题与排查技巧实录vllm 排障和其他框架不太一样，它的错误信息有时候很含蓄，更多时候是“能跑，但性能不对”。下面这些是我和身边朋友实际踩过的坑，整理成速查表。5.1 典型问题速查表现象可能原因解决思路启动时报 “No available memory for the cache blocks”gpu-memory-utilization 过低或 max-model-len 过大调高利用率（注意别超），或调小 max-model-len运行中 torch.cuda.OutOfMemoryError激活值显存不足，模型过大或 batch 太大调低 max-num-seqs，或换量化权重服务整体吞吐低，GPU 利用率却不高max-num-seqs 设置太小，批次一直不满调大 max-num-seqs 和 max-num-batched-tokens部分请求延迟突然飙升长 prompt 预填充阻塞了生成请求开启 enable-chunked-prefill 试试输出质量明显下降量化精度设置不当，或小模型量化换回 FP16 对比测试后决定显存占用逐渐增长，疑似泄漏长连接推理服务的内存碎片定期重启服务，或检查 vllm 版本升级多卡 TP 模式吞吐不升反降Tensor parallel size 设过大，通信开销过高降为 2 或 4，观察扩展比preemption 过多，日志大量显示抢占显存不足、调度过于拥挤调低 max-num-seqs，或增大 KV Cache 空间5.2 preemption 的高发场景和避坑preemption 是 vllm 在显存不足时，把一个序列的 KV Cache 从显存里移走（换出到 CPU，或者全部重算）的机制。它有两种策略：recompute 和 swap。recompute 是把被抢占序列之前生成的 token 全部丢弃，等显存有空位再重新计算；swap 则是把 KV Cache 换到 CPU 内存里，等需要时再换回。从实际效果看，swap 通常比 recompute 更平滑，但 CPU 和 GPU 之间的 PCIe 传输会成为瓶颈。如果频繁出现 swap，吞吐量会显著下降。配置参数上，vllm 的--swap-space控制 CPU 侧 swap 空间大小，但这是兜底机制，不要指望靠它解决显存不足。我排查 preemption 的经验是：先看日志统计里 preemption 次数。如果次数超过总请求数的 5%，说明批次配置偏大或显存预算偏紧，应该调低max-num-seqs或调低gpu-memory-utilization给 KV Cache 更多空间。有些场景换到 FP8 KV Cache 后，preemption 直接降到接近零，这是因为每个序列占的 block 数减半了，同等显存能容纳的序列数翻倍。5.3 性能监控：不要只看 nvidia-smi很多人调 vllm 性能时喜欢盯着nvidia-smi看显存占用。但显存占用高并不代表吞吐高，也可能是批次太小、显存预分配导致的假象。vllm 自带 metrics 服务，在启动时加上--metrics相关的参数（vllm 服务默认暴露 Prometheus 格式的 metrics），可以看到更关键的指标，比如：当前正在处理的请求数preemption 次数各阶段平均耗时（预填充时间、解码时间）吞吐量（tokens per second）我的建议是至少记录三个指标：请求排队时间、preemption 次数、生成吞吐量。这三个指标能帮你判断瓶颈在调度层、显存层还是计算层。比如排队时间长，但生成吞吐量很高，说明是请求到达速率超过了处理速率，需要加副本而不是调参数；preemption 次数多，优先调显存和 batch 参数；生成吞吐量低但 GPU 利用率高，考虑推理引擎本身的能力边界。我遇到过一种情况：GPU 利用率看着有 90% 以上，但吞吐量就是上不去，后来发现是max-num-seqs设太大，导致每个迭代里序列很多但每个序列都很短，单次 forward 的小矩阵运算多了，GPU 算力浪费在调度和 kernel 启动上。把序列数降下来、batch tokens 设得更合理，吞吐量反而涨了。这种反直觉的问题，不靠 metrics 分析很难定位。5.4 换卡和换模型时的配置迁移还有一个常见问题：模型从 7B 换成 13B，或从单卡换成多卡，配置能直接沿用吗？答案是最好不要。模型尺寸变了，权重显存、KV Cache block 数量、激活值显存都会变，直接沿用旧配置往往会出现 OOM 或性能下降。我建议每次换模型或换 GPU 环境后，用一个固定 prompt 集做一次压测，观察显存占用和吞吐，然后按上面说的参数分组逐项微调。不要迷信旧配置在多场景下的通用性。vllm 的配置本来就是性能调优的起点，不是终点。6. 一些值得深入的方向和补充思路vllm 的 optimization 文档中还有一些容易被忽略但值得研究的内容，简单展开一下，供有精力的读者深入。6.1 投机解码（Speculative Decoding）的实际收益vllm 支持 speculative decoding，核心思路是用一个小模型草拟多个候选 token，再由大模型并行验证。如果小模型草拟的 token 与大模型一致，大模型一次 forward 就能生成多个 token，相当于解码速度翻倍。这个方案对单请求低延迟场景非常有效，但对小模型的质量要求较高。在实际测试中，小模型和大模型分布越接近，收益越明显。如果两者差异过大，草拟准确率低，大模型频繁拒绝，收益反而被额外计算抵消。想尝试的话，可以在启动参数里指定 draft model 相关配置。这个方向适合对单 token 延迟有极致要求的场景，比如实时对话。6.2 结构化输出对 KV Cache 和调度的影响如果你的业务要求模型输出 JSON 或特定格式，vllm 提供了结构化输出相关的限制机制。它和优化配置的关系在于：结构化限制会改变生成阶段的行为——模型在每一步生成时会被约束选择合法 token。虽然这让输出更符合格式预期，但也略微增加了单步计算量。在性能敏感场景，要评估这部分额外开销是否值得。我的经验是，格式错误造成的下游解析成本往往更高，所以结构化输出通常利大于弊。6.3 版本升级对配置的隐性影响vllm 迭代非常快，版本升级时默认值经常变化。我遇到过从 0.4 升到 0.6 后，原本跑得好好的配置突然 OOM 的情况，原因是新版默认启用了更激进的内存复用策略。所以每次升级后，建议先小流量灰度，对比压测结果，不要直接全量切。这个习惯可以帮你避开很多坑。7. 个人经验总结与建议说了这么多，最后聊点纯个人经验。vllm 的优化配置本质上是一个“显存换吞吐”的工程优化过程，没有脱离场景的参数组合，也没有永远最优的配置。但有几个原则我每次都会先确认：第一，先量化你的业务长度分布。很多人跑 vllm 不统计 prompt 和 completion 的实际长度分布，全凭感觉设置max-model-len，试来试去性能上不去。花五分钟统计一下业务数据，把最大长度和尤其是 P95 长度搞清楚，配置就有了量化依据。第二，每次只动一个参数。vllm 参数之间相互耦合，一次调好几个参数，出了问题根本不知道是哪一步引起的。我的习惯是搭一个标准压测脚本，固定测试集和并发模型，每次改一个参数记录吞吐和延迟，最后汇总再综合调整。这个方法虽然慢，但最可靠，不玄学。第三，定期看官方更新。vllm 团队对调度和显存管理的优化一直没有停过，很多新版本的默认行为比旧版好得多。如果生产环境有条件，保持每三个月左右的版本升级节奏，同时用你的压测脚本验证，能得到持续的性能收益。最后给一个小技巧：在 vllm 服务启动参数里加上--verbose或看日志中的调度统计，启动后观察前几百个请求的调度行为。如果日志里频繁出现 preemption 相关提示，就不要急着加大并发，先把显存配置凑稳再说。很多时候性能问题不是参数不够激进，而是基础配置不匹配。希望这篇经验能让你少走一些弯路。你的业务形态如果和我的场景差别很大，欢迎拿文档中的参数继续交叉验证，vllm 的优化空间远比表面看到的更大。