同样的 GPU、同样的模型裸跑 HuggingFace 推理和用 vLLM吞吐能差出一个数量级。差距不来自玄学来自一个叫 PagedAttention 的技术以及它背后对「显存」这件事的重新管理。这篇讲清楚它快在哪以及什么场景该用它。传统推理的显存浪费生成式推理的特点一个字一个字往外蹦每生成一个字都要把整个上下文算一遍。为 accommodate 可能的最长生成推理框架会提前给每个请求预留一大块连续显存放 KV 缓存模型处理过的上下文的中间结果。问题在于你不知道每个请求会生成多长。预留按最大长度来实际生成往往短得多——碎片化的预留空间用不上又不能给别人用实测浪费率能到六到八成。显存就这么白白空着吞吐自然上不去。PagedAttention把操作系统的解法搬过来vLLM 的核心思路借鉴了操作系统虚拟内存的分页把 KV 缓存切成固定大小的小块block按需分配逻辑上连续、物理上离散。请求要多少给多少显存利用率从三四成拉到九成以上。省下来的显存直接变成吞吐同样显存能塞下更多并发请求。官方数据中吞吐相较传统方案提升最高二十余倍实际项目里三五倍是常见兑现。附加的三个能力一是高效批处理请求随到随进批次continuous batching不用等凑满一批GPU 利用率大幅提升。二是多副本共享同一个模型可以同时服务多个 LoRA 适配器基座权重只加载一份——微调多业务线的团队直接受益。三是 OpenAI 兼容接口现有应用把 base URL 指过去就能切换迁移成本接近零。使用边界vLLM 是 GPU 服务端方案需要 NVIDIA 显卡面向高并发生产场景。个人本地单机试用、CPU 环境、苹果芯片Ollama 或 llama.cpp 更合适。并发低的场景一天几百次调用vLLM 的复杂度是纯开销日调用量上万、多用户共享、对延迟敏感的服务它就是那个必选项。部署前用真实流量压测一轮确定实例数与显存配置——vLLM 给你的是能力上限容量规划还是自己的功课。