LLM推理PD分离架构深度工程实践：从Prefill-Decode异构到分布式KV Cache传输

当单GPU同时承载计算密集的Prefill和访存密集的Decode阶段时，延迟灾难就已注定。PD分离架构通过将两阶段解耦到异构GPU集群，实现了LLM推理服务吞吐与延迟的数量级提升。

一、为什么必须分离Prefill和Decode

现代大语言模型的推理过程呈现两个截然不同的计算阶段：

Prefill阶段（预填充）：一次性处理全部输入Token，计算模式是矩阵-矩阵乘法（GEMM），典型的计算密集型操作。一个2048 Token的输入在13B模型上的Prefill，需要执行一次大规模矩阵乘法，计算复杂度O(n²·d)（n为序列长度，d为隐藏维度）。该阶段充分利用GPU的Tensor Core，计算利用率可超过80%。

Decode阶段（自回归解码）：逐Token生成输出，每次推理只处理一个Token。计算模式退化为矩阵-向量乘法（GEMV），访存成为瓶颈。Decode阶段的计算利用率通常不足5%——GPU的绝大部分算力处于空闲等待KV Cache数据从显存加载的状态。

当这两个阶段在同一GPU上串行执行时，问题就暴露了：Prefill的长输入会阻塞已经在排队等待的Decode请求，导致高负载下的尾延迟飙升（Request-level Head-of-Line Blocking）。更糟的是，共享GPU内存意味着长序列的KV Cache挤占了解码请求的可用显存，直接压低了系统整体的batch size，从而限制了吞吐。

这就是PD分离架构的核心动机：让擅长计算的GPU做Prefill，让带宽充裕的GPU做Decode，各取所长。

二、PD分离全景：从DistServe到NVIDIA Dynamo

PD分离的研究路线几乎与PagedAttention同期展开。2024年OSDI的DistServe（SingGroup/清华）首次系统性论证了分离式部署的优势：在相同GPU数量下，PD分离相比传统共置部署（Collocated）可实现2.3x吞吐或10.1x延迟改善。

随后涌现的工程实现各有侧重：

这些系统虽然工程细节不同，但架构模型一致：将推理引擎拆分为Prefill Engine和Decode Engine两个独立服务，通过KV Cache传输通道连接，在Prefill完成后将新生成的KV向量（Key-Value Cache）从Prefill节点传送到Decode节点。

三、KV Cache传输协议：PD分离的核心工程挑战

PD分离的最大工程挑战不在于分离本身，而在于如何在Prefill完成后低延迟地将KV Cache传输到Decode节点。对于7B模型、2048 Token的输入，每个Transformer层的KV Cache大小约为：

KV per token = 2 × num_kv_heads × head_dim × 2(bf16) bytes
              = 2 × 8 × 128 × 2 = 4096 bytes

KV per layer for 2048 tokens = 4096 × 2048 = 8 MB

Total KV (32 layers) = 8 MB × 32 = 256 MB

对于70B模型（80层，GQA 8 KV heads × 128 dim），一个32K上下文的KV Cache可超过8GB——这就是为什么Decode阶段严重受限于显存带宽而非计算能力。

3.1 传输策略：全量传输 vs 分层传输

全量传输即每次Prefill后将整个KV Cache复制到Decode节点，简单直接但存在两个致命问题：

1. 网络占用高：每个请求传输数百MB到数GB的数据，容易在网络层形成头阻塞
2. 内存带宽浪费：256MB的KV Cache在Decode节点上的写入就需数毫秒，期间Decode计算pipeline处于stall状态

分层流水线传输是更优方案：Prefill Engine每完成一层的计算，就将该层的KV数据通过NVLink或RDMA推送到Decode Engine的显存。Decode Engine在接收到第一批KV数据后即可开始Attention的流水线计算，边传输边处理。NVIDIA的Dynamo框架就采用这种架构——配合GPU Direct RDMA，Prefill节点的NIC直接写入Decode节点的GPU显存（GDR技术），绕过CPU中转。

时间轴:
Prefill: [Layer 0] ──KV0──▶ [Layer 1] ──KV1──▶ [Layer 2] ...
Decode:               ──KV0▶ [Attn0] ──KV1▶ [Attn1] ...
                         ↑ 流水线重叠

3.2 Mooncake的KV Cache分层缓存池

月之暗面开源的Mooncake系统采用了一种更激进的策略：将KV Cache存储从解耦的本地显存扩展为分层缓存池。

架构分为四层存储： - GPU HBM（L1）：当前正在处理的KV Cache - CPU DRAM（L2）：近期未使用但可能被复用的KV Cache - NVMe SSD（L3）：冷KV Cache、长上下文历史 - 远端分布式缓存（L4）：跨节点的KV Cache共享池

Mooncake的缓存命中率在长对话场景中表现出色——因为对话历史的KV Cache不需要重新Prefill，直接从近端缓存甚至远端迁移即可。实测数据显示：在Claude类长对话场景下，Mooncake借助KV Cache复用可减少62%的Prefill计算量，端到端延迟降低40%以上。

四、深入NVLink RDMA：PD分离的底层传输工程

PD分离架构的极限性能取决于KV传输的带宽和延迟。现代GPU互连技术提供了多条传输路径：

对于7B模型的256MB KV Cache： - NVLink Gen4（900 GB/s）传输仅需 0.28 ms - GPU Direct RDMA 400Gbps需要 5.1 ms - 传统TCP/IP网络需要 >50 ms

选择NVLink或RDMA传输KV Cache，在用户体验上往往意味着 Prefill 延迟从100ms+降至接近零——这就是为什么NVIDIA Dynamo + NIXL组合被业界视为现阶段生产部署的最优解。

五、NVIDIA Dynamo中的PD分离编排

Dynamo（NVIDIA Dynamo 0.1+）将PD分离抽象为分离计算图（Disaggregrated Pipeline）的概念：

from dynamo import Pipeline, Role, TensorStore

# 定义分离计算图解耦PD Dynamo 0.1+）  Prefill: KV Generator（计算节点）
prefill = Role(
    name="prefill",
    engine="tensorrt_llm",
    instances=2,              # 2个Prefill Worker
    gpus=[0, 1],              # A100 80GB × 2
    batch_size=4,
    max_input_len=8192        # 长上下文Prefill能力强
)

decode = Role(
    name="decode",
    engine="tensorrt_llm",
    instances=4,              # 4个Decode Worker  
    gpus=[2, 3, 4, 5],        # 带宽充裕的L40S
    max_batch_tokens=256      # 高吞吐Decode
)

# KV Cache传输层：自动选择NVLink或RDMA
kv_transfer = TensorStore(
    backend="nixl",           # NVIDIA NIXL KV传输库
    transport="auto",         # 自动选择最优路径
    buffer_pool_size="16GiB"  # 预分配KV缓冲池
)

# 串联成Pipeline
pipeline = Pipeline(
    prefill=prefill,
    decode=decode,
    kv_transfer=kv_transfer,
    routing="prefix_cache",   # 基于前缀哈希的智能路由
    load_balancer="shortest_queue"
)

在这个架构中，路由器会根据Prefix Hash将共享相同系统提示词（System Prompt）或对话历史前缀的请求路由到同一个Prefill节点。如果命中前缀缓存（Prefix Caching），Prefill可以跳过已为先前请求计算过的KV Cache，只计算新Token对应的KV Cache部分——将重复Prefill计算降为零。

六、工程实践：延迟与吞吐的权衡

6.1 Prefill Scheduling：最短队列 vs 最长上下文优先

分离部署最大的调度挑战是Prefill节点的负载不均衡。如果多个长请求同时涌向同一个Prefill请求，它会成为整个集群的瓶颈。Dynamo采用的Shortest Queue策略会将新请求路由到当前Predicted Load最低的Prefill节点。

另一种更聪明的策略是Work-Conserving with Chunked Prefill：将Prefill拆分为固定大小的chunk（如512 Token），与其他已Chunk的Prefill请求交错执行。这种策略虽然增加了少量KV Cache传输开销，但避免了长Prefill请求阻塞整个Decode pipeline。

6.2 KV缓存的精度压缩

KV Cache不仅体积大，而且全精度（FP16/BF16）存储造成显存和带宽浪费。工程上常见的压缩方案：

• FP8 KV Cache：将KV Cache从BF16压缩到FP8（4-bit E4M3），显存占用减半，PD分离传输带宽需求也减半。对模型质量的影响取决于模型——Llama 3 8B在FP8 KV Cache下几乎没有质量损失，70B模型需要谨慎验证。
• GQA（Grouped-Query Attention）：通过共享KV Head来减少KV Cache体积（已在Llama系模型广泛采用，8 KV Heads vs 32 Q Heads）
• Token Dropping：对重要性较低的历史Token丢弃KV Cache（结合Attention Score评分），将有效密度降低30%-50%

6.3 PD分离的适用边界

PD分离并非万能药，它在以下场景中效果递减：

• 短输入短输出（<256 Token）：PD分离的KV传输开销开始接近Prefill共置部署
• 单机推理：NVLink高带宽优势存在，但编排复杂度收益有限
• 小模型（<1B参数）：Prefill本身极快，分离增加延迟而非降低

最适合PD分离的场景：长上下文（>8K Token）+ 中等模型（7B-70B）+ 高QPS生产负载。典型应用包括代码补全、长文档分析、对话系统等具有较长输入前缀的场景。

七、未来展望：从PD分离到通用计算-存储分离

PD分离架构暗示了一个更宏大的趋势：AI推理的存算分离（Disaggregrated Compute-Storage）。

随着CXL 3.x Fabric、NVLink-C2C互连的成熟，未来的推理架构可能进一步将KV Cache抽象为独立的存储层（KV Store），计算节点（无论Prefill还是Decode）都可以按需从KV Store中检索任意Token的KV数据。这个方向与KV Cache on Flash（如HCache、InfiniStore）的研究相结合，有望打破HBM容量瓶颈。

另一个值得关注的方向是异步PD分离：当前PD分离是严格同步的——Prefill完全KV Cache生成后才能传输到Decode节点。未来的分离架构可能允许Generate-Decode模式：Decode Engine在Prefill Engine还没有完成全部KV Cache之前就开始Attention推理，通过Streaming KV的方式实现真正的流水线重叠。

NVIDIA Blackwell架构正是为此而生——其第五代NVLink Switch提供高达1.8 TB/s的总带宽（是上代的5倍），配合Disaggregated Inference特性，单Switch域内可支持72个GPU的全互联。这意味着未来的PD分离集群可以将数十个Prefill GPU和数十个Decode GPU组合成统一的逻辑推理引擎，总GPU利用率有望从目前分离部署的60%-70%提升至85%以上。

结语

PD分离架构不是简单的架构拆分，而是对LLM推理计算瓶颈的精确识别与针对性优化。它用网络通信换来了计算密度的居中获得——将计算密度高的Prefill和访存密度高的Decode分别部署在最适合的硬件上，相当于将所有GPU的综合利用率提升到接近理论最大值。在AI推理从"能用"走向"好用"再走向"廉价滥用的今天，PD分离正成为大规模LLM推理服务的标准部署范式。而理解这一架构原理，对于每一个AI Infra工程师而言，已经不是选修课，而是必修课。