From 7568e041ffba6881589c7039969e99d8585d6de8 Mon Sep 17 00:00:00 2001
From: Gahow Wang <gahow.wang@gmail.com>
Date: Tue, 12 May 2026 05:28:06 +0000
Subject: [PATCH] docs(kvc): record real Ali KVC experiment results

---
 docs/REAL_ALI_KVC_EXPERIMENT_LOG_ZH.md | 514 +++++++++++++++++++++++++
 1 file changed, 514 insertions(+)
 create mode 100644 docs/REAL_ALI_KVC_EXPERIMENT_LOG_ZH.md

diff --git a/docs/REAL_ALI_KVC_EXPERIMENT_LOG_ZH.md b/docs/REAL_ALI_KVC_EXPERIMENT_LOG_ZH.md
new file mode 100644
index 0000000..a512c78
--- /dev/null
+++ b/docs/REAL_ALI_KVC_EXPERIMENT_LOG_ZH.md
@@ -0,0 +1,514 @@
+# Real Ali KVC 实验日志
+
+**分支**：`kvc-real-ali-iter-v1`，从 `kvc-debug-journey-v1-to-v4` checkout 出来。
+**日期**：2026-05-11/12。
+**环境**：单机 8x NVIDIA H20，SGLang xPyD，模型 `/home/admin/cpfs/wjh/models/Qwen/Qwen3-Coder-30B-A3B-Instruct`。
+**真实 trace**：`/home/admin/cpfs/wjh/ali-trace/trace-qwen3-coder-formatted/041715-041717.jsonl`。
+
+本日志记录真实 Ali workload 上的 KVC pd-hybrid 迭代。结论只按当前证据成立；`time-scale=10` smoke 和 KVC-friendly slice 不作为 full workload headline。
+
+## 1. 当前最新进展
+
+已新增真实 Ali trace 的固定样本和 sweep 管线：
+
+- `scripts/prepare_real_ali_samples.py`：从真实 Ali trace 生成可复现实验样本，保留真实 input/output/hash_ids/timestamp，可选择 rebase timestamp。
+- `scripts/sweep_real_ali_kvc.sh`：对同一 prebuilt sample 依次跑 DP cache-aware、PD-disaggregation、KVC、KVC+backpressure。
+- `benchmark-live --use-trace-as-sample`：直接 replay 指定 trace，避免不同策略重新采样导致不可比。
+- `replay-progress.jsonl` heartbeat：后续长跑会每 30s 写客户端侧进度，不轮询 `/server_info`，避免扰动 scheduler。
+- `prepare_real_ali_samples.py --max-sampled-duration-s`：为快速 smoke 生成 capped sample；只用于迭代，不用于 headline。
+
+已经完成的真实 Ali KVC-fit smoke：
+
+- 样本：`outputs/real-ali-kvc-iter/samples-balanced/ali-kvc-fit-smallappend.jsonl`
+- 179 requests，64 sessions，全部 multi-turn；turn2+ 共 115 个，direct-eligible ratio 100%。
+- `time-scale=10`，concurrency 32。
+- DP cache-aware、PD-disaggregation、KVC no-backpressure、KVC+backpressure 均已完成。
+
+## 2. 全量 Ali trace 画像
+
+`outputs/real-ali-kvc-iter/ali-full-profile.json` 显示：
+
+| 指标 | 数值 |
+|---|---:|
+| requests | 763,727 |
+| sessions | 555,905 |
+| multi-turn sessions | 39,247 |
+| turn2+ requests | 207,822 |
+| turn2+ direct-eligible ratio | 82.95% |
+| input p50 / p90 / p99 | 4,329 / 51,067 / 112,955 tokens |
+| output p50 / p90 / p99 | 93 / 826 / 5,616 tokens |
+| append p50 / p90 / p99 | 303 / 2,879 / 17,885 tokens |
+| inter-turn gap p50 / p90 / p99 | 4.65s / 38.68s / 1,133s |
+
+这个 profile 说明 KVC 有真实适用面：turn2+ 的 hash overlap 和小 append 很常见。但 full workload 里 single-turn session 极多，KVC 收益会被显著稀释；因此必须分 slice 报告，不能只报 KVC-fit 子集。
+
+## 3. 已跑样本
+
+### Continuous 15min cold-window session sample
+
+路径：`outputs/real-ali-kvc-iter/samples-window-900s-600req/ali-window.jsonl`
+
+- 600 requests，439 sessions，32 multi-turn sessions。
+- rebased duration：886.544s，覆盖约 15min。
+- turn2+ requests：161，direct-eligible：143，ratio 88.8%。
+- input p50 / p90 / p99：3,871 / 68,234 / 98,131。
+- output p50 / p90 / p99：85 / 712 / 5,195。
+- append p50 / p90 / p99：274 / 2,202 / 16,120。
+- inter-turn gap p50 / p90 / p99：4.656s / 19.376s / 63.575s。
+
+这是对 179-request KVC-fit smoke 的替代验证样本。它按 900s 窗口分成 15 个时间桶，轮转选择窗口内从 root 开始的整 session，直到达到 600 requests。这样避免 parent 缺失导致 `load_trace()` 把真实 session 切碎，也让请求覆盖整个 15min，而不是只取窗口开头 600 条。
+
+重要边界：它是 **cold-window / new-session-only** sample，不是完整 raw production window；它排除了窗口开始前已经活跃的 ongoing sessions。因此可以用于“600+ 请求、15min、真实混合负载”的稳定性验证，但不能单独代表全量 Ali production window。
+
+### KVC-fit small append
+
+路径：`outputs/real-ali-kvc-iter/samples-balanced/ali-kvc-fit-smallappend.jsonl`
+
+- 179 requests，64 sessions。
+- input p50 / p90：6,446 / 15,491。
+- output p50 / p90：112 / 1,159。
+- append p50 / p90：215 / 855。
+- overlap ratio p50 / p90：0.875 / 0.938。
+
+这是 KVC-friendly slice，用来验证机制上限和 microbenchmark 是否能迁移到真实 token/hash 序列。
+
+### Representative-mt / early multi-turn balanced
+
+路径：`outputs/real-ali-kvc-iter/samples-balanced/ali-representative-mt.jsonl`
+
+- 460 requests，64 sessions。
+- input p50 / p90：41,175 / 98,621。
+- append p50 / p90 / p99：272 / 1,979 / 13,900。
+
+这个样本更接近真实 multi-turn 压力，后续用于验证大上下文、大 resident KV 下是否仍能稳定。但它当前实现是“从 start_time 后取最早 64 个 multi-turn session”，不是严格随机或分层 representative；正式 headline 需要按 input/append/output/gap 分层抽样。
+
+### Capped smoke samples
+
+为避免少数真实长 gap 让 smoke 浪费大量 wall time，新增：
+
+- `outputs/real-ali-kvc-iter/samples-balanced-cap120s/ali-kvc-fit-smallappend.jsonl`：177 requests，64 sessions，duration 65.859s。
+- `outputs/real-ali-kvc-iter/samples-balanced-cap120s/ali-representative-mt.jsonl`：359 requests，64 sessions，duration 117.366s。
+
+这些样本去掉了 KVC-fit 原样本末尾 timestamp 3613s 和 5414s 的两个请求，因此只能用于快速工程迭代；正式对比仍应使用完整样本或真实连续窗口。
+
+## 4. 当前结果
+
+### 4.1 DP cache-aware vs KVC+backpressure, KVC-fit, time-scale=10
+
+| 策略 | Requests | Errors | Trunc | E2E mean | E2E p50 | E2E p90 | E2E p99 | TTFT mean | TTFT p50 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| 8-way DP cache-aware | 179 | 0 | 0 | 6.603s | 3.126s | 17.639s | 34.582s | 1.112s | 1.052s |
+| KVC 2P6D + worker admission + backpressure | 179 | 0 | 0 | 4.443s | 2.076s | 13.288s | 21.202s | 0.700s | 0.154s |
+
+Paired comparison（KVC - DP）：
+
+- overall E2E mean delta：-2.161s；p50 delta：-1.427s；152/179 wins。
+- turn2+ direct 子集：mean delta -2.503s；p50 delta -1.508s；103/115 wins。
+- turn2+ TTFT mean delta：-0.930s；p50 delta -0.887s。
+
+执行路径：
+
+- KVC turn1 seed：64 requests。
+- `kvcache-direct-to-d-session`：115 requests。
+- session reused：115。
+- actual KV transfer blocks：623。
+
+结构日志：
+
+- admission probes：179，全为 `ok`。
+- transfer queue depth：p50=0，p90=2，max=3。
+- backpressure event：0。
+
+解释：这轮证明的是 **KVC direct-to-D/session reuse** 在真实 Ali KVC-fit slice 上有正信号；不是证明 backpressure 有效，因为没有触发 backpressure。
+
+### 4.2 PD-disaggregation baseline, KVC-fit, time-scale=10
+
+| 策略 | Requests | Errors | Trunc | E2E mean | E2E p50 | E2E p90 | E2E p99 | TTFT mean | TTFT p50 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| PD-disaggregation 2P6D | 179 | 0 | 0 | 7.850s | 6.306s | 15.192s | 22.405s | 4.994s | 5.336s |
+
+Paired comparison（PD - DP）：
+
+- overall E2E mean delta：+1.247s。
+- p50 delta：+2.231s。
+- 46/179 faster，133/179 slower。
+
+解释：在这个 KVC-fit slice 上，普通 PD-disaggregation 明显弱于 8-way DP cache-aware。它付出了 P->D transfer 和拆分调度成本，却没有 KVC direct-to-D 的 bypass 收益。
+
+### 4.3 KVC no-backpressure 消融, KVC-fit, time-scale=10
+
+| 策略 | Requests | Errors | Trunc | E2E mean | E2E p50 | E2E p90 | E2E p99 | TTFT mean | TTFT p50 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| KVC 2P6D worker admission, no backpressure | 179 | 0 | 0 | 4.404s | 1.936s | 13.200s | 21.326s | 0.604s | 0.139s |
+
+Paired comparison：
+
+- KVC no-BP vs DP：mean delta -2.200s，p50 delta -1.434s，153/179 wins。
+- KVC no-BP vs PD-disaggregation：mean delta -3.447s，p50 delta -3.514s，163/179 wins。
+- KVC no-BP vs KVC+BP：mean delta -0.039s，p50 delta -0.005s，92/179 wins。
+
+结构分析：
+
+- direct-to-D rate：64.25%。
+- admission probes：179，全为 `ok`。
+- transfer queue depth：p50=0，p90=2，max=3。
+- pause_ms 全 0，backpressure event 0。
+
+解释：no-backpressure 与 +backpressure 几乎等价，说明本 slice 没有 D 压力；本轮提升来自 direct-to-D，不来自反压。
+
+### 4.4 Continuous 15min / 600-request window, time-scale=1
+
+样本：`outputs/real-ali-kvc-iter/samples-window-900s-600req/ali-window.jsonl`
+
+重要边界：这是 cold-window / new-session-only session sample，不是完整 raw window。它覆盖约 15min，且 `missing_parent_count=0`，但排除了窗口开始前已活跃的 ongoing sessions。
+
+运行结果：
+
+| 策略 | Requests | Errors | Trunc | E2E mean | E2E p50 | E2E p90 | E2E p99 | TTFT mean | TTFT p50 | TTFT p90 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| DP cache-aware 8-way | 600 | 1 | 0 | 13.942s | 5.222s | 29.299s | 151.183s | 6.162s | 1.746s | 19.176s |
+| PD-disaggregation 2P6D | 600 | 1 | 0 | 40.886s | 40.018s | 84.681s | 113.460s | 38.545s | 37.782s | 81.852s |
+| KVC 2P6D mem_fraction_static=0.82 | 600 | 53 | 0 | 12.386s | 4.225s | 37.998s | 78.234s | 10.078s | 2.674s | 27.774s |
+
+KVC 默认启动失败：
+
+- 默认 KVC 2P6D 在 H20 上两次启动 OOM，均未进入 replay。
+- 日志显示 decode/prefill worker 启动时只剩约 526MB，模型加载阶段 OOM。
+- `--load-format layered` 不支持 Qwen3-Coder-30B-A3B。
+- 使用 `--mem-fraction-static 0.82` 后 KVC 能启动并完成 replay，但这降低了 KV pool 容量，因此这轮 KVC 是 memory-constrained rerun。
+- 尝试 `KVC_SEED_MIN_TURN_ID=2` + `mem_fraction_static=0.82` 时，启动阶段 scheduler 被 SIGKILL，疑似 OS OOM killer，未进入 replay。
+
+Paired comparison（只在两边都有 latency 的 547 个 paired request 上计算）：
+
+- KVC vs DP：mean delta -1.335s，p50 delta -0.055s，p90 delta +19.371s，284 wins / 263 losses。
+- KVC vs PD：mean delta -28.341s，p50 delta -25.687s，p90 delta +2.834s，465 wins / 82 losses。
+
+KVC 结构数据：
+
+- execution modes：388 `pd-router-turn1-seed`，90 `kvcache-direct-to-d-session`，67 `pd-router-fallback-large-append-session-cap`，1 `pd-router-large-append-reseed`，1 `pd-router-turn1-d-backpressure`，53 `kvcache-centric` error rows。
+- direct-to-D rate：15.0%。
+- direct-to-D session 分布：413/439 sessions 在 0-20% direct rate；只有 6 sessions 在 80-100%。
+- admission probes：533；reason `ok` 531，`no-space` 2；queue depth p50=0，p90=2，max=5。
+- pause hint 非零 20 次，但没有 backpressure event，因为本轮 no-BP。
+
+KVC error breakdown：
+
+- 50 `ReadTimeout`。
+- 2 `HTTPStatusError 400 Bad Request` on `open_session`。
+- 1 context length error：同 DP/PD 的 `input_length=310521 > 262144`。
+- 错误主要集中在 turn1：50 turn1，3 turn2+。
+
+解释：
+
+1. KVC 相对普通 PD 仍明显更好，说明普通 P->D disaggregation 在真实 600-request 窗口上成本很高。
+2. KVC 相对 DP 只在 clean request 的 mean/p50 上有小幅正信号，但 p90 变差，而且 error_count 从 DP 的 1 增到 53。
+3. 因此在这个 600-request / 15min window 上，**KVC 不能算稳定提升系统**。主要问题不是 direct-to-D 快路径无效，而是该快路径覆盖率只有 15%，并且 turn1 seed / session admission / memory-constrained KV pool 引入大量 timeout。
+4. 这直接修正 179-request KVC-fit smoke 的结论：小样本证明 KVC 适用 slice 存在；600-request mixed window 证明当前实现还不能稳定服务真实混合 workload。
+
+## 5. 是否已经相对 pd-colocation/pd-disaggregation 取得提升
+
+当前只能下这个限定结论：
+
+1. **相对 PD-disaggregation：已经取得清晰提升。**
+   PD-disaggregation p50 6.306s，KVC no-BP p50 1.936s，KVC+BP p50 2.076s；TTFT p50 5.336s vs 0.139s/0.154s。收益主要来自 turn2+ 直接打到已有 D session，避免每轮 P 全量 prefill 和 P->D KV transfer。
+
+2. **相对强 DP cache-aware：在 KVC-fit slice 上有提升。**
+   KVC no-BP 和 KVC+BP overall mean/p50/p90/p99 都优于 DP，并且 paired wins 分别是 153/179 和 152/179。但这是 KVC-friendly、全 multi-turn、turn2+ 100% direct-eligible 的 slice，不代表 full Ali workload。
+
+3. **相对 full workload：尚未证明。**
+   全量 Ali 里 single-turn 占多数，且长上下文和长尾 output 较多。KVC 的收益面会被 single-turn 稀释，D resident KV 容量和 tail 稳定性会成为更强约束。
+
+4. **相对 600-request / 15min mixed window：尚未取得稳定提升。**
+   KVC clean E2E mean/p50 有正信号，但 error_count=53/600，p90 paired delta 相对 DP 变差。按“E2E + error/truncation”标准，这不能算系统性胜出。
+
+## 6. 提升来自哪里
+
+主要收益链路：
+
+1. turn1 seed 在 D 上建立 session。
+2. turn2+ 若 append 小、hash overlap 高，直接走 `kvcache-direct-to-d-session`。
+3. direct-to-D 避免 P worker 参与，不走 P->D KV transfer。
+4. D 只对 append suffix 做少量 prefill，已有前缀 KV 直接复用。
+
+这带来两个可观测收益：
+
+- TTFT 大幅下降：turn2+ direct 子集 TTFT mean 从 DP 的约 1.04s 降到约 0.112s。
+- E2E 下降：direct 子集 mean E2E 降低约 2.50s。
+
+另外，KVC 的 cached_tokens 统计显著更高：KVC mean cached tokens 5,992，DP mean 228。这说明它确实复用了大段真实前缀 KV。
+
+## 7. 遇到的问题与修复
+
+### 问题 1：通用 sampler 会被单个长 session 主导
+
+现象：真实 Ali session 分布长尾明显，duration-oriented 采样容易选出不均衡样本，导致策略比较不可重复或不代表多 session 竞争。
+
+修复：新增 `scripts/prepare_real_ali_samples.py`，按 session 上限和每 session turn 上限生成 balanced sample，并保留真实 token/hash/timestamp。
+
+### 问题 2：不同策略重新采样导致不可比
+
+现象：`benchmark-live` 原本会按参数重新采样，不同策略可能 replay 不同请求。
+
+修复：新增 `--use-trace-as-sample`，所有策略 copy 并 replay 同一个 prebuilt sample；后续 paired comparison 才有意义。
+
+### 问题 3：长 trace replay 中途没有进度
+
+现象：`request-metrics.jsonl` 和 summary 只在 replay 结束后写出，跑真实 pacing 时很难判断是正常等待还是卡住。
+
+修复：新增 `replay-progress.jsonl` heartbeat，每 30s 写 submitted/completed/inflight/errors/execution_modes。它只使用客户端本地状态，不访问 `/server_info`。
+
+### 问题 4：`/server_info` polling 会扰动 scheduler
+
+现象：旧 profiling 里 1Hz polling 曾明显改变错误数。真实 performance run 如果持续 poll pool，会把测量工具变成干扰源。
+
+修复：`scripts/sweep_real_ali_kvc.sh` 默认关闭 pool polling。容量类问题依赖结构日志和必要时单独 profile run，不混入 headline performance run。
+
+### 问题 5：backpressure smoke 没有触发 backpressure
+
+现象：KVC-fit smoke 中 transfer queue max 只有 3，所有 admission reason 都是 `ok`，pause_ms 全 0。
+
+结论：这轮不能证明 backpressure 有效，只能证明 direct-to-D 有效。需要更高 session 数、更大 resident KV 或更强并发的压力样本专门验证 backpressure。
+
+### 问题 6：环境和旧报告不一致
+
+现象：旧文档写的是 H100，本轮真实环境是 H20；模型路径也在 `/home/admin/cpfs/wjh/models/...`。
+
+处理：本日志按 H20 记录；跨文档比较时只看机制趋势，不把 H100/H20 的绝对 latency 混为同一实验。
+
+### 问题 7：continuous window 可能截断 session ancestry
+
+现象：按 timestamp 直接截窗口可能留下 parent turn 在窗口外的请求。对 KVC 来说，这会让 session reuse/turn chain 与真实 workload 不一致。
+
+处理：当前 continuous window 只作为待改进候选，不作为正式 headline。正式窗口需要保留 warmup ancestors，或显式保留原始 session chain 信息。
+
+## 8. 如果后续 full workload 效果不好，当前假设
+
+可能不是实现小 bug，而是方案适用面和资源约束共同导致：
+
+1. **single-turn 稀释收益**：全量 Ali session 中 single-turn 占多数，KVC seed 只带来成本，没有 turn2+ reuse。
+2. **长上下文挤占 D KV 池**：input p90 51K、p99 113K，resident KV 长尾会限制 D 上可同时保留的 session。
+3. **direct 不是免费 lunch**：turn1 seed、admission probe、session lifecycle 都有额外成本；只有后续 turns 充分复用时才摊薄。
+4. **D 端容量和 eviction 仍是核心风险**：旧 SWE 实验已经显示 session pinning + D 容量盲选会造成 starvation；early multi-turn balanced 样本可能复现。
+5. **普通 PD-disaggregation 很弱**：如果 KVC fallback 频繁退回普通 PD 路径，整体会被 P->D transfer 和高 TTFT 拖垮。
+6. **H20 显存余量不足会改变 KVC 条件**：默认 KVC 2P6D 启动 OOM，必须降 `mem_fraction_static` 才能完成 600-request run；这会进一步降低 D KV pool，放大 session-cap 和 timeout。
+
+## 9. 下一步验证顺序
+
+1. 补 sticky/session-affinity baseline，拆出“粘到同一个 D”和“KVC direct bypass”的贡献。
+2. 补 KVC `seed-min-turn-id=2` 或 no-turn1-seed，验证 turn1 seed 成本是否值得。
+3. 在 early multi-turn balanced 样本上跑 DP / PD / KVC no-BP / KVC+BP，验证大上下文真实 multi-turn 压力。
+4. 选小固定样本跑 `time-scale=1`，避免只在压缩 replay 条件下成立。
+5. 做包含 single-turn 的 continuous window，并处理窗口内 parent turn 缺失问题，再按 full Ali 分布加权报告。
+6. 对最终候选配置做 N>=3 rerun，报告方差；N=1 只作为 smoke。
+7. 针对 600-request window 优先跑 `seed-min-turn-id=2`，减少 single-turn turn1 seed；目标是先把 53/600 errors 降到接近 DP 的 1/600，再讨论 latency。
+   - 当前第一次尝试未进入 replay，启动阶段疑似 OS OOM；需要先解决 H20 启动显存/系统内存稳定性，或者降低 worker 数/模型内存占用。
+
+## 10. KVC error 根因与 multi-turn-only 验证准备
+
+用户指出 179-request run 不够，并要求至少 15min / 600+ 请求；当前正式问题定位基于
+`outputs/real-ali-kvc-iter/runs/window900s-600req-ts1-kvc-mem082/kvcache-centric-kv-aware-worker-admission-20260511T093601Z`。
+
+### 10.1 为什么 KVC 有大量 error
+
+该 run 为 600 requests，KVC mem0.82 有 53 errors：
+
+- 50 个 `ReadTimeout`。
+- 2 个 `/open_session` HTTP 400。
+- 1 个真实超上下文错误：input 310,521 > model context 262,144。
+
+按 turn 看，50/53 errors 在 turn1。按 structural admission 看，绝大多数失败请求在
+`structural/admission-events.jsonl` 中已经被 D 端 admission 判定 `can_admit=true`，所以这不是单纯的
+`d-session-cap` 或 `no-space`。主要失败点是 turn1 seed 进入 KVC seeded path 后，在
+P/D streaming session bootstrap、P->D transfer 或 router streaming 过程中超时；而混合真实窗口中 single-turn session 很多，
+这些 turn1 seed 对大多数 session 没有后续复用收益。
+
+结论：当前 KVC error 的主因是 **对 single-turn / 未知是否多轮的 session 做了过多 turn1 seed**，它把大量新 session 推进
+KVC control-plane 和 seeded router 路径，增加超时和 session lifecycle 残留；不是 direct-to-D fast path 本身出错。
+
+### 10.2 已做修复/消融开关
+
+代码与脚本修复：
+
+- `scripts/sweep_real_ali_kvc.sh` 新增 `KVC_SEED_ONLY_MULTITURN=1`，会传入
+  `--kvcache-seed-only-multiturn-sessions`。这是 oracle 消融，用来验证“只 seed 会有后续 turn 的 session”能否消除 turn1 seed 错误。
+- `src/agentic_pd_hybrid/replay.py` 对 `/open_session` 400 增加 close+retry 一次，并写
+  `structural/session-lifecycle.jsonl`。这是 lifecycle 健壮性修复，目标是处理 timeout 后服务端残留 session 导致的
+  “already exists” 400，不改变 routing policy。
+- `scripts/prepare_real_ali_samples.py` 新增 `--window-min-turns` 和 `--window-output-name`，用于生成可复现的 multi-turn-only window 样本。
+
+验证：
+
+- `uv run python -m py_compile scripts/prepare_real_ali_samples.py src/agentic_pd_hybrid/replay.py src/agentic_pd_hybrid/benchmark.py src/agentic_pd_hybrid/cli.py`
+- `bash -n scripts/sweep_real_ali_kvc.sh`
+
+### 10.3 已生成 multi-turn-only 样本
+
+样本路径：
+
+`outputs/real-ali-kvc-iter/samples-window-900s-600req-multiturn/ali-window-multiturn.jsonl`
+
+生成命令：
+
+```bash
+uv run python scripts/prepare_real_ali_samples.py \
+  --trace /home/admin/cpfs/wjh/ali-trace/trace-qwen3-coder-formatted/041715-041717.jsonl \
+  --output-root outputs/real-ali-kvc-iter/samples-window-900s-600req-multiturn \
+  --window-duration-s 900 \
+  --window-target-requests 600 \
+  --window-buckets 15 \
+  --window-min-turns 2 \
+  --window-output-name ali-window-multiturn.jsonl \
+  --profiles representative-mt \
+  --max-sessions 64 \
+  --max-turns-per-session 12
+```
+
+样本 profile：
+
+- 626 requests，107 sessions，107 个都是 multi-turn sessions。
+- sampled duration 889.341s。
+- turn2+ = 519。
+- direct-eligible turn2+ = 473 / 519 = 91.1%。
+- missing parent = 0。
+- input p50/p90/p99 = 26,846 / 91,596 / 123,898 tokens。
+
+这个 case 是“过滤掉 single-turn 的多轮压力切片”，不能替代 full mixed workload，但可以回答：
+如果 workload 确实以多轮 coding agent session 为主，KVC 的 direct-to-D 覆盖率和稳定性是否接近 microbenchmark。
+
+### 10.4 GPU 资源阻塞
+
+截至本次记录，8 张 GPU 均被另一组 `vllm serve` 进程占用，每张约 82GB / 98GB，端口为 51000-51007。
+这些不是本 repo 的 SGLang/benchmark 进程，因此未启动新的性能 run，避免把资源冲突误判为 KVC 策略失败。
+
+GPU 释放后，优先跑两组：
+
+```bash
+# 混合真实窗口：验证 seed-only-multiturn 是否把 53/600 errors 降下来
+TRACE=outputs/real-ali-kvc-iter/samples-window-900s-600req/ali-window.jsonl \
+OUT_ROOT=outputs/real-ali-kvc-iter/runs/window900s-600req-ts1-kvc-seedonly-mt-mem082 \
+RUNS="kvc" \
+TIME_SCALE=1 \
+CONCURRENCY=32 \
+REQUEST_TIMEOUT_S=600 \
+STACK_TIMEOUT_S=1800 \
+EXTRA_SERVER_ARGS="--mem-fraction-static 0.82" \
+KVC_SEED_ONLY_MULTITURN=1 \
+bash scripts/sweep_real_ali_kvc.sh
+
+# 多轮-only workload：DP vs KVC，对照过滤 workload 是否能复现 microbenchmark 收益
+TRACE=outputs/real-ali-kvc-iter/samples-window-900s-600req-multiturn/ali-window-multiturn.jsonl \
+OUT_ROOT=outputs/real-ali-kvc-iter/runs/window900s-600req-multiturn-ts1-mem082 \
+RUNS="dp kvc" \
+TIME_SCALE=1 \
+CONCURRENCY=32 \
+REQUEST_TIMEOUT_S=600 \
+STACK_TIMEOUT_S=1800 \
+EXTRA_SERVER_ARGS="--mem-fraction-static 0.82" \
+KVC_SEED_ONLY_MULTITURN=1 \
+bash scripts/sweep_real_ali_kvc.sh
+```
+
+### 10.5 multi-turn-only 启动尝试被 GPU 占用阻塞
+
+用户要求启动 multi-turn-only 的 `pd-disaggregation` vs `kvcache-centric` 对比。启动前检查发现 8 张 GPU 均被外部
+`vllm serve` 进程占用，每张约 84GB / 98GB，端口为 51000-51007。该进程不属于本 repo 的 SGLang/benchmark run。
+
+因此本次没有强行启动 SGLang。原因是剩余显存不足以启动 2P6D 或 8-worker 对照，强行运行只会得到初始化 OOM 或不稳定超时，
+不能用于判断 KVC pd-hybrid 是否优于 pd-disaggregation。
+
+资源释放后要运行的 multi-turn-only 对比命令：
+
+```bash
+TRACE=outputs/real-ali-kvc-iter/samples-window-900s-600req-multiturn/ali-window-multiturn.jsonl \
+OUT_ROOT=outputs/real-ali-kvc-iter/runs/window900s-600req-multiturn-ts1-pd-vs-kvc-mem082 \
+RUNS="pd kvc" \
+TIME_SCALE=1 \
+CONCURRENCY=32 \
+REQUEST_TIMEOUT_S=600 \
+STACK_TIMEOUT_S=1800 \
+EXTRA_SERVER_ARGS="--mem-fraction-static 0.82" \
+KVC_SEED_ONLY_MULTITURN=1 \
+bash scripts/sweep_real_ali_kvc.sh
+```
+
+### 10.6 multi-turn-only PD vs KVC 正式结果
+
+资源释放后已启动并完成 multi-turn-only 对比。运行命令：
+
+```bash
+TRACE=outputs/real-ali-kvc-iter/samples-window-900s-600req-multiturn/ali-window-multiturn.jsonl \
+OUT_ROOT=outputs/real-ali-kvc-iter/runs/window900s-600req-multiturn-ts1-pd-vs-kvc-mem082 \
+RUNS="pd kvc" \
+TIME_SCALE=1 \
+CONCURRENCY=32 \
+REQUEST_TIMEOUT_S=600 \
+STACK_TIMEOUT_S=1800 \
+EXTRA_SERVER_ARGS="--mem-fraction-static 0.82" \
+KVC_SEED_ONLY_MULTITURN=1 \
+bash scripts/sweep_real_ali_kvc.sh
+```
+
+Run 目录：
+
+- PD：`outputs/real-ali-kvc-iter/runs/window900s-600req-multiturn-ts1-pd-vs-kvc-mem082/pd-disaggregation-kv-aware-20260512T030433Z`
+- KVC：`outputs/real-ali-kvc-iter/runs/window900s-600req-multiturn-ts1-pd-vs-kvc-mem082/kvcache-centric-kv-aware-worker-admission-20260512T040444Z`
+
+样本仍是 626 requests、107 sessions、889.341s，全部为 multi-turn session。
+
+| 策略 | Requests | Errors | Trunc | E2E mean | E2E p50 | E2E p90 | E2E p99 | TTFT mean | TTFT p50 | TTFT p90 |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| PD-disaggregation 2P6D | 626 | 0 | 0 | 97.013s | 70.243s | 214.309s | 308.406s | 94.506s | 69.048s | 212.528s |
+| KVC 2P6D worker admission, no BP, seed-only-multiturn | 626 | 39 | 0 | 43.362s | 8.239s | 135.289s | 236.475s | 40.578s | 1.442s | 132.233s |
+
+Paired comparison 只在 KVC 成功且 PD 也有 latency 的 587 个 request 上计算：
+
+- PD same-request E2E mean/p50/p90/p99：97.457s / 70.514s / 214.095s / 309.362s。
+- KVC same-request E2E mean/p50/p90/p99：43.362s / 8.239s / 135.930s / 237.283s。
+- mean E2E reduction：55.5%。
+- absolute mean improvement：54.095s。
+- wins/losses：472 / 115。
+
+按 KVC execution mode 拆分：
+
+| KVC mode | Count | KVC mean | PD same mean | Reduction |
+|---|---:|---:|---:|---:|
+| `kvcache-direct-to-d-session` | 286 | 2.255s | 92.944s | 97.6% |
+| `pd-router-fallback-large-append-session-cap` | 169 | 88.869s | 113.614s | 21.8% |
+| `pd-router-d-session-reseed` | 25 | 143.456s | 106.501s | -34.7% |
+| `pd-router-large-append-reseed` | 19 | 47.631s | 88.981s | 46.5% |
+| `pd-router-turn1-seed` | 78 | 55.974s | 73.050s | 23.4% |
+
+按 turn 深度拆分：
+
+- turn2+：504 successful paired requests，KVC mean 40.791s vs PD mean 101.055s，reduction 59.6%。
+- turn>=5：299 successful paired requests，KVC mean 34.121s vs PD mean 104.697s，reduction 67.4%。
+- turn>=10：161 successful paired requests，KVC mean 39.027s vs PD mean 86.548s，reduction 54.9%。
+
+KVC execution modes：
+
+- `kvcache-direct-to-d-session`：286。
+- `pd-router-fallback-large-append-session-cap`：169。
+- `pd-router-turn1-seed`：78。
+- `pd-router-d-session-reseed`：25。
+- `pd-router-large-append-reseed`：19。
+- `pd-router-fallback-no-d-capacity`：4。
+- `pd-router-turn1-d-backpressure`：5。
+- `pd-router-d-session-reseed-after-eviction`：1。
+- error rows：39，记录为 `kvcache-centric`。
+
+KVC 的收益来源非常清楚：286 个 direct-to-D request 的 same-request mean 从 PD 的 92.944s 降到 2.255s，基本复现了 microbenchmark 的核心机制收益。它跳过 P worker 和 P->D KV transfer，只在已有 D session 上处理 append suffix。总体 actual KV transfer blocks 从 PD same-success 的 4436 降到 KVC success 的 3827；summary 口径下 KVC total actual KV transfer blocks 为 3827，低于 PD 的 5276。
+
+但这轮仍不能作为“稳定生产级胜出”结论：
+
+1. KVC 仍有 39/626 errors，error rate 6.23%，PD 为 0。
+2. 39 个错误全部是客户端 `ReadTimeout`，不是服务端 OOM/Traceback；服务端日志未发现对应崩溃关键字。
+3. 错误分布：24 个 turn1，15 个 turn2+；按 decode 节点分布为 decode-0 15、decode-1 9、decode-3 7、decode-4 5、decode-5 3。
+4. 8 次 `/open_session` 400 已被 close+retry 兜住，并写入 `structural/session-lifecycle.jsonl`，没有形成 HTTP 400 error row。
+5. 长尾 drain 明显：PD 约 60min 完成，KVC 约 40min 完成；二者都远超 889s trace duration。KVC 在 900s 时已完成 490/626，而 PD 只完成 283/626，说明 KVC 中段吞吐更好，但最后几十个 large-append fallback 仍然拖尾。
+6. direct-to-D 覆盖率为 286/626 = 45.7%，低于样本静态 direct-eligible turn2+ ratio 91.1%。缺口主要来自 D session/residency capacity、large append session cap、reseed/fallback。
+
+当前判断：
+
+- 如果只看 successful paired request，multi-turn-only workload 上 KVC 相对 PD-disaggregation 已经有很强 E2E 提升，且提升主要来自 direct-to-D session reuse。
+- 如果按系统可靠性看，当前实现还不合格，因为 6.23% timeout 会抵消“稳定系统”的结论。
+- 真实 workload 与 microbenchmark 差距的主要原因不是 KVC fast path 无效，而是 fast path 覆盖率不足、D 侧 resident KV/session admission 压力、large append fallback、以及 seeded/reseed path 的 timeout 稳定性。