Ollama 适合把模型跑起来，vLLM 适合把模型跑「多」——PagedAttention 把显存切成页来管理，让 KV Cache 的利用率接近极限，吞吐量相比朴素实现常有数倍提升。但从 demo 到生产，有三道坎要一道道过。

第一道：显存规划

vLLM 的核心参数 gpu_memory_utilization 决定了「留多少显存给模型和 KV Cache」。新手最常踩的坑是设得太满：留出来的余量不够处理峰值批次的激活值，直接 OOM。经验起点是 0.85-0.90，然后压测回调。

要算清三笔账：模型权重占多少、上下文长度决定单请求 KV Cache 占多少、吞吐目标决定并发数。上下文长度翻倍，KV Cache 翻倍——这笔账和之前聊 KV Cache 与前缀复用 时的账本是同一本。

第二道：并发与调度

vLLM 的 continuous batching 会自动把新请求插进正在解码的批次，吞吐由此而来。但要理解它的排队行为：上下文长的请求会霸占 KV Cache 页，短请求可能被挤压。流量结构不均匀时，给不同业务线拆实例，比调参数更有效。

流式输出场景记得关掉不必要的日志和采样开销；延迟敏感的场景，max_num_seqs 别贪大——并发上去了，单请求的延迟曲线会先缓后陡。

第三道：版本与快照

vLLM 迭代很快，版本间行为差异不小（采样默认值、调度策略都改过）。生产的纪律是：版本钉死，升级前跑基准。用 Docker 镜像固定版本，压测脚本记录吞吐、延迟分位数、显存峰值三个指标，升级前后各跑一遍——回归看数据，不看感觉。

小结

vLLM 的性能上限是社区的，生产下限是自己的。显存留余量、调度看流量结构、版本有钉死——三道坎都过完，才谈得上「跑在生产」。

说明：本文为公开资料的整理与评述，信息来源包括 vLLM 官方文档与社区生产实践分享，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。