392 lines
23 KiB
Markdown
392 lines
23 KiB
Markdown
# AITuner tuning：核心挑战、统一成本口径与研究路线
|
||
|
||
日期：2026-07-15（Asia/Singapore）
|
||
|
||
状态：**问题定义与历史成本审计完成；新的 tuner 贡献尚未建立。**
|
||
|
||
## 结论先行
|
||
|
||
我们不应该把 tuning 定义成“根据当前 telemetry 判断哪个 cap 满了，再调对应 knob”。这个定义同时遗漏了 knob interaction、反事实识别、实验成本和跨任务失配。更准确的问题是：
|
||
|
||
> 给定模型、engine version、hardware、workload、SLO 和一个声明好的合法配置空间，tuner 如何用最少的真实 GPU 成本，依次选择可能包含多个 knob 的 intervention，找到 SLO-goodput regret 不超过 `epsilon` 的配置？
|
||
|
||
AITuner 可以形成的系统贡献应当是：
|
||
|
||
> **一个 intervention-calibrated、action-conditioned、cost-aware 的 tuner：它从真实 engine trajectory 和已测 intervention 中学习联合 config action 的反事实收益分布，并以 cost-to-oracle 而非规则命中率作为目标。Harness 只负责实验语义、合法性、配对、记账和可复现性，不负责用人工 bottleneck rule 决定 action。**
|
||
|
||
现有结果支持这个问题值得做，但不支持宣称它已经解决：
|
||
|
||
- 在真实 `TP x MNS` surface 上，one-knob-at-a-time 会停在比 oracle 低 **25.6%** 的 coordinate-wise local optimum。
|
||
- 在 action-aware pilot 中，增加 MBBT 在“几乎从未独占打满 MBBT cap”的情况下仍把 source goodput 提高 **48.0%--77.1%**；因此 `cap -> knob` 不是完整模型。
|
||
- 同一 dash0 任务上，当前 guided harness 到 5% empirical regret 只比纯 LLM 少 **5.85%** H20-hours；到 2% regret 则少 **61.09%**。这说明必须比较完整 cost--regret curve，不能只比较最终最好值。
|
||
- Frontier 的 decision-bearing throughput top-1 在 12-cell surface 上有 **30.46%** real regret。Simulator 本身的边际 GPU cost 是 0，但通过 real-final 恢复 oracle 需要 tie-expanded 4 个真实 cell，即 **0.7828 reconstructed H20-hours**。
|
||
|
||
## 1. Tuning 问题和成功标准
|
||
|
||
固定 task context：
|
||
|
||
```text
|
||
T = {model, engine build, hardware, workload/trace, SLO, legal config space C}
|
||
```
|
||
|
||
每个完整配置 `c in C` 的目标为：
|
||
|
||
```text
|
||
f_T(c) = max request_rate_per_gpu
|
||
subject to request SLO pass rate >= target
|
||
```
|
||
|
||
有限空间 oracle 为：
|
||
|
||
```text
|
||
f*_T = max_{c in C} f_T(c)
|
||
regret(c) = 1 - f_T(c) / f*_T
|
||
```
|
||
|
||
顺序 tuner 在第 `t` 步基于历史 `D_t` 选择一个完整 config intervention：
|
||
|
||
```text
|
||
a_t = c_t -> c_{t+1}
|
||
```
|
||
|
||
成功不是“最后找到一个不错的值”，而是同时满足：
|
||
|
||
1. `regret(best_t) <= epsilon`；
|
||
2. 达到该点之前的 all-in H20-hours 最小；
|
||
3. launch、correctness、SLO 和失败率约束不退化；
|
||
4. 结论在 held-out task 上成立，而不是在用于设计规则的 task 上成立。
|
||
|
||
### 1.1 GPU cost 的统一定义
|
||
|
||
未来实验的 task-marginal cost 应定义为：
|
||
|
||
```text
|
||
C_task = sum_j allocated_GPU_count_j
|
||
* (GPU_idle_or_release_time_j - allocation_start_time_j)
|
||
```
|
||
|
||
它包括 method 实际触发的 startup、warm-up、prefix/full replay、confirmation、failure、cleanup；如果 LLM 思考期间 GPU 仍被占用，也计入。Simulator/模型的一次性 onboarding 成本单独报告：
|
||
|
||
```text
|
||
C_e2e(N tasks) = C_profile_or_training / N + C_task
|
||
```
|
||
|
||
另外报告 CPU-hours、LLM API latency/cost，但不把它们伪装成 GPU-hours。构建 benchmark oracle 的 exhaustive annotation cost 是公共评测成本，单独报告，不计入任何方法；同时可给一个将其等量加回所有方法的 conservative view。
|
||
|
||
历史记录没有 allocation start/release timestamp。本次只能从每个 `engine.log` 的首末时间戳重建：
|
||
|
||
```text
|
||
C_engine_lower_bound = parallel_size * engine_log_span / 3600
|
||
```
|
||
|
||
因此下面所有历史 H20-hour 数字都是 **engine-lifetime lower bound**，不是 all-in cost。尤其 simulator 的一次性 H20 operator profiling 成本没有记录，不能称为完全免费。
|
||
|
||
### 1.2 两种 oracle 必须分开
|
||
|
||
- **Exact finite-surface oracle**：声明好的 12-cell `TP x MNS` 空间全部真实测量，oracle 是 `TP2/MNS32 = 3.2833 req/s/GPU`。
|
||
- **Broader empirical reference**：dash0 两个 sequential run 中观察到的最好值 `3.35 req/s/GPU`。它包含 surface 外的 MBBT/chunk/GMU action，但只是 best observed，不是全局 oracle。
|
||
|
||
不能把 empirical best 写成 global oracle，也不能让每个方法使用不同的 oracle 定义。
|
||
|
||
## 2. 现有方案的 cost-to-oracle 审计
|
||
|
||
可复算输入和完整结果在：
|
||
|
||
- `runs/tuning-cost/manifest.json`
|
||
- `runs/tuning-cost/analyze.py`
|
||
- `runs/tuning-cost/metrics.json`
|
||
|
||
### 2.1 严格同任务对照：纯 LLM vs 当前 guided harness
|
||
|
||
两组均为 dash0、Qwen3-30B-A3B、community-vLLM 0.20.0、8xH20 可见、`chat_w20260311_1000`、input 0--8k、output 128、replay scale 0.1、TTFT 2/4/6s、TPOT 50ms、pass rate 0.95。除 tuner method 和服务端口外，固定 task spec 相同。
|
||
|
||
Reference 是两组中 best observed `3.35 req/s/GPU`：
|
||
|
||
| Method | 到 <=5% regret | 到 <=2% regret | 到 <=1% regret | 完整 run 成本 | 最终 best |
|
||
|---|---:|---:|---:|---:|---:|
|
||
| Pure LLM, no harness | 0.2847 H20h，trial 2，regret 2.736% | 1.1458，trial 6，regret 1.493% | 1.3719，trial 7，regret 0% | 2.2825 | 3.35 |
|
||
| Guided harness v2 | 0.2681 H20h，trial 2，regret 2.736% | 0.4458，trial 3，regret 1.990% | 未达到 | 0.6231 | 3.30，regret 1.493% |
|
||
|
||
直接结论：
|
||
|
||
- 5% endpoint：guided 比 pure LLM 少 **5.85%**，不是 material contribution。
|
||
- 2% endpoint：guided 比 pure LLM 少 **61.09%**，有明显 headroom signal，但只有一个 task，不能外推。
|
||
- Pure LLM 在 trial 7 已找到 best observed，之后又花了 `2.2825 - 1.3719 = 0.9106 H20h` 而没有改进，说明 trustworthy stopping 本身就是成本来源。
|
||
- Pure LLM 的 trial 3 使用当前 binary 不支持的 `--expert-parallel-size` 并在 launch 前失败。当前 harness 的 legality/version contract 有实际价值，但它仍不是性能 action-ranking 贡献。
|
||
|
||
### 2.2 Simulator：零边际 GPU cost 不等于零 tuning cost
|
||
|
||
Frontier fidelity suite 在 CPU 上执行 184 个 simulation，耗时 **2.055 CPU-hours**，simulation 本身为 0 marginal H20-hours。其对应的 exact dash1 12-cell real surface annotation lower bound 为 **3.5953 H20-hours**。
|
||
|
||
Decision-bearing `frozen-calibrated/throughput-proxy`：
|
||
|
||
| Policy | Real cells evaluated | Real-final H20h lower bound | Selected real regret |
|
||
|---|---:|---:|---:|
|
||
| Simulator-only top-1 | 0 | 0 | **30.46%**，选 TP1/MNS64 |
|
||
| Throughput top-1 + real final | 1 | 0.1353 | **30.46%** |
|
||
| Throughput top-2 + real final | 2 | 0.2672 | **30.46%** |
|
||
| Throughput nominal top-3 + real final | tie-expanded 4 | 0.7828 | 0%，找到 TP2/MNS32 |
|
||
|
||
Post-hoc `SLO-gated` reading 把 `{TP2/MNS32, TP2/MNS64}` 放在 top tie bucket；测两个 cell 需 **0.5156 H20h** 并能找到 oracle。但它不是 preregistered decision-bearing policy，而且 anchor verdict 中有 21 个 false-feasible、7 个 false-infeasible，只能作为诊断上界，不能反写成 prospective simulator 结果。
|
||
|
||
Pure LLM/harness 数据来自 dash0，simulator exact surface 来自 dash1。模型、engine、trace、GPU type 匹配，但 host 和 campaign 不同。因此两块内部可以直接比较，跨块只能做 development-level 指示；paper 结论必须在同 host、同 task execution protocol 下重跑。
|
||
|
||
### 2.3 我们要达到的成本目标
|
||
|
||
在当前 reconstructed lower-bound 口径下，一个有意义的单任务 development bar 是：
|
||
|
||
| Endpoint | 当前最强同任务 baseline | 20% reduction bar | 兼顾 post-hoc sim+real 的 30% bar | 暂定目标 |
|
||
|---|---:|---:|---:|---:|
|
||
| <=5% empirical regret | guided 0.2681 | 0.2144 | 0.3609 | **<=0.2144 H20h** |
|
||
| <=2% empirical regret | guided 0.4458 | 0.3567 | 0.3609 | **<=0.3567 H20h** |
|
||
|
||
这两个数字不是 paper result，只用于检查 proposed method 是否有足够 headroom：
|
||
|
||
- 5% endpoint 已经由 baseline + TP2 两个完整 trial 达到。任何必须先跑 source 再跑 target 的 telemetry tuner 都不能靠减少 trial count 获得 20% 优势；它必须能够 one-shot warm-start、跳过 baseline，或安全地缩短其中一次测量。
|
||
- 2% endpoint 有更合理的结构性空间：从一个 source 直接选择 joint `TP2 + MBBT/chunk` target，可能跳过当前中间 trial；如果仍按当前三次完整 trial 顺序执行，就不会达到 bar。
|
||
|
||
Paper-facing gate 不使用这些跨 campaign 绝对数，而使用 prospective same-host all-in cost：在每个 held-out task 上 regret <=5%，相对最强 safe outcome-only/current harness 至少省 20%，相对 frozen simulator+real 至少省 30%，并报告 task-level paired confidence interval。
|
||
|
||
## 3. 四个最核心的 tuning challenge
|
||
|
||
### Challenge 1：响应面是联合、条件化且 regime-dependent 的
|
||
|
||
#### 问题本质
|
||
|
||
一般情况下：
|
||
|
||
```text
|
||
f(c) != base + sum_k effect_k(c_k)
|
||
```
|
||
|
||
一个 knob 的 effect 是当前完整 context 的函数：
|
||
|
||
```text
|
||
Delta_x(c, workload, engine state)
|
||
```
|
||
|
||
它可能随 topology、另一个 runtime knob、load、SLO 或 engine version 改变大小甚至改变符号。因此不能先分别求每个 knob 的最优值再 merge，也不能固定一个低质量 context 去判断另一个 knob。
|
||
|
||
#### 已有真实证据
|
||
|
||
在 C1 12-cell real surface：
|
||
|
||
- `MNS 8 -> 32` 在 TP1/TP2/TP4 下分别提升约 **8.7% / 44.3% / 90.3%**。
|
||
- 从同一 `TP1/MNS8` 起点，先 tune MNS 再 TP 会停在 `TP4/MNS16 = 2.4417`；该点沿任一单维都没有 strictly improving move，但 joint/global surface oracle `TP2/MNS32 = 3.2833` 高 **34.5% relative to the local point**，即 local point 对 oracle 有 **25.6% regret**。
|
||
- C3 中 `MBT 256 -> 384` 的 effect 根据 topology/MNS 从 0 到约 -9.2%；`MNS 64 -> 128` 从 0 到约 +10.1%。
|
||
- Action-aware Regime A 中 MBBT 几乎从不作为 exclusive cap，但 MBBT action 仍把 source goodput 提高 48.0%--77.1%。它通过 chunk size、prefill packing 和 scarce MNS slot residency 的联合变化获得收益。
|
||
|
||
这直接否定两类通用策略：OAT/coordinate greedy，以及 `which cap is full -> tune that knob`。
|
||
|
||
#### Tuner 必须具备的能力
|
||
|
||
- Action 的基本单位是完整 `config delta`，允许 sparse joint action，而不是孤立 knob/value。
|
||
- 对 topology/runtime family 使用 crossed anchors 或信息增益设计，主动测 interaction；不是默认所有 interaction 都强。
|
||
- 能从数据判断 task 是 topology-dominant、runtime-interaction-dominant 还是 flat/noisy，并据此分配实验，而不是把固定 search order 写进规则。
|
||
|
||
### Challenge 2：当前状态是 observational signal，tuning 需要 counterfactual identification
|
||
|
||
#### 问题本质
|
||
|
||
一次 telemetry trace 只能告诉我们：
|
||
|
||
```text
|
||
P(engine trajectory | current config, workload)
|
||
```
|
||
|
||
Tuning 真正需要的是：
|
||
|
||
```text
|
||
P(Delta SLO-goodput, failure, cost
|
||
| source trajectory, proposed full-config action)
|
||
```
|
||
|
||
Queue、KV、padding、split prefill 等状态既可能是原因，也可能是 workload/config 的结果。看见某种状态，不等于知道哪个 action 能修复它。一个 action 也可能同时改变多条机制；例如 MBBT 同时改变总 token budget、per-request chunk 和 multi-request packing，现有 telemetry 的解释是 mechanism-consistent，不是已完成的 causal decomposition。
|
||
|
||
#### 已有真实证据
|
||
|
||
- 5/10 秒 telemetry 确实太短；300 秒 phase-aware experiment 中，MNS action 的 queue/padding 机制直到 replay 75%--100% 才稳定出现。
|
||
- 但 external TTFT outcome 在 25% 已完美区分该 action 是否修复 SLO。Telemetry 解释了 why，却没有比 outcome 更早或更可靠地指导 tuning。
|
||
- 3.125 req/s/GPU 的 source 无法在 timeout 内 drain；另一组 source 已达 offered ceiling 的 99.1%--100%，数学上不可能通过 10% improvement gate。没有 exposure/headroom 和 censoring control，模型学到的不是 action response。
|
||
- Same-config repeats 与 matched intervention 的波动不可忽略；只比较两个未经配对的 run 会混入 arrival/order/warm-state noise。
|
||
|
||
#### Tuner 必须具备的能力
|
||
|
||
- 训练样本必须是 exact-workload paired intervention：`(source trajectory, action) -> target delta`，保留失败和 censoring。
|
||
- 使用 phase-binned continuous trajectory，而不是人工 bottleneck label 或 threshold rule。
|
||
- 输出 response distribution 和 uncertainty；证据不足时 abstain，而不是强行给 diagnosis。
|
||
- Telemetry 的价值必须通过同 cutoff、同 model capacity 的 outcome-only ablation 证明。若不能降低 end-to-end H20-hours，instrumentation 只保留为 debugging/解释工具。
|
||
|
||
### Challenge 3：这是异构成本下的 sequential experimental design，不是静态 ranking
|
||
|
||
#### 问题本质
|
||
|
||
每个 trial 的成本不同：TP4 是 TP1 的四倍 GPU multiplier，startup/warm-up 可能主导短 probe，失败也有成本；同时 tuner 不知道 oracle，只能在 exploitation、information gain 和 cost 之间权衡。选对 top-1 的 accuracy 不能代表 tuning 效果。
|
||
|
||
必须回答三个连续问题：
|
||
|
||
1. 下一次测哪个联合 action？
|
||
2. 测多久，何时 continuation/confirmation？
|
||
3. 什么证据允许停止，并声称 best 已在 `epsilon` 内？
|
||
|
||
#### 已有真实证据
|
||
|
||
- Pure LLM 达到 best observed 后仍浪费 0.9106 reconstructed H20h。
|
||
- Simulator top-1 虽然 0 marginal GPUh，却因 rank error 损失 30.46%；real-final 的 k 增大又迅速增加 H20h。
|
||
- 5% endpoint 上两个方法都只需两个 trial，selection-count headroom 很小；2% endpoint 才暴露 action quality 和 stopping 的巨大差异。
|
||
- Prefix 不是天然便宜：如果 startup、warm-up 和稳定状态形成占主要成本，缩短 replay window 未必带来等比例 H20h reduction。
|
||
|
||
#### Tuner 必须具备的能力
|
||
|
||
- Acquisition 直接优化 expected regret reduction / predicted H20 cost，并把 failure probability 纳入约束。
|
||
- 在 run 前做与 tuning policy 分离的 workload admissibility check：避免 outcome ceiling、无法 drain、无请求或 measurement cap。
|
||
- 使用 uncertainty-aware continuation 和 stop；stop criterion 针对声明的 candidate set 中“仍存在 >epsilon improvement 的概率”，而不是连续几次没提升。
|
||
- 主结果报告 H20-hours-to-5%/2%/1%、fixed-budget regret 和 cost-normalized regret AUC，不 metric shopping。
|
||
|
||
### Challenge 4：任何 mechanism model 都有 fidelity 和 transfer boundary
|
||
|
||
#### 问题本质
|
||
|
||
Simulator、learned surrogate、LLM prior 都是近似。Workload、SLO、model、hardware、engine version 改变后，operator cost、scheduler state transition、合法 flag 和 response surface 都可能变化。模型在 calibration task 上解释得好，不表示能在 held-out task 上排序正确。
|
||
|
||
#### 已有真实证据
|
||
|
||
- Frontier throughput reading 在完全匹配的 12-cell task 上仍把 real oracle 排错，top-1 regret 30.46%。这说明预测绝对 throughput 还不够，局部 rank fidelity 才是 tuning 关键。
|
||
- Post-hoc SLO reading 的 top bucket 正确，但有大量 anchor feasibility error，也没有 prospective policy status。
|
||
- Pure LLM 提出了当前 community-vLLM binary 不支持的 flag；engine/API version knowledge 本身会漂移。
|
||
- 已有 cross-version experiment 中 vLLM 0.20 的强配置在 0.24 上出现大幅退化，说明 response prior 不能无条件迁移。
|
||
|
||
#### Tuner 必须具备的能力
|
||
|
||
- Simulator 只能作为 prior mean 或 candidate prior；真实 outcome 是 authoritative update。
|
||
- 学习 simulator residual：把 `sim prediction + source state + action` 映射到 real response，而不是用 telemetry 重新实现另一个无校准 simulator。
|
||
- 对 task-level OOD 显式提高 uncertainty/abstain；train/test 按完整 task 分割，不能按 request、anchor 或同一 surface cell 随机分割。
|
||
- 分开报告 cold-start profile/training cost 与 per-task marginal cost，并在 N=1/10/100 等 amortization horizon 下展示。
|
||
|
||
## 4. 对应的系统设计
|
||
|
||
### 4.1 Harness：从 rule-based tuner 收缩成 experimental control plane
|
||
|
||
Harness 保留以下确定性职责：
|
||
|
||
- engine-version-aware config schema、合法性和资源约束；
|
||
- 完整 config/action canonicalization，禁止隐式 merge 和重复试验；
|
||
- exact trace/request/arrival/length hash，配对、随机化和 counter-rotation；
|
||
- engine trajectory、external outcome、failure/censoring 的统一时间轴；
|
||
- all-in GPU cost ledger、oracle annotation 分账、budget enforcement；
|
||
- data sanity、coverage、SLO/correctness 和 stop-proof audit。
|
||
|
||
Harness **不**包含 `queue > N -> increase MNS`、`cap full -> tune knob` 或人工 diagnosis-to-action mapping。这里的规则是实验语义和安全 invariant，不是性能决策 heuristic。
|
||
|
||
### 4.2 Action-conditioned response model
|
||
|
||
每条学习记录为：
|
||
|
||
```text
|
||
x = {source full config,
|
||
workload/SLO context,
|
||
source external outcome,
|
||
phase-binned engine trajectory}
|
||
a = normalized full-config delta
|
||
y = {Delta SLO-goodput, target feasibility/failure, measured H20 cost}
|
||
```
|
||
|
||
学习：
|
||
|
||
```text
|
||
p_theta(y | x, a, optional simulator prediction)
|
||
```
|
||
|
||
第一版应使用适合小数据且有 uncertainty 的 action-conditioned Gaussian-process/bootstrapped surrogate；kernel/feature ablation包括：
|
||
|
||
1. config + external outcome；
|
||
2. 同样输入 + telemetry trajectory；
|
||
3. simulator + config + outcome；
|
||
4. 同样输入 + telemetry residual features。
|
||
|
||
Telemetry 保留 continuous phase distributions：queue/running residency、MNS/token slack、prefill/decode composition、partial/split prefill、step duration、KV、graph/padding。模型学习它们与 action 的 interaction；不先压成 bottleneck label。
|
||
|
||
### 4.3 Cost-aware policy
|
||
|
||
在合法的 single/joint candidate set 上选择：
|
||
|
||
```text
|
||
a* = argmax_a
|
||
expected constrained improvement(a)
|
||
/ expected all-in H20 cost(a)
|
||
```
|
||
|
||
探索项来自 posterior uncertainty/information gain；launch/SLO failure 有显式 penalty。Simulator 可提供 prior mean，但 simulator 与 real discrepancy 会被 posterior residual 更新。一次 target measurement 后更新 response model，并重新计算下一步 action 或停止概率。
|
||
|
||
LLM 在这个 tuning core 中不是 telemetry classifier。它最多作为可移除的 candidate/prior source，提出 schema 内的 sparse joint actions 或检索 engine mechanism；每个 proposal 都由同一个 response model、cost acquisition 和 real validator 评分。只有 `with LLM` 相对 `same tuner without LLM` 在 held-out tasks 上继续降低 cost-to-oracle，才能讨论 LLM 必要性。
|
||
|
||
### 4.4 Stop 条件
|
||
|
||
对一个预先声明的有限 candidate set，满足以下条件才 stop：
|
||
|
||
```text
|
||
P(exists c: f(c) > best_observed / (1 - epsilon) | D_t) < alpha
|
||
```
|
||
|
||
并且 best config 通过独立 confirmation、SLO/correctness gate，remaining candidate 的 cost-aware value of information 低于阈值。停止原因、posterior coverage 和未测区域必须写入 audit。
|
||
|
||
## 5. 下一阶段如何证明，而不是再次构造 heuristic
|
||
|
||
### R0：已有数据 retrospective premise check
|
||
|
||
- 用 C1/C3 response surfaces 检查 joint model 是否能避免 OAT trap。
|
||
- 用 action-aware paired records 比较 outcome-only 与 +telemetry 的 action-delta calibration。
|
||
- 用 SimFid surface 比较 direct model 与 simulator-residual model 的 rank/regret。
|
||
- 所有 feature、kernel、candidate encoding 在 held-out task 结果之前冻结。
|
||
|
||
R0 只能筛选 model family，不能作为 paper result，因为现有 tasks 已参与路线设计。
|
||
|
||
### R1：prospective same-host cost-to-oracle pilot
|
||
|
||
- dash0 8xH20，固定 engine build/model；serialized placement，禁止共置干扰。
|
||
- 至少一个未参与 feature/threshold 选择的新 trace window；选择非 ceiling、可 drain 的 offered load。
|
||
- 声明一个可穷举的小 surface，至少包含 topology/runtime crossed actions，而不是只有一个 MNS ladder。
|
||
- Oracle annotation 与 tuner online actions 分开记账；method 只能看到当时可用的数据。
|
||
- 运行 random/search、OAT、纯 LLM、当前 guided harness、frozen simulator+real、outcome-only response、+telemetry response、sim-residual +telemetry。
|
||
- 比较完整 H20 cost-to-regret curve，而不是 action classification accuracy。
|
||
|
||
Pilot opening gate：
|
||
|
||
1. telemetry model 相对相同 response model 去掉 telemetry，确实改变至少一个正确的 prospective action ranking；
|
||
2. 最终 regret <=5%，无 false-safe accept；
|
||
3. all-in H20-hours 相对 strongest safe outcome-only 至少下降 20%；
|
||
4. 如果使用 simulator，需相对 frozen simulator+real 至少下降 30%；
|
||
5. instrumentation overhead <=1%，所有成本和失败均计入。
|
||
|
||
若 1--5 任一失败，就不能把 telemetry/harness 写成 tuning contribution；保留其 debugging/measurement 价值即可。
|
||
|
||
### R2：task-held-out replication
|
||
|
||
至少 3 个 workload window x 2 个 SLO regime，按完整 task 做 leave-one-task-out 或固定 train/test split。报告每个 task 的 regret、安全和成本，以及 task-level paired bootstrap CI。只有 R2 通过，才能把单 task 的 61.09% lower-bound saving 升级为项目贡献。
|
||
|
||
## 6. 当前能说与不能说的贡献
|
||
|
||
当前能说：
|
||
|
||
- 我们有真实反例证明 OAT 和 cap-to-knob mapping 不是通用 tuning strategy。
|
||
- Harness 的 legality、exact replay、failure/cost accounting 有必要的实验基础设施价值。
|
||
- 当前 guided sequence 在一个严格同任务比较中显著减少了达到 2% empirical regret 的 reconstructed engine cost。
|
||
- Simulator 的边际计算便宜，但 rank error 会转化成显著 real regret 或更多 real-final 成本。
|
||
|
||
当前不能说：
|
||
|
||
- telemetry 已经对 end-to-end tuning 提供独立增益；现有 direct pilot 对此为 negative。
|
||
- 当前 harness 的 heuristic action ranking 是系统贡献；5% endpoint 只省 5.85%。
|
||
- LLM 是必要组件；尚无同 policy 的 with/without LLM held-out ablation。
|
||
- simulator 总 tuning cost 是 0；profile GPU cost 未审计，real verification 不能忽略。
|
||
- 3.35 是 global oracle，或 dash0 与 dash1 数字是完全 controlled comparison。
|
||
|
||
## Data sanity
|
||
|
||
- Dash0 sequential numeric scores：n=9，min/max `1.1042/3.35`，distinct=7；两组 config outcome 不全相同。
|
||
- Exact surface scores：n=12，min/max `1.2833/3.2833`，distinct=8；12 cells 完整且与 simulator metrics 中的 real scores 一致。
|
||
- Reconstructed trial/cell attempts 包括 4 个无 engine timestamp 的失败：n=32，min/max `0/0.49778 H20h`，distinct=26；所有可重建成本均非负。
|
||
- Sequential regret observations：n=16，min/max `0/0.34328`，distinct=6，全部在 `[0,1]`。
|
||
- Checked invariants：dash0 fixed task contexts 相同（除 method/port）；trial counts 与 manifest 相符；engine log timestamps monotonic；surface cell 唯一且 MBT=8192；simulator 无失败且 predictions 不全相同；scores/results 不全相同；cost 非负；regret bounded。
|
||
- Measurement limitation：primary 12-cell campaign 的 4 个 TP4 pre-ready failure 没有 engine timestamp，随后由 companion campaign 完整重跑；其失败成本在 engine-lifetime reconstruction 中为 0。因此 `3.5953 H20h` 是 completed annotation lower bound，不能作为 all-in annotation cost。这个缺口已显式保留，没有在其上建立 total-cost claim。
|