通过 vLLM 中的双向 KV 传输改善多轮智能体工作负载的 TTFT

多轮智能体工作负载随着智能体进行推理、调用工具并整合先前结果而不断累积上下文。每个新一轮,客户端会重新发送对话历史,包括系统指令、先前的提示、工具结果和模型响应,导致不断增长的上下文被反复处理。在 Prefill-decode (P-D) 分离架构中,每个请求被拆分到专用节点上:prefill 节点处理提示并构建其 KV 缓存,然后 decode 节点检索这些 KV 块并生成响应。

然而,传统的分离式服务只在单一方向传输 KV 缓存:从 prefill 节点到 decode 节点。这种单向流给多轮工作负载带来了两个低效问题。首先,在生成响应后,decode 节点同时保留提示和新生成 token 的 KV 缓存条目。在处理下一轮时,prefill 节点无法检索这些条目,因此必须重新计算先前响应 token 的 KV 投影。其次,decode 节点维护会话状态而 prefill 节点不维护,这增加了 prefill 节点上活跃会话的缓存被逐出的概率。在完全缓存未命中的情况下,prefill 节点必须为整个对话历史重新计算 KV 投影,包括系统指令、先前的用户请求、工具结果和模型生成的响应。随着对话增长,这种冗余工作消耗更多加速器容量,并增加首 token 时间(TTFT)。

对于构建对话助手和智能体应用的客户来说,更长的交互历史会增加延迟,并通过重复的 prefill 计算消耗加速器容量。在本文中,我们展示了 双向 KV 缓存传输 如何让 prefill 和 decode 节点跨轮次复用先前计算的上下文,提高加速器利用率,并帮助应用在对话增长时保持响应迅速的 TTFT。

在我们使用通过 AWS Elastic Fabric Adapter 连接的 Amazon EC2 P5en 实例的 1P1D 部署上进行的多轮基准测试中(AWS EFA,AWS 中跨服务器使用的低延迟 RDMA 网络)连接的 Amazon EC2 P5en 实例进行的 1P1D 部署多轮基准测试中,双向 KV 传输将 Qwen3-32B 的 TTFT 降低了最高 1.6 倍,将 zai-org/GLM-5-FP8 的 TTFT 降低了最高 3.3 倍(参见 性能数据 部分);结果取决于工作负载和配置。

我们最初在通过 EFA 连接的 AWS Trainium 实例集群上构建并验证了该功能,并将其作为与加速器无关的能力贡献给 vLLM。此处展示的结果来自带 EFA 的 Amazon EC2 P5en GPU 集群,表明其优势同样适用于 GPU。本文介绍了双向传输架构、路由器元数据流、KV 块保留与重计算控制、性能结果,以及如何复现该基准测试。

双向 KV 传输

双向 KV 传输是一种机制,允许 decode 节点在对话的后续轮次中将先前计算的 KV 返回给 prefill 节点,避免在 prefill 节点上重新计算共享上下文,该机制由可配置的 KV 重计算阈值控制。这缓解了前面描述的两种计算冗余场景,而实现这一点需要 KV 在产生它的轮次之后继续存活,并以相反方向传输,由一个感知 KV 缓存的路由器进行协调。

面向双向传输的 NIXL KV 连接器增强

我们扩展了 NVIDIA Inference Xfer Library (NIXL) KV 连接器 ,让 prefill 节点能够消费远程 KV 块,类似于 decode 节点已经消费 prefill 节点提供的 KV 块的方式。这并非一个简单的改动,因为两种节点类型在架构上不同:prefill 节点为新提示 token 计算 KV 表示,并且可以提供完整的提示 KV 块。Decode 节点缺乏生成完整 KV 表示的能力(或效率),只能提供先前缓存的 KV 块。因此,prefill 和 decode 节点仍然保留各自计算远程和本地 KV 块元数据的角色和逻辑。不过,实际的 KV 传输机制(NIXL READ)对于 P->D 和 D->P 两个方向是共用的。

下图首先以蓝色显示现有流程:路由器将请求发送到 prefill 节点,prefill 节点计算提示 KV 并返回其块元数据,然后路由器将请求和元数据转发给 decode 节点以进行标准的 P→D NIXL READ。编号的红色路径展示了双向 KV 传输的新增内容:(1) decode 节点在生成后保留符合条件的 KV 块,(2) 在流式响应中返回它们的元数据,(3) 路由器缓存该元数据以供下一次 prefill 请求使用。然后 prefill 节点 (4) 在应用本地缓存匹配后检查可远程复用的 KV,(5) 当可复用 token 数量达到阈值时排队一个异步接收,并 (6) 在计算剩余后缀之前执行 D→P NIXL READ。

KV缓存感知路由器

vLLM 包含针对双向 KV 传输的连接器侧支持，而协调跨对话轮次的 KV 复用则需要一个具备 KV 缓存感知能力的路由器。vLLM GitHub 提供了一个 示例代理 实现了本文所使用的流程，可以针对您的环境进行调整。

KV-cache感知路由器是一个轻量级的、有状态的控制平面组件，位于客户端、prefill节点和decode节点之间。它维护一个从客户端提供的 conversation_id 解码的 kv_transfer_params。该路由器仅存储块位置元数据，而不存储 KV 张量，并且它从响应流中获取该元数据，而不是单独查询解码节点。

下图展示了路由器如何在多轮对话中管理 KV 元数据。在第一轮，缓存查找未命中，请求遵循标准的 P→D 流程；路由器随后从响应流中保存解码的元数据。在后续轮次中，路由器使用以下内容获取该元数据 conversation_id，使 prefill 能够复用 decode 的 KV，并在生成后刷新元数据以供下一轮使用。

区块保留 TTL

通常情况下,decode实例会在生成完成后立即释放请求的块。在双向模式下,它会在一段可配置的生命周期内保留这些块(decoder_kv_blocks_ttl（默认 480 秒）并发布它们的位置和过期时间，因此会话的 KV（包括 prompt 前缀和已生成的响应）会为下一轮保持可用。对于在 TTL 过期之前到达的一轮，prefill 节点会复用 KV；较晚到达的则回退到正常的 prefill。由于这个 TTL 是固定的且不会续期，应将其调整为预期的轮次间隔时间，以在 KV 复用与加速器内存占用之间取得平衡。一个自然的下一步改进是将基于心跳续期的租约扩展到 decode 侧，这样一旦会话进入空闲状态，decode 实例就能立即回收块，而不是等到固定计时器结束。

KV 重算阈值

KV 复用并不总是比本地重算更快。对于较短的可复用前缀，互连与协调开销可能超过重算这些 token 所需的时间。 kv_recompute_threshold 设置（默认 64 个 token）控制这一决策。当需计算的 token 数量低于阈值时，prefill 节点会重算；当达到或高于阈值时，则从 decode 节点拉取 KV。部署方可根据模型计算时间、KV 大小和互连性能来调整此值。

性能数据

在评估中，我们在使用 EFA 连接的 Amazon EC2 P5en 实例上的 1P1D 部署中使用了 Qwen3-32B 和 GLM-5-FP8 模型。为了模拟 prefill 节点已逐出本地缓存、或路由器选择了另一个没有该会话 KV 块的 prefill 节点的场景，我们通过以下设置禁用了 prefill 节点上的前缀缓存： --no-enable-prefix-caching.

在两个模型上，开启双向 KV 传输都能减少多轮对话中的 prefill 计算，且收益通常随 prompt 长度增长而增加。关闭该功能时，prefill 实例每一轮都要重算整个增长后的上下文，因此 TTFT 陡增：Qwen3-32B 在 2k 时从 158 毫秒攀升到 24k 时的 778 毫秒，GLM-5-FP8 在 2k 时从 500 毫秒攀升到 20k 时的 2,334 毫秒。开启该功能时，decode 实例保留的 KV 会被复用而非重算，使 TTFT 曲线平缓得多：Qwen3-32B 在相同范围内仅从 122 毫秒升至 460 毫秒（最长 prompt 处约降低 1.6 倍），而 GLM-5-FP8 从 358 毫秒升至 702 毫秒，在长 prompt 下比重算路径最多低 3.3 倍。prefill 时长的细分数据解释了原因。

双向传输会增加少量 KV 传输时间（Qwen3-32B 约为 30 ms 至 130 ms；GLM-5-FP8 约为 29 ms 至 110 ms），但它省去的预填充计算量远超这段 KV 传输时间。因此，开启传输后的总预填充时长（Qwen3-32B：128 ms 至 414 ms；GLM-5-FP8：316 ms 至 541 ms）始终远低于仅重新计算的路径（Qwen3-32B：153 ms 至 744 ms；GLM-5-FP8：500 ms 至 2,331 ms）。更大的 GLM-5-FP8 模型呈现出更大的绝对和相对差距，因为其更高的每 token 重算时间使得随着模型和上下文规模的扩大，KV 复用的收益更加显著。

Qwen3-32B

下图绘制了 Qwen3-32B 的 TTFT 与提示长度的关系，对比了开启与关闭双向 KV 传输的情况。

下一张图表将相同运行的预填充时长拆分为其重算和KV传输两个组成部分。

这些图表共同显示，开启该功能时 TTFT 几乎保持平稳，而关闭该功能的路径则随着上下文增长急剧攀升，因为微小的 KV 传输时间远被其省去的重计算所抵消。

zai-org/GLM-5-FP8

同样的两种视角也适用于 GLM-5-FP8。第一张图绘制了在功能开启与关闭的情况下 TTFT 随提示长度的变化。

第二个将预填充时长分解为重计算和KV传输两个组成部分。

GLM-5-FP8 显示出比 Qwen3-32B 大得多的差距，在长提示下 TTFT 最多低约 3.3 倍，因为其更高的单 token 重计算时间使得随着上下文长度增长，KV 复用的收益更加显著。

如何运行基准测试

要复现我们的 1P1D 基准测试配置，即一个 prefill 节点和一个 decode 节点，使用带 EFA 的 Amazon EC2 P5en 实例，请按照以下分步说明操作： 复现我们的结果 下方指南。该指南涵盖环境设置、启动 vLLM prefill 和 decode 服务器、运行基准测试以及收集结果。该功能可以在其他支持的配置上运行,但性能结果会因硬件、模型、工作负载和网络配置的不同而有所差异。

结论

在这篇文章中，我们展示了双向 KV 缓存传输如何在智能体的对话历史增长时降低 TTFT。在 P-D 分离部署中，该功能允许 prefill 节点跨轮次复用 decode 节点保留的 KV 块，从而减少重复计算。可配置的块保留和重算阈值决定了何时发生复用。在由 EFA 连接的 Amazon EC2 P5en 实例组成的 1P1D 部署中，在测试的最长提示长度下，我们观察到 Qwen3-32B 的 TTFT 降低了 1.6 倍，zai-org/GLM-5-FP8 降低了 3.3 倍；结果取决于工作负载和部署配置。要在您的环境中实现此功能，请使用 vLLM v0.21.0 或更高版本，并配合 NixlConnector, 启用 bidirectional_kv_xfer 在 prefill 和 decode 服务器上都使用支持 KV-cache 感知的路由器，并遵循 繁殖指南.

相关资源

• AWS EFA
• Prefill-Decode（P-D）分离式服务
• 多轮对话下的KV缓存卸载基准测试

致谢

我们感谢 Nicolò Lucchesi（Mistral）、Mark McLoughlin（Red Hat）以及 vLLM 社区在维护此功能方面给予的支持。

附录:复现我们的结果

该拓扑为两个 AWS p5en 实例(prefill 在 :8100、解码于 :8200(启用EFA)外加一个第三小型节点,在其上运行代理和基准测试客户端于 :8000.

本文附带了三个脚本： serve_pd_multiturn.sh 分别启动开或关该特性的两个分支， run_multiturn_sweep.sh 驱动提示词长度扫描，而 cleanup.sh 负责拆除部署。

测试环境

两个 GPU 节点的配置完全相同：

NIXL 对 EFA 设备的选择。 LIBFABRIC 后端将所有 16 个 EFA 设备作为 rails 打开，并使用 efa 提供程序将全部 16 个 EFA 设备作为 rail 打开。然后，它仅在共享该 GPU PCIe 交换机的 2 个 rail 上注册每个 GPU 的 KV 缓存，因此每次传输都保持在 PCIe 本地。未设置任何 NIXL 或 libfabric 设备覆盖；这是默认选择。要在您自己的节点上确认这一点，请使用以下参数启动服务器 NIXL_LOG_LEVEL=DEBUG 并检查注册行：

grep -E "Created rail [0-9]+ \(device=|mapped to rail" server.log

1. 预配节点

在两个 GPU 节点上安装 EFA 用户态软件栈，并确认提供程序存在。我们使用了安装程序 1.50.0:

curl -O https://efa-installer.amazonaws.com/aws-efa-installer-1.50.0.tar.gz
tar -xf aws-efa-installer-1.50.0.tar.gz && cd aws-efa-installer
sudo ./efa_installer.sh -y
fi_info --version         # libfabric 2.6.0amzn1.0
fi_info -p efa -t FI_EP_RDM            # verify the EFA provider is present on both GPU nodes

2. 在两个 GPU 节点上安装 vLLM 和 NIXL

python3 -m venv ~/venv-pd && source ~/venv-pd/bin/activate
pip install --upgrade pip && pip install vllm==0.29.0 nixl==1.4.1

在两个节点上各应用一次 vLLM PR #40186 。它将 kv_transfer_params 附加到 流式 响应上，这正是多轮代理链接各轮所需的：代理始终使用以下参数查询解码节点 stream=True，因此如果没有此补丁，decode 节点永远不会返回块元数据，每一轮都会成为缓存未命中。

SITE=$(python -c 'import site; print(site.getsitepackages()[0])')
curl -sL https://github.com/vllm-project/vllm/pull/40186.diff -o /tmp/40186.diff
patch -p1 -d "$SITE" --fuzz=3 < /tmp/40186.diff

3. 下载模型

export HF_HOME=/fsx/huggingface        # a large shared volume
hf download Qwen/Qwen3-32B

4. 启动 P/D 对

运行 serve_pd_multiturn.sh 每个 GPU 节点一次。 BIDIR 是 A/B 两条分支之间唯一改变的东西，并且它必须在两个节点上保持一致：

# on the prefill node
P_IP=<P_IP> D_IP=<D_IP> ROLE=prefill BIDIR=false ./serve_pd_multiturn.sh
# on the decode node
P_IP=<P_IP> D_IP=<D_IP> ROLE=decode  BIDIR=false ./serve_pd_multiturn.sh

在 prefill 一侧，它展开为：

export FI_PROVIDER=efa
export VLLM_NIXL_SIDE_CHANNEL_HOST=<P_IP> VLLM_NIXL_SIDE_CHANNEL_PORT=5600
vllm serve Qwen/Qwen3-32B --served-model-name Qwen --dtype bfloat16 \
  --tensor-parallel-size 8 --max-model-len 32768 --max-num-seqs 8 \
  --no-enable-prefix-caching --port 8100 \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_buffer_device":"cuda",
    "kv_role":"kv_producer","engine_id":"prefill-engine-001","kv_rank":0,
    "kv_parallel_size":2,"kv_connector_extra_config":{"backends":["LIBFABRIC"],
    "kv_recompute_threshold":64,"decoder_kv_blocks_ttl":480,
    "bidirectional_kv_xfer":false}}'

--no-enable-prefix-caching 仅在 prefill 节点上设置——这正是基准测试所模拟的缓存被逐出的场景。在 decode 节点上保持前缀缓存启用。等待两个 /health 端点都返回 200。

5. 启动多轮对话代理

python3 -m venv ~/venv-proxy && source ~/venv-proxy/bin/activate
pip install fastapi uvicorn httpx pandas numpy aiohttp transformers tqdm
sudo dnf install -y jq || sudo apt-get install -y jq
git clone --depth 1 --branch v0.29.0 https://github.com/vllm-project/vllm.git ~/vllm_src
export VLLM_SRC=~/vllm_src
 
python3 $VLLM_SRC/examples/disaggregated/disaggregated_serving/disagg_proxy_multiturn.py \
  --port 8000 --prefiller-host <P_IP> --prefiller-ports 8100 \
  --decoder-hosts <D_IP> --decoder-ports 8200 \
  2>&1 | tee ~/proxy_$(date +%Y%m%d_%H%M%S).log

该代理接受主机和端口，而不是 URL。复用由客户端发送 conversation_id来驱动，因此这里没有需要启用的开关。

6. 先运行 OFF 分支，再运行 ON 分支

VLLM_SRC=~/vllm_src LEG=off ./run_multiturn_sweep.sh

对于 ON 分支，停止两个服务器和代理，然后用以下命令重新启动第 4 步 BIDIR=true 重新启动第 4 步，重启代理（其会话缓存在进程内），然后：

VLLM_SRC=~/vllm_src LEG=on ./run_multiturn_sweep.sh

对 GLM-5-FP8 重复两个分支，使用 MODEL=zai-org/GLM-5-FP8 SERVED_NAME=GLM.

7. 收集数据

三个量，每个来源一个：

• TTFT，来自由 --stats-json-output写入的基准测试每请求统计 JSON。每条记录都包含 ttft_ms 以及 input_num_tokens 和 conversation_id。这是 TTFT 图表的 y 轴。
• Prefill 时长，来自代理日志，它将每个请求的 prefill 部分报告为 Prefill done in <N>ms。这是 prefill 时长分解中每个柱状图的总高度。
• KV 传输时间和传输量，来自 prefill 节点的日志，它会报告 KV Transfer metrics: 行，包含平均和 P90 传输时间、每次传输的字节数以及吞吐量。这是每个 ON 柱状图中的 KV-xfer 组件。

NIXL遥测数据由发起传输的一侧记录，因此D->P读回操作出现在prefill节点的日志中，而普通的P->D拉取操作出现在decode节点的日志中。

按每个提示词长度对各数量取平均值,然后绘图:将 TTFT 相对于提示词长度绘制为两条线(ON 和 OFF),并将 prefill 时长绘制为每个提示词长度的成对堆叠柱状图,其中 ON 柱再拆分为 prefill 计算和 KV 传输两部分。两种视图之间的差异才是重点——柱状图所揭示的传输开销,正是 TTFT 折线所转化的节省。

故障排除

• 代理服务器总是会记录 cache MISS 在 ON 运行状态下 — 缺失 --send-conversation-id, PR #40186 未在两个节点上应用，或者 BIDIR=false 留在了 decode 节点上，在这种情况下它不返回任何 kv_transfer_params 。
• Declining expired remote read 在 prefill 节点上 — decode 节点的块在下一轮到来之前已失效。调高 decoder_kv_blocks_ttl （默认 480 秒），并保持代理的 cache TTL 低于该值。
• fi_info -p efa 为空或回退到 sockets — 缺少 EFA provider。重新安装 aws-efa-installer 并确认实例是以支持 EFA 的接口启动的；否则 NIXL 要么初始化失败，要么悄悄通过 TCP 运行，这会使传输数字失去意义。

清理

./cleanup.sh proxy      # on the proxy / benchmark driver node
./cleanup.sh server     # on each GPU node

然后终止这些实例并确认没有实例仍在运行。