# Qwen3-235B FP8：Frontier 与 community vLLM config rank 对比

## 结论

在本实验限定的 Qwen3-235B-A22B-FP8、H20、prefill-only workload 上，经过 best-effort 补齐 FP8/MoE serving path 后，Frontier **能够选对满足 SLO 的 per-GPU throughput 最优配置**：`TP=4, MBT=16384`，`MNS=64/128` 并列。细化网格上的 Spearman rank correlation 为 `0.9487`，20 个可比较非 tie config pair 全部同序，选择 regret 为 `0`。

但这不等于 Frontier 已精确模拟系统。原始粗网格给出 56/56 load labels 正确、Spearman=1 的表象；加入 decision-boundary rates 后，Frontier 在 33 个被测试边界点中产生 6 个 false-infeasible，均为两个 MNS 配置上可复现的稳定误差。它系统性地把三个 action family 的最大经验 SLO throughput 低估一个 `0.05 req/s` 档位：

| TP | MBT | Frontier capacity | real capacity | real v2→v3 transition | 结论 |
|---:|---:|---:|---:|---|---|
| 4 | 8192 | 0.15 | 0.20 | `0.20: 61→61`, `0.25: 60→60` | 稳定低估 0.05 |
| 4 | 16384 | 0.25 | 0.30 | `0.30: 61→61`, `0.35: 59→59` | 稳定低估 0.05 |
| 8 | 8192 | 0.40 | 0.45 | `0.45: 61→61`, `0.50: 60→60` | 稳定低估 0.05 |
| 8 | 16384 | 0.45 | 0.45 | v2: `0.45: 61`, `0.50: 60` | 边界正确 |

表中 pass count 分母均为 64，经验可行门槛为 61。每一行的两个 MNS 结果一致；v3 对前三行的两个 MNS 都做了 fresh-server 复测。

因此，对这个 case 最准确的判断是：

- Frontier 有较好的 **decision/ordinal fidelity**，不能再用“它找不到最优 config”作为该 case 的研究 premise。
- Frontier 没有达到 **capacity calibration fidelity**，也没有完全学对 action effect；它适合筛选，但不能在 SLO knee 附近代替真机 capacity certification。
- 粗网格上的“完全匹配”并不足以证明 simulator solve 了问题；它会同时掩盖绝对容量误差和错误的 action differential。

## 固定实验口径

| 项目 | 固定值 |
|---|---|
| model | `models/Qwen/Qwen3-235B-A22B-FP8` |
| real runtime | community vLLM 0.10.2 |
| hardware | dash0，8×NVIDIA H20 |
| workload | prefill-only，raw completion，output tokens=1，prefix cache disabled |
| config surface | `TP∈{4,8} × MNS∈{64,128} × MBT∈{8192,16384}` |
| cohort | 64 个固定 prompt；所有 config/rate 的 request ID、顺序、输入长度完全相同 |
| input length | p50=1478，p95=18439，max=29385，mean=3511.55 tokens |
| 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 |
| primary SLO | `TTFT ≤ 1000 ms + input_tokens / 8000 tokens/s`，至少 95% requests 通过 |
| capacity | 所有 64 requests 完整结束后，最大被测试可行 offered rate；不做 early stop/二分单调假设 |
| primary objective | capacity / TP，即 per-GPU request throughput |

cohort 只通过 uniform arrival scaling 改变 load，不随 rate 重新抽样。该设计消除了 workload composition confound，但 64-request 固定 cohort 的结果仍是经验容量，不代表总体 workload distribution 的置信界。

## Frontier best-effort 公平性

这里比较的不是未经修改的 stock Frontier。为了避免“故意把 baseline 调差”的质疑，我们在真机 ranking 冻结前完成并冻结了以下补齐：

- 使用 community vLLM 0.10.2 在 H20 上得到的真实 FP8 operator profiles；quantization contract 为 FP8 W8A8 dynamic activation、BF16 output/accumulation，而不是用 BF16 compute profile 冒充 FP8。
- 补齐 Qwen MoE community serving path、MoE plan 与 serving entrypoint。
- 按真实 expert route 构造 EP local lanes，并以最慢 lane 作为同步 critical path。
- 修正 TP/EP-aware profile cache key，避免不同 topology 错用缓存结果。
- 使用 batched lane prediction；与逐 lane exact path 做 byte-identical equivalence 后才用于完整 sweep，模拟运行加速约 2.57×。
- KV block capacity 使用真机测量值：TP4=26101，TP8=62351。
- Frontier refined 8×11=88 个结果在真机运行前冻结；旧 rates 的 56 个结果与先前 freeze byte-identical。没有用真机 v2/v3 结果回调 simulator 参数。

相关实现与审计入口包括：

- `fixed_cohort_rank.py`
- `frontier_fp8_profile_contract.patch`
- `frontier_moe_serving_path.patch`
- `frontier_moe_ep_prefill_exact_cache.patch`
- `frontier_moe_ep_prefill_use_batched_lanes.patch`
- `frontier_moe_ep_prefill_batched_lane_predict.patch`

这说明结果反映的是“给 Frontier 当前抽象最大的合理帮助以后，它能做到什么”，不是 stock baseline 的缺功能测试。

## 三阶段实验结果

### v1：blind 全表面、粗网格

Frontier 先冻结，再运行 community vLLM 的 8 configs × 7 rates：

- 56/56 config-load primary feasibility labels 正确。
- raw capacity 与 per-GPU efficiency 的 top set 均完全匹配。
- Spearman=1，20/20 非 tie pair 同序，top-1 regret=0。
- 但 3584 个 request 的 TTFT MAE 为 124.20 ms，MAPE 为 20.98%，平均 `predicted-real=+93.20 ms`。
- request-level SLO label accuracy 为 96.82%；Frontier/real failure-set Jaccard 仅 0.7569（103 false fail、11 false pass）。

因此，aggregate capacity 完全匹配时，具体失败请求和 request latency mechanism 已明显不匹配。

### v2：反向 config/rate 顺序，加入细化边界

v2 只重跑预注册 SLO transition 及中间 refinement rates，共 8 configs、33 loads、2112 requests：

- 0 server/request failure，0 early stop，0 monotonicity violation；所有 trace hash 匹配 refined protocol。
- per-GPU top set 仍精确匹配：`TP4, MBT16384, MNS64/128`。
- Frontier/real per-GPU capacity Spearman=0.9487，20/20 非 tie pair 同序，regret=0。
- 33 个边界点中 27 个 feasibility label 正确；6 个错误全部是 false-infeasible，没有 false-feasible。
- pass-rate MAE=1.278 percentage points，平均 `Frontier-real=-1.278 pp`。
- 2112 个 request 的 TTFT MAE=83.15 ms，MAPE=16.34%，平均 `predicted-real=+53.02 ms`。
- request SLO label accuracy=98.34%，failure-set Jaccard=0.7535。

v1 与 v2 的 19 个共同 config-load 点包含 1216 个相同 requests：

- 真机 trial-to-trial TTFT MAE=14.05 ms，absolute-error p95=57.94 ms，平均 v2-v1=+1.75 ms。
- primary request label 只有 1/1216 flip；19/19 load labels 和 8/8 原始网格 capacity 全部稳定。
- Frontier 有 23 个 request label 在两次真机 trial 中都稳定预测错误。

这排除了 config order 和普通 runtime noise 是主要 residual 来源。

### v3：只复测 v2 的全部争议 transition

v3 的选择规则是 v2 中所有 Frontier/real primary capacity 不同的 config；它是 data-dependent replication，不作为新的 blind primary result。共 6 configs、12 loads、768 requests：

- 0 failure/early-stop/monotonicity violation，trace hash 全部匹配。
- v2 与 v3 的 768/768 primary request labels 完全一致，failure-set Jaccard=1.0。
- 12/12 config-load labels、6/6 capacity boundaries 完全一致。
- 真机 trial-to-trial TTFT MAE=14.98 ms，absolute-error p95=62.52 ms，平均 v3-v2=+1.55 ms。
- Frontier 在该争议集合上仍有 6/12 false-infeasible；18 个 request labels 在 v2/v3 都稳定预测错误。

这证明细化边界误差不是一次随机跨阈值。

## 系统层面的理解

### 1. 绝对误差与 action differential 必须分开

如果只是一个全局 latency scale 偏差，所有 topology 下 MBT 的相对收益应基本保持。数据并非如此：

- TP4：Frontier 预测 MBT `8192→16384` 的 capacity 增益为 `0.15→0.25`，即 +0.10 req/s；真机为 `0.20→0.30`，同样 +0.10。
- TP8：Frontier 预测 `0.40→0.45`，即 +0.05；真机为 `0.45→0.45`，实际增益为 0。

也就是说，Frontier 在 TP4 学对了 MBT differential、错了 absolute offset；在 TP8 则连 differential 都错了。该误差依赖 TP/EP topology，不能靠一个全局 calibration factor 修复。这正是 execution configuration 与 scheduler state/action effect 相互耦合的证据。

### 2. 决策正确不代表 simulator 对系统有正确解释

per-GPU objective 下，TP4/MBT16384 与其他配置有足够大的 margin，所以即便 capacity 每类偏差 0.05，最优 config 仍不变。raw single-replica objective 下，Frontier 只把 TP8/MBT16384 列为 top set，而真机四个 TP8 config 全部在 0.45 并列；虽然从 Frontier top set 中任选仍是 zero regret，但它虚构了 TP8 上 MBT 的收益。

因此需要同时报告：

1. selected-config regret；
2. rank/order fidelity；
3. capacity error；
4. action differential error；
5. request/failure-set fidelity。

只报其中任意一层都会得到偏颇结论。

### 3. residual 是状态/长度相关尾部误差，不是 profile 全局比例错误

v2 中 Frontier 的平均 signed TTFT error 随输入长度显著变化：

| input tokens | mean `predicted-real` | MAE |
|---|---:|---:|
| [0,1024) | -3.61 ms | 40.74 ms |
| [1024,2048) | +44.45 ms | 57.63 ms |
| [2048,4096) | +91.21 ms | 109.73 ms |
| [4096,8192) | +138.80 ms | 140.80 ms |
| [8192,16384) | +237.37 ms | 237.37 ms |
| [16384,32769) | +147.36 ms | 240.89 ms |

短请求甚至略偏乐观，中长请求明显偏保守；与此同时 aggregate load label 只由 1–2 个请求是否跨 SLO 阈值决定。这更像 batch composition、critical-lane/EP synchronization 和 queueing state 共同造成的 residual，而不是 operator profile 全局慢了固定百分比。

### 4. MNS 在该 workload 上是非活跃维度，但不能外推

在所有共同测试点中，MNS=64/128 的 pass counts 基本逐点相同，Frontier 也预测 tie。对这个 prefill-only、固定 cohort、当前 concurrency 范围，MBT/token budget 和 topology 是活跃因素，MNS 没有形成独立瓶颈。但 decode/mixed workload 的 sequence residency、KV pressure 和 iteration cadence 不同，不能据此宣称 MNS 普遍无效。

## 对研究方向的判断

这个 case 不支持以下论文 premise：

> Frontier 类 simulator 无法为 Qwen3-235B FP8 选择最优配置，所以必须由一个新 tuner 替代。

在公平补齐 FP8/MoE path 后，它已经能以 zero regret 选出该 workload 的 per-GPU 最优配置。继续用这一 case 证明“simulator 排序失败”会被 reviewer 用本组数据直接反驳。

本 case 真正揭示、且更有 systems 内容的问题是：

> 一个 simulator 可以在 coarse grid 上拥有完美 rank，并在最终 objective 上 zero regret，同时仍错误表达 topology-dependent action differential 和 SLO knee；我们如何判断一个模拟决策何时足够可信，何时必须回到真机？

可继续发展的研究问题包括：

- decision-aware uncertainty：不追求每条 TTFT 精确，而是给 config ordering/capacity boundary 提供可校验置信区间。
- counterexample-guided measurement：只在模拟 action margin 小或 differential 不稳定的 boundary/state 上调用真机，而不是全表面 sweep。
- topology-aware residual model：显式建模 TP/EP、batch composition、critical lane 与输入长度共同造成的尾部偏差，避免全局比例校准。
- distinguish safe screening from certification：Frontier 当前在该 case 是保守筛选器（0 false-feasible），但不是精确 capacity certifier。

下一步要判断这是否足以构成更一般的 research premise，应转向已计划的 Qwen3-235B decode-only 和 mixed prefill/decode case。它们会激活 KV state、replica residency、iteration cadence 和 communication overlap；如果只有这些 case 出现稳定排序/regret 错误，研究问题就应围绕 simulator 在 stateful execution/scheduling coupling 下的决策失效，而不是泛化地宣称 simulator 不工作。

## 证据与复现

本目录保存紧凑 comparison、trial-stability 与 manifest；完整 request-level freeze 保留在 dash0：

`/home/admin/cpfs/wjh/frontier-community-qwen235-smoke-20260715/rankable-fixed-cohort-v1`

关键 artifact SHA256：

| artifact | SHA256 |
|---|---|
| refined protocol manifest | `695c0500b9a5d51cdd4e39b722e3c9db15f8bed48795454f4d0d6442d24929cb` |
| Frontier refined freeze | `318b3c7742c8371191e2dbd429f0e0e63c1a42f4806a599e018b0548cb9d6336` |
| v1 blind comparison | `fc87c54179b891e2148a738dbdfeed328595fa32198f2248c892c890625c9fe2` |
| v2 run manifest | `cf1a722043f42ff8f435e3521d0b2b2892a8ea0922e1e4870ec10fba26c0f998` |
| v2 community freeze | `5a9c59fc4082db47bec7b59432e9ebe9f907f70baa95a9f0d3480e85f8992ff2` |
| v2 comparison | `d21f2dd846c4d8361668f312f0c063f2e8f949ec7a9d3b19100c813b3da3b586` |
| v1-v2 stability | `a522189618ad26df68f18d2d9b67c38b1fe59c5c8f13af633eced0b092f8e06d` |
| v3 run manifest | `0f8908671b8903e516f0dc8e68f556483a15ff7ec51f7cfbc18a9c74b3a5ba61` |
| v3 community freeze | `4edd25edde3d7508d8feb9b024b5bca4ba6a5f25335ac84008f09c524ed7bc34` |
| v3 comparison | `e04f40ead995e007d64b2f6f0f2731999204907770f05b4c2d037d224e49c573` |
| v2-v3 stability | `7be2ff27dd0393c99f0512bd6a0b7b35eb404ee0bfd22bd3ec33a4b8ce14748b` |

## 限制

- 只测试了一个模型、H20、community vLLM 0.10.2 和 prefill-only workload。
- 固定 64-request cohort 适合 simulator-vs-real paired comparison，但不足以给总体 workload distribution 的 95% SLO capacity 做统计认证。
- v3 是在观察 v2 后选择全部争议点的 replication，不是 blind discovery dataset。
- operator profiles、KV capacity 和 MoE route contract 本身使用了真机信息；本结果评估的是 best-effort simulator 的决策能力与剩余误差，不是 zero-measurement transfer。
- 没有测试 decode、mixed phase、prefix caching、multi-replica placement、异构 GPU 或跨节点通信。
