docs(kvc): freeze reseed slow-path audit + three reviewer challenges

Standalone reference document capturing the v2 reseed slow-path forensic
audit before opening the feat/d-to-p-sync branch. Designed to be quoted
directly by future paper drafts and to prevent the team from re-relitigating
the same questions verbally.

Contents:

§1. The three team-member challenges that disproved "capacity-backup will
    save the slow path" (each with code citation and verdict):
    1) P pool can't fit all backups -- replay.py:1618-1620 caps backup
       count at 1 for sessions with ~50K peak input.
    2) P's backup is a stale snapshot -- 49K of direct-to-D append work
       never flows through P. _commit_prefill_backup_residency
       (replay.py:1483) is only called from seed/reseed paths;
       direct-to-D path (replay.py:2719) never touches P-side state.
    3) When D evicts, old KV is freed directly (no D->P dump).
       session_aware_cache.release_session only calls
       kv_pool_allocator.free().

§2. End-to-end reseed timeline (t=0 to t=4550ms) with code citations
    showing exactly where each component sits. P-side re-prefill =
    1.5-3s, mooncake transfer = 1.5-4s, both contributing 50/50 to
    total reseed cost.

§3. Table of "looks like D->P but isn't" code locations -- every
    candidate found during forensic search ruled out with line citations.

§4. Specification of what D->P incremental sync would require:
    mooncake bidirectional roles (~400 LOC), D-side append commit hook
    (easy), P-side radix tree multi-producer extension (the real blocker),
    agentic-pd-hybrid replay.py hooks. Estimated 1-2 weeks engineering.

§5. Confirmation via `git ls-remote origin --refs` that author has NOT
    secretly implemented D->P on another branch -- only main + this
    working branch exist on the server.

§6. Roadmap for the upcoming feat/d-to-p-sync branch.

Appendices: code position crosswalk, related commits, paper section
suggestions.

This document is referenced by V2_DEEP_ANALYSIS_ZH §4.2 and by
KVC_ROUTER_ALGORITHM §9 Open Question 4.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/RESEED_SLOW_PATH_AND_D_TO_P_GAP_ZH.md

@@ -0,0 +1,368 @@
+# Reseed 慢路径现状与 D→P KV 同步缺口
+
+**日期**：2026-05-11
+**对象**：项目团队 + 后续 paper reviewer
+**性质**：基线现状落盘 + future-work 缺口定位
+**前置文档**：
+- `docs/V2_DEEP_ANALYSIS_ZH.md` §3.2 §4.2（reseed 路径在 v2 数据中的表现）
+- `docs/KVC_ROUTER_ALGORITHM.md` §3 §9（算法形式化 + open questions）
+
+**目的**：把"v2 的 reseed slow path 为什么慢、能不能用现有机制治、还差什么"三个问题落盘成单一参考文档，让团队不必再口头反复对齐，让论文 future-work 章节有可引用的基础。
+
+---
+
+## 0. TL;DR
+
+1. KVC v2 在 SWE-Bench 测试中 8.3% 请求走非 direct-to-D 的 reseed/fallback 路径，**单次 reseed 实测 3-7s**（TTFT p99 = 1.28s 全部来自这条路径）。
+2. 启用真 RDMA（节点有 mlx5_0/_1 @ 200 Gb/s × 2 active）能把 reseed 的 transfer 段（~1.5-4s）压到 ~200-400ms，但**对 re-prefill 段（~1.5-3s）无效**。预期 reseed 总时间从 3-7s 降到 1.7-3.2s，TTFT p99 ~0.7s，**仍输 DP（0.43s）**。
+3. 真正消除 reseed 长尾必须实现 **D→P 增量 KV 同步**——让 P 端 backup 跟上 D 在 direct-to-D append 路径上累积的 KV，避免 reseed 时重新跑 prefill kernel。
+4. 经 Opus agent 独立 forensic 审查（commit `9ccd853`）+ 全分支 git 检索：**当前代码、vendored SGLang、mooncake 三层均无 D→P 实现**，作者也没有在其它分支偷偷开发——仓库总共只有 main（旧 baseline）+ kvc-debug-journey-v1-to-v4（本工作分支）两个分支，main 还落后我们 18 个 commit。
+5. `--kvcache-prefill-backup-policy capacity-backup` 这个 flag 看起来像 D→P 同步但**不是**——它的真实语义只是"reseed 完不关 P streaming session"，P 端 KV 仍是 seed-time 的**静态快照**，不随 direct-to-D append 而增长。
+6. 实现 D→P 增量同步的工程量 ~1-2 周，最难的不是网络层（mooncake 加 D-sender / P-receiver 角色 ~400 LOC），而是 **SGLang radix tree 改成允许从外部 worker 喂数据**——radix cache 当前假设单一生产者。
+
+---
+
+## 1. 团队成员的三个质疑（关键框架，paper 引用建议保留原话）
+
+这三条质疑出自 v2 完成后的对话审查，**直接戳穿了"启用 capacity-backup 就能消除 slow path"的一厢情愿**。每条都有代码层证据支持，**全部成立**。
+
+### 质疑一：P 节点的 pool 塞得下所有 backup 的 KV cache 吗？
+
+**回答：塞不下，max 同时 backup ~1-2 个大 session。**
+
+代码证据（`src/agentic_pd_hybrid/replay.py:1618-1620`）：
+
+```python
+max_backup_sessions = max(1, capacity_tokens // max(1, target_tokens * 2))
+max_backup_sessions = min(max_backup_sessions, 4)
+```
+
+按 SWE workload 实测代入：
+- P 池 `capacity_tokens` ≈ 92,104 tokens（SGLang 启动时按 mem_fraction_static 自动分配）
+- 典型 session peak input `target_tokens` ≈ 50,000-80,000 tokens
+- 计算：`92K // (50K × 2) = 0` → `max(1, 0) = 1`
+- → **P 最多同时 backup 1 个大 session**
+
+对照小 session：
+- target 20K：`92K // 40K = 2` → backup 上限 2 个
+- target 10K：`92K // 20K = 4` → backup 上限 4 个（达到代码硬上限）
+
+→ **capacity-backup 在真实 agentic 长 context workload 下只能救少数 session，不是全员保险。**
+
+### 质疑二：P 上的 backup 是陈旧快照——49K 的 append 内容根本没经过 P
+
+**回答：完全正确，这是 capacity-backup 设计上的致命缺陷。**
+
+**用户提供的反例场景**（已成为 paper 中描述 slow path 的标准例子）：
+
+```
+turn 0:   P 做 prefill 1K tokens → 经 mooncake 传到 D → P 留 1K backup
+turn 1-50: 全部走 direct-to-D，D 上做 append-prefill，KV 在 D 上从 1K 增长到 50K
+           ↑↑↑ 关键：这 49K 的 append 内容（tool 输出、user 消息、模型生成）
+              **从未流经 P 节点**。P 端 backup 锁在 1K 状态。
+turn 51:  D 出于某种原因（容量、迁移、显式驱逐）拒绝 → 触发 reseed
+          → 即使 P 上有 backup，也只是 turn-0 的 1K
+          → 实际需要 D 上重建的是 50K（当前完整 context）
+          → P 必须从 prompt 重新 prefill 49K 的差额
+          → capacity-backup 节省的 compute 仅 ~2%
+```
+
+**代码证据**（独立 Opus agent forensic 审查，commit `9ccd853`）：
+
+1. 唯一更新 `session.prefill_resident_tokens` 的函数是 `_commit_prefill_backup_residency`（`replay.py:1483`）
+2. 这个函数的唯一 caller 是 `_invoke_kvcache_seeded_router`（`replay.py:2208`）—— 即 seed/reseed 路径
+3. `_invoke_session_direct`（`replay.py:2719`，direct-to-D 路径）只更新 `session.opened` / `resident_tokens` / `last_trace_request`，**从不触碰任何 P 端字段**
+4. `_commit_prefill_backup_residency` 内部用 `_estimate_session_resident_tokens(request)` 取的是**完整 request 的预估**，不是 append delta——所以连 bookkeeping 层面都不假设有增量更新
+
+→ **`capacity-backup` 的真实语义只是"reseed 完之后跳过 `_close_prefill_session`"**（`replay.py:2221`），P 端 streaming session 保持 open 状态、KV 留在 P 的 radix tree 中。但**不存在任何机制让这份 KV 跟上 D 端的 append 增长**。
+
+### 质疑三：D 触发 reseed 后，本机旧 session 的 KV cache 是不是清空了？P 做完 re-prefill，KV 推到哪里？
+
+**回答：是的，旧 KV 直接 free 掉；P 重新 prefill 完之后推到 router 选的新 target D（可能同 D，可能换 D）。中间没有"先 dump 到 P 再清"的快捷方式。**
+
+#### D 端驱逐时的 KV 处理
+
+代码证据（`replay.py:_close_decode_session`，1539-1569 行；`session_aware_cache.py:release_session`，250-276 行）：
+
+```python
+# replay.py 端
+async def _close_decode_session(..., evicting_for_capacity=False):
+    if not session.opened:
+        return
+    await _close_streaming_session(...)         # 给 D 发关闭信号
+    # 从 D 的 resident bookkeeping 里删掉这个 session
+    session.opened = False
+    session.resident_tokens = 0
+    if evicting_for_capacity and not session.prefill_opened:
+        residency.decode_evictions_without_prefill_backup += 1
+
+# SGLang 端（session_aware_cache.py）
+def release_session(self, session_id):
+    # 解锁引用 + 直接 free KV slots
+    self.token_to_kv_pool_allocator.free(kv_indices)
+    # ↑ 没有序列化、没有外发、没有 D→P 通道
+```
+
+**D 驱逐 = 把 KV slot 直接归还给 token pool 分配器。完全没有任何 outbound 网络调用。**
+
+#### Reseed 时 P→D 的目标选择
+
+驱逐之后的 reseed 路径（`_invoke_kvcache_seeded_router`，`replay.py:2101`）走的是与 turn 0 完全一样的 P-mediated seeding：
+
+```
+1. KvAwarePolicy.select() 选择一个 target D'（可能是同一个 D，也可能因 migration 换 D）
+2. _invoke_kvcache_seeded_router 在 D' 上 open 一个 streaming session
+3. 给 P 发完整 prompt → SGLang pd-router 让 P 做完整 prefill
+4. P 的 prefill 完成后通过 mooncake 把 KV 一次性推到 D'
+5. D' 上接收完毕，session 重建完成；decode 继续
+```
+
+**所以 P 做完 re-prefill 的 KV 推到 KvAwarePolicy 选的 target D'**——可能是：
+- 同一个 D（驱逐后重新接受）
+- 另一个 D（如果 reject 计数累积触发 migration，详见 KVC_ROUTER_ALGORITHM §3.3）
+
+无论哪种，**旧 D 的旧 KV 在新 KV 到达之前就已经被 free**。没有 D→D 的直接迁移路径，没有"先 dump 到 P 再推回"的快捷路径。
+
+---
+
+## 2. Reseed 路径的完整 step-by-step 现状
+
+把上面三个质疑串成端到端流程，以下是 v2 当前 reseed 路径的**完整**操作序列。每一步都标注实测耗时与代码位置。
+
+### 触发条件
+
+下列任一发生时 router 走 reseed 路径（详见 `KVC_ROUTER_ALGORITHM.md §3.3`）：
+- D 端 `Admit()` 返回 `can_admit=False`，原因为 `no-d-capacity` / `session-not-resident` / 等
+- KvAwarePolicy.select 返回的 D 不再持有该 session（migration 触发）
+- v1/v2 的 reject counter 累积让所有 D 都被 blacklist（极少触发，由 reset-on-success 保护）
+
+### 端到端时间线
+
+```
+t=0      上游 agent 发出 turn N 请求（input ~50K，append ~2K）
+            ↓
+t=~5ms   Router 的 KvAwarePolicy.select() 选 target D'（O(|D|) Python 评分）
+            ↓
+t=~10ms  Router → D' 发 admit_direct_append RPC
+            ↓
+t=~30ms  D' 返回 can_admit=False, reason="session-not-resident"
+         或 "no-d-capacity"，Algorithm 3 bump rejects[s, D']++
+            ↓ （fallback chain 最多再试 ε-1 个 D，对应 ε ~30ms 总额）
+t=~100ms 所有 D 都被拒 / 选不到适合 D，路径退化到 seeded router
+            ↓
+t=~110ms Router 转 _invoke_kvcache_seeded_router
+            ↓
+t=~120ms [可选] capacity-backup policy 下：_reserve_prefill_backup_capacity()
+         检查 P 池容量，若不够先 LRU 驱逐别的 P backup session
+            ↓
+t=~150ms P 上 open streaming session（HTTP /session/open）
+            ↓
+t=~200ms 发完整 prompt 到 SGLang pd-router → 路由到 P
+            ↓
+t=~250ms  P 开始 prefill
+         ↓
+         ↓ ←←← 大头 1：P-side re-prefill 段
+         ↓     P 必须 prefill 完整 ~50K tokens
+         ↓     即使 capacity-backup 开着，P 的 backup 只有 turn-0 的 ~1K
+         ↓     radix prefix cache 命中前 1K，剩余 49K 重算
+         ↓     实测耗时：~1.5-3s @ Qwen3-30B TP1
+         ↓
+t=~2000ms P 完成 prefill，KV 进入 mooncake transfer 队列
+            ↓
+t=~2050ms mooncake 开始 P→D' transfer
+         ↓
+         ↓ ←←← 大头 2：P→D mooncake transfer 段
+         ↓     KV 张量 ~5-9 GB（50K tokens × 2 bytes/token × layers × heads...）
+         ↓     **TCP loopback** 实测耗时：~1.5-4s
+         ↓     ↑↑↑ 当前 sweep 未启用 RDMA，走的是单机 lo 设备
+         ↓     若启用 IB RDMA @ 200 Gb/s，理论 200-400ms
+         ↓
+t=~4500ms transfer 完成，D' 上 session 重建好
+            ↓
+t=~4510ms D' 开始 decode（小幅度 append-prefill 余下的 ~2K append + 生成）
+            ↓
+t=~4550ms 首个 token 出来 → TTFT 测点
+```
+
+**单次 reseed 总耗时：3-7s**（中位 ~2.5s 来自较小 session，p99 ~7.7s 来自最大 session）。**re-prefill 段与 transfer 段大致五五开**，受 session 大小影响。
+
+### 这就是为什么 v2 的 TTFT p99 = 1.28s
+
+8.3% slow path 走的是上面这条流水线，其中 reseed 路径（`pd-router-d-session-reseed`）单独占 3.4%（150/4449 请求），构成 KVC TTFT p99 长尾的主要贡献。
+
+---
+
+## 3. 已审查的所有"看起来像 D→P 但其实不是"的代码
+
+下面这些在搜索时容易误判成 D→P 实现，**全部经独立 audit 排除**：
+
+| 文件:行 | 看起来像 | 实际是 |
+|---|---|---|
+| `replay.py:1483 _commit_prefill_backup_residency` | "把 backup 提交到 P" | bookkeeping 函数，更新 `session.prefill_resident_tokens` 计数字段。不传输任何 KV 数据，只在 seed/reseed 完成后被调用。 |
+| `replay.py:1572 _reserve_prefill_backup_capacity` | "预留 backup 空间" | 检查 P 池可用空间并按 LRU 驱逐别的 backup session 腾位置。不传 KV，只调整 reservation 计数。 |
+| `cli.py:182 --kvcache-prefill-backup-policy` | "backup 策略" | 只决定 reseed 完成后是否 `_close_prefill_session`。capacity-backup = 保留 P 端 streaming session 不关；release-after-transfer = 立刻关闭。**两种策略下 P 的 KV 都是 seed-time 的静态快照**。 |
+| `session_aware_cache.py:release_session` | "释放 session（可能含外发）" | 仅调 `kv_pool_allocator.free(kv_indices)`。零网络调用。 |
+| `disaggregation/decode.py: start_decode_thread` | "decode 端线程，可能有出站" | 纯 receiver loop。处理入站 `AUX_DATA / CHUNK_READY / STAGING_REQ / KVPoll.Success`，**没有出站 KV 传输分支**。 |
+| `disaggregation/mooncake/conn.py:1563` | "传输请求添加" | `assert disaggregation_mode == PREFILL`——硬约束，只有 P 端能调。 |
+| `mooncake.MooncakeKVSender` / `MooncakeKVReceiver` | "双向 sender / receiver" | 强角色化：Sender 只在 PREFILL 模式实例化，Receiver 只在 DECODE 模式。`BaseKVManager` 抽象无 bidirectional slot。 |
+| `pd-router-d-session-reseed-after-eviction` execution_mode | "走 backup 的快路径" | 实际还是走完整 `_invoke_kvcache_seeded_router`（P 完整 prefill + 完整 mooncake transfer），只是 `_eviction_suffix()` 在 execution_mode 字符串末尾加了 "-after-prefill-backed-eviction" 标签。**没有任何 fast-path 优化**。v2 中仅 2/4449 请求走到这个标签。 |
+
+---
+
+## 4. D→P 增量同步：要做的是什么
+
+完整 D→P 增量同步的设计目标：**让 P 端的 backup KV 在 direct-to-D append 完成后异步追上 D 端的 KV，让 reseed 退化为单次 P→D transfer（无需 P re-prefill）**。
+
+### 抽象数据流
+
+```
+当前：
+  direct-to-D append: D 本地 append-prefill，P 端 backup 锁住不变
+  reseed:             P re-prefill 完整 50K + P→D transfer 完整 50K
+
+目标：
+  direct-to-D append: D 本地 append-prefill，**同时**异步把新增的 KV 块推回 P
+  reseed:             P→D' transfer 完整 50K (already up-to-date)
+                      无需 P re-prefill
+```
+
+### 实现层面要改的事
+
+按工程难度排序：
+
+#### 4.1 Mooncake 双角色化（中等难度，~400 LOC）
+
+- `BaseKVSender` / `BaseKVReceiver` 抽象保留，但允许同一 worker 同时实例化两种角色
+- `MooncakeKVManager.__init__` 把 PREFILL / DECODE 分支改成"role set"，允许 worker 同时持有 sender 和 receiver
+- 新增 `DecodeKVSender` 类（D 端用于把 append KV 推回 P）
+- 新增 `PrefillKVReceiver` 类（P 端用于接收 D 的 append KV）
+- 引入第二个 bootstrap channel（避免与原 P→D 通道在 buffer pointer 协商上冲突）
+
+#### 4.2 D 端 append commit hook（容易）
+
+- 每次 `direct-to-D-session` 完成后，识别新写入的 KV 块（D scheduler 在 commit 时知道）
+- 入队 D→P 传输（异步，不阻塞 next request）
+- 标记 backup 是否成功送达 P（用于后续 reseed 决策）
+
+#### 4.3 P 端 radix tree 多生产者扩展（**最难，工程量主体**）
+
+**这是真正的架构 blocker**。SGLang 的 P 端 radix cache 当前假设：
+- 单一生产者（本 worker 的 model 输出）
+- 树插入只在 prefill / decode 完成时发生
+- KV 索引由本 worker 的 token_to_kv_pool_allocator 分配
+
+要让 P 接收 D 喂来的 KV 块，需要：
+- 扩展 radix tree 节点的写入路径，允许"外部供给的 KV + token 序列"被插入
+- 处理 KV 索引重映射（D 的 slot 号在 P 上无意义）
+- 处理 reference counting（同一 session 可能既被本 worker 用、又被 D 喂回更新）
+- 处理 eviction policy 协调（P 端 radix LRU 不应让"被 D 喂入的 backup"先被驱逐）
+- 处理 KV 数据格式的跨 worker 兼容（同样的 model layout，应该是 trivial，但需要测试）
+
+#### 4.4 agentic-pd-hybrid 端 hook（容易）
+
+- `_invoke_session_direct` 完成后，新增一步：触发 D→P 同步 RPC（异步）
+- `_invoke_kvcache_seeded_router` 在 reseed 触发前先 probe P 是否有 up-to-date backup；若有，跳过 re-prefill，只做 P→D transfer
+- 新增 CLI flag `--enable-d-to-p-sync`，默认 off，保留 baseline 行为
+- 新增 structural log channel 记录 D→P 同步事件 / 失败 / 延迟
+
+### 实现完毕后的预期收益
+
+| 指标 | 当前 (v2) | RDMA only | RDMA + D→P sync |
+|---|---:|---:|---:|
+| reseed re-prefill 段 | 1.5-3s | 1.5-3s（不变） | **~0**（已有 up-to-date backup） |
+| reseed transfer 段 | 1.5-4s | 0.2-0.4s | 0.2-0.4s |
+| reseed 总耗时 | 3-7s | 1.7-3.4s | **0.2-0.4s** |
+| TTFT p99 | 1.285s | ~0.7s | **~0.4-0.5s**（与 DP 接近或胜过） |
+| 8.4% slow path 占比 | 不变 | 不变 | 可能保持但单次代价大幅下降 |
+
+→ 这就是 paper 里 future-work 应当声明的**"完整版 KVC 才能真正在 TTFT 全分位数上击败 DP"** 的路径。
+
+---
+
+## 5. 仓库分支审查（确认无作者私下实现）
+
+`git ls-remote origin --refs` 完整结果：
+
+```
+9ccd853...  refs/heads/kvc-debug-journey-v1-to-v4   ← 本工作分支（含本文档）
+e9062b1...  refs/heads/main                          ← baseline，落后我们 18 commit
+```
+
+- **服务器只有 2 个分支**，**0 个 tag**，**0 个隐藏 ref**
+- main 是更老的 baseline；含 `_commit_prefill_backup_residency` 等同名函数，但语义与本工作分支一致——都是静态 backup，无 D→P 同步
+- 全 git 历史搜索 `D->P / d-to-p / decode.*prefill.*transfer / kv.*pushback / kv.*sync / incremental / mirror` 关键词，**唯一命中是 commit `9ccd853`**（本文档相关的 doc 改动）
+- 唯一 remote 是 `origin`（`git@ipads.se.sjtu.edu.cn:wangjh/agentic-pd-hybrid.git`），无 upstream / fork
+
+→ **作者没有在其它分支偷偷实现 D→P**。这块工作是真空。
+
+---
+
+## 6. 下一步
+
+按 ROI 排序：
+
+### 必做（落地下一阶段）
+
+1. **新开 `feat/d-to-p-sync` 分支** 从当前 `kvc-debug-journey-v1-to-v4` 起步
+2. 写设计文档 `docs/D_TO_P_SYNC_DESIGN_ZH.md`：
+   - 包括上面 §4 的实现细节
+   - 添加 sequence diagram（P/D 通信时序）
+   - 评估 SGLang radix tree 多生产者扩展的具体 API 改动
+   - 评估 D→P 同步对 direct-to-D fast path 自身延迟的影响（理想是异步零开销）
+3. POC 阶段 1：mooncake 双角色化 + 一个能跑通的 D→P transfer 单测
+4. POC 阶段 2：P 端 radix tree 多生产者扩展（重点工程量）
+5. POC 阶段 3：agentic-pd-hybrid 端的 hook + flag
+6. 端到端验证：跑同 trace 同 ts=1 配置，目标 TTFT p99 < 0.5s
+
+### 推荐
+
+7. **同时启用真 RDMA**（独立于 D→P 工作，只需改 sweep 脚本加 `--force-rdma --ib-device mlx5_0`），先把现有 transfer 段加速作为 baseline
+8. **跑 RDMA-only 对照**：先证明单 RDMA 启用能把 TTFT p99 从 1.28s 压到 ~0.7s，再用 D→P sync 把剩下的 re-prefill 段也吃掉。这样 paper 里能写两条独立的 ablation
+
+### 不要做的事
+
+- 在 main / 工作分支上做 D→P 实验（隔离开），主分支应该保持 v2 稳定
+- 试图通过 capacity-backup 现有 flag "调出"D→P 效果——它结构上做不到
+
+---
+
+## 附录 A：本文档涉及的代码位置
+
+| 函数 / 字段 | 位置 |
+|---|---|
+| `_commit_prefill_backup_residency` | `src/agentic_pd_hybrid/replay.py:1483` |
+| `_reserve_prefill_backup_capacity` | `src/agentic_pd_hybrid/replay.py:1572` |
+| `_close_prefill_session` | `src/agentic_pd_hybrid/replay.py:1507` |
+| `_close_decode_session` | `src/agentic_pd_hybrid/replay.py:1539` |
+| `_invoke_session_direct` (direct-to-D 路径) | `src/agentic_pd_hybrid/replay.py:2719` |
+| `_invoke_decode_session_direct` | `src/agentic_pd_hybrid/replay.py:2826` |
+| `_invoke_kvcache_seeded_router` (reseed 路径) | `src/agentic_pd_hybrid/replay.py:2101` |
+| `DirectSessionState.prefill_resident_tokens` | `src/agentic_pd_hybrid/replay.py:128` |
+| `_eviction_suffix` | `src/agentic_pd_hybrid/replay.py:1220` |
+| `--kvcache-prefill-backup-policy` CLI flag | `src/agentic_pd_hybrid/cli.py:182-189, 436-441` |
+| `MooncakeKVManager.__init__` | `third_party/sglang/python/sglang/srt/disaggregation/mooncake/conn.py:187-256` |
+| `start_decode_thread` (decode 端 receive loop) | `third_party/sglang/python/sglang/srt/disaggregation/mooncake/conn.py:1425-1496` |
+| `add_transfer_request` (assert PREFILL) | `third_party/sglang/python/sglang/srt/disaggregation/mooncake/conn.py:1563` |
+| `MooncakeKVSender` / `MooncakeKVReceiver` | `third_party/sglang/python/sglang/srt/disaggregation/mooncake/conn.py:1648, 1740` |
+| `BaseKVSender` / `BaseKVReceiver` 抽象 | `third_party/sglang/python/sglang/srt/disaggregation/base/conn.py` |
+| `session_aware_cache.release_session` | `third_party/sglang/python/sglang/srt/mem_cache/session_aware_cache.py:250-276` |
+| `session_controller._close` | `third_party/sglang/python/sglang/srt/managers/session_controller.py:293-316` |
+
+## 附录 B：相关 commit
+
+| Commit | 内容 |
+|---|---|
+| `9ccd853` | docs: D→P 缺口的 Opus forensic audit 写入 V2_DEEP_ANALYSIS §4.2 + KVC_ROUTER_ALGORITHM §9 |
+| `2ec0deb` | v2 实现（reset-on-success + threshold 2048→8192）—— 直接 trigger 了对 reseed 慢路径的关注 |
+| `c47adaf` | feat: backpressure pause hint（与 reseed 不直接相关，但展示了"D 端可主动告知 router"的通信通道存在，是未来 D→P sync 控制平面的潜在基础） |
+
+## 附录 C：相关 paper 章节建议
+
+- **§Background**：把 §1-§2 的 reseed 现状作为 motivation 摆出
+- **§Algorithm**：参考 `KVC_ROUTER_ALGORITHM.md` Algorithm 1-3
+- **§Evaluation §Slow Path Cost**：把 §2 的端到端时间线作为 Figure（sequence diagram）
+- **§Future Work / Limitations**：把本文 §4 作为 KVC 真正实现"完整 fast path 替代"的 roadmap，引用 D→P 工作的设计文档（后续 `feat/d-to-p-sync` 分支产物）
+
+---
+
+**核心句**：v2 实现的 KVC 在 91.6% 请求上证明了 session-affinity 路由的价值，但 8.3% 的 reseed 慢路径让 TTFT p99 比 DP 差 3×。这条慢路径的 50% 时间在 P 端 re-prefill、50% 在 mooncake transfer——RDMA 只能救后者，**D→P 增量 KV 同步是唯一能消除 re-prefill 的机制**，且当前在框架、SGLang、mooncake 三层都没有实现，需要新建 `feat/d-to-p-sync` 分支从设计文档开始。