头部互联网公司：大模型推理 Prefill↔Decode 之间的流量走向调研

2026-07-15深度报告40+ 公开来源工业实践 × 学术论文

1. 背景：为什么 PD 分离之后的"路由"成了核心命题

自 DistServe (OSDI'24, ref1) 在 LLM Serving 中确立了"Prefill / Decode 必须分离"的基本范式后，几乎所有头部互联网公司的推理栈都已或将切换到 PD 分离架构。PD 分离的核心价值：

• 解耦算/存瓶颈：Prefill 是 compute-bound，Decode 是 memory-bandwidth-bound，资源画像完全不同。
• SLO 独立优化：TTFT 主要取决于 Prefill 质量；TPOT/TBT 主要取决于 Decode 质量。
• 消除干扰：Prefill 的 burst 计算不再打乱 Decode 的 steady-state 滑动窗口。

2. 路由维度与"流通途径"分类

P/D 分离中的路由（routing）可以分为一个控制平面与一个数据平面两层。两者是不同的"走向"：

2.1 控制平面路由（Placement / Orchestration / Scheduling）

决定 "请求去哪个 Prefill Worker 跑 / 去哪个 Decode Worker 接"。

2.2 数据平面路由（KV Transfer Path）

决定 "KV Cache 沿着哪条物理/网络路径从 Prefill 端到 Decode 端"。详见 §6。

2.3 路由决策粒度

• 请求级 (request-level)：每个请求选定 P + 选定 D，之后 KV 走唯一通路。DistServe / Mooncake。
• Token 级 (token-level / chunk-level)P → D 在 token 粒度上切分，多个 micro-request 并行跑。DynaServe ref14。
• 层/层组级 (layer-level)P 端每算完一点就马上推到 D 端（流水线化 KV transfer）。HexAGenT ref19、Lynx ref22。
• 多轮会话级 (conversation-level)第一跑走 P → 之后 Turn 直接在 D 端追 prefill，不再走 PD 管道。ConServe ref20 / PPD-MultiTurn ref16。

3. 头部公司 / 云服务平台的公开披露

3.1 Meta

"We built a disaggregated inference stack with PyTorch & vLLM. The architecture introduces a Service Proxy attached to the decode server that forwards requests to remote prefill hosts for KV transfer. The router load-balances across prefill hosts using server workload and caching hit rate... This design enables independent scale-out of prefill and decode capacity..." — PyTorch Blog, "Disaggregated Inference at Scale with PyTorch & vLLM", 2025-09-12（参考 a8fe agent 的搜索结果）

关键路由特征：

• decode 端的 Service Proxy 是路由入口；KV transfer 完成后把 KV 拷贝进 decode 端的 KV block pool。
• 在多个 prefill host 之间按 workload 与 cache hit rate 联合选路。
• prefill 与 decode 节点可独立扩缩容。
• 异步 KV Connector，KV 传输与模型主流水线并行（不抢 GPU 计算）。

3.2 Alibaba PAI / EAS (百炼)

• 2025-08-06 EAS 发布 PD 分离功能，支持 vLLM、SGLang、BladeLLM 三种引擎。
• 提供 静态 PD 分离、动态 PD 分离、共置 三种模式——路由决策点就是"进 P 池还是完全本地处理"。
• 与 MoE 专家并行(EP)联合部署 DeepSeek MoE：路由层同时考虑 PD 分离 + EP 并行度 两个维度（参见 KVDirect ref4 和 EPD EPD blog）。
• 通过 API 网关（Inference Gateway + Inference Extension）暴露配置化路由策略。路由依据 token 数阈值、SLO、缓存命中等信号。

3.3 Moonshot AI（Kimi / Mooncake）

• Mooncake 是 Kimi 推理平台的内核，USENIX FAST'25 收录。
• KVCache-centric 架构中的 Conductor（全局调度器）决定 P→D 的完整路由，可做出 early rejection（过载时拒绝）。
• KV Cache 在 Prefill/Decode 之外用了三级存储：CPU DRAM → SSD → 网络 KV pool，路由端根据优先级、容量、成本在这三层间搬运 KV。
• SLO-aware token-level routing：每个 token/batch 的 KV 应在哪一程、落在哪个 worker，由 Conductor 在中心统一决定。

3.4 ByteDance (Volcengine / EIC)

• Volcengine 的"模型推理服务"显示支持 PD 共置 + PD 分离 两种模式，并配有"智能路由、全局 KV Cache 管理、独立扩缩"（产品文档层面公开）。
• Jakiro 框架（ACM 2025）为 PD 分离提供 VPC 内的 RDMA+TCP 共路网络基座。
• 与 NVIDIA 合作的 EIC（Elastic Inference Cluster）产品披露使用 NIXL GPU-GPU 零拷贝 + ZMQ 元数据通道做 Router 协调。

3.5 Microsoft Azure / OpenAI

• Azure OpenAI 服务大规模使用 vLLM 推理；内部转向 PD 分离（公开资料有限）。
• LLM-d（NVIDIA Dynamo 生态）在 Azure 大规模跑，采用 Dynamo 的 KV-aware Smart Routing（cache overlap + active load 复合指标）。
• OpenAI 未公开 PD 路由实现细节，但近期招聘启事与基础设施采购（NVLink + CXL 路线图）强烈暗示其走 PD 分离+异构 KV Pool 路线。

3.6 AWS

• Router = control plane (Dynamo + Bedrock)，用户可选 token threshold 决定是否走 PD 分离。
• Web 搜索结果显示：AWS 使用 vLLM + Dynamo + HyperPod 做 PD 分离，并在 NDInf2 / Trn2 实例上实测。

3.7 Google Vertex AI / Anthropic

• Google 完全没有公开 PD 路由论文或博客，但 Pathways 架构天然是 PD 分离形态的扩展，且大量使用 NVL72 约束下的 GPU 路由。可参考其 GKE Inference Gateway 论文推断"节点选择"维度。
• Anthropic 未公开，工程博客只披露了 Triton + 自研推理栈，PD 路由细节不明。

3.8 头部公司路由决策对比

4. 开源系统中的 PD 路由

4.1 vLLM（Push / Pull KV / NIXL）

• NIXL KV Connector（vLLM v0.25.1 起）：提供 Push / Pull 两种模式。Push：Prefill 端主动 KV 推给 Decode 端；Pull：Decode 端主动拉。设计文档。
• KV Cache Lease（lease = 30s + heartbeat renewal）：让 Decode 端保留 KV 锁，Prefill 端据此更新 TTL，lease 过期 KV 兜底清理。设计文档。
• 路由入口：DisaggPrefillRouter，基于 max-logits / prefix-hash + SLO 联合选路。

4.2 SGLang（LMSYS）

• Router PD 分离配置：--disaggregation-mode prefill|decode 确定 worker 角色；SGLang Router 通过 NIXL 模式下发 KV 搬运。
• 2025-05-05 LMSYS 博客详述在 96 H100 上做 DeepSeek + PD + Large-Scale EP，明确"Prefill 跑完 → KV 直接到 Decode 节点"流水线。博客。
• 2026-01 EPD 博客（Alibaba Cloud 合作）提出 VLMs 弹性 PD 编码分离。EPD blog。

4.3 NVIDIA Dynamo

• KV-aware Smart Routing （cache overlap score + active load 复合指标）：每个 Decode Worker 维护自己的 KV Cache pool 热度；Router 按 KV 命中分数 + 负载派发。
• 动态 GPU 调度：根据工作负载动态分配 prefill/decode GPU。
• 已原生集成 vLLM 和 llm-d，成为多家云厂商（AWS / Azure / GCP）采用的开源行业标准。

4.4 Mooncake（MoonshotAI/Mooncake）

• KVCache-centric scheduler 在中心调度 Conductor 中做全局路由 (placement)；early rejection 在负载超过阈值时直接拒绝长上下文的请求。
• CPU DRAM / SSD / 三级 KV 存储由 Conductor 在 "overloaded" 模式时 KV overflow 走 CPU。
• Simulated 场景最高 525% 吞吐提升；生产流 real workload 在 Kimi 上实测 +75% 请求处理能力。

4.5 LMCache / LMCache

• 将 KV Cache "脱离引擎"：所有 KV 通过 modular connector 落 CPU DRAM / Redis / S3，可跨引擎、跨查询复用。
• PD 模式中它的角色是为 Decode 端提供 "源" KV 存储：Prefill 端把 KV 写入 LMCache pool，Decode 端从 pool 拉取——反向路由。
• 被 vLLM 和 SGLang 同时集成。LMCache paper (2510.09665)。

4.6 其他开源

• KVDirect（S. Chen ref4）：tensor-centric 通信 + pull-based KV，把 PD 分布化到多机（含 EP）下跨节点通信开销降到 55%↓。
• BanaServe（ref6）：KV Cache 与路由解耦，用 KV layer-level / attention-level migration 让路由只关心 load，不关心 cache 位置（这是目前最独特的路由哲学）。
• AIBrix (>= 0.25 vLLM ecosystem)：Redis-style distributed KV cache 作为中间池。

5. 学术论文中的路由决策（2024 ~ 2026）

5.1 经典与范式型

• DistServe (OSDI'24, 2401.09670)：奠基工作。placement 与 AG/AMA 集群带宽联合优化，根据 TTFT/TPOT SLO 反向约束 P/D 比例。："Prefill 将请求送入哪个 Decode Worker"由中心 router 用动态规划决定。
• Mooncake (USENIX FAST'25, 2407.00079)：KVCache-centric Conductor + early rejection；过载时走本地 / CPU DRAM。
• TokenScale (2512.03416)：Token Velocity 指标 + Convertible Decoder（Decode GPU 临时改作 Prefill），突破 P 池瓶颈。这是一条完全新的"路由路径"——路由进入 P 端失败时，索性把请求推给 D 端，让它"叛变"做 prefill。
• DynaServe (2504.09285)：micro-request 任意 token-boundary 切分，SLO-aware 的 two-level 调度——决定一个请求的 "30% tokens 在 P 端跑，70% 在 D 端共演，比完整 PD 分离弹性高 1.15~3×。
• Microserving (2412.12488)：可编程 router + 子请求级 API，让 PD 策略可脚本化。

5.2 负载感知型 (load-aware / SLO-aware)

• LAPS ref_laps：prompt-length-aware 独立调度，长 prompt 走独立 P 池，短 prompt 在本地；增 35% 吞吐，-30% prefill latency。
• DOPD ref7：动态调整 P/D 比例，+1.5× goodput，P90 TTFT ↓67.5%。
• DualScale ref12：phase-aware placement + DVFS，能量↓ 39~48%。
• Price of Anarchy ref_poa：博弈论 + 自适应路由控制器，饱和时 PoA ↓3.1×。

5.3 拓扑 / 网络感知型

• NetKV ref21：network cost oracle + O(|D|) per-request greedy，TTFT ↓21.2%。
• Multi-stage Flow (MFS) ref17：Least-Laxity-First + RMLQ 结构，TTFT SLO attainment ↑1.2~2.4×。
• DualPath ref13：双路径 KV 加载（传统 P 路径 + 新 storage→D 路径，再 RDMA 从 D 传到 P），吞吐 1.96×。
• TraCT ref9：CXL shared memory 替代 RDMA，TTFT ↓9.8×，P99 ↓6.2×。
• HMA-Serve ref_hm：GDDR prefill + HBM decode 异构，跨厂商 KV 传输 + phase-wise 量化 + deferred dequant，goodput ↑3.2×、$/perf ↑4.8×。
• 3DLS ref23：3D 堆叠芯片，KV transfer 走垂直互连与 TP collective 走平面互连分离，E2E latency ↓60.2%。

5.4 KV Transfer 优化型（压低 KV 体积）

• Lynx ref22：Anchor Stream（高位） + Residual Stream（低位）渐进投机量化，TTFT ↓1.43× 同 BF16 精度。
• SplitZip ref18：GPU 友好的 lossless KV 压缩（利用 float exponent 冗余），613 GB/s 压缩，E2E TTFT ↓1.30×。
• SpectrumKV ref24：per-token mixed precision：attention sink FP16、中重要 INT8、次重要 INT4（按模型自适应 downgrade），50% KV budget 下 perplexity 变化 +1.97%（vs PDTrim +25.85%）。
• SCD (Semantic Cache Distillation) ref25：KL + Patch 替代 raw KV；2.65× TTFT 提升。
• ObjectCache ref26：KV Cache 落 S3 对象存储，层 wise 顺序传输，64K context 仅增 5.6% latency。

5.5 Workflow / 多轮 / Agentic

• ConServe ref20：对话级调度，Turn 1 走 PD，后段始终 pin 在 D 节点，不再搬 KV。p95 TT-First-Effective ↓51.08%，能效 +7.51%。
• PPD MultiTurn ref16：区分 full prefill 与 append-prefill，后者直接放在 decode 节点完成，KV 不再跨节点，Turn 2+ TTFT ↓68%。
• HexAGenT ref19：workflow-DAG 异构图 scheduling，联合决定 P/D placement + local queue priority；SLO scale savings 平均 20.1%。
• WRP Architecture ref_wrp：vLLM Semantic Router 三维框架 Workload-Router-Pool，给出 21 个未来方向。
• ELDR ref27：MoE expert signature 路由，locality-band routing 在多 MoE model 上 TPOT ↓5.9~13.9%。
• Prefill-as-a-Service (PaaS) ref28：跨 DC 把 prefill offload 到独立 compute-dense 计算集群，commodity Ethernet 传 KV，异构部署 +54% 吞吐、P90 TTFT ↓64%。
• CrossPool ref26（CrossPool）：Cold MoE 场景下 KV-Cache Pool 与 FFN weight Pool 分离，调度器在两个 pool 之间路由请求。

• NVLink / NVSwitch：同一节点内 GPU 之间，TB/s 级带宽、ns 级延迟。NVL72 (NVSwitch full mesh) 是最彻底的 PD "单节点内分离"。
• 3D 堆叠垂直互连（3DLS ref23）：KV transfer 走 TSV，TP collective 走 D2D，物理隔离；最尖端的走法，预计 2027 后有硅。
• CXL 在同一封装（Intel / AMD 方案）：目前主要在 L 2 层。

• RDMA (RoCE / InfiniBand)：100~400 Gbps，μs 级延迟。这是 PD 分离 KV 直通主力。Dynamo / vLLM / LMCache 主力路径。
• CXL 3.0 Fabric（TraCT ref9）：load/store 语义，媲美本地内存带宽，替代 NIC hop，TTFT ↓9.8×。
• PCIe P2P：跨 GPU 直传，带宽有限但延迟低。NIXL GPU-GPU 模式使用此层。

• Prefill-as-a-Service (PaaS) ref28：把 P 集群和 D 集群物理拆到不同 DC，commodity Ethernet 传 KV（model-side KV efficiency + system-side 智能调度），是当前 DC 间 PD 分离的最前沿设想。
• LMCache + S3 (Object Storage)：跨 DC 只传 hash-key，由 S3 兜底。ObjectCache ref26 已做到 64K context 仅额外 5.6% latency。

• Push 模式（NixlPushConnector）：Prefill 端主动 WRITE 到 Decode 端。关键工程细节：两侧 request_id 顺序无关，通过 writer-local matching tables + get_base_request_id() 剥离 Proxy 注入的 8-hex 后缀，实现 push 侧对齐。
• Pull 模式（NixlPullConnector）：Decode 端主动 READ。Proxy 把 kv_transfer_params 注入请求，Decode 端拿到后发起 NIXL READ。
• KV Cache Lease：per-request lease（默认 30s）+ heartbeat renewal。Decode 端从 queueing 阶段开始续租，lease 过期 KV 兜底清理。设计文档。
• 路由入口：DisaggPrefillRouter，基于 max-logits / prefix-hash + SLO 联合选路。

7.2 NVIDIA Dynamo：KV-aware Smart Routing

• Router 复合指标：cache_overlap_score + active_load 两维打分。每个 Decode Worker 维护自己的 KV Cache pool 热度。
• Planner：根据工作负载动态分配 prefill/decode GPU，原生集成 vLLM 和 llm-d。
• Liveness：Canary liveness 检测（非 lease 模型），失败时 KV 路由自动切换到备用 Decode Worker。

7.3 SGLang：Bootstrap Protocol + Push

• 角色启动：--disaggregation-mode prefill|decode 确定 worker 角色。
• CommonKVSender bootstrap：Prefill 端起 HTTP Bootstrap Server，Decode 端用 bootstrap_room 握手；follow_bootstrap_room 模式用 bootstrap_room % dp_size 决定 DP rank。
• 推送方向：sender 主动推送到 receiver 预分配地址（push 模式）。
• 超时：bootstrap_timeout = 300s。

7.4 LMCache MP：ZMQ DEALER/ROUTER + 双模式

• 协议：ZMQ DEALER/ROUTER 模式，RequestType 枚举（REGISTER / STORE / RETRIEVE / PREPARE / COMMIT）。
• 传输模式：lmcache_driven vs engine_driven 两种模式——前者由 LMCache 主动搬运 KV，后者由推理引擎驱动。
• 并发控制：ttllock 读写锁 per-object。
• 与 vLLM 集成：共享 NixlConnector，Router 使用 --vllm-pd-disaggregation 标志。

7.5 四系统路由对比

8. 核心洞察与研究前沿

9. 引用资料

关键论文

• DistServe: Disaggregating Prefill and Decoding (OSDI'24) [1]
• Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving (FAST'25) [2]
• A System for Microserving of LLMs [3]
• KVDirect: Distributed Disaggregated LLM Inference [4]
• LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference [5]
• BanaServe: Unified KV Cache & Dynamic Module Migration [6]
• DOPD: Dynamic PD-Disaggregation [7]
• TokenScale: Timely Autoscaling for Disaggregated LLM Serving [8]
• TraCT: Disaggregated LLM Serving with CXL Shared Memory KV Cache at Rack-Scale [9]
• RAPID-Serve: Resource-efficient P/D Intra-GPU Disaggregation
• DualScale: Energy-Efficient Disaggregated LLM Serving via Phase-Aware Placement and DVFS [12]
• DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference [13]
• DynaServe: Unified and Elastic Execution for Dynamic Disaggregated LLM Serving [14]
• EcoServe: Enabling Cost-effective LLM Serving with Partial Disaggregation
• TokenScale（同上）
• Not All Prefills Are Equal: PPD Disaggregation for Multi-turn [16]
• Multi-stage Flow Scheduling for LLM Serving (MFS) [17]
• SplitZip: Ultra Fast Lossless KV Compression [18]
• HexAGenT: Workflow- and Heterogeneity-Aware Agentic Serving [19]
• Observation, Not Prediction: Conversation-Level Disaggregated Scheduling (ConServe) [20]
• NetKV: Network-Aware Decode Instance Selection [21]
• Lynx: Progressive Speculative Quantization for KV Transfer [22]
• 3DLS: A 3D Logic-Stacked Architecture for Disaggregated LLM Serving [23]
• SpectrumKV: Per-Token Mixed-Precision KV Cache Transfer [24]
• Semantic Cache Distillation (SCD) [25]
• CrossPool: Efficient Multi-LLM Serving via KV-Cache Disaggregation [26] · ObjectCache: Layerwise Object-Storage Retrieval
• ELDR: Expert-Locality-Aware Decode Routing for PD-Disaggregated MoE Serving [27]
• The Price of Anarchy in Disaggregated Inference
• WRP Architecture (Workload-Router-Pool), vLLM Semantic Router
• Prefill-as-a-Service (PrfaaS), KVCache Cross-Datacenter [28]
• HBM Is Not All You Need (HMA-Serve, GDDR Prefill + HBM Decode)
• LAPS: Length-Aware-Prefill LLM Serving System
• Dual-Pool Token-Budget Routing
• StreamServe: Adaptive Speculative Flows
• Towards Load-Aware Prefill Deflection

官方博客 / 工程文档

• Meta · Disaggregated Inference at Scale with PyTorch & vLLM
• Meta Engineering · Scaling LLM Inference
• 阿里云 PAI · Prefill-Decode 分离部署
• Alibaba Cloud 博客 · EAS 发布 PD 分离
• 火山引擎 · 模型平台 PD 分离
• NVIDIA Dynamo 官方博客
• NVIDIA Dynamo GitHub
• LMSYS Blog Index