PD 分离架构深度解析大模型推理如何从单体走向分体2026 年 8 月由开源推理引擎 SGLang 孵化的 RadixArk 官宣完成超 1 亿美元种子轮融资同月AI 推理平台 Baseten 估值从 21 亿美元飙升至 130 亿美元Fireworks 在 7 个月内估值翻 4 倍达到 175 亿美元。当大模型竞赛从训练全面转向推理与部署一个底层架构正在被重新设计——它就是 PD 分离Prefill/Decode DisaggregationPrefill/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(defaultNone, reprFalse) 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: [fk{i} for i in job.prompt], V: [fv{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(ftok_{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_workers2, decode_workers4) jobs [Job(rid1, prompt[7] * 200, output50), # 文档分析长入短出 Job(rid2, prompt[9] * 30, output120), # 聊天短入长出 Job(rid3, prompt[3, 1, 4] * 40, output30)] for j in jobs: server.handle(j)运行结果如下可以看到每个请求都走完了Prefill 编码 → KV 交接 → Decode 生成的完整流水收到 req#1 (prompt200, output50) [Prefill] req#1 编码 200 token → KV Cache 就绪 [Decode] req#1 生成 50 token 收到 req#2 (prompt30, output120) [Prefill] req#2 编码 30 token → KV Cache 就绪 [Decode] req#2 生成 120 token 收到 req#3 (prompt120, output30) [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 体积与上下文长度成正比跨节点传输会带来额外延迟。主流解法包括MLAMulti-head Latent Attention把 KV 压缩到传统 MHA 的 1/8Chunked 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 年推理优化这条主线的钥匙——算力很贵把每一分钱花在刀刃上才是这个时代真正的工程智慧。
PD 分离架构深度解析大模型推理如何从单体走向分体2026 年 8 月由开源推理引擎 SGLang 孵化的 RadixArk 官宣完成超 1 亿美元种子轮融资同月AI 推理平台 Baseten 估值从 21 亿美元飙升至 130 亿美元Fireworks 在 7 个月内估值翻 4 倍达到 175 亿美元。当大模型竞赛从训练全面转向推理与部署一个底层架构正在被重新设计——它就是 PD 分离Prefill/Decode DisaggregationPrefill/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(defaultNone, reprFalse) 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: [fk{i} for i in job.prompt], V: [fv{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(ftok_{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_workers2, decode_workers4) jobs [Job(rid1, prompt[7] * 200, output50), # 文档分析长入短出 Job(rid2, prompt[9] * 30, output120), # 聊天短入长出 Job(rid3, prompt[3, 1, 4] * 40, output30)] for j in jobs: server.handle(j)运行结果如下可以看到每个请求都走完了Prefill 编码 → KV 交接 → Decode 生成的完整流水收到 req#1 (prompt200, output50) [Prefill] req#1 编码 200 token → KV Cache 就绪 [Decode] req#1 生成 50 token 收到 req#2 (prompt30, output120) [Prefill] req#2 编码 30 token → KV Cache 就绪 [Decode] req#2 生成 120 token 收到 req#3 (prompt120, output30) [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 体积与上下文长度成正比跨节点传输会带来额外延迟。主流解法包括MLAMulti-head Latent Attention把 KV 压缩到传统 MHA 的 1/8Chunked 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 年推理优化这条主线的钥匙——算力很贵把每一分钱花在刀刃上才是这个时代真正的工程智慧。
