PD 与 C2C：局部更快，怎样变成端到端收益？

1. 把优化放回同一条关键路径

Prefill／Decode 分离后，缓存、网络和计算共享请求的延迟预算。命中的 KV 若在 suffix prefill 时提前送往 Decode，可能缩短等待，也可能更早占住 Decode HBM。前一阶段省下的时间，可能变成下一阶段的排队。

主线可以画成：请求准入、KV 恢复、prefill 与集合通信、P→D 传输、Decode 准入和首 token。部署未必严格串行，需要把依赖、重叠与等待放进同一张时间线。

KV Transfer 与 DeepEP 共用网卡时能否让位？容量紧张时能否先接收到 host？C2C 能否让部分状态留在 CPU DRAM 参与计算？这些优化分别改变时间、空间和访问方式，需要接受同一组端到端指标的检验。

测量这条路径已有更细的实现入口：10 月 2 日合并的 vLLM #58874 在 KV consumer 端按 engine 区分 waiting_to_start、in_progress、completed_waiting。它们是 Scheduler 观察到的请求计数，不是 NIC 活跃传输数或阶段延迟；completed_waiting 也可能是失败后准备重算。把三个计数与实际传输时间线、lease 剩余时间和 TTFT 对齐，才能判断等待位于网络还是传完后的准入。一个尚未执行的最小证伪检查是暂停 D 超过 lease 并让 P 复用原块，再恢复 D：应观察到重算或明确失败，而非只凭 HTTP200 判为恢复成功；睡眠／唤醒另测注册 epoch 和物理页，避免把 pause 与 unmap 混成一个变量。

支持横向滑动查看

2. 传输粒度与接收位置分别控制

SGLang #39992 针对超过 pack buffer 的大请求，将目标 rank 的 token 分片切成有界 slices，每片 gather／pack 后批量传输，等待完成再复用 buffer，以避免大量逐 token RDMA。它讨论的是 slice-pack，并非修改 DCP ownership。

截至 2026-09-30，#39992 已关闭、未合并，标题标有 DO NOT MERGE。性能数字来自作者下游分支，未在最新 main 验证。这是方案线索，不能写成上游已上线的收益。

另一条路径是 #40238：它于 9 月 24 日合并 Decode host receive 通用接口。在设备 token usage 达阈值时，具备能力的后端可将新传输接收到 host pool，设备准入后再恢复到 GPU。接口默认关闭；PR 当时明确内置后端尚未实现 host destination。实际能否使用，要检查目标后端，不能只看开关或合并状态。

传输粒度、接收位置、显存预留时点是不同变量。较大 slices 不会自动解决容量问题，host 接收也有搬运成本。

3. 区分链路调度与阶段调度

TENT 将传输意图与具体路径分离，在 slice 粒度依据遥测和成本估计晚绑定链路，处理拥塞、坏链路与带宽闲置。拥有这种能力，并不能直接证明某个部署中的 TENT 能理解 DeepEP collective 的业务优先级，或能抢占外部库已经发出的工作。

阶段调度关注另一层信息。MFS 在 9 月 19 日的 v2 改题为 Stage-Aware Communication Scheduling for Disaggregated LLM Serving，系统名 Nuska，将 KV retrieval、collective、P2D 的依赖及 TTFT 余量纳入调度。来源中的两个标题是同一论文的版本演进。

验证实现时还要拆开 CPU 与设备路径。GIL 或同步等待是否让提交串行，和已发出的 GPU／NIC 工作是否互相争用，是两组问题。异步 API 不证明实际重叠，时间线重叠也不证明互不干扰。可先对比 prefill-only、KV-only、prefill+KV，记录 CPU 提交、kernel、DeepEP dispatch／combine、NIC 吞吐与 inflight 数。

ThunderEP v1 提供了一个拓扑边界鲜明的对照：在没有 P2P 的六卡 consumer GPU 上，Prefill 的 DMA 搬运与 expert 计算可按 sender 到达顺序衔接；Decode 为维持 CUDA Graph 的双 buffer 轮换反而仍用 SM。它的 All-Gather 少传字节，GPU-reduce Combine 则主要省同步链。由此能提出的检查项是分别量化 payload、等待和资源争用，不能把该论文的 PCIe 结果直接写成 Grace C2C 或 RDMA 的收益。

完成语义还要跨过故障边界。Mooncake 的 TENT 后续提案 #4447–#4449 在控制面快速失败之后，为 RDMA／RPC 通知加入 session／seq 去重，并把失败或退役 QP 中已 post 的带戳 typed SEND 交给后台换 NIC 配对重发。这解释了为什么先有去重，才敢在结果不确定时重发；不过 4,096 条滑动窗口、旧 peer／raw payload 兼容、进程重启和接收端消费之前崩溃都仍有限制。作者两主机故障注入结果属于完整 stacked 分支，不能拆成单 PR 收益，也不能把 NIC 确认与应用消费等同为端到端 exactly-once。比较正常与故障路径时，吞吐、通知唯一交付和请求最终完成需要分别测量。

GPU-Initiated Communication v1 的作者微基准进一步把 issue 与 completion 分开：前者衡量提交线程构造并发出操作的时间，后者还包含轮询、顺序保证和队列更新。GPU 发起也不自动隔离 bulk 流量；共享 context／ring 会增加等待，比较保留队列的收益还必须固定实际承载负载。通信代码本身也可能增加寄存器需求、降低调用方 block 驻留率，甚至在通信分支未执行时产生代价。因此，PD／C2C 实验应分别记录提交、完成、队列共享与计算资源占用，不能用更短 issue 推断整层更快。这些结论来自论文指定库版本和拓扑，不证明当前 TENT 已能调度 DeepEP 的业务优先级，或某种 C2C 部署必然获益；本站未独立复现。

4. 分离 C2C 的容量与带宽收益

BOOST 希望同一 wave 内的 CTA 按带宽比例并行访问 HBM 与 host memory，以 PAM 处理页放置、DSR 维护动态 KV 映射。其评估重点是 GH200 上 bandwidth-bound decode，不能直接推广到所有 prefill 或 PCIe 系统，更不能简化为固定几个 head 放在 CPU 就能得到相同效果。

DirectKV 提供独立实现与 SGLang 集成，区分 GH200 ARM 与 Hopper x86／PCIe 镜像，并提示 PCIe 可做功能验证但性能不同。能运行、正确性通过、性能复现，是三项检查。

一个尚未运行的实验是先固定 batch，对比 HBM-only、prefetch+staging 与 host 直接访问，再放开 batch 测容量收益。固定 context、精度、命中条件与内核版本，记录 TPOT、HBM／C2C 读写和 CTA 尾部。对提前 P→D 传输，则比较完成后发送、命中即发送和预算限制发送，联合记录 TTFT、goodput 与 Decode 预留 HBM 的字节×时间，避免把等待转移误判成加速。