Prepare Frontier code trace fidelity campaign
This commit is contained in:
204
runs/frontier-code-trace-v0/experiment-card.md
Normal file
204
runs/frontier-code-trace-v0/experiment-card.md
Normal file
@@ -0,0 +1,204 @@
|
||||
# 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` 全行存在；
|
||||
- `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
|
||||
|
||||
候选 cap 固定为 `40960/65536/98304/131072/262144`，选能 **100% 覆盖选中窗口 `ISL+OSL`** 的最小值。规则：
|
||||
|
||||
- 若 max≤131072，主路径使用 131072 或更小的审计推荐值；
|
||||
- 若存在 >131072 请求，不允许悄悄过滤。优先验证 262144；若 runtime 不可行，必须预注册过滤比例，并把 claim 改为“≤131072 子群”；
|
||||
- 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 至少覆盖 32k/48k/64k/80k/96k/112k/120k；
|
||||
- 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。
|
||||
Reference in New Issue
Block a user