博客Johney Zheng 的博客 · 全部文章索引 · 本文原文将编码、Prefill 与 Decode 分开建模核算 embedding 和 KV 的传输成本并用目标 SLO 推导资源配比与准入策略。Prefill/Decode区别阶段瓶颈类型推荐硬件最优 batch并行策略Prefill预填充算力瓶颈AI~s 数千算力卡 (H800/950PR)小单序列已饱和TP/PPchunk 当 micro-batch、DeepEPnormal, contiguous GEMM等Decode解码带宽瓶颈B~几十高显存带宽设备大受 SLO 和 C(B) 约束见第五章DP-attnEP、DeepEPlow-latency、masked GEMMSLO 看 TPOTP99等ViT / LLM-Prefill / LLM-Decode 区别ViTLLM-PLLM-D瓶颈算力 小算子launch算力带宽状态无状态→ 瞬时扩缩、可放廉价卡(L20,成本 1/5)KV 生产者KV 消费者负载方差多图可dp10×3-5×KV-Cache 传输:方案与时延场景方案关键点TP_p TP_d(同构)rank-i → rank-i 直传布局对齐,SGLang 自动 bypass stagingTP_p ≠ TP_d(异构)per-worker gatherpermute → staging buffer → bulk RDMA → 对端 scatterhead 维按路由表合并/拆分;token 维消 block 碎片;比 per-token slice 快2-5×;绝不 rank0 集中(只用 1 张网卡)MLA直传,不开 staginglatent 全头共享,head 维免疫(token 维碎片仍在)目标 block 就位D 预分配 block_table 预注册 pool,P 用RDMA 写偏移直落多 P rank 并发写同一 D buffer 不同 offset → concat 被消掉时延优化三板斧降低暴露在关键路径上的传输时间① layer-wise:算完第 i 层就传,与后续层计算 overlap实际暴露量取决于流水与链路 ② 首 token P 侧 sample:减少等待但 TTFT 仍可能包含最后一段 KV 传输 ③ GPUDirect NIC 亲和绑定:绕 CPU bounce(有效带宽 8→20GB/s)双机实测(sglang 0.5.22 Mooncake,Qwen3-32B,KV 256 KB/token;P/D 都是 TP2,同 NUMA 网卡):输入同卡混部 TTFTPD RDMAPD TCP(mooncake_tcp)1K261 ms278(17)358(97)4K10521088(36)1401(349)16K48604927(67)5584(724)32K1127411357(83)11908(634)走 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_BUFFER1后只多 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。对象分配与复用原则标准 KVpaged block 管理前缀按 token/位置及模型版本复用GDN 循环状态只能恢复已保存的前缀 checkpoint不能从最终状态截断出任意历史状态CSA/HCA 压缩 KV同时记录已完成压缩块和未完成 tail交接时保留压缩边界SWA / indexer分别维护滑窗生命周期与索引数据不能只搬 latent 就宣称状态完整前缀缓存收益取决于完整状态是否可恢复不直接按“15/60 层”乘成固定 1/4。分层缓存由 GPU → CPU → NVMe 扩展容量是否读回按查找排队搬运布局恢复 重算该前缀的时间判断并计入对在线请求带宽的争用。长上下文通常更值得复用但小请求未必值得多一跳。SLO 驱动的配比和准入目标是最大化满足 TTFT/ITL 分位 SLO 的吞吐先明确分位与测量窗口再对 batch、上下文和负载扫描平均 TPOT 不能代替 P99 ITL。TTFT 排队 编码 prefill 暴露的 KV 传输 首 token 输出 n_P : n_D (平均输入 token / 单 P 实例 prefill tok/s) : (平均输出 token / 单 D 实例 decode tok/s)这里的吞吐必须在目标 SLO、真实长度分布下测得缓存命中按实际省下的 prefill 工作量折算。输入与输出的长度分布会直接改变所需配比。路由先排除内存或预计尾延迟越界的实例再综合前缀命中、队列长度、KV 占用和 SLO 余量实时、交互与批处理可分池服务。这组 PD 对比中混部使用 2 卡分离使用 2P2D 卡P99/P50 从 13–48 降至约 1.2。两组资源不同主要用于观察长 prefill 对 decode 抖动的影响。Embedding传输① Shape 与量的计算:emb/图 n_token × d × bpp 1080p1920*1080 图(Qwen-VL 系,28×28/token,不限像素)→ 2664 token × 7168 × 2B ≈ 37 MB/图 8 图请求 296 MB ⚠️ emb/token d×2B 14KB(d7168)—— 没被压缩!d 和 token 数都按模型及实际预处理输出取值本次 Qwen3.5 的 d40961024² 图产出 1026 tokenemb 约 8.4 MB。比较 EPD 时应保持图像预处理与 token 工作量一致。KV 压缩不同时压缩 embedding因此 E→P 与 P→D 的字节比例必须分别计算。② 多图 overlap(流水化):不流水(等全部编码完再 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实测(Qwen3.5-397B-FP8,语言模型 TP8;EPD 时 4 个 encoder-only 副本在另一台机器,Mooncake RDMA 传 emb):请求混部空载EPD 空载混部负载(12 请求突发)EPD 负载448² × 8319 ms168(−47%)1097515(−53%)1024² × 1168185(10%)590351(−40%)1024² × 4456314(−31%)26791322(−51%)1024² × 8879605(−31%)51742913(−44%)本次 EPD 比混部增加 4 张 encoder 卡结果用于解释阶段隔离收益不代表固定资源下的加速。多图时空载降约 31%,负载下降 40–61%;单张图时 EPD 多了一跳远程编码,反而慢 10–68%,少量小图不值得拆。由混部空载估算,1024² 图的 ViT 约 70 ms/张(在 TP8 的 LLM 卡上)。③ D2H/H2D 问题(跨进程/跨机时):路径对比(37MB,实测,PCIe Gen5): 真走 pickle(dumpsshmloadsH2D):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 配比与通信机制设计:配比 各级吞吐匹配:n_E : n_P : n_D (负载/Thr_E) : (负载/Thr_P) : (负载/Thr_D) Thr_X 单实例在 SLO 下的吞吐(图/s、prefill tok/s、decode tok/s),不是单请求耗时 D 一次 batch 几百个请求,直接用单请求耗时比(如 E1.04s / P1.93s / D8s)会把 D 高估一个量级 通信机制四原则(让配比收益能兑现): ① 异步 队列解耦:E→P 经 request queue,不做同步 RPC(否则 E 的抖动直接传导成 P 的气泡) ② 预注册传输资源:IPC slab / RDMA MR 启动时注册,运行时零 setup ③ batch 边界解耦:E 按图 batch、P 按 token batch,队列处重组,互不迁就 ④ 反压:queue 深度做准入控制,防止 E 跑太快把 P 的显存灌爆系列导航章节文章编排日期0Roofline用算力与带宽建立性能预算2026-01-011通信模型从集合原语到跨机拓扑2026-02-132分布式推理TP、DP、EP、CP 与 PP 的取舍2026-03-293推理硬件GPU、NPU 与存储层级2026-05-114Attention 演变从 GQA、MLA 到混合状态2026-06-245MoE 推理Batch、DeepEP、DeepGEMM 与负载均衡2026-08-066PD 与 EPD阶段分离、状态传输与资源配比本篇2026-09-197核心优化CUDA Graph、投机推理、Overlap 与量化2026-11-01上一篇MoE 推理Batch、DeepEP、DeepGEMM 与负载均衡 · 下一篇核心优化CUDA Graph、投机推理、Overlap 与量化