LLM 推理服务的 PD 分离架构 2026:从 KV 跨节点传输到容量规划的生产真相
把 prefill 与 decode 算力解耦、靠 RDMA/NCCL 跨节点传输 KV cache,把共置架构的算力错配转化为容量规划 + 网络 + 状态机的工程问题,是 2026 年 LLM 推理服务的默认形态。
约 43 分钟阅读12,832 字13 次阅读博主
把 prefill 与 decode 算力解耦、靠 RDMA/NCCL 跨节点传输 KV cache,把共置架构的算力错配转化为容量规划 + 网络 + 状态机的工程问题,是 2026 年 LLM 推理服务的默认形态。
一句话摘要：当 prompt 长度从 200 token 涨到 32k token，prefill 与 decode 在同一张 GPU 上互相阻塞、共置架构的算力错配成为推理服务的头号瓶颈；2025 年起业界全面转向 PD 分离（Prefill-Decode Disaggregation），把 prefill 池与 decode 池部署在不同节点，通过 RDMA/NCCL 跨节点传输 KV cache，这是一次"打破 GPU 共置假设"的根本架构演进，也是 2026 年推理服务的默认形态。
大模型推理服务化走到 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 分离生产架构真相。
定义一个推理请求 r 的延迟 D(r) 为从请求进入队列到第一个 token 输出（TTFT, Time-To-First-Token）与后续每个 token 间隔（ITL, Inter-Token Latency）的函数：
在共置架构下，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 分离的数学基础是算力解耦后的乘法延迟模型：
但分离引入了新变量：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 分离的容量规划需要同时满足四个约束：
四个约束同时满足意味着 PD 分离不是简单的"拆成两个池"——它是一次完整的容量规划 + 调度算法 + 状态机 + 可观测性的体系重构。
Prefill 池的设计目标是最大化算力吞吐而非延迟均匀——它吃 prompt、做预填充，输出 KV cache 序列与初始 logits。Prefill 节点的硬件画像应当优先选算力峰值高、HBM 容量适中的卡，H100/H200/B100 是首选，A100 退而求其次，L40S 这类"带宽优先"卡几乎不适合做 prefill。
Prefill 池的关键工程参数：
Prefill 池的常见工程坑：
Prefill 池的可观测性核心指标是每秒生成的 KV 字节数（KV bytes/sec generated），这个指标直接对应下游 decode 池的可用 KV 带宽上限——它必须实时暴露给调度器，否则调度器无法做容量规划。
Decode 池的设计目标是最大化单请求 ITL 的稳定性——它吃 KV cache，逐 token 自回归生成，输出 token 流。Decode 节点的硬件画像应当优先选HBM 带宽高、显存容量大的卡，A100/L40S/H100 都合适，但 H100 因为 HBM3 带宽 3.35 TB/s 而 decode 性能远超 A100 的 2 TB/s。
Decode 池的关键工程参数：
Decode 池的常见工程坑：
Decode 池的可观测性核心指标是每秒生成的 token 数（tokens/sec generated）+ 当前活跃 batch 大小 + P50/P99 ITL，这三个指标是 SRE 看 SLO 是否健康的核心面板。
PD 分离的"传输层"是整个架构最容易低估的部分——很多人以为"反正有 RDMA，KV 传输不会成为瓶颈"，但实测告诉我们：KV 序列化与反序列化的开销可以超过传输本身。
KV cache 的数据布局选择有三种：
2026 年业界主流选择是分块布局 + FP8 压缩——分块与 PagedAttention 的内存管理兼容，FP8 把 KV 容量与传输带宽同时减半，配合 NVLink/IB Switch 的 400Gbps 链路，单次 KV 传输的端到端延迟可以压到 50-100ms。
传输协议的选择：
传输的状态机必须考虑部分传输失败的处理：
2026 年生产系统的推荐选择是Mooncake 风格的 UCX + 块级重传 + 冗余路径并行，在 100Gbps+ 链路上能把 P99 KV 传输延迟稳定在 200ms 以内。
传输层之上的另一个关键设计是KV 缓存的持久化层（KVStore）——prefill 节点生成的 KV 不只是发给当前 decode 节点，还应当缓存到全局 KVStore 中，供后续 prefix cache 命中或异地 decode 复用。KVStore 的实现有内存缓存（Redis/Memcached）、NVMe SSD 缓存、对象存储（S3）三级金字塔——热数据进内存、温数据进 SSD、冷数据进对象存储，三级之间的淘汰策略按 LRU + 访问频率加权。
PD 分离架构的调度器需要同时做三个决策：请求进哪个 prefill 节点、KV 传输到哪个 decode 节点、decode 节点在何时开始 decode。这三个决策不是独立的，而是相互耦合——prefill 节点的选择影响 KV 传输距离，decode 节点的选择影响 ITL，编排顺序影响端到端延迟。
调度算法的设计原则：
调度器实现的关键技术：
调度算法的评估不能只看平均延迟，必须看长尾延迟（P99/P999）的稳定性——PD 分离的一个核心宣称就是"通过解耦消除共置架构的长尾雪崩"，但如果调度器没做好，PD 分离反而会引入"KV 传输超时"的新长尾。
调度器常见坑：
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 硬件无法享受最优性能。
四家方案的工程取舍：
2026 年业界共识是 PD 分离已成为推理服务的默认架构——任何严肃的 LLM 推理服务都应当把 PD 分离列入 capacity planning 的标准选项；纯共置架构只在延迟不敏感（如离线 batch 推理）或规模极小（如个人 GPU）场景保留。
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。
最后给出 PD 分离架构落地时 SRE 应当掌握的可观测性清单与成本模型。
可观测性 5 大面板：
成本模型核心公式：
SRE 必会的应急操作：
PD 分离架构不是银弹——它把共置架构的"算力错配"问题转化为"容量规划 + 网络 + 状态机"的复合问题，但只要按本文给出的 9 节框架系统落地，2026 年的 LLM 推理服务完全可以稳定达到 P99 < 1s、goodput > 95% 的生产 SLO。
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 的标准起点，而不是把它当作"未来可能用得上的高级特性"。
Conversation
0 条