vLLM 分离式服务指南

vLLM 引入了分离式服务（Disaggregated Serving），将 LLM 推理的三个主要工作负载分离开来：提示词处理（prefill）、Token 生成（decode）以及 CPU 密集型前端任务（分词和解析）。通过拆分这些阶段，vLLM 防止了长提示词阻塞活跃的生成流，使运维人员能够独立调整首字延迟（TTFT）和 Token 间延迟（ITL）。

分离式架构技术细节

vLLM 中的分离式服务将推理流水线拆分为不同的层级，可以独立进行扩展和调整：

Prefill 与 Decode 分离

Prefill 和 Decode 作为独立的实例运行。Prefill 实例处理初始提示词并生成 KV 缓存（注意力键和值），然后通过 KV 连接器传输到 Decode 实例。

  • KV 缓存传输： 传输大小取决于模型和提示词长度。例如，BF16 格式的 Llama-3.1-70B 每个 Token 占用 320 KiB；一个 1 万个 Token 的提示词需要传输约 3 GB 数据。
  • 连接器： vLLM 支持多种用于此传输的连接器，包括 NIXL、LMCache、Mooncake、FlexKV 和 AMD 的 MoRI-IO，通常利用 RDMA 实现高速传输。

前端分离（渲染/反渲染）

CPU 密集型任务被转移到无 GPU 的前端层：

  • /render： 将 OpenAI 风格的请求转换为 Token ID。
  • /derender： 将输出的 Token ID 转换回结构化的 OpenAI 响应，包括内容、推理过程和工具调用的分离。

其他分离维度

  • 编码器分离： 用于多模态模型，将编码器与流水线的其余部分分离。
  • AFD 插件： 在混合专家模型（MoE）中将注意力机制与前馈网络（FFN）分离。
  • 混合 SSM： 支持混合 SSM 模型的 Mamba 状态传输。

性能影响：有效吞吐量与延迟

分离式服务专注于提高有效吞吐量（goodput）——即在满足 TTFT 和 ITL 目标的同时所能维持的请求速率，而不是峰值原始吞吐量。

降低尾部延迟

在协同定位（collocated）服务中，一个长 Prefill 请求可能会阻塞同一 GPU 上的所有并发 Decode 流，导致 p99 ITL 激增。在分离式设置中，Decode 实例仅运行 Decode 批次，消除了由 Prefill 引起的阻塞。

在使用 Qwen2.5-7B-Instruct 和两块 NVIDIA L40S GPU 进行 8k Token 提示词的测试中，协同定位模式下的 p99 ITL 在 0.4 req/s 时从 23 ms 跳升至 169 ms，而分离式（P/D）设置的 p99 ITL 保持在 25 ms 到 52 ms 之间。

提高有效吞吐量

快速的 KV 传输对于实现这些收益至关重要。AMD 的 MoRI-IO 在 Qwen3-235B-A22B-FP8 上的基准测试显示，在分离模式下，73% 的请求达到了 TTFT（<1s）和 ITL（<50ms）目标，而协同定位模式下仅为 30%——有效吞吐量提升了 2.4 倍。

传输成本

每一个首字都会产生 KV 缓存传输的延迟代价。如果传输速度较慢（例如缺乏点对点支持或 RDMA），TTFT 将会增加。在没有 P2P 支持的硬件上，8k Token 的提示词传输需要约 1.3 秒，导致系统即使在 ITL 保持稳定的情况下也无法达到 TTFT 目标。

操作实现

运行 Prefill/Decode

从 vLLM v0.30.0 开始，分离式设置需要三个组件：Prefiller、Decoder 和用于协调切换的代理（Proxy）。

  1. Prefiller： 配置为 kv_producer，使用特定的 kv_connector（例如 NIXL）。
  2. Decoder： 配置为 kv_consumer。
  3. Proxy： 以 max_tokens=1 和 do_remote_decode: true 调用 Prefiller，然后将生成的 kv_transfer_params 转发给 Decoder。

多轮对话

为了避免为聊天中的先前轮次重新计算 KV 缓存，vLLM 支持 bidirectional_kv_xfer。这允许 Prefiller 从 Decoder 取回现有的块，仅计算提示词中的新 Token。

部署渲染层

渲染层是无状态的，可以作为标准的 CPU Web 服务进行扩展。确保模型、分词器和解析器配置在渲染、反渲染和引擎层之间保持同步至关重要，以避免输出不匹配。

当前限制与未来工作

  • 流式解析器开销： 带有解析器的流式反渲染计算成本很高，因为它目前在每个数据块中都会重建解析器并重放 Token 历史记录，导致长生成任务中出现 $O(n^3)$ 的字符处理工作。计划引入缓存层来解决此问题。
  • 网络开销： 长提示词在请求体中占主导地位，因为在流式反渲染过程中，prompt_token_ids 会随每个数据块重复发送。
  • 正确性差距： 正在解决关于批处理反渲染中 finish_reason: "tool_calls" 以及返回占位符字符串而非整数 Token ID 用于 logprobs 的问题。

总结建议表

情况 建议
负载下 ITL p99 未达 SLO 分离
高并发下的长提示词 分离（如果 KV 传输速度快）
聊天/智能体在不断增长的上下文中的循环 使用双向传输进行分离
GPU CPU 配置文件显示高分词/解析负载 拆分渲染层
TTFT 是约束瓶颈 保持协同定位或先进行测量
KV 传输缓慢 修复传输或保持协同定位
低流量、突发流量或对延迟不敏感的流量 保持协同定位

Sources