# EXP-CODE-TRACE：从 chat 1h trace 扩展到 code 与 phase-separated replay

> **状态：READY_FOR_DATA PREFLIGHT，未启动 GPU。** 当前只完成本地适配与实验冻结；`dash1`--`dash4` 有整机空闲后按本文 gate 顺序推进。禁止使用 `dash0`。

## 目标与成功定义

当前 1h+ 证据只覆盖 Qwen3-30B-A3B 的生产 chat trace、prefill+decode（P+D）和亚临界负载。本 campaign 分两步扩展：

1. **主任务：** 使用 `~/ali-trace/trace-glm5.1-formatted/` 中的 1h+ code trace，先完成 P+D real-vs-Frontier 回放；
2. **后续 phase matrix：** 对 chat/code 都补 prefill-only 和严格 decode-only。

本轮不是只看“能否跑完”。每个正式 cell 必须满足：同一 request vector、同一 arrival、同一 token shape、同一 prefix/initial-KV 合约、real 零失败、无持续 backlog，并同时报告 TTFT/TPOT/E2E、queue/batch、KV/prefix state 与 5min 分窗漂移。

## 三种 workload mode 的冻结定义

| Mode | 保留 | 改写 | 主指标 | 明确不声称 |
|---|---|---|---|---|
| P+D | 原 ISL/OSL、arrival、session/prefix | 仅做 source block→16-token runtime block 映射 | TTFT、TPOT、E2E、hit ratio、batch/queue | 不代表 PD 分离 |
| prefill-only | 原 ISL、arrival、session/prefix | OSL 固定为 1，real `min_tokens=max_tokens=1`，sim decode tokens=1 | TTFT、prefill service/tokens/s、prefix hit、queue | TPOT 不定义；1-token decode 只用于完成请求 |
| strict decode-only | 原 OSL、context length、arrival burst | arrival 定义为 **KV-ready time**；请求进入 decode 时已有 ISL 长度的 initial KV | TPOT、decode tokens/s、batch/queue、preemption | 不包含 prefill 与 KV transfer latency，不把短 prompt proxy 称为 decode-only |

strict decode-only 必须同时具备：

- real：vLLM `DecodeBenchConnector`（或等价、经验证的 initial-KV 注入）；
- sim：Frontier request 在 admission 时已拥有相同长度/块布局的 computed KV；
- 两侧都不在 decode critical path 重做 prefill；
- arrival 以 KV-ready time 对齐。若只保留原 trace 的相对到达形状，结论限定为 decode engine compute/scheduling fidelity。

在该合约完成前，只允许跑并标注为 **decode-dominant proxy**，不能进入 strict decode-only 结果表。

## 为什么 code P+D 不能直接复用 chat 配置

已知历史探查显示 code trace ISL p90 约 81.9k，约 32.6% 请求超过旧 `40960` 上限；真实数值必须由本 campaign 重新审计。至少有四个独立适配面：

1. **Serving cap：** `max_model_len` 必须覆盖 `ISL+OSL`，不能只看 ISL，也不能静默丢掉超长请求；
2. **KV capacity：** Qwen3-30B 模型 position limit 为 262144，但 TP1/2/4 在 H20 上是否有足够 KV blocks 是 runtime gate，不由 config.json 自动保证；
3. **Prefix block：** code source hash 预计为 512-token block，chat harness 原先固定 64→16；
4. **Profile support：** 当前修复后的 attention profile 只覆盖到约 32k KV context。即使 vLLM 能跑 128k，Frontier 对 32k–128k 仍会出 profile 支撑域；在补 long-context 网格前只能做诊断 replay，不能做 fidelity claim。

## Hypotheses

- **H-code-generalizes：** 在补齐 long-context profile 支撑域后，code P+D 的 TTFT/TPOT/E2E 分布统计偏差仍处于当前 chat 量级，且 1h 残差不发散。
- **H-longctx-gap：** code 的主要新增 gap 来自 32k 以上 KV-context 外推；补到 trace p99/max 对应的网格后，TTFT bias 随 ISL 的二次项显著收敛。
- **H-phase-specific：** prefill-only 主要暴露 long-context/profile gap；strict decode-only 主要暴露 batch-conditioned whole-layer service 与 scheduler fixed-point gap。二者不能用 P+D 的误差抵消来互相证明准确。

## Preflight gates（按顺序，任一失败即停止后续真机矩阵）

### G0：数据位置与 provenance

- 只读列举 `trace-glm5.1-formatted/*.jsonl`，记录文件大小与 SHA256；
- 确认至少两个独立日期段：一个作为 development，一个 held-out；
- 本机当前没有该目录；仓库历史记录的远端位置为
  `/home/admin/cpfs/wjh/ali-trace/trace-glm5.1-formatted/`。恢复机器后先确认 `~/ali-trace/...` 是否为同一路径/软链，不能假设。

### G1：1h window、schema 与 block contract

运行 `audit_code_trace.py`，要求：

- timestamp 单调，存在 60–75min 连续稳定窗口；
- `timestamp/input_length/output_length` 全行存在；
- `input_length<=0` 或 `output_length<=0` 的行不进入 replay，但必须计数并保留样例。已抽查的两条 0→0 行在 raw trace 中同时满足 `usage.total_tokens=0`、`response_message={}`，属于未发生模型执行的 source request，不是 full-cache decode；
- `hash_ids` 数量与某个 source block size 在全行严格满足
  `ceil(ISL/source_block_size)`；预计值 512，但以审计结果为准；
- 记录 ISL/OSL/ISL+OSL 的 p50/p90/p95/p99/max、gap、request rate、prompt/sampling 字段覆盖。

选择窗口后用 `prepare_code_window.py` 物化只读派生文件，并按 session root 生成确定性的 `sampling_u`。另一日期段不参与 rho 与 profile 选择。

### G2：`max_model_len` data gate

source-window audit 先用 `40960/65536/98304/131072/262144` 给出完整
窗口上界；真实 server 则使用能 **100% 覆盖该 rho 实际 paired requests
的 `ISL+OSL`** 的最小 16-token 对齐值。规则：

- sampling 只按 session-coherent `sampling_u`，不得按 token length 过滤；
- full source window 的 cap 用于记录 workload envelope，不强迫低 rho cell
  为未被抽中的 outlier 预留 KV capacity；
- 若某 paired cell max≤131072，使用 131072 或更小的对齐值；超过
  131072 时按该 cell 实际 max 向上对齐，而不是直接跳到 262144；
- Frontier 的 trace max tokens、predictor max tokens/request、vLLM `--max-model-len` 三处使用同一个 manifest 值。

### G3：prompt 与 prefix fidelity

优先级：

1. 有对齐 prompt text sidecar：用 Qwen tokenizer 重分词，要求 token length 与 trace ISL 全行一致；
2. trace 内已有 prompt text/token IDs：同样做长度与 hash relation 检查；
3. 两者都没有：允许用 source hash 确定性展开为 synthetic Qwen token IDs，但结果降级为 **length/arrival/prefix-shape faithful**，不声称 prompt-content 或 MoE routing faithful。

不论走哪条路径，source→16 映射冲突、runtime identity collision、parent prefix violation 都必须为 0。P+D/prefill-only 两侧 prefix caching 同开；先用 5–10min TP4/MNS16 做 hit-ratio audit。

### G4：long-context profile support

现有 profile-v5 的 KV context 上界约 32k，对 code 不足。根据 development window 的 uncached-ISL 分布生成 profile-v6-code-longctx：

- full chunk：`q8k`，context 至少覆盖 40k/56k/72k/88k/104k/120k/128k；
- tail chunk：从真实 `ISL mod 8192` 的 p50/p90 选择 2–4k/4–6k 代表点；
- TP1/2/4 分开采集，复测 `q1ks8k/q8ks32k` anchor；
- 每点至少两次 fresh-process repeat；CV≤5%，anchor drift≤10%；
- profile max context 必须 ≥ development window p99；正式 max claim 要求 ≥ max。若只覆盖 p99，max 以上请求单独列为 out-of-support，不进入总体准确度数字。

这是 code P+D 正式 fidelity 的硬 gate。可以先用旧 profile 跑 diagnostic sim 来估 load，但不得与真机组成最终 gap。

### G5：vLLM max-length/KV runtime gate

对每个候选 topology（先 TP4，再 TP2，TP1 后置）：

1. fresh server，以 manifest cap 启动；
2. 记录 vLLM 版本、model config、GPU KV blocks、maximum concurrency、启动日志；
3. 发 3 个单请求：ISL p50、p99、max（OSL=1），usage 必须逐 token 对齐；
4. 发 5min sampled P+D canary，零 OOM/timeout/preemption storm；
5. 只有 maximum concurrency>1 且 canary drain tail≤窗口时长 10% 才进入 rho calibration。

`max_model_len` 变大不等于每个请求都预占最大 KV，但会改变启动合法性与可表达的单请求上界；实际 KV 压力仍由并发 token state 决定。

### G6：每种 mode 独立标定 rho

不能复用 P+D rho：

- P+D 同时按 raw/prefix-adjusted prefill tokens/s 与 decode tokens/s 看 knee；
- prefill-only 因 OSL=1，重新按 prefill work 标定；
- strict decode-only 因无 prefill，按 decode tokens/s 和 batch fixed point 标定。

每种 workload×mode 选择 `low/mid/near-knee` 三点；正式点必须亚临界：全请求完成、无持续 backlog、drain tail≤10%、waiting p99 不单调随时间增长。跨 knee 点若运行，只作为 overload boundary，不支持“不发散”结论。

### G7：strict decode-only capability gate

先在 10min synthetic trace 上验证：

- real connector 确认没有执行 prefill kernel；
- Frontier ledger 第一个阶段就是 decode，computed tokens=ISL；
- 相同 context length 下两侧 KV block count 一致；
- connector preload/transfer 时间独立记账，不混入 TPOT；
- decode batch telemetry 能覆盖 b1 到目标 batch。

若 vLLM 0.20 community stack 没有等价 connector，严格 case 保持 BLOCKED；可另跑 decode-dominant proxy，但单独命名和汇报。

## 正式实验矩阵与推进顺序

### Phase A：code P+D（第一优先级）

1. **A0 CPU/data：** G0–G4；
2. **A1 max-len smoke：** TP4→TP2；TP1 只在 KV gate 通过后加入；
3. **A2 paired 10min canary：** TP4/MNS16，low rho，real+sim；
4. **A3 calibration：** 各 rho 只先跑 sim，冻结 low/mid/near-knee；
5. **A4 full：** TP4/MNS16、TP2/MNS16 × 3 rho × 2 trial × 60–75min；
6. **A5 held-out：** 只在 development window 判据冻结后，对第二日期段跑 TP4 的 mid/near-knee。

若某 topology 的 near-knee 过载，像现有 chat TP2/ρ0.01 一样排除，不为凑齐矩阵强跑。

### Phase B：chat/code prefill-only

- 复用各自已物化 window，只把 OSL 改为 1；
- primary：TP4/MNS16、TP2/MNS16 × 3 独立 rho × 2 trial；
- 报 TTFT/CDF/quantiles、prefill tokens/s、prefix hit、waiting、chunk/context 分带 residual；
- TPOT 记为 N/A，E2E 仅作为“一 token completion”辅助值；
- code 必须继续使用 profile-v6 long-context；chat 使用已验证 profile-v5。

### Phase C：chat/code strict decode-only

先做 batch-sensitive screening，再决定是否铺满：

- **C0 capability canary：** 两 workload × TP4 × MNS{16,128}，10min；
- **C1 core full：** TP{2,4} × MNS{16,128} × rho{low,near-knee} × 2 trial；
- **C2 conditional expansion：** 只有当 C1 的 batch 分布从 b≤8 跨到 b>8，或 accuracy gap 随 MNS 改变>5pp，才补 MNS{32,64} 与 mid rho。

decode profile/serving anchors 至少覆盖实际 batch p99。当前 whole-layer grid 只对少数 b≤8 有证据，且 b6 有长尾；在 MNS128 case 前必须补 b{1,2,4,8,16,32,64,128} 或实际访问 bucket，不能把 b8 常数外推到 b128。

## 指标与判据

共同口径：

- 分布统计偏差：`(sim statistic-real statistic)/real statistic`，不是 per-request MAPE；
- mean/p50/p90/p99 与 empirical CDF；
- 5min 分窗，前 15min warmup 不进漂移 slope；
- batch histogram、time-weighted running/waiting、drain tail、preemption；
- 两 trial pooled 结果和 trial-to-trial noise floor 分开报告。

判据分两层：

1. **准确度：** primary latency mean/p90/p99 的 |bias|≤15% 为强通过，15–30% 为有界但需标注 correction，>30% 立 bad case；任何 topology 排序或 SLO feasibility 翻转都单独判 failure，不能被平均值掩盖。
2. **长时稳定：** `|residual Theil–Sen slope|×12 / real noise floor < 1` 为 H-BOUNDED；只适用于亚临界 cell。

mode-specific：

- P+D：TTFT/TPOT/E2E 全部 primary；
- prefill-only：TTFT primary，TPOT N/A；
- strict decode-only：TPOT primary，TTFT 仅表示 admission/connector overhead，不进入 compute-fidelity gate。

## 成本与调度

- Phase A core：12 个 60–75min jobs（2 topology×3 load×2 trial），约 15 host-hours；按 TP 加权约 45 H20-GPU-hours，加 2–4 个 smoke/canary；
- Phase B 两 workload：24 个 full jobs，按相同 75min 上界约 90 H20-GPU-hours；
- Phase C 不一次铺满。C0 4 个 10min canary；C1 32 个 full jobs；C2 按触发条件追加。

每个 job fresh server；只在 `dash1`–`dash4` 全 8 卡 idle/healthy 时启动。即使 TP2/TP4 job 只用部分 GPU，也不在同一 host 并跑，避免 fresh-server 空窗竞态。每一批使用新的 jobs TOML，现有 dispatcher 非幂等。

## 预期产物

- `inputs/code-audit.json`、`inputs/code-window/window-manifest.json`；
- P+D/prefill-only 的 paired `frontier.csv`、`real_requests.jsonl` 与 manifest；
- profile-v6-code-longctx raw/merged profile 与 variance report；
- 每 cell real/sim request metrics、server telemetry、stage ledger；
- `results/code-pd-fidelity.md`；
- 最终 `chat/code × P+D/prefill-only/decode-only` compatibility table。

## 已知边界

- code trace 来自 GLM5.1 业务，serving model 是 Qwen3-30B；若无原 prompt text，测试只能保持 shape/prefix 结构，不能证明内容相关 routing fidelity；
- `max_model_len=128k/256k` 解决的是接入上界，不自动解决 32k 以上 profile 外推；
- strict decode-only 只测 decode engine；完整 PD 分离还需要单独建模 prefill、KV transfer、backpressure 与 KV-ready arrival。

## 执行记录（2026-07-23）

- fleet probe：dash1–dash4 均为 8×H20；32 张卡 memory.used=0、
  utilization=0、无 compute process、uncorrected ECC=0；
- 两个 formatted trace 都严格满足 512-token source hash contract；
- 0513：2,108,130 个有效请求、6090 个 zero-usage source 行；稳定
  development window=`[3480,7140)`，61min、1,078,928 请求；
- 0529：1,977,423 个有效请求、6031 个 zero-usage source 行；冻结为
  held-out，稳定候选 window=`[2640,6240)`；
- development window：ISL p50/p90/p99/max =
  20,051/88,224/125,803/202,371；OSL p50/p90/p99/max =
  78/758/6449/131,072；`ISL+OSL max=202,745`；
- full-window 131072 coverage=99.399%，262144 coverage=100%。但
  session sampling 的候选 `rho<=0.0032` 实际 max total=137,016，因此
  primary server cap 将按最终 cell max 对齐，不为未抽中的 202k outlier
  直接预留 262k；
- source 无 Qwen-aligned prompt/token IDs。raw canonical prompt 使用 GLM
  token contract，不能同时保持 Qwen token content 与 trace ISL；本 campaign
  采用 synthetic Qwen tokens 保持 length/hash/prefix shape，并降级内容 claim。