arno
c0ba3fb853
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
85 lines
6.7 KiB
Markdown
85 lines
6.7 KiB
Markdown
# 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
|