Files
aituner/simulator-fidelity.md

39 KiB
Raw Blame History

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 包含真机最优 configKendall τ-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-infeasible12 个 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.948720/20 个可比较非 tie config pair 同序,选择 regret 为 0
  • 在 Qwen3-235B-A22B-FP8 fixed-shape mixed 上Frontier 同样给出了与真机完全相同的 TP4 top setKendall τ-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-infeasible20 个 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,定义:

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/matchsimulator top set 是否与 real top set 有交集/完全相同。

  • Worst tie-break regret:若 simulator 给出多个并列最优,任取其中最差一个在真机上的损失:

    max[c in SimTop] (RealBest - capacity_real(c)) / RealBest
    
  • Rank correlation:有并列时优先使用 Kendall τ-bQwen235B 已有冻结分析使用 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 AQwen3-30B-A3B mixed serving

项目 设置
真机 dash08×NVIDIA H20
model Qwen/Qwen3-30B-A3B
serving runtime community vLLM 0.20.0CUDA 12.9 环境
simulator Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e
trace chat_w20260311_1000replay time scale=0.1input 0--8192 tokensoutput override=128 tokensmax 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 个搜索 probes92 个实测 anchors共 27,583 个 request observations
simulator workload 对每个 real anchor 重放同一冻结 request cohort 的 token length、arrival、request count 与 prefix block identitiesold 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 BQwen3-235B-A22B-FP8 prefill-only

项目 设置
真机 dash08×NVIDIA H2097,871 MiB/GPU全互联 NV18driver 580.95.05
model Qwen/Qwen3-235B-A22B-FP8block-wise FP8 weightsBF16 KV cache
serving runtime community vLLM 0.10.2Python 3.12.3、torch 2.8.0+cu128、FlashInfer 0.3.1.post1、Transformers 4.55.2eager 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=2026071501input p50=1478、p95=18,439、max=29,385、mean=3511.55 tokensoutput 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 offTP8 为 EP on
serving controls prefix cache/speculative decoding offchunked 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 capacityTP4=26,101TP8=62,351。Frontier refined outputs 在真机 v2/v3 ranking 运行前冻结,没有使用本 case 的 serving capacity 做 end-to-end calibration

该 case 是有意设计的 prefill mechanism-isolation workloadoutput 固定为 1prefix 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_lengthoutput_length、session parent/turn 和 block-size=64 的 hash_ids。只读审计得到:

属性 数值
natural offered rate 25.798 req/s
input tokens mean=3,660.0p50=1,491p95=19,610.6p99=29,944.6max=51,827
output tokens mean=3,924.6p50=3,435p95=8,945.1p99=17,705.5max=74,867
total context mean=7,584.6p50=5,317p95=25,102.1p99=37,110.5max=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 keyFrontier 消费等价 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 requests99.50%)。排除后 input/output/total 的均值分别为 3,575.0/3,823.3/7,398.2 tokensp95 分别为 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.000exact sign=37.88% 25.63% 排序错误
Qwen30 mixed / vLLM 0.20 profile-only 12 TP2,MNS32 全部 12 configs 不可辨识 τ-b=0.000exact sign=7.58% 60.91% 同栈 raw profile 仍不足
Qwen30 mixed / frozen per-TP calibration 12 TP2,MNS32 TP2,MNS32/64 hit非 exact τ-b=0.9668exact sign=93.94% 0.76% dash0
Qwen235 FP8 prefill / best-effort 8 TP4,MBT16K,MNS64/128 与 real 完全相同 exact match ρ=0.9487non-tied 20/20 0 足以选最优 config
Qwen235 FP8 fixed-shape mixed / frozen full profile 8 四个 TP4 configs 与 real 完全相同 exact match τ-b=0.8944exact sign=24/28real non-tie=16/20 0 选对 topology漏掉 TP8 MNS×MBT interaction

最重要的区别是Qwen30 的 high-fidelity 结果依赖 per-TP E2E calibrationQwen235 的 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

图中 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 为 12.4417/3.2833=25.63%
  • Calibrated Frontier 把 TP2/MNS32 和 TP2/MNS64 判为并列。前者是真机唯一最优,后者低 0.025 req/s/GPU;因此 optimistic regret=0worst 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-infeasibleaggregate 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 rows30 个 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

完整 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 labelsagree / 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.3940non-tied pair concordance=70.49%。这只是 failure diagnosis不能替代本文定义的 SLO-feasible capacity objective。两路 CPU shard 都是 46/46 PASS合计 simulator runtime 为 2,394.9 s0.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 graph224 个 pure-prefill steps 中 192 个为 NONE、30 个 PIECEWISE、仅 2 个 FULL9,466 个 true-mixed steps 中 8,623 个为 NONE、842 个 PIECEWISE、仅 1 个 FULL。本轮 isolated profiles 则关闭 CUDA graphFrontier 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 callFrontier 必须分别得到 attn_prefillattn_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.107median max/mean expert load 为 6.12/5.64Frontier 固定的 per-layer Uniform prior 分别只有 0.4851.84。实际与 Frontier expert allocation 的逐层 Pearson median 接近 0prefill -0.017、decode -0.024),而 Frontier 在所有 phase 复用相同 allocationprefill/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 msMoE grouped GEMM 为 3.76×、RoPE 7.39×、attention prefill 2.67×。这说明版本更新没有产生一个小而一致的 correction不同 components 的误差方向和幅度不同,随后又通过 scheduler queue、batch composition、graph mode 与 routing 反馈到下一个 state。

因此本实验否证 H1Frontier 原生支持按 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 shapeMNS 改变 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

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 都不 binding150 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 msp95 TTFT 为 295.8--305.5 ms。只有这个通过 gate 的 contract 会进入最终 real capacity/rank。

完整评测 setup

项目 设置
真机 dash08×NVIDIA H2097,871 MiB/GPU、driver 580.95.05、NV18TP4 cells 各独占 4 GPUTP8 cells 独占全部 8 GPU
model/runtime Qwen/Qwen3-235B-A22B-FP8community vLLM 0.10.2、Python 3.12.3、torch 2.8.0+cu128、FlashInfer 0.3.1.post1eager、FP8 weights、BF16 KV
workload 64 个不同 token 的固定长度 requestsISL=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 offTP8 为 EP on
simulator Frontier commit d9cfeb6d8791fbf2f295dd9744c56a666171776e + frozen best-effort patches1,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/s64/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

TP MNS MBT Real Frontier Real boundarypass → 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/GPUboundary 的 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.894428 个 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/GPUdifference-in-differences 为 +0.20 req/s/GPU。也就是说,MBT 的作用方向取决于 MNS它们不能被看成两个独立、可加的 controls。 Frontier 对四个 TP8 cells 都预测 0.15interaction 恰好为 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 隐藏成预注册结论。

尚不能纳入 simulator ranking 的 case

原 internal-runtime Qwen235 prefill-only

原实验有 8/8 valid real cells但使用不同的 serving/runtime contractreal 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 graphsFrontier 当前没有等价的 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 contractrequest 到达时分配与 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 建议使用同一 gateworst selected-config regret ≤5%、tie-aware rank correlation ≥0.8、足够数量的 informative pairs、ground-truth bracket 不足以反转最优决策,并单独报告达到该结果所需的 real-GPU profiling/calibration cost。

数据与复现

重新生成 PNG/SVG

python3 scripts/plot_simulator_fidelity.py