摘要：很多团队把它vLLM 当 demo 跑，但是其实这没把它系统能力发挥出来。这篇文章将介绍怎么让 vLLM 真正干活——持续输出高令牌/秒，哪些参数真正有用，以及怎么在延迟和成本之间做取舍。
很多团队把它vLLM 当 demo 跑，但是其实这没把它系统能力发挥出来。这篇文章将介绍怎么让 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 一样，令牌的预算可能天差地别。规划容量要用输入加输出的令牌/秒。设 C 是选定批处理形状下单 GPU 的持续令牌/秒，容量约等于 GPU 数量x C x 利用率。利用率保持在 70-85% 能吸收峰值，再高就该横向扩了。
有时候 90% 的利用率会莫名其妙的慢，所以尽量不要到达这个临界值。
# pull a vLLM image with your preferred modeldocker 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 falseAWQ 模型做了权重 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 专心批处理不需要管流控。背压机制也是要有的，慢消费者会拖累流式输出，所以一定要将服务器端超时和最大队列长度设好。
7B 模型的上下文控制在 2-3k 令牌，再长注意力成本是二次方，质量提升有限。检索后修剪也很重要，删掉近似重复的块，只留高分句子。静态前导加动态事实的结构，前缀缓存命中率最高。
仪表板最少得有这些：TTFT 的 p50 和 p95，令牌/秒（输入、输出、总计），活跃序列数和 KV 缓存利用率，批处理大小分布随时间变化，调度器队列长度和准入拒绝率，OOM 和驱逐事件。
活跃序列数饱和或者 KV 缓存接近 100% 的时候 TTFT p95 飙升，说明容量到头了，横向扩或者减模型长度。
全局最大上下文设太大，KV 页巨大并行度差，解决方法是设合理的 --max-model-len，长上下文只在需要时开单独层级。
每个租户 prompt 随机没法复用前缀，解决方案是标准化样板用模板。
输出不限制单个请求霸占调度器，可以在端点层面限 max_tokens。
所有流量打一个 worker，而GPU 闲置，需要在智能网关后跑多 worker 按桶分片。
仪表板只看 QPS 属于监控的混乱，要把令牌/秒和 TTFT 提到优先级，缓存饱和加告警。
来源：deephub
