48 KiB
Frontier simulator fidelity：以 config ranking 为目标的阶段性评测
更新日期：2026-07-17。
统一实验平台：所有新增与重跑实验只使用 dash0 的 8×NVIDIA H20。Qwen30B 的真实 P1 artifacts 也来自 dash0；早期文档中的主机 provenance 标注错误，本版已按实验主机和远端 artifact 路径更正。
结论摘要
本文统一使用同一个优化目标：在给定 workload 和 SLO 下，最大被测试可行 offered request throughput/GPU。我们关心 simulator 是否保持 config 的相对排序、是否覆盖真机最优集合，以及部署 simulator 所选 config 后的真实 regret；绝对 latency/throughput 误差不是首要判据。
当前证据不支持“Frontier 普遍找不到最优 config”这一判断：
- 在 Qwen3-30B mixed serving artifact 上，未经端到端校准的 Frontier 排序失败，选择 regret 为
25.63%；但使用独立 workload 上冻结的 per-TP calibration 后，Frontier 的候选 top set 包含真机最优 config，Kendall τ-b 为0.9668，最坏 tie-break regret 为0.76%。真实 serving 与本轮补测 profiles 均运行在dash0。 - 将 operator profile 更新为与真实 serving 一致的 community vLLM
0.20.0、BF16、H20、TP1/2/4 栈后，新的 profile-only Frontier 没有恢复排序：92 个真实 anchors 在 simulator 中全部 SLO-infeasible，12 个 config 因而全部并列，最坏 tie-break regret 为60.91%。这否证了“旧 profile 版本不一致是主要原因”这一简单解释，并把问题收敛到 execution context、operator composition 与 mixed-state schema。 - 在 Qwen3-235B-A22B-FP8 prefill-only 上，补齐 FP8/MoE profile 与 serving semantics、但不做端到端 action calibration 后，Frontier 的最优集合与真机完全一致，Spearman ρ 为
0.9487，20/20 个可比较非 tie config pair 同序，选择 regret 为0。 - 在 Qwen3-235B-A22B-FP8 fixed-shape mixed 上，Frontier 同样给出了与真机完全相同的 TP4 top set，Kendall τ-b=
0.8944、worst tie-break regret=0。但这次成功掩盖了一个明确的机制错误：Frontier 认为同一 TP family 内四个 MNS/MBT config 完全等价，真机 TP8 capacity 却形成对角为 0.30、非对角为 0.20 req/s/GPU 的 checkerboard interaction。34 个 config-load labels 中有 10 个 false-infeasible；20 个 real non-tie pairs 中只保持 16 个方向。 - 新增的 Qwen3-30B-A3B BF16 prefill-only 对照在没有 decode、prefix reuse 和 true-mixed attention 的情况下仍然失败：真机 top set 是四个 TP4 config，Frontier top set 却是全部 TP1/TP2 config，top set 无交集，worst regret=
12.5%、Kendall τ-b=-1.0，32 个 real non-tie pairs 全部反向。这直接否证了“prefill-only 是 simulator ranking 充分容易条件”。 - 现有结果更支持一个 margin-aware fidelity 解释：action-differential residual 可以很大，但只有当它足以穿过 real decision margin 时才会导致选错。Qwen235 mixed 中真机 TP4 相对最好 TP8 的 margin 是
2×，足以掩盖同 TP family 内的机制错误；Qwen30 prefill-only 中 TP scaling 差分更细，Frontier 的 residual 直接反转了 topology ordering。模型大小或 execution phase 单独都不足以解释现有结果。
因此，现阶段最准确的 research statement 不是“simulator 排序一定错误”，而是：
Simulator 的 usefulness 取决于 action-differential residual 是否小于真实 decision margin。问题不是简单区分 prefill 与 mixed，而是定位哪些 scheduler-state-conditioned execution residual 会随 TP、batch composition 和负载被放大，并用最少的真机信息判断 ranking 是否足够可信。
评测口径
对系统 s ∈ {real, sim} 和 config c，定义：
capacity_s(c) = max { tested offered rate r | empirical SLO pass rate(c, r) >= 0.95 }
所有结果使用 capacity/实际占用 GPU 数 作为 primary score。我们只报告实际测试到的最大可行点，不对未测试区间做连续插值，也不因观察到局部非单调就强制单调化。
核心指标如下：
-
Top set：达到各自最大 capacity 的全部 config，保留并列。
-
Top-set hit/match：simulator top set 是否与 real top set 有交集/完全相同。
-
Worst tie-break regret：若 simulator 给出多个并列最优，任取其中最差一个在真机上的损失：
max[c in SimTop] (RealBest - capacity_real(c)) / RealBest -
Rank correlation：有并列时优先使用 Kendall τ-b；Qwen235B 已有冻结分析使用 Spearman ρ，同时报告非 tie pair direction。
-
Pairwise direction：两两 config 的
> / = / <是否一致。只报告 non-tied accuracy 时，会同时给出可比较 pair 数量。
这个定义也修正了之前的口径混用：内部 throughput proxy 不是“满足 SLO 的最大 throughput”，不能用来决定部署 config。本文的 Qwen30B 主结论因此取代 旧 simulator fidelity 总结 中基于 throughput-proxy 的 config-selection 结论；该旧读法仍可作为 simulator 内部机制误差的诊断证据。
实验 setup
Case A：Qwen3-30B-A3B mixed serving
| 项目 | 设置 |
|---|---|
| 真机 | dash0，8×NVIDIA H20 |
| model | Qwen/Qwen3-30B-A3B |
| serving runtime | community vLLM 0.20.0，CUDA 12.9 环境 |
| simulator | Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e |
| trace | chat_w20260311_1000，replay time scale=0.1，input 0--8192 tokens，output override=128 tokens，max concurrency=64 |
| SLO | 至少 95% requests 同时满足 TTFT 阶梯阈值（input ≤4096: 2s；≤32768: 4s；其余 6s）和 TPOT ≤50ms |
| config surface | TP∈{1,2,4} × MNS∈{8,16,32,64}，MBT=8192，共 12 cells |
| ground truth | 每个 cell 最多 8 个搜索 probes；92 个实测 anchors，共 27,583 个 request observations |
| simulator workload | 对每个 real anchor 重放同一冻结 request cohort 的 token length、arrival、request count 与 prefix block identities；old profile-only、calibrated、vLLM 0.20 profile-only 各 92 runs，合计 276/276 成功 |
| primary objective | SLO-feasible request throughput/GPU |
我们区分两个 Frontier 条件：
- Profile-only：直接使用已有 H20 operator profiles，不用 serving E2E 数据修正时间尺度。
- Frozen per-TP calibration：使用
TP1=0.723481, TP2=0.468089, TP4=0.352137三个 execution-time scales。它们在独立的coder_200_ts2workload 上拟合，并在coder_200_ts3上冻结验证；本chatsurface 不重新拟合。该 scale 由外部 hook 在 Frontier 组成 batch execution time 后注入，并不是 Frontier 原生的 per-TP operator profiling 功能。
Frontier 原生 profile schema 可以按 num_tensor_parallel_workers 选择 TP-specific kernel rows；这与上面的 calibration 不同。第二个条件不是 zero-measurement prediction：它使用了同 model/hardware/runtime family 的真机 serving 数据，并能同时吸收 CUDA graph、fusion、routing、CPU launch 和 profile provenance 等残差。另一个限制是已有 H20 profiles 的生成栈与 ground-truth vLLM 0.20.0 并非严格同版本；per-TP calibration 吸收了相当一部分 execution-scale mismatch。
Case B：Qwen3-235B-A22B-FP8 prefill-only
| 项目 | 设置 |
|---|---|
| 真机 | dash0，8×NVIDIA H20（97,871 MiB/GPU，全互联 NV18），driver 580.95.05 |
| model | Qwen/Qwen3-235B-A22B-FP8，block-wise FP8 weights，BF16 KV cache |
| serving runtime | community vLLM 0.10.2；Python 3.12.3、torch 2.8.0+cu128、FlashInfer 0.3.1.post1、Transformers 4.55.2；eager execution |
| simulator | Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e + 冻结的 FP8/MoE best-effort patches |
| source trace | thinking_w20260327_1000；从 15,409 个 eligible requests 中固定选择 64 个 length-stratified prompts |
| fixed cohort | seed=2026071501；input p50=1478、p95=18,439、max=29,385、mean=3511.55 tokens；output override=1 token |
| offered rates | 0.15, 0.20, 0.25, 0.30, 0.35, 0.40, 0.45, 0.50, 0.75, 1.00, 1.50 req/s；只缩放同一 cohort 的 arrival timeline |
| SLO | 至少 61/64 requests 满足 TTFT ≤ 1000ms + input_tokens/8000 tokens/s |
| config surface | TP∈{4,8} × MNS∈{64,128} × MBT∈{8192,16384}；实际 TP4 为 EP off，TP8 为 EP on |
| serving controls | prefix cache/speculative decoding off，chunked prefill on；每个 config fresh server，第二轮反转 config/rate 顺序 |
| primary objective | 最大被测试可行 offered rate / TP |
这里比较的不是 stock Frontier。为建立公平的 FP8 compatibility envelope，我们先用同一 community-vLLM 0.10.2 栈在 H20 上测量 FP8 linear/attention/MoE/collective profiles，修复了 MoE FP8 tuning-key、Qwen MoE serving plan、TP/EP-aware cache key 与 critical-lane prediction，并输入真机测得的 KV block capacity（TP4=26,101；TP8=62,351）。Frontier refined outputs 在真机 v2/v3 ranking 运行前冻结，没有使用本 case 的 serving capacity 做 end-to-end calibration。
该 case 是有意设计的 prefill mechanism-isolation workload：output 固定为 1，prefix cache 关闭，并使用固定 64-request cohort。它不保持原 trace 的 output-length distribution 和 prefix reuse，因此不能被称为 trace-faithful workload，也不能代表 mixed serving。
Case D：Qwen3-30B-A3B BF16 prefill-only
| 项目 | 设置 |
|---|---|
| 真机 | dash0，8×NVIDIA H20；每个 job 按 TP 独占 GPU |
| model/runtime | Qwen/Qwen3-30B-A3B；community vLLM 0.20.0+cu129（source 88d34c6409e9fb3c7b8ca0c04756f061d2099eb1），BF16 weights/activation/KV，FA3，runtime 默认 CUDA graph |
| workload | 64 个不同 token-chain prompts；ISL=2,048、OSL=1、uniform open-loop QPS、prefix cache off |
| config surface | TP∈{1,2,4} × MNS∈{8,16,32,64}，MBT=8,192，chunked prefill on，共 12 cells |
| simulator | Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e + 当前 compatibility patches + vLLM 0.20 same-stack profile-v2；无 E2E calibration、decode graph=none、analytical collective |
| load lattice | base system rates {4,8,16,32,64} req/s；事先声明的 common refinement 为 {5,6,7} req/s/GPU |
| real anchor | 每个 (config,rate,round) fresh server；两轮独立运行且第二轮反转顺序；两轮都 pass 才算 feasible |
| SLO | 至少 61/64 requests 满足 TTFT≤1,256 ms |
| primary objective | 最大被测试可行 offered req/s / 实际 TP GPUs |
这个 case 是对“prefill-only 是 simulator 的容易区间”的直接可证伪测试。它刻意去掉 decode、true-mixed batch、prefix reuse 和 KV-residency feedback，但保留 TP 改变下的 local shard、collective、batching 与 scheduler queue。Frontier surface 在查看真机 ranking 前冻结，没有使用本 surface 的 serving latency 拟合 scale。
Workload fidelity 修正
thinking_w20260327_1000 的 600 秒原始窗口包含 15,479 requests，字段包括 exact prompt、arrival、input_length、output_length、session parent/turn 和 block-size=64 的 hash_ids。只读审计得到：
| 属性 | 数值 |
|---|---|
| natural offered rate | 25.798 req/s |
| input tokens | mean=3,660.0，p50=1,491，p95=19,610.6，p99=29,944.6，max=51,827 |
| output tokens | mean=3,924.6，p50=3,435，p95=8,945.1，p99=17,705.5，max=74,867 |
| total context | mean=7,584.6，p50=5,317，p95=25,102.1，p99=37,110.5，max=74,973 |
rows with hash_ids |
15,479/15,479 |
len(hash_ids) == ceil(input_length/64) |
15,479/15,479 |
| arrival-order repeated block ratio | 40.88% |
| input+output 超过 community model 40,960 context | 72 requests |
| output length=0 | 6 requests |
因此，input/output/hash filtering 不是 trace fidelity 的默认要求。此前 fixed output length 是为了分别隔离 prefill 或 decode 机制；如果用它回答 production-trace fidelity，就属于错误 benchmark。新的实验矩阵固定为：
| 层次 | Workload contract | Prefix contract | 回答的问题 |
|---|---|---|---|
| T0 fixed-shape | 固定 ISL、OSL、uniform QPS；所有 config 使用相同 request IDs/order | prefix off，使用等长但不同 token 的 prompts | 最简单条件下 execution/scheduler composition 是否匹配 |
| T1 trace-faithful mixed | 保留 trace 的 arrival、input、output、session；不使用 completion override | real 由 exact prompt tokens 自然计算 cache key；Frontier 消费等价 block_hash_ids |
在真实 joint distribution 下能否保持 config rank |
| T2 decode-only | output 保留 trace 或受控固定值；input length 表示 request 到达时已存在的 KV residency | initial-KV state 单独冻结；不得用一次 1-token prefill 冒充 | KV residency、decode batching、TP/DP/EP coupling 下能否保持 rank |
T1 中只允许两类有记录的排除：模型 context 上限不支持的 72 requests，以及 API 无法形成 completion 的 6 个 zero-output rows；二者不重叠，最终 eligible universe 为 15,401/15,479 requests（99.50%）。排除后 input/output/total 的均值分别为 3,575.0/3,823.3/7,398.2 tokens，p95 分别为 18,887/8,768/23,697，说明没有把 workload 人为变成 short-request case。其余请求不能因为“跑得慢”或“方便形成 cohort”被选择性移除。capacity search 只通过 trace 已有、同 session 共享的 sampling_u 做与长度无关的 session-coherent thinning；每个被选 request 的 arrival、input、output、prompt、hash 和相对次序均保持不变。完整 eligible universe 是抽样母体和最终 workload 声明，不用 length-stratified cohort 代替。
全量 tokenizer audit 进一步验证了 15,401/15,401 个 eligible prompts、共 55,057,919 tokens 的实际 community-Qwen token 数与 trace input_length 完全一致。在 867,538 个 source blocks 上，hash_id 与 (parent_hash_id, 64-token chunk) 的双向映射也没有发现冲突。因此 exact prompt 和 source hash 足以保留该 trace 的 prefix-equivalence relation，不需要用 synthetic length-only prompt 替代。
trace 的 source hash block size 为 64，而 community vLLM 0.10.2 的 CUDA KV block size 不能直接设置为 64。下一轮实验冻结 real 与 Frontier 的 block size 都为 16：从 exact prompt token IDs 重新生成 block-16 parent/content identities，并用 source hash_ids 验证每四个完整 block-16 所对应的 64-token equality/reuse relation。tokenized length、request order、cache query/hit/allocated blocks 仍必须在两侧逐请求核对；上面的离线 audit 不能代替 runtime counter parity。
总体结果
| Case / simulator 条件 | configs | real optimum | simulator top set | top-set 结论 | rank / pairwise | worst regret | 判断 |
|---|---|---|---|---|---|---|---|
| Qwen30 mixed / old profile-only | 12 | TP2,MNS32 | TP4,MNS32/64 | miss | τ-b=0.000；exact sign=37.88% | 25.63% | 排序错误 |
| Qwen30 mixed / vLLM 0.20 profile-only | 12 | TP2,MNS32 | 全部 12 configs | 不可辨识 | τ-b=0.000；exact sign=7.58% | 60.91% | 同栈 raw profile 仍不足 |
| Qwen30 mixed / frozen per-TP calibration | 12 | TP2,MNS32 | TP2,MNS32/64 | hit，非 exact | τ-b=0.9668；exact sign=93.94% | 0.76% | dash0 |
| Qwen30 BF16 prefill-only / vLLM 0.20 profile-only | 12 | 全部 TP4 configs | 全部 TP1/TP2 configs | miss，无交集 | τ-b=-1.0000；real non-tie=0/32 | 12.50% | topology order 反转 |
| Qwen235 FP8 prefill / best-effort | 8 | TP4,MBT16K,MNS64/128 | 与 real 完全相同 | exact match | ρ=0.9487；non-tied 20/20 | 0 | 足以选最优 config |
| Qwen235 FP8 fixed-shape mixed / frozen full profile | 8 | 四个 TP4 configs | 与 real 完全相同 | exact match | τ-b=0.8944；exact sign=24/28；real non-tie=16/20 | 0 | 选对 topology；漏掉 TP8 MNS×MBT interaction |
最重要的区别是：Qwen30 的 high-fidelity mixed 结果依赖 per-TP E2E calibration，而新 prefill-only profile-only 实验证明“去掉 decode/mixed 状态”也不足以恢复 ranking。Qwen235 的 high-fidelity 结果不依赖本 case 的 E2E calibration，但依赖同 runtime/hardware 的 operator profile、真实 KV capacity 和多处 compatibility fixes。两个 model 的 stack 和精度不同，所以不能把差异直接归因为 model size；二者也都不能表述为“拿 stock Frontier 零成本预测即可”。
Case A baseline 结果：Qwen30 mixed serving
图中 config 按真机 capacity 从高到低排列。上图显示 profile-only Frontier 选错 TP family；下图显示冻结 per-TP calibration 后，simulator 基本恢复了有用排序。
| Config | Real | Frontier profile-only | Frontier calibrated | Calibrated − real |
|---|---|---|---|---|
| TP1, MNS8 | 2.1000 | 1.1000 | 1.7167 | -0.3833 |
| TP1, MNS16 | 2.3500 | 1.1000 | 2.3833 | +0.0333 |
| TP1, MNS32 | 2.2833 | 1.1000 | 2.3833 | +0.1000 |
| TP1, MNS64 | 2.2833 | 1.1000 | 2.3833 | +0.1000 |
| TP2, MNS8 | 2.2750 | 0.0000 | 1.7417 | -0.5333 |
| TP2, MNS16 | 2.2750 | 1.1917 | 2.3000 | +0.0250 |
| TP2, MNS32 | 3.2833 | 0.0000 | 3.7500 | +0.4667 |
| TP2, MNS64 | 3.2583 | 0.0000 | 3.7500 | +0.4917 |
| TP4, MNS8 | 1.2833 | 0.0000 | 1.3208 | +0.0375 |
| TP4, MNS16 | 2.4417 | 0.0000 | 2.5000 | +0.0583 |
| TP4, MNS32 | 2.4417 | 1.3208 | 2.5000 | +0.0583 |
| TP4, MNS64 | 2.4417 | 1.3208 | 2.5000 | +0.0583 |
单位均为 SLO-feasible req/s/GPU。0.0000 表示该 config 在复用的 tested anchors 中没有被 Frontier 判为 SLO-feasible，不代表硬件在零负载下也无法运行。
相对排序方面：
- Profile-only 的 top set 为 TP4/MNS32、TP4/MNS64；两者真机 capacity 都是 2.4417，而 real optimum TP2/MNS32 是 3.2833，因此 regret 为
1−2.4417/3.2833=25.63%。 - Calibrated Frontier 把 TP2/MNS32 和 TP2/MNS64 判为并列。前者是真机唯一最优，后者低
0.025 req/s/GPU；因此 optimistic regret=0，worst tie-break regret=0.76%。 - Calibrated absolute error 并不是一个全局常数：TP2/MNS8 被低估 0.5333，而 TP2/MNS32/64 被高估约 0.47--0.49。选对 config 不代表 simulator 已正确解释每个 state/action 的性能。
- 92 个 anchor-level SLO 判定中，calibrated Frontier 仍有 21 个 false-feasible、7 个 false-infeasible；aggregate top set 正确部分来自 cell boundary 上误差抵消。因此该条件足以做本 surface 的 near-optimal selection，但不能替代真机 SLO certification。
同栈 vLLM 0.20 per-TP profile 消融
为了判断上述差异是否只是旧 operator profile 与真实 serving 版本不一致，我们在 dash0 上使用 ground-truth 相同的 community vLLM 0.20.0 source commit 88d34c6409e9fb3c7b8ca0c04756f061d2099eb1、Qwen3-30B-A3B BF16 与 H20，重新测量 TP1/2/4 profiles。Frontier code、92 个 trace fixtures、SLO、KV capacity、config surface、communication backend 与随机种子保持不变；这轮只替换 compute profiles，不使用本 surface 的 serving latency 拟合 scale。
| Profile component | 冻结行数 | 测量与使用方式 |
|---|---|---|
| attention + KV | 132 | 102 个 pure prefill/decode rows；30 个 true-mixed rows由同 TP pure profile 比例做 total-conserving split |
| fused mixed diagnostic | 30 | 保存 vLLM FA3 实测 fused total；不作为 Frontier 的第三个 target |
| linear / norm / RoPE / router | 36 | vLLM 0.20 CUDA operator |
| MoE | 72 | TP1/2/4 local-shard shapes × 12 token sizes × uniform/random/hotset8 routing |
| all-reduce | 24 | TP2/4 实测；本 base comparison 不注入，用来诊断 communication，保持历史 analytical CC backend 不变 |
attention、linear 和 MoE 的 TP 字段改变的是单张 H20 上的 local-shard shape；它们不是一次 distributed full-engine graph replay。只有 all-reduce 使用真实 TP2/4 ranks 测量。该限制是实验设计的一部分：本消融回答“把相同 runtime 的 isolated operator profiles 换进去是否足够”，而不是预先假设 isolated profile 已等价于真实 execution counterfactual。
完整 92-probe 结果如下。0 表示复用的 anchors 中没有一个被 simulator 判为 SLO-feasible；它既不表示零负载硬件 capacity，也不能被解释成“因为真实最优 config 位于并列集合中所以 top-set hit”。当所有 config 都并列时 simulator 没有选择信息，故 primary 指标是 worst tie-break regret。
| Frontier 条件 | Sim top set | τ-b | Exact pair sign | Worst regret | Anchor labels：agree / false feasible / false infeasible |
|---|---|---|---|---|---|
| old profile-only | TP4,MNS32/64 | 0.0000 | 37.88% | 25.63% | 37 / 0 / 55 |
| vLLM 0.20 profile-only | 全部 12 configs | 0.0000 | 7.58% | 60.91% | 30 / 0 / 62 |
| frozen per-TP calibration | TP2,MNS32/64 | 0.9668 | 93.94% | 0.76% | 64 / 21 / 7 |
若忽略 SLO，仅按 simulator 完成 throughput proxy 排序，新 profile 的 top-1 是 TP1/MNS64，真机 regret 仍为 30.46%，τ-b=0.3940，non-tied pair concordance=70.49%。这只是 failure diagnosis，不能替代本文定义的 SLO-feasible capacity objective。两路 CPU shard 都是 46/46 PASS，合计 simulator runtime 为 2,394.9 s（0.665 CPU-hour）；所以结果不是 crash、missing row 或未完成运行造成的。
为什么相同 operator provenance 仍不等于 execution fidelity
证据把 mismatch 收敛到以下三个相互耦合的层面：
- Execution regime 随 scheduler state 改变。 6 个真实 P1 cells 共记录 161,161 个 model steps。151,471 个 pure-decode steps 全部使用 FULL CUDA graph；224 个 pure-prefill steps 中 192 个为 NONE、30 个 PIECEWISE、仅 2 个 FULL；9,466 个 true-mixed steps 中 8,623 个为 NONE、842 个 PIECEWISE、仅 1 个 FULL。本轮 isolated profiles 则关闭 CUDA graph，Frontier comparison 也固定
decode_cuda_graph_mode=none。同一个 nominal operator 在不同 phase/state 下并不是同一个 launch/fusion regime。 - Mixed attention schema 不保真。 vLLM 0.20 的 FA3 对 true-mixed batch 执行一个 fused varlen call；Frontier 必须分别得到
attn_prefill与attn_decode_in_mixed。不做 split 时 simulator 在第一个 mixed batch 明确报 missing prediction；采用 pure-profile ratio split 虽保持prefill + decode = fused total，但 split 是兼容性归因而非真实观测。scheduler 使用这个虚构分解推进后续状态，误差会累积。 - MoE routing 不是固定先验。 对 exact trace 的 8 个 requests、48 层 native routing capture，实际 median load CV 在 prefill/decode 分别为
1.076/1.107，median max/mean expert load 为6.12/5.64；Frontier 固定的 per-layer Uniform prior 分别只有0.485与1.84。实际与 Frontier expert allocation 的逐层 Pearson median 接近 0（prefill-0.017、decode-0.024），而 Frontier 在所有 phase 复用相同 allocation，prefill/decode correlation 被固定为 1.0；真实 median correlation 为0.667。8-request capture 是 mechanism probe，不是 workload population estimate，但足以否证“固定 routing vector 等价于该 trace execution”的假设。
更直接地，在同一个 tp1_mns64 fixture、batch_id=0/layer_id=0、两条 trajectory 尚未分叉时，新 profile 的 layer component sum 已是旧 profile 的 2.70×（1.148→3.101 ms）：MoE grouped GEMM 为 3.76×、RoPE 7.39×、attention prefill 2.67×。这说明版本更新没有产生一个小而一致的 correction；不同 components 的误差方向和幅度不同，随后又通过 scheduler queue、batch composition、graph mode 与 routing 反馈到下一个 state。
因此本实验否证 H1：Frontier 原生支持按 num_tensor_parallel_workers 选择 per-TP profile rows，而且 attention/MoE kernel 也确实可以逐 TP 测量；真正缺失的是 scheduler state 与 execution regime 条件化的 joint counterfactual。 TP 和 MNS 不能拆开：TP 改变 shard、collective、replica capacity、routing placement 与 graph shape，MNS 改变 batching/queue evolution；两者共同决定 phase mixture 和 execution mode。历史 per-TP calibration 是 composition 之后的外部 E2E scale，因此能吸收这些残差，但它不是机制解释，也不是 Frontier 原生 profiling。
下一轮不应继续盲目加 isolated rows，而应依次做可证伪的 context ablation：按 FULL pure-decode、NONE/PIECEWISE prefill/mixed 建立 graph-conditioned step profiles；保留 fused mixed layer/step total 而不是要求不可观测的拆分；用 trace-conditioned per-layer/request/phase routing histogram 替换固定先验；再单独注入 measured collective。每次只改变一个条件，最终仍在完整 TP×MNS joint surface 上以 SLO ranking 验证，frozen calibration 只作为可达到的上界。
本次 accepted profile jobs 使用约 0.118 H20-GPU-hour；包括 smoke 和失败 attempt 的完整 campaign 为 0.410 H20-GPU-hour。冻结 profile、manifest、condensed artifacts 与作图脚本位于 runs/frontier-qwen30-vllm020-profile-v1/。
Case B 结果：Qwen235 FP8 prefill-only
| TP | EP | MNS | MBT | Real | Frontier | Frontier − real |
|---|---|---|---|---|---|---|
| 4 | off | 64 | 8192 | 0.05000 | 0.03750 | -0.01250 |
| 4 | off | 128 | 8192 | 0.05000 | 0.03750 | -0.01250 |
| 4 | off | 64 | 16384 | 0.07500 | 0.06250 | -0.01250 |
| 4 | off | 128 | 16384 | 0.07500 | 0.06250 | -0.01250 |
| 8 | on | 64 | 8192 | 0.05625 | 0.05000 | -0.00625 |
| 8 | on | 128 | 8192 | 0.05625 | 0.05000 | -0.00625 |
| 8 | on | 64 | 16384 | 0.05625 | 0.05625 | 0.00000 |
| 8 | on | 128 | 16384 | 0.05625 | 0.05625 | 0.00000 |
单位均为 SLO-feasible req/s/GPU。这里 Frontier 对 capacity 有明显、且依赖 topology/action family 的绝对 gap：
- TP4/MBT8K 与 TP4/MBT16K 都低估 0.0125 req/s/GPU，但正确预测了 MBT8K→16K 的相对增益。
- TP8/MBT8K 低估 0.00625，而 TP8/MBT16K 恰好匹配；Frontier 因而预测 MBT 在 TP8 上有收益，真机中四个 TP8 config 实际并列。
- 尽管这个 action differential 是错的，TP4/MBT16K 相对其余 config 有足够 margin，所以 simulator top set 仍与 real top set 完全相同，最终 regret=0。
细化边界实验中，Frontier/real 的 33 个 config-load labels 有 6 个 false-infeasible；这些误差在 fresh-server v3 复测中稳定重复。因此这个 case 的结论应严格限定为：Frontier 是有效的 config ranker / conservative screener，但不是精确的 capacity estimator，也没有完全学对 topology-dependent MBT effect。
Case C 结果：Qwen235 FP8 fixed-shape mixed
2026-07-16 在 dash0 GPU 0--3 上完成了 community vLLM 0.10.2、TP4/DP1、MNS64、MBT8192、eager、BF16 KV、prefix/spec/CUDA graph off 的 pilot。所有请求实际 usage 和 streaming token count 都严格为 ISL=2,048、OSL=128：
| load | requests | TTFT mean/p95 | TPOT mean/p95 | 40 ms joint SLO |
|---|---|---|---|---|
| single | 1 | 586.2 / 586.2 ms | 136.2 / 136.2 ms | 0/1 |
| concurrency=2 | 2 | 310.2 / 434.3 ms | 124.3 / 124.9 ms | 0/2 |
Frontier 使用与成功 prefill ranking 相同的 frozen source fingerprint、TP4 KV blocks=26,101 和 block size=16。第一次运行完成 prefill 并提交第一个 decode token后，在纯 decode batch 抛出 attention decode prediction cache not found for cluster monolithic。初始化日志给出直接原因：no standard decode rows，而 final attention CSV 的 726 rows 全部是 prefill rows。该 crash 没有被记为 SLO fail，也没有使用 dummy prediction。
随后在 dash0 单张 H20 上用同一 community-vLLM/FlashInfer 栈补测 TP4、batch {1,2}、KV {2048,2176} 的 4 个 CUDA-event decode points。profile-closed Frontier smoke 精确完成了相同请求：
| load | Real TTFT | Frontier TTFT | Real TPOT | Frontier TPOT |
|---|---|---|---|---|
| single | 586.2 ms | 267.7 ms | 136.2 ms | 88.3 ms |
| concurrency=2 | 186.1--434.3 ms | 470.7 ms | 123.8--124.9 ms | 90.5 ms |
因此 missing-row blocker 已关闭，但 absolute error 明显且不是固定比例；这正是需要 config surface 而不能只看单点 latency 的原因。steady-QPS 下还会出现 prefill+decode true-mixed batches，最小 4-row profile 不足以支持完整 sweep。完整 closure 另外测量了 TP4/TP8 各 81 个 standard-decode points 和 108 个 true-mixed points，覆盖 decode batch 到 128、KV 2,048--2,175；合并 root 共 1,104 rows。Frontier 已确认用 108 个 TP-specific samples 训练 attn_decode_in_mixed，没有使用本 case 的 E2E latency calibration。
完整 8 configs × 8 rates simulator surface 已在任何真机 surface cell 之前冻结，manifest SHA256 为 801aa36451c8647f71cc87011144622d2203786e82f189ed1375d964399b106a。64/64 cells 都有 64 个 finite、非负、shape-exact request records，累计 simulator CPU time 为 11,675.2 s。冻结结果如下，单位为最大被测试可行 req/s/GPU：
| config family | TPOT 40 ms | TPOT 120 ms | TPOT 150 ms | TPOT 180 ms |
|---|---|---|---|---|
| TP4，任意 MNS/MBT | none | 0.20 | 0.40 | 0.60 |
| TP8，任意 MNS/MBT | none | 0.05 | 0.15 | 0.20 |
Frontier 在同一 TP family 内给四个 MNS/MBT config 生成了逐 request 完全相同的结果，即它预测这些 controls 在当前 load range 都不 binding；150 ms sensitivity 下则预测 TP4 family 的 per-GPU capacity 是 TP8 的 2.67×。这两个判断均已用下面的完整真机 surface 检验。
第一次真机 surface attempt 还暴露了一个 measurement-contract 问题：一个 fresh server 内连续测多个 rates 会把前一 anchor 的 execution warm state 带入后一 anchor。两个 TP4/MNS64 config 在正向 0.10→1.60→2.40 的 1.60 点分别只有 36/64、41/64 requests 通过 150 ms SLO；反向先运行 2.40 后，同一 1.60 点都变成 64/64。逐段看，正向 1.60 的前 24 requests TPOT 从约 234 ms 递减到 169 ms，后半段才稳定到 114--134 ms；反向 1.60 从第一个 request 起就在 113--128 ms。这个 attempt 整体排除，不能用“两个 round 都通过”的保守聚合掩盖 real 与 simulator 的 state contract 不同。
修正后的 ground-truth contract 对每个 (config, rate, round) 独立启动 server，并在目标 rate 下丢弃 min(32, max(4, ceil(rate×20))) 个 exact-shape warmup requests。anchor-isolation smoke 在两个 config、两个 fresh-server repeats 上均为 64/64 completed、0 failure、150 ms SLO 64/64；四次 p95 TPOT 为 127.8--138.0 ms，p95 TTFT 为 295.8--305.5 ms。只有这个通过 gate 的 contract 会进入最终 real capacity/rank。
完整评测 setup
| 项目 | 设置 |
|---|---|
| 真机 | dash0，8×NVIDIA H20（97,871 MiB/GPU、driver 580.95.05、NV18）；TP4 cells 各独占 4 GPU，TP8 cells 独占全部 8 GPU |
| model/runtime | Qwen/Qwen3-235B-A22B-FP8；community vLLM 0.10.2、Python 3.12.3、torch 2.8.0+cu128、FlashInfer 0.3.1.post1；eager、FP8 weights、BF16 KV |
| workload | 64 个不同 token 的固定长度 requests；ISL=2,048、OSL=128、uniform QPS、prefix/speculative decoding/CUDA graph off |
| config surface | TP∈{4,8} × MNS∈{64,128} × MBT∈{8192,16384}；TP4 为 EP off，TP8 为 EP on |
| simulator | Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e + frozen best-effort patches；1,104-row attention profile；无本 case E2E calibration |
| simulator anchors | 每个 config 都运行 {0.10,0.20,0.40,0.80,1.20,1.60,2.40,3.20} req/s；64/64 cells 在真机 surface 前冻结 |
| real anchors | 围绕冻结 simulator boundary 运行并自适应补齐相邻点；共 34 config-rate cells × 2 independent rounds |
| 每个 real anchor | fresh vLLM server；先按目标 rate 丢弃 min(32,max(4,ceil(rate×20))) 个 warmup requests，再从空 scheduler queue 测 64 requests |
| primary SLO | ≥61/64 requests 同时满足 TTFT≤1,256 ms、TPOT≤150 ms；两个 rounds 均通过才判定 feasible |
| primary objective | 最大被测试可行 offered req/s / 实际占用 GPU 数 |
150 ms 是看到最低负载真实 TPOT 已达 136.2 ms 后公开记录的 post-pilot amendment；原 40 ms 阈值仍保留，但所有 config 在最低 anchor 都不可行。120 ms sensitivity 的 lower boundary 尚未补齐，180 ms sensitivity 在最高 3.20 anchor 仍有 censored cells，因此本文只对 150 ms primary SLO 报告完整 ranking。
完整结果
| TP | MNS | MBT | Real | Frontier | Real boundary：pass → fail（两个 rounds） |
|---|---|---|---|---|---|
| 4 | 64 | 8192 | 0.60 | 0.40 | 2.40: 64/64,64/64 → 3.20: 57/64,59/64 |
| 4 | 64 | 16384 | 0.60 | 0.40 | 2.40: 64/64,64/64 → 3.20: 62/64,57/64 |
| 4 | 128 | 8192 | 0.60 | 0.40 | 2.40: 64/64,64/64 → 3.20: 53/64,55/64 |
| 4 | 128 | 16384 | 0.60 | 0.40 | 2.40: 64/64,64/64 → 3.20: 52/64,54/64 |
| 8 | 64 | 8192 | 0.30 | 0.15 | 2.40: 64/64,64/64 → 3.20: 46/64,48/64 |
| 8 | 64 | 16384 | 0.20 | 0.15 | 1.60: 64/64,64/64 → 2.40: 45/64,53/64 |
| 8 | 128 | 8192 | 0.20 | 0.15 | 1.60: 64/64,64/64 → 2.40: 40/64,56/64 |
| 8 | 128 | 16384 | 0.30 | 0.15 | 2.40: 64/64,64/64 → 3.20: 50/64,46/64 |
Real 与 Frontier 单位均为 SLO-feasible req/s/GPU；boundary 的 offered rate 单位为 system req/s。所有 8 个 real boundaries 都由相邻 lattice points 闭合。四个 TP4 configs 是 real 与 simulator 的共同、完全相同的 top set，因此 optimistic/worst tie-break regret 都是 0。Kendall τ-b=0.8944；28 个 config pairs 中 exact >/< /= sign 命中 24 个，20 个 real non-tie pairs 中命中 16 个方向。34 个实际测量的 config-load labels 中，Frontier 命中 24 个，有 10 个 false-infeasible、0 个 false-feasible。
这个结果同时给出一个比“absolute error”更重要的反例。TP8 真机在 2.40 system req/s 上的 feasibility matrix 是：
MBT 8K MBT 16K
MNS 64 pass fail
MNS 128 fail pass
换成 capacity，ΔMBT | MNS64 = -0.10，而 ΔMBT | MNS128 = +0.10 req/s/GPU，difference-in-differences 为 +0.20 req/s/GPU。也就是说，MBT 的作用方向取决于 MNS；它们不能被看成两个独立、可加的 controls。 Frontier 对四个 TP8 cells 都预测 0.15，interaction 恰好为 0。相同四个 configs 在 1.60 及以下都通过，差异只在持续高负载下出现，说明问题不只是单个 operator 在空载下的固定时间偏差，而发生在 batching/scheduling state 与 execution topology 的组合上。现有数据还不能区分具体是 batch composition、MoE EP communication、memory/KV pressure，还是 runtime 的其他动态状态；下一步应对此边界做 scheduler batch trace、per-step kernel/NCCL timeline 与 KV/queue counters，而不是先给出未经验证的根因。
因此本 case 的严格结论是：Frontier 足以在这个 8-config surface 上选择全局最优 topology，但不足以解释或优化 TP8 family 内的 MNS/MBT controls。 成功来自 TP4-vs-TP8 的真实 margin 足够大，能够容忍 TP4 33.3%、TP8 25%--50% 的 capacity 低估和内部 action-ordering error；它不是 simulator 已获得 scheduling/execution 深层认知的证据。
接受的 ground-truth 共 18 个 fleet jobs、68 个 fresh-server anchors、4,352 个 measured requests 和 1,664 个 warmup requests，消耗 36.26 H20-GPU-hours；从第一个 accepted job 到最后一个完成的墙钟跨度为 5.74 小时。增量 full-attention closure 在单张 H20 上运行 12 秒（0.0033 H20-GPU-hours），但它复用了此前已有的 726-row prefill profile，因此这个数字不是构建全部 compatibility envelope 的总成本。另有共享 GPU/endpoint 的污染 attempts 和暴露 cross-anchor warm-state leakage 的 diagnostic attempts 被整目录隔离，不进入上述统计。Frontier 64-cell surface 消耗 11,675.2 CPU-seconds。完整 hash、逐 anchor input 与排除 ledger 见本节末的复现链接。
完整证据见 T0 smoke report 与 预注册协议。
原预注册的 TPOT 40 ms 因最低负载已不可行而失去 capacity-ranking 可辨识性；本文已把 150 ms 明确记录为 post-pilot protocol amendment，并保留 40 ms 全部失败的 sensitivity 结果，没有把 SLO change 隐藏成预注册结论。
Case D 结果：Qwen30 BF16 prefill-only
结果不是“绝对 capacity 有偏差但 rank 可用”，而是完整的 topology ordering reversal：
| TP | MNS | Real | Frontier profile-only | 差异 |
|---|---|---|---|---|
| 1 | 8/16/32/64 | 7.0 | 8.0 | +1.0 |
| 2 | 8/16/32/64 | 7.0 | 8.0 | +1.0 |
| 4 | 8/16/32/64 | 8.0 | 6.0 | -2.0 |
单位为最大被测试 SLO-feasible req/s/GPU。四个 TP4 configs 是真机 top set；Frontier 却把全部八个 TP1/TP2 configs 判为 top set，两者无交集。部署任一 simulator top config 都只能在真机上得到 7 req/s/GPU，因此 optimistic 与 worst tie-break regret 都为 1-7/8=12.5%。Kendall τ-b=-1.0；32 个 real non-tie pairs 中 0 个同序。96 个 config-load decisions 中 80 个一致，但同时有 8 个 false-feasible 和 8 个 false-infeasible，它们刚好跨过了不同 TP family 的 capacity boundary。
错误从哪里开始放大
代表性 MNS=8 anchors 表明，低负载单次 execution time 并没有数倍偏差，错误主要在接近饱和时被 queue 放大：
| Config / system rate | Real TTFT p95（两轮） | Frontier TTFT p95 | Real / sim SLO |
|---|---|---|---|
| TP1 @ 4 req/s | 154.1 / 153.6 ms | 171.6 ms | pass / pass |
| TP1 @ 8 req/s | 1289.2 / 1254.4 ms | 516.4 ms | fail / pass |
| TP2 @ 8 req/s | 97.7 / 93.8 ms | 122.2 ms | pass / pass |
| TP2 @ 16 req/s | 1389.9 / 1365.0 ms | 962.8 ms | fail / pass |
| TP4 @ 4 req/s | 82.3 / 69.6 ms | 93.1 ms | pass / pass |
| TP4 @ 32 req/s | 1136.6 / 1134.0 ms | 1787.9 ms | pass / fail |
这排除了“只要给所有 kernel 乘一个 global scale 就能修好”的解释：相同 stack 在低负载下接近，但在不同 TP 的饱和边界上向相反方向偏移。更符合数据的抽象是：小的 per-step composition residual 改变 service rate，再通过 scheduler queue 的非线性反馈放大成 TTFT 和 capacity 边界错误。
当前证据可以排除一些原因，但还不能唯一定位根因：
- Decode/true-mixed schema 不是必要条件。 这个 workload 没有 decode、FULL decode CUDA graph、fused true-mixed attention 或 initial-KV state，排序仍然失败。这些机制可能在 mixed/decode 中进一步增大误差，但不是本次失败的前提。
- Communication 可能解释部分 TP scaling，但不能单独解释全部误差。
profile-v2/allreduce.json已有 24 个 TP2/TP4 实测 rows，但 base Frontier 为了保持历史对照使用 analytical 600-Gbps/1-µs collective，没有注入这些数据。下一步必须单独做 measured-collective ablation；但 TP1 无 collective 仍在 8 req/s 出现 773 ms 的 p95 低估，所以 collective 不会是唯一根因。 - Profile 覆盖了 token count，却未必覆盖 scheduler 实际产生的 batch composition。 linear/MoE rows 覆盖到 8,192 tokens，但 exact-2,048 pure-prefill attention 在每个 TP 下只有 batch=1 的直接样本；实际 MBT=8,192 可以产生多个 2,048-token sequence 的组合。这是一个需要补测的 coverage hypothesis，不是已证明根因。
- Routing、step composition 和 scheduler batch state 仍然是联合候选。 pure-prefill 只排除了 phase mixing，没有排除 MoE routing、TP-specific local shape、launch/fusion 和持续负载下 batch/queue trajectory 的耦合。
为什么 235B 能选对，30B 却选错
现有数据不支持“235B 大所以 simulator 更容易”这种模型大小因果。两个 case 的 precision、vLLM 版本、attention backend、graph mode、EP 和 profile closure 都不同。能被数据直接支持的区别是 decision margin：
- 235B mixed 真机中 TP4 最优 capacity 为 0.60 req/s/GPU，最好 TP8 为 0.30，有
2×margin；Frontier 虽然漏掉 TP8 的 MNS×MBT interaction，仍预测 TP4/TP8 为 0.40/0.15，所以 residual 没有穿过全局拓扑边界。 - 30B prefill-only 真机 TP4 相对 TP1/TP2 只有 8 vs. 7 req/s/GPU 的 margin。Frontier 预测为 6 vs. 8，TP-dependent residual 大于真实 margin，因而把最优 topology 完整反转。
因此，“prefill-only 容易，decode/mixed 困难”的强假设已被否证。phase 仍可能改变 residual 的幅度，但它不是 fidelity 的充分条件。按预注册 decision rule，此时不应继续无区分度地扩展更多 phase cases，而应在 Qwen30 同一 model/workload 上按单变量顺序做：measured collective injection → batch-composition-conditioned pure-prefill attention/step profile → 在 TP1@8、TP2@16、TP4@32 对齐 real/sim scheduler batch、queue 与 per-step critical path → 最后再测 routing/graph。
本 case 接受的 ground truth 共 24 个 fleet jobs、192 个 fresh-server anchors、12,288 个 measured requests 和 4,512 个 warmup requests，消耗 12.07 H20-GPU-hours。运行中曾因 fleet controller 在 fresh-server 空窗误判 GPU 为空闲而产生重叠 launch；这些 attempts 未被合并到 accepted artifact root，已整体隔离并用独立 queue state 重跑。最终 comparison SHA256 为 c9a9cac9f60c7be804d1cb9466c455f8fe9e3a8dc60b9cec3329bde6a8c19334。
尚不能纳入 simulator ranking 的 case
原 internal-runtime Qwen235 prefill-only
原实验有 8/8 valid real cells，但使用不同的 serving/runtime contract，real top set 是四个 TP8 config。它没有与本文 best-effort Frontier 使用同一个 community-vLLM FP8 profile/serving contract，不能和新 simulator 数值直接拼接。本文的 community-vLLM Case B 是目前可辩护的 aligned prefill comparison。
原 Qwen235 decode-only
真实 surface 有 7/8 valid cells，且 capacity 搜索区间大量重叠：经验 top set 为 5/8，而考虑 bracket uncertainty 时 8/8 都可能最优。更关键的是，该 case 依赖 initial KV state、DecodeBenchConnector、EAGLE3、FP8 KV、DeepEP/NVSHMEM 与 decode CUDA graphs；Frontier 当前没有等价的 initial-KV/EP8 execution contract。因此现在给出 simulator-vs-real rank 或 regret 都会把 contract mismatch 误写成 fidelity 结果。
下一步不再用 decode-dominant mixed workload 回避问题，而是在 community vLLM 0.10.2 与 Frontier 两侧增加显式、相同的 initial-KV contract：request 到达时分配与 input length 对应的 KV blocks、标记 prefill complete，再从第一步 decode 开始调度。首先关闭 speculative decode、prefix cache 和 decode CUDA graph，建立 fixed-shape decode-only baseline；随后按单变量顺序启用 trace lengths/prefix、EP8、EAGLE3 和 FULL_DECODE_ONLY graph。每一层都重新报告 ranking，不能把后一层的 mismatch 归因给前一层。
当前判断与下一步 gate
当前证据的结论是：
- 绝对 gap 不是否决 simulator 的理由。 Qwen235 中 11%--50% 的 capacity 低估仍可保持 zero-regret config selection。
- rank 成功不能证明模型机制正确，rank 失败则表明 residual 穿过了 decision margin。 Qwen235 prefill 的 TP8 MBT differential 错误，fixed-shape mixed 又漏掉 TP8 的 MNS×MBT 非加性交互，但大 topology margin 保住了 top set；Qwen30 prefill-only 的较小 margin 被 TP-dependent saturation residual 穿过，导致 τ-b=-1 和 12.5% regret。
- prefill-only 不是 fidelity 的充分容易条件。 Qwen30 在没有 decode、prefix reuse、initial KV 和 true-mixed batch 时仍选错 topology。phase 可以改变 residual，但不能单独作为 compatibility-envelope 边界。
- alignment 是结果的一部分。 Qwen30 mixed 需要 per-TP E2E calibration 才能恢复排序，同栈 operator profile 或去掉 mixed phase 都不足；Qwen235 不需要本 case E2E calibration，但需要同栈 FP8 profiles、真机 KV capacity 和 simulator patches。论文必须报告这部分真机成本，不能把它隐藏在“offline profiles”中。
- 现在有了可复现的全局选优反例，但尚不足以声称 simulator 普遍失败。 Qwen30 BF16 prefill-only 是一个无 top-set overlap 的稳定反例；Qwen235 两个 case 又证明 Frontier 在某些 envelope 内足以选优。更有研究价值的 premise 是：什么 state-conditioned action residual 决定 ranking 是否能跨过 real margin，以及如何在不做全 surface 真机 sweep 的情况下检测这个风险。
后续每个 case 建议使用同一 gate：worst selected-config regret ≤5%、tie-aware rank correlation ≥0.8、足够数量的 informative pairs、ground-truth bracket 不足以反转最优决策，并单独报告达到该结果所需的 real-GPU profiling/calibration cost。当前下一 gate 是在 Qwen30 prefill-only 上做同模型单变量 context ablation，而不是继续扩展跨模型 phase 矩阵。
数据与复现
- 图表输入：data.json
- 画图脚本：plot_simulator_fidelity.py
- Qwen30 audit：report.md
- Qwen30 aligned metrics：metrics.json
- Qwen30 prefill-only experiment card：experiment-card.md
- Qwen30 prefill-only comparison：comparison.json
- Qwen30 prefill-only capacity table：capacity.csv
- Qwen30 prefill-only analyzer：analyze_qwen30_prefill_fidelity.py
- Qwen235 fixed-cohort comparison：v2_refined_comparison.json
- Qwen235 full report：report.md
- Fixed-shape mixed comparison：comparison.json
- Fixed-shape mixed capacity table：capacity.csv
- Frozen Frontier surface：frontier_surface_frozen.json
- Executed real plan：real-plan-executed.json
- Real exclusions/acceptance ledger：exclusions.json
- Fixed-shape / trace-faithful / decode-only 分阶段协议：protocol.md
- Trace tokenizer/hash contract audit：trace-contract-audit.json
- Trace contract audit reproducer：audit_trace_contract.py
- T0 real smoke 与 Frontier decode-profile failure：t0-smoke-report.md
- 尚未对齐 case 的 real-only audit：report.md
重新生成 PNG/SVG：
python3 scripts/plot_simulator_fidelity.py
python3 runs/frontier-phase-factorial-v0/analyze_qwen30_prefill_fidelity.py \
--fleet-artifacts runs/frontier-phase-factorial-v0/fleet-artifacts-exclusive \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-tp1/frontier_surface_frozen.json \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-tp2/frontier_surface_frozen.json \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-tp4/frontier_surface_frozen.json \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-refine-tp1/frontier_surface_frozen.json \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-refine-tp2/frontier_surface_frozen.json \
--simulator-manifest runs/frontier-phase-factorial-v0/simulator-refine-tp4/frontier_surface_frozen.json \
--output-root runs/frontier-phase-factorial-v0/results/final
cp runs/frontier-phase-factorial-v0/results/final/qwen30-prefill-ranking.png \
docs/assets/simulator-fidelity/qwen30-prefill-ranking.png