DistServe (OSDI'24) 确立 P/D 分离范式后，SGLang、vLLM、Mooncake、NVIDIA Dynamo 等开源 / 商业系统全面跟进，Meta / Alibaba PAI / AWS / Volcengine / Moonshot Kimi 均已落地部署。PD 分离的常态输入长度已从 2024 年的 2-4K tokens，上升到 2025 下半的 32-128K tokens，1M 级别已列入 2026-2027 年产品规划（Kimi K2.5、Claude、Gemini 系列在 2025 年先后宣布 1M 上下文）。
长序列在共置（colocated）推理中已带来挑战；但在 PD 分离下，这类挑战会被放大，因为：
| 压力 ① D 端 KV 容量 | 压力 ② P→D KV 传输 | 压力 ③ 长序列 Attention 计算 | |
|---|---|---|---|
| 在 PD 分离下被放大机制 | D 端 HBM 必须同时存放所有活跃请求的 KV，长请求会让 batch size 急剧压缩 | 128K+ 的 KV 经网络搬运，传输时间可能超过 prefill compute 本身 | Decode 每一步都要对完整 KV 做 attention，decode 时长随 sequence 线性增长 |
| 关键定性阈值 | ≈ 128K（GQA 模型 D 端从并行退化为串行） | ≈ 64K（传输开始主导 TTFT） | ≈ 32K（标准 FMHA kernel 效率开始退化） |
| 是否有研究未覆盖区 | 有（异构 KV pool sizing 是 open 问题） | 多数已有工作 | 计算 + 路由联合优化是 open 问题 |
vLLM 社区 RFC #43470 "Bottleneck-aware expansion for PD disaggregation"（2026-05-22, author: zsn6493）首次将 PD 运行时的压力分为三类：
关键原文："decode-side KV capacity becomes the dominant bottleneck even when compute is still available; remote KV transfer backlog creates hidden stalls between the two pools"
协作方 robertgshaw2-redhat（llm-d 组织，与 NVIDIA Dynamo 同源）回应：该能力应放在编排层（llm-d flow-control / Dynamo 路由），vLLM 作为执行层只需"暴露压力信号"即可 —— 这一分工共识说明KV 容量调度已从系统问题提升为编排层问题。
DeepSeek-V4-Pro FP8 + H200 GPU（total_gpu_memory=138.17 GB），PD 分离 prefill 节点因 is_hybrid_swa=true 错误地把 token 容量钳制到 swa_max_total_num_tokens = 18,432，而实际硬件 KV pool 可支撑 186,368 tokens：
Memory profiling: available_gpu_memory=17.94 GB, total_gpu_memory=138.17 GB, mem_fraction_static=0.90, rest_memory=4.13 GB DSv4 memory calculation: bytes_per_full_token=23749.84, available_bytes=4.13 GB, full_token=186368 DSv4 pool sizes: full=186368, swa=18432, c4=46592, ... Request ... exceeds the maximum number of tokens: 100804 > 18432
这说明：即使在 140GB 级 GPU 上，PD 部署的有效 KV 容量利用率低于 14%（Pool 可用 186K 但被 SWA 限到 18K）。问题不只是硬件不够，而是软件栈里的 KV pool 规划逻辑与长序列 load 不对齐。
源：#24523（2026-05-06, 14 comments, open）
GB300 节点（4 GPU/node, MNNVL fabric），Kimi-K2.5-NVFP4，mooncake transfer backend：
| 场景 | CUDA graphs | Per-rank running reqs | 结果 |
|---|---|---|---|
| PD disagg serving (mooncake) | on | 450–790 | deadlock 6/6 复现（4–8 分钟） |
| PD disagg serving | off | 512 (slot cap) | stable 26 min |
| Single-node agg, CUDA-graph on | on | 730–790 | stable 16 min |
解读：在 PD 分离 + CUDA graph 启用 + 高 batch 三者耦合时，D 端在长序列 decode 队列高密度堆积 → KV pool 实时调度与 CUDA graph 捕获的计算图失配 → 死锁。说明 D 端在高并发 + 长序列的压力耦合下，稳定性的工程挑战仍 open。
源：#30010（2026-06）
SGLang 在 GB300 NVL72 长上下文博客（2026-07-08）中明确写道：
"Long-context decode quickly becomes KV-dominated and memory-bound: each new token repeatedly reads the full KV history, so both KV capacity (how many sequences can stay resident) and HBM bandwidth become the primary bottlenecks."
团队列出的 key techniques 直接针对 D 端容量：
源：Deploying DeepSeek on GB300 NVL72: Big Wins in Long-Context Inference（LMSYS 2026-07-08，此前已抓取归档为 blog_gb300_longctx.md）
在 PD 分离下，D 端必须"收到完整 KV Cache"才能开始 decode，而这个等待时间直接加在 TTFT 上。共置推理没有这个成本（KV 就在本地显存里）。
NetKV（2606.03910）论文证明：
"Disaggregated LLM inference forces the KV cache to traverse the datacenter network before decoding begins, so transfer time enters directly into the Time to First Token (TTFT) budget."
更进一步的结论：随着上下文长度增长，仅靠 cache-aware（KV 亲和性）和 load-aware（负载均衡）调度会"arbitrarily suboptimal" —— 必须加入网络拓扑感知（network-aware）的代价函数。这说明在长序列 + PD 分离下，P→D 的数据路径本身从"完美网络假设"退化为"实际拓扑相关性"，这是共置推理不需要面对的挑战。
| 路径 | 代表工作 | 关键思路 | 长序列下适用性 |
|---|---|---|---|
| KV 渐进传输 | Lynx (2607.01831) | 把 KV 拆为 Anchor（高位，优先）+ Residual（低位，投机 decode），D 端收到 Anchor 就开始 decode | 直接针对长序列 decode 不能等完整 KV 的痛点 |
| GPU 友好 KV 压缩 | SplitZip (2605.01708) | 利用 float exponent 冗余做无损压缩，GPU 上实时编解码 | "especially for long-input and agentic workloads" — 作者在摘要里明确面向的场景 |
| 语义蒸馏 | SCD (2606.07684) | 用 low-rank 重建 + 稀疏 patch 替代原始 KV | 长序列下 semantic misalignment 随层累积，需有损 / 无损的精度取舍 |
| 按 token 混合精度 | SpectrumKV (2606.08635) | attention sink FP16 / 中重要 INT8 / 次重要 INT4（按模型 adaptive） | 长序列下"重要 token"分布变化，需要 token 级别的保护 |
Prefill-as-a-Service (PaaS, 2604.15039) 把 P 端和 D 端物理拆分到不同 DC，之间走 commodity Ethernet：
"... PD disaggregation has become the standard architecture for large-scale LLM serving, but in practice its deployment boundary is still determined by KVCache transfer. ... real workloads remain bursty, request lengths are highly skewed, prefix caches are evenly distributed, and inter-cluster bandwidth fluctuates."
对长序列研究者的启示：长序列下的 P→D 路径已经从"机内 NVLink" → "机架 RDMA" → "DC 内 RoCE" 一路退化到 "跨 DC Ethernet"。这是极端但现实的场景，在研究长序列 PD 时必须把网络距离作为一等参数，而不是 off-band 假设。
在序列长度远大于 GPU cache 容量时，D 端只能保留最新的 K 个 token（sliding window），一旦 decode 窗口滑出 KV pool，需要丢弃旧 KV 并在重新需要时 recompute——这就是 retraction。
GB300 博客原文明确提及这一危险：Wide-EP 的目标之一是 "without triggering retraction"。说明即使 288 GB HBM 的 GPU，retraction 在 128K 工作负载下仍是一个现实风险。
SGLang #31252 内也讨论了 HiCache 方案——Prefill 端用根号的 KV cache 表示（Lora-style），Decode 端只在需要时 reconstruct —— 这是对 retraction 问题的一个重构方案。
在 128K prefill 下，TTFT 从 ~3.2s 被压缩到 ~8.6s（GB300 + 32K dynamic chunking）。核心逻辑是
这说明：即使 P 端计算和网络传输都已经优化，prefill 本身的调度粒度在 128K+ 下仍是一个开放优化空间。
3DLS（2607.01617）指出，在长序列 PD 分离（每 layer KV 都要搬到 D 端）下，KV 传输与 TP 的 all-to-all 集体通信在同一 2D 平面互连上混跑，decode critical path 被拉长。
3DLS 的解法：把 KV 传输走垂直（3D TSV）通道，让 decode-side TP 留在平面互连上。1.49× throughput 与 60.2% latency 下降，给出方向：长序列 PD 的芯片互连拓扑需要为 KV 传输单独开道。
长序列不仅是"单请求长 prompt"，更是"多轮对话累积长 history"。
这两项工作共同指向一个洞察：长序列 PD 的真实压力不在"长 prompt"本身，而在"长 history 反复被搬动"。缓解策略的核心是"稳定 D 端 residency"——一旦 KV 落地 D 端，就尽量别动。
| 工作 | 年份 | 核心思路 | 对 PD 长序列的适用度 |
|---|---|---|---|
| Mooncake (2407.00079) | FAST'25 | 三级 KV 存储（GPU-CPU-SSD）+ early rejection | ★★★★★ 商业部署先例 |
| Prefill-as-a-Service (2604.15039) | 2026 | 跨 DC P→D，commodity Ethernet 传 KV | ★★★★ 长序列 × 跨 DC |
| Lynx (2607.01831) | 2026 | Anchor + Residual 双重渐进传输 | ★★★★ 解决"D 端等完整 KV 才 decode"的假设 |
| SpectrumKV (2606.08635) | 2026 | per-token mixed precision 保护 attention sink | ★★★★ 长序列下 attention sink 是关键 |
| 3DLS (2607.01617) | 2026 | KV 传输走 3D 垂直互连 | ★★★ 芯片级，2027+ 才有硅 |
| HMA-Serve (2606.29986) | 2026 | GDDR-P + HBM-D 异构（phase-wise 量化） | ★★★ 长序列下 prefill 端 KV 精度损失问题 |
| 工作 | 年份 | 核心思路 |
|---|---|---|
| SplitZip (2605.01708) | 2026 | GPU 实时 lossless KV 压缩，613 GB/s |
| SCD (2606.07684) | 2026 | 语义蒸馏替代 raw KV（low-rank + sparse patch），TTFT ↑2.65× |
| NetKV (2606.03910) | 2026 | network-aware D 端选择（含拓扑代价） |
| MFS (2603.17456) | 2026 | Least-Laxity-First + RMLQ 避免多阶段流拥塞 |
| TraCT (2512.18194) | 2025 | CXL shared KV cache 替代 RDMA（rack-scale） |
| 工作 | 年份 | 核心思路 |
|---|---|---|
| ConServe (2606.01839) | 2026 | 对话级调度，Turn 1 走 PD，后续 pin D 端 |
| PPD MultiTurn (2606.13358) | 2026 | Turn 2+ append-prefill 直接在 D 端完成 |
| HexAGenT (2605.16637) | 2026 | Agentic workflow DAG 异构图调度 |
| Load-Aware Prefill Deflection (2607.02043) | 2026 | P 过载时分流到 D 端做 chunked prefill |
| DynaServe (2504.09285) | 2025 | micro-request 任意 token-boundary 切分 PD |
| EcoServe (2504.18154) | 2025 | 部分 PD + 滚动激活 |
| Price of Anarchy (2606.17081) | 2026 | 博弈论分析 + 自适应路由（NVIDIA Dynamo 实测） |
以下为 2026-07-15 后续调研新发现的高阶论文，进一步佐证上述判断：
对 vLLM main 分支（2026-07-15）源码级抓取，揭示 PD 分离下 D 端 KV 容量的内生矛盾：
block_size=16 / gpu_memory_utilization=0.92 / cache_dtype="auto" / enable_prefix_caching=Truewatermark_blocks ≈ 1% 是 D 端 KV pool 几乎唯一的硬护栏。kv_lease_duration=30s + heartbeat 续约（~5s 周期、延 ~20s）把"承诺"变成可撤销，但续约本身增加长序列下 D 端高并发心跳压力。allocate_slots → determine_available_memory() 做一次完整 model run 量 peak memory 后反推出 KV 空间；KVCacheManager → BlockPool → KVCacheTensor 三层结构。这是长序列 PD 调参的"原始旋钮"。源：vllm/config/cache.py · nixl_kv_push_connector.md · nixl_kv_cache_lease.md · 本目录 vllm-decode-memory/index.html（713 行深度解析）
| 方向 | 当前论文密度 (2025-2026) | 工业落地密度 | 未来 12 个月预测 |
|---|---|---|---|
| D 端 KV 容量扩容（HBM / CXL / 异构） | ★★★ | ★★★★ | GB300 / MI355X / Rubin 发布让 HBM 不再是短期绝对瓶颈 |
| KV 压缩（渐进 / 混合精度 / 语义） | ★★★★★ | ★★★ | 从"论文井喷"到"少数方案收敛"（Lynx/SplitZip 路径有望胜出） |
| 长序列 PD 调度 / 稳定性 | ★★★★ | ★★★ | 伴随 128K+ 部署量上升，OOM / 死锁类 issue 将成为研究热点 |
| 1M+ PD 分离系统研究 | ★ | ★ | 预计 2027 年才会出现第一批系统论文（Moonshot Kimi 最可能首发） |
| 长序列 PD 与 kernel/FMHA 联合 | ★★ | ★★ | FMHA 长序列 kernel 优化（参考 GB300 SFU 升级）是关键依赖 |