Target: DistServe — prefill/decode 物理分离 + goodput-optimal placement search。 与 8 篇相关 framework 论文对照。
这 8 篇按与 DistServe 的关系分成三个同心圈：
内圈 —「同一痛点、同一解法家族」(prefill/decode 分离 serving)
中圈 —「同为 serving、正交或互补的解法」
外圈 —「同一 disaggregation/placement 范式、不同 domain」(training)
vs PagedAttention/vLLM (2309.06180) — 正交且更狠。
vLLM 在 colocated 前提下压榨 KVCache 内存碎片（有效利用率 20%→接近 100%），从而增大 batch 提升吞吐 2–4× [2309.06180]。DistServe 则换了前提：它不改内存管理，而是直接分离两个阶段，报告 2.0–7.4× 更高 rate [2401.09670]。关键 delta：vLLM 优化 raw throughput（tokens/s），DistServe 优化 per-GPU goodput（SLO 约束下的 rps/GPU）——DistServe 的 §2.3 明确指出 colocated 系统即使 parallelism 调到最优也无法解决 interference（ablation 中 "vLLM++" ≈ vLLM）[2401.09670]。两者可叠加：DistServe 把 vLLM 当组件用。
vs FastServe (2305.05920) — 都攻 colocated，但一个改时间维度、一个改空间维度。
FastServe 的 root cause 分析是「90% 延迟来自排队」，解法是 skip-join MLFQ 抢占式调度 [2305.05920]。DistServe 的 root cause 是「prefill/decode 互相干扰 + 资源耦合」，解法是物理分离。二者互补但也部分重叠：FastServe 的抢占能缓解 HoL blocking，DistServe 的分离直接消灭 prefill→decode 干扰。DistServe 自己在 §4.3 承认没做 preemption，留作 future work——这正是 FastServe 的主场。增量方向明显：disaggregation + preemptive scheduling 尚未有人合并。
vs Mooncake (2407.00079) — 学术定义 vs 生产落地。
这是最重要的 delta。两者 Q1 几乎逐字相同（prefill 计算密集/decode 访存密集、耦合互相干扰）[2401.09670][2407.00079]。但增量分工清晰：
vs NEO / FastDecode (2411.01142, 2403.11421) — 同一 decode 洞察、相反的资源方向。
三篇都同意「decode 是 memory-bandwidth-bound，需要大 batch」。DistServe 的对策是给 decode 专用 GPU 池以攒大 batch [2401.09670]；NEO/FastDecode 的对策是把 decode attention 搬到 CPU释放 GPU 显存给 batch [2411.01142][2403.11421]。Delta：DistServe 花更多 GPU 换 SLO（goodput/cost），NEO/FastDecode 花 CPU 换 GPU 显存（内存受限硬件）。三者的部署前提不同——DistServe 假设多 GPU 集群 + NVLINK/IB，NEO 假设单节点 + 强 CPU，FastDecode 假设 GPU + 远程 CPU 集群 + IB。
vs FlexRLHF / HybridFlow (2312.11819, 2409.19256) — 跨 domain 的同构 delta。
DistServe 是 serving 侧、FlexRLHF/HybridFlow 是 training 侧，但三者共享同一「aha」：同一模型在不同阶段有不同资源特征，不该 co-located。FlexRLHF 的 Disaggregated 策略把 training/generation 运行时分离 [2312.11819]；HybridFlow 的 Auto Device Mapping = 训练版的 placement search [2409.19256]。Delta：serving 的 SLO 约束（TTFT/TPOT）催生了 goodput 目标函数，而 training 无延迟约束，目标是纯 throughput——所以 DistServe 的 placement search 里有 SLO-attainment 这一维，HybridFlow 的没有。
vs DeepSeek-V3 (2412.19437) — 从「论文提案」到「frontier 采纳」的时间线 delta。
DistServe (2024-01) 提出分离，DeepSeek-V3 (2024-12) 的生产推理直接用了分离部署 [2412.19437]。V3 还叠加了 DistServe 没有的 MLA（把 KV cache 压到 512 维），这直接削弱了 DistServe 最担心的 KVCache 传输开销——DistServe 特意选 OPT（经典 MHA）来「制造传输压力」[2401.09670]，而 MLA/GQA 模型上传输开销更小，DistServe 会表现更好（论文自己也这么说）。
攻击 1：M/D/1 模型的均匀长度假设在真实负载下崩塌。
DistServe 的 Eq.1–3 全部建立在「prompt 长度均匀、每请求执行时间 $D$ 恒定」之上 [2401.09670]。但 §3.3 自己承认真实负载长度非均匀会导致 pipeline bubble，「slight deviations from M/D/1」。这个 "slight" 是被低估的：FastServe 的整篇论文正是建立在长度高度倾斜这一事实上（ShareGPT load=0.9 时 98% 延迟来自排队）[2305.05920]。在长尾负载下，M/D/1 的 closed-form 预测与实际排队延迟可能有数量级偏差，而 DistServe 的 placement 又是基于 simulator（用拟合分布重采样）——若分布拟合偏离真实长尾，整个 placement 可能次优。反驳线：DistServe 的 simulator 实测 <2% SLO-attainment 误差 [2401.09670]，但那是在 ShareGPT/HumanEval/LongBench 上，未覆盖对抗性长尾。
攻击 2：FCFS + 无 preemption = convoy effect，DistServe 自己承认。
§4.3 明说 FCFS 会有 convoy effect（长请求阻塞短请求），且 preemption 留作 future work [2401.09670]。这意味着 DistServe 在 prefill 实例内部重新引入了它想消灭的那类 head-of-line blocking——只是从「prefill 阻塞 decode」变成「长 prefill 阻塞短 prefill」。FastServe 证明这个问题能贡献高达 90% 的延迟 [2305.05920]。DistServe 分离了阶段，却没分离队列纪律。
攻击 3：KVCache 传输 <0.1% 的结论高度依赖 segment-colocation trick 与 MHA-friendly 场景。
「传输 <0.1% 总延迟」是 DistServe 的招牌数字 [2401.09670]，但它成立有三个前提：(a) Algorithm 2 的 same-stage segment 强制 colocation 让传输走 NVLINK；(b) 测试集 prompt 不算极长；(c) 用 OPT-66B（KVCache 1.13GB/512-token）。一旦 (a) 不满足（如纯跨节点、无 NVLINK 的 low-affinity 集群且模型太大放不下 segment pair），传输会暴露到跨节点带宽（testbed 仅 25Gbps）。Mooncake 正是因为不能假设 NVLINK 总能藏住传输，才建了分布式 KVCache 池 + RDMA Messenger + layer-wise streaming [2407.00079]。DistServe 的 <0.1% 是「受控 testbed 下的最好情况」。
攻击 4：分离引入 fault propagation，且成本核算偏乐观。
§4.3 承认 decode 实例故障可能拖垮映射到它的所有 prefill 实例，容错留作 future work [2401.09670]。生产系统（Mooncake、DeepSeek-V3）都在实际承受这个复杂度。此外 DistServe 的「7.4× more requests」暗示 cost 降低，但分离天然需要 replica 冗余（$n$ prefill + $m$ decode），在低负载/小集群下这个冗余反而浪费——DistServe §7 自己承认 resource-constrained 场景下 non-disaggregated 更优 [2401.09670]。
范式定位：DistServe 是「prefill/decode disaggregation」这一 paradigm 的学术奠基作之一。
在 2024 年初，serving 的主流范式是 vLLM 式 colocated + continuous batching [2309.06180]。DistServe（与并发的 Splitwise/TetriInfer/DéjàVu）把「物理分离两阶段」从边缘想法推成了主流。它的独特贡献不是分离本身，而是证明了分离的收益主要来自消除 interference 而非 parallelism 调优（"vLLM++" ≈ vLLM 这一 ablation 是 paradigm 说服力的核心）[2401.09670]，以及把 placement 形式化为可搜索的优化问题。
采纳证据（strong）：
github.com/LLMServe/DistServe），6.5K Python + 8.1K C++/CUDA [2401.09670]，可复现性高于 Mooncake（生产 trace 但 dummy model）、远高于 FlexRLHF（未开源）[2312.11819]和 DeepSeek HAI-LLM（框架未开源）[2412.19437]。跨 domain 生态位： DistServe 与 FlexRLHF/HybridFlow 共同印证了「disaggregation + placement search」是一个跨 training/serving 的通用 infra 范式，而非 serving 专属 trick [2409.19256]。这抬高了它的引用半径。
边界（DistServe 诚实标注）： offline throughput-optimized 场景（chunked-prefill 更优）、单/少 GPU 场景（分离设计空间坍缩）下 DistServe 不适用 [2401.09670]。它是在线 + SLO 敏感 + 多 GPU 集群这一生态位的最优解。
方向 1：Disaggregation × Preemptive scheduling（DistServe × FastServe）。
DistServe 分离了阶段但队列内仍 FCFS；FastServe 有 skip-join MLFQ 但不分离 [2401.09670][2305.05920]。把 skip-join MLFQ 装进 DistServe 的 prefill 实例，可同时消灭「阶段间干扰」和「阶段内 HoL blocking」。目前无人合并——这是 cluster 里最明显的 hybrid gap。
方向 2：Adaptive colocation（按负载在 colocated ↔ disaggregated 之间切换）。
DistServe §7 承认低负载下分离浪费冗余，高负载下分离制胜 [2401.09670]；NEO 的 Greedy 原则（每迭代在 offload ↔ GPU-only 间选优，保证 never-worse）提供了现成范式 [2411.01142]。把 NEO 式 per-iteration greedy 提升到 per-epoch 的 colocated↔disaggregated 动态重配（DistServe 已有 replanning 骨架），可覆盖全负载谱。
方向 3：Disaggregation × CPU-offload 的三层内存分离。
DistServe 把 decode 放专用 GPU 池；NEO/FastDecode 把 decode attention 放 CPU [2411.01142][2403.11421]。二者可组合：decode 实例本身再做 CPU-offload，在同样 GPU 预算下攒更大 batch。Mooncake 已用 CPU DRAM 存 KVCache 池 [2407.00079]，但用于 prefix 复用而非 decode attention 计算——把 R-Part offload 叠加进 disaggregated decode 池是未探索组合。
方向 4：KVCache-centric placement（DistServe × Mooncake）。
DistServe 的 placement search 完全不考虑 prefix cache 命中；Mooncake 的调度以 prefix 匹配为核心但 placement 是启发式 [2407.00079]。把「prefix cache 亲和性」作为一维加进 DistServe 的 goodput-optimal search（Algorithm 1/2 的枚举空间），可在高 prefix 复用负载（L-Eval >80%）下同时拿到 disaggregation 与 caching 的收益。
方向 5：借鉴 DualPipe 的细粒度 overlap 到 KVCache 传输。
DeepSeek-V3 的 DualPipe 把 all-to-all 通信完全藏进计算间隙 [2412.19437]。DistServe 的 KVCache 传输目前靠 segment-colocation「藏在 NVLINK 里」，在跨节点 low-affinity 场景暴露。把 DualPipe 式 compute-comm overlap 用于 prefill→decode 的 layer-wise KV 传输（Mooncake 已做 layer-wise streaming 但未做双向 overlap），可解除 DistServe 对 NVLINK 的强依赖。