vLLM深度优化指南，涵盖批处理、量化、缓存配置等核心策略，助您大幅提升LLM推理吞吐量和效率。
原文标题：vLLM 性能优化实战：批处理、量化与缓存配置方案
原文作者：数据派THU
冷月清谈：
性能调优的关键点包括：
1. **批处理大小的策略性选择：** 针对不同场景（低TTFT的聊天交互或高吞吐的批量任务），合理配置批处理大小，并通过网关层限制单请求最大令牌数，甚至可依据输出长度将请求分流至独立vLLM worker以稳定延迟。
2. **前缀缓存的利用：** 通过标准化系统提示词、few-shot示例及RAG模板，可有效复用KV缓存，实现零成本的性能提升。
3. **量化技术的应用：** AWQ或RTN等4-bit权重量化技术能显著节省内存，支持更高的并发序列数，在内存紧张时应积极采用，其带来的并发收益通常远超微小的质量损失。KV缓存的量化也是一个方向。
4. **重要并发参数的配置：** `--max-num-seqs`（限制并发序列数）、`--max-model-len`（设置模型上下文长度）、`--tensor-parallel-size`（多卡并行）及`--gpu-memory-utilization`（预留GPU内存）等参数需根据实际工况精准调优，切忌盲目拉满。
5. **基于令牌率的容量规划：** 容量规划应以输入加输出的“令牌/秒”而非QPS为基准，并保持70-85%的利用率以应对峰值请求。
6. **生产配置与调度：** 提供了AWQ模型部署示例，并强调了在多租户环境下采用`--enforce-eager`和`--trust-remote-code=false`的重要性。对于混合工作负载，建议设立独立的短任务和长任务处理池，并配合网关层的准入控制和背压机制。
7. **RAG场景的优化：** 建议7B模型上下文控制在2-3k令牌，并通过检索后修剪和结构化模板提升前缀缓存命中率。全面的监控仪表板是确保系统稳定和快速定位性能瓶颈不可或缺的工具。
怜星夜思：
2、文章强调了前缀缓存是“白捡的性能”，但它依赖于请求共享相同前缀。在哪些实际应用场景下，很难实现前缀的标准化和复用，或者说，有哪些业务场景天然就要求每个请求的prompt差异巨大，导致前缀缓存效果不佳？有没有其他技术可以弥补这种情况下的性能损失？
3、文章提到KV缓存量化可能导致超长生成时质量轻微下降。在LLM应用中，哪些“质量下降”是用户可以接受的，哪些又是完全不能容忍的？我们如何量化评估这种质量下降，并找到性能增益与用户体验下降之间的最佳平衡点？
原文内容
来源：DeepHub IMBA本文约2000字，建议阅读5分钟本文将介绍怎么让 vLLM 真正干活。
很多团队把它vLLM 当 demo 跑，但是其实这没把它系统能力发挥出来。这篇文章将介绍怎么让 vLLM 真正干活——持续输出高令牌/秒，哪些参数真正有用，以及怎么在延迟和成本之间做取舍。
先说 vLLM 到底好在哪
vLLM 提供 OpenAI 兼容的 API，核心是 continuous batching 加上 PagedAttention。PagedAttention 用分页管理 KV 缓存，内存复用做得很高效，能同时跑多个序列，GPU 占用率拉满，还能流式输出令牌。
并且工作流程不复杂。请求进来带着 prompt ，调度器把它们切成微批次喂给 GPU，KV 缓存存着注意力的键值对，PagedAttention 按页分配避免碎片。相似的 prompt 可以跨请求复用 KV 页，这就是前缀缓存。并行度和内存怎么分配由你定，这是性能调优的核心。
批处理大小
批处理越大吞吐量越高，但尾部延迟也跟着涨。得先想清楚场景：聊天类交互要的是低 TTFT（首令牌延迟），批次小点；批量任务或者 RAG 管道追求高吞吐，TTFT 长点能接受。
网关层得限制单请求的最大令牌数，不然一个大请求能把队列堵死。多个中等大小的 prompt 比少数巨型 prompt 效果好，continuous batching 在形状规整时效率最高。如果能按输出长度分类（短/中/长），就给每类跑独立的 vLLM worker，延迟会稳定很多。
前缀缓存算是白捡的性能
两个请求共享相同前缀时——系统提示词、few-shot 示例、检索的引导文本——vLLM 直接复用 KV 缓存。这是零成本加速。
怎么设计才能吃到这个红利？可以及逆行系统提示词跨租户标准化，few-shot 示例保持完全一致，变量放用户输入里别放示例里。RAG 场景就把模板和指令缓存起来，每个请求只追加检索到的事实。
量化可以性能倍增器
AWQ 或 RTN 做 4-bit 权重量化，内存省了不少，perplexity也几乎不掉，这是服务端点的默认选择。KV 缓存也能量化，缓存占用减少意味着能跑更多并发序列，但代价是超长生成时质量可能轻微下降。
经验如下：GPU 内存紧张、调度器塞不下足够多序列时就量化。更多并行序列带来的收益通常远超全精度权重那点质量提升。
并发参数这几个很重要
--max-num-seqs 限制并发序列数，A100 级别的卡从 64-128 起步，往上调到 TTFT 开始变差为止。
--max-model-len 别设成模型理论最大值，除非真需要那么长，限制小点意味着 KV 页小，并行度高。
--tensor-parallel-size 是把大模型切到多卡，NVLink 这种快速互连是必须的，批次得够大才能掩盖通信开销。
--gpu-memory-utilization 留 10-15% 余量，应对流量尖峰时的 OOM。
千万别把所有参数都拉满然后指望调度器自己搞定，这个一定要实测。
容量规划看令牌率而不是 QPS
两个请求 QPS 一样，令牌的预算可能天差地别。规划容量要用输入加输出的令牌/秒。设 C 是选定批处理形状下单 GPU 的持续令牌/秒，容量约等于 GPU 数量x C x 利用率。利用率保持在 70-85% 能吸收峰值，再高就该横向扩了。
有时候 90% 的利用率会莫名其妙的慢，所以尽量不要到达这个临界值。
生产配置
# pull a vLLM image with your preferred model
docker run --gpus all --rm -p 8000:8000 \
-v /models:/models \
vllm/server:latest \
--model /models/Qwen2.5-7B-Instruct-AWQ \
--dtype auto \
--tensor-parallel-size 1 \
--max-num-seqs 128 \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--enforce-eager \
--trust-remote-code false
AWQ 模型做了权重 4-bit 量化，部署密度高。--enforce-eager 避免混合流量下漫长的 CUDA graph 预热，流量模式统一且要 CUDA graph 优化时再关掉。--trust-remote-code=false 在多租户环境保持安全。
OpenAI 兼容的请求写法如下：
curl http://localhost:8000/v1/chat/completions \
-H"Content-Type: application/json" \
-d'{
"model":"Qwen2.5-7B-Instruct-AWQ",
"messages":[{"role":"user","content":"Write a haiku about GPUs"}],
"stream":true,
"max_tokens":128,
"temperature":0.3
}'
调度和公平性
工作负载如果混了短生成和长生成，跑两个池：短任务优先池和长任务池。TTFT 保持合理范围，批量吞吐也不损失。准入控制在网关层做，按租户限令牌速率，vLLM 专心批处理不需要管流控。背压机制也是要有的，慢消费者会拖累流式输出，所以一定要将服务器端超时和最大队列长度设好。
RAG 令牌长度
7B 模型的上下文控制在 2-3k 令牌，再长注意力成本是二次方，质量提升有限。检索后修剪也很重要，删掉近似重复的块，只留高分句子。静态前导加动态事实的结构，前缀缓存命中率最高。
监控必须要有
仪表板最少得有这些：TTFT 的 p50 和 p95，令牌/秒（输入、输出、总计），活跃序列数和 KV 缓存利用率，批处理大小分布随时间变化，调度器队列长度和准入拒绝率，OOM 和驱逐事件。
活跃序列数饱和或者 KV 缓存接近 100% 的时候 TTFT p95 飙升，说明容量到头了，横向扩或者减模型长度。
常见坑和方案
全局最大上下文设太大，KV 页巨大并行度差，解决方法是设合理的 --max-model-len，长上下文只在需要时开单独层级。
每个租户 prompt 随机没法复用前缀，解决方案是标准化样板用模板。
输出不限制单个请求霸占调度器，可以在端点层面限 max_tokens。
所有流量打一个 worker，而GPU 闲置，需要在智能网关后跑多 worker 按桶分片。
仪表板只看 QPS 属于监控的混乱，要把令牌/秒和 TTFT 提到优先级，缓存饱和加告警。
总结
vLLM 的核心价值不是 prompt 技巧，是让 GPU 一直干活。令牌当预算单位，前缀设计好复用，上下文窗口别乱开，并发上限设实际点，吞吐量自然上去而且不会突然垮。
编辑：文婧
