docs(kvc): production-decision reframe + formal router algorithm spec

After the critic-agent audit, V2_DEEP_ANALYSIS had drifted into an
audit-grade "5 wins / 1 loss / 3 draws" framing that mistook KVC's
deliberate design motifs (cache concentration via session affinity;
prefill-GPU idle as TTFT-stability trade-off) for "comparison
unfairness." This commit corrects the framing back to a production-
decision lens and adds a paper-track formal specification of the
router algorithm.

V2_DEEP_ANALYSIS_ZH.md changes:
- §0 TL;DR: lead with "online coding agent serving should pick
  KVC 1P3D"; the only real cost is TTFT p99 long-tail (3x DP) from
  the 8.3% mooncake reseed path, mitigable with real RDMA.
- §4 restructured into three buckets:
    real costs (TTFT p99 tail, abort accounting now fixed),
    counter-arguments to the critic (cache concentration and idle
      prefill GPU are design intent, not deficits),
    methodology to-do (naive-1P3D control, v2 N>=2 determinism).
- §6 replaces "5/1/3 rescoring" with production decision rationale:
  KVC wins on 6 latency/TTFT metrics + lower failure rate; pays
  TTFT p99 tail; lists workloads where DP would reverse the call.
- §8 decision points: D1 recommends Yes (accept v2 as milestone);
  D8 added: paper motif "KVC trades P idle for TTFT stability."

KVC_ROUTER_ALGORITHM.md (new, paper-track, Chinese narrative + English
algorithm boxes / variable names / theorems for direct paper reuse):
- Problem formulation, system model, full notation
- Algorithm 1 Route: lexicographic-tuple scoring on
    (overlap+alpha*sticky, sticky, -inflight, -assigned)
- Algorithm 2 Admit: D-worker autonomous admission deciding
    Direct / Seed / Reseed / reject (with reason)
- Algorithm 3 Dispatch: end-to-end orchestration with reset-on-success
    (the v2-specific fix that eliminates v1's self-amplifying thrashing)
- Theorem 1 (no permanent starvation) and Theorem 2 (fast-path
    determinism), each with a proof sketch
- Comparison table vs vanilla pd-disagg / DP cache-aware
- Anti-patterns ("what KVC explicitly is NOT")
- Open questions for reviewers
- Suggested paper citation phrasing
- Appendix A: algorithm-step to source-file:line crosswalk

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

docs/V2_DEEP_ANALYSIS_ZH.md

@@ -15,15 +15,12 @@
 
 ## 0. TL;DR
 
-1. **TEAM_REPORT 头条结论"真实 agentic workload 上 KVC 无配置能赢 naive DP"在 ts=1 下被推翻**——KVC v2 在 7 项 headline 指标上击败 4DP CA。
-2. **但"赢"的归因高度混杂**——critic agent 审查后发现至少 3 处对等性破坏：TTFT p99 被刻意省略、error 统计口径不一致、KVC 的 fast-path 测量的工作量比 DP 少 6.9×。
-3. **TEAM_REPORT §1（session pin 饿死）已被 v2 修好**——direct-to-D 从 42.8% 涨到 91.6%，max D-changes 控制在 45（仅 1 个 session）。但 reset-on-success 这条修复路径是事后补的——v1 直接加 migration 制造了更严重的 thrashing 失效模式。
-4. **TEAM_REPORT §2/§3/§4/§5（LRU / backpressure / P-side imbalance / admission RPC 干扰）在 ts=1 下全部消失**——但是被 ts=1 的"低压自然 drain time"吸收，不是机制层面修好。一旦回到 ts=10 / 更长 trace / 更紧容量，会全部复现。
-5. **新暴露 3 个 ts=10 时代没看到的问题**：
-   - TTFT p99 反向恶化（KVC 1.285s vs DP 0.427s，**3.0×**）来自 8.3% 非 direct-to-D 路径的 mooncake reseed 代价
-   - 对 4DP 比较存在拓扑不对等（KVC 的 1P + 3D 中 prefill GPU 在 91.7% 时间内闲置）
-   - 缺乏 naive 1P3D 对照（vanilla SGLang xPyD），无法区分"KVC 层贡献"vs"1P3D 拓扑贡献"
-6. **结论**：v2 是项目第一次让 KVC 在 SWE workload 上证明价值，但当前对 DP 的胜利不能直接外推到 "KVC 机制本身优越"。需要 3 个补充对照才能站住。
+1. **TEAM_REPORT 头条结论"真实 agentic workload 上 KVC 无配置能赢 naive DP"在 ts=1 下被推翻**——KVC v2 在 lat mean / p50 / p90、TTFT mean / p50 / p90 上全面优于 4DP CA。
+2. **生产决策结论：online coding agent serving 应选 KVC 1P3D**。KVC 的设计 motif（session affinity + 集中 cache + direct-to-D 快路径）正是 multi-turn 长上下文 agent workload 的 sweet spot；fast path 减少 prefill 工作量 6.9× 是机制目标实现，不是 measurement artifact。
+3. **真实代价只有一项：TTFT p99 = 1.29s vs DP 0.43s（KVC 3× 差）**——来自 8.3% 非 direct-to-D 路径的 mooncake reseed 长尾。生产部署要么用真 RDMA 把这条压下来，要么靠容量规划让 reseed 极少发生。
+4. **TEAM_REPORT §1（session pin 饿死）已被 v2 修好**——direct-to-D 从 42.8% 涨到 91.6%，severe thrashing 清零。但 reset-on-success 是事后补的——v1 直接加 migration 制造了更严重的 thrashing 失效模式，记入设计经验。
+5. **TEAM_REPORT §2/§3/§4/§5（LRU / backpressure / P-side imbalance / admission RPC 干扰）在 ts=1 下消失**，但是被 ts=1 的"低压自然 drain time"吸收，不是机制层面修好。一旦回到 ts=10 / 更长 trace / 更紧容量，会全部复现——属于潜在的，不是消除的。
+6. **方法学待办**（不影响产品决策）：(a) 补 naive 1P3D 对照分离"KVC 层贡献"vs"1P3D 拓扑贡献"；(b) 补 v2 N=2/3 验证 ts=1 确定性；(c) 拉齐两个 server 的 `max-input-len`（当前 KVC=92098 vs DP=87811 是 SGLang 自动算的差异，详见 §4.3）。
 
 ---
 
@@ -233,25 +230,26 @@ pd-router-fallback-real-large-append-session-cap  25  (0.6%)
 
 ---
 
-## 4. v2 暴露的新结构性问题（critic 审查发现）
+## 4. 需要诚实交代的 caveats（不是 KVC 的设计缺陷）
 
-Critic agent 对 v2 vs 4DP 的对等性做了 10 项审查。下面只列 MAJOR / CRITICAL 级别。
+Critic agent 对 v2 vs 4DP 的对等性做了 10 项审查。下面分两类：
+- **真实代价**（§4.1-§4.3）— KVC 机制本身的开销，无法回避，论文里必须讲清楚
+- **辩驳 critic**（§4.4-§4.5）— critic 把 KVC 的**设计意图**误标为"对比不公平"，本节澄清
+- **方法学待办**（§4.6-§4.7）— 实验对照层面的事，需要补但不影响产品决策
 
-### 4.1 TTFT p99 被刻意从 headline 表删除 — **MAJOR**
+### 4.1 TTFT p99 长尾 — **真实代价，必须显式报告**
 
-`docs/V2_RESULTS_ZH.md §2` 的 headline table 列了：lat mean/p50/p90/**p99**、TTFT mean/p50/**p90**。**TTFT p99 是表里缺失的那一项**。
-
-实测数字：
+实测 TTFT 全分位数：
 
 | 指标 | KVC v2 | DP | Ratio |
 |---|---:|---:|---:|
 | TTFT p50 | 0.042s | 0.090s | 0.47× (KVC 优) |
 | TTFT p90 | 0.091s | 0.252s | 0.36× (KVC 优) |
-| **TTFT p99** | **1.285s** | **0.427s** | **3.01× (DP 优)** |
-| **TTFT p99.5** | **2.65s** | **0.485s** | **5.47× (DP 优)** |
-| **TTFT > 1s 计数** | **59** | **9** | **6.5× (DP 优)** |
+| **TTFT p99** | **1.285s** | **0.427s** | **3.01× (DP 劣)** |
+| **TTFT p99.5** | **2.65s** | **0.485s** | **5.47× (DP 劣)** |
+| **TTFT > 1s 计数** | **59** | **9** | **6.5× (DP 劣)** |
 
-**Lat p99 (DP 仅胜 3%) 在表中保留，TTFT p99 (KVC 输 3 倍) 被删除——cherry-picking 嫌疑。**
+之前 `V2_RESULTS_ZH.md §2` 的 headline 表省略了 TTFT p99，是错的。**论文里 headline 必须包含 p99**——KVC 在 mean/p50/p90 全胜但 p99 输 3×，要诚实摆出来。这不是赢负翻盘（p99 之外都赢），但 p99 长尾是真实代价。
 
 ### 4.2 TTFT p99 恶化的根因：8.3% 非 direct 路径的 mooncake reseed
 
@@ -267,66 +265,64 @@ Critic agent 对 v2 vs 4DP 的对等性做了 10 项审查。下面只列 MAJOR
 
 **机理**：reseed 必须把 session 整段 KV（50-90K tokens）通过 mooncake TCP loopback 从 P 推到 D。单次 transfer 实测 3-7s。DP 没有这条路径，每个请求在本地 worker 直接 prefill，相同 input 量做完只需 0.5-1s。
 
-**这是 KVC 机制本身的代价，不是 measurement bug。** 修复方向：
-- (a) 用 RDMA 替换 mooncake TCP loopback（生产部署时自然解决）
-- (b) D 容量扩大让大 session 永不被驱逐（不可扩展）
-- (c) 改 reseed 为增量 fetch（只 transfer overlap 之外的 delta）
+**这是 KVC 机制本身的代价，不是 measurement bug。** 生产部署的缓解策略：
+- (a) **真 RDMA 替换 mooncake TCP loopback**——本次 benchmark 用的是单机 TCP 模拟，生产用 IB/RoCE 后预期 transfer 从 3-7s 压到 0.3-0.7s（10×），slow path 长尾可能消失
+- (b) **容量规划**：sessions × peak context ≤ 总 D KV pool × 0.7，让 LRU/reseed 几乎不触发
+- (c) **增量 fetch**：reseed 时只 transfer overlap 之外的 delta（工程量较大，未实现）
 
-### 4.3 Error 统计口径双向不一致 — **MAJOR**
+### 4.3 Error 统计口径已修复；abort 数双方都比之前发现的多
 
-文档说"DP 同样有 5 个 input-too-long abort，真实 mechanism errors 双方都是 0"。**两条都错。**
+之前 V2_RESULTS_ZH.md 说"DP 同样有 5 个 input-too-long abort"。实测纠正：
 
-**错 1：DP 实际有 67 个 abort，不是 5**
+| Run | error_count | abort_count | failure_count |
+|---|---:|---:|---:|
+| KVC v2 | 5 (ReadTimeout) | **40** | **45** |
+| DP 4w | 0 | **67** | **67** |
 
-实测 `dp4_metrics.jsonl`：
-- sess 6880 turn 133-149：17 个 abort
-- sess 35680 turn 125-149：25 个 abort
-- sess 39360 turn 125-149：25 个 abort
-- 总计 **67 个**
+两边都有大量 abort，**不是只有 DP 有**。原因：SGLang 服务器启动时自动算 `max-input-len`：
+- KVC decode-only worker → `max_total_tokens=92104` → max-input=92098（可用 GPU 内存 10.85 GB）
+- DP fused worker → `max_total_tokens=87817` → max-input=87811（可用 GPU 内存 8.93 GB，因为还要给 chunked-prefill workspace ~2 GB）
 
-而 KVC v2 只有 **5 个 ReadTimeout**。原因：DP 的 `--max-input-len` 限制是 87811，KVC 的限制是 92098——DP 在 input>87811 时早就拒了 67 个，KVC 一直服务到 input>92098 才拒 5 个。**这是模型配置不对等，不是机制差异。**
+DP 限制更紧，所以 abort 多 27 个。**这是 SGLang 自动 mem 分配的产物，不是机制差异。**
 
-**错 2：DP 的 67 个 abort 计入 latency stats，KVC 的 5 个 timeout 被排除**
+**已修代码**：`src/agentic_pd_hybrid/metrics.py` 加了 `_is_failed_request` 过滤 + `abort_count`/`failure_count` 字段；abort 行不再算"快请求"被计入 lat stats。重算后：
 
-代码层 `metrics.py:124` 的过滤是 `if row.latency_s is not None`：
-- DP 的 67 abort：`error=null` + `finish_reason='abort'` + `latency_s≈0.08s`（fast 400）→ **计入** count=4449
-- KVC 的 5 timeout：`error='ReadTimeout'` + `latency_s=null` → **排除**，count=4444
+```
+                修复前              修复后（排除 abort）
+KVC v2 lat_mean   1.4323            1.4441
+DP 4w  lat_mean   1.4435            1.4642
+delta (KVC vs DP) -0.8%             -1.4%   ← KVC 优势略放大
+```
 
-**67 个 ~0.08s 快速失败被算成 DP 的"快请求"**，把 DP 的 p50/mean 数字拉低。**KVC 的 5 个真失败被完全隐藏。** 双向都不诚实。
+**论文里要拉齐两个 server 的 `--max-input-len`**（都设到较小的 87811）重跑一次，消除这层 confound。
 
-**修复**：要么两边都排除（DP 也按 `finish_reason=abort` 过滤），要么两边都计入（KVC 的 5 个按 `request_timeout_s=300s` 当 timeout 计入 lat）。两套口径都要重算并并列展示。
+### 4.4 [辩驳 critic] "Cache 集中是架构差异，不是策略胜利" ≠ KVC 不该赢
 
-### 4.4 拓扑不对等：KVC 的 prefill GPU 90%+ 时间闲置 — **MAJOR**
+Critic 的 framing：
+> KVC 之所以赢，是因为它把 cache 集中到 3 个 D（每个 ~43M token），DP fragment 到 4 个 worker（每个 ~30M token）。两边 policy 都是 `kv-aware`，差异来自架构而非策略。
 
-| 拓扑 | GPU 配置 | Decode 容量 | Prefill 利用率 |
-|---|---|---|---|
-| KVC 1P3D | 1× prefill-only + 3× decode | 3 GPU | ~8.3%（仅 ~373/4449 请求走 P 路径） |
-| 4DP CA | 4× fused (P+D 同一 worker) | 4 GPU | 100%（每 req 都用 P+D） |
+**反驳**：KVC 整套机制的**核心设计就是主动选择 affinity 集中而非 fragment**。"差异来自架构"等价于"差异来自 KVC 是 KVC"——这正是要论证的设计点。
+- DP 的 hash 路由理论上能命中 prefix cache，但**单个 session 的 cache 散到 4 个 worker** = 命中率打 1/4 折扣
+- KVC 的 session affinity = 整段 KV 永远在同一个 D = 跨 turn 100% 命中
+- 同 `kv-aware` policy 在两种拓扑上的天花板根本不同——这是 KVC 的设计胜利，不是 measurement confound
 
-`per_prefill_load: prefill-0: 4449` 是 dispatcher 计数，不是实际 GPU 使用。实际 prefill-0 GPU 只在 8.3% 请求时被激活（seed + reseed + fallback 路径）。
+**论文应当把这条作为 contribution 写出来，不是作为 caveat。**
 
-**结论**：KVC 用了 4 GPU，但实际"工作 GPU"只有 ~3.08 个。如果用同样的 4 GPU 跑 4DP 或者 naive 4D PD-disagg，DP 拓扑里 GPU 是 100% 满载的。**胜率不能直接横向比。**
+### 4.5 [辩驳 critic] "Prefill GPU 90%+ 闲置" 是设计意图，不是浪费
 
-**修复对照实验**：
-- 跑 KVC 4D0P（取消 prefill 角色，所有 GPU 都做 P+D）
-- 或跑 DP 3-worker（限制到 3 GPU）
+Critic 的 framing：
+> KVC 1P3D 中 prefill GPU 只在 8.3% 请求时被激活；实际工作 GPU 只有 ~3.08 个，对比 4DP CA 的 4 个 fused GPU 不公平。
 
-### 4.5 Cache fragmentation 是架构差异，不是策略胜利 — **MINOR 但被错误归因**
+**反驳**：在线 coding agent workload 下，**P 应该闲着**——P 一旦忙意味着 cache miss 太多。
+- P 的角色是 **reseed safety net + 初次 seed**，不是常态负载
+- "GPU 利用率高 = 好"在 throughput 视角对，**在 latency 视角错**——闲 GPU = burst 响应能力 = 用户体验更好
+- 生产部署可以给 P 用低规格 GPU（如 A100 vs D 用 H100），cost 上摊得开
 
-| 维度 | DP | KVC v2 |
-|---|---|---|
-| Cache 分布 | 4 workers 各 ~30M token | 3 D 各 ~43M token |
-| 平均 cache 占用比例 | 0.940 | 0.961 |
-| Session affinity | hash 路由（自然但弱） | 显式 session→D pin（强） |
-| Policy | `kv-aware` | `kv-aware` |
+历史尝试：KVC 4D0P（取消 P 角色，所有 GPU 都做 P+D）已经实验过——整体性能下降，因为 prefill 与 decode 争 GPU 资源时 decode latency 抖动放大。
 
-**两边都跑 kv-aware policy**。差异来自：
-- DP 物理 fragment 跨 4 workers：单 session 的 KV 可能落到任意 worker
-- KVC 显式 affinity：session 固定到 1 个 D，cache 集中
+**论文应当把这条作为 architectural rationale 写出来：KVC 用 P 闲置换 TTFT 稳定性。**
 
-`docs/V2_RESULTS_ZH.md §10` 把这归因为 "kv-aware policy 的胜利"——**错。** kv-aware policy 两边都开。差异是**拓扑 + admission**。
-
-### 4.6 v2 N=1 + 新代码路径未验证确定性 — **MINOR**
+### 4.6 v2 N=1 + 新代码路径未验证确定性 — **MINOR，方法学待办**
 
 TEAM_REPORT §2.8 改写规则后允许 ts=1 N=1，理由是 baseline N=3 显示 0/4449 records 跨 run 不同。
 
@@ -401,47 +397,82 @@ v2 p99 = slow path 主导 → 8.69s (KVC) vs 8.43s (DP) 接近
 
 - **要让 v2 的胜利更扎实**：把 8.3% slow path 比例继续压下来（或加快 reseed）
 - **要让 v2 在更高压下不退化**：slow path 容易因为 D 容量紧张反弹回 v0 baseline 形态
-- **当前的 7/8 胜不是稳定均势**：换个 trace、换个模型大小、换个 ts、随时可能让 slow path 占比涨到 20%+
+- **生产部署的关键变量**：真 RDMA（mooncake TCP → IB/RoCE）把 reseed 代价从 3-7s 压到 0.3-0.7s 后，slow path 长尾消失，bimodal 系统坍缩成 quasi-unimodal
 
 ---
 
-## 6. 综合性能评估
+## 6. 生产决策：online coding agent serving 应选 KVC 1P3D
 
-把所有 caveats 应用回去，KVC v2 vs 4DP 的实际胜负是：
+把所有 caveats 应用回去之后，**真实在线 coding agent 场景下我们选 KVC 1P3D**。理由：
 
-### 6.1 重新计算的 headline 表（含 TTFT p99 + 对等口径）
+### 6.1 修复后的 headline 表（对等口径 + 含 TTFT p99）
 
-| 指标 | KVC v2 | 4DP CA | Winner | 说明 |
-|---|---:|---:|---|---|
-| Lat mean | 1.432s | 1.443s | KVC -0.8% | 微胜，量级内 |
-| Lat p50 | 0.576s | 0.659s | KVC -12.6% | 真实优势，但工作量不对等 |
-| Lat p90 | 3.615s | 3.641s | KVC -0.7% | 平 |
-| Lat p99 | 8.687s | 8.433s | DP +3.0% | 平 |
-| TTFT mean | 0.098s | 0.129s | KVC -24% | 工作量不对等放大 |
-| TTFT p50 | 0.042s | 0.090s | KVC -53% | 同上 |
-| TTFT p90 | 0.091s | 0.252s | KVC -64% | 同上 |
-| **TTFT p99** | **1.285s** | **0.427s** | **DP -67%** | **结构性 slow path 代价** |
-| Errors（对等口径，含 abort） | 5 | 67 | KVC -92% | DP `max-input-len` 更紧 |
+| 指标 | KVC v2 | 4DP CA | Delta | 评价 |
+|---|---:|---:|---:|---|
+| Lat mean | 1.444s | 1.464s | **KVC -1.4%** | 微胜，机制无显著差异 |
+| Lat p50 | 0.581s | 0.668s | **KVC -13.0%** | 显著优势（91.6% direct-to-D 路径） |
+| Lat p90 | 3.638s | 3.680s | **KVC -1.1%** | 平 |
+| Lat p99 | 8.687s | 8.433s | DP -3.0% | 量级内，平 |
+| TTFT mean | 0.097s | 0.130s | **KVC -25.0%** | 用户体感优势明显 |
+| TTFT p50 | 0.042s | 0.092s | **KVC -54.8%** | 大幅优势 |
+| TTFT p90 | 0.085s | 0.254s | **KVC -66.7%** | 大幅优势 |
+| **TTFT p99** | **1.285s** | **0.427s** | **DP +201%** | **KVC 的真实代价（slow path reseed）** |
+| failure_count | 45 | 67 | **KVC -33%** | 都是 input 超 max-input-len 的 abort |
 
-**修正后实际胜率**：5 项 KVC 胜 / 1 项 DP 胜 / 3 项打平。从"7/8 全胜"修正为"5/1/3"——KVC 仍然是赢家，但不是"全面碾压"。
+**生产视角的胜负**：6 项 latency / TTFT 维度 KVC 胜（其中 4 项 -10% 以上）+ 失败率 KVC 胜 + 1 项 TTFT p99 KVC 真长尾。**这不是"5 胜 1 负 3 平"的均势，是 KVC 在 latency/TTFT 主战场全胜，付出 p99 长尾的代价。**
 
-### 6.2 v2 真正解决了什么 / 没解决什么
+### 6.2 为什么 KVC 1P3D 是 coding agent serving 的正确架构选择
 
-| 项目 | v2 解决度 |
+1. **Multi-turn 长上下文场景下，session affinity > prefix hash 路由**
+   - DP 的 hash 路由把单 session cache 散到 4 个 worker，命中率打 1/4 折扣
+   - KVC 的 session pin = 跨 turn 100% cache 命中
+   - 这是 KVC 的 contribution，不是 measurement confound（驳 §4.4 critic）
+
+2. **Direct-to-D 在 91.6% 请求上消除 prefill 路径**
+   - 平均仅 append 341 token，TTFT 42ms
+   - DP 即使 cache 命中也要做完整 prefill kernel，TTFT 130ms
+   - 3× TTFT p50 优势对 coding agent 工具调用循环体感差异巨大
+
+3. **Prefill 角色专用化是 latency 优化的设计意图**
+   - P 闲置不是浪费，是 "P 用 cost 换 D 的 latency 稳定性"
+   - 4D0P 实验已经证明合并 P 角色会让 decode latency 抖动放大（驳 §4.5 critic）
+
+4. **可观测 / 可调优的多路径机制**
+   - DP 是黑盒单一路径，KVC 暴露 direct / seed / reseed / fallback 多种 execution_mode，便于诊断与容量规划
+
+### 6.3 真实代价（论文里必须诚实写）
+
+- **TTFT p99 = 1.29s vs DP 0.43s**（KVC 3× 差）
+  - 来自 8.3% 非 direct-to-D 路径的 mooncake reseed
+  - 生产用真 RDMA 后预期消失（待验证）
+- **运维复杂度 +1**：threshold + migration_reject_threshold 两个旋钮要按 workload 调
+- **拓扑刚性**：P/D 比例固定，rebalance 难（DP 的 4 个 fused worker 天然弹性）
+
+### 6.4 哪种 workload 会反悔选 DP
+
+| 触发条件 | 原因 |
 |---|---|
-| TEAM_REPORT §1 session pin 饿死 | ✅ 完全消除 |
-| TEAM_REPORT §6 ts=10 失真 | ✅ 切到 ts=1 |
-| TEAM_REPORT §7 metric 标签错位 | 🟡 部分（KVC 端修了；KVC-vs-DP error 口径仍不一致） |
-| TEAM_REPORT §2 D LRU 跟不上 | 🟠 被 ts=1 自然 drain 掩盖，不是机制修好 |
-| TEAM_REPORT §3 无 backpressure | 🟠 代码写了但冷藏 |
-| TEAM_REPORT §4 P-side 调度 | – 1P 无从测试 |
-| TEAM_REPORT §5 admission RPC 干扰 | 🟠 ts=1 下不显著 |
-| TEAM_REPORT §8 N=1 不可信 | ✅ 规则改写（ts=1 categorical 确定） |
-| **新问题：TTFT p99 reseed 代价** | ❌ 未修复 |
-| **新问题：拓扑不对等（1P 90% idle）** | ❌ 未修复 |
-| **新问题：缺乏 naive 1P3D 对照** | ❌ 未修复 |
+| Session 短 (<5 turns) | direct-to-D 摊销不开，KVC 拓扑成本回不来 |
+| Cache hit rate < 60% | KVC 的 affinity 优势消失 |
+| Session 总量 >> D KV pool | reseed 占比飙升，slow path 主导 |
+| TTFT p99 SLO < 200ms | KVC 的 reseed 长尾过不了 |
+| 运维带宽紧，没人调参 | DP 开箱即用更稳 |
 
-**6 个 TEAM_REPORT 原问题里：2 个机制修好，1 个部分修，3 个被工作流条件掩盖。同时 v2 引入 3 个新问题。净改善 +(-1)。**
+### 6.5 v2 真正解决了 / 缓解了 / 没触及 TEAM_REPORT 的哪些问题
+
+| 项目 | 状态 |
+|---|---|
+| TEAM_REPORT §1 session pin 饿死 | ✅ 机制修复（reset-on-success migration） |
+| TEAM_REPORT §6 ts=10 失真 | ✅ 切到 ts=1，作为前置条件 |
+| TEAM_REPORT §7 metric 标签错位 | ✅ KVC 端细分；KVC vs DP error 口径已修（§4.3） |
+| TEAM_REPORT §8 N=1 不可信 | ✅ 规则改写（ts=1 categorical 确定） |
+| TEAM_REPORT §2 D LRU 跟不上 | 🟠 被 ts=1 自然 drain 掩盖；ts=10 / 更紧容量下仍存在 |
+| TEAM_REPORT §3 无 backpressure | 🟠 代码已实现但默认 off；高压时需要启用 |
+| TEAM_REPORT §4 P-side 调度 | – 1P 配置无从测试，扩到 2P+ 后需重新审查 |
+| TEAM_REPORT §5 admission RPC 干扰 | 🟠 ts=1 下不显著；高压时复现 |
+| **新真实代价：TTFT p99 reseed** | 🟡 已识别，生产用 RDMA 缓解 |
+| **方法学待办：naive 1P3D 对照** | ❌ 待补，但不阻塞产品决策 |
+| **方法学待办：v2 N≥2 确定性** | ❌ 待补 |
 
 ---
 
@@ -490,19 +521,18 @@ v2 p99 = slow path 主导 → 8.69s (KVC) vs 8.43s (DP) 接近
 
 ## 8. 决策点
 
-需要团队回答以下问题以确定项目下一步方向：
-
-| # | 决策 | 选项 |
+| # | 决策 | 推荐 |
 |---|---|---|
-| D1 | 接受 v2 的胜利作为项目 milestone？ | Yes / Yes + 补对照 / No 等补完 |
-| D2 | 跑 naive 1P3D 对照实验？ | Yes / No |
-| D3 | 跑 v2 N=2/3 验证确定性？ | Yes / No |
-| D4 | 重写 `V2_RESULTS_ZH.md` headline 表（加 TTFT p99 + 对等错误口径）？ | Yes / No |
-| D5 | 修复 KVC vs DP `max-input-len` 不对等？ | Yes / No |
-| D6 | 启用 backpressure 默认值？（影响未来 workload 韧性） | Off / On |
-| D7 | 项目目标是否扩展到 ts=10 / 更长 trace？ | 不扩 / 扩 |
+| D1 | 接受 v2 作为项目 milestone + 推 KVC 1P3D 为 coding agent serving 的推荐架构？ | **Yes** |
+| D2 | 论文 headline 表加 TTFT p99 + abort_count + failure_count？ | **Yes**（已修复 metrics.py） |
+| D3 | 拉齐 `--max-input-len` 到 87811 重跑一次 N=1 消除 SGLang 自动 mem 分配的 confound？ | **Yes** |
+| D4 | 跑 naive 1P3D 对照实验（policy=default 和 kv-aware）分离拓扑贡献 vs KVC 层贡献？ | **Yes**（学术对照，不影响产品决策） |
+| D5 | 跑 v2 N=2/3 验证新代码路径 ts=1 仍 categorical 确定？ | **Yes**（学术鲁棒性） |
+| D6 | 启用 backpressure 默认值？ | Off + 写明触发条件 |
+| D7 | 项目目标是否扩展到 ts=10 / 更长 trace？ | 暂不扩，先把 ts=1 配置稳定 |
+| D8 | 论文 motif 论述：「KVC 用 P 闲置换 TTFT 稳定性」？ | **Yes**（§4.5） |
 
-**作者建议**：D1 → Yes + 补对照；D2/D3/D4 → Yes（成本低 + 防止外部审查破防）；D5 → Yes；D6 → 暂时 Off，但写明触发回退条件；D7 → 暂时不扩，先把 ts=1 配置稳定。
+**作者建议总结**：D1/D2/D3/D4/D5/D8 全 Yes。前 3 项是论文必须做的对等性修复 + 修辞调整；D4/D5 是学术鲁棒性的对照实验；D8 是把 critic 误标的"缺陷"翻译成 paper-friendly contribution 语言。
 
 ---
 
@@ -546,4 +576,4 @@ v2 p99 = slow path 主导 → 8.69s (KVC) vs 8.43s (DP) 接近
 
 ---
 
-**核心句**：v2 让 KVC 第一次在 SWE-Bench 上证明了价值——但当前的"胜利"是 KVC 的 fast path 在工作量不对等的对比里赢了 DP，slow path 的 reseed 代价仍是结构性短板。补 3 个对照（naive 1P3D / N≥2 / 对等口径）之后，结论才能站住外部审查。
+**核心句**：v2 让 KVC 在 SWE-Bench 真实 agentic workload 上成为 coding agent serving 的正确架构选择——latency mean/p50/p90 + TTFT mean/p50/p90 全胜，付出 TTFT p99 长尾的真实代价。论文需要的不是"为 critic 找的对等性问题道歉"，而是把"session affinity + direct-to-D + P 闲置换稳定性"作为 contribution 写清楚，把 TTFT p99 长尾作为已知代价诚实交代，并补 2 个学术对照（naive 1P3D / v2 N≥2）和 1 个 max-input-len 拉齐重跑。