gahow/aituner
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e1f2557a0c41239f5c80a1c849bed36dde5ea1d0
aituner/runs/frontier-code-trace-v0/experiment-card.md

20 KiB
Raw Blame History

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

状态：RUNNING（Phase A code P+D）。 A0 数据/profile 与 A1 TP4 max-length smoke 已完成；A2 paired canary 正在运行；A3 sim calibration 已冻结 topology-specific rho。只使用 dash1--dash4，禁止使用 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 分窗漂移。

当前决策快照

项目 当前结论 下一 gate
code P+D 数据 61min development window、long-context profile-v6、四个 paired full 输入已冻结 paired canary real-vs-sim
TP4 负载 low/mid/near-knee=rho 0.0002/0.0008/0.0016；三点均亚临界 canary 通过后启动 1h
TP2 负载 low/mid/near-knee=rho 0.0002/0.0004/0.0008；0.0016 明确过载 TP2 canary/KV gate
code prefill-only rho<=0.0032 的 paired remap cache 已生成，OSL 全为 1 独立 sim rho calibration
strict decode-only vLLM 0.20.0 有 DecodeBenchConnector；Frontier trace generator 尚不能注入 initial computed tokens C0 contract canary，未进入正式结果

三种 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 决定。

对本模型，VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 只放宽 scheduler/config 校验，不会扩展模型内部 RoPE cache；server 还必须显式传 --hf-overrides '{"max_position_embeddings":147456}'。runner 对 MAX_MODEL_LEN>40960 自动同时设置这两层。长上下文 job 默认使用 host-local vLLM compile cache；FlashInfer workspace 按 topology 复用， 避免每个 rho/trial 重编译同一组 fused-MoE kernels。两者只影响启动， 不进入 replay latency。

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，不支持“不发散”结论。

drain tail 必须同时列出最后完成请求的 arrival、ISL、OSL、waiting 和 E2E。早于 cutoff 到达但 OSL 很长的请求可以在最后 arrival 后继续 decode；这属于 intrinsic response tail，不等价于 arrival cutoff 时仍有 持续增长的 queue backlog。亚临界判断以 queue/waiting trajectory 和 tail driver 分解共同决定，不能只用一个 drain 秒数。

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 一样排除，不为凑齐矩阵强跑。

当前状态：A0 完成；A1 的 TP4 完成、TP2 由 paired canary 同时验证； A2 运行中；A3 完成；A4 的 paired input 已物化但尚未在 canary gate 前启动。

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。

已安装 vLLM 0.20.0 的 DecodeBenchConnector 会在首次 schedule 时把 request.num_tokens-num_computed_tokens-1 个 token 标为 external， 同步向已分配的每层 KV blocks 写 dummy non-zero values，再从最后一个 prompt token 开始 forward。因此它适合测大 context 下的 decode compute/scheduling，但 connector fill 发生在 client admission 之后： fill time 必须单独记账并从 KV-ready arrival/TPOT 口径中排除。 dummy KV 也不提供真实 prompt-content 或 MoE-routing fidelity。

Frontier commit deadc4a3 的 Request 已支持构造 num_processed_tokens，但 TraceReplayRequestGenerator 不读取该列； 因此 sim 侧仍需一个显式、可测试的 initial_computed_tokens trace contract。C0 必须同时证明 real 首个 model step 是 decode、Frontier 首个 ledger stage 是 decode，之后才能解除 strict decode-only 的 BLOCKED。

指标与判据

共同口径：

  • 分布统计偏差：(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。
  • selected rho=0.0032 中有 1355 个可检查 parent links：tail rewrite p50/p90/p95/p99/max=1/1/4/57/169 个 source blocks，说明 coder parent_chat_id 不等价于 append-only prompt。source hash 序列作为 prefix truth；synthetic content block 生成后再计算 parent-sensitive runtime identities，避免“相同内容块出现在不同前缀后”造成 Frontier false hit。
  • 远端 Qwen3-30B config.json 的原生 position limit 是 40960 (rope_theta=1e6,无 rope_scaling)。147456 profile smoke 在显式 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 下成功；该 override 只支持 performance/shape fidelity，不形成生成质量或模型长上下文正确性 claim， 并作为 provenance 中的显式实验变量。
  • profile-v6-code-longctx 覆盖 TP1/2/4、KV context 到 131072， 33 个 long-context rows；两次 fresh-process repeat 的最大相对差 4.648%，旧 anchor drift 最大 1.7%。attention profile SHA256 = fbcf7e1f95789a6f6d771e24d1fc60958b7daf04eb0db260d27869a19d71d550。
  • TP4 max_model_len=147456 smoke 已在 dash4 通过。server 日志同时确认 max_model_len=147456 与 hf_overrides.max_position_embeddings=147456； 20,051+78、119,702+68、136,774+242 三个 shape 均成功。对应 TTFT=853.29/12,699.04/3,820.55ms，TPOT=16.65/7.21/8.13ms。 最长请求的非单调 TTFT 来自 cold compile/cache state，因此这里只作为 runtime support gate，不作为 profile accuracy 数据。
  • calibration 全部使用同一 profile-v6 SHA。TP4 的 rho=0.0016 decode batch max=16、drain=21.07s，仍通过 10% 亚临界 gate；TP2 的 rho=0.0016 waiting p50=332.97s、drain=976.86s，明确过载并排除。 完整 compact table 在 results/calibration-summary.json。
  • TP2/TP4 的 rho={0.0002,0.0004,0.0008,0.0016} 61min full paired inputs 已在 CPFS 物化；每个 paired row digest 和 Frontier CSV SHA 均与 calibration input 逐项一致。manifest 副本在 results/paired-input-manifests/。最大一个目录约 901MiB，不把大型 token arrays 提交进 Git。
  • code prefill-only 的最大 calibration cache 已物化： 3477 requests、总 prefill 115,828,371 tokens、OSL 全为 1， paired digest=40865068e02414612ba1cd4595894e20e85e01fd34d73f8660185552d531ecea。
  • 多 host 并发 server startup 暴露出 shared CPFS AOT cache 和每-job FlashInfer JIT 的 apparatus cost。它发生在 readiness 前，不进入 TTFT； runner commit d5bb974 改为长上下文默认使用 host-local vLLM cache， 并按 topology 复用 FlashInfer workspace。