Files
aituner/docs/simulator-fidelity-frontier-20260711.md
2026-07-13 11:06:11 +08:00

135 lines
8.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Simulator-based tuning 保真度实验总结Frontier / H20— 供 review
日期2026-07-11。目的判断现有实验数据是否**严格**支撑"simulator-based
tuning 会导致错误的 rank 排序和最终性能 gap"这一论文主张。全部原始材料在
`~/phd/replayserve`(见文末指针);本文只做总结,不新增任何数字。
## 一句话结论
在给足模拟器一切有利条件(同模型同硬件的 H20 算子 profile、逐 token 精确的
真实 workload、在独立数据上冻结的逐 TP 吞吐校准之后Frontier 在预注册判定
规则下仍未通过:在真实调优器实测过的 12-cell TP×MNS 面上,模拟器选出的配置
比真实最优差 **30.46%**top-1 real-evaluated regret关键交互关系只复现
3/6。**若按模拟器结果部署,你会选 TP1/MNS64真实 2.283 req/s/GPU放弃
TP2/MNS32真实 3.283)——这就是"最终 gap"的操作性含义。**
## 实验设置(三个不可辩驳性设计)
- **Ground truth 是真实调优研究本身**C1 交互研究dash1 恢复的 store
vLLM 0.20.0H20`chat_w20260311_1000` 窗口scale 0.112 个
TP{1,2,4}×MNS{8,16,32,64} cell 的 SLO-feasible peakpass≥0.95,阶梯
TTFT 2/4/6sTPOT 50ms。每个数字从原始 state.json/engine.log 独立复算。
- **EXACT workload**materialized JSONL32,606 行,含真实 prompt 文本)
逐 token 重建——tokenize 后逐行断言等于 `input_length`17,710/17,710 全
chat 模板开销恒为 +8 token 并分解到具体 token IDblock-16 前缀 hash
按 vLLM 0.20.0 的 `hash_block_tokens` 源码vendored、逐字节比对计算。
每个 cell 用它自己实测过的锚点92 个锚点,选中请求数 92/92 与真实记录
相等),不插值、不补网格。
- **预注册**:判定规则在任何模拟跑之前冻结于
`replayserve/docs/simfid_s2r_protocol.md` §6——(1) 最坏 top-1 regret ≤5%
(2) TP4/MNS16 陷阱 6 条关系全复现;(3) 92 次留一锚点复检全过。四种读法中
只有"冻结校准 + 吞吐代理"承载结论,其余为诊断。校准系数
a_tp = {TP1: 0.7235, TP2: 0.4681, TP4: 0.3521} 来自独立的 3 配置切片
S2-ES2-R 数据上不重拟合。
执行184 次 Frontier CPU run92 锚点 × 未校准/校准184/184 通过、
0 失败sanity 无红旗。
## 核心证据12-cell 分数表req/s/GPU
| Cell | 真实 SLO peak | 校准后 sim 吞吐 | 校准后 sim SLO |
|---|---:|---:|---:|
| tp1_mns8 | 2.100 | 2.173 | 1.717 |
| tp1_mns16 | 2.350 | 3.242 | 2.383 |
| tp1_mns32 | 2.283 | 4.297 | 2.383 |
| tp1_mns64 | 2.283 | **4.357** ← sim 判为全局最优 | 2.383 |
| tp2_mns8 | 2.275 | 2.039 | 1.742 |
| tp2_mns16 | 2.275 | 2.244 | 2.300 |
| tp2_mns32 | **3.283** ← 真实全局最优 | 3.650 | 3.750 |
| tp2_mns64 | 3.258 | 3.650 | 3.750 |
| tp4_mns8 | 1.283 | 1.545 | 1.321 |
| tp4_mns16 | 2.442 | 2.437 | 2.500 |
| tp4_mns32 | 2.442 | 2.462 | 2.500 |
| tp4_mns64 | 2.442 | 2.462 | 2.500 |
**失败机理**(不是尺度错,是形状错):真实 TP1 在 MNS16 后随 SLO 边界饱和
2.35→2.28sim 认为吞吐随 MNS 单调上升3.24→4.30→4.36)。逐 TP 校准
已消掉尺度误差,负载响应形状仍然错——来源是排队/尾延迟/调度开销,不是算子
时间表。佐证sim TTFT p95 仅为真实的 0.300.38TPOT p95 0.630.79
S2-E 持出集)。
排序质量:校准吞吐读法 τ-b = 0.448(未校准 0.236),成对方向正确率
6873%。远低于可用水平。
## 什么已被严格证明(本文主张的边界内)
1. **在被测面上simulator-only 的吞吐排序会给出 30.46% 的真实 gap**——
端到端、预注册、workload 逐 token 精确、同硬件 profile、校准冻结。链条
里没有"我们没给模拟器机会"的空隙。
2. **未做延迟校准的模拟器做 SLO 判断不可信**S2-E 直接反例sim TPOT p95
46.43ms vs 真实 71.38ms,横跨 50ms SLO → sim 判可行、真实不可行);
S2-R-b 校准 SLO 读法在 92 锚点上有 21 假可行 / 7 假不可行。
3. **覆盖缺口独立于精度成立**MoE EP>1 无 profile 支持、GMU 惰性、
CUDA-graph 未接、scheduler-delay 不可表达——这些 knob 模拟器根本无法
评估replayserve/docs/simfid_inventory.md 旋钮矩阵)。
## 什么还没被严格证明review 时请重点判断这三条)
1. **跨引擎版本 profile**最大攻击面H20 profile 来自 vLLM 0.11.1 时代
的对齐工作ground truth 是 0.20.0。防守方可以说"按 0.20.0 重新 profile
就好了"。我们的回应有二:(a) 冻结校准已吸收逐 TP 尺度误差,剩余的是形状
误差,其来源(排队/调度/CUDA-graph不在算子表里(b) 反身性论证——若
每个引擎版本 × 硬件都要重 profile + 重校准profiling 本身占用同款 GPU
跑真实负载模拟器的成本优势即被churn吃掉。但 (a) 目前是机理论证 +
间接证据,不是实验闭环。
2. **SLO 门控读法的意外成功**:校准 + SLO 门控(预注册为仅诊断)达到
regret 00.76%、τ-b 0.967、陷阱 6/6。审稿人可主张"你选错了读法"。
我们的回应该读法建立在错误的逐锚点判定上21 假可行/7 假不可行),
正确性来自误差在逐 cell 峰值处的部分抵消,无法保证泛化;且它是事后
观察,预注册规则不允许换读法。**但要诚实:这条把可主张的结论从
"模拟器必然错排"弱化为"模拟器排序不可信、必须真实验证"。**
3. **单面、单模型、单硬件、单 workload 窗口**:无跨 workload 复制。且论文
审稿人点名的多半是 Vidur我们测的是 Frontier同类算子 profile +
事件驱动调度模拟;需论证类代表性或列为 limitation
## 建议的论文主张口径(可辩护版本)
> 不主张"simulator 总是错排",主张:在我们的真实调优器必须绕开局部陷阱的
> 那个交互面上,一个被给足条件的模拟器(同硬件 profile + 吞吐校准 + 精确
> workload在其预注册的最优读法下产生 30% 的部署 gap且其 SLO 判定在
> 无延迟校准时存在跨边界的假可行;因此 simulator-only tuning 的结果不经
> 真实评估不可信——而真实评估的成本控制正是 AITuner 的贡献。混合设计
> (模拟器粗筛 + 真实终判)是被我们的诊断数据支持的未来方向,且"何时必须
> 真实评估"仍由相似度度量回答。
## 可选补强(按闭环价值排序)
1. **负载响应形状分析**(零新模拟,复用 184 run + 真实 probe history
逐 cell 对比归一化吞吐/延迟-锚点曲线。若形状系统性不匹配,则证明任意
逐配置尺度校准(= 任意精度的算子 profile原理上无法恢复排序直接
封死上面第 1 条攻击面的一半。
2. **vLLM 0.20.0 重 profile**(需 GPU 时间 + 审批):实验性封死跨版本
质疑,但注意这同时演示了 churn 成本,输赢都有叙事价值。
3. **第二个 workload 窗口**(如 coder 或 2200 slot复制性。
## 数据 sanity block
- 12-cell 真实向量n=12min/max=1.283/3.2838 个 distinct 值。
- 校准 sim 吞吐向量n=12min/max=1.545/4.35710 个 distinct。
- 执行n=184失败 0请求数 min/max=66/60034 distinct
- regret=30.456853% 由 12.2833/3.2833 独立复算精确一致a_tp 三值与
S2-E 冻结清单一致;所有比率在 [0,1];无逐配置全同向量。
- 已知异常(保留未修饰):真实 TP2/MNS32 与 MNS64 的 pass-rate 非单调,
但 0.95 可行性截断有序。
## 材料指针(全部在 ~/phd/replayserve
- 最终综合报告:`docs/simfid_s3_fidelity_report.md`
- 12-cell 结果与全部指标:`docs/simfid_s2rb_results.md`
`runs/simfid_s2rb/results/metrics.json`
- 预注册协议 + 修正案:`docs/simfid_s2r_protocol.md`
- 吞吐校准与延迟反例:`docs/simfid_s2e_report.md`
- 数据清单与旋钮覆盖矩阵:`docs/simfid_inventory.md`
- 全程决策/验收台账:`docs/simfid_campaign_state.md`
- 恢复的 EXACT workload`~/phd/aituner/trace_windows/traces/chat_w20260311_1000.jsonl`