📅 调研时间：2026-07-15 | 受众：AI 系统 / 芯片架构研究人员 | 覆盖：SGLang · vLLM · NVIDIA Dynamo · Mooncake · LMCache · arxiv 前沿（2024-2026） | 主题：挑战 · 流通模式 · CXL 影响分析 | 📎 续篇：PD 路由调研 · 长序列 PD 挑战（含 4 项子报告）
LLM 推理两阶段本质不对称：Prefill 对 prompt 做一次大矩阵乘，算力强但时间短；Decode 每次只生成一个 token，访存密集、对延迟敏感。传统统一调度把两者放在同一组 GPU 上，产生三类干扰：
在 5 种 LLM 上，统一调度相对于分离调度的 goodput 下降 3.4×–8.3×，因为 TTFT SLO 与 ITL SLO 无法同时满足。来源：arxiv 2401.09670
解决路径：把 Prefill 和 Decode 拆成独立实例池，中间通过高速网络把 Prefill 产生的 KVCache 传给 Decode。传输行为 = 整个系统的新瓶颈与新战场。
| 模式 | 数据流向 | 代表系统 | 核心特征 |
|---|---|---|---|
| Pull（拉取） | D 主动 RDMA READ P 端的 KV | vLLM NixlConnector (默认) | D 拥有调度主动权；P 被动“扣块”持有 lease |
| Push（推送） | P 主动 RDMA WRITE 到 D 预分配的内存 | vLLM NixlPushConnector | D 提前注册 block 信息；P 在 forward 结束后立即发 |
| Peer-to-Peer 共享池 | KV 写 → 多级缓存（GPU/CPU/SSD）→ 任何实例可取 | Mooncake · LMCache MP 模式 | KVCache 成为"一等公民"持久化对象；跨会话复用 |
KVCache 流通并非只在 P→D 请求级发生，按时间粒度可分为四层：
来源：SGLang Blog（Deploying DeepSeek with PD Disaggregation, The SGLang Team, 2025-05）
核心设计：Prefill Server 与 Decode Server 通过本地 sender/receiver 配对握手，Decode 侧先预分配 KV cache 后通知 Prefill 发起 forward；forward 后数据通过非阻塞 RDMA 直传。
来源：Deploying DeepSeek on GB200 NVL72 (Part I): 2.7× Higher Decoding Throughput, SGLang Team, 2025-06
在 GB200 NVL72 上最大的变化：
来源：SGLang GitHub · Kimi K2 在 128 H200 上的部署
SGLang Router 在 PD 分离中承担"轻量调度"：基于 label 自动发现 P/D 节点，支持 least-privilege routing 与 decode-partition 定制化负载均衡。Kimi K2 (1T MoE, 384 experts) 实测 decode 288k tok/s，成本 $0.21 / 1M output。
来源：Disaggregated Prefilling (experimental) - vLLM Official Docs · vLLM GitHub docs/design/nixl_kv_push_connector.md
| 连接器 | 后端 | 适用场景 |
|---|---|---|
| NixlConnector | UCX (IB/RoCE), GDS (GPUDirect Storage), TCP | 通用 P→P2P KV 传输 |
| NixlPushConnector | NIXL WRITE 直写 D 的显存 | 降低 D 等待延迟、绕过 D 侧调度排队 |
| MooncakeConnector | Mooncake 传输引擎 | 跨节点 GPU 直接 KV 搬运 |
| LMCacheConnectorV1 | LMCache 后台的 NIXL 通道 | 跨会话 KV 持久化 + P/D 分离 |
| OffloadingConnector | CPU DRAM | KV 溢出 CPU 卸载 |
| FlexKVConnectorV1 | 分布式 KV Store | 超大规模多 LLM 共享 |
| MoRIIOConnector | ROCm 生态 | AMD 平台专用 |
来源：vllm/docs/design/nixl_kv_push_connector.md © vLLM Authors
Pull 路径：P 完成 forward 后等待 D 主动 READ → D 获得控制权；P 端需 lock block（做 lease）防被提前 evict。
Push 路径：D 在 allocate block 后主动发 PUSH_REG:msgpack 通知 P 端的物理地址，NixlPushWorker 在 P 端以 NIXL WRITE 把 block 直接写进去，再发完成通知给 D。
Push 优势：P 端紧接 forward 立即发 → TTFT 更小；D 端只需支持后台 completion 入队，不消耗主循环。
来源：vllm/docs/design/nixl_kv_cache_lease.md
kv_lease_duration=30ssend_notif/get_new_notifs 通道，支持 IB/RoCE→TCP 自动 fallback来源：arxiv 2407.00079 "Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving"（Moonshot AI, 2024-06） · Mooncake GitHub
Kimi 在线推理平台 Mooncake：Prefill 集群 + Decode 集群 + CPU/DRAM/SSD 的 KVCache 三层级分离式 cache。核心调度策略是"KVCache-centric"：不再是先请求后分配，而是先找 KVCache（抢占/迁移）再决定放哪里 prefill。
关键结论：在模拟高负载场景下，KVCache-centric 比 prefill-centric 策略提升 525% throughput（同时满足 SLO）。同时 Mooncake 采用prediction-based early rejection：过负载时提早丢掉不会在 SLO 内完成的请求。
来源：arxiv 2510.09665 "LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference"（IBM Research 等） · LMCache Docs
LMCache 的三大贡献：
vLLM 最近引入的另一种反方向思路：不流传 KV block，而是把 KV 放在一个全局 KV Store，Decode Worker 按需 fetch。适合 ultra-large-scale 多模型场景。
来源：NVIDIA Dynamo GitHub (2026-07)
| 能力 | 角色 |
|---|---|
| Disaggregated P/D | 把 P 池 / D 池独立扩缩 |
| KV-Aware Routing | 按 worker 负载 + KV cache overlap 路由，消除冗余 prefill（2× TTFT 提升实测） |
| KV Block Manager (KVBM) | GPU → CPU → SSD → Remote Store 多级 offload |
| ModelExpress | NIXL/NVLink 权重流：7× 更快拉起新副本 |
| Planner + AIConfigurator | 10K + 部署配置模拟；SLA-driven autoscale；80% SLA breach ↓ |
| Grove | K8s topology-aware 调度，NUMA/NVL72-aware |
Dynamo 的哲学：KV Cache 不再是 engine 内部概念，而是 data center 一级的资产。KVBM 让 KV Store 脱离任何单一 vLLM/SGLang 实例，这是与 LMCache 思路的融合。
一个 100K token 的 prompt，按 DeepSeek-V3 的 MLA 参数，prefill KV 就有几个 GB。在 400Gbps RDMA 下仅传输就占 ~0.1–0.3s，这是 TTFT 中的大块。
最新论文已证明（Towards Load-Aware Prefill Deflection, arxiv 2607.02043, 2026-07）：production 集群 P95 TTFT 中，仅 2-23% 真正在做 prefill 计算，其余都是排队 + KV 搬移。结论：调度器必须把网络拓扑代价纳入目标函数（NetKV, 2606.03910）。
3DLS 论文（arxiv 2607.01617, 2026-07）指出芯片级问题：在 2D/2.5D chiplet 芯片上，P→D KV cache transfer 与 Decode-side TP allreduce 争夺同一条横向 Die-to-Die 互连带宽，混合流量干扰 decode critical path。3DLS 提出用垂直互连把这两类流量解耦。
HMA-Serve（arxiv 2606.29986, 2026-06）：用 GDDR 卡做 prefill + HBM 卡做 decode（AMD MI355X + H100），跨厂商导致：
Kimi K2 部署（128 H200, Mooncake team, arxiv 2407.00079）：实测 agentic 场景 input length 常在 30K–50K，每轮 P→D 搬一次 + D→P 再搬回 → 带宽轻松打满。PPD Disaggregation（arxiv 2603.13358, 2026-03）提出区分 append-prefill vs prefix-prefill，只搬 diff。
| 方法 | 思路 | 论文 |
|---|---|---|
| SplitZip | 无损 KV 压缩后传输 | arxiv 2605.01708 |
| SpectrumKV | Attention sink FP16 + 中位 INT8 + 低位 INT4 per-token | arxiv 2606.08635 |
| Lynx | 渐进式 speculative quantization | arxiv 2607.01831 |
| SCD | 语义码本替代原始 KV | arxiv 2606.07684 |
arxiv 2401.09670. 首次系统化证明 separated PD 在 goodput 维度压倒统一调度；指出 KV transfer 在单节点可通过 NVLink 低成本完成，但 cross-node 的代价决定全局部署拓扑。
arxiv 2407.00079. 提出 KVCache-centric scheduler：把 KV Cache pool 大小作为调度核心约束；过载时主动 early rejection。预测："KVCache-centric 将成为未来 LLM serving 的 default 范式" Mooncake Team, 2025 LMSYS Blog。
注：SplitServe（另一分支方向）讨论离线训练 + 推理的共存，属于不同问题；本文不展开。
arxiv 2606.24506. 解决多 LLM + 稀疏 MoE 的静态 KV 浪费：cold model 峰值 KV 重叠概率低，共享 pool 可显著降低 reserve 成本。
arxiv 2606.03910. 提出 thin operator-scheduler 接口 + network cost oracle。关键结论：仅考虑 prefix-cache hit 的调度在上下文变长时任意次优（可证明）。NetKV 在 64 GPU 集群 5 类模型上提升 30-55% goodput。
arxiv 2601.11822. 在单 GPU 内部通过硬件时间 multiplex 模拟 PD 分离，消除 prologue/epilogue 开销；不需要跨节点 KV transfer。
arxiv 2607.02043. 结论：在 D 端穿插 chunk-prefill 对冲 P 节点饱和，让 P 池和 D 池互为冗余。P 池利用率可从 22% 提升到 60%+。
arxiv 2607.01617. 首个在芯片架构层面把 P-KV transfer 与 D-collectives 用垂直 die 分离的研究；提出"KV-cache 专用的 die-to-die channel 将来可能是必需"。
TokenScale（arxiv 2512.03416）提出 "Token Velocity" 自指标，利用 token 产出速率作为领先信号替代 lagging GPU 利用率 驱动 autoscale。两者共同指向：PD 分离的动态调度必须进入毫秒级反馈时代。
背景延伸：前述结论来自 /tmp/research_cxl.md（本调研的子代理已完成 CXL 专项）。本节结合调研收集的最新进展给出系统判断。
| 属性 | 意义 |
|---|---|
| Memory Pooling | 跨主机共享 TB 级内存；GPU 可直接 load/store 远端 CXL memory |
| Cache-line 粒度 | 与 GPU 按 page 搬 KV 块不同，CXL 语义是 64B–256B 随机访问 |
| 带宽延迟 | CXL 3.0 ~64 GT/s × 16 lanes ≈ 256 GB/s（单向）；延迟 hundreds ns（~1μs） |
| 协议兼容 | CXL 在 PCIe 物理层之上，与现有 I/O 生态兼容 |
来源：/tmp/research_cxl.md（已通过 arxiv / IEEE 等检索验证）
| 系统 | CXL 用法 | 效果 |
|---|---|---|
| ITME | SK Hynix CMM (CXL Memory Module) | 吞吐 ↑35.7% |
| SAC | Sparse attention → CXL 随机取 KV | 2.1× ttput, 9.7× TTFT |
| Beluga | CXL Switch GPU-direct + KV 本地缓存 | 7.35× |
| TraCT | Rack-scale CXL pooled memory 作为 KV Store | 9.8× TTFT |
| PNM-CXL | Processing-near-memory + CXL | 21.9× ttput, 60× 能耗↓, 7.3× TCO |
判断：CXL pooled memory 最可能作为 "KV 持久共享层"——NIXL/Mooncake 继续承担跨数据中心 KV 迁移与热路径层间搬移；CXL 承担"冷 KV 远程缓存在内存池里随用随取"。这与 Dynamo KVBM / LMCache 的三级分层是同一个方向。
TraCT 实测：在 rack-scale 8 节点、H100 作 P、CXL 内存池作 KV Store，长上下文（128K）的 TTFT 提升 9.8×；关键 trick：P prefill 后的 KV 不经网络挂到 D，而是写到 CXL Pool；D decode 直接 CXL load。进一步佐证了上述判断。
完整链接列表详见本地 references.md（含访问失败链接）。下方列出本节文的全部超链接。
research_cxl.md）