arno
c0ba3fb853
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
6.7 KiB
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 分离背后可能出现什么问题"，可以从这几个维度答：
- KV Cache 传输开销（最核心）：强调网络带宽要求，算传输时间，说明为什么需要 InfiniBand 或 NVLink 级互联；
- 负载不均衡：不同 workload 下 P:D 比例需求不同，静态配置导致资源浪费；
- 调度复杂度：生产者-消费者同步、资源分配决策、气泡问题；
- 显存管理：KV Cache 跨节点生命周期管理、碎片化、OOM 风险；
- 性能对 workload 敏感性：没有万能配置，需要动态调整。
如果追问"怎么解决"，可以说业界方案：高速网络、智能调度算法、动态伸缩、KV Cache 压缩和复用等。提一下 DistServe、Mooncake 这些系统的实践，会显得对前沿有了解。
这道题考的不是让你背八股，而是看你有没有真正理解生产环境的复杂性。
编者：丁师兄，专注智能驾驶大模型，持续分享 LLM 面试干货；大模型 1v1 辅导。微信：dsxaigc