# PD(预处理/解码)分离架构

“1P1D”是部署大语言模型（LLM）时，**“预填充-解码分离”（P/D Disaggregation）架构**中最基础的一种部署形态。它是一种“以空间换时间、以网络换效率”的部署策略。

简单来说，它指的就是**用1个节点专门负责“预填充”（Prefill），用另外1个节点专门负责“解码”（Decode）**。

## 🧐 为什么要搞“1P1D”分离？

要理解1P1D，需要先理解为什么要把模型的推理过程拆开。大模型生成一个回答，在内部经历了两个完全不同性质的阶段：

| 阶段 | 任务 | 特点与瓶颈 |
| **预填充 (Prefill)** | 读取并理解你输入的整个问题（Prompt）。 | **计算密集型**，需要强大的算力快速处理大量文本，像GPU这样的处理器擅长于此。 |
| **解码 (Decode)** | 逐字生成回答的Token，直到结束。 | **内存带宽密集型**，这个过程受限于从内存中读取数据的速度，并且非常依赖**KV缓存**。 |

当这两个阶段挤在同一个GPU上时，它们会互相争抢资源。最典型的问题是，一个超长文本的“预填充”计算，可能会阻塞其他用户的“解码”生成，导致所有用户的体验都变卡顿，这种现象被称为队头阻塞（Head-of-Line Blocking）。


**“1P1D”的核心思想，就是把这“一读”和“一写”两个阶段，放到两台独立的机器（或GPU）上跑，让它们各司其职，互不干扰。**

## 🔧 “1P1D”是如何工作的？

整个过程就像一条高效的流水线，主要涉及三个角色：

1.  **“代理人”（Proxy Server）**：作为统一入口接收所有用户请求。
2.  **“阅读理解员”（Prefill Server）**：有且仅有1个。
3.  **“写作快手”（Decode Server）**：有且仅有1个。

**工作流程如下：**

1.  用户的请求先发给**Proxy**。
2.  **Proxy**将请求路由给唯一的**Prefill Server**。
3.  **Prefill Server**快速处理完整个问题（预填充），生成关键的**KV缓存**，然后通过高速网络（如RDMA）将这份“记忆”直接传递给**Decode Server**。
4.  **Decode Server**拿到“记忆”后，开始逐字生成回答，并将生成的文本通过**Proxy**返回给用户。

## ⚖️ 1P1D的优势与适用场景

*   **主要优势**：将“读”和“写”分开，消除了两者间的资源争抢，提升了整体吞吐量，并让资源可以独立优化。比如，你可以给预填充节点配置高算力的卡，给解码节点配置内存带宽高的卡。
*   **适用场景**：适合作为入门或概念验证。当你的业务负载中，输入和输出的文本量都比较大且均衡时，1P1D是一个很好的起点。

## 💡 从1P1D看更大的世界

“1P1D”中的“1P”和“1D”分别代表**1个预填充实例**和**1个解码实例**。理解了它，你就能轻松看懂其他类似术语：

*   **2P1D**：2个预填充实例 + 1个解码实例。适合输入（问题）普遍超长，需要更多计算资源来“阅读理解”的场景。

*   **1P2D**：1个预填充实例 + 2个解码实例。适合输出（回答）很长或并发用户很多，需要更多资源来“写作”的场景。