vLLM 生产环境部署：构建高吞吐量推理服务架构

更新于 2025 年 12 月 11 日

2025 年 12 月更新： Stripe 通过迁移至 vLLM 实现了 73% 的推理成本降低（在三分之一的 GPU 集群上处理每日 5000 万次 API 调用）。PagedAttention 消除了 KV 缓存碎片化导致的 60-80% 内存浪费。vLLM 相比传统服务框架可提供 2-24 倍的吞吐量提升。目前已在 Meta、Mistral AI、Cohere、IBM 等公司的生产环境中运行。兼容 OpenAI 的 API 简化了采用流程。

Stripe 的机器学习平台团队在从 Hugging Face Transformers 迁移到 vLLM 后，发现推理成本下降了 73%——在三分之一的 GPU 集群上处理同样的每日 5000 万次 API 调用。¹ vLLM 高效性的秘密在于 PagedAttention，这是一种将 GPU 内存当作操作系统虚拟内存来管理的算法，消除了传统推理系统中浪费 60-80% 内存的碎片化问题。² 运行生产级 LLM 工作负载的组织发现，vLLM 相比传统服务框架可提供 2-24 倍的吞吐量提升，从根本上改变了大规模部署大语言模型的经济效益。³

推理服务领域分散着数十种选择：TensorRT-LLM 承诺最大化 NVIDIA 优化，Hugging Face TGI 提供熟悉的集成体验，Ollama 则简化了本地部署。然而 vLLM 已成为生产工作负载的主流选择，为 Meta、Mistral AI、Cohere 和 IBM 提供推理服务支持。⁴ 该框架将 PagedAttention、连续批处理和兼容 OpenAI 的 API 相结合，创造了一种在原始性能与运维简便性之间取得平衡的部署体验。理解 vLLM 的架构和部署模式，是实现高性价比推理与陷入高昂 GPU 账单之间的分水岭。

PagedAttention 革新内存管理

传统 LLM 推理为每个序列的键值（KV）缓存分配连续的内存块，无论实际使用情况如何，都会为最大可能的序列长度预留空间。一个配置为 4,096 个 token 的系统，即使对于 100 个 token 的响应也会分配全部内存，浪费了 97% 的预留容量。当数百个并发请求叠加时，GPU 内存被空预留填满，而实际序列却在排队等待资源。

PagedAttention 通过将 GPU 内存划分为固定大小的页面（通常每页 16 个 token）来重新构想这一架构。⁵ 每个序列维护一个页面引用列表，而非连续分配，从而实现了几项突破性能力：

非连续存储允许 KV 缓存块分散在可用 GPU 内存的任何位置。系统不再需要大块连续区域，消除了困扰传统分配器的碎片化问题。一个 2,000 token 的序列将其缓存存储在分布于任何可用空间的 125 个页面中。

动态分配仅在序列增长时才配置内存。第一个 token 分配一个页面。第十七个 token 触发第二个页面的分配。内存消耗追踪实际使用情况，而非理论最大值，显著提高了有效容量。

内存共享使相同的提示前缀能够跨请求共享 KV 缓存页面。十个用户询问同一系统提示的变体时，共享该前缀的单一缓存副本，对于常见模式可减少 90% 的内存消耗。具有标准化提示的生产系统可看到超过 400% 的利用率提升。⁶

近零浪费消除了静态分配中常见的内部碎片。传统系统在部分填充的块中平均每个序列浪费 4.1 个 token。PagedAttention 的页面级粒度将浪费减少到不足一个页面，无论长度如何，每个序列通常不超过 8 个 token。

该算法直接借鉴了操作系统虚拟内存的灵感，将数十年的内存管理研究应用于 GPU 推理。就像现代操作系统将虚拟地址映射到物理内存页面一样，PagedAttention 将逻辑 KV 缓存位置映射到物理 GPU 内存块。转换开销为每次注意力计算增加了微秒级延迟，但节省了数 GB 的内存容量。

连续批处理最大化 GPU 利用率

静态批处理在处理请求前等待固定数量的请求积累，当批次部分填充时会造成延迟峰值，当请求到达不均匀时吞吐量会下降。批大小为 32 意味着第 31 个请求必须等待再来一个请求才能开始处理，在低流量期间可能增加数秒的延迟。

vLLM 中的连续批处理完全消除了批次边界。⁷ 调度器在迭代级别而非请求级别运行，每次前向传递都做出决策，而非每个批次。当一个序列完成生成时，其槽位立即接受新请求，无需等待同批序列完成。GPU 在每个时刻处理所有存在的工作，填补静态批处理留下的空隙。

该实现需要内存管理和调度之间的精心协调：

迭代级调度在每个解码步骤评估请求队列。已完成的序列释放其槽位，等待的请求获取可用容量，下一次迭代以最优填充的批次继续。请求之间的延迟方差被吸收而非放大。

抢占处理管理内存压力迫使序列被驱逐的情况。低优先级请求检查点保存其 KV 缓存状态，并将 GPU 内存让给高优先级序列。当容量恢复时，被抢占的序列从其检查点恢复，而非从头重新开始。

前缀缓存识别共享公共前缀的请求，并将它们路由到已持有相关 KV 缓存页面的实例。在一个每个请求都以相同的 500 token 上下文开始的客户支持系统中，后续 token 从缓存状态提供服务，消除了冗余的前缀计算。

基准测试展示了其影响：在等效配置下，vLLM 实现了每秒 793 个 token 的吞吐量，而 Ollama 为每秒 41 个 token，P99 延迟为 80ms 对比 673ms。⁸ 连续批处理架构在从 1 到 256 个并发用户的所有并发级别上都保持这些优势。

生产架构跨集群扩展

单节点 vLLM 部署可处理大量流量，但生产系统需要集群范围的编排以实现可靠性、可扩展性和效率。vLLM production-stack 通过四个关键补充将推理引擎转变为完整的服务系统。⁹

请求路由根据路由键、会话 ID 或前缀匹配将传入查询定向到适当的后端实例。智能路由通过将相关请求发送到已持有相关上下文的实例来最大化 KV 缓存复用。具有多轮的对话一致地路由到同一后端，避免跨实例的冗余前缀计算。

KV 缓存共享通过 LMCache 项目将 PagedAttention 的内存效率扩展到多个 vLLM 实例。后端通过高速互连共享已计算的 KV 缓存块，即使请求路由到不同实例也能实现缓存命中。具有重复工作负载的系统从跨实例缓存共享中获得 3-10 倍的延迟降低和 2-5 倍的吞吐量提升。¹⁰

可观测性集成通过 Prometheus 暴露指标，并通过 Grafana 仪表板进行可视化。每请求指标捕获首 token 时间（TTFT）、token 间隔时间（TBT）和端到端延迟。每实例指标跟踪 GPU 利用率、内存压力、队列深度和缓存命中率。运维团队获得对性能瓶颈和容量规划数据的可见性。

水平扩展根据需求信号添加和移除 vLLM 实例。Kubernetes 部署使用 Horizontal Pod Autoscaler，配合针对队列深度或延迟百分位数的自定义指标。路由器层自动发现新实例并重新平衡流量，实现跟踪实际需求的弹性容量。

部署遵循标准的 Kubernetes 模式，通过 Helm charts 实现：

# vLLM production-stack 的 values.yaml
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

部署的技术栈通过 Kubernetes 服务暴露兼容 OpenAI 的 API，使当前调用 OpenAI 或 Azure OpenAI 端点的应用程序能够直接替换。现有代码库只需更改端点 URL 即可从云 API 迁移到自托管推理。

基础设施需求影响部署决策

vLLM 的内存效率使更大的模型能够在更小的 GPU 配置上运行，但硬件选择仍然决定性能特征。理解模型大小、GPU 内存和吞吐量之间的关系对采购决策至关重要。

GPU 内存限制了最大模型大小和并发批处理容量。一个 70B 参数的模型在 FP16 下仅权重就需要 140GB，在任何当前硬件上都需要多 GPU 张量并行。同一模型在 INT4 量化下为 35GB，可在单个 A100 80GB 或 H100 上部署，并有充足的 KV 缓存空间。内存带宽通常比原始计算更能限制吞吐量，使配备 HBM3 的 GPU 格外有效。

张量并行将模型层分割到节点内的多个 GPU 上，对于超过单 GPU 内存的模型至关重要。vLLM 支持与 GPU 数量匹配的张量并行度，自动分片注意力和前馈层。一个运行张量并行度为 8 的 8-GPU 节点可以服务 405B 参数模型，否则需要多节点配合较慢的流水线并行。

网络架构对于多节点部署变得至关重要。跨节点的流水线并行需要阶段之间的低延迟、高带宽互连。具有 200-400Gbps 带宽的 InfiniBand 或 RoCE 网络支持高效的多节点服务，而标准以太网会引入大幅降低首 token 时间的延迟。

存储吞吐量影响加载模型权重时的冷启动性能。一个 FP16 的 70B 模型在服务第一个请求前需要从存储传输 140GB 到 GPU 内存。提供 7GB/s 的 NVMe 存储在 20 秒内加载模型；500MB/s 的网络附加存储需要 5 分钟。生产系统要么维护热备实例，要么实施模型缓存策略以最小化冷启动影响。

Introl 帮助组织在我们的全球覆盖区域设计 vLLM 基础设施，将硬件配置与工作负载需求相匹配，同时优化成本效率。¹¹ 我们的工程师已部署每月服务数十亿请求的推理基础设施，深谙将功能性部署与高度优化系统区分开来的细微差别。

vLLM 与替代方案对比

推理服务生态系统提供多种框架，各有独特优势。选择正确的工具需要将框架能力与工作负载特征相匹配。

TensorRT-LLM 通过激进的内核优化和图编译在 NVIDIA 硬件上提供最高性能。基准测试显示 TensorRT-LLM 在 H100 上使用 FP8 量化可实现每秒 10,000+ 个输出 token，首 token 时间约 100ms。¹² 代价是：复杂的设置需要检查点转换、引擎构建，以及跨 TensorRT-LLM、tensorrtllm_backend 和 Triton Inference Server 的大量配置。拥有专门 ML 基础设施团队和稳定模型部署的组织受益最大。

**Hugging Fa

[内容因翻译需要而截断]