文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,84 @@
|
||||
# LLM 做 PD 分离后，怎么更慢了？
|
||||
|
||||
> **来源**：微信公众平台（丁师兄）
|
||||
> **作者**：丁师兄（专注于智能驾驶大模型，LLM 面试干货分享）
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/0HlmtIuPGU7QE5r1fyhcsA
|
||||
|
||||
> 面试题视角：PD分离实际落地会遇到什么问题。从"代价/坑"的角度讲 PD分离的 5 大问题——KV Cache 传输开销、生产者-消费者不平衡、调度复杂度、显存压力与碎片化、P:D 比例敏感性。与只讲红利的文章形成互补。
|
||||
|
||||
---
|
||||
|
||||
> 编者按（丁师兄）：前不久有个学员面试完回来说，面试官问"PD 分离听起来挺好的，那你说说实际落地会遇到什么问题？"他当时愣了一下，只答出了网络传输这一点。这道题考的就是你有没有真正理解过生产环境的复杂性。PD 分离现在是个热门话题，vLLM、SGLang 都在推，Meta 和 Kimi 也在用，但真要把它跑起来，坑可不少。
|
||||
|
||||
## 01 先理解 PD 分离在解决什么
|
||||
|
||||
LLM 推理分两个阶段：Prefill 阶段是计算密集型的，把整个 prompt 并行处理完，生成 KV Cache；Decode 阶段是内存密集型的，逐个 token 串行生成，频繁读写 KV Cache。这两个阶段的资源需求完全相反，混在一起跑会互相干扰。
|
||||
|
||||
所以 PD 分离就是把这两个阶段拆到不同的 GPU 上去执行。Prefill 用高算力卡，Decode 用高带宽卡，听起来很美好对吧？但工业界真正落地的时候，问题就来了。
|
||||
|
||||
## 02 第一个大坑：KV Cache 传输开销
|
||||
|
||||
最核心的问题——KV Cache 的传输成本。Prefill 阶段算完之后，得把整个 KV Cache 传给 Decode 阶段。
|
||||
|
||||
拿 **Llama-3.1-70B** 举例，一个请求的 KV Cache 大概是 **1.34GB**。这是单个请求。如果 TTFT 要求 500ms 以内，Prefill 本身可能就要 200ms，留给传输的时间只有 300ms 左右。
|
||||
|
||||
这时候网络就成了瓶颈：
|
||||
- **10GbE**：传这 1.34GB 要 1 秒多，根本不够用；
|
||||
- **25GbE**：勉强 400 多毫秒，也很紧张；
|
||||
- **InfiniBand HDR 或 NVLink**：才能压到几十毫秒甚至几毫秒。
|
||||
|
||||
如果传输开销超过了分离带来的性能收益，整个架构就白搭了。这就是为什么 PD 分离必须要有高速互联网络支持，不是随便拿几台机器就能做的。Meta、Kimi 在生产环境用的都是专门的高速网络，这个成本不低。
|
||||
|
||||
## 03 第二个问题：生产者-消费者不平衡
|
||||
|
||||
Prefill 和 Decode 之间的负载不均衡，取决于工作负载特征：
|
||||
|
||||
- **短 prompt、长输出**（用户问一句，模型生成一大段）：Decode 压力大，需要 **1P3D**；
|
||||
- **长上下文**（文档总结、代码分析，prompt 几千 token，输出不长）：Prefill 成瓶颈，反过来配 **3P1D**。
|
||||
|
||||
问题在于真实业务流量是动态变化的——上午都是短问答，下午突然来一批长文档处理。如果 P:D 比例是静态配置的，就会出现一边资源闲置、另一边排队等待。这就需要动态调度和弹性伸缩，但又增加了系统复杂度。
|
||||
|
||||
有篇论文专门研究了这个，发现当 Prompt/Output 比例变化时，不同 P:D 配置的性能曲线会交叉——没有一个万能配置，必须根据实际 workload 调整。
|
||||
|
||||
## 04 第三个问题：调度复杂度飙升
|
||||
|
||||
传统架构里调度器只管一个队列。PD 分离之后调度逻辑复杂多了：
|
||||
|
||||
调度器要实时决策：请求分配给哪个 Prefill 实例？Prefill 完成后 KV Cache 传给哪个 Decode 实例？要考虑各节点负载、显存剩余、KV Cache 复用率、网络拓扑等。
|
||||
|
||||
更麻烦的是 Prefill 和 Decode 的协调：Prefill 做完了 Decode 还在忙，KV Cache 传不过去只能等；或者 Decode 空闲了 Prefill 还没准备好，又是浪费。这种生产者-消费者同步问题，在高并发场景下特别容易出现气泡（资源利用率的空洞）。
|
||||
|
||||
DistServe 和 Mooncake 设计了非常复杂的调度算法。Mooncake 甚至搞了三层架构：Prefill 集群、Decode 集群，还有专门的 Caching 集群管理 KV Cache——这个复杂度对小团队维护成本很高。
|
||||
|
||||
## 05 第四个问题：显存压力和碎片化
|
||||
|
||||
Prefill 阶段可能同时处理多个请求，每个都要生成 KV Cache，显存占用瞬间飙升。Decode 阶段更惨，要保留所有在生成中请求的完整 KV Cache，随生成长度增加 Cache 还在不断增长。
|
||||
|
||||
虽然有 PagedAttention 缓解碎片化，但 PD 分离后 KV Cache 的生命周期跨越两个不同节点，管理更复杂——要确保 Prefill 生成的 Cache 高效映射到 Decode 节点显存，还要处理释放和复用时机。管理不好会出现一边频繁 OOM、另一边大量闲置。
|
||||
|
||||
## 06 第五个问题：P:D 比例的敏感性
|
||||
|
||||
一篇 Medium 文章做了个实验，测试 1P3D、2P2D、3P1D 三种配置。结果发现性能曲线会随 Prompt/Output 比例变化而交叉——某个 workload 下最优的配置，换个 workload 可能变成最差。
|
||||
|
||||
本质是 Prefill 和 Decode 的瓶颈切换不是平滑的，而是突变的。workload 从 Decode 密集切换到 Prefill 密集时，系统性能可能断崖式下跌。所以真正做得好的系统需要实时监控 workload 特征、动态调整 P:D 比例——但这又回到调度复杂度问题，是个循环依赖。
|
||||
|
||||
> 从上图可以看出，PD 分离可以提高 decoding 部分的效率。但从 TP2 变成 1P1D，prefilling 的卡减少，大 bs、长输入时会导致 TTFT 变长。另外因为 prefill 的计算量大，decoder 阶段的传输量大，因此 PD 分离可以对两个阶段使用不同类型的显卡，最大化性价比。
|
||||
|
||||
## 07 总结
|
||||
|
||||
如果被问"PD 分离背后可能出现什么问题"，可以从这几个维度答：
|
||||
|
||||
1. **KV Cache 传输开销**（最核心）：强调网络带宽要求，算传输时间，说明为什么需要 InfiniBand 或 NVLink 级互联；
|
||||
2. **负载不均衡**：不同 workload 下 P:D 比例需求不同，静态配置导致资源浪费；
|
||||
3. **调度复杂度**：生产者-消费者同步、资源分配决策、气泡问题；
|
||||
4. **显存管理**：KV Cache 跨节点生命周期管理、碎片化、OOM 风险；
|
||||
5. **性能对 workload 敏感性**：没有万能配置，需要动态调整。
|
||||
|
||||
如果追问"怎么解决"，可以说业界方案：高速网络、智能调度算法、动态伸缩、KV Cache 压缩和复用等。提一下 DistServe、Mooncake 这些系统的实践，会显得对前沿有了解。
|
||||
|
||||
> 这道题考的不是让你背八股，而是看你有没有真正理解生产环境的复杂性。
|
||||
|
||||
---
|
||||
|
||||
> 编者：丁师兄，专注智能驾驶大模型，持续分享 LLM 面试干货；大模型 1v1 辅导。微信：dsxaigc
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：LLM 做 PD 分离后，怎么更慢了？
|
||||
|
||||
> **原文**：[2026-08-05_LLM做PD分离后怎么更慢了_丁师兄.md](./2026-08-05_LLM做PD分离后怎么更慢了_丁师兄.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/0HlmtIuPGU7QE5r1fyhcsA
|
||||
> **来源**：微信公众平台（丁师兄）
|
||||
> **作者**：丁师兄（专注智能驾驶大模型，LLM 面试干货分享）
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **落地五坑** — 从生产环境视角系统列出 PD 分离的 5 大落地问题（KV 传输、负载失衡、调度复杂度、显存管理、P:D 敏感性），是与清一色"红利派"文章互补的"代价派"清单。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文以面试题"PD 分离实际落地会遇到什么问题"切入，系统梳理了 PD 分离生产落地的 5 大坑：KV Cache 传输开销（Llama-3.1-70B 单请求 1.34GB，10GbE 传 1 秒以上，需 IB/NVLink 级互联）、生产者-消费者不平衡（workload 动态变化使静态 P:D 配置失效）、调度复杂度飙升（双实例决策与气泡问题）、显存压力与跨节点生命周期管理、P:D 比例对 workload 的高度敏感性（性能曲线交叉、断崖式下跌）。其价值在于提供了本批文章中唯一完整的"反面清单"，并给出了可直接计算的量化示例；局限是数字多为估算与二手引用，无第一手实验，且"如何解决"仅点到业界方案名称。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **KV Cache 传输是最大坑** — Llama-3.1-70B 单请求 KV 约 1.34GB，TTFT 500ms 预算下 Prefill 占 200ms 后仅剩约 300ms 传输窗口：10GbE 需 1 秒+、25GbE 勉强 400 多毫秒，只有 InfiniBand/NVLink 才能压到几十毫秒级；"传输开销超过分离收益则整个架构白搭"。 `[分类: 共识]`
|
||||
2. **P:D 比例无万能配置** — 短 prompt 长输出需 1P3D，长上下文需 3P1D；真实业务流量动态变化，静态配置必出现一边闲置一边排队；论文与 Medium 实验均显示不同 Prompt/Output 比例下性能曲线交叉。 `[分类: 共识]`
|
||||
3. **调度复杂度飙升** — 调度器从单队列变为实时决策"请求分给哪个 P、KV 传给哪个 D"；生产者-消费者同步在高并发下产生气泡；Mooncake 的三层架构（P/D/Caching 集群）对小团队维护成本高。 `[分类: 共识]`
|
||||
4. **显存管理与碎片化** — KV Cache 生命周期跨越两个节点，PagedAttention 只能缓解单节点碎片；P/D 两侧的释放与复用时机协调不当会出现"一边频繁 OOM、另一边大量闲置"。 `[分类: 共识]`
|
||||
5. **瓶颈切换是突变而非平滑** — workload 从 Decode 密集切到 Prefill 密集时性能可能断崖式下跌；动态调整 P:D 又依赖实时监控与调度，与问题 3 形成循环依赖——这是动态 P:D 配比至今未成熟解决的深层原因。 `[分类: 未探索]`
|
||||
6. **应对方向的业界共识** — 高速网络、智能调度算法、动态伸缩、KV Cache 压缩与复用，并以 DistServe、Mooncake 为前沿实践代表。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论假设 PD 分离的收益已成立（文章未质疑分离本身，只质疑落地方式）；同时隐含假设读者已具备 PD 分离基本概念；"动态 workload"是常态这一前提放大了静态配比的缺陷，但未讨论可预测负载（如离线批处理）场景下静态配比的适用性。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
五个问题维度划分清晰、逻辑自洽，KV 传输的量化示例（1.34GB、300ms 窗口、各网络档位耗时）可直接复算，说服力强。但 P:D 敏感性结论仅转述"有篇论文"与"一篇 Medium 文章"，未给出论文名与数据来源，引用严谨性不足；部分数字（10GbE 传 1 秒多）为估算，未提供计算公式；"问题清单"完整但"解决路径"止于名词罗列。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论针对"动态生产流量下的在线推理"场景，对负载稳定的离线批量场景不适用；KV 传输开销的判断以 Llama-3.1-70B 为样本，对 KV 更小的 MoE 模型（如 DeepSeek）或 KV 压缩技术下的传输量需重新评估——其悲观程度与 DistServe 论文"传输可隐藏"的乐观结论形成对照，真实答案取决于网络与模型的具体组合；文章未覆盖传输与计算重叠（overlap）等已有缓解技术。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "这道题考的不是让你背八股，而是看你有没有真正理解生产环境的复杂性。"
|
||||
|
||||
> "如果传输开销超过了分离带来的性能收益，整个架构就白搭了。"
|
||||
|
||||
> "没有万能配置，必须根据实际 workload 调整。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 本批 PD 分离文章中唯一的系统性"代价清单"，与红利派文章形成强互补
|
||||
- KV 传输量化示例具体可复算（1.34GB、300ms 窗口），可直接用于面试与方案评估
|
||||
- 明确点出 P:D 敏感性、瓶颈突变、动态调整循环依赖等常被忽视的深层问题
|
||||
|
||||
**不足**：
|
||||
- 关键结论依赖未具名的二手引用，严谨性不足
|
||||
- 无第一手实验数据，数字多为估算
|
||||
- "怎么解决"止于业界方案名称，缺少可操作建议
|
||||
|
||||
**适用场景**：准备 LLM 推理面试的候选人；正在评估 PD 分离方案的架构师与运维团队（决策前的风险清单）；与红利派文章对照理解 PD 分离全貌的读者。
|
||||
|
||||
**关联建议**：与本批新智元 DistServe 文章对照阅读，可见"传输可隐藏 vs 传输是大坑"的张力本质是网络条件与模型规模假设不同；与本批 marcus 的 vLLM 源码文章串联，可理解调度复杂度在代码层的具体表现；进一步可阅读 Mooncake 论文（KVCache 复用与缓存集群）与 DistServe 论文中关于调度算法的章节。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
Reference in New Issue
Block a user