大模型推理分离架构与预填充解码优化 — 深度调研报告

调研主题：大模型推理分离架构（Prefill-Decode Disaggregation）与预填充解码优化 所属领域：大模型框架 / LLM Inference Serving 调研日期：2026-05-13 报告类型：四维度全景分析 + 精华整合

第一部分：概念剖析

1.1 定义澄清

通行定义

大模型推理分离架构（Prefill-Decode Disaggregation, PD Disaggregation） 是一种将 LLM 推理过程的两个阶段——预填充（Prefill）和解码（Decode）——分配到不同 GPU 或不同计算节点上独立执行的系统架构。预填充阶段并行处理整个输入提示（prompt），生成 KV Cache；解码阶段逐 token 自回归生成输出，反复读取 KV Cache。分离式架构的核心动机是二者资源需求截然不同：预填充是计算密集型（受限于 GPU TFLOPS），解码是内存带宽密集型（受限于 GPU HBM 带宽）。将二者解耦后可以独立优化、独立扩缩容，从而显著提升整体系统吞吐和延迟满足率。

常见误解

1. 误解一：分离架构等同于分布式推理 分布式推理（Tensor Parallelism, Pipeline Parallelism）解决的是"单 GPU 放不下模型"的问题，将模型参数切分到多卡；而 PD 分离解决的是"预填充和解码互相干扰"的问题，并不要求模型必须跨卡部署。二者是正交的优化手段。

2. 误解二：预填充和解码可以完全独立于同一批请求 实际上分离架构带来了显存状态转移（KV Cache 传输）的新开销。如果在物理分离的节点间传输 KV Cache 的网络带宽不足，可能抵消分离带来的收益。这也是当前研究的核心矛盾之一。

3. 误解三：PD 分离只对超大模型有效 事实上，对于 7B-13B 规模的中等模型，在长上下文（>4K tokens）或高并发场景下，PD 分离同样能带来显著收益。主要瓶颈在于模型大小决定 KV Cache 体积，而非模型参数规模本身。

边界辨析

1.2 核心架构

┌──────────────────────────────────────────────────────────────────┐
│                   PD 分离推理系统架构 (Disaggregated Serving)      │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────┐    ┌──────────────┐    ┌──────────────┐           │
│  │  Router   │───>│  Prefill     │───>│  Decode      │           │
│  │ (请求路由) │    │  Pool       │    │  Pool        │           │
│  │          │    │ (计算密集)    │    │ (内存带宽密集) │           │
│  └──────────┘    └──────┬───────┘    └──────┬───────┘           │
│         │               │                   │                   │
│         │               │    KV Cache       │                   │
│         │               │◄─── Transfer ────►│                   │
│         │               │   (RDMA/NVLink)   │                   │
│         │               ▼                   ▼                   │
│         │        ┌──────────────┐    ┌──────────────┐           │
│         └────────┤  KV Cache    │    │  Monitor &   │           │
│                  │  Store       │    │  Autoscaler  │           │
│                  │ (分布式缓存)  │    │ (SLO追踪/扩缩容)│          │
│                  └──────────────┘    └──────────────┘           │
│                                                                  │
│  KV Cache 传输后端: Mooncake / NIXL / NCCL / TCP                 │
└──────────────────────────────────────────────────────────────────┘

组件说明：

• Router：接收用户请求，根据请求特征（上下文长度、缓存命中状态、SLO 要求）将请求路由到合适的 Prefill 节点或直接到 Decode 节点（缓存命中时）
• Prefill Pool：一组 GPU，专门处理预填充计算——并行处理 prompt tokens，生成 KV Cache，完成后通过高速网络将 KV Cache 发送到 Decode 节点
• Decode Pool：一组 GPU，专门处理自回归解码——接收 KV Cache 后逐 token 生成输出，具有低延迟要求
• KV Cache Store：分布式 KV 缓存层（跨 GPU DRAM/CPU DRAM/NVMe），支持缓存复用，减少重复预填充
• Monitor & Autoscaler：监控 TTFT/TPOT/SLO 达标率，自动调节 Prefill/Decode 节点配比

1.3 数学形式化

(1) 推理阶段的计算特征

其中 $N_{\text{params}}$ 为模型参数量，$S$ 为输入序列长度，$N_{\text{gen}}$ 为生成 token 数，$B_{\text{compute}}$ 为 GPU 计算带宽（TFLOPS），$B_{\text{memory}}$ 为 GPU 显存带宽（GB/s）。该公式量化说明预填充延迟与输入长度成正比（计算受限），解码延迟与生成 token 数成正比（访存受限）。

(2) KV Cache 传输开销

每层每注意力头的 KV Cache 大小为 $2 \times N_{\text{heads}} \times d_{\text{head}} \times S$（K 和 V 各一份），FP16 精度下每元素 2 字节。传输时间由网络带宽 $B_{\text{network}}$ 决定。对于 Llama 70B 在 4K 上下文下，KV Cache 约 1.34 GB，100GbE 网络下传输约 110ms——这是分离架构的关键开销。

(3) Goodput 度量

Goodput 是 PD 分离领域最核心的度量指标，同时约束首 token 延迟（TTFT）和每 token 延迟（TPOT），比原始吞吐更能反映用户体验。

(4) 资源分配优化模型

$N_p$ 和 $N_d$ 分别为预填充和解码的 GPU 数量。$\lambda_p, \lambda_d$ 为两阶段的请求到达率。该优化问题描述了在总 GPU 预算下如何分配 prefill/decode 配比以最小化延迟。

(5) 缓存复用率影响

其中 $r_{\text{cache}}$ 为缓存命中率，$T_{\text{prefill,full}}$ 为完整预填充时间，$T_{\text{prefill,append}}$ 为追加预填充时间。当缓存命中率 > 90%（如智能体场景），加速比可达 5-10 倍。

1.4 实现逻辑（Python 伪代码）

class DisaggregatedServingSystem:
    """PD 分离推理系统的核心抽象"""

    def __init__(self, config: DisaggConfig):
        self.router = AdaptiveRouter(config.routing_policy)
        self.prefill_pool = GPUPool(
            num_gpus=config.num_prefill_gpus,
            phase="prefill",
            kv_cache_transport=config.kv_transport_backend  # Mooncake/NIXL
        )
        self.decode_pool = GPUPool(
            num_gpus=config.num_decode_gpus,
            phase="decode",
            kv_cache_transport=config.kv_transport_backend
        )
        self.kv_cache_store = DistributedKVCache(
            tiers=["gpu_hbm", "cpu_dram", "nvme"],
            eviction_policy="lru"
        )
        self.monitor = SLOAwareMonitor(
            ttft_slo=config.ttft_slo,   # e.g. 500ms
            tpot_slo=config.tpot_slo    # e.g. 50ms
        )

    def serve_request(self, request: Request) -> Response:
        """请求处理主流程"""
        # Step 1: 路由决策
        route_plan = self.router.decide_route(
            prompt=request.prompt,
            cached_kv_id=self.kv_cache_store.lookup(request.prompt_prefix)
        )

        if route_plan.is_cache_hit:
            # 缓存命中 → 直接发送到 Decode Pool（跳过 Prefill）
            kvcache = self.kv_cache_store.fetch(route_plan.cache_key)
            return self.decode_pool.generate(request, kvcache)

        # Step 2: Prefill 阶段（计算密集型）
        prefill_result = self.prefill_pool.execute(
            phase="prefill",
            prompt=request.prompt,
            output_kv_cache=True
        )

        # Step 3: KV Cache 传输（关键瓶颈）
        kv_cache = prefill_result.kv_cache
        self._transfer_kv_cache(kv_cache, from_pool=self.prefill_pool,
                                to_pool=self.decode_pool)

        # Step 4: Decode 阶段（内存带宽密集型）
        response = self.decode_pool.execute(
            phase="decode",
            input_ids=request.tokenized_prompt,
            kv_cache=kv_cache
        )

        # Step 5: 缓存 KV 供后续复用
        self.kv_cache_store.store(kv_cache, ttl=request.session_ttl)

        # Step 6: SLO 监控
        self.monitor.record(request.id, ttft=... , tpot=...)
        return response

    def _transfer_kv_cache(self, kv_cache, from_pool, to_pool):
        """通过高速网络传输 KV Cache（RDMA 零拷贝优先）"""
        transport = from_pool.get_transport(to_pool)
        transport.async_send(kv_cache)  # 流水线化：边传输边解码

1.5 性能指标

1.6 扩展性与安全性

水平扩展

• Prefill 池独立扩容：根据 TTFT SLO 和请求到达率，独立增加 Prefill 节点数，无需增加 Decode 节点，反之亦然。NVIDIA Dynamo 和 SGLang 均支持 K8s 原生的独立扩缩容。
• 多级 KV Cache 层级：GPU HBM → CPU DRAM → NVMe → 分布式缓存（RDMA 网络），形成类似 CDN 的多级缓存架构（如 Together AI 的 CPD 方案）。
• 全局路由负载均衡：Router 层根据各节点负载、缓存状态、网络拓扑智能分发请求，支持在线和离线混合部署。

垂直扩展

• 单节点 Prefill 优化：使用更大的 batch size、更高的 Tensor Parallelism 度来压满 GPU 计算单元。
• 单节点 Decode 优化：优化重点在 HBM 带宽利用率，如 PageAttention、FlashAttention 减少显存碎片和访存次数。单节点解码吞吐上限由内存带宽决定。
• KV Cache 压缩：CacheGen 等技术可将 KV Cache 压缩 3.5-4.3× 以减轻传输和存储压力。

安全考量

• KV Cache 泄漏风险：KV Cache 包含用户输入的语义信息，跨节点传输时需加密。在多租户环境下，隔离不同用户的 KV Cache 至关重要。
• SLA 攻击（SLO 饥饿）：攻击者可以发送超长提示消耗 Prefill 节点资源，导致正常请求 TTFT 超标。需要请求级隔离和公平调度策略。
• 网络级 DoS：KV Cache 传输可能占满 RDMA 网络带宽，影响其他推理流量。DeepSeek DualPath 使用 QoS（VL/TC）为推理通信保留 99% 优先级。
• 缓存毒化（Cache Poisoning）：恶意用户构造特定前缀污染 KV Cache，导致后续用户请求产生错误输出。需实现缓存内容校验和时效管理。

第二部分：行业情报

2.1 GitHub 热门项目

2.2 关键论文（12 篇）

2.3 系统化技术博客（10 篇）

2.4 技术演进时间线

2023.11 ─┬─ Splitwise (Microsoft) 提出 PD 阶段拆分概念
2024.01 ─┼─ DistServe (北大+UCSD) 定义 Goodput，OSDI'24
2024.03 ─┼─ Sarathi-Serve (Microsoft) 提出分块预填充 + Stall-Free 调度，OSDI'24
2024.04 ─┼─ LoongServe (北大) 弹性序列并行，SOSP'24
2024.06 ─┼─ Splitwise 贡献被合并入 vLLM (PR #2809)
2024.09 ─┼─ CacheGen (芝加哥大学) KV 缓存压缩与流式传输，SIGCOMM'24
2024.11 ─┼─ Mooncake (月之暗面) 开源传输引擎
2025.02 ─┼─ Mooncake 获 FAST 2025 最佳论文奖 → 集成 vLLM/SGLang/TensorRT-LLM
2025.03 ─┼─ SGLang 发布 v0.4.5，原生支持 PD 分离
2025.05 ─┼─ EPDServe (ICML'25) 提出三阶段 EPD 分离，支持多模态
2025.07 ─┼─ Nexus 提出 GPU 内 PD 动态资源分区
2025.08 ─┼─ TaiChi 统一聚合与分离，差异化 GPU 实例
2025.09 ─┼─ NVIDIA 开源 NIXL 传输库；Dynamo 公开
2025.10 ─┼─ ARES：基于输出长度预测的自适应解码重调度
2025.12 ─┼─ TokenScale：基于 Token Velocity 的自动扩缩容
2026.01 ─┼─ Red Hat OpenShift AI 3.0 集成 PD 分离
2026.02 ─┼─ DeepSeek DualPath：双路径 KV-Cache 加载，打破 I/O 瓶颈
2026.02 ─┼─ PrefillShare：多模型共享预填充模块
2026.03 ─┼─ NVIDIA Dynamo 1.0 GA：生产级 PD/EPD 分离
2026.03 ─┼─ DUET (DAC'26) 专用硬件封装，4× TTFT
2026.05 ─┴─ 当前状态：PD 分离进入生产成熟期，从"要不要分离"进入"如何精细化分离"阶段

第三部分：方案对比

3.1 历史发展时间线

2023    ─┬─ Splitwise 提出分离设想：prefill 和 decode 跑在不同 GPU
         │   → 核心洞察：prefill 计算密集、decode 访存密集
2024    ─┼─ 两个并行突破方向：
         │   ├─ 物理分离路线：DistServe (OSDI'24)、Mooncake (FAST'25)
         │   │   → 证明分离可大幅提升 goodput
         │   └─ 分时交错路线：Sarathi-Serve (OSDI'24) chunked prefill
         │       → 不分离硬件但消除头部阻塞
2025    ─┼─ 分化加剧与融合：
         │   ├─ 新维度：EPD 三阶段分离 (ICML'25)、GPU 内分离（Nexus）
         │   ├─ 工程化：vLLM/SGLang 原生支持、NVIDIA Dynamo 公开
         │   └─ 融合：TaiChi 统一聚合与分离、冷热分离（CPD）
2026    ─┴─ 当前状态：生产级成熟（Dynamo 1.0 + 多后端）；前沿探索从"是否分离"转向
         "分离粒度"（每请求级/每 token 级）和"传输瓶颈"（DeepSeek DualPath）

3.2 6 种方案横向对比

3.3 技术细节对比

3.4 选型建议

选型决策树

模型大小?
├─ < 7B        → 全聚合（无需分离）
├─ 7B-70B ──── 上下文长度?
│              ├─ < 2K → 分块预填充
│              └─ > 2K → 轻量级 PD 分离（SGLang）
└─ > 70B ───── 应用场景?
               ├─ 在线对话 → 物理 PD 分离（Dynamo/vLLM）
               ├─ 多模态   → EPD 三阶段分离
               ├─ 智能体   → 混合聚合-分离 + 缓存优化
               └─ 离线批处理 → 物理 PD 分离（prefill 优先，decode 可略弱）

第四部分：精华整合

4.1 The One 公式

核心心智模型：PD 分离的本质是用空间换时间——用一个额外的 KV Cache 网络传输开销换取两个阶段的独立优化空间。当传输成本小于干扰成本时，净收益为正。

4.2 一句话解释

大模型推理分离架构，就是把 LLM 思考问题（预填充）和回答问题的过程（解码）分给不同的 GPU 去执行，让擅长计算的 GPU 负责"思考"，擅长读内存的 GPU 负责"回答"，互不干扰地并行工作。

4.3 核心架构图

用户请求 → [Router 路由决策]
               │
        ┌──────┴──────┐
        ▼              ▼
   [缓存命中?]     [缓存未命中]
        │              │
        │      ┌───────┘
        │      ▼
        │   [Prefill GPU] → KV Cache
        │      │
        └──────┼────────── (RDMA 传输)
               ▼
          [Decode GPU] → 流式响应
               │
               ▼
          [KV Cache Store] (多级缓存: GPU→DRAM→NVMe)

4.4 STAR 总结

Situation（背景 + 痛点）

LLM 推理中，预填充（Prefill）和解码（Decode）对计算资源的需求截然相反：预填充需要高 TFLOPS 计算能力并行处理所有 prompt token，而解码需要高内存带宽逐 token 生成输出。2023-2024 年主流方案将二者混合在同一 GPU 上执行，导致严重干扰——一个长提示的预填充会阻塞所有并发解码迭代，产生头部阻塞（Head-of-Line Blocking）。随着 70B+ 大模型和多轮对话、智能体等场景普及，这一矛盾急剧恶化，TTFT 抖动可达 10 倍以上。

Task（核心问题）

如何在避免预填充-解码相互干扰的前提下，同时最大化系统吞吐和满足严格延迟 SLO（TTFT < 500ms, TPOT < 50ms）？核心约束包括：(1) 两阶段间必须传输 KV Cache，其大小与上下文长度线性增长（70B 模型 4K 上下文约 1.34 GB）；(2) 网络带宽有限，传输延迟不可忽略；(3) GPU 集群是昂贵的共享资源，扩缩容效率直接影响 TCO。

Action（主流方案）

技术进步可分三个关键阶段：(1) 软件优化（2024）：Sarathi-Serve 提出分块预填充 + 无气泡调度，在不分离硬件的前提下缓解头部阻塞；(2) 物理分离（2024-2025）：DistServe、Splitwise、Mooncake 等将两阶段分配到独立 GPU 池，证明 goodput 可提升 4-7×，但受限于 KV Cache 跨节点传输延迟；(3) 精细化分离（2025-2026）：NVIDIA Dynamo 1.0 实现生产级 PD/EPD 分离，SGLang 和 vLLM 原生支持；DeepSeek DualPath 突破 I/O 瓶颈，利用解码引擎闲置网卡实现双路径加载；TaiChi 和 PPD 实现请求级自适应的聚合-分离切换；DUET 甚至为两阶段设计专用芯片。

Result（效果 + 建议）

当前 PD 分离已进入生产成熟期。Dynamo 1.0 在 Blackwell 上实现 7× 吞吐提升，DeepSeek DualPath 在 660B 模型上实现 1.96× 在线吞吐提升。对技术选型的实操建议是：(1) < 7B 模型或短文本场景无需分离——全聚合即可；(2) 70B+ 模型或长上下文强烈推荐物理 PD 分离，优先使用 NVIDIA Dynamo 或 SGLang 的现成实现；(3) 多模态应用采用 EPD 三阶段分离提升编码效率；(4) 智能体场景（缓存命中率 > 90%）需额外关注 I/O 瓶颈和缓存架构，可参考 DeepSeek DualPath。未来方向集中在 GPU 内动态分离、多模型共享预填充（PrefillShare）、以及硬件-算法协同设计。

4.5 理解确认问题

问题：假设你的推理集群从 100 个请求/秒增长到 1000 个请求/秒，输入平均长度从 1K tokens 增长到 8K tokens。在"为 Prefill 和 Decode 分别增加等比例 GPU"和"动态调整 Prefill/Decode 配比"两个策略中，哪个策略更优？为什么？

参考答案：动态调整配比策略更优。因为输入长度增长会线性增加 Prefill 的计算量（KV Cache 也随之增大），而 Decode 负载主要受生成 token 数影响。此时 Prefill 压力会不成比例地增长，简单等比例增加 GPU 会导致 Decode 资源过剩。正确的做法是使用 TokenScale 或 Dynamo Planner 等工具，基于当前请求特征（输入长度分布、缓存命中率、SLO 要求）动态计算最优 P/D 配比——通常在输入变长时需要将更多 GPU 分配给 Prefill 池。同时建议引入冷热请求分离（CPD），让缓存命中的请求直接发往 Decode，缓解 Prefill 压力。

附录

A. 参考资源汇总

B. 缩写对照表

本报告基于 2026 年 5 月公开数据编写，所有 GitHub Stars 数据为近似值，以实际 GitHub 页面为准。