企业官网建设流程全解析

PD 分离架构深度解析：大模型推理如何从"单体"走向"分体"


2026 年 8 月，由开源推理引擎 SGLang 孵化的 RadixArk 官宣完成超 1 亿美元种子轮融资；同月，AI 推理平台 Baseten 估值从 21 亿美元飙升至 130 亿美元，Fireworks 在 7 个月内估值翻 4 倍达到 175 亿美元。当大模型竞赛从"训练"全面转向"推理"与"部署"，一个底层架构正在被重新设计——它就是 PD 分离（Prefill/Decode Disaggregation，Prefill/Decode 分离）。

一、为什么推理会"卡"？先理解 Prefill 与 Decode

大模型"生成一句话"看似一气呵成，实际上包含两个资源特征截然不同的阶段：

• **Prefill（预填充）**：一次性并行处理全部输入 Token，构建 KV Cache。它是高并行度的矩阵乘法，属于**计算密集型**（Compute-bound）任务，追求吞吐，算力利用率越高越好。

• **Decode（解码）**：基于 KV Cache 逐 Token 生成输出，每一步都要读写整段 KV Cache，属于**内存带宽密集型**（Memory-bound）任务，对延迟极其敏感，用户感知的"打字速度"就取决于它。

传统单体架构把两个阶段放在同一批 GPU 上混跑，问题随之而来：长 Prompt 的 Prefill 会瞬间吃满计算单元，正在逐字生成的短请求被迫"陪跑"；反过来，Decode 的高频小步迭代又会拖慢 Prefill 的吞吐。两类负载互相踩脚的结果是，GPU 的算力与带宽永远无法同时跑满——计算密集的时候带宽闲置，带宽密集的时候算力闲置。

二、为什么是现在：推理优化成为 2026 年主战场

这一轮 PD 分离热并非偶然，而是模型竞赛重心转移的必然结果：

• **资本用脚投票**：AI 推理平台 Baseten 估值从 21 亿美元暴涨至 130 亿美元、年收入增长 20 倍；Fireworks 在 7 个月内估值翻 4 倍达到 175 亿美元、年化营收突破 10 亿美元。2026 年 8 月，由开源推理引擎 SGLang 孵化的 RadixArk 正式亮相，宣布完成超 1 亿美元种子轮融资，并推出开源后训练框架 Miles——把训练与推理放进同一套系统统一调度，让 SGLang 在推理端持续产出高质量思维链样本、Miles 在训练端实时更新权重，消除阶段切换的等待损耗。

• **推理引擎三年三级跳**：早期的静态 Batching 像"排队打饭"，一个算完才轮到下一个；Continuous Batching（连续批处理）让 GPU 变成"随时上下客的公交"，吞吐提升 2~4 倍；而 PD 分离则是在此之上的第三次跃迁——不再把 Prefill 和 Decode 塞在同一张卡上互相拖累。

• **头部玩家全部入局**：DeepSeek 用 32 张 GPU 组成 Prefill 最优单元专门处理输入，一旦开始逐字回答，就通过高速网络把任务交给专门的 Decode 卡集群；月之暗面 Kimi、NVIDIA Dynamo 框架、SGLang、vLLM 均已落地或原生支持 PD 分离。国内方面，京算"Token 工厂"、趋境科技、中昊芯英"须臾"TPU 也都在 2026 年 7 月密集发布了 PD 分离相关实践。

三、PD 分离：把两种负载拆到不同的 GPU 池

PD 分离的核心思想非常朴素：既然 Prefill 吃算力、Decode 吃带宽，那就把它们分别部署到特性不同的硬件上，各自独立调度。

• **Prefill 池**：由高性能 GPU 组成，专注快速"吞下"输入，产出 KV Cache；

• **Decode 池**：由高带宽、更经济的 GPU 组成，专注逐 Token 生成；

• 中间通过高速网络（RDMA/InfiniBand）把 KV Cache 从 Prefill 节点"交接"给 Decode 节点。

两个池可以独立扩缩容：聊天场景输出长、输入短，就多配 Decode 卡；文档分析场景输入长，就多配 Prefill 卡。DeepSeek 在生产环境中正是用 H800 80GB 做 Prefill 节点、用更便宜的 L40S 做 Decode 节点，实现成本的差异化配置。据 NVIDIA、超擎数智等联合测试，PD 分离可让 Token 吞吐提升 2~3 倍、推理硬件成本下降 30%~50%。

四、代码实践：一个最小的 PD 分离服务

下面这段代码（完整可运行）演示了 PD 分离的架构机制：请求先进 Prefill 池完成编码，KV Cache 交接后交给 Decode 池独立生成，两个池各自拥有独立的 worker 数量，天然支持异构扩缩容。

#!/usr/bin/env python3 """极简 PD 分离服务演示：Prefill 池与 Decode 池分离 + KV Cache 交接""" from dataclasses import dataclass, field from typing import Optional @dataclass class Job: """一个推理请求""" rid: int prompt: list[int] # 输入 token 序列 output: int # 要生成的 token 数 kv_cache: Optional[dict] = field(default=None, repr=False) class PrefillPool: """计算密集型：把整段 prompt 一次性编码为 KV Cache""" def __init__(self, n_workers: int): self.n_workers = n_workers def run(self, job: Job) -> None: # 真实场景里这里是高并行矩阵乘法；此处用 dict 模拟 KV Cache job.kv_cache = {"K": [f"k{i}" for i in job.prompt], "V": [f"v{i}" for i in job.prompt]} print(f" [Prefill] req#{job.rid} 编码 {len(job.prompt)} token → KV Cache 就绪") class DecodePool: """带宽密集型：逐 token 生成，每一步都要读完整 KV Cache""" def __init__(self, n_workers: int): self.n_workers = n_workers def run(self, job: Job) -> list[str]: assert job.kv_cache is not None, "KV Cache 尚未由 Prefill 池产出" out = [] for i in range(job.output): # 模拟注意力：读一遍 KV（内存带宽占用），再吐 1 个 token _ = sum(len(v) for v in job.kv_cache["V"]) out.append(f"tok_{i}") print(f" [Decode] req#{job.rid} 生成 {len(out)} token") return out class PDServer: """PD 分离调度：请求先进 Prefill 池，KV 交接后交给 Decode 池""" def __init__(self, prefill_workers: int = 2, decode_workers: int = 4): self.pool_p = PrefillPool(prefill_workers) self.pool_d = DecodePool(decode_workers) self.kv_ready: list[Job] = [] # KV 交接区 def handle(self, job: Job) -> None: print(f"收到 req#{job.rid} (prompt={len(job.prompt)}, output={job.output})") self.pool_p.run(job) # ① Prefill 池处理 self.kv_ready.append(job) # ② KV Cache 通过高速网络交接 self.pool_d.run(job) # ③ Decode 池独立消费 if __name__ == "__main__": server = PDServer(prefill_workers=2, decode_workers=4) jobs = [Job(rid=1, prompt=[7] * 200, output=50), # 文档分析：长入短出 Job(rid=2, prompt=[9] * 30, output=120), # 聊天：短入长出 Job(rid=3, prompt=[3, 1, 4] * 40, output=30)] for j in jobs: server.handle(j)

运行结果如下，可以看到每个请求都走完了"Prefill 编码 → KV 交接 → Decode 生成"的完整流水：

收到 req#1 (prompt=200, output=50) [Prefill] req#1 编码 200 token → KV Cache 就绪 [Decode] req#1 生成 50 token 收到 req#2 (prompt=30, output=120) [Prefill] req#2 编码 30 token → KV Cache 就绪 [Decode] req#2 生成 120 token 收到 req#3 (prompt=120, output=30) [Prefill] req#3 编码 120 token → KV Cache 就绪 [Decode] req#3 生成 30 token

五、工程落地：绕不开的 KV Cache 传输与两层调度

PD 分离不是把机器拆开就完事，真正的难点在调度与传输：

1.两层调度：第一层是全局请求分发层，用一致性哈希把请求映射到 Prefill 组；第二层是 Prefill 组内的细粒度负载均衡。Kimi、DeepSeek 的推理平台均采用类似设计。

2.KV Cache 压缩与传输：KV Cache 体积与上下文长度成正比，跨节点传输会带来额外延迟。主流解法包括：MLA（Multi-head Latent Attention）把 KV 压缩到传统 MHA 的 1/8；Chunked Prefill 边算边传，让 Decode 尽早开始；KV Cache Offload 把冷数据放到 CPU/SSD，腾出显存支持更多并发。

3.Continuous Batching 仍是地基：PD 分离是在连续批处理之上的架构演进，两者是叠加关系而非替代关系。NVIDIA Dynamo、SGLang、vLLM 等框架已原生支持 PD 分离，建议从成熟框架起步而非自研。

部署侧的一个示意（不同硬件规格拆分两个池）：

# 示意：将异构 GPU 拆分到两个池（以 SGLang Router 为例，参数以实际版本为准） # Prefill 池：4 × 高性能计算卡，负责长 Prompt 编码 sglang.launch_server --model-path Qwen/Qwen2.5-72B-Instruct \ --dp 4 --role prefill --port 30000 # Decode 池：8 × 高带宽经济卡，负责逐 Token 生成 sglang.launch_server --model-path Qwen/Qwen2.5-72B-Instruct \ --dp 8 --role decode --port 30001 # 路由层：一致性哈希分发 + KV 交接 sglang.launch_server --router-only --prefill-port 30000 --decode-port 30001

六、挑战与选型建议

• 日请求量百万级以上的推理服务，PD 分离几乎是必选项；小规模单机部署反而会因网络开销得不偿失。

• 底层硬件的异构性与软件栈不兼容，是当前最大的工程挑战，也是"京算 Token 工厂"等国产算力平台着力攻克的难点。

• 关注 2026 年 WAIC 上中昊芯英"须臾"TPU 等原生适配 PD 分离调度芯片的进展，硬件与框架协同优化正在成为新趋势。

总结

从 vLLM 解决"跑得起来"，到 PD 分离解决"跑得经济"，大模型推理正在从"单体黑盒"走向"可编排的分布式服务"。理解了 Prefill 与 Decode 的资源差异，你就抓住了 2026 年推理优化这条主线的钥匙——算力很贵，把每一分钱花在刀刃上，才是这个时代真正的工程智慧。