docs(kvc): add GPU-utilization and cache-efficiency figures (rebut critic)

Two figures inserted into V2_DEEP_ANALYSIS §4.5 and §4.4 respectively, to
visually rebut the two critic-agent claims that we argued in prose were
design intent, not deficiencies.

(1) gpu_utilization.png  -- §4.5  "P GPU is wasted 90% of the time"
  Two-panel side-by-side:
    Left  (request count view, the naive reading): KVC P = 328 reqs (7.4%),
          KVC D = ~1450 each, DP = ~1100 each. P "looks idle."
    Right (compute work view, the honest reading): KVC P does 1.07M tokens
          of prefill, comparable to each KVC D worker's ~0.80M. P is a
          low-frequency high-cost safety net, not idle capacity.
  Bonus finding: KVC's total compute (3.47M tokens across 4 GPUs) is 33%
  LESS than DP's (5.17M). Same GPUs, less work done. That's the affinity
  win.

(2) cache_efficiency.png  -- §4.4  "Cache concentration is not policy win"
  Two-panel side-by-side. The setup: KVC has 27% LESS total KV pool
  (276K vs 351K tokens) yet caches MORE per request.
    Left  (cache hit rate vs turn number): KVC's session-affinity lets
          hit rate accumulate with turns; DP's hash + radix-LRU causes
          a mid-turn drift around turns 8-25 where KVC = 97.0% vs DP
          = 95.8% (1.24pp gap). Shows mechanism, not just outcome.
    Right (ECDF of per-request uncached tokens, log x): KVC's distribution
          concentrates near zero (50% < 187 tokens), DP's is spread
          (50% < 781 tokens). At uncached = 500 tokens threshold, KVC
          has 74% of requests below, DP has 31%.
  → smaller pool, better retention, less per-request work. Direct empirical
  rebuttal to "fragmentation is architectural, not policy."

Bundled scripts (rerunable):
- scripts/analysis/plot_gpu_utilization.py
- scripts/analysis/plot_cache_efficiency.py

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

docs/V2_DEEP_ANALYSIS_ZH.md

@@ -312,26 +312,49 @@ delta (KVC vs DP) -0.8%             -1.4%   ← KVC 优势略放大
 Critic 的 framing：
 > KVC 之所以赢，是因为它把 cache 集中到 3 个 D（每个 ~43M token），DP fragment 到 4 个 worker（每个 ~30M token）。两边 policy 都是 `kv-aware`，差异来自架构而非策略。
 
-**反驳**：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
+**反驳**：KVC 整套机制的**核心设计就是主动选择 affinity 集中而非 fragment**。"差异来自架构"等价于"差异来自 KVC 是 KVC"——这正是要论证的设计点。更重要的：**KVC 的总 KV pool 实际上比 DP 少 27%**（KVC 3×92K=276K vs DP 4×87K=351K tokens），但 cache 命中率仍然更高（98.1% vs 96.8%）。
 
-**论文应当把这条作为 contribution 写出来，不是作为 caveat。**
+![Cache efficiency paradox: KVC 用更少的总池子缓存更多](figures/cache_efficiency.png)
+
+**左图 — 命中率随 turn 的演化**揭示了 cache 效率不是"总池子大小"决定的，是"留什么"的策略决定的：
+- KVC 的 session affinity → cache 在被钉定的 D 上**随 turn 累积**，hit rate 单调上升
+- DP 的 hash 路由 + radix LRU → 跨 session 共享 87K pool，hit rate 在 turn 8-25 区间（KVC 97.0% vs DP 95.8%，差 **1.24pp**）出现"中段 drift"
+- 后期两边都稳定在 ~98-99%（session 长时间没换，cache 反复命中），但 DP 的 IQR band 更宽 → 不同请求 / 不同 session 之间命中波动更大
+
+**右图 — uncached tokens 的 ECDF** 量化了 per-request 影响：
+- KVC 50% 请求 uncached ≤ **187 tokens**，DP 50% 请求 uncached ≤ **781 tokens**（4× 差距）
+- 在 uncached = 500 tokens 阈值上：**KVC 74% 请求落在该阈值以下，DP 只有 31%**
+- KVC 的曲线 "撞墙" 在 ~200 token 处快速爬到 0.5；DP 的曲线在 100-10K 区间均匀展开
+
+→ 论文里这是 **contribution**，不是 caveat：KVC 的 mechanism 让 27% 更少的总池子产生了更高的 retention 效率。
 
 ### 4.5 [辩驳 critic] "Prefill GPU 90%+ 闲置" 是设计意图，不是浪费
 
 Critic 的 framing：
 > KVC 1P3D 中 prefill GPU 只在 8.3% 请求时被激活；实际工作 GPU 只有 ~3.08 个，对比 4DP CA 的 4 个 fused GPU 不公平。
 
-**反驳**：在线 coding agent workload 下，**P 应该闲着**——P 一旦忙意味着 cache miss 太多。
-- P 的角色是 **reseed safety net + 初次 seed**，不是常态负载
-- "GPU 利用率高 = 好"在 throughput 视角对，**在 latency 视角错**——闲 GPU = burst 响应能力 = 用户体验更好
-- 生产部署可以给 P 用低规格 GPU（如 A100 vs D 用 H100），cost 上摊得开
+**反驳**：按"请求计数"看 P 确实稀疏，但按"实际工作量"看 P 的负载和每个 D 相当——P 是**低频高 cost 的 safety net**，不是 idle 容量。
 
-历史尝试：KVC 4D0P（取消 P 角色，所有 GPU 都做 P+D）已经实验过——整体性能下降，因为 prefill 与 decode 争 GPU 资源时 decode latency 抖动放大。
+![Per-GPU utilization: 请求计数视图 vs 工作量视图](figures/gpu_utilization.png)
 
-**论文应当把这条作为 architectural rationale 写出来：KVC 用 P 闲置换 TTFT 稳定性。**
+**左图 — 请求计数视图**：KVC P GPU 仅处理 328 个请求（7.4%），而 KVC D 各处理 ~1450 个（33%），DP 各处理 ~1100 个（25%）。**乍看像 critic 说的"P 闲着"**。
+
+**右图 — 工作量视图（compute tokens）**：
+- KVC P GPU：**1.07M tokens 的 prefill 工作**（仅 prefill，无 decode）
+- KVC D GPU 每个：~0.80M tokens（小量 append-prefill + 全部 decode）
+- DP 每个 worker：~1.30M tokens（全套 prefill + decode）
+
+→ **KVC P GPU 的 per-GPU 工作量与每个 KVC D GPU 相当**——只是分布在少数（328）个高强度请求上（每个 reseed 5K-90K tokens）。它不是空转，是 **low-frequency, high-cost safety net**。
+
+**总工作量对比**：
+- KVC 4 个 GPU 合计 ~3.47M tokens 工作
+- DP 4 个 GPU 合计 ~5.17M tokens 工作（**KVC 减少 33% compute**——这是 session affinity 带来的 cache 复用收益）
+
+这两点综合：KVC 用 **同样 4 个 GPU、更少总 KV pool、更少总 compute**，做到了 latency / TTFT mean/p50/p90 全胜。
+
+**论文应当把这条作为 architectural rationale 写出来：KVC 用 P 的低频专用化换 D 端的 TTFT 稳定性。**
+
+历史尝试佐证：KVC 4D0P（取消 P 角色，所有 GPU 都做 P+D）已经实验过——整体性能下降，因为 prefill 与 decode 争 GPU 资源时 decode latency 抖动放大。
 
 ### 4.6 v2 N=1 + 新代码路径未验证确定性 — **MINOR，方法学待办**