从PD分离到MoE联合优化：大模型推理架构的2026年演进

摘要

大模型推理正取代训练成为算力投入与成本压力的中心。中国信通院2026年3月发布的《大模型推理优化关键技术及应用实践研究报告》披露，我国日均Token调用量两年增长超1400倍，2026年初突破140万亿；受Agentic AI驱动，推理计算量两年增长达1万倍。在这一轮规模化落地的工程运动中，PD分离（Prefill-Decode Disaggregation，预填充-解码分离）从2024年的学术概念蜕变为2025—2026年的产业标配，Mooncake、Dynamo、vLLM V1、SGLang等主流系统密集给出生产级实现。本文沿"两阶段计算本质→PD分离三层技术栈→工业实现对比→MoE专家并行联合优化→AF分离新趋势→挑战与前沿"的路径，拆解PD分离为何能同时压低首Token延迟（TTFT）与单Token间隔（TPOT），它如何与专家并行（EP）、Attention-FFN分离（AF）形成可正交组合的联合优化体系，以及KV Cache传输、负载均衡、异构调度这三项代价如何决定收益上限。面向需要搭建或评估推理系统的开发者，本文给出数据驱动的架构判断与四条可落地的选型清单，文中关键指标均标注出处，便于读者交叉核验。

一、引言：推理成为大模型落地的"最后一公里"

当模型能力进入存量竞争，决定用户体验与成本的变量已经从"训练有多大"转移到"推理跑得多快"。OpenAI在2024年的推理预算已达到其GPT-4训练预算的15倍，Gartner预测2030年大模型推理成本较2025年将下降90%以上——这种量级的降本预期，单靠硬件迭代无法兑现，必须由系统架构层面的重构来承接。

推理服务的第一性矛盾藏在两个内部阶段里。Prefill阶段一次性消费完整输入prompt，做大规模并行矩阵运算，吃算力；Decode阶段逐token自回归生成，每一步都被KV Cache的读取带宽和显存容量锁死，吃访存。二者对硬件资源的诉求几乎相反，却被传统架构强制共置在同一批GPU上，互相拖累。

PD分离（Prefill-Decode Disaggregation）正是针对这一矛盾给出的系统性方案：把Prefill与Decode拆到不同的GPU、实例甚至异构硬件上，各自按自身瓶颈做针对性优化。它看起来只是调度层的结构改动，实际牵动KV Cache传输、负载均衡、异构调度、分布式内存池一整条系统链路。本文从计算特征出发，逐层拆解这条链路，并落到2026年可运行的工业实现上。

二、推理的两阶段本质：Prefill vs Decode 的计算特征差异

理解PD分离的前提，是把两个阶段的资源画像算清楚。

Prefill阶段将整个prompt并行编码。对输入长度为 L、模型隐藏维为 d 的Transformer，单层自注意力的浮点运算量约正比于 4·L²·d（QKV三投影加注意力得分与前向投影），因此Prefill的FLOPs随输入长度呈平方级放大，是典型的计算密集型负载。它把矩阵乘法摊到满算子并行度上，对拥有高TFLOPS与高Tensor Core吞吐的GPU（如H100）非常友好。实测在Qwen3-32B这类模型上，Prefill阶段的GPU算力利用率可以做到80%以上。

Decode阶段则完全不同。每生成一个token是一次串行的前向传播，计算量约正比于当前序列长度（读取并更新KV Cache），整体FLOPs很低，但每一步都要把累积的KV Cache搬进寄存器参与注意力计算。此时GPU算力不再是瓶颈，显存带宽（HBM bandwidth）才是。同样在Qwen3-32B上，Decode阶段的算力利用率常常跌到20%以下——大部分计算单元空转，等数据。

两个阶段的用户体验指标也互相拉拽。TTFT（Time To First Token，首Token时间）由Prefill主导，长prompt下急剧恶化；TPOT（Time Per Output Token）则由Decode的步进延迟决定。传统融合部署里，一个长输入的Prefill会压住同批短请求的Decode，而Decode的高频小步迭代又会割裂Prefill的批次，两阶段的最优解根本无法同时达到。这种"双向拉拽"是PD分离成立的工程根源。

三、PD分离架构的核心思想：为什么"拆开"比"融合"更高效

核心洞察很朴素：既然两阶段的瓶颈维度不同，就应当按资源形态分组，而不是把所有请求混在同一批卡堆上。PD分离把GPU集群划分为Prefill Worker池与Decode Worker池：Prefill池按"算力/带宽"比例配机器，允许长输入独占高计算能力；Decode池则贴近访存优化，用连续批处理（continuous batching）把短步进请求的批量做到极致，压低TPOT。

融合部署的资源错配有量化后果。Decode阶段闲置的Tensor Core无法被Prefill借用，集群整体利用率被"拖底"取平均；反过来，当一批长输入到来时，Decode的实时性又被排队击穿。PD分离之后，每个池子都能独立扩缩容，达到各自的最优资源配比。

衡量这个系统是否合格，不能用朴素的吞吐量（RPS），而要看Goodput（有效吞吐量）——同时满足TTFT与TPOT两个SLO约束的请求比例。举例：一个系统测得10 RPS的原始吞吐，但只有3 RPS的请求同时落在延迟约定内，那么它的Goodput只有3 RPS。PD分离的全部设计（调度、传输、缓存）最终都收敛到一个目标：在SLO约束下最大化Goodput，而非最大化裸吞吐。

四、PD分离的三层技术栈拆解

PD分离不是单个开关，而是一条完整的数据路径。拆开看，它由调度层、传输层、存储层三层构成，每一层解决一个独立问题。

调度层解决"请求该去哪"。路由节点需要决策：这个请求的Prefill在本地执行，还是转发给远程Prefill Worker；短输出/低并发请求直连Decode，长输入/高并发请求先去Prefill。调度要考虑KV Cache命中——如果能命中其他请求已缓存的前缀，这个请求甚至可以直接跳过大部分Prefill。同时还要做队列负载均衡与过载保护，避免某一组Worker被长输入或短输出压垮。Mooncake的全局调度器Conductor就是这一层的代表，它综合缓存命中率、本地队列长度与集群负载给出路由决策。

传输层解决"KV Cache怎么搬过去"。Prefill产出的KV Cache必须从Prefill GPU搬运到Decode GPU，这是PD分离的物理代价。业界有两个主流工程路径：NVIDIA开源的NIXL（NVIDIA Inference Transfer Library，GTC 2025开源）提供点对点KV传输，支持RDMA/InfiniBand、RoCE、TCP、NVMe-oF与S3对象存储五类后端，vLLM把它作为disaggregated prefill的默认连接器之一；Mooncake的Transfer Engine则走零拷贝+RDMA直传。传输设计的核心是"非阻塞"—GPU前向计算不应被传输卡住，要用异步元数据交换把计算与通信重叠起来。

存储层解决"KV Cache放在哪"。GPU HBM装不下长上下文的所有KV，于是形成三级架构：热数据留在GPU HBM，温数据落到节点DRAM（分布式内存池，如Mooncake Store），冷数据退到NVMe/分布式存储。以存换算（用更便宜的内存换掉昂贵显存）的同时，大量复用前缀缓存的工程技巧在这一层展开。三级存储之间的命中率与带宽差异，直接决定系统能否支撑百万Token长上下文。

下面的图1把这三层串成一条完整的数据流：请求先进调度层，调度层决定去Prefill还是直接进Decode，KV Cache经传输层在存储层与Worker之间搬移。

flowchart LR
    subgraph L1["调度层"]
        R["请求入口"]
        S["全局调度器<br/>路由决策+负载均衡"]
    end
    subgraph L2["传输层"]
        T["NIXL / Transfer Engine<br/>RDMA·零拷贝·NVLink"]
    end
    subgraph L3["存储层"]
        HBM["GPU HBM<br/>热KV"]
        DRAM["节点DRAM<br/>温KV"]
        NVMe["分布式存储<br/>冷KV"]
    end
    subgraph W["Worker池"]
        PW["Prefill Worker"]
        DW["Decode Worker"]
    end
    R --> S
    S -->|"本地/远程选径"| PW
    S -->|"可跳过Prefill"| DW
    PW --> T
    T <--> HBM
    T <--> DRAM
    T <--> NVMe
    T --> DW

图1展示了PD分离的完整数据流：调度层在前端做路由与缓存命中的判断，传输层负责KV Cache在GPU、DRAM、分布式存储之间的移动，Worker池只关心各自阶段的计算。三个层次彼此解耦，意味着你可以独立替换传输实现（NIXL换成自研RDMA栈）或存储后端（分布式内存池换成S3），而不必推翻整个系统——这正是PD分离能被工业界快速接受的结构性原因。

以三层技术栈为透镜，就能理解为什么"PD分离看起来简单、做起来难"：调度要实时感知集群状态，传输要压到零拷贝级别，存储要承受海量KV的读写压力。任何一层掉链子，Goodput都会被拖垮。

五、工业级实现全景：Mooncake、Dynamo、SGLang与vLLM

把三层技术栈对照到四个主流实现，能清晰看到产业分化的两种路线：以KV Cache为核心的"存储中心派"（Mooncake）与以调度编排为核心的"框架派"（Dynamo），外加两个开源 serving 引擎的双轨支持。

Mooncake（月之暗面Kimi+清华）：以KV Cache为中心的分离式架构。它将GPU集群解耦为Prefill集群、Decode集群与分布式KV缓存池（Mooncake Store），并充分利用GPU集群中闲置的CPU、DRAM与SSD资源做解耦缓存。核心创新有三：分块管道并行（Chunked Pipeline Parallelism）把单层Prefill按块切分，TTFT较传统序列并行降低约40%；KV Cache感知的全局调度让缓存复用率超过50%；基于预测的早期拒绝策略在过载场景提前放弃无望请求。论文报告的指标是长上下文模拟场景吞吐最高提升525%，真实负载下让Kimi多处理75%请求，且承载了Kimi线上80%以上的流量。

Dynamo（NVIDIA）：开源的分布式推理编排框架，推理引擎无关，可编排vLLM、SGLang、TensorRT-LLM等后端。它由Frontend、Router、Worker、PrefillQueue四个核心组件构成，用KV Block Manager（KVBM）在底层路由Prefill产出，用NIXL完成GPU间KV传输。Dynamo把"PD分离建成平台能力"：KV感知路由、动态Worker规划、K8s编排、自动扩缩容一应俱全，适合把一套推理服务做成可运营的集群产品。

开源双轨：SGLang与vLLM。SGLang在2025年后持续加强对PD分离与MoE大EP的支持，其事件循环队列天然适合分离式调度；vLLM在V1架构中提供了KV Connector抽象层，支持NIXL Connector、LMCache Connector、SharedStorageConnector等多种传输实现，配合LMCache可显著改善p95 Inter-Token Latency——LMCache官方给出的数据是相较基线降低78.8%。换句话说，PD分离已经下沉到开源引擎的默认能力之中，不再是论文里的玩具。

下面的图2把Mooncake与Dynamo两类实现并列对比，便于看清"以存为中心"与"以调度为中心"的差异。

flowchart TD
    subgraph MK["Mooncake（KV Cache中心）"]
        M1["全局调度器 Conductor"]
        M2["Prefill 集群"]
        M3["Decode 集群"]
        M4["Mooncake Store<br/>分布式KV池 CPU/DRAM/SSD"]
        M1 --> M2
        M2 --> M3
        M2 <--> M4
        M3 <--> M4
    end
    subgraph DY["Dynamo（调度编排中心）"]
        D1["Frontend"]
        D2["Router"]
        D3["Worker Pool<br/>vLLM·SGLang·TRT-LLM"]
        D4["KV Block Manager + NIXL"]
        D1 --> D2
        D2 --> D3
        D3 <--> D4
    end

图2把两条路线并排呈现。Mooncake把事情的重心压在"KV Cache在存储池里的组织与复用"上，调度器（Conductor）的任务更像是为每个请求找到一段可复用的KV前缀；Dynamo则把重心放在"在庞大的集群里编排多个引擎实例"，Router和KVBM负责把Prefill的产出精确路由到正确的Decode Worker，NIXL处理底层搬运。前者先解决"缓存放哪、怎么省显存"，后者先解决"集群如何规模化运营"。二者并非互斥——Kimi也可以把Dynamo当作编排层，而vLLM生产部署同样可以接Mooncake Store。

选型上可以给一个粗糙的判断：如果你的瓶颈是长上下文显存（如文档问答、长对话），Mooncake路线的"以存换算"收益更大；如果你的瓶颈是大规模多实例集群的运维复杂度（多模型、多引擎、弹性伸缩），Dynamo路线的编排能力更直接。

六、从PD分离到MoE联合优化：专家并行（EP）的引入

PD分离解决了"阶段冲突"，却撞上了MoE（混合专家）带来的新复杂度。主流MoE模型（如DeepSeek-V3/R1，每层256个专家）在推理时只稀疏激活部分专家，专家参数分布在前置的并行拓扑上。当PD分离与MoE叠加，路由决策不再只是"去Prefill还是Decode"，还必须同时回答"这次激活了哪几位专家、它们在哪几张GPU上"。两个决策维度耦合，调度空间被显著放大。

DeepSeek推理系统给出了"大EP"（Wide Expert Parallelism）的工程答案。它将专家以跨节点的方式平铺到多张GPU上，每张GPU只持有少量专家参数，把访存压力摊薄，同时用自研通信库DeepEP（用于token与专家之间的高效分发与收集）与EPLB（Expert Parallelism Load Balancer，专家级负载均衡）解决流量不均。DeepSeek-V3/R1的部署把"分离式架构+DP+EP"作为默认组合，跨节点的宽专家并行配合PD分离，让稀疏激活的真正优势（计算与访存分离优化）在系统层面兑现。

阿里云PAI则把"EP+PD分离+MTP"做成一键部署模板：一个配置项同时打开专家并行、PD分离与Multi-Token Prediction（一次前向预测多个token，进一步压低TPOT）。这里的关键工程权衡是：MoE的EP对通信极其敏感，专家路由产生的all-to-all通信不能走慢速路径，必须与KV传输共用一套高性能网络才能不成为新的瓶颈。

图3展示MoE+EP+PD分离联合优化下的请求生命周期：路由层同时决策"去哪个PD节点"与"激活哪些专家"，专家在EP拓扑上的分布决定KV Cache搬到哪里。

flowchart LR
    R["请求"] --> S["路由层<br/>PD选径 + 专家路由"]
    S -->|"Prefill路径"| PW["Prefill Worker"]
    S -->|"Decode路径"| DW["Decode Worker"]
    PW <-->|"KV传输"| KV["KV Cache 存储池"]
    DW <--> KV
    subgraph EP["专家并行拓扑"]
        E1["GPU1 专家A·E"]
        E2["GPU2 专家B·F"]
        E3["GPU3 专家C·G"]
        E4["GPU4 专家D·H"]
    end
    PW <-->|"all-to-all·DeepEP"| E1
    PW <--> E2
    PW <--> E3
    PW <--> E4
    DW <-->|"all-to-all·DeepEP"| E1
    DW <--> E2
    DW <--> E3
    DW <--> E4

图3揭示了一个容易被低估的事实：MoE加入后，PD分离的"传输层"里不再只有KV Cache在流动，还有每token的专家激活向量在EP拓扑上做all-to-all交换。因此联合优化真正的功力在通信路径的统一调度——KV传输与专家通信共享网络带宽，调度器必须同时预算这两类流量，否则任意一侧突发都会互相挤占，把PD分离省下的延迟又吃回去。这也解释了为何DeepSeek、MegaScale这类系统都要自研通信库：通用GPU通信栈在"KV大块搬运+专家细粒度交换"混合模式下，性能远不如按场景裁剪的实现。

联合优化后的资源利用率出现质变：Prefill负载与Decode负载、计算型专家与访存型算子被分别调度到最适合自己的硬件形态上。MoE的稀疏性不再是系统的负担，反而成为调度的额外自由度。

七、AF分离：Attention与FFN的进一步解耦

PD分离是纵向的阶段分离（按请求生命周期的时间维度切），AF分离则是横向的层间分离（按Transformer内部的算子维度切）。MoE模型里，Feed-Forward Network（FFN）是计算密集重头，几乎贡献了主要算力消耗；Attention层则是访存密集的KV读写大户。传统部署中二者在同一张卡上互相争抢资源，AF分离把它们拆到不同硬件。

MegaScale-Infer、Step-3是这一路线的代表实践：通过定制通信库实现层间流水并行，让Attention层的访存工作与FFN层的矩阵计算落在不同的GPU（甚至异构芯片）上，各自按瓶颈优化，并配合前面的专家负载均衡与路由优化。中国信通院的2026年报告把AF分离直接列为"PD分离—MoE优化进阶"路径的下一个热点。

AF与PD的关系是正交可组合的：PD把那条请求流水线在时间上切开（先Prefill后Decode，分给不同池子），AF把每一层的内部结构在空间上切开（Attention与FFN分给不同硬件）。两者叠加时，一个请求的Prefill阶段里Attention可能跑在P-AF卡上、FFN跑在P-FFN卡上，Decode阶段同理。这种"阶段×层次"的二重分离把硬件异构性利用到了极致，但也对通信调度提出了双倍要求——调度器要在两个维度上同时预算流量。

对绝大多数团队来说，AF分离的工程门槛高于PD分离：它需要更细粒度的计算图改造与更紧的定制通信耦合，收益在超大模型与专用硬件场景才足够明显。PD分离是"现在就该做的结构性优化"，AF分离更像是"部署规模与硬件形态到位后的下一步"。

八、挑战与权衡：传输开销、负载均衡与异构调度

PD分离不是没有代价，三个挑战决定它的收益上限。

传输开销：GPU间KV Cache移动是PD分离的物理成本。在NVLink/IB这类高带宽低延迟网络下，传输可以被计算重叠隐藏；但在PCIe或边缘部署这类带宽受限场景，KV搬运会成为新的瓶颈，甚至抵消分离收益。工程上常用量化KV Cache、分块传输、异步预取来压低这部分成本。传输粒度也可以选择：粗粒度整段搬+细粒度增量搬的权衡，直接影响网络占用。

负载均衡：PD分离天然制造两类不均衡。Prefill Worker可能因长输入堆积而饱和——长prompt的Prefill耗时远超短prompt；Decode Worker可能因短输出而空闲——请求的输出分布高度倾斜。动态扩缩容与请求调度必须联动：侦测到Prefill队列积压就把请求路由到别的池，发现Decode有空闲就增加并发。Mooncake的早期拒绝策略处理的是另一面：在预测无法满足SLO时，提前拒绝而非排队无效消耗。

异构调度：硬件层面的差异与自主趋势，正在把PD分离推向更复杂形态。上海AI实验室DeepLink团队2026年初发布了首个支持国产异构算力的PD分离混合推理方案；云天励飞公布了规划专用P芯片（负责Prefill）与D芯片（负责Decode）的路线图；DeepSeek联合清华、北大于2026年2月提出"双路径KV-Cache加载"机制，通过"存储到解码"路径缓解Prefill侧的I/O单点瓶颈。异构调度的本质是让调度器理解每种芯片的长短板，把计算型负载与访存型负载精确匹配到对应硬件。

九、2026年前沿：专用芯片、智能体原生架构与AI存储进化

PD分离的2026年前沿，正从软件架构向硬件协同与数据底座两个方向延伸。

硬件级优化：2026年7月WAIC期间，中昊芯英发布第二代自研TPU"须臾"，其架构原生适配PD分离调度；天数智芯的新一代通用GPU天垓300在行动智能方面强化了PD分离能力，对Prefill与Decode做差异化优化；北京京算Token工厂采用PD分离智能调度架构，通过异构算力池化提升算力吞吐。PD分离已从"软件层的调度技巧"升级为"芯片设计时的原生考量"——芯片内部算子组织、片上存储与互联带宽都围绕两阶段特性做定向裁剪。

智能体原生架构与AI存储进化：AI存储正从"数据存储"走向"知识存储/记忆存储"。大模型"易遗忘"的通病，催生了把推理状态（KV Cache、会话记忆、检索索引）视为一等公民的存储系统。2025年12月，记忆张量与商汤科技合作，把PD分离架构与记忆结构深度耦合，重构"记忆—计算—调度"体系——KV Cache不再只是被"搬运"的临时数据，而是被"管理"的长期资产。这一思路把PD分离从"服务延迟优化"升维到"Agent记忆基础设施"。

多模态推理优化：视觉Token、音频特征、视频帧的KV Cache远大于纯文本，张量级KV Cache管理成为新战场。多模态模型推理中，视觉encoder产生的KV往往占据显存大头，PD分离的存储层必须按模态差异化缓存策略，否则多模态长上下文会迅速击穿任何内存池。

十、总结与开发者实操建议

本文沿着一条清晰的演进线展开：两阶段计算本质决定了必须拆（第二章）→PD分离三层技术栈是拆的工程骨架（第四章）→Mooncake与Dynamo给出了两条可复用的工业实现范式（第五章）→MoE让"拆"升级为"联合优化"（第六章）→AF分离提供了进一步的可组合维度（第七章）→传输、均衡、异构调度构成不可回避的代价（第八章）→专用芯片与AI存储把PD分离推向系统级基础设施（第九章）。

落到你的工程决策上，四条检查清单：

用SLO约束而不是负载来选型。先回答"我的业务是TTFT敏感（实时对话、交互式Agent）还是TPOT敏感（长文本生成、批量写作）"。只有同时面临严格低首Token延迟与高并发吞吐，PD分离才从"可选项"变成"必选项"；单侧敏感的服务用传统融合部署再加连续批处理可能更划算。
建立基线再谈优化。上线前先记录准确率、延迟（TTFT/TPOT/P95）、显存占用、GPU利用率四个核心指标，没有基线就没法量化PD分离的净收益，也无法判断KV Cache优化是否真实兑现。
优先深耕KV Cache优化。量化、稀疏化、分页、淘汰、前缀复用——这在超长上下文时代是比PD分离本身更普遍的杠杆。很多团队在跑PD分离之前，先把KV Cache砍掉一半显存，收益更直接。
盯紧框架版本迭代。vLLM V1的KV Connector、SGLang 0.5+的PD支持、Dynamo 1.0+的编排能力都在快速演进出更成熟的默认值。使用开源路线时，优先选择把PD分离做进默认能力的版本，减少自研维护成本。

一条判断供你对照：如果你们的推理服务同时被低首Token延迟和高并发吞吐两个目标夹击，PD分离不是加分项，而是绕不开的架构必经之路。学会用Goodput而不是RPS来衡量系统，你会更早看清这一点。

参考来源

中国信通院&人工智能产业发展联盟：《大模型推理优化关键技术及应用实践研究报告（2026年）》，2026年3月（caict.ac.cn）
Moonshot AI & Tsinghua KVCache.ai：Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving（525%吞吐提升、75%请求增量、Kimi 80%+流量承载）
NVIDIA Technical Blog：Enhancing Distributed Inference Performance with the NVIDIA Inference Transfer Library（NIXL，GTC 2025开源，RDMA/UCX/NVMe/S3后端）
NVIDIA Dynamo（developer.nvidia.com / GitHub）：KV Block Manager、Frontend/Router/Worker/PrefillQueue四组件、推理引擎无关
vLLM Docs：Disaggregated Prefilling（KV Connector：NixlConnector / LMCacheConnector / SharedStorageConnector）
LMCache Lab：LMCache + vLLM v1 PD，p95 ITL 降低78.8%
DeepSeek（DeepEP、EPLB、256专家/层的MoE架构与宽专家并行推理实践）
百度百科-中昊芯英"须臾"TPU、天数智芯天垓300、京算Token工厂等PD分离落地报道（2026年7月）