diff --git a/docs/KVCACHE_CENTRIC_PROGRESS_ZH.md b/docs/KVCACHE_CENTRIC_PROGRESS_ZH.md
index 1215ce0..494432a 100644
--- a/docs/KVCACHE_CENTRIC_PROGRESS_ZH.md
+++ b/docs/KVCACHE_CENTRIC_PROGRESS_ZH.md
@@ -151,6 +151,45 @@ router 会将内部字段剥离，只把标准 `priority` 分别传给 P/D backe
 - 但 p99 仍未稳定改善，tail 仍由 P->D transfer/bootstrap timeout 主导。
 - 2P3D 不稳定，错误 17 个，不适合作为当前推荐配置。
 
+### 与默认 PD-disaggregation 的同配置对比
+
+为了避免和旧 2P2D/no-pressure 基线混比，补跑了同一 workload、同一 2P4D、同一 P `--max-total-tokens 90000`、同一 `time_scale=50`、同一 `request_timeout_s=180` 的默认 PD-disaggregation 基线。
+
+| 策略 | ok/total | mean | p50 | p90 | p99 | cached total | direct-to-D |
+|---|---:|---:|---:|---:|---:|---:|---:|
+| 默认 PD-disaggregation 2P4D | 316/316 | 29.210s | 28.940s | 47.434s | 52.605s | 8.165M | 0 |
+| KVC 2P4D latency-best | 312/316 | 26.442s | 27.759s | 38.197s | 47.970s | 7.882M | 11 |
+| KVC 2P4D seed-min2 | 316/316 | 26.729s | 25.840s | 43.589s | 50.426s | 8.337M | 3 |
+
+结论：
+
+- 如果只看成功请求延迟，KVC 2P4D latency-best 相比默认 PD：
+  - mean 改善约 9.5%；
+  - p50 改善约 4.1%；
+  - p90 改善约 19.5%；
+  - p99 改善约 8.8%。
+- 但 latency-best 有 4 个 `ReadTimeout`，全部来自 turn1 大 seed 的 P->D transfer/bootstrap timeout。
+- `kvcache_seed_min_turn_id=2` 可以消除这些错误，达到 316/316 成功，同时 mean/p50/p90/p99 仍然优于默认 PD。
+- 因此当前推荐分成两档：
+  - 追求最低 mean/p90：使用 KVC 2P4D latency-best。
+  - 追求稳定性：使用 KVC 2P4D seed-min2。
+
+### 进一步优化尝试
+
+在当前最佳配置基础上尝试了三个优化方向：
+
+| 策略 | ok/total | mean | p50 | p90 | p99 | 结论 |
+|---|---:|---:|---:|---:|---:|---|
+| KVC 2P4D latency-best | 312/316 | 26.442s | 27.759s | 38.197s | 47.970s | 延迟最优，但有 4 个 turn1 seed timeout |
+| transfer-cap4 | 304/316 | 27.961s | 29.785s | 38.730s | 45.192s | 不可取，实时 transfer queue snapshot 滞后，错误更多 |
+| disable-failed-session | 285/316 | 29.179s | 30.878s | 42.794s | 46.411s | 不可取，失败 session 降级会放大后端异常状态 |
+| seed-min2 | 316/316 | 26.729s | 25.840s | 43.589s | 50.426s | 稳定性最优 |
+| inflight0 | 316/316 | 29.497s | 31.186s | 43.498s | 48.022s | 太保守，几乎关闭 KVC 收益 |
+
+从错误明细看，latency-best 的 4 个错误全部是 turn1 seed timeout，每个都是约 1250 KV blocks 的大 seed。`seed-min2` 跳过 turn1 seed 后，错误全部消失，说明当前主要稳定性问题是启动阶段 seed 风暴，而不是后续 direct append 本身。
+
+transfer-cap4 没有效果，说明仅依赖 D worker 的实时 `decode_transfer_queue_reqs` 不够；并发请求可能同时读取到尚可的 snapshot，然后一起进入 P->D transfer，导致 backlog 在 admission 后形成。
+
 ## Ali filtered 当前状态
 
 Ali filtered small-append trace：
@@ -197,16 +236,19 @@ Kvcache-centric 在 Ali filtered 上曾出现 58-67 个 router 200 后挂住、
    - P 侧 reuse 提升后，E2E 不一定改善。
    - 主要原因是 D 侧 transfer/bootstrap pipeline 成为瓶颈。
    - 增加 D 可以降低 prealloc，但不能自动降低 transfer backlog。
+   - 当前同配置下 KVC 已经可以优于默认 PD，但必须在 latency-best 和 stable 两种策略之间取舍。
 
 ## 下一步优化方向
 
 1. transfer-aware admission：
    - seed/direct 不只看 D token capacity，也要看 `decode_transfer_queue_reqs`、`decode_prealloc_queue_reqs`、`decode_retracted_queue_reqs`。
    - 当 transfer queue 高时，应该主动走 PD fallback。
+   - 当前实验显示，单纯使用实时 transfer queue threshold 不够，需要配合本地 reservation。
 
 2. per-D transfer budget：
    - 对每个 D 设置 seed/reseed 并发上限。
    - 不能只按 session residency 或 token headroom 判断。
+   - 特别要限制 turn1 大 seed 的并发，避免启动阶段 seed 风暴。
 
 3. P/D ratio 联合调度：
    - 2P4D 当前最好，但 P queue 也随 D 增加而上升。