aituner/docs/tuning-core-challenges-cost-audit-20260715.md

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：

T = {model, engine build, hardware, workload/trace, SLO, legal config space C}

每个完整配置 c in C 的目标为：

f_T(c) = max request_rate_per_gpu
         subject to request SLO pass rate >= target

有限空间 oracle 为：

f*_T = max_{c in C} f_T(c)
regret(c) = 1 - f_T(c) / f*_T

顺序 tuner 在第 t 步基于历史 D_t 选择一个完整 config intervention：

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 应定义为：

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 成本单独报告：

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 的首末时间戳重建：

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 的

问题本质

一般情况下：

f(c) != base + sum_k effect_k(c_k)

一个 knob 的 effect 是当前完整 context 的函数：

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 只能告诉我们：

P(engine trajectory | current config, workload)

Tuning 真正需要的是：

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

每条学习记录为：

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}

学习：

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 上选择：

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：

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。