推理 INFRA 方法论（6）：PD 与 EPD：阶段分离、状态传输与资源配比

将编码、Prefill 与 Decode 分开建模，核算 embedding 和 KV 的传输成本，并用目标 SLO 推导资源配比与准入策略。

本文为「推理 INFRA 方法论」系列第 7/8 篇。发布日期按 2026 年 1–11 月编排；内容统一整理于 2026-11-01，包含年内后续更新的模型与实验资料。

Prefill/Decode区别

ViT / LLM-Prefill / LLM-Decode 区别

KV-Cache 传输:方案与时延

时延优化三板斧（降低暴露在关键路径上的传输时间）：

1
2
3

① layer-wise:算完第 i 层就传,与后续层计算 overlap；实际暴露量取决于流水与链路
② 首 token P 侧 sample:减少等待，但 TTFT 仍可能包含最后一段 KV 传输
③ GPUDirect + NIC 亲和绑定:绕 CPU bounce(有效带宽 8→20GB/s)

H20 两机实测(sglang 0.5.22 + Mooncake,Qwen3-32B,KV 256 KB/token;P/D 都是 TP2,同 NUMA 网卡):

• 走 RDMA 时传输只暴露 0.7–6.5%;走 TCP 多 7–33%。长输入时 TCP 的大部分传输和 chunked prefill 计算重叠掉了(32K 理论约 2.6 s/rank,只暴露 0.63 s),短输入几乎全暴露。
• decode 第一步(第二个 token 间隔)三种方式都是 12–15 ms,没有因为等 KV 变长;TTFT 里仍含最后一段 KV 的传输。
• TP 不一致(P TP4 → D TP2):不开 staging 比同构 TP4→TP4 多 10–52%,开 SGLANG_DISAGG_STAGING_BUFFER=1 后只多 1.4–6%。
• 亲和:Mooncake GPU→GPU 写单网卡 48.9 GB/s,GPU 跨 NUMA 配对时减半到 24 GB/s。

为什么要分离,还要看插入长 prefill 时 decode 的抖动。实测(16 路 decode 并发,每 6 秒插入一个 16K prefill):同卡混部 decode ITL 的 P99/P50 为 27×(默认 chunk)、48×(mixed-chunk 2048)、13×(mixed-chunk 512,但只要有 chunk 在跑,每个 decode step 都要约 180 ms,16K prefill 也慢 9%);PD 是 1.23×(P99 17.4 ms)。本次较小 chunk 降低了最坏停顿，但仍有 decode 延迟与 prefill 效率的取舍；PD 用独立资源隔离两类负载。

异构 KV、前缀复用与分层缓存

按“每层每 token 同样大小”分配一个统一 KV 池，无法充分表达混合注意力。应按类型区分变长 KV、循环状态、滑窗、压缩块及未压缩尾部，并让传输元数据包含类型、位置、head/TP 归属与目标 offset。

前缀缓存收益取决于完整状态是否可恢复，不直接按“15/60 层”乘成固定 1/4。分层缓存由 GPU → CPU → NVMe 扩展容量；是否读回按 查找+排队+搬运+布局恢复 < 重算该前缀的时间 判断，并计入对在线请求带宽的争用。长上下文通常更值得复用，但小请求未必值得多一跳。

SLO 驱动的配比和准入

目标是最大化满足 TTFT/ITL 分位 SLO 的吞吐，先明确分位与测量窗口，再对 batch、上下文和负载扫描；平均 TPOT 不能代替 P99 ITL。

1
2
3

TTFT = 排队 + 编码 + prefill + 暴露的 KV 传输 + 首 token 输出
n_P : n_D = (平均输入 token / 单 P 实例 prefill tok/s)
          : (平均输出 token / 单 D 实例 decode tok/s)

这里的吞吐必须在目标 SLO、真实长度分布下测得；缓存命中按实际省下的 prefill 工作量折算。长输入和长输出业务会把配比推向不同方向，不保留固定“RAG 40:1、Agent 1:13”的通用结论。路由先排除内存或预计尾延迟越界的实例，再综合前缀命中、队列长度、KV 占用和 SLO 余量；实时、交互与批处理可分池服务。

PD 实测使用混部 2 卡、分离 2P+2D 卡：P99/P50 从 13–48 降到约 1.2 支持隔离减少抖动，但吞吐增加不能直接解释为同资源收益。P:D 比例未做扫描，MLA staging 路径也未做端到端验证。

Embedding传输

① Shape 与量的计算:

1
2
3
4

emb/图 = n_token × d × bpp
1080p（1920*1080） 图(Qwen-VL 系,28×28/token,不限像素)→ 2664 token × 7168 × 2B ≈ 37 MB/图
8 图请求 = 296 MB
⚠️ emb/token = d×2B = 14KB(d=7168)—— 没被压缩!

d 和 token 数都按模型及实际预处理输出取值：本次 Qwen3.5 的 d=4096，1024² 图产出 1026 token，emb 约 8.4 MB。图像缩放属于部署配置，不把特定单机策略推广成模型规律；EPD 对照应使用相同预处理和 token 工作量。KV 压缩不同时压缩 embedding，因此 E→P 与 P→D 的字节比例必须分别计算。

② 多图 overlap(流水化):

1
2
3
4
5
6
7
8
9
10
11

不流水(等全部编码完再 prefill):
E: [图1][图2][图3][图4][图5][图6][图7][图8]
P:                                         [────prefill 全部────]
                                           ↑ 干等 8×130ms = 1040ms
TTFT = 1040 + T_prefill

流水(编码 k 张就送去 prefill 一个 chunk):
E: [图1][图2][图3][图4][图5][图6][图7][图8]
P:      [chunk1][chunk2][chunk3][chunk4][chunk5][chunk6][chunk7]
              ↑ 只等前 k 张的编码时间
TTFT ≈ k×130ms + T_prefill_last_chunk

H20 实测(Qwen3.5-397B-FP8,语言模型 TP8;EPD 时 4 个 encoder-only 副本在另一台机器,Mooncake RDMA 传 emb):

本次 EPD 比混部增加 4 张 encoder 卡，结果用于解释阶段隔离收益，不代表固定资源下的加速。多图时空载降约 31%,负载下降 40–61%;单张图时 EPD 多了一跳远程编码,反而慢 10–68%,少量小图不值得拆。由混部空载估算,1024² 图的 ViT 约 70 ms/张(在 TP8 的 LLM 卡上)。

③ D2H/H2D 问题(跨进程/跨机时):

1
2
3
4
5
6
7
8

路径对比(37MB,H20 实测,PCIe Gen5):
  真走 pickle(dumps+shm+loads+H2D):45-61 ms
  预分配 shm + memcpy + H2D(不 pickle):~7.6 ms(预分配 pageable 13-16GB/s;每次新分配只有 ~3GB/s)
  pinned memory:                  D2H/H2D 各 ~0.7ms(54GB/s)
  ★ CUDA IPC 预注册 slab(同机): 跨卡 0.11 ms(NVLink 363GB/s),同卡 0.03 ms
  ★ GPUDirect RDMA(跨机):       GPU→NIC→GPU,不过 host;Mooncake 单网卡 ~49GB/s
原则:emb 永远不该以 CPU 内存为中转 —— pinned 是底线,IPC/GPUDirect 是正解
注意:IPC handle open 同卡 0.24ms、跨卡 ~0.8ms(首次 2.2ms)→ 必须启动时预注册 slab,运行时只传 offset

④ E/P/D 配比与通信机制设计:

1
2
3
4
5
6
7
8
9

配比 = 各级吞吐匹配:n_E : n_P : n_D = (负载/Thr_E) : (负载/Thr_P) : (负载/Thr_D)
   Thr_X = 单实例在 SLO 下的吞吐(图/s、prefill tok/s、decode tok/s),不是单请求耗时
   D 一次 batch 几百个请求,直接用单请求耗时比(如 E=1.04s / P=1.93s / D=8s)会把 D 高估一个量级

通信机制四原则(让配比收益能兑现):
① 异步 + 队列解耦:E→P 经 request queue,不做同步 RPC(否则 E 的抖动直接传导成 P 的气泡)
② 预注册传输资源:IPC slab / RDMA MR 启动时注册,运行时零 setup
③ batch 边界解耦:E 按图 batch、P 按 token batch,队列处重组,互不迁就
④ 反压:queue 深度做准入控制,防止 E 跑太快把 P 的显存灌爆

阶段隔离的收益必须覆盖交接成本

拆分部署既改变资源争用，也引入网络和状态交接。是否值得拆，要在相同输入、资源预算和延迟目标下比较；额外增加编码卡或 Decode 卡的实验，可以解释隔离效果，但不能直接证明同资源吞吐提升。

系列导航

上一篇：MoE 推理：Batch、DeepEP、DeepGEMM 与负载均衡 · 下一篇：核心优化：CUDA Graph、投机推理、Overlap 与量化