企业官网建设流程全解析

1. 为什么vLLM的优化配置值得逐行研究

我最早接触vLLM时，和大多数人一样，第一件事就是跑一个默认参数的推理服务，能出结果就万事大吉。真正让我开始认真研究docs/configuration/optimization.md这份文档的契机，是一次实测：同样的模型、同样的并发压力，默认配置下P99延迟直接翻出两倍多，而吞吐量还低了一截。当时我以为是机器问题，后来才发现是几个默认开关和资源比例没有按场景调整。

先说结论：vLLM在高并发、长上下文、流式输出的场景下优势非常明显，但这些优势全部建立在“配置正确”的前提上。optimization.md对应的就是vLLM服务端的性能与显存优化参数，包括KV cache管理、预填充策略、批处理调度、量化推理后端等。这份文档解决的核心问题只有一个：在显存有限、并发不确定、模型大小不一的情况下，怎么把每一张卡的性能压榨出来，同时不让服务质量崩掉。

适合读这份文档的人大概有三类：第一类是做大模型服务的后端工程师，服务上线前要确定并发上限和显存规划；第二类是负责压测和容量评估的SRE，需要知道哪些参数会影响延迟分布；第三类是自己在单卡或双卡上跑开源模型的开发者，想在不买新卡的前提下提升吞吐。不管你是哪一类，建议按本文的顺序把配置项捋一遍，而不是看到哪个参数像就调哪个。

vLLM的优化文档有个特点：它不像框架的普通接口文档那样只罗列参数名和默认值，它更接近一份“性能调优手册”，很多参数之间是相互影响的。比如你改了gpu_memory_utilization，会影响KV cache可用空间；KV cache空间变了，max_num_batched_tokens的合理取值也会变；这两个变了，实际能支撑的并发又不同。所以单独看任何一个参数都无法真正理解文档，要看它们构成的系统。

2. 吞吐、延迟与显存：三个目标背后的配置博弈

2.1 先弄清优化到底在优化什么

vLLM的优化目标通常分成三块：吞吐量（throughput）、TTFT（Time to First Token，首Token延迟）、TPOT/ITL（每个输出Token的延迟或Token间延迟）。这三者在资源占用上是互相挤占的。optimization.md里的每一项配置，本质都是在调整这三者之间的天平。

默认情况下，vLLM倾向于用连续批处理来提升吞吐，也就是让多个请求在推理引擎的调度中穿插执行。每次调度时，引擎会把当前所有等待中的序列拼进一个batch，然后并行算完当前步。这个设计对GPU利用率非常友好，但代价是单请求的延迟会随着并发上升。你看到“并发高但首Token很慢”的时候，先别急着怀疑网络，大概率是调度与KV cache参数没配合好。

理解这个博弈是理解整份优化文档的前提。后面所有配置，你都可以回到这个三角关系里问自己：我现在是要压低延迟，还是要拉高吞吐，还是要在显存受限时保住更多请求？答案不同，参数走向完全不同。

2.2 显存是怎么被瓜分的

GPU显存里同时躺着三样东西：模型权重、KV cache、推理过程中的中间激活值。optimization.md中反复出现的gpu_memory_utilization就是用来控制“前两者”总占用上限的。默认值通常是0.9，意思是允许vLLM拿90%的显存，其中扣掉模型权重后，剩下的都自动分配给KV cache。

这里有个新手常踩的坑：把gpu_memory_utilization提到0.95甚至0.98，以为能多塞点缓存。实际情况是，如果你的模型权重本身就占了很大比例，剩下的空间可能不足以支撑vLLM需要的最小KV cache，服务会直接启动失败，报一个类似于“Not enough memory”的错误。所以在调这个参数前，先确认你的模型权重占据了多少显存，留出至少10%-15%的余量给CUDA context、推理框架运行时和临时激活值。

另外，显存分配还会受到max_model_len的影响。KV cache按“最大序列长度”做预留，如果你设置了一个非常大的max_model_len，引擎必须按这个上限预分配KV cache块。哪怕实际请求都是短文本，显存也已经按长序列预留了。反过来，把max_model_len设置为接近你业务的真实上限，能立刻释放大量显存用于并发。

2.3 KV cache块大小和高并发的关系

vLLM的KV cache不是一次性给每个请求分整段显存的，而是以block为单位，按需分配。block大小由block_size决定，文档里通常建议保持默认。这个设计的好处是显存利用率高，序列长短不一也不会互相浪费；坏处是block太小会让管理开销变大，block太大则长序列增长时可能有一整块只用了很小一部分。

在实际压测中我发现一个规律：并发请求越长、块数越多，block_size对性能的影响越明显。短文本场景下，block_size调大调小区别不大；长文本、高并发的场景，稍微偏小的block能减少末尾浪费，但会让调度稍微多花点时间。这个参数一般保持默认就好，不建议业务侧随意改。

还有一个容易被忽略的关联参数是num_gpu_blocks_util类的动态信息，它会告诉你在运行中KV cache block的占用比例。如果接近90%以上，说明系统已经接近容量上限，继续加并发会出现排队或拒绝。此时与其调gpu_memory_utilization，不如先压max_model_len或换量化权重，因为block耗尽意味着物理空间确实不够了。

3. 连续批处理与预填充拆分：并发吞吐的两个核心玩法

3.1 连续批处理不是简单的“多请求排队”

很多人以为vLLM的高吞吐来自“把多个请求塞进一个batch”，其实没那么简单。真正关键的是连续批处理（continuous batching）：每个请求内部的解码步不是等整批全部跑完再进入下一步，而是任何一个序列只要准备进入下一步，就可以被调度器放进正在执行的batch里。这样新请求能及时插入、已完成请求能立刻让出位置，GPU始终在算，而不是在等。

vLLM默认是启用连续批处理的，你不需要专门开一个开关。需要你操心的是max_num_batched_tokens或对应版本里的max_num_seqs。前者限制了一次调度中参与计算的Token总量，后者限制了batch里的最大序列数。这个上限决定了单次前向传播中KV cache的访问跨度。跨度越大，显存带宽压力越大，但吞吐上限也越高。

如果你的业务是大量短请求，比如对话助手，建议让max_num_seqs高一些，从而允许更多并发请求同时进入调度。如果业务是长文档总结、代码生成这类单请求长序列，则更适合调高max_num_batched_tokens，让一个长序列的多个Token在单次前向中被批量处理，而不是被短请求频繁打断。

3.2 Chunked Prefill：把长提示词的预填充切成小块

长提示词请求到达时，vLLM会先进入预填充阶段，把整个提示词算一遍，生成KV cache，然后才进入解码阶段。传统方式是“一次性全部算完”，这个阶段GPU算力用得很猛，但显存带宽用不上，而且整个阶段内该请求不会产出任何可读的Token，TTFT会被拉得很长。

Chunked prefill把预填充切成多个小段，允许预填充和解码阶段交错执行。直观效果是：一个长提示词的请求进来了，它不需要独占GPU跑完预填充，引擎可以先算其中一段，穿插几个其他请求的解码步，再回来继续算下一段。这样单个长请求的TTFT没有减少，但整个batch的吞吐上去了，其他短请求也不会被长请求“堵死”。

这就是optimization.md里chunked_prefill相关参数的用意。如果你的场景里存在“少数超长提示词”和“大量短请求”混合，这个功能几乎是必需品。默认情况下新版vLLM已经默认启用或建议启用，但你需要关注它的配合参数：chunk大小决定了每次预填充最多占用的Token/序列比例。切得越小，调度越灵活，但增加了计算次数；切得越大，长请求的TTFT越短，但可能阻塞其他请求。

我建议的实测路径是：先保持默认，构造一组混合负载，然后逐步缩小 chunk size，观察吞吐变化。如果吞吐没有明显提升，就说明长请求占比还不够高，没必要继续切小。

3.3 调度器与队列长度：并发上限其实是你自己设的

optimization.md里还有一个值得注意的点是请求调度策略和队列上限。vLLM默认根据显存和配置计算能容纳多少KV cache block，并据此决定当前能同时处理多少个序列。如果你没有显式调整max_num_seqs，实际并发能力完全由“KV cache可用block数”反推。

这里我踩过一次狠的：某次我把max_model_len调大了一倍，结果KV cache可容纳的序列数骤降，压测时并发一高就大量排队，还以为代码有问题。查了半天，才发现是KV cache总容量不变的情况下，单个序列的块数增加，能服务的并发自然下降。所以当你发现并发上不去时，先算一笔账：max_model_len × 层数 × 头数 × 精度字节数就是每个序列占用的KV cache量，用它去除总KV cache容量，才是理论上的并发上限。

调度队列如果超出上限，请求会进入等待队列。等待队列本身不在显存中占KV cache，但它占内存，且会直接影响用户体验。如果你有严格的SLA，建议把队列长度上限调低，宁可返回“繁忙”也不要无限排队。这属于产品策略问题，但配置上确实是由你手上的参数决定的。

4. 服务端参数优化：从实际压测看前后端配合

4.1 并行采样与beam search：默认配置不能满足所有场景

optimization.md里对采样相关参数着墨不多，但它在服务端配置里却极其关键。很多人以为采样参数只影响结果质量，不影响性能。实际上，vLLM对单个请求的n个并行采样和beam search的处理方式完全不同。

比如你设置了n=4，也就是一个请求回来4条候选，vLLM内部会把它当成4条独立的序列去调度，每条都占用独立的KV cache block。这个行为在文档里虽然没有大篇幅强调，但你必须清楚：一个并发请求拉4条结果，相当于4倍并发。如果你压测时只数“请求数”，没数“序列数”，性能数字会非常不可信。

beam search同理，vLLM虽然支持，但它的beam状态管理要维护比普通采样更多的候选。从性能角度，我个人的建议是：能用普通采样让应用层多路请求，就不要用beam search。因为beam search的中间状态存储与恢复完全在引擎内完成，对KV cache的占用方式比普通采样更复杂，而且很难用gpu_memory_utilization直接约束。

做部署评估时，请把“峰值并发下的总序列数”而不是“请求数”作为容量指标。这是一个非常容易被忽略、但影响规划准确性的核心细节。

4.2 前缀缓存（Prefix Caching）：省算力的开关，也是显存刺客

前缀缓存是vLLM针对“多轮对话、多请求共享相同前置内容”场景的优化。它会把某个Prompt的前缀计算出来的KV cache块缓存住，下一个请求如果前缀相同，直接复用，不用重新计算。对系统提示词很长的对话应用，这个功能能把吞吐提升一大截。

但它的代价也很直接：缓存要占KV cache空间。如果前缀复用率不高，缓存占用的块会造成浪费。文档中关于前缀缓存的建议是：要么通过参数显式控制，要么在系统提示词变动频繁时关闭它。因为提示词只要改一个字符，缓存就全部失效。

我在项目里验证过：系统提示词基本固定、只有尾部用户输入变化时，前缀缓存能减少大概30%-40%的重复预填充时间。但一旦提示词模板按版本频繁迭代，收益就会归零，还剩下一堆过期的缓存块在显存里等淘汰。这种时候不如关掉缓存，把显存让给KV cache扩容。

4.3 日志、监控与额外开关：别让服务端把吞吐吃掉

除了文档焦点参数，服务端还有一些容易被忽略但对性能有实际影响的配置。比如日志级别调成debug时，每个请求的调度细节都会输出，日志写入会争抢CPU时间片，高并发下性能下降肉眼可见。上线时务必确认日志级别为info或warning。

另一个是流式输出与skip_special_tokens这类的后处理参数。虽然它们看起来和性能无关，但某些版本中后处理逻辑会阻塞工作线程。此类问题通常不会出现在单请求测试里，只会在并发拉高后暴露。碰到类似情况，建议用profiling工具看线程状态，别凭感觉改配置。

文档里通常还会提到与torch.compile和CUDA graph相关的开关。CUDA graph能减少kernel启动开销，对短序列、小batch场景尤其明显。但CUDA graph的捕获过程对动态shape敏感，如果你的输入长度变化太剧烈，捕获可能失败或回退。实际部署中，我会优先开启CUDA graph，然后压一轮请求长度分布；若发现频繁回退，再关掉对比效果。

5. 量化、权重加载与推理后端的取舍

5.1 量化的显存收益和精度损失，别只看一个维度

显存不够用时，量化通常是第一反应。vLLM支持多种量化方案，比如常见的INT8、INT4，以及某些更细粒度的分组量化。optimization.md中涉及量化相关的内容，核心思想是“以少量精度损失换取显存空间和计算速度”。

不同的量化方案，在显存节省和计算加速上的表现差异很大。以INT8量化为例，它能比较稳固地把KV cache相关显存需求降下来，同时对大多数业务场景的精度影响在可接受范围内。INT4则更激进，显存占用更低，但部分模型上的输出质量下降明显，尤其对数学、代码这类任务。

我建议不要一次性把所有层全部量化到底。vLLM允许更细粒度地控制哪些层被量化，但实际操作里多数人直接用统一配置。如果你在业务中发现了量化后的质量下降，尝试保留某些敏感层的原精度，是一个比整体回退更好的折中方案。

5.2 权重加载精度与序列长度的真实关系

优化文档中有一个很容易被忽略的参数，是权重加载的数据类型与KV cache的存储类型。KV cache不一定要和模型权重用同样的精度，比如权重用FP16，KV cache可以单独设置为INT8。这会带来两个效果：KV cache占用减半，可容纳的并发序列数上升；同时，解码过程中的KV cache读取带宽压力下降。

代价是精度下降，长序列下误差可能累计。我测试过某个70B级别的模型，在开启KV cache INT8后，短文本对话场景输出几乎无感知，但在长文档生成时，少数段落会出现轻度重复或跑偏。紧急情况下这个配置能救命，生产环境请务必在目标场景上做充分评测。

此外，dtype的设置要与衡量的语义对齐。很多人只看显存变化，却忽略了切换dtype之后吞吐也可能提升。因为显存带宽有时才是瓶颈，精度降低意味着同样时间能搬更多数据。反过来，如果你的瓶颈在算力不在显存，量化带来的吞吐提升就没那么明显。

5.3 推理后端的选择：CPU offload与多卡方案不要盲开

部分场景下，显存不够，文档会建议使用CPU offload，也就是把部分权重放到内存里，计算时再搬到显卡。这个功能听起来像“白嫖显存”，但实际上CPU到GPU的搬运带宽远低于显存带宽，只要offload的权重被频繁访问，性能就会严重恶化。

我的经验是：CPU offload只适合追求“能跑起来”的场景，比如演示、调试、偶尔推理；一旦进入持续在线服务，这个方案基本会让TPOT翻好几倍。预算允许的情况下，用多卡张量并行，把模型切分到多张卡上，比offload靠谱得多。

多卡并行时也要注意，optimization.md中关于Tensor Parallel的设置不是越大越好。卡间通信开销会随卡的增多而上升。比如一个70B模型，用4卡能跑，用8卡也能跑，但8卡的通信开销可能让部分算力被浪费。最稳妥的做法是跑一个可复现的压测脚本，固定同一组输入，逐一比较不同并行度的延迟，而不是背参数表。

6. 从启动日志读到优化空间：一套可复制的调优路径

6.1 启动日志里那些数字的真实含义

vLLM启动时会打印一大段日志，里面包含“GPU memory usage”“KV cache size”“maximum number of sequences”等信息。很多人瞟一眼就过去了，其实这些数字是第一个该看的优化指标。

我通常的读法是这样的：先看KV cache占显存的比例，如果低于20%，说明模型权重占比太高，可优化的空间有限，要么换量化，要么加卡。如果比例在40%-60%，说明配置比较合理，可以继续微调max_model_len和并发上限。如果比例高于70%，说明并发容量充足，但要注意长序列场景下是否有溢出风险。

这个“比例直觉”来源于多次压测经验，比任何文档公式都实用。你不需要手动算每一步，启动日志已经把结果算好了。你只需记住：KV cache比例不是越高越好，而是要与你的业务请求长度分布匹配。

6.2 一次完整调优该按什么顺序操作

调优最忌讳一上来就乱改参数。我整理了一套顺序，每次新场景都按这个路径走，省掉大量无效排查：

第一步，固定模型与硬件，用默认配置启动，记录启动日志中的KV cache大小和峰值并发估计。第二步，用业务侧的真实请求样本做一轮压测，记录TTFT、TPOT和吞吐基线。第三步，按max_model_len、gpu_memory_utilization、max_num_seqs的顺序逐个调整，每次只改一个参数，重新压测，对比基线。

第四步，开启前缀缓存并构造复用前缀的请求，验证收益。第五步，显存仍不足时，考虑KV cache量化或权重量化，并做精度对比。第六步，全部参数确定后，用混合负载做最终压测，确认调度是否稳定。

这个顺序背后的逻辑是：先确定显存边界，再调整并发和批处理，最后再做量化妥协。倒过来操作，很可能出现“量化后吞吐上去了，但并发增加了调度不稳”的情况，反而更难排查。

6.3 哪些配置组合最容易“翻车”

最后分享几个我亲测容易踩坑的配置组合，写在这儿给你当避雷清单。

第一，gpu_memory_utilization设置过高 + 同时开启前缀缓存。前缀缓存本身要占KV cache，显存利用率拉满时缓存空间不足，可能导致大量缓存被提前淘汰，前缀缓存形同虚设。第二，max_num_seqs调得过高 + 短并发请求极多，调度器需要频繁切换序列，CPU开销上升，反而压低了有效吞吐。第三，chunked prefill的chunk设得非常小 + 长Prompt占比高，预填充被切得太碎，计算重复次数增多，TTFT不降反升。

这些组合在文档里看起来都是“独立的”，实测中却会互相放大问题。所以配置的正确姿势不是把某个点调到极致，而是把所有参数按业务画像压在一个平衡区间。这个区间只能靠压测找，没有公式。

在做完这一轮配置之后，我的体会是：vLLM的optimization.md不是一份“填参数”的文档，而是一张显存与计算资源的分配地图。真正吃透它之后，你对任何推理服务的容量规划都会有个清晰的分析框架。碰到新模型、新显卡、新业务场景时，直接套用上面的调优路径重新走一遍，大多能在一个小时内得到接近合理的配置，剩下的偏差就交给更细粒度的压测去磨了。