# 11.3 分离式 Prefill-Decode 架构

随着大模型在生产环境的大规模应用，2024-2025 年推理引擎领域最重要的架构创新是**分离式推理架构**（Disaggregated Prefill-Decode）。这一架构直击了单体推理引擎的核心痛点。

## 11.3.1 单实例架构的资源错配

在传统的单实例架构（如 11.1 节所述）中，同一个请求的 Prefill（预填充，处理 Prompt）和 Decode（解码，生成回答）都在同一个 GPU 实例上执行。这导致了严重的资源错配：

1. **计算特征冲突**：Prefill 是**计算密集型**（Compute-Bound）操作，能高效利用 Tensor Core；而 Decode 是**访存密集型**（Memory-Bound）操作，受限于显存带宽。将两者混合在同一 GPU 上调度，会导致计算单元和内存带宽轮流闲置。
2. **延迟相互干扰**：当批次中加入一个新的长 Prompt 请求进行 Prefill 时，整个批次的计算时间会被拉长，导致正在进行 Decode 的请求出现明显卡顿（TPOT 飙升），严重影响流式输出的平滑度。
3. **资源配置僵化**：有些应用场景（如代码补全）的特点是“长输入短输出”，显存压力大；有些（如故事生成）则是“短输入长输出”，计算压力小。单实例架构无法为不同阶段独立扩容。

## 11.3.2 架构设计与 KV 缓存传输挑战

**分离式架构**将推理集群在物理上划分为两个独立的池化资源：

1. **Prefill 集群**：专门处理长文本理解。通常配置具有强算力的 GPU（如 H100/B200）。由于足够长的单条 Prompt 即可打满算力，Prefill 的 batch size 需要受控——合批主要用于聚合短 Prompt，超过算力饱和点后继续加大 batch 不再提升吞吐，只会拉长批内所有请求的 TTFT。
2. **Decode 集群**：专注于逐词权重和 KV 缓存的快速读取，优先看显存容量与带宽。Decode 是访存密集型，需要在专用 GPU 上累积较大的 batch size 来摊薄权重与 KV 缓存的读取成本。H200/B200/B300 更适合高端 Decode 池；L40S 这类性价比卡可用于较小模型或低成本分层服务，但不能简单等同于高带宽大显存卡。

请求首先到达 Prefill 集群处理完 Prompt。**真正的工程挑战在于状态的交接**：Prefill 阶段计算出的所有 KV 缓存必须传输给 Decode 集群才能继续生成。

**KV 缓存传输的定量成本**：对于 32K 词元的长提示词，以 Llama-70B 的 80 层、8 个 KV heads、head\_dim=128、batch size=1 计算，KV 缓存大小为 $$32768 \times 80 \times 2 \times 8 \times 128 \times \text{bytes}$$，即约 5 GiB（FP8）或 10 GiB（FP16）。如果只用标准万兆以太网（10 Gbps）传输，理想线速也需要约 4.3-8.6 秒，足以抵消 Prefill 集群的收益。生产环境通常采用以下优化手段：

* **高速网络拓扑**：部署 InfiniBand、RoCE 或节点内 NVLink，使用 GPU Direct RDMA / GPU-to-GPU 传输在计算节点的显存之间搬运 KV，减少 CPU 和操作系统栈开销。
* **异步流水线传输**：Prefill 在计算 KV 缓存的同时启动传输，当前层或分块的 KV 计算完成后立即发送，后续计算继续执行，从而隐藏可重叠的网络延迟。
* **KV 缓存分级压缩**：近期 KV（如最后 1000 个词元）保留 FP16 精度用于生成的精确性，历史 KV 压缩为 INT8 或 FP8，进一步减少传输量。
* **前缀缓存预热**：离线预计算常见前缀（系统提示、热门文档）的 KV 缓存，缓存到 Decode 侧的专用缓存服务器，新请求只需传输增量部分。

Mooncake、DistServe 和 DeepSeek 的内部基础设施均采用了这一架构方向，但收益是 workload-specific 的：它依赖输入/输出长度分布、RDMA/NVLink 带宽、并行传输能力、前缀/语义缓存命中率以及 KV 压缩策略。配置得当时，分离式架构可以提升复杂生产负载的整体吞吐并降低 Decode 侧 TPOT；配置不当时，KV 传输和调度开销会吞掉收益。这一创新标志着 LLM 推理系统正逐步演进为类似微服务架构的分布式系统。

## 11.3.3 条件分离式推理

在实际生产流量中，并非所有请求都适合分离式处理。**条件分离**（Conditional Disaggregation）是一种更智能的策略：请求首先到达一个**智能网关**（AI Gateway），由其根据请求特征动态决定路由：

**触发分离的条件**：

* 输入序列长度 > 某阈值（如 2000 词元）
* 输入序列未命中前缀缓存
* 当前 Decode 集群的 KV 缓存占用率 > 80%（表示单体处理可能导致尾延迟上升）

**不分离的情况**：

* 输入已完全缓存（直接在 Decode 侧快速路径）
* 输入超短（< 100 词元），Prefill 开销可忽略
* Prefill 集群负载饱和（避免级联延迟）

条件分离相比固定分离更适合真实世界的混合流量模式，可根据负载动态调整，避免短请求的分离开销，同时保护长请求的 TPOT。DistServe 证明了 Prefill/Decode 分离在特定 SLO 和流量分布下的 goodput 收益；条件分离则更接近 NVIDIA Dynamo 等生产系统中的路由策略。两者不能混成一个固定的 P99 百分比结论，实际尾延迟收益必须按请求长度分布、网络和缓存命中率评测。

## 11.3.4 专家并行：MoE 模型的分布式推理

**混合专家**（Mixture-of-Experts，MoE）模型如 DeepSeek-V3（671B，37B active）的推理需要专门的分布式策略。与标准密集模型不同，MoE 模型中只有路由到特定专家的词元会激活对应的参数。这使得**专家并行**（Expert Parallelism，EP）成为一种高效的分布式方案：

**策略对比**：

| 并行方式          | 适用模型   | 通信方式             | 通信成本                                           | 适用场景                     |
| ------------- | ------ | ---------------- | ---------------------------------------------- | ------------------------ |
| **张量并行**（TP）  | 密集模型   | NVLink/GPU 间     | 在每个 Transformer 层内反复通信                         | 单节点或少数节点（低延迟网络）          |
| **流水线并行**（PP） | 密集模型   | RDMA（跨节点）        | 在层间通信，可异步                                      | 多节点密集模型                  |
| **序列并行**（SP）  | 长上下文   | NVLink + RDMA    | Ring Attention 通过块级 KV 环传扩展序列长度，稠密注意力计算仍为二次复杂度 | 1M+ 词元上下文                |
| **专家并行**（EP）  | MoE 模型 | RDMA（All-to-All） | 词元级 All-to-All（词元数相关）                          | MoE 模型的 Prefill 和 Decode |

在 EP 中，每张 GPU 持有部分专家的全部参数。每个词元根据路由器的决策被发送到对应的专家 GPU，经过专家层后再汇总。以 DeepSeek-V3 为例，模型约 671B 总参数、每词元激活约 37B 参数；配置中包含 256 个路由专家、1 个共享专家，每词元激活 8 个路由专家。专家并行要处理的不是“37 个专家”，而是路由后的专家参数和词元重分发。**All-to-All 通信**是 EP 的性能瓶颈——不同 GPU 上的词元需要重新分配到各自的目标专家，要求高速的点对点通信能力。这是为什么 DeepSeek 等大规模 MoE 部署依赖 RDMA 网络而非简单以太网的原因。

在分离式架构下，Prefill 和 Decode 的词元分布不同——Prefill 中许多词元可能被路由到相同的专家组合，而 Decode 中每个词元都独立决策，All-to-All 通信模式差异大。某些先进部署会对 Prefill 和 Decode 的 EP 并行度进行分别优化。

分离式架构的另一个优势是可以对 Prefill 和 Decode 引擎进行独立优化，这称为**异构张量并行**（Heterogeneous Tensor Parallelism）。例如，计算密集型的 Prefill 引擎可以使用较低的张量并行度（TP=2 或 4）：足够长的 Prompt 在低 TP 下即可让算力饱和，继续加大 TP 对时延的边际收益递减，反而徒增 GPU 间通信开销；而访存密集型的 Decode 引擎则需要较高的 TP（TP=8 或更高），在单卡显存瓶颈下分散模型权重，增加可服务的并发度。这样在相同硬件上可获得更优的整体效率——Prefill 侧吞吐，Decode 侧低延迟。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/llm_internals/di-san-bu-fen-tui-li-yu-bu-shu-pian/11_serving/11.3_disaggregated_serving.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.