说真的，这年头搞 LLM 部署，绕不开 vLLM。但我也见过太多人上来就 pip install vllm 然后直接 --model meta-llama/Llama-3.1-8B-Instruct 就指望能抗住生产流量——结果呢？监控炸了，P99 延迟飙到 10 秒，OOM 频繁到运维想骂娘。
这玩意儿不是装个包就能跑起来的。你得懂它的脾气。
别信默认配置，那是给开发机玩的
vLLM 的默认参数说白了就是让你在单卡上能跑通就行。真要上生产，第一件事就是忘掉 --max-model-len 和 --gpu-memory-utilization 的默认值。
我见过最离谱的案例：某团队用 4 张 A100 跑 70B 模型，max_num_seqs 设了 256，结果 KV Cache 直接爆了，服务每 5 分钟重启一次。为啥？因为他们以为这个参数只是限制并发数，不知道它直接影响 KV Cache 的内存预算。
vLLM 的核心矛盾：你要吞吐量就得塞更多序列进一个 batch，但每个序列都要吃 KV Cache 内存。vLLM 的调度器会先给每个序列预分配 max_model_len 长度的 KV Cache 空间。如果你的 max_num_seqs 设太大，GPU 显存根本扛不住。
那个配置计算器是真的香
6 月初 Reddit 上有人搞了个 vLLM Configuration Calculator，我试用了一下——说实话，比我自己手算快多了。你输入模型大小、GPU 型号、目标流量特征，它直接给你推荐 max_num_seqs、KV Cache 分配量，甚至能预测 P95 延迟。
实测下来，对我手头一个 7B 模型 + 单张 A10G 的场景，它推荐的 max_num_seqs=32 比我自己瞎调的 max_num_seqs=64 在 P99 延迟上降了 65%。当然，吞吐量也降了，但至少服务不会挂了。
我现在的流程是：先用这玩意儿算个基线，然后做压力测试微调。省了至少 80% 的初始配置时间。
连续批处理不是银弹
vLLM 最大的卖点是 continuous batching。但很多人不知道的是：如果你的请求长度差异极大，连续批处理的效率反而会下降。
举个栗子：你的应用里既有“翻译一句话”的短请求，也有“总结这篇论文”的长请求。vLLM 的调度器会尽量把同长度的请求塞在一起，但如果长短差距太大，短请求会被长请求拖死（因为要等 long-prefill 完成）。
我的经验：如果你的请求长度方差很大，考虑把服务拆成两个 endpoint——一个专门处理短文本（--max-model-len 2048），一个处理长文本（--max-model-len 32768）。这样每个实例的 batch 效率都能拉满。
Prefix Caching 是双刃剑
这个功能在 vLLM 0.6+ 版本里默认是关的，得手动开 --enable-prefix-caching。很多人开了之后发现显存占用直接翻倍——因为 prefix cache 本身就是存 KV Cache 的 hash 表。
但如果你做的是多轮对话或者 RAG 场景，这东西能省 30%-50% 的 prefill 时间。前提是你的 prompt 前缀要有足够的重复度。
我踩过的坑：开 prefix caching 后，第一次请求的延迟反而变高了（因为要建 hash 表）。所以如果你的服务是冷启动频繁的（比如 serverless），别开这玩意儿。
显存利用率到底设多少？
这是最常被问的问题。--gpu-memory-utilization 默认 0.9，但我建议你按场景来：
- 低延迟场景（比如实时聊天）：设 0.85，留点余量给峰值
- 高吞吐场景（比如批量推理）：可以干到 0.95
- 千万别设 1.0，你总得留点显存给模型权重之外的玩意儿（比如 CUDA 内核、临时张量）
我有个血的教训：有次设了 0.98，结果模型加载成功了，但第一个请求进来直接 OOM。因为 vLLM 计算 KV Cache 预算时没考虑 prefill 阶段的临时显存开销。
那门 DeepLearning.AI 的课值得看
6 月初 Andrew Ng 那边出了门 vLLM 的课，Cedric Clyburn 讲的。我花了 3 小时刷完，说实话比看文档强。里面讲了 continuous batching 的内存管理细节、prefix caching 的实现原理、还有 profiling 工具的使用。
最有用的是它教你用 vllm.entrypoints.openai.api_server 的 profiling 模式，能直接看到每个 step 的显存分配情况。这玩意儿文档里写得稀碎，但课里讲得挺清楚。
最佳实践速查表
| 配置项 | 推荐值 | 场景说明 | 踩坑记录 |
|---|---|---|---|
max_num_seqs | 16-64 | 根据显存和模型大小调 | 设太大导致 KV Cache OOM |
gpu_memory_utilization | 0.85-0.95 | 低延迟用 0.85，高吞吐用 0.95 | 设 1.0 会翻车 |
max_model_len | 按实际需求设 | 不要用默认值，按最长 prompt 设 | 设太大浪费显存 |
enable_prefix_caching | 按场景开 | 多轮对话/RAG 场景收益大 | 冷启动场景别开 |
tensor_parallel_size | 按 GPU 数量设 | 70B 模型至少 4 张 A100 | 跨节点 TP 延迟高 |
dtype | bfloat16 | 大部分场景 | float32 显存翻倍 |
kv_cache_dtype | fp8 (如果支持) | H100 优先 | A100 上收益有限 |
FAQ
Q: vLLM 和 TGI 比到底哪个好？
A: 看场景。vLLM 的内存管理更激进，同样显存下能塞更多并发。TGI 的稳定性更好，适合对延迟抖动敏感的场景。我个人的选择：80% 场景用 vLLM，20% 需要极致稳定的用 TGI。
Q: 单卡能跑多大的模型？
A: 用 24GB 显存（RTX 4090）跑 7B 模型（4-bit 量化）勉强可以，但并发只能到 4-8。想跑 70B 模型至少需要 4 张 A100 80GB 做张量并行。
Q: vLLM 支持多节点吗？
A: 支持，但延迟会明显增加。跨节点通信走 NCCL，网络瓶颈明显。我建议单节点内做 TP，多节点用 DP（数据并行）或者干脆拆成多个独立服务。
Q: 怎么监控 vLLM 的性能？
A: 最直接的是看 /metrics endpoint，Prometheus 格式。关键指标：vllm:num_requests_running、vllm:gpu_cache_usage、vllm:request_prompt_tokens。我们团队在 Grafana 上搭了个面板，一小时内定位了三次 OOM 问题。
Q: speculative decoding 值得开吗？
A: 如果你用 H100 跑小模型（<13B），开 --speculative-model 能提 1.5-2x 吞吐。但 A100 上收益有限，而且配置起来很麻烦——你得准备一个 draft model，还得调 --num_speculative_tokens。建议先关了，等吞吐量瓶颈了再考虑。
最后说一句
vLLM 的社区很活跃，但文档确实跟不上代码更新速度。Reddit 上的 r/vllm 和 r/mlops 比官方文档有用得多。我 90% 的配置知识都是从那里扒来的，包括那个计算器。
别指望一次性配置完美。先跑起来，监控，调参，再跑起来。这是唯一的路。