7.3 KV Cache 传输与 Connector：解耦的工程命脉

7.2 说 KV 传输是解耦的命脉——这一节把它讲透。先算清楚”传多少数据、花多少时间”（这是判断解耦值不值的核心账），再看 vLLM 怎么把传输做成可插拔的 Connector 抽象，最后对比 NIXL / Mooncake / LMCache 等后端的取舍。学完这一节，你能自己回答”我的负载该不该解耦、该用什么传输”。

📑 目录

1. 传多少：KV Cache 的体积估算
2. 花多久：传输延迟对 TTFT 的影响
3. 怎么传：vLLM 的三层抽象
4. 传输后端全景：NIXL / Mooncake / LMCache
5. 带宽规划与网络选型
6. 传输优化的工程手段
7. 何时传输不是瓶颈
📝 总结
🎯 自我检验清单
📚 参考资料

1. 传多少：KV Cache 的体积估算

1.1 单 token 的 KV 体积公式

KV Cache 每个 token 占用的显存（FP16）：

\text{KV/token} = 2 \times n_{\text{layers}} \times n_{\text{kv\_heads}} \times \text{head\_dim} \times 2\text{ bytes}

（系数 2 来自 K 和 V 各一份）

实际数字（典型模型，FP16）：

模型	层数	kv_heads	head_dim	KV/Token
LLaMA-2-13B	40	40	128	~0.8 MB
LLaMA-2-70B	80	8（GQA）	128	~0.3 MB
LLaMA-3-70B	80	8（GQA）	128	~0.3 MB
DeepSeek-V3	61	128（MLA）	128	~2.0 MB（MLA 已压缩，未压更大）

📌 关键点：GQA（分组查询注意力）把 kv_heads 从 64 压到 8，KV 体积直接 ÷8——GQA/MLA 是 KV 传输的隐形盟友。同样 70B 模型，MHA 版（64 kv_heads）每 token KV 约 2.6MB，GQA 版只有约 0.3MB——传输压力差近 10 倍。这也是为什么现代大模型普遍用 GQA/MLA。

1.2 一次请求的传输总量

\text{传输量} = \text{KV/token} \times \text{prompt 长度}

场景	传输量（13B, ~0.8MB/token）	传输量（70B GQA, ~0.3MB/token）
1K prompt	0.8 GB	0.3 GB
4K prompt	3.2 GB	1.2 GB
32K prompt（长上下文）	25.6 GB	9.6 GB

💡 提示：记住量级——K 级 prompt 传 GB 级 KV。这远超单次 RPC 能承载的量，必须走专用的高速传输路径（RDMA/GPU Direct），而不是 HTTP/JSON。这就是”KV Connector”这类专用抽象存在的原因。

2. 花多久：传输延迟对 TTFT 的影响

2.1 传输时间估算

以 4K prompt、70B GQA（1.2GB）为例，不同互联的传输时间：

t = \frac{\text{数据量}}{\text{带宽}}

互联	典型带宽	传输 1.2GB	传输 3.2GB（13B 4K）
NVLink（节点内）	~100 GB/s 有效	12 ms	32 ms
InfiniBand 400Gb/s	~45 GB/s 有效	27 ms	71 ms
RoCE 200Gb/s	~22 GB/s 有效	55 ms	145 ms
万兆以太网	~1.1 GB/s	1.1 s	2.9 s

2.2 对 TTFT 的含义

解耦后 TTFT 的构成：

\text{TTFT}_{\text{解耦}} = \text{Prefill 计算} + \text{KV 传输} + \text{Decode 首步}

4K prompt 的 prefill 计算本身约 1-3s（A100 单卡量级）
传输占比：IB 下约 1-3%（可接受）；万兆网下 30-100%（不可接受！）

📌 关键点：网络带宽直接决定解耦是否可行。经验法则——KV 传输时间应该控制在 prefill 计算时间的 10% 以内；超过 30%，解耦的 TTFT 优势就被吃掉了。生产解耦部署的最低网络配置是 200Gb/s 级（IB 或 RoCE），万兆以太网做 P/D 解耦基本不可行（除非模型极小）。

2.3 带宽与输出长度的权衡（Splitwise 的定量结论）

Splitwise 论文给出关键权衡：输出越长，KV 传输摊薄越多——因为传输只发生一次（prefill 后），而 decode 的收益在输出的每一个 token 上累积。

\text{解耦净收益} \approx \text{decode 提速} \times \text{输出长度} - \text{KV 传输开销}

短输出（<100 token）：传输开销占比大，解耦收益薄
长输出（>500 token）：传输摊薄到每 token 极小，解耦收益显著

3. 怎么传：vLLM 的三层抽象

vLLM v0.26 的 Disaggregated Prefill 把 KV 传输抽象成三个组件（源码位于 vllm/distributed/kv_transfer）：

3.1 Connector：传输的入口

每个 vLLM 进程都有一个 Connector，分两类：

Scheduler Connector：在调度器进程内，调度 KV 传输操作（什么时候传、传哪些块）
Worker Connector：在 worker 进程内，执行实际的张量搬运

Connector 的职责：让 KV 的”消费者”（decode 实例）从”生产者”（prefill 实例）取回指定请求的 KV Cache。

3.2 LookupBuffer：KV 的暂存与检索

数据库风格的 KV 暂存层，两个 API（语义像 SQL）：

insert(kv)：把 KV 存入缓冲区（非阻塞——生产者写完即走）
drop_select(条件)：按条件取回并删除 KV（阻塞——消费者等数据到达）

3.3 Pipe：单向张量管道

底层传输通道，两个 API（语义像 torch.distributed）：

send_tensor(tensor)：发送张量
recv_tensor()：接收张量

💡 提示：三层抽象对应三种实现自由度（官方文档的第三方接入指南）：

Fully-customized：实现整个 Connector（最大控制力，但版本兼容风险高）

Database-like：实现 LookupBuffer（适合 KV 存储类后端）

Distributed P2P：实现 Pipe（适合直接对接传输库）

想接自己的传输系统，选一个层实现即可——这是 vLLM 特意留的插件点。

3.4 传输流程

Prefill 实例                           Decode 实例
┌────────────┐   insert    ┌──────────┐   drop_select   ┌────────────┐
│ Worker     │──KV 块─────→│ Lookup   │←──KV 块────────│ Worker     │
│ Connector  │             │ Buffer   │                 │ Connector  │
└────────────┘             └──────────┘                 └────────────┘
   Scheduler Connector 调度传输        Scheduler Connector 调度取回

传输按层进行（逐层 KV 的 insert/drop_select），decode 实例收到第 L 层 KV 即可算第 L 层 attention，传输与计算流水重叠
KV 块粒度为 vLLM 的 block 大小（如 16 token/块）

4. 传输后端全景：NIXL / Mooncake / LMCache

vLLM v0.26 支持 9 种 Connector，这里讲生产最常用的三个：

4.1 NixlConnector：NVIDIA 的传输库

底层：NIXL（NVIDIA 统一通信库，兼容 UCX/GDS 等后端）
特点：全异步 send/recv，支持 GPU Direct（GDS：显存直接到存储/网卡）
配置示例：

--kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_both",
  "kv_buffer_device":"cuda",
  "kv_connector_extra_config":{"backends":["UCX","GDS"]}}'

适用：单机多卡（NVLink）或同构 IB 集群，vLLM 官方推荐的基础后端

4.2 MooncakeConnector：Kimi 的 KVCache 中心化方案

底层：Mooncake（Moonshot AI 开源，Kimi 生产架构）
设计：KVCache 分层存储池——显存 → CPU DRAM → SSD 的分布式 KV 池；传输引擎用 RDMA 直连
特点：解耦 + 跨实例 KV 复用（相同前缀的 KV 在池中共享，省 prefill）；池内多实例共享
适用：大规模集群、多实例服务、前缀复用场景（如多轮对话）

4.3 LMCacheConnectorV1：开源 KV 缓存层

底层：LMCache（开源项目，支持 NIXL 传输）
特点：独立 lmcache server 进程持 KV（LMCacheMPConnector 模式），多个 vLLM 实例共享
适用：想在 vLLM 之外独立管理 KV 缓存生命周期的团队

后端	传输路径	特色	适合场景
NIXL	UCX/GDS，GPU Direct	全异步、官方默认推荐	同构集群基础解耦
Mooncake	RDMA + 分层存储池	KV 池化复用	大规模、前缀复用
LMCache	NIXL + 独立 server	缓存生命周期外置	多实例共享缓存

📌 关键点：后端选择的核心维度是**“传输能力”和”KV 存储形态”**——只解耦（P→D 一次传）用 NIXL 足够；要跨请求复用 KV（多轮对话、共享前缀）才值得上 Mooncake/LMCache 这类”KV 池化”方案。先想清楚需求再选后端，别上来就上最重的。

5. 带宽规划与网络选型

5.1 容量规划公式

解耦集群需要的池间带宽（峰值场景）：

\text{带宽需求} \approx \text{峰值 QPS} \times \text{平均 prompt KV 量}

例：峰值 100 req/s、平均 prompt 2K token、70B GQA（0.15 MB/token）→ 需要约 15 GB/s（约 150Gb/s 净带宽）——200Gb/s 单链路就是为此设计的。

5.2 选型建议

场景	推荐互联	理由
单机内解耦（NVLink）	NVLink	带宽最足，但失去了跨节点扩展的意义
同机房解耦（主流）	IB 400Gb/s / RoCE 200Gb/s+	传输 < prefill 的 10%
跨机房/边缘	不推荐解耦	延迟+带宽双重不可控

💡 提示：除了带宽，延迟也要看——KV 传输是”同步等待”（decode 实例必须等到 KV 才能开始），所以 RTT 直接加进 TTFT。同机房（RTT <1ms）没问题；跨城（RTT 10ms+）解耦会显著劣化 TTFT——这是”解耦必须同机房”的根本原因。

6. 传输优化的工程手段

流水重叠：逐层传 KV（传输第 L 层时算第 L-1 层），把传输藏进计算（vLLM 的 layer-by-layer 设计）
块级传输：以 block（16 token）为粒度传输，而不是整个请求的 KV 一次性传——调度更细、等待更短
GPU Direct：RDMA/UCX 直接从显存到显存，绕过 CPU 拷贝和 pinned memory（NIXL GDS 后端）
量化 KV：KV 量化（第 4.4 节）直接除以传输量（FP8 → 减半）
池化复用：Mooncake/LMCache 让相同前缀的 KV 在池内复用，减少重复传输（不只省算力，还省带宽）

📌 关键点：传输优化与 KV Cache 优化的联动——KV 量化、GQA/MLA、前缀缓存（APC）每一项都在同时缩小传输量。第 4 章和第 2 章的知识在这里汇合：优化 KV 的手段，在解耦架构里自动变成传输优化。

7. 何时传输不是瓶颈

诚实地说几个传输不重要的场景：

短 prompt + 长输出：传输只发生一次且量小，decode 收益占绝对主导
小模型（7B 级）：KV/token 小，万兆网也能扛
低 QPS：带宽压力小，普通网络即可

这些场景下”随便传”也行——判断标准始终是传输时间占 TTFT 的比例（10% 以内不用焦虑，30%+ 必须优化）。用第 1/2 节的公式先算账，再决定投入多少工程资源。

📝 总结

体积：KV/token = 2×层数×kv_heads×head_dim×2B；K 级 prompt 传 GB 级 KV
时间：传输占 TTFT 的比例决定解耦可行性（<10% 优，>30% 危险）
GQA/MLA 是传输盟友：KV 体积差近 10 倍
三层抽象：Connector（调度+执行）/ LookupBuffer（insert/drop_select）/ Pipe（send/recv）
后端选择：NIXL 基础解耦、Mooncake KV 池化复用、LMCache 缓存外置
网络：同机房 IB/RoCE 200Gb/s+；跨机房不解耦
优化：逐层流水、块级传输、GPU Direct、KV 量化、池化复用

🎯 自我检验清单

口算 LLaMA-70B（GQA）每个 token 的 KV 体积？4K prompt 传多少？
KV 传输时间怎么算？IB 400Gb/s 传 1.2GB 要多久？
为什么说”网络带宽直接决定解耦是否可行”？经验阈值是多少？
vLLM 的三层抽象各是什么？“接入自己的传输系统”有哪三种方式？
NIXL/Mooncake/LMCache 的定位差异？什么场景选 Mooncake？
为什么”解耦必须同机房”？
列出 5 种传输优化手段，哪些与 KV 量化/APC 联动？

📚 参考资料

vLLM 官方文档：Disaggregated Prefilling（含 Connector 列表与配置示例）（https://docs.vllm.ai/en/latest/features/disagg_prefill.html）
vLLM 官方文档：NIXL Connector Usage Guide（https://docs.vllm.ai/en/latest/features/nixl_connector_usage.html）
Mooncake 项目（Kimi 开源）：https://github.com/kvcache-ai/Mooncake
LMCache 项目：https://github.com/LMCache/LMCache
Qin et al., Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving（https://arxiv.org/abs/2407.00079）

搜索