aituner/runs/frontier-code-trace-v0/experiment-card.md

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。