超长序列（1M+ Tokens）在 P/D 分离架构下的挑战

关键信息源：Pipeline Parallelism for Long Context 文档（直接打开） + PR #8846（Support PD disaggregation with Prefill PP，2025-10 合并）

PPT 文档明确指出：

核心链条：

• SGLang 认为 1M+ context 的问题首先是 PP 问题——TP 跨节点有通信瓶颈，PP 只需 stage 边界通信，更适合长上下文。
• 但 PP+PD 的组合直到 2025-10 的 #8846 才首次支持（"Support PD disaggregation with Prefill PP"），且 Decode PP 至今未支持（"Decode PP will be supported in the next PR"）。
• 为了减小 pipeline bubble，SGLang 提出 Dynamic Chunking 机制——因为 attention 复杂度随 prefix 长度增长，chunk 大小需要动态递减，这揭示长 context prefill 的非均匀计算分布加剧了 PD 调度的难度。
• Micro-batching Event Loop + async P2P通信是现阶段解法，说明P→D KV 转移的延迟隐藏是工程瓶颈。

观察：SGLang 从未在文档中声称 PD disaggregation 是长 context 的天然解法；相反，社区对 1M context 的讨论几乎全部在 PP 范式下进行。PD 分离在 1M 场景下为何需要 PP 帮忙？这本身就说明 PD 架构面对长 context 时的原生瓶颈。

关键信息源：GitHub Issue #11286 [Performance]: decoding speed on long context（2024-12 开）

Issue 实测数据揭示了长 context decode 的断崖式下降（单 A800 80G, bs=90）：

vLLM 维护者 noooop 的官方解释（直接译文）：

对 PD 架构的启示：

• 上述数据是共置引擎的观测，PD 分离下 D 端的 KV 同样遇到该带宽瓶颈，且更严重——因为 KV 还要从 P 端跨网络传输而来。
• chunked_prefill 在长输入下更优，但用户报告"仍无用"——暗示vLLM 默认 scheduler 在长 context 下 bubble 问题主导。
• vLLM 目前没有针对长 context 的 decode 端 HBM capacity planning 专门的 issue 或文档，--block-size 仍是主要调优参数，未发现类似 SGLang PP 的专门配套。

vLLM Semantic Router（arxiv:2604.dualpool 同源工作）：xunzhuo 系列的 Token-Budget Routing 指明 fleet 中 80-95% 是短请求，为最坏长 context 配置 fleet 会导致 4-8x 吞吐浪费。

关键信息源：Mooncake HTML 全文 + PrfaaS (arxiv:2604.15039) + SGLang #8846

Mooncake 生产视角下长 context PD 的独有挑战：

• Overload-oriented Scheduling：Mooncake 论文明确指出"existing research assumes all requests will be processed"——只有 Kimi 因用户量暴涨 facing severe overload。长 context 加剧 overload：每个请求占据 decode slot 期间还要持续消耗 HBM 容量。Early rejection policy 必须预测 generation length。
• Prefill + 长 context 的相互恶化：Conductor 要尽可能复用远程 KV Cache 以减少计算，但"waiting for KVCache stored on lower-tier storage may violate TTFT SLO"；同时 "high demand on KVCache server can lead to network congestion"。
• Decode VRAM 硬上限："aggregation 受 TBT SLO 与 decode 端 VRAM 可容纳 KV 总量双重限制"。当 batch size × context length × KV/ token > VRAM 时 decode 端直接饱和。
• Chunked Pipeline Parallelism (CPP) + Layer-wise Prefill：Mooncake 专为长 context TTFT 设计的机制，将 KV 流式传输到 decode，与 SGLang 后来的 PP for Long Context 不谋而合。
• PrfaaS (2026-04)：Moonshot 近作进一步承认——长 context dense attention 下的 KV 迫使 P/D 紧耦合在同一个 RDMA 域；hybrid attention 使跨 DC 部署成为可能，但non-trivial："real workloads remain bursty, request lengths highly skewed, prefix caches unevenly distributed"。

• NVIDIA Dynamo (路由层)：目前公开的 Dynamo 讨论聚焦 KV-aware routing（cache overlap + active load 复合指标），但未发现专门针对 1M+ context 的 PD 路由策略公开文档。Rubin CPX 是 NVIDIA 首个"prefill 专用加速器"（2025 台北展），隐含的叙事是长 context prefill 的算力需求已需要专用芯片。
• Meta：PyTorch Blog 2025-09-12 披露的 Service Proxy at Decode + cache-aware LB，upstreaming 到 vLLM；同样未公开长 context 专项讨论。
• Alibaba PAI-EAS：三种静态/动态 PD + EP 模式可配，但无 1M+ context 专项资料。
• AWS：Dynamo-style router = control plane + token threshold 路由；未见到类似 Mooncake early rejection 的公开材料。

PD 分离相对于共置推理的独特挑战：

判定：PD 分离下长 context 的 HBM 容量压力不仅是绝对量的放大，更是调度时序问题——KV 在传输中不可被 decode 使用，但已在目标节点被预留。

传统 PD 理论基础——prefill 是 compute-bound，decode 是 memory-bound——在长 context 下在两个阶段同时失效：

• Prefill 端：attention 是 O(N²) 计算，1M token prefill 的 compute 与 memory 同时爆炸（即使 chunked prefill，prefill 依然需要暂存中间 KV）；
• Decode 端：曾经每个 batch 只需 attention 到当前 token 的固定成本，现在必须 attention 到 1M+ 历史 token——decode 不再是简单的 memory-bandwidth-bound；它变成了长序列 read-bandwidth-bound + capacity-bound 双杀；
• 系统层面：the ratio of compute-to-memory capacity（OI/CF）在长 context 请求间变化 10-100x，令 fleet 配置困难 (arXiv:2601.22001)。

以 Llama-3-70B（80层, 128 head dim=128, GQA 8 组）为例估算：每个 token 的 KV ≈ 80 × 8 × 128 × 2 × 2 bytes ≈ 320KB。

• 1M token → 320GB KV 共（超过任何单机 HBM，必须分片）。
• 即便是 100K token，KV 也 ≈ 32GB，单节点 HBM 即被占满。
• Lynx (arxiv:2607.01831) 直面此问题：challenge 了 "KV cache 不可分割" 的隐含假设，但这是 2026-07 才出现在 SIGCOMM 的新工作。

PD 分离特有现象：KV 不仅要跨网络传输，还要按 batch + layer 顺序组织以便 decode attention 直接读取。这进一步增加了 decode 端的 buffer 管理复杂度。

• SGLang 的 RadixAttention 在 short context 下 hit rate >80%，但在 long context 下，prefix 块极易超过 DRAM/SSD 容量被驱逐——每个 long request 占据大块 radix tree，子节点极少被复用。
• Mooncake 三级存储（GPU HBM → CPU DRAM → SSD）中，long context 占用 SSD tier 后，即便 HBM 空闲，KV 仍需从 SSD->DRAM->HBM 多跳读取。
• SAC (arxiv:2606.19746) 是首个针对该问题从 CXL 语义出发的 disaggregated KV 系统，暗示 RDMA 时代 PD 的 prefix cache 假设已不可扩展。

Dual-Pool Token-Budget Routing (arxiv:2604.08075) 直接指出：

• 生产 fleet 按 worst-case context 配置 → 80-95% <1K 请求都在"长上下文模式"下运行，浪费 4-8x 并发能力。
• 长请求的 KV pool 占满 decode 节点后，短请求被 preemption → 5.4x preemption rate 提升。
• PD disaggregation 假设 prefill / decode 解耦后各自独立调度，但长 context batch 实际上让 decode 变成了 queue-length-dominated 系统。

Mooncake (arxiv:2407.00079) 观察到一个反直觉现象：

原因：长 context 请求在 prefill 完成后才知是否能在 decode slot 中被接受。prefill 是 expensive compute，如果被 reject，已消耗的计算被浪费、网络带宽被占用、decode 端的期望 batch 被破坏。

SAC (arxiv:2606.19746) + PNM-1M (arxiv:2511.00321) 代表一条路径：让 KV 留在远端，只在 decode attention 需要时 cache-line 粒度读取。对 PD 的影响：

• D 端不再需要全量 KV 驻留 HBM——HBM 从"KV pool"降级为"KV cache"。
• 代价：每次 attention 都要 CXL 读取延迟（~100ns vs HBM ~50ns），仅对 sparse attention 可行。

限制：CXL 生态成熟度、dense attention 无解。

Lynx (arxiv:2607.01831) + Token-Budget Routing (arxiv:2604.08075) 代表系统层压缩路径：

• Anchor + Residual 双流让 decode 在 10% KV 到达时就开始工作——TTFT 接近 4bit 量化但精度等同 BF16。
• Token-Budget Routing 按预算路由让长 context 进专用 pool，避免fleet 层污染。

限制：仅解了 P→D 传输瓶颈，D 端 HBM 容量瓶颈仍存。

3DLS (arxiv:2607.01617) 代表硬件层路径：将 P→D KV 转移走垂直互连，decode TP 留在 lateral fabric，避免混合流量竞争。

• 这是首个承认"PD 长 context 瓶颈已到达封装互连层"的工作。
• 吞吐比共享 fabric 基线高 1.49x，比 workload-aware priority 基线高 1.17x。

限制：尚未流片，2-3 年内不可生产。

Moonshot 的 PrfaaS (arxiv:2604.15039) 承认：dense attention 下的 PD 长 context 是无解的——必须依赖 hybrid attention（如 Jamba、DeepSeek-V3.2 的 sparse attention）压缩 KV 才可能。

范式判断：工业界正在从"PD 系统层面解决 long context"向"模型架构 + 系统协同"视角迁移。

Mooncake 的 Conductor + early rejection + 预测未来 generation length，演进到 PrfaaS 的跨 DC KV 选择性 offload——这是唯一一条被商业产品验证的路径。

内在限制：overload 预测依赖 workload pattern，面对 bursty long context 流量（agentic 系统）预测准确率下降。

• SGLang：PP for Long Context 文档承认 TP 跨节点不适合长上下文，PP 是正确答案；但 PP + PD 组合直到 2025-10 的 #8846 才初步支持 Decode-side PP 至今 pending。Dynamic Chunking 部分缓解 pipeline bubble，但无法突破单 request KV 容量墙。
• vLLM：Semantic Router（Dual-Pool Routing 同族）+ NIXL push/pull KV transfer，没有 1M+ context 专项优化路径。--block-size=128 是当前仅有的长 context 参数。
• NV Dynamo：KV-aware Smart Routing 是行业标准路由，但未公开 1M+ 专项策略。