Evaluate vLLM 0.20 profiles against Frontier

simulator-fidelity.md

@@ -0,0 +1,360 @@
+# Frontier simulator fidelity：以 config ranking 为目标的阶段性评测
+
+更新日期：2026-07-16。
+
+统一实验平台：所有新增与重跑实验只使用 `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 个方向。
+- 现有结果表明：**在已对齐的受控 case 中，绝对 capacity 有 gap、甚至 action differential 错误，都不必然妨碍 Frontier 找到当前 surface 的最优 config。** 统一 dash0 campaign 已完整覆盖 Qwen235 FP8 prefill-only 与 fixed-shape mixed，但仍不能外推到 trace-faithful mixed 或 decode-only，也不能忽略达到这种 fidelity 所需的真机 profile、KV capacity、runtime-semantic patch 或 calibration 成本。
+
+因此，现阶段最准确的 research statement 不是“simulator 排序一定错误”，而是：
+
+> Simulator 的 usefulness 取决于 compatibility envelope。问题是需要多少、什么类型的真机信息，才能使其 config ranking 可被信任；以及当 workload、runtime 或 execution topology 变化时，如何低成本判断该 envelope 是否仍成立。
+
+## 评测口径
+
+对系统 `s ∈ {real, sim}` 和 config `c`，定义：
+
+```text
+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 给出多个并列最优，任取其中最差一个在真机上的损失：
+
+  ```text
+  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 总结](docs/simulator-fidelity-frontier-20260711.md) 中基于 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 条件：
+
+1. **Profile-only**：直接使用已有 H20 operator profiles，不用 serving E2E 数据修正时间尺度。
+2. **Frozen per-TP calibration**：使用 `TP1=0.723481, TP2=0.468089, TP4=0.352137` 三个 execution-time scales。它们在独立的 `coder_200_ts2` workload 上拟合，并在 `coder_200_ts3` 上冻结验证；本 `chat` surface 不重新拟合。该 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。
+
+## 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 |
+| 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 结果依赖 per-TP E2E calibration；Qwen235 的 high-fidelity 结果不依赖本 case 的 E2E calibration，但依赖同 runtime/hardware 的 operator profile、真实 KV capacity 和多处 compatibility fixes。二者都不能表述为“拿 stock Frontier 零成本预测即可”。
+
+## Case A baseline 结果：Qwen30 mixed serving
+
+![Qwen3-30B mixed serving simulator-vs-real config ranking](docs/assets/simulator-fidelity/qwen30-mixed-config-ranking.png)
+
+图中 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。
+
+![Qwen3-30B vLLM 0.20 profile-only ablation and execution-context diagnostics](docs/assets/simulator-fidelity/qwen30-vllm020-profile-ablation.png)
+
+完整 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 收敛到以下三个相互耦合的层面：
+
+1. **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。
+2. **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 使用这个虚构分解推进后续状态，误差会累积。
+3. **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
+
+![Qwen3-235B FP8 prefill-only simulator-vs-real config ranking](docs/assets/simulator-fidelity/qwen235-prefill-config-ranking.png)
+
+| 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。
+
+### 完整结果
+
+![Qwen3-235B fixed-shape mixed simulator-vs-real config ranking](docs/assets/simulator-fidelity/qwen235-t0-fixed-shape-ranking.png)
+
+| 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 是：
+
+```text
+                  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](runs/frontier-multicase-sufficiency-v1/t0-smoke-report.md) 与 [预注册协议](runs/frontier-multicase-sufficiency-v1/protocol.md)。
+
+原预注册的 TPOT 40 ms 因最低负载已不可行而失去 capacity-ranking 可辨识性；本文已把 150 ms 明确记录为 post-pilot protocol amendment，并保留 40 ms 全部失败的 sensitivity 结果，没有把 SLO change 隐藏成预注册结论。
+
+## 尚不能纳入 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
+
+当前证据的结论是：
+
+1. **绝对 gap 不是否决 simulator 的理由。** Qwen235 中 11%--50% 的 capacity 低估仍可保持 zero-regret config selection。
+2. **但 rank 成功不能证明模型机制正确。** Qwen235 prefill 的 TP8 MBT differential 错误，fixed-shape mixed 又漏掉 TP8 的 MNS×MBT 非加性交互；Qwen30 还有 28/92 anchor SLO labels 错误。只是当前 decision margin 足以容忍这些 residual。
+3. **alignment 是结果的一部分。** Qwen30 需要 per-TP E2E calibration 才能恢复排序；Qwen235 不需要本 case E2E calibration，但需要同栈 FP8 profiles、真机 KV capacity 和 simulator patches。论文必须报告这部分真机成本，不能把它隐藏在“offline profiles”中。
+4. **目前不能建立“simulator 全局选优普遍失败”的 premise。** 受控 prefill、fixed-shape mixed 和历史 mixed surface 上，经过 alignment 的 Frontier 已经能选到最优或 0.76% 内的近最优 config。更有证据的 research premise 是：aggregate selection success 会掩盖 action interaction 与 state-transition model 的错误；若要声称全局选优失败，仍必须在 dash0 的 trace-faithful mixed、decode-only、prefix cache 或跨 topology case 上得到稳定反例。
+
+后续每个 case 建议使用同一 gate：worst selected-config regret ≤5%、tie-aware rank correlation ≥0.8、足够数量的 informative pairs、ground-truth bracket 不足以反转最优决策，并单独报告达到该结果所需的 real-GPU profiling/calibration cost。
+
+## 数据与复现
+
+- 图表输入：[data.json](docs/assets/simulator-fidelity/data.json)
+- 画图脚本：[plot_simulator_fidelity.py](scripts/plot_simulator_fidelity.py)
+- Qwen30 audit：[report.md](runs/frontier-multicase-sufficiency-v0/results/qwen30-baseline/report.md)
+- Qwen30 aligned metrics：[metrics.json](runs/frontier-slo-alignment-v0/results/metrics.json)
+- Qwen235 fixed-cohort comparison：[v2_refined_comparison.json](runs/frontier-multicase-sufficiency-v0/best_effort/fixed_cohort_evidence/v2_refined_comparison.json)
+- Qwen235 full report：[report.md](runs/frontier-multicase-sufficiency-v0/best_effort/fixed_cohort_evidence/report.md)
+- Fixed-shape mixed comparison：[comparison.json](runs/frontier-multicase-sufficiency-v1/results/t0-final/comparison.json)
+- Fixed-shape mixed capacity table：[capacity.csv](runs/frontier-multicase-sufficiency-v1/results/t0-final/capacity.csv)
+- Frozen Frontier surface：[frontier_surface_frozen.json](runs/frontier-multicase-sufficiency-v1/artifacts/frontier-t0-surface-v1/frontier_surface_frozen.json)
+- Executed real plan：[real-plan-executed.json](runs/frontier-multicase-sufficiency-v1/artifacts/t0-real-surface-v1/real-plan-executed.json)
+- Real exclusions/acceptance ledger：[exclusions.json](runs/frontier-multicase-sufficiency-v1/artifacts/t0-real-surface-v1/exclusions.json)
+- Fixed-shape / trace-faithful / decode-only 分阶段协议：[protocol.md](runs/frontier-multicase-sufficiency-v1/protocol.md)
+- Trace tokenizer/hash contract audit：[trace-contract-audit.json](runs/frontier-multicase-sufficiency-v1/trace-contract-audit.json)
+- Trace contract audit reproducer：[audit_trace_contract.py](runs/frontier-multicase-sufficiency-v1/audit_trace_contract.py)
+- T0 real smoke 与 Frontier decode-profile failure：[t0-smoke-report.md](runs/frontier-multicase-sufficiency-v1/t0-smoke-report.md)
+- 尚未对齐 case 的 real-only audit：[report.md](runs/frontier-multicase-sufficiency-v0/results/ground-truth/report.md)
+
+重新生成 PNG/SVG：
+
+```bash
+python3 scripts/plot_simulator_fidelity.py
+```