跳到主要内容

标定 / 验证 / DSE

perf model 写出来 ≠ 可信——三阶段方法论:标定参数、对标实测、用模型搜设计空间

核心要点:

  • 三阶段方法论:标定(把 datasheet 转成可用参数)→ 验证(对标实测识别误差来源)→ DSE(用 perf model 搜设计空间)
  • 标定核心是 $\eta$:GenZ 实测 H100 compute η=60%/mem η=70%,误差 < 6%;Calculon 分段曲线 a100_80g.json avg 3.65% / max 8.87%
  • 验证三要素:口径(TPOT 稀释 stall 让 Groq vs Etalon 差 4×)、配置(cache hit 差异让同 workload 输入 token 差 50%)、稳态(MLPerf Server 600s + 24,576 样本最小要求)
  • 误差分层:模型误差(公式选错)与标定误差(参数估偏)修法不同——AMALI MAPE 127.56% → 23.59% 是修模型误差(instruction cache + throttle)
  • DSE 可用穷举:Calculon 单次仿真 ~1 ms 支持十亿级配置扫描,Vidur-Search 1 小时 CPU = $218K GPU 实测
  • 报告精度声明易误读:SimAI PP 场景 avg error 77.2% vs 同 testbed PrismLLM 0.58%,泛化是最大弱点

名词定义

名词定义
标定(Calibration)从实测或 datasheet 推导 perf model 参数(η、$\alpha$$\beta$)的过程
验证(Validation)用未参与标定的测量数据对照预测,衡量误差
设计空间探索(DSE)给定约束(SLO / TCO)和搜索空间(并行 / batch / 量化),用 perf model 找 Pareto 最优
Data leakage标定集与验证集重叠造成的"假对"
口径预测的指标与测的指标的物理含义对齐(TTFT / TPOT / E2EL 各自定义)
MAPEMean Absolute Percentage Error,均值百分比绝对误差
Stage Importance某阶段延迟变化对端到端延迟的相对贡献
Sobol 指数全局敏感度方差分解指标

本篇范围

perf model 的可信度由三阶段决定:标定参数、对标实测、用模型搜设计。这三步贯穿 02-07 所有篇但首次在本篇集中讲方法论。

包含:

  • 各档 perf model 的标定流程与跨档标定路径
  • 对标三要素 + 误差分层归因 + cross-tool 精度横向
  • 敏感度分析与不确定性传播
  • DSE 框架与典型案例

不包含:

  • 各档具体建模手段——已在 02 / 03 / 04 篇覆盖
  • 多目标 / 异构维度——见 07 篇
  • workload 输入选择——见 06 篇

第一阶段:标定

把 perf model 公式里的参数($\eta$$\alpha$$\beta$、各类效率因子)从抽象量变成可用数值。各档方法不同。

Analytical 档:η 的实测拟合

GenZ(arXiv 2406.01698)在 8×H100 SXM 上跑 LLaMA2 推理,调整 η 使预测对齐实测,得:

  • compute η = 60%
  • memory bandwidth η = 70%
  • NVLink 链路效率 75%(有效 350 GB/s per GPU)
  • 验证误差 < 6%

GenZ 用单一全局 η,适合定量延迟预测且标定流程简单。

Calculon(SC'23,arXiv 2307.02047)用分段效率曲线 JSON(a100_80g.json),每类资源按传输规模分段:

资源规模 / 配置η
HBM≥ 100 MB0.90
HBM≥ 10 MB0.75
HBM≥ 1 MB0.60
HBM< 1 MB0.30
NVLink固定0.65

@tbl-ipm-v-calculon-eta Calculon 分段效率曲线(A100)

参数来自 A100 Selene 超算上 Megatron 系列实测,avg error 3.65% / max 8.87%。Calculon 与 GenZ 的核心差异:前者分层分段 η,后者单一全局 η——这是粒度选择的工程取舍。

Trace-Replay 档:profiling 工作流

Vidur(arXiv 2405.05465)把算子分三类(token-level / sequence-level / communication),各类用不同 profiling 策略(CUPTI + PyTorch),再训练随机森林对未 profile 的 tensor 维度插值。论文强调 "data frugality" 但未公开训练集确切样本数,端到端误差 < 9%。

vTrain(arXiv 2312.12391)直接用 CUPTI 采集 CUDA kernel trace,构建 operator-to-task lookup table——不训练 ML 模型,查找表直接驱动仿真。这是 vTrain 与 Vidur 在 trace-replay 上的方法差异:Vidur 用 ML 插值新形状,vTrain 只回放已采样形状

Cycle-Approx 档:microarch 参数标定

gem5 标定有两路:

  • RTL co-sim:用 Microarchitecture Cliffs benchmark 精确归因,SPECint 误差降 15.1%
  • gem5Tune:TPE Bayesian 优化自动搜索参数,无需 RTL 参考

SystemC AT 对 DRAM 参数做线性回归,worst-case 误差约 4.5%——这是 cycle-approx 档可达到的工业精度。

跨档标定:Cycle-Approx → Analytical

范式有向图(01 总览)的最关键边——cycle-approx 跑代表性 kernel,经回归把结果喂给 analytical 提升其 $\eta$ 精度。工业实践:

  • CTCF 线性变换:$\alpha$ 修正系数 + $\beta$ 偏移,跨 T4 / A10G / L4 / L40s 验证误差 < 5%
  • LLMCompass mapper:不直接标 η,而是在硬件 mapping 空间搜索最优 tiling(26,400 次扫描),利用率从搜索结果中涌现——端到端误差 4.1%
  • Microbenchmark-driven(arXiv 2605.04178):把每个参数绑定到具体 microbenchmark 测量,B200 MAE 1.31%——这是当前 LLM perf model 报告的最高精度

标定数据稀缺时的退化策略

无目标硬件实测时,可信度递减的四档退化:

  1. 相近架构参数迁移:仅更新数值(同代芯片不同 SKU)
  2. 厂商 datasheet × 经验折扣:compute η 取 0.3-0.5 保守区间
  3. 代理硬件 proxy benchmark:ERT(Empirical Roofline Toolkit)扫 attainable peak
  4. 保守 η 先验 + 显式标注"启发式估算":声明用于相对排序,不做绝对值断言

核心原则:datasheet 阶段的 perf model 输出只承诺相对排序,不承诺绝对值——这一点必须在工具文档和 DSE 报告里显式声明,避免误导决策者。

第二阶段:验证

对标三要素:口径 / 配置 / 稳态

perf model 与实测对不上,九成是这三件事中至少一件没对齐。

口径对齐

预测的指标与测的指标必须物理含义一致。最高发的失效源:

  • TPOT 用均值定义会稀释 scheduling stall——Groq 官宣吞吐与 Etalon fluidity-index 测量值差 4×(arXiv:2407.07000 verbatim)
  • perf model 预测 compute-only latency,不能直接与含 queueing 的 E2EL 对比
  • TTFT vs TBT(Token Between Tokens)vs TPOT 三个指标各自定义,Etalon 论文专门提出 fluidity-index 替代 TPOT

实操:对标前在文档里明确写下预测的指标定义,与对方 benchmark 的指标定义逐字段比对。

配置对齐

任一字段不同就没可比性:

  • 不同工具处理相同 ShareGPT 数据集时输入 token 量差 50%(prefix cache hit 差异)——arXiv:2605.24217
  • 温度参数单独造成 21% 吞吐差异——同一论文
  • 对标前必须 flush KV cache 或锁定 cache hit ratio = 0

稳态对齐

MLPerf Offline 场景规定最少 600 秒 + 24,576 样本——稳态对齐是 MLPerf 规范的核心。同一论文报告:单进程 asyncio 测量工具在 1,000 QPS 下 GIL 造成最多 58 s 延迟膨胀、7.2× 吞吐差距——换工具而非换模型即可消除这部分误差。

实操:启动 warmup 至少 60 s 后开始计量,单进程 asyncio 在高 QPS 下不可信。

Data Leakage 警告

最常见的标定错误:同一组实测数据既用来拟合 η,又用来算验证误差——结论必然好看但无意义。显式切分:

集合用途
标定集算 η,可包含 batch ∈ [1, 16]、seq ∈ [128, 2048]
验证集不参与标定,可包含 batch ∈ [32, 64]、seq ∈ [4096, 8192]
外推集测试泛化,covers 标定集未见过的形状

报告误差时必须说明误差来自哪个集合。论文 cherry-pick 标定集误差等同于过拟合。

误差分层归因

误差分两类,识别信号不同:

误差类型信号修法
模型误差同类算子误差方向固定;换硬件后误差不变改公式(加机制 / 换抽象)
标定误差换硬件后误差显著变化;同硬件不同算子误差方向不同重标 η / 加分段
调度误差单算子误差 < 5%,端到端误差 > 20%修事件驱动 DAG / overlap 假设

@tbl-ipm-v-error-layering 误差三层识别信号与修法

AMALI 案例(ISCA 2025):把 GPU micro-arch 模型 MAPE 从 127.56% 降至 23.59%——差距来自 instruction cache 和 throttle stalls 未建模(模型误差,不是标定误差)。这是典型的"加再多标定也修不好"场景,只能换公式

LLMCompass 案例:端到端误差 4.1% 低于算子误差 10.9%——算子误差互消是标定误差的典型特征。误差互消意味着结构正确,标定可以分而治之。

Cross-Tool 精度横向

工具平台Avg Error关键备注
CalculonanalyticalA100 Selene3.65% / max 8.87%训练为主
GenZanalyticalH100 SXM< 6%推理
LLMCompassanalytical+searchLLM 推理4.1% E2E / 10.9% per-opmapper 搜索
MicrobenchmarkanalyticalB200MAE 1.31%当前最高
Vidurtrace-replayLLM 推理< 9% / P95 ≤ 3.33% / max 12.65%高负载场景误差放大
vTraintrace-replaytrainingMAPE 8.37%(单节点)/ 14.73%(多节点)NCCL 孤立 profile 低估 30%
Frontierevent-driven16×H800throughput < 4%;latency 44.9% → 6.4%现代工具显著降误差
SimAI(PP 场景)event-driven256 GPUavg 77.2%依赖建模缺失
PrismLLMevent-driven同 SimAI testbed0.58%修复 PP 依赖
LLMPerfML-basedLLM 推理24.25%(内部)→ 46.11%(公开)泛化崩塌

@tbl-ipm-v-cross-tool perf model 精度横向汇总

关键观察:

  • 同 testbed 同 workload,SimAI 与 PrismLLM 差 130×(77.2% vs 0.58%)——PP 依赖建模缺失是致命的模型误差,不是标定问题
  • LLMPerf 内部到公开 MAPE 翻倍——ML-based 工具泛化是最大弱点
  • Vidur 高负载 max 12.65% 比 P95 3.33% 大 4×——调度级联放大误差

报告精度声明的五大缺陷

读到"我们的工具误差 ±5%"时必须警惕的陷阱:

  1. 只报均值不报尾(max / P95 / P99 缺失)
  2. 只验证自有硬件,不跨平台
  3. 忽略并行策略失效场景(PP 是高危)
  4. 误差口径不统一(throughput / latency / MAPE 混用)
  5. Workload cherry-picking(标准 batch / BF16,不测 long-context / MoE / speculative decode)

敏感度与不确定性

参数估偏 ±10% 会传到端到端误差多少?这是敏感度分析问题。

三类经典方法的适用边界

方法计算量输出适合
OAT(One-At-a-Time)$O(k)$局部线性效应参数少(≤ 10),解析型模型
Morris$r(k+1)$,$r=5\text{-}10$$(\mu^*, \sigma)$ 主效应 + 交互event-driven 模型,Sobol 前的筛选
Sobol$N(k+2)$全局方差分解解析型或快 event-driven,cycle-approx 需先建代理模型

@tbl-ipm-v-sensitivity-methods 三类经典敏感度方法适用边界

G5 这一档的特殊性:cycle-approx 单次调用代价高,不能直接跑 Sobol —— 先用 LHS 采样 50-200 次拟合 RF / GP 代理模型,再对代理跑 Sobol。这是 cycle-approx 档敏感度分析的工程化路径。

不确定性传播

  • MC 仿真:对模型无假设但收敛慢($N \ge 1000$),解析型可行
  • PCE(Polynomial Chaos Expansion):数十至数百次样本拟合正交多项式,Sobol 指数从展开系数直接解析,参数 ≤ 10 时性价比最高
  • 标准工程路线:LHS 50-200 次 → 拟合代理 → 对代理跑 MC / Sobol

已报告的敏感度数字

  • Calculon(SC'23):A100 端到端误差 ±10%,参数误差近线性传播
  • LLMCompass(ISCA'24):算子级 10.9%、端到端 4.1%,多算子误差抵消
  • Vidur:静态 < 3.33%,高负载 95% max 12.65%——调度级联会放大误差而非抵消,方向与 LLMCompass 相反

Stage Importance 定义为"该阶段延迟增加 $\delta$ 时端到端延迟的相对变化"。prefill 在 compute-bound 区对 $\eta_{\text{compute}}$ 高度敏感;decode 在 bandwidth-bound 区对带宽高度敏感。跨越 roofline 瓶颈分叉点时敏感度突变——OAT 容易遗漏该非线性效应。

Pareto 稳定性

DSE 文献经验:参数扰动 ±20% 以内,Pareto 前沿拓扑结构(支配关系排序)通常稳定;两个设计点差距 < 5% 时小扰动可翻转支配关系。推荐:

  • 噪声注入测试(±10% 高斯噪声,Pareto 集成员变化率目标 < 20%)
  • Hypervolume 稳定性指标

第三阶段:DSE(设计空间探索)

问题定义

给定 $\{TP/PP/DP/EP \text{ 度} \times \text{batch size} \times \text{调度策略} \times \text{GPU SKU}\}$ 联合空间,找满足 SLO(TTFT / TBT 上界)且 TCO 最低的配置。

搜索算法

算法适用
穷举扫描解析模型评估极快时主流——Calculon 单次仿真 ~1 ms,支持"数十亿量级"配置
Vidur-Search先枚举合法配置再逐一仿真,LLaMA2-70B CPU 1 小时 = 42,000 GPU 小时实测($218K)
LLMCompass mapper单次仿真内对所有层做 26,400 次 tiling 参数搜索
Bayesian Optimization黑盒评估场景(SCOOT / MOBO)
AlpaServeDP + ILP 两阶段搜索并行策略
RL联合分片度优化(arXiv 2509.00217)

@tbl-ipm-v-dse-algos 主流 DSE 算法

Hardware Co-Design

DSE 不止搜软件配置,也搜硬件参数:

  • Calculon(SC 2023)在总内存约束下联合搜索 TP/PP/DP 与硬件规格
  • LLMCompass(ISCA 2024)搜索芯片微架构,发现 prefill 与 decode 对硬件需求本质不同:吞吐优先设计(HBM → DRAM + 4× 算力)vs GA100 吞吐 1.42× / 性价比 3.41×;延迟优先设计削减 50% 算力保留 95.3% 性能,面积减 42.1%

关键 DSE 案例发现

  • Vidur-Search 发现同一 LLaMA2-70B 在不同 workload 下最优 batch 不同:LMSys-Chat-1M = 256,BWB = 64——DSE 必须与 workload 联合做
  • Calculon 发现 GPT3-1T on 16,384 B200 最优配置 $n_t=8, n_d=32, n_p=64$——NVS 域扩大后最优策略从 PP 切换为 DP 主导,Pareto 呈非凸特性
  • Sarathi-Serve 不是 DSE 工具,而是 Vidur-Search 搜索空间里的一种候选调度策略;参数(token budget)通过 one-time profiling 确定,不自动搜索

DSE 输出的工程含义

配置依赖性必须显式标注:

  • "在 LMSys workload 下最优 batch = 256" ≠ "永远最优 batch = 256"
  • DSE 输出必须附带:(workload 假设, 硬件配置, SLO 约束)三元组
  • Sensitivity analysis 验证结论鲁棒性是必要项不是可选项

升降档判据(方法论视角)

  • 标定数据稀缺:用 analytical 档 + 单一 $\eta$,显式声明 "仅相对排序"
  • 目标硬件已上线:cycle-approx 跑代表性 kernel → 标定 analytical $\eta$ 分段曲线
  • 回答 SLO / P99 问题:必须 event-driven + 请求级 DES,analytical 给不出尾分布
  • 回答能耗 / 成本 / Pareto 选型:必须 DSE + sensitivity,单点最优解不可信
  • 跨工具结论不一致:SimAI vs PrismLLM 差 130× 警示——优先信报告了 max / P99 误差的工具,不信只报均值的

G5 落地视角(方法论)

G5(SystemC AT)在标定 / 验证 / DSE 三阶段的角色:

  • 标定:G5 跑代表性 kernel 标定 $\eta$ 与 microarch 参数,回喂 analytical 档(范式有向图最关键边)
  • 验证:G5 输出 cycle 数 + 资源画像 → 与 RTL co-sim 或硅后实测对标,worst-case 误差 4.5% 是当前 SystemC AT 工业精度
  • DSE:G5 单次调用代价高,不直接做穷举 DSE——配 RF / GP 代理模型(LHS 50-200 次 → 代理跑 Sobol / MC)是工程化路径
  • 报告精度规范:G5 输出必须含 max / P95 / P99,不能只给 avg——这是从 SimAI 教训反推的工程纪律

Takeaway

知识点核心结论
三阶段方法论标定 → 验证 → DSE,三步缺一不可
标定核心η 实测拟合,GenZ 单一 η / Calculon 分段曲线 / LLMCompass mapper 搜索
跨档标定cycle-approx 跑 kernel → 回归喂 analytical,是当前最高精度路径(B200 MAE 1.31%)
Data leakage标定集与验证集必须显式切分,否则报告精度无意义
三要素口径 / 配置 / 稳态,任一不对齐误差不可控
误差分层模型误差(改公式)/ 标定误差(改 η)/ 调度误差(改 DAG)修法不同
Cross-tool 警示SimAI PP 77.2% vs PrismLLM 0.58% 差 130×,优先信报 max / P99 的工具
敏感度Sobol 适解析,Morris 适筛选,cycle-approx 必须先建代理模型
DSE 算法解析快 → 穷举(Calculon 十亿级),event-driven → 候选枚举(Vidur-Search 1h CPU = $218K)
Pareto 稳定性扰动 ±20% 内拓扑稳定,差距 < 5% 时可翻转,sensitivity 是必选项

开放问题

  • Cross-tool unified benchmark 缺失:无公开论文跨 Calculon / Vidur / LLMCompass / GenZ 在同一 workload 同一硬件做对照,工具间精度比较只能依赖各自报告
  • DSE 算法在异构混部下的可扩展性:跨代 GPU / chiplet 系统的搜索空间指数膨胀,Vidur-Search 类穷举不再可行,BO / RL 的实际效果未充分研究
  • Sensitivity 在动态 workload 下的有效性:静态参数扰动不能 capture 真实 workload 变化的影响,stochastic sensitivity analysis 业界少有
  • LLM-based perf model 的可解释性:ML-based 工具(LLMPerf)误差报告大但内部黑盒,debugging 困难——这与 SimAI PP 失效一样致命

参考资料

延伸阅读