- 46 篇原文+摘要双文件归档(按 来源/作者 分层,复用本地归档 20 篇+新抓取 26 篇) - 即梦生成 9 组主题配图(大图+列表缩略图)存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
4.3 KiB
📊 文章摘要:LLM关于PD分离的最新实测
原文:2025-06-22_LLM关于PD分离的最新实测.md 原文链接:https://zhuanlan.zhihu.com/p/1919794916504114120 来源:知乎 作者:akaihaoshuai 发布日期:2025-06-22 摘要日期:2026-08-06 价值评级:⭐⭐⭐ 高
核心命题
实测边界 — 给出 PD 分离生效的量化阈值与工程落地经验,并指出其核心是 cache 调度。
文章概要
作者基于 vLLM/sglang 的 PD 分离实测,给出 9 条工程结论:PD 分离仅在超长上下文+大模型+高并发下收益明显(至少输入>8k、输出>100、并发>10、模型>32B),吞吐提升 20%~50%,且优化的是 TBT 而非 TTFT;P/D 配比 3P1D 较优、1P2D 更佳;prefill 可用 4090 这类"算力够、带宽差"的卡做异构部署。文章还逐一代码剖析了 SharedStorageConnector、P2pNcclConnector、LMCacheConnector、NixlConnector 与 sglang 的 PD 分离实现,并给出可直接复用的启动脚本。价值在于把 PD 分离从概念落实到"选型边界",并明确指出普通场景没必要折腾。
关键要点
- 收益有明确阈值 — 至少输入>8k、输出>100、并发>10、模型>32B 左右才有效果;超长上下文+大并发下 TBT 可保持稳定,吞吐提升 20%~50%
[分类: 共识] - PD 分离优化 TBT 而非 TTFT — 且 prefill 卡减少(如 TP2 变 1P1D)会导致大 bs、长输入时 TTFT 变长
[分类: 共识] - P/D 配比反直觉 — 2P2D 一般不太行、3P1D 差不多;因 prefill 只执行一次而 decode 要很多遍,1P2D 更能提升整体资源利用率
[分类: 争议] - 核心在于 cache 调度 — request 调度不能只考虑负载均衡,还要考虑 cache 复用率、显存剩余空间等
[分类: 共识] - 传输方式决定 TTFT 损耗 — GPU 传输(NCCL)最快、基本保持原 TTFT,CPU/disk 传输都会使 TTFT 变慢;NCCL 初始化即固定全部 GPU、不适合动态扩缩容,Mooncake 统一多种传输方式,Dynamo 重新封装 nixl 协议
[分类: 共识] - 异构框架最大化性价比 — 4090 算力约为 A/H 系列 30%~50% 但带宽不足 10%,非常适合 prefill 阶段;高带宽 GPU 做 decoding
[分类: 共识] - 分离后的固有资源短板 — Prefill server 带宽利用率低、decoder server GPU 利用率低,是 PD 分离需要接受的代价
[分类: 共识]
批判性分析
假设前提
假设读者具备 vLLM/sglang 使用经验;测试环境为作者自有的 GPU 集群,结论依赖具体模型(Qwen 系列)与负载形态,阈值未必能直接外推到其他硬件组合。
论据与逻辑
结论来自一手实测与源码阅读,可信度高;但未披露完整测试环境与数据细节,"20%~50%"为区间估计,缺少逐项实验数据表,难以复现验证。
边界与局限
作者明确给出适用边界——"能单卡跑的没必要多卡,能单机承载的没必要多机";结论在短上下文、小模型、低并发场景不适用,且 PD 分离本身会引入 P/D 两侧资源利用率失衡的新问题。
可引用金句
"PD分离的核心其实在于cache的调度。"
"能单卡跑的没必要多卡,能单机承载的没必要多机。"
总体评价
亮点:
- 9 条实测结论量化了收益边界,反直觉结论(1P2D 优于 2P2D)有工程指导价值
- 四种 KVConnector 的代码级对比透彻,启动脚本可直接复用
- 异构硬件(4090 做 prefill)观点对成本敏感团队极有参考价值
不足:
- 测试环境与数据细节披露不足,结论难以严格复现
- 对 sglang 与 Mooncake 的介绍偏向代码流程转述
- Dynamo/nixl 章节与"实测"主题关联度略松散
适用场景:推理服务工程师做 PD 分离技术选型与落地;需要判断"我的场景该不该上 PD 分离"的团队;预算有限、考虑异构卡部署的团队。
关联建议:结合极客博哥《LLM PD 分离背后的架构问题》对照架构决策维度;阅读 Mooncake 论文与 vLLM disaggregated serving 官方文档;跟踪 Dynamo 框架演进。
