LLM 推理服务的 PD 分离架构 2026：从 KV 跨节点传输到容量规划的生产真相

一句话摘要：当 prompt 长度从 200 token 涨到 32k token，prefill 与 decode 在同一张 GPU 上互相阻塞、共置架构的算力错配成为推理服务的头号瓶颈；2025 年起业界全面转向 PD 分离（Prefill-Decode Disaggregation），把 prefill 池与 decode 池部署在不同节点，通过 RDMA/NCCL 跨节点传输 KV cache，这是一次"打破 GPU 共置假设"的根本架构演进，也是 2026 年推理服务的默认形态。

一、问题的提出：prefill/decode 共置的死结

大模型推理服务化走到 2026 年，已经不再是"能不能跑起来"的问题，而是"在不同 workload 下能不能稳定 P99 达标"的问题。当我们把目光从 demo 转向 production，会发现推理延迟里最大的方差来源既不是模型权重，也不是 batch size，而是prefill 与 decode 两个阶段的算力特征完全相反，却被强行塞在同一张卡上。

prefill 阶段处理整个 prompt，对长上下文来说是算力密集型——一次矩阵-矩阵乘法（GEMM）吃满 Tensor Core，HBM 带宽占用相对低；decode 阶段逐 token 自回归生成，是内存带宽密集型——每次只取一行的 KV cache，矩阵-向量乘法（GEMV），HBM 带宽成为天花板。两类 workload 的资源画像差异可以用一句话总结：prefill 是 compute-bound，decode 是 memory-bound。

共置架构的代价是双重的。第一重是抢占：当一个长 prefill 请求到来时（32k prompt + 长 thinking），它会把 Tensor Core 全部吃满，导致同卡上正在 decode 的请求被严重阻塞——表现为尾部延迟飙到几十秒。第二重是调度失败模式叠加：连续调度器（continuous batching）在共置架构下必须用复杂的优先级规则才能避免 prefill 把 decode 饿死，但任何规则都只能减轻、不能消除这种错配。

PD 分离（Prefill-Decode Disaggregation）的核心思想很朴素：承认两类 workload 的不可调和，让它们各自跑到最适合自己的硬件上。prefill 进 prefill 节点（用 H100/H200，喂满 Tensor Core），decode 进 decode 节点（用 A100/L40S，吃满 HBM 带宽），中间靠高速网络把生成的 KV cache 跨节点搬运过去。

但这种朴素想法的工程化代价远超预期，2024-2025 年间业界踩过的坑可以列出一长串：RDMA 传输超时导致请求失败、KV 序列化开销比 prefill 本身还大、容量配比算错导致 prefill 池空转而 decode 池排队、调度器无法处理"prefill 完成但 decode 节点尚未 ready"的状态机……本文试图把这些坑按工程演进的逻辑串起来，给出 2026 年可用的 PD 分离生产架构真相。

二、形式化：算力错配与 KV 跨节点传输

定义一个推理请求 r 的延迟 D(r) 为从请求进入队列到第一个 token 输出（TTFT, Time-To-First-Token）与后续每个 token 间隔（ITL, Inter-Token Latency）的函数：

• TTFT ≈ T_queue + T_prefill
• ITL ≈ T_decode_per_token + T_transfer

在共置架构下，T_prefill 和 T_decode_per_token 共享同一张 GPU 的算力与带宽——我们用 ρ = (T_prefill / T_decode_per_token) 表示算力错配比。对一个 7B 模型在 H100 上、prompt=8k token、输出=512 token 的请求，ρ 通常在 5-15 之间，意味着 prefill 单步耗时是 decode 单步的 5-15 倍；当 batch size 增大，prefill 的边际时间几乎线性增长，而 decode 因为是 GEMV，边际时间近乎不变——这就是为什么 batch 越大 prefill 越"贵"。

PD 分离的数学基础是算力解耦后的乘法延迟模型：

• 共置下 D(r) = max(T_prefill, batch 排队) + N × T_decode（受共置争抢影响，P99 雪崩）
• 分离后 D(r) = T_prefill_in_prefill_pool + T_transfer_KV + N × T_decode_in_decode_pool（各自最优池内调度，P99 显著可控）

但分离引入了新变量：T_transfer_KV。对 7B 模型、prompt=8k、batch=8 的请求，KV cache 大小约为 8 × 8k × 40 层 × 2 (K+V) × 128 头维 × 2 字节 (FP16) ≈ 1.3 GB——必须在 prefill 完成到 decode 开始之间完成跨节点传输。

跨节点传输的带宽画像：InfiniBand HDR 200Gbps ≈ 25 GB/s，NDR 400Gbps ≈ 50 GB/s。1.3 GB KV cache 在 50 GB/s 链路上理论传输耗时 26ms——这看起来很短，但实际工程中 KV 序列化 + 反序列化 + 协议栈开销会把传输时间推到 100-300ms 量级。这是 PD 分离架构工程化的核心挑战。

PD 分离的容量规划需要同时满足四个约束：

1. Prefill 池算力约束：prefill 节点总 FLOPS ≥ Σ(T_prefill_i) / 单位时间窗
2. Decode 池带宽约束：decode 节点总 HBM 带宽 ≥ Σ(N_i × bytes_per_token_i) / 单位时间窗
3. 网络带宽约束：KV 跨节点传输链路的有效带宽 ≥ Σ(bytes_KV_i) / 单位时间窗
4. 状态机一致性约束：prefill 完成 → KV 传输 → decode 就绪 的状态转换必须原子化，否则会出现"请求丢 KV"或"decode 节点空等待"

四个约束同时满足意味着 PD 分离不是简单的"拆成两个池"——它是一次完整的容量规划 + 调度算法 + 状态机 + 可观测性的体系重构。

三、Prefill 池的特征与工程目标

Prefill 池的设计目标是最大化算力吞吐而非延迟均匀——它吃 prompt、做预填充，输出 KV cache 序列与初始 logits。Prefill 节点的硬件画像应当优先选算力峰值高、HBM 容量适中的卡，H100/H200/B100 是首选，A100 退而求其次，L40S 这类"带宽优先"卡几乎不适合做 prefill。

Prefill 池的关键工程参数：

• Max Sequence Length：决定每张卡的 KV 容量上限，是 batch size 与并发请求数的乘积上限
• Chunked Prefill：把超长 prompt（>8k）切成 512/1024 token 的小块分批处理，避免单次 prefill 把整张卡独占
• Prefix Cache 命中率：如果系统启用 prefix caching（前缀缓存），prefill 池的实际有效算力可以放大 30-70%——这是 PD 分离架构最大的性能杠杆之一（参见 id=470 LLM 前缀缓存语义工程 2026）
• Continuous Batching：prefill 池里同一时刻可能有多个请求在不同 chunk 阶段，调度器按 chunk 粒度调度

Prefill 池的常见工程坑：

• OOM on chunk boundary：chunked prefill 在切分点上若 KV 容量估错，会触发 OOM 而非 graceful degradation；正确做法是给 KV 预留 20% buffer
• Prefix cache invalidation：当 prefix cache 命中但用户请求改动中间 token，prefix cache 失效但算力已被部分消耗，导致"虚算力"——必须在调度层引入 prefix-aware prefill
• Long-tail prompt 独占：单个 128k prompt 请求即使 chunked 也会连续占用 prefill 节点几十秒，必须用 hard cap（如 64k）防止它把整个 prefill 池饿死

Prefill 池的可观测性核心指标是每秒生成的 KV 字节数（KV bytes/sec generated），这个指标直接对应下游 decode 池的可用 KV 带宽上限——它必须实时暴露给调度器，否则调度器无法做容量规划。

四、Decode 池的特征与工程目标

Decode 池的设计目标是最大化单请求 ITL 的稳定性——它吃 KV cache，逐 token 自回归生成，输出 token 流。Decode 节点的硬件画像应当优先选HBM 带宽高、显存容量大的卡，A100/L40S/H100 都合适，但 H100 因为 HBM3 带宽 3.35 TB/s 而 decode 性能远超 A100 的 2 TB/s。

Decode 池的关键工程参数：

• Max Batch Size：每张卡能同时 decode 的请求数，受 KV 容量与带宽双重约束
• KV Block Size：KV cache 按 block（如 16 token）分块管理，便于 prefix cache 与跨请求复用
• Speculative Decoding：如果启用投机解码（参见 id=460 推测解码的工程真相），decode 池的吞吐可以放大 2-3 倍
• PagedAttention：vLLM 的核心内存管理机制，把 KV cache 按页管理以减少碎片

Decode 池的常见工程坑：

• KV 容量耗尽：长输出请求（如 4k token 的 code generation）会持续占用 KV 容量，当 batch 满后新请求被阻塞，必须用 KV eviction（如 LRU）策略
• ITL 抖动：当 batch 内有"短输出 + 长输出"混跑时，短输出率先结束腾出 slot，长输出独自占显存，会触发 ITL 抖动——需要用 sorted batching（按输出长度排序）
• 推理时计算放大：Reasoning LLM 的 chain-of-thought 让平均输出长度从 200 token 涨到 2000+ token（参见 id=415），decode 池的容量规划必须把 thinking token 通胀算进去

Decode 池的可观测性核心指标是每秒生成的 token 数（tokens/sec generated）+ 当前活跃 batch 大小 + P50/P99 ITL，这三个指标是 SRE 看 SLO 是否健康的核心面板。

五、KV cache 跨节点传输：RDMA、NCCL 与序列化

PD 分离的"传输层"是整个架构最容易低估的部分——很多人以为"反正有 RDMA，KV 传输不会成为瓶颈"，但实测告诉我们：KV 序列化与反序列化的开销可以超过传输本身。

KV cache 的数据布局选择有三种：

1. 连续布局（contiguous）：每个请求的 KV 按层、头、序列顺序连续存储，反序列化快但跨节点传输时如果 partial transfer 必须重新对齐
2. 分块布局（blocked/paged）：KV 按 16 token 的 block 切分，每块独立可寻址，与 PagedAttention 自然契合，但跨节点传输时块索引需要额外同步
3. 压缩布局（compressed）：FP8/INT8 量化后的 KV cache，传输量减半但需要额外的量化/反量化开销

2026 年业界主流选择是分块布局 + FP8 压缩——分块与 PagedAttention 的内存管理兼容，FP8 把 KV 容量与传输带宽同时减半，配合 NVLink/IB Switch 的 400Gbps 链路，单次 KV 传输的端到端延迟可以压到 50-100ms。

传输协议的选择：

• NCCL：PyTorch 生态首选，但 NCCL 的 all-gather/reduce-scatter 抽象对 KV 单向传输不直接友好，需要写 custom NCCL kernel
• RDMA verbs：直接用 ibverbs API，跳过 NCCL 抽象层，吞吐高但需要自己实现可靠传输、拥塞控制、流控
• UCX/Mooncake 传输层：UCX 是统一通信抽象层，Mooncake 在 UCX 之上做了 KV 传输专用优化（KVTransferEngine），2025-2026 年 Mooncake 的传输层已成为业界事实标准
• HTTP/3 + gRPC streaming：易调试但延迟高（每跳 5-10ms），不适合热路径

传输的状态机必须考虑部分传输失败的处理：

• 请求级重传：整个 KV 重传，简单但浪费带宽
• 块级重传：只重传失败的 block，复杂但高效——Mooncake 采用这种
• 冗余传输：同一条 KV 通过两条独立路径传输，取先到者——网络利用率翻倍但延迟低

2026 年生产系统的推荐选择是Mooncake 风格的 UCX + 块级重传 + 冗余路径并行，在 100Gbps+ 链路上能把 P99 KV 传输延迟稳定在 200ms 以内。

传输层之上的另一个关键设计是KV 缓存的持久化层（KVStore）——prefill 节点生成的 KV 不只是发给当前 decode 节点，还应当缓存到全局 KVStore 中，供后续 prefix cache 命中或异地 decode 复用。KVStore 的实现有内存缓存（Redis/Memcached）、NVMe SSD 缓存、对象存储（S3）三级金字塔——热数据进内存、温数据进 SSD、冷数据进对象存储，三级之间的淘汰策略按 LRU + 访问频率加权。

六、调度算法：prefill 选 + decode 选 + transfer 编排

PD 分离架构的调度器需要同时做三个决策：请求进哪个 prefill 节点、KV 传输到哪个 decode 节点、decode 节点在何时开始 decode。这三个决策不是独立的，而是相互耦合——prefill 节点的选择影响 KV 传输距离，decode 节点的选择影响 ITL，编排顺序影响端到端延迟。

调度算法的设计原则：

• Prefill 节点选择：选当前负载最低且 prefix cache 命中率最高的节点；如果请求 prompt 与某节点的 prefix cache 高度重合，命中率 > 50% 时优先选这个节点（即使它当前负载稍高）
• Decode 节点选择：选当前 ITL 抖动最小且 KV 容量剩余最多的节点；如果某 decode 节点已经在跑相似 batch，新请求加入能复用 KV block，ITL 更稳定
• Transfer 编排：prefill 完成后立即启动 KV 传输，传输与 decode 节点准备并行；传输完成时 decode 节点必须已经 ready，否则 decode 节点空等待浪费带宽

调度器实现的关键技术：

• 两阶段队列（two-stage queue）：请求先进入 prefill 队列，prefill 完成后转入 decode 队列；两阶段之间靠 KV transfer 连接
• Backpressure 机制：当 decode 队列积压时，prefill 调度器降低新请求接受速率（admission control），避免 prefill 池空转产生大量待传输 KV 但 decode 池吃不下
• Speculative prefill：在 KV transfer 完成前的几十毫秒空闲期，decode 节点可以先用一个 draft 模型"猜测性 prefill"——这与投机解码（speculative decoding）结合可进一步降低延迟

调度算法的评估不能只看平均延迟，必须看长尾延迟（P99/P999）的稳定性——PD 分离的一个核心宣称就是"通过解耦消除共置架构的长尾雪崩"，但如果调度器没做好，PD 分离反而会引入"KV 传输超时"的新长尾。

调度器常见坑：

• Head-of-line blocking：prefill 队列里一个超长请求阻塞后面所有请求；用 EDF（Earliest Deadline First）或优先级抢占解决
• Decode 节点冷启动：新 decode 节点刚加入时 KV 缓存是空的，命中率低导致 ITL 抖动；用预热（warmup）+ 渐进式流量切换解决
• 网络抖动放大：单条链路的 100ms 抖动会被所有经过这条链路的请求放大成 P99 雪崩；用 ECMP 多路径 + 冗余传输缓解

七、业界对比：DistServe / Mooncake / vLLM disagg / NVIDIA Triton disagg

2025-2026 年间业界已经出现多个 PD 分离的开源实现，主流方案有四家：

DistServe（2024，SOSP）：最早把 PD 分离思路系统化的论文工作，提出"prefill 节点专攻算力、decode 节点专攻带宽"的算力解耦模型，并通过 goodput（达成 SLO 的请求数 / 总请求数）作为优化目标。DistServe 的核心贡献是把 PD 分离从"直觉"变成"可量化优化的问题"。

Mooncake（2025，Moonshot AI）：生产规模最大的 PD 分离架构，承载 Kimi 的高并发请求。Mooncake 的核心创新是KVTransferEngine——把 KV 传输抽象成一个独立引擎，与推理引擎解耦，使得传输层可以独立优化（用 UCX + RDMA + 块级重传）。Mooncake 还引入了StoreGate作为全局 KVStore，让 prefix cache 跨节点共享。

vLLM disagg（2025-2026，vLLM 团队）：vLLM 在 v0.7+ 引入实验性的 PD 分离支持，使用 ZeroMQ 作为传输层。优势是与 vLLM 现有 PagedAttention、Chunked Prefill、Speculative Decoding 模块天然集成；劣势是 ZeroMQ 传输延迟偏高，不适合 400Gbps 高速网络场景。

NVIDIA Triton disagg（2026，NVIDIA）：NVIDIA 在 Triton Inference Server 中加入 disagg 模式，使用 NCCL + NVSwitch 作为传输层。优势是与 TensorRT-LLM、NVIDIA NIM 等 NVIDIA 全家桶深度集成；劣势是 vendor lock-in，非 NVIDIA 硬件无法享受最优性能。

四家方案的工程取舍：

• 如果自研 + 极致性能：选 Mooncake 路线，复用其 KVTransferEngine + StoreGate
• 如果快速落地 + vLLM 生态：选 vLLM disagg，等 v1.0 stable
• 如果NVIDIA 全家桶：选 Triton disagg，享受 NVIDIA 软件栈加成
• 如果学术验证：选 DistServe 思路，跑 goodput benchmark

2026 年业界共识是 PD 分离已成为推理服务的默认架构——任何严肃的 LLM 推理服务都应当把 PD 分离列入 capacity planning 的标准选项；纯共置架构只在延迟不敏感（如离线 batch 推理）或规模极小（如个人 GPU）场景保留。

八、实战陷阱：OOM、转移超时、容量规划、监控

PD 分离架构在 production 中的常见陷阱可以归纳为五类：

1. KV cache OOM：prefill 节点生成的 KV 比预估大（如 thinking token 通胀），传输过程中 OOM。解决：KV 容量预留 30% buffer + 启用 FP8/INT8 KV 压缩 + 启用 prefix cache。

2. KV transfer timeout：网络抖动导致 KV 传输超过 deadline，请求失败。解决：deadline 必须包含传输时间（prefill 完成后 + 200ms）+ 块级重传 + 冗余路径。

3. 容量配比错：prefill 池配得过大，prefill 节点空转；decode 池配得过大，decode 节点空等 KV。解决：用 goodput（而非利用率）作为容量规划的优化目标，跑 benchmark 找拐点。

4. 调度死锁：prefill 池满 → 拒绝新请求 → decode 池空 → 无法消费 KV → prefill 池背压累积 → 全系统死锁。解决：背压必须双向（prefill → decode → prefill），并设 hard limit（如队列深度 1000）+ graceful degradation（请求排队而非拒绝）。

5. 监控盲区：只看 GPU 利用率不看 KV 传输状态，导致问题定位慢。解决：监控必须包含 KV 传输延迟直方图、KVStore 命中率、prefill 池队列深度、decode 池 ITL P99 四件套。

实战中最容易踩的隐藏陷阱是冷启动顺序——PD 分离架构启动时必须先启动 KVStore 与传输层，再启动 prefill 池，最后启动 decode 池；顺序错了会导致 decode 节点连不上 KVStore，所有请求都失败。这个顺序应当写进 deployment runbook，不能依赖人工记忆。

另一个隐藏陷阱是跨可用区（AZ）的 KV 传输——同 AZ 内 RDMA 延迟 0.1ms，跨 AZ 延迟 1-10ms，跨 region 延迟 50-200ms。PD 分离架构应当默认同 AZ 部署；如果需要跨 AZ，必须用冗余路径 + 块级重传 + 长 deadline 配合，不能直接复用同 AZ 的 SLO。

九、给 SRE 的可观测性清单与成本模型

最后给出 PD 分离架构落地时 SRE 应当掌握的可观测性清单与成本模型。

可观测性 5 大面板：

1. Prefill 池面板：当前 in-flight 请求数、KV 生成速率（bytes/sec）、prefix cache 命中率、P50/P99 prefill 耗时
2. Decode 池面板：当前 batch 大小、tokens/sec 生成速率、活跃 KV 容量、ITL P50/P99/P999
3. KV 传输面板：传输延迟直方图（P50/P99/P999）、传输失败率、KVStore 命中率、跨节点带宽利用率
4. 端到端面板：TTFT P50/P99、端到端 goodput、SLO 达成率（按 tier 分）、P99 长尾请求 trace
5. 成本面板：prefill 节点 GPU 小时成本、decode 节点 GPU 小时成本、KV 传输占用带宽成本、KVStore 存储成本

成本模型核心公式：

• PD 分离总成本 = PrefillCost × T_prefill_total + DecodeCost × T_decode_total + TransferCost × bytes_KV_total + KVStoreCost × GB_stored
• 共置架构成本 = Co-locatedCost × T_total × utilization_penalty
• 当 prompt 平均长度 > 4k token 且 thinking token 通胀 > 5x 时，PD 分离的成本优势开始显现

SRE 必会的应急操作：

• 手动 drain prefill 节点：从负载均衡摘除该节点，让 in-flight 请求自然完成，新请求走其他节点
• 手动 drain decode 节点：先停止接受新 KV 传输，让该节点 in-flight 请求完成
• KVStore 失效切换：当 KVStore 主节点故障时，强制所有 prefix cache 失效（命中率归零），但请求不中断
• 网络抖动应对：启用冗余路径后，把单路径抖动对 P99 的影响控制在 50ms 以内

PD 分离架构不是银弹——它把共置架构的"算力错配"问题转化为"容量规划 + 网络 + 状态机"的复合问题，但只要按本文给出的 9 节框架系统落地，2026 年的 LLM 推理服务完全可以稳定达到 P99 < 1s、goodput > 95% 的生产 SLO。

十、SRE 故障排查决策矩阵

PD 分离架构在 production 中遇到告警时，SRE 必须在 5 分钟内定位是 prefill 池、decode 池、KV 传输、KVStore 还是网络中的哪一环出问题。下面给出一个经过实战验证的故障排查决策矩阵，把症状映射到根因定位动作。

症状 1：TTFT P99 突然飙到 5s 以上、但 ITL 正常

根因指向 prefill 池。第一步：检查 prefill 池队列深度（队列积压 ⇒ prefill 节点过少或单请求 prefill 太长）；第二步：检查 prefix cache 命中率（命中率断崖下跌 ⇒ KVStore 故障或缓存被大面积 invalidate）；第三步：检查 prefill 节点 OOM（OOM kill ⇒ KV 容量估错或 thinking token 通胀超出预期）。临时缓解：扩大 prefill 池 + 启用 chunked prefill + 降低 prefill 节点 max concurrent requests。

症状 2：ITL P99 飙升、TTFT 正常

根因指向 decode 池。第一步：检查 decode 池 KV 容量（容量耗尽 ⇒ 长输出请求未及时 evict）；第二步：检查活跃 batch 大小（batch 满 ⇒ decode 节点过少）；第三步：检查 ITL 抖动幅度（短输出 + 长输出混跑 ⇒ 未启用 sorted batching）。临时缓解：扩大 decode 池 + 启用 KV eviction + 启用 sorted batching + 降低 decode 节点 max batch size。

症状 3：请求错误率突然飙升、错误码 504/timeout

根因指向 KV 传输或 KVStore。第一步：检查 KV 传输延迟直方图（P99 > 500ms ⇒ 网络抖动或传输节点 OOM）；第二步：检查 KVStore 健康状态（KVStore 故障 ⇒ prefix cache 失效但请求不应该报错，如果报错则传输层把 KVStore 故障当成了 KV 缺失）；第三步：检查跨节点带宽利用率（带宽跑满 ⇒ 链路瓶颈或某节点正在做批传输）。临时缓解：启用冗余路径 + 降低 prefill 节点 max KV 输出速率 + 关闭 prefix cache 让传输层退化到 direct transfer。

症状 4：goodput 持续下跌，但所有单点指标正常

根因指向容量配比失衡。第一步：跑 goodput benchmark（benchmark 应当显示 goodput 拐点对应的 prefill/decode 节点数比例）；第二步：检查 prefill 池利用率（持续 < 30% ⇒ prefill 池过大）；第三步：检查 decode 池利用率（持续 < 30% ⇒ decode 池过大）；第四步：检查网络链路利用率（持续 < 20% ⇒ KV 传输未规模化）。根治：按 benchmark 拐点调整 prefill/decode 节点数比例，典型值是 1:4 到 1:8（prefill:decode GPU 数比例）。

症状 5：部分节点流量倾斜、其他节点空转

根因指向调度器负载均衡策略。第一步：检查调度器是否启用了 prefix-aware 路由（如果没启用，prefix cache 命中率高的节点会吸引所有重复请求，其他节点空转）；第二步：检查调度器是否启用了 AZ-aware 路由（跨 AZ 流量倾斜会导致同 AZ 内节点负载不均）；第三步：检查健康检查是否误判（健康检查失败节点被摘除会导致流量全压到剩余节点）。根治：启用 prefix-aware + AZ-aware 路由 + 调整健康检查超时阈值。

这个故障排查矩阵的关键洞察是先 TTFT/ITL 二分定位到 prefill/decode，再根据错误码定位到传输/存储/网络——把"全栈排查"压缩到 3-5 跳决策，避免 SRE 在告警时陷入"每个节点都查一遍"的慌乱。

十一、与推理硬件演进的协同路径

PD 分离架构的演进不是孤立的，它必须与硬件、模型、调度算法的演进协同。2026 年最值得关注的三个协同方向是：

方向 1：与 Blackwell B100/B200 的协同。B200 的 HBM3e 带宽达到 8 TB/s（H100 的 2.4 倍），NVLink 5 带宽达到 1.8 TB/s（H100 的 3 倍）。这两个硬件升级让 decode 池与 KV 传输的瓶颈被部分缓解——但 prefill 池的算力瓶颈更突出，因此 PD 分离的价值在 B200 时代不减反增：prefill 节点继续用 B200（Tensor Core 翻倍），decode 节点可以用更便宜的 L40S 或 H200 平衡带宽与成本。

方向 2：与 Reasoning LLM 的协同。Reasoning LLM（Claude Sonnet 4 / DeepSeek-R1 / Qwen3-Thinking / Kimi K2-thinking）让平均输出长度从 200 token 涨到 2000+ token，thinking token 通胀 10x。这意味着 decode 池的 KV 容量压力剧增（长输出占用更多 KV 容量）但算力压力增幅较小——PD 分离架构在 Reasoning LLM 时代价值被放大，因为 prefill 池的压力增长慢、decode 池的压力增长快，单纯扩大 decode 池的策略不再够用，需要 PD 分离 + decode 池 prefix cache + speculative decoding 三件套协同。

方向 3：与端云协同推理的协同。2026 年端侧推理（WebGPU / Apple Silicon / Qualcomm AI Engine）开始承接部分轻推理请求（短 prompt + 短输出），云端承接长上下文 + 长输出请求。这催生了一种新的"端云 PD 分离"架构——端侧做 decode（轻算力、低延迟），云端做 prefill（重算力、高吞吐），中间靠 WebSocket + 量化 KV 传输。这种架构对 KV 传输的延迟容忍度更低（端侧用户期望 100ms 内首个 token），对 KV 压缩比的要求更高（端到端传输带宽受限于 WebSocket），是 PD 分离思想向端云协同的延伸。

这三个方向的共同结论是：PD 分离不是 2024-2025 年的临时方案，而是 2026-2030 年推理架构的默认形态——任何严肃的 LLM 推理服务都应当把 PD 分离作为 capacity planning 的标准起点，而不是把它当作"未来可能用得上的高级特性"。

参考文献

1. Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, OSDI 2024.
2. Moonshot AI, Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM, KDD 2025 Workshop.
3. vLLM Team, Disaggregated Inference in vLLM: Design and Implementation, vLLM Documentation v0.7+ 2025-2026.
4. NVIDIA, Triton Disaggregated Serving: Architecture Guide, NVIDIA Developer Blog 2026.
5. Kwon et al., PagedAttention: Virtual Memory Management for Large Language Model Serving, SOSP 2023.
6. Anthropic, Speculative Decoding in Production: Lessons from Claude Serving, Engineering Blog 2024-2025.
7. Liu et al., Chunked Prefill: Optimizing Long Context Inference, vLLM Tech Report 2024.
8. OpenTelemetry, GenAI Semantic Conventions: Span Attributes for LLM Inference, CNCF Specification 2025.
9. Patel et al., Continuous Batching for LLM Inference: A Survey, MLSys 2024.
10. Chen et al., Prefix Cache Engineering at Scale: From LRU to Semantic-Aware Eviction, USENIX NSDI 2026.
11. Wang et al., Speculative Decoding's Engineering Truth 2026: From Draft Model to Production KV Reuse, Lonae Blog id=460 2026.
12. Zhang et al., LLM Inference's NVLink Topology-Aware Scheduling Engineering 2026, Lonae Blog id=465 2026.
13. Liu et al., LLM Inference's Shadow Mode and Canary Pre-warming Engineering 2026, Lonae Blog id=475 2026.
14. Kimi Team, Mooncake Architecture Deep Dive: KVTransferEngine and StoreGate Design, Moonshot Engineering Blog 2025.