考察点
PD 分离是近两三年推理系统方向的热点（Splitwise、DistServe、Mooncake 等），面试官借此区分"用过推理框架"和"理解推理系统"的候选人。要答清一条因果链：prefill 和 decode 的资源特性相反 → 混在一起互相干扰、扩缩容被绑死 → 拆开各跑各的、KV Cache 跨节点搬运 → 带来的工程代价。追问常落在 KV 传输开销、两阶段实例配比、哪些业务适合拆。
参考答案
为什么 Prefill 和 Decode 是一对矛盾
两个阶段对资源的需求几乎是镜像的：
- Prefill：一次性并行处理整个 prompt，GEMM 规模大，compute-bound，吃算力；时延是一次性的，但长 prompt 下可达秒级。
- Decode：每步只算一个 token，算力喂不饱，瓶颈在显存容量（放得下多少 KV Cache 决定 batch 多大）和显存带宽（每步搬一遍权重），memory-bound。
混部在一个实例上就有三个问题。第一，互相干扰：一个长 prompt 的 prefill 会霸占 GPU 几百毫秒，同 batch 正在 decode 的请求 TPOT 立刻劣化，流式输出肉眼可见地卡一下。第二，扩缩容绑死：prefill 想多加卡提升算力、decode 想多要显存放大 batch，两者最优的并行策略都不一样（prefill 倾向 tensor parallel 缩短时延，decode 倾向小 TP 大 batch 提吞吐），混着部署只能取折中，两头都不最优。第三，资源浪费：为峰值 prefill 算力配的卡，decode 阶段算力闲置；为 decode 显存配的卡，prefill 时显存闲着。
PD 分离的做法
思路很直接：把 prefill 和 decode 拆到不同的 GPU 实例（甚至不同机型）上，各自独立调度、独立扩缩容、独立选并行策略。流程变成：
- 请求先到 prefill 集群，算完整个 prompt 的前向，产出 KV Cache 和第一个 token；
- KV Cache 通过高速互联（NVLink 域内、RDMA/RoCE 跨机）传给 decode 实例；
- decode 实例接管，continuous batching 逐 token 生成，结果流式返回。
收益：decode 实例不再被 prefill 打断，TPOT 平稳，流式体验好；prefill 集群可以按算力最优配（大 TP），decode 集群按显存最优配（小 TP 大 batch），资源各归其位；TTFT 和 TPOT 的 SLO 可以分开保障，容量规划清晰。Mooncake（Kimi 的生产架构）还把这个思路扩展成以 KV Cache 为中心的分布式池：全球节点的 KV 统一缓存调度，prefix 命中率最大化。
代价和工程难点
天下没有免费的拆分，PD 分离引入的新问题正是面试官爱追问的：
- KV 传输开销：prefill 产出的 KV 可能上 GB（长上下文），跨机传输若慢于本地 prefill，反而抬高 TTFT。依赖高带宽互联，需要传输与计算流水线化（边算边传、分层传输）。
- 实例配比：prefill 和 decode 集群各配多少卡，取决于流量里 prompt 长度和生成长度的分布（比如输入 4k、输出 500 的摘要业务和输入 500、输出 2k 的创作业务配比完全不同），要按真实流量测算，配错了就是新的浪费。
- 调度复杂度：请求生命周期跨两个集群，排队、失败重试、负载均衡、KV 放置（哪个 decode 实例有空闲显存）都要全局协调。
什么业务值得拆
短输入短输出、并发不大的业务，混部加 chunked prefill 就够了，拆 PD 的传输开销不划算。长上下文 + 高并发 + 对 TPOT 敏感的场景收益最大：文档问答、代码仓库级理解、agent 长链路对话。这也是各家大模型 API 服务商（长 prompt 是常态）普遍走向 PD 分离的原因。
可能的追问
- PD 分离和 chunked prefill 都解决 prefill 干扰 decode，什么关系？ Chunked prefill 是混部下的缓解手段（把 prefill 切碎插进 decode 间隙），零额外架构成本；PD 分离是架构级消除，两者可叠加。流量规模小用前者，大到干扰成为主要矛盾再上后者。
- KV Cache 传输具体怎么优化？ 分层流水：prefill 每算完一层就把该层 KV 发出去，与下一层计算重叠；配合 RDMA 零拷贝、按 block 粒度传输； prefix 命中的部分甚至可以不传输直接复用。
- prefill/decode 实例配比怎么估？ 用流量的输入/输出长度分布算两阶段的算力-时间占比：prefill 总耗时 ≈ Σ prompt 长度相关 FLOPs / prefill 集群算力，令其与 decode 总耗时匹配，再留峰值余量；生产上靠压测迭代逼近。