aituner/runs/frontier-multicase-sufficiency-v1/protocol.md

# Qwen235B simulator fidelity 预注册协议 v1

状态：`IN PROGRESS`。更新日期：2026-07-16。T0 的 simulator 与 real 8-config surface 已完成；T1 和 T2 尚未运行。pilot 单独记录在 [t0-smoke-report.md](t0-smoke-report.md)，最终 T0 rank evaluation 记录在 [comparison.json](results/t0-final/comparison.json) 和根目录 [simulator-fidelity.md](../../simulator-fidelity.md)。

## Research question 与成功标准

对同一 workload、SLO 和候选 config surface，Frontier 是否能找到真机上低 regret 的 config，而不要求绝对 latency 或 capacity 完全一致？

主目标统一为：

```text
capacity(c) = max { 被真实测试的 offered req/s | 至少 95% requests 满足全部 SLO }
score(c) = capacity(c) / config 实际占用的 GPU 数
```

每个 case 都报告 real/sim capacity、top set、worst tie-break regret、Kendall tau-b、informative-pair direction、anchor-level SLO confusion，以及为达到该 fidelity 使用的 profile、patch 和真机 calibration 成本。只有同时满足下列条件，才能说 Frontier 对该 compatibility envelope 是足够的 config ranker：

- worst selected-config regret 不超过 5%；
- tie-aware rank correlation 不低于 0.8，且有足够的 non-tied pairs；
- ground-truth capacity bracket 不足以反转最优决策；
- 不使用被评测 workload/config 的端到端测量做 per-action calibration。

## 冻结的平台与软件边界

| 项目 | 设置 |
|---|---|
| machine | 仅 `dash0`，8×NVIDIA H20；不得调度到 `dash1` |
| remote repo | `/home/admin/cpfs/wjh/aituner/aituner`；实验使用独立 clean worktree/clone，不修改当前 dirty checkout |
| model | `/home/admin/cpfs/wjh/models/Qwen/Qwen3-235B-A22B-FP8` |
| serving | community vLLM `0.10.2` isolated environment，eager，BF16 KV；包版本与二进制 hash 入 manifest |
| simulator | Frontier upstream commit `d9cfeb6d8791fbf2f295dd9744c56a666171776e` + 明示、hash 后的 FP8/MoE/trace patches |
| trace | `thinking_w20260327_1000.jsonl`，SHA256 `f878e9af18f94dcfaced94a8e1e6b20a2f7d97d64aa862448025660dbbd965b2` |
| source window | 600 s，15,479 requests，natural offered rate 25.798 req/s |

每个 real trial 使用 fresh server。第一轮 config 顺序由固定 seed 随机化，第二轮反序；同一 config 的 offered-load anchors 从低到高和从高到低各跑一次。任何 OOM、engine crash、timeout 和右删失 cell 都作为结果保留，不能静默丢弃。

## Trace fidelity contract

source row 同时包含 exact prompt、arrival timestamp、`input_length`、`output_length`、session/turn/parent、`sampling_u`，以及 block-size=64 的 `hash_ids`。主 trace case 不设置 output override，也不按 input/output length 选择“好跑”的 cohort。

community model 的最大 context 是 40,960 tokens。预先冻结的 eligible universe 如下：

| universe | requests | input mean/p50/p95 | output mean/p50/p95 | total mean/p50/p95 |
|---|---:|---:|---:|---:|
| source | 15,479 | 3,660.0 / 1,491 / 19,610.6 | 3,924.6 / 3,435 / 8,945.1 | 7,584.6 / 5,317 / 25,102.1 |
| eligible | 15,401 | 3,575.0 / 1,490 / 18,887 | 3,823.3 / 3,417 / 8,768 | 7,398.2 / 5,305 / 23,697 |

唯一排除项是 72 个 `input_length + output_length > 40960` rows，以及 6 个 `output_length = 0` rows；二者无重叠。eligible 比例为 99.50%。

capacity search 使用 `sampling_u <= u` 调整 offered rate。`sampling_u` 在同一 session 内共享，因此这是与长度无关的 session-coherent thinning，而不是 workload filtering。对每个 anchor，real 与 sim 必须具有相同的 source row IDs、arrival/order hash、input/output vector hash、session vector hash 和 prefix vector hash。每个被选 request 仍使用原始 arrival、prompt、input、output 和 hash。

第一个 correctness gate 已完成：在 `dash0` 上使用 community model 的 `Qwen2TokenizerFast` 全量处理 15,401 个 prompts、55,057,919 tokens，实际 token length 与 trace `input_length` 的 mismatch 为 0；在 852,407 个完整和 15,131 个末尾 partial source blocks 上，`hash_id ↔ (parent_hash_id, 64-token chunk)` 均无冲突。结果和 digest 记录在 [trace-contract-audit.json](trace-contract-audit.json)。这说明 exact prompt/source hash 可以表达原 trace 的 prefix-equivalence relation。

在启动 GPU 前还需完成第二个 correctness gate：

1. real 与 Frontier 的 KV block size 都冻结为 16。source `hash_ids` 的 block size 是 64，因此应从 exact prompt token IDs 生成 block-16 content/parent identities，并验证每四个完整 block-16 对应的 64-token source equality/reuse relation 没有改变。两侧逐 request 比较 computed/hit/allocated block counts。

## T0：fixed-shape sanity case

T0 是最简单的机制隔离基线，不声称代表 production trace。

| 项目 | 设置 |
|---|---|
| requests | deterministic 生成；ISL=2,048、OSL=128 |
| arrivals | uniform QPS；相同 request IDs/order；每个 anchor 至少 64 个 completed requests |
| prefix | off；不同 token content，保证没有共享完整 KV blocks |
| SLO | TTFT `<= 1000 ms + 1000×input_tokens/8000`（本 case 为 1,256 ms），TPOT `<= 40 ms`，joint pass rate ≥0.95 |
| configs | `TP∈{4,8} × MNS∈{64,128} × MBT∈{8192,16384}`；沿用已闭合的 TP4/TP8 MoE mapping |

先在 simulator 中用宽 anchor lattice 找到每个 config 的边界，再冻结 simulator output 和 hash；真机只运行相同 anchors。T0 回答的是：在没有 length variance、prefix reuse 和 burstiness 时，profile composition 与 scheduler 是否已经能保持 config rank。它不能用于回答真实 trace fidelity。

首次真机 smoke 之后、完整 surface 之前预先记录如下 amendment：TP4 的 zero-queue TPOT 已经是 136.2 ms，因此 40 ms 主 SLO 对至少 TP4 没有非零 capacity。40 ms 仍保留为 preregistered primary，不因结果不可行而删除；同时固定报告 TPOT 120/150/180 ms sensitivity。150 ms 是 post-pilot 的 decision-bearing sensitivity，因为它略高于已观测 TP4 idle floor，又仍可能在 batch/queue 增大时产生 capacity knee；它不能冒充 blind primary result。

完整 simulator lattice 固定为 system offered rate `{0.10,0.20,0.40,0.80,1.20,1.60,2.40,3.20}` req/s，每个点 64 requests。所有 8×8 simulator cells 必须在任何 real surface cell 之前冻结。真机对每个 config 先测 simulator 在 150 ms sensitivity 下的相邻 transition anchors，并始终加入最低 0.10 req/s anchor；若没有 transition，则测边界方向的两个 anchors。若这些 real labels 没有 bracket，按冻结 lattice 向外扩展，且 simulator 结果不得重算。每个被测 anchor 做两个 fresh-server rounds，rate 顺序正向/反向，所有 strict/sensitivity SLO 均在同一 raw requests 上离线打分。真机 anchor 只有在两个 round 都达到 95% joint pass rate 时才保守地记为 feasible；两个 round 标签不一致时同时报告原始 pass rates，并把该点记为重复性不确定而不是择优取样。

第一次多-rate 真机 run 后、接受任何 real surface cell 之前增加一项 execution amendment。原 runner 每个 round 只启动一次 server，正向 `0.10→1.60→2.40` 时 1.60 的前 24 个 requests 出现 114--234 ms 的递减 TPOT transient；反向先运行 2.40 后，同一 1.60 anchor 从第一个 request 起稳定在 113--128 ms。两个独立 TP4 config 同时复现，说明前一 rate 的 GPU/kernel/batch warm state 泄漏到后一 rate，而 Frontier 的各 rate 是独立 simulator run。该诊断 run 整体排除，不作为 ground truth。修正后的每个 `(config, rate, round)` 使用独立 fresh server，并在测量前按同一 target rate 丢弃 `min(32, max(4, ceil(rate×20)))` 个 exact-shape warmup requests；随后从空 scheduler queue 开始记录 64 requests。正/逆序只用于复测和控制机器时间漂移，不再共享 execution state。这个 amendment 是观察 diagnostic transient 后作出的，必须在结果中明示，不能写成原始 blind protocol。

steady-QPS profile closure 不能只含 pure decode。完整 profile 预先覆盖 TP `{4,8}`、decode batch `{1,2,4,8,16,32,64,96,128}`、KV 2,048--2,175，并加入 prefill-chunk=2,048 的 true mixed prefill+decode rows。最终 attention root 含 726 个既有 prefill rows、162 个 standard decode rows 和 216 个 true-mixed rows；没有使用 T0 端到端 latency 做 calibration。

## T1：trace-faithful mixed case

T1 直接使用上述 15,401-row eligible universe：不设置 completion override，不改变入选 request 的 input/output，不做 length-stratified sampling，prefix caching 在 real 与 sim 两侧同时打开。

| 项目 | 设置 |
|---|---|
| selection | source `sampling_u <= u`；同 session 一起入选；real/sim 共用 frozen anchor files |
| arrival | 原 timestamp、600 s window、原 burst/order；`replay_time_scale=1.0` |
| output | `min_tokens=max_tokens=output_length`；记录实际 usage，必须与 trace 相等 |
| prefix | exact prompt token blocks；两侧相同 block size、capacity、cache policy 与 sticky session routing |
| SLO | 与 T0 相同的 TTFT 规则和 TPOT 40 ms；另报告 TPOT 20/50 ms sensitivity，不用 sensitivity 改选主结论 |
| configs | 与 T0 相同的 8 cells，先隔离 workload state，再扩展 DP/EP topology |

由于 natural QPS 远高于该模型 capacity，直接全量同时到达只会让所有 config 都 infeasible，不能产生排序信息。这里 `sampling_u` 是 trace 原生的负载抽样维度；它只改变入选 session 数量，不改变入选请求的 joint distribution 和字段。每个边界至少用两个预先冻结的 session-hash folds 或两个独立 trace windows 重复，避免一个低-u 小样本偶然决定 ranking；若暂时只有一个 window，结论标为 single-window evidence。

## T2：Qwen235B strict decode-only case

T2 不用“短 prefill + 长 output”冒充 decode-only。它要求一个可检查的 initial-KV contract：request 到达 scheduler 时，与 input token IDs 对应的 KV blocks 已经 resident，request 状态为 prefill complete，首次被调度的 token 是第一个 decode token。

两侧 contract 必须共同记录：initial KV token/block count、block identities、replica placement、填充/传输开始结束时间、首次 scheduler admission time。若真机 connector 在 GPU 上同步填充 dummy KV，这项带宽和同步成本会干扰并发 decode；Frontier 必须显式建模这段 admission cost，或真机把它移到计时区间之前。不能只忽略 TTFT，就假设 connector 没有影响 TPOT。

T2 分两步，避免把 execution mechanisms 混成一个不可解释的 gap：

| 层次 | Workload / mechanisms | Config surface | 目的 |
|---|---|---|---|
| T2a controlled decode | fixed ISL=2,048、OSL=512；BF16 KV；eager；prefix/speculation/CUDA graph off | `TP∈{4,8} × MNS∈{64,128} × MBT∈{256,384}`，DP=1 | 验证 initial-KV、decode attention/batching 与 TP rank |
| T2b topology stress | trace exact input/output；EP8；仍先关闭 EAGLE3 与 decode graph | `(TP4,DP2,EP8)` 与 `(TP2,DP4,EP8)` × MNS `{64,128}` × MBT `{256,384}` | 激活 replica count、expert communication、KV residency 的耦合 |

只有 T2a/T2b 对齐后，才按单变量顺序加入 FP8 KV、EAGLE3、DeepEP/NVSHMEM 和 `FULL_DECODE_ONLY` CUDA graph；每加入一项都重新冻结 simulator ranking 并测真机。现有 internal-vLLM decode surface 同时打开了这些机制，而且 8 个 config 的 capacity brackets 全部可能包含最优值，只作为 historical real-only evidence，不作为本协议 ground truth。

## Run order 与停止条件

1. 完成 tokenizer、row vector、prefix-block correctness audit；不使用 GPU。tokenizer/source-hash 离线部分已完成，block-16 runtime-counter parity 待完成。
2. 在 dash0 做一次 community vLLM TP4 model-load + T0 one-request smoke。已完成：server 与 exact 2,048/128-token requests 成功，但最低负载 TPOT 为 136.2 ms，40 ms primary SLO 不可行；对应 Frontier run 暴露 decode attention profile 未闭合。
3. 完成 T0 的 simulator 8-cell surface并冻结 SHA256；随后运行 T0 real anchors。已完成：64/64 simulator cells 冻结，8/8 real config boundaries 在 150 ms decision-bearing SLO 下闭合。
4. 实现并单测 trace block translation，完成 T1 simulator freeze，再运行 T1 real anchors。
5. 实现 community-vLLM 0.10.2 与 Frontier 的 initial-KV contract；一请求和并发请求状态机 smoke 通过后，运行 T2a。
6. 只有 profile closure 包含 EP8 all-to-all 且 T2a 可解释时，运行 T2b。

每层遇到 mismatch，先按 request/stage 分解 queue wait、prefill、decode step、collective、MoE 和 KV admission residual。只有证据定位到某一 composition invariant 失效，才修改 simulator；不通过端到端 scalar 把 ranking 调到正确。

## 首次 GPU launch gate

首次 GPU smoke、full attention closure 与完整 T0 sweep 均已于 2026-07-16 在 `dash0` 完成，GPU 已释放。接受的 T0 ground truth 为 68 个 fresh-server anchors，消耗 36.26 H20-GPU-hours；污染和 cross-anchor-state diagnostic attempts 已隔离。任何 T1/T2 GPU launch 都必须重新 echo resolved workload、artifact paths、GPU 预算与预计时长。