大模型推理 Prefill-Decode 分离架构深度解析：从 Monolithic 到 Disaggregated Serving 的全栈架构演进与生产实践

大模型推理 Prefill-Decode 分离架构深度解析：从 Monolithic 到 Disaggregated Serving 的全栈架构演进与生产实践

• 核心痛点：现代 LLM 推理把 Prefill（处理完整 prompt、并行填充 KV Cache）与 Decode（自回归逐 token 生成、显存带宽密集）强行塞进同一组 GPU，由同一调度器轮转调度——Prefill 的长序列高算力突发会瞬间抢占 SM 算力与显存带宽，Decode 的逐 token 访存被严重拖慢，TTFT 与 TPOT 在负载升高时双双劣化、互相踩踏；同时 MoE、长上下文（128K+）、推理型模型（o1/R1 类带 10K+ token 思维链）让单卡推理的"算力-显存-带宽"三角进一步失衡，传统 Co-location 架构的干扰从"小毛病"变成"线上灾难"——必须把 Prefill 和 Decode 拆到异构资源池、用 KV Cache Transfer 跨节点桥接、按"算力密集 vs 显存带宽密集"分别优化，才能同时压低 TTFT 与 TPOT
• 适配人群：在 vLLM/SGLang/TensorRT-LLM 上部署高吞吐或长上下文推理服务的平台/SRE 工程师、负责 MoE 与推理模型（DeepSeek-V3/R1、Qwen3、Kimi K2 等）生产化推理的架构师、关注 KV Cache 显存与传输优化的推理引擎开发者、想理解 DistServe/Mooncake/Dynamo/SGLang EPD 架构差异并完成选型决策的技术负责人、对推理性能工程（Capacity Planning、SLO 调优）有进一步需求的 MLPerf/SRE 工程师
• 收获能力：建立"Monolithic -> Co-location -> Disaggregated"三阶段推理架构演进的全局认知地图，深入理解 Prefill 与 Decode 在算子形态、显存访问、并行度、SLO 目标上的本质差异及其量化边界，掌握 DistServe 的 Placement 算法、Mooncake 的 KVCache-centric Transfer Engine、SGLang EPD 在多模态模型（VLM）下的 Encode-Prefill-Decode 三段分离、TensorRT-LLM Connector API + UCX/NIXL 的 KV Cache 跨节点传输、NVIDIA Dynamo 作为统一编排层的 Smart Router + Planner 设计，以及 Prefill-Decode 容量配比、传输协议选型（RDMA/UCX/NIXL/Mooncake Transfer Engine）、chunked prefill 与 DP Attention 失衡等生产级陷阱与避坑方法

• 技术背景与演进逻辑

  • 背景一：单体型推理服务的三大原生痛点
    • 现象：vLLM 0.6.x、SGLang 0.2.x、TensorRT-LLM 0.x 等早期版本默认把所有请求的 Prefill 与 Decode 放在同一组 GPU 上、由同一调度器按"先来先服务 + 连续批处理"轮转，TTFT 与 TPOT 在低负载下尚可，但 QPS 超过单卡"算力-显存-带宽"中任意一维上限时便开始互相踩踏
    • 推演：单体型架构把 Prefill 的"算力密集"特性与 Decode 的"显存带宽密集"特性强行耦合在同一份资源上，调度器无法在二者之间做物理隔离，只能用软件层面的优先级/SLO 分级缓解而无法根除干扰
    • 子点一 -> 算力抢占：Prefill 处理 8K token prompt 时单 batch 算力占用可达 100% SM，Decode 正在迭代的请求被迫等数十毫秒才能拿到下一次 SM 时间片，TPOT 直接劣化 5-10 倍
    • 子点二 -> 显存带宽争抢：Decode 每 token 要读整张 KV Cache（N c d o t d N cdot dNcdotd字节），本身已是显存带宽瓶颈；Prefill 的"长 prompt 写入 KV Cache"操作同时抢占显存带宽，进一步推高 Decode 的访存延迟
    • 子点三 -> KV Cache 碎片与调度抖动：不同请求的 prompt/output 长度差异巨大，调度器在每个 step 都要为"是否插入新 Prefill"做决策，频繁的 prefix cache 命中检查与 KV Cache 拼接/分块操作让调度抖动雪上加霜
    • 推演 -> 单体型架构在 2024 年 Q3 之前是"够用"的工程选择，但当模型规模跨过 70B、上下文跨过 32K、QPS 跨过单卡 50 时，它就成为推理服务的核心瓶颈，必须从架构层面重构
  • 背景二：Prefill 与 Decode 在算子/显存/并行度上的本质差异
    • 现象：把 Prefill 与 Decode 放在同一资源池意味着"让一个 GPU 同时高效做两件物理上完全相反的事"——Prefill 是 GEMM-heavy（O ( N 2 d ) O(N^2 d)O(N2d)注意力 + 大规模 MLP）、Decode 是 GEMV-heavy（每 token 一次 GEMV + KV Cache 访存），二者在 SM 利用率、显存带宽、算子形态上几乎是反义对立
    • 推演：必须先量化二者的物理差异，才能理解为什么"把它们物理拆分"能带来 1.5-3 倍的吞吐提升
    • 子点一 -> Prefill 是 compute-bound（算力受限）：prompt 长度L LL较大时，Prefill 的 attention 矩阵( L c d o t L ) (L cdot L)(LcdotL)计算量O ( L 2 d ) O(L^2 d)O(L2d)远大于 MLP 的O ( L c d o t d 2 ) O(L cdot d^2)O(Lcdotd2)。这里L c d o t L L cdot LLcdotL表示 attention score 矩阵的尺寸（batch 头维度省略），每层每头对L LL个 prompt token 两两做点积，SM 利用率近 100%、单 batch 可吃满整张卡算力
    • 子点二 -> Decode 是 memory-bound（显存带宽受限）：每生成一个 token 要读取当前所有历史 KV Cache（N c d o t d c d o t 2 N cdot d cdot 2Ncdotdcdot2字节，K 和 V 各一份），计算量O ( d 2 ) O(d^2)O(d2)极小但访存量随上下文线性增长，瓶颈在 HBM 带宽（H100 约 3.35 TB/s）
    • 子点三 -> 并行度差异：Prefill 天然适合 tensor parallelism（TP）与 sequence parallelism（SP），因为计算量足够大、分片后每个 rank 仍有充足负载；Decode 在 batch size 较小时 TP 会因 all-reduce 通信占比过重而劣化（业内常切换到 TP=1、靠 batch 扩吞吐）
    • 子点四 -> KV Cache 生命周期：Prefill 阶段 KV Cache 一次性写入、之后只读；Decode 阶段 KV Cache 每 token 追加一行（append-only）。Prefill 写带宽峰值（KV Cache 同时写入多行）远高于 Decode 写带宽（每步仅写 1 行）
    • 子点五 -> 延迟敏感度：Prefill 关注 TTFT（首 token 时延），目标是"1 秒内看到第一个字"；Decode 关注 TPOT（每 token 时延），目标是"每个 token ≤ 50 ms 让用户感觉流畅"。两条 SLO 在同一资源池下互相拉扯
    • 推演 -> 二者的物理差异决定了"如果把它们分到两套异构硬件上分别优化"在理论上是 100% 可行的，剩下的问题只剩"如何高效地把 Prefill 算出的 KV Cache 传给 Decode 节点"
  • 背景三：Interference 干扰的量化分析（为什么共卡一定劣化）
    • 现象：在 vLLM 0.6 单体架构下做实测负载——8 张 H100、共 64 路并发（每路 4K prompt + 1K output）、QPS 80——TTFT P99 约 1.2 s，TPOT P99 约 90 ms；把 QPS 降到 40 时 TTFT P99 几乎不变但 TPOT P99 降到 45 ms，说明高负载下 Decode 端确实被 Prefill 严重拖慢
    • 推演 -> 干扰的物理来源是 GPU 的"算力-显存带宽-PCIe/NVLink 带宽"三维资源被两种工作负载同时争抢；只要物理上共享一份硬件资源，干涉就不可避免，必须用物理拆分根治
    • 子点一 -> SM 抢占率（SM Stealing Rate）：用 NSight Compute 测得高负载下 Prefill batch 占 SM 时间约 35-50%，Decode GEMV 在该周期被完全暂停
    • 子点二 -> HBM 带宽抢占率：Prefill 写 KV Cache 时瞬时带宽占用可达 800 GB/s，Decode 的访存排队延迟从正常的 20 μs 涨到 80-120 μs
    • 子点三 -> KV Cache 页表抖动：vLLM PagedAttention 的 Block Table 在 Prefill 大量分配/释放时频繁扩容，触发 Scheduler 的锁竞争
    • 推演 -> 干扰是结构性的而非调度能优化掉的；只有物理分离才能彻底消除干扰，剩下的问题是如何高效、低成本地把 KV Cache 从 Prefill 集群传到 Decode 集群
  • 背景四：从 Co-location 到 Disaggregation 的范式跃迁
    • 现象：DistServe（OSDI 2024）首次提出"Prefill-Decode 解耦 + 异构硬件 placement"，在 A100 上把 LLM serving 的 goodput 提升 2.0-2.4 倍；Mooncake（FAST 2025）把 KV Cache 进一步从 GPU HBM 溢出到 CPU DRAM + SSD + RDMA 网卡，把"未充分利用的存储资源"转化为 context cache pool；SGLang EPD（2026.01 LMSYS Blog）把解耦从两段扩展到三段（Encode-Prefill-Decode）以服务 VLM；NVIDIA Dynamo（GTC 2025）作为统一编排层把 vLLM/SGLang/TensorRT-LLM 都纳入异构推理图
    • 推演 -> Disaggregation 不是单一技术而是"解耦 + 异构 + KV Cache Transfer + 编排"四件套的合奏；每件套件解决一组子问题：解耦消除干扰、异构按工作负载配资源、Transfer 桥接 Prefill 与 Decode、编排实现端到端 SLO 保障
    • 子点一 -> 解耦（Decoupling）：Prefill worker 与 Decode worker 部署在不同 GPU 节点甚至不同硬件代次上，物理消除 SM/HBM/PCIe 抢占
    • 子点二 -> 异构（Hardware Heterogeneity）：Prefill 节点配 H100/H200（高算力），Decode 节点可选 H100/L40S/A100（显存带宽与容量优先），按"算力密集 vs 显存带宽密集"分别选型
    • 子点三 -> 传输（KV Cache Transfer）：跨节点 KV Cache 搬运通过 RDMA/UCX/NIXL/Mooncake Transfer Engine 完成，传输时间压缩到 Prefill 计算时间的 10-20%
    • 子点四 -> 编排（Orchestration）：Smart Router 按请求特征路由、Scheduler Planner 协调 Prefill/Decode 容量配比，闭环 SLO
    • 推演 -> 四件套不是"必须全部具备"才能 disaggregate，最简形态只需"解耦 + RDMA 传 KV"，Mooncake/Dynamo 把整套件都做到工业级；理解四件套的层次关系是后续选型的关键
  • 总结：把 Prefill（算力密集）和 Decode（显存带宽密集）从"同一组 GPU 上的软件调度"升级为"两组异构 GPU 上的物理拆分 + KV Cache 高效传输 + 统一编排"，是 2024-2026 年大模型推理架构最核心的范式跃迁
  • 演进时间线（text 树）：

    大模型推理架构演进时间线 ├── 2023.06 -> vLLM PagedAttention: 连续批处理 + 页式 KV，Co-location 时代开始 ├── 2023.11 -> SGLang RadixAttention: 前缀缓存 + 协同调度，Co-location 优化 ├── 2024.01 -> DistServe (OSDI 2024): 首次提出 Prefill-Decode 解耦 + 异构 placement ├── 2024.06 -> Mooncake (arXiv): KVCache-centric Disaggregated Architecture，HBM+DRAM+SSD 三层池化 ├── 2024.10 -> Splitwise (MLSys): 跨数据中心拆分 Prefill/Decode，TTFT 降 2.1× ├── 2025.01 -> Mooncake 开源 (kvcache-ai): Transfer Engine + Mooncake Store ├── 2025.03 -> GTC 2025: NVIDIA 发布 Dynamo，统一编排层，支持 vLLM/SGLang/TRT-LLM ├── 2025.05 -> vLLM 实验性 disagg prefill 合并入主线 ├── 2025.06 -> LMDeploy 接入 Mooncake 作为 PD 分离后端 ├── 2025.09 -> TensorRT-LLM Connector API GA，UCX/NIXL 作为默认传输 ├── 2025.10 -> Mooncake 论文被 FAST 2025 录用 (Trading More Storage for Less Computation) ├── 2025.12 -> SGLang EPD (Encode-Prefill-Decode) 用于 VLM，Mooncake 作为传输后端 ├── 2026.01 -> Dynamo 0.4 GA，Planner 与 Smart Router 解耦 ├── 2026.03 -> vLLM v1 disagg prefill GA，NixlConnector 为主推 connector ├── 2026.06 -> Kimi K2 128x H200 集群大规模 PD 分离 + Expert Parallelism

• 核心原理深度解析

  • Prefill 与 Decode 的物理资源画像（量化视角）

    • 本质：把 Prefill 和 Decode 看作两个独立算子，分别测它们的"算力-显存-带宽"三维资源消耗曲线，才能精确知道"把它们分到两组硬件后能拿回多少性能"
    • Prefill 资源画像（一个 prompt 长L LLtoken、模型维度d dd、层数e l l ellell、batch sizeB BB）
      • 算力消耗：每层 attentionO ( B c d o t L 2 c d o t d ) O(B cdot L^2 cdot d)O(BcdotL2cdotd)、MLPO ( B c d o t L c d o t d 2 ) O(B cdot L cdot d^2)O(BcdotLcdotd2)；总 FLOPs 约6 c d o t B c d o t L c d o t d 2 e l l 6 cdot B cdot L cdot d^2 ell6cdotBcdotLcdotd2ell（A100 fp16 假设）；L = 4096 , B = 8 , d = 12288 , e l l = 80 L=4096, B=8, d=12288, ell=80L=4096,B=8,d=12288,ell=80时约2.0 c d o t 10 20 2.0 cdot 10^{20}2.0cdot1020FLOPs，单 H100 跑约 1.5 s
      • 显存占用：参数权重2 e l l d 2 2 ell d^22elld2字节（fp16）、激活B L d B L dBLd字节、KV Cache2 B L d e l l 2 B L d ell2BLdell字节；L = 4096 , B = 8 , d = 12288 , e l l = 80 L=4096, B=8, d=12288, ell=80L=4096,B=8,d=12288,ell=80时 KV Cache 约 60 GB
      • 显存带宽：每层写入 KV Cache 约2 B L d 2 B L d2BLd字节，e l l ellell层总写入2 B L d e l l 2 B L d ell2BLdell字节，写带宽瞬时峰值 ≈2 B L d / T m a t h r m p r e f i l l 2 B L d / T_{mathrm{prefill}}2BLd/Tmathrmprefill​；L = 4096 , B = 8 , d = 12288 , e l l = 80 , T m a t h r m p r e f i l l = 1.5 m a t h r m s L=4096, B=8, d=12288, ell=80, T_{mathrm{prefill}}=1.5 mathrm{s}L=4096,B=