KV cache 跨节点传输瓶颈
跨节点 KV 传输何时受 RTT 主导、何时受带宽限制，以及如何突破瓶颈
核心要点：
- 两类瓶颈：RTT-bound ($N \cdot \alpha$ 主导，PagedAttention 小块逐发) vs BW-bound ($S/\beta$ 主导)
- 临界点：$S_{\text{KV}} \lesssim$ BDP 时不论 chunk 多大都 RTT-bound; $S_{\text{KV}} \gg$ BDP 时 chunk 不过分小则转 BW-bound
- 关键实测：8×400 Gbps NIC 下消息要 16 MB+ 才能饱和带宽 (4 GB/s @ 64 KB → 49 GB/s @ 16 MB)
- 跨拓扑差异：NVLink 几乎纯 BW；同 rack RDMA 看 chunk 聚合；跨 DC RTT-bound 严重
- TTFT 隐藏：Layer-wise pipeline + 每层 KV 传输 < 每层 prefill 时，几乎全部可掩盖
- 8 类优化：chunked transfer / multi-NIC / layer-wise / staging / GPUDirect / heterogeneous TP / KV 压缩 / pull-on-demand
本文只讨论传输性能的瓶颈分析与建模。具体系统实现 (Mooncake Transfer Engine、FlowKV、NVIDIA Dynamo NIXL) 分别由 9.4 Mooncake / 9.6 NVIDIA Dynamo 展开；PD 分离的调度模型与 SLO 拆分在 9.2 Prefill/Decode 分离原理。
KV cache 体量怎么算
核心问题：不同模型 / 上下文长度的 KV 大小公式与典型量级？
KV cache 体量决定传输是 RTT-bound 还是 BW-bound 的关键变量。对一个 batch size 为 $B$、序列长度为 $s$ 的请求：
$$\begin{equation} S_{\text{KV}} = 2 \cdot L \cdot H_{\text{kv}} \cdot d_{\text{head}} \cdot s \cdot B \cdot b \label{eq:kvbw-size} \end{equation}$$$L$ 为层数，$H_{\text{kv}}$ 为 KV head 数 （GQA 下远小于 query head 数），$d_{\text{head}}$ 为每个 head 的维度，$b$ 为单元素字节数 (FP16 = 2, FP8 = 1)。系数 2 来自 K 与 V 各占一份。
Llama-3 70B 单请求 128K 上下文 ($L = 80$, $H_{\text{kv}} = 8$, $d_{\text{head}} = 128$, FP16):
$$\begin{equation} S_{\text{KV}}^{70\text{B},128\text{K}} = 2 \times 80 \times 8 \times 128 \times 128000 \times 1 \times 2 \approx 4.0 \times 10^{10}\ \text{B} \approx 40\ \text{GB} \label{eq:kvbw-llama70b} \end{equation}$$该数值与 Mooncake README 测试基准一致 ("40 GB of data (equivalent to the size of the KVCache generated by 128k tokens in the LLaMA3-70B model)"[1])。对短上下文 （如 2K token） 同一模型 KV 仅约 640 MB；对 MHA (如 Llama-2 70B, $H_{\text{kv}} = 64$) 相同长度则放大 8 倍。
传输代价怎么建模
核心问题：α-β 模型 / chunked 模型怎么写？两类瓶颈对应什么？
把 KV 传输抽象为 α-β 模型：
$$\begin{equation} T_{\text{transfer}} = \alpha_{\text{eff}} + \frac{S_{\text{KV}}}{\beta_{\text{eff}}} \label{eq:kvbw-alpha-beta} \end{equation}$$$\alpha_{\text{eff}}$ 与 $\beta_{\text{eff}}$ 都不是物理常数，而依赖消息分块策略。当 KV 被切成 $N$ 个非连续小 chunk （典型 PagedAttention 行为），每 chunk 至少消耗一次 RDMA write completion 与少量协议栈开销，实际形态接近：
$$\begin{equation} T_{\text{transfer}} \approx N \cdot \alpha + \frac{S_{\text{KV}}}{\beta_{\text{peak}} \cdot \eta(S_{\text{chunk}})} \label{eq:kvbw-chunked} \end{equation}$$其中 $\eta(S_{\text{chunk}}) \in (0, 1]$ 是 chunk 大小决定的带宽利用率。
两类瓶颈分别对应：
- RTT-bound ($N \cdot \alpha$ 主导): chunk 数极多 + 单 chunk 极小 + RTT 大。来源于 PagedAttention 16–64 KB 物理块逐块发送，被 NAIC'25 工作[2]类比为 "classic TCP small send window problem"
- BW-bound ($S_{\text{KV}} / \beta$ 主导): chunk 已足够大、链路被填满，仍要花 $S/\beta$ 时间把字节搬完
临界 size 与 BDP 比较：当 $S_{\text{KV}} \lesssim \text{BDP} = \beta \cdot \alpha$ 时即使把全部数据合成一个消息也填不满管道，此时不论 chunk 多大都受 RTT 制约；当 $S_{\text{KV}} \gg \text{BDP}$ 时只要 chunk 不过分小，瓶颈即转为带宽。
实测消息大小怎么影响有效带宽
核心问题：chunk 大小从 64 KB 到 16 MB 时，实际吞吐能涨多少？
LMCache 在 8×400 Gbps Broadcom Thor-2 NIC 集群上实测 RCCL 传输吞吐随消息大小变化：
| 消息大小 | 实测吞吐 |
|---|---|
| 64 KB | 4 GB/s |
| 256 KB | 13 GB/s |
| 1 MB | 30 GB/s |
| 10 MB | 46 GB/s |
| 16 MB+ | ~49 GB/s |
@tbl-kvbw-lmcache-msg-bw 消息大小与有效带宽的关系 （8×400 Gbps NIC 单 GPU rail 49 GB/s）
LMCache 明确给出："the transfer size must reach at least 16 MB to saturate the available network bandwidth"[3]。也就是说 PagedAttention 原生 16–64 KB block 在该链路上只能跑到峰值的 8%–25%; vLLM 原生 CPU offload 仅 88 Gbps，而 LMCache 把若干 page 聚合成 chunk-level granularity （论文未直接量化到 token 数） 后达到 400 Gbps，差距约 4.5×。
其他系统实测：
- Mooncake Transfer Engine：用 40 GB （即 70B/128K 整请求） 规模做 stripe + multi-NIC parallel I/O，在 4×200 Gbps RoCE 上达到 87 GB/s，在 8×400 Gbps RoCE 上达到 190 GB/s，分别是 TCP 的 2.4× / 4.6×[1]
- NVIDIA Vast Data 实测：GDS 路径到单 H100 达到 35 GB/s、WEKA RDMA 路径下 8 GPU 聚合 270 GB/s
关键观察：同一对硬件、同一总字节数，只因 chunk 大小不同，端到端时间可以差一个数量级。这是 RTT-bound 与 BW-bound 之间最直接的过渡现象。
不同拓扑层次瓶颈在哪
核心问题：NVLink / 同 rack / 跨 rack / 跨 DC 四级 RTT 和带宽差异？
不同物理范围决定了 $\alpha$ 与 $\beta$ 的量级，进而决定上面的曲线落在何处：
| 拓扑层次 | 典型 RTT (α) | 典型单向带宽 (β) | BDP （参考） | 主导瓶颈 |
|---|---|---|---|---|
| 同节点 NVLink (A100) | 亚 μs | 600 GB/s | < 1 MB | 几乎纯 BW，单大消息即饱和 |
| 同 rack RDMA (400 Gbps RoCE) | 2–5 μs | ~50 GB/s 单 rail | ~100–250 KB | KV 单层就远超 BDP，关键看 chunk 是否聚合 |
| 跨 rack RDMA （同 DC） | 5–20 μs | 同上 | ~250 KB–1 MB | chunk 太小时被 $N\cdot\alpha$ 拖累 |
| 跨 DC / geo-distributed | 数百 μs–几 ms | 受限于 WAN 带宽 | 数十 MB 起 | RTT-bound, PagedAttention 小块逐发"窗口塌缩" |
@tbl-kvbw-topology α 与 β 在不同拓扑层次下的典型量级与主导瓶颈
DistServe 在 OSDI'24 报告："the transfer overhead even for a relatively large 175B model was only around 0.1% of the total latency"[4]，前提是在 NVLink + InfiniBand 同 DC 环境且使用 layer-wise 流水线传输。这个 0.1% 的数字对应的是同节点 NVLink + 同 rack IB 的最优情形，不可外推到跨 DC。
NAIC 2025 的"RTT- or Bandwidth-Bound?"工作[2]直接挑战社区默认的"提高带宽就够了"的假设，结论为：在 geo-distributed 部署下 KV 传输 predominantly RTT-bound，且物理带宽充裕时有效吞吐仍然显著下降；根因正是 PagedAttention 非连续小块的顺序发射，在高 RTT 链路上变成"窗口受限"的逐 RTT 拷贝。
传输怎么挤占 TTFT 预算
核心问题：TTFT 三段拆分公式 + Layer-wise pipeline 怎么隐藏 + 定量代入两种场景？
PD 分离下 TTFT 由三段组成：
$$\begin{equation} \text{TTFT} = T_{\text{queue}} + T_{\text{prefill}} + T_{\text{transfer\_visible}} \label{eq:kvbw-ttft} \end{equation}$$$T_{\text{transfer\_visible}}$ 是"未被 prefill 计算掩盖的"那部分传输时间。若启用 layer-wise pipeline 且每层 prefill 计算时间 $t_\ell^{\text{cmp}}$ 大于该层 KV 的传输时间 $t_\ell^{\text{xfer}}$，则除最后一层外全部可重叠：
$$\begin{equation} T_{\text{transfer\_visible}} \approx \max\!\left(0,\ \sum_{\ell=1}^{L} t_\ell^{\text{xfer}} - \sum_{\ell=1}^{L-1} t_\ell^{\text{cmp}}\right) + t_L^{\text{xfer}} \label{eq:kvbw-overlap} \end{equation}$$定量代入 （Llama-3 70B, prompt 8K token, FP16，单请求 KV 约 2.5 GB；每层 64 KB chunk 数 ≈ 单层 KV ~32 MB / 64 KB ≈ 500）：
- 同 rack 400 Gbps RoCE，聚合 chunk 后 ~50 GB/s 有效带宽 → 总传输 ~50 ms，分摊每层 ~0.6 ms，可被 prefill 计算 （典型每层数 ms） 轻松覆盖 → $T_{\text{transfer\_visible}}$ 接近末层残尾，几 ms 级
- 跨 DC （RTT 5 ms，每层 80 个 64 KB chunk 逐发） → 每层 $\geq 80 \times 5\text{ms} = 400\text{ms}$, 单层就超过整个 prefill，pipeline 失效
另例 (Llama-3.1-8B, 13K input, 8×A100 NVLink): FlowKV 实测把 NCCL 原生 PagedAttention 传输的 0.944 s 压缩到 0.053 s （96% 缩减）[5]，改进来自把 $L \times 2$ 次 NCCL 调用合并。
关键结论：传输是否挤占 TTFT 取决于"每层 KV size ÷ 每层 prefill 算时" — 若该比值 $\ll 1$ 即可完全掩盖；若 $\gg 1$ （短 prompt + 跨 DC 大 RTT + 小 chunk），传输直接成为 TTFT 主导项。
优化策略总结
核心问题：各类优化怎么映射到压低 $N \cdot \alpha$ 或提高 $\beta_{\text{eff}}$?
| 策略 | 攻击对象 | 机制 | 代表实现 |
|---|---|---|---|
| Chunked transfer | $N \cdot \alpha$ / $\eta$ | 把 16–64 KB block 聚合成 MB 级大消息，单次 RDMA write | LMCache、Mooncake Transfer Engine |
| Multi-NIC striping | $\beta_{\text{peak}}$ | 大消息切片并行通过多张 RDMA NIC | Mooncake (4×200/8×400 RoCE) |
| Layer-wise pipeline | $T_{\text{transfer\_visible}}$ | 第 $\ell$ 层传输与第 $\ell{+}1$ 层 prefill / decode 重叠 | DistServe、Mooncake、LMCache |
| Staging (CPU/CXL/SSD) | 时序解耦 | prefill 推到中转存储，decode pull，吸收速率不匹配 | Mooncake KV Pool、Dynamo NIXL |
| GPUDirect RDMA | $\alpha$ / CPU 旁路 | NIC 直读 GPU HBM 省一次 bounce | NVIDIA Dynamo、Mooncake |
| Heterogeneous TP + reshape | 适配场景 | prefill 用大 TP、decode 用小 TP；传输前重组以减少 chunk 数 | DistServe、SGLang PD |
| KV 压缩 / 量化 | $S_{\text{KV}}$ | 把 FP16 换成 FP8 / 4-bit / token-aware pruning | 各类压缩工作 |
| Pull-on-demand | 总传输量 | 仅在 decode 命中时拉，不命中则丢弃 | DistServe、Mooncake "pull" 模式 |
@tbl-kvbw-opts 优化策略与攻击对象的映射
注意这些策略并非互斥：生产系统 (Mooncake、Dynamo) 通常同时启用 chunked + multi-NIC + layer-wise + staging。
PD 分离的适用与不适用判定
核心问题：不同部署情境下值不值得做 PD 分离？
| 部署情境 | 主导瓶颈 | 是否值得做 PD 分离 |
|---|---|---|
| 单节点内 NVLink，短 prompt | BW （且数据极小） | 通常不需要分离，直接 colocated |
| 同 rack 400 Gbps RoCE，长 prompt | BW，可 layer-wise 掩盖 | 典型 PD 分离场景，DistServe / Mooncake 适用 |
| 跨 rack 同 DC | 取决于 chunk 策略；若聚合可保持 BW-bound | 适合，但必须 chunked transfer |
| 跨 DC / WAN | RTT-bound, PagedAttention 原生不可用 | 需要 KV 池化 + 大消息聚合 + prefix cache 命中调度，否则传输代价反向超过重算 prefill |
| 短 prompt (≤ 1K token) + 跨 DC | RTT-bound 严重 | 不建议跨 DC 分离，应在源 DC 内 colocated |
@tbl-kvbw-scenarios PD 分离的部署适用性判定
最朴素的"重算 vs 传输"判据：若 $T_{\text{transfer}} > T_{\text{prefill}}^{\text{recompute}}$ 则不如让 decode 节点自己重新跑一遍 prefill。在跨 DC 短 prompt 场景这种逆转很常见。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 两类瓶颈 | RTT-bound ($N \cdot \alpha$) vs BW-bound ($S/\beta$) |
| 临界点 | $S_{\text{KV}} \lesssim$ BDP 时纯 RTT-bound; $S_{\text{KV}} \gg$ BDP 时 chunk 大就 BW-bound |
| 关键实测 | 8×400 Gbps NIC 下消息 64 KB → 4 GB/s; 16 MB+ → ~49 GB/s, 16 MB 是饱和阈 |
| 跨拓扑量级 | NVLink ~纯 BW；同 rack 看 chunk；跨 DC 严重 RTT-bound |
| TTFT 掩盖 | 每层 KV 传输 < 每层 prefill 时，Layer-wise pipeline 几乎全部隐藏；跨 DC pipeline 失效 |
| 8 类优化 | chunked / multi-NIC / layer-wise / staging / GPUDirect / het TP / KV 压缩 / pull |
| 重算判据 | $T_{\text{transfer}} > T_{\text{prefill}}^{\text{recompute}}$ 时不如重算 prefill，跨 DC 短 prompt 常见 |
参考资料
- Mooncake GitHub README — Transfer Engine. https://github.com/kvcache-ai/Mooncake/blob/main/README.md
- RTT- or Bandwidth-Bound? Demystifying the KV Cache Transfer in Large Language Model Serving, NAIC 2025. https://dl.acm.org/doi/10.1145/3748273.3749196
- LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference, arXiv 2510.09665. https://arxiv.org/html/2510.09665v1
- DistServe, OSDI 2024. https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin
- FlowKV: A Disaggregated Inference Framework with Low-Latency KV Cache Transfer and Load-Aware Scheduling, arXiv 2504.03775. https://arxiv.org/html/2504.03775v1