跳转至

仿真实验方法

可信的仿真结论来自“问题—模型—校准—解释”的闭环。配置能跑通只是起点；真正困难的是确认模拟器测到的量与真实问题属于同一层抽象。

标准流程

flowchart LR
    Q[提出可证伪问题] --> M[选择最小充分模型]
    M --> W[固定 Workload 与 ROI]
    W --> B[建立 Baseline]
    B --> C[用微基准校准]
    C --> S[单变量 Sweep]
    S --> A[归因与敏感性分析]
    A --> R[实机/另一模型交叉验证]
    R -. 修正参数或假设 .-> M

1. 把问题写成可证伪假设

不写“研究更大的 L2”，而写：

在固定 A100-like 核心与 HBM 带宽时，把 L2 从 20 MB 增加到 40 MB，会因为减少目标 GEMM/Attention 的 HBM 流量而降低执行周期；若 L2 Miss 与 HBM 读流量没有下降，则假设不成立。

假设中应出现：工作负载、固定项、自变量、因变量与预期机制。

2. 固定 Workload 与 ROI

  • 明确是完整应用、一个 iteration、一个 layer 还是单 kernel。
  • 记录动态 shape、输入数据和控制流是否会改变 Trace。
  • 区分冷启动、Warmup 与稳定阶段。
  • 模型太慢时用采样/截取，但确认 ROI 仍代表目标瓶颈。

3. 先建立可以解释的 Baseline

Baseline 至少做三种守恒检查：

  1. 功能守恒：输出或指令数是否符合预期。
  2. 流量守恒：关键 Tensor 大小与各层读写量是否数量级一致。
  3. 时间守恒：总周期能否由计算、访存与 Stall 分类近似解释。

4. 用微基准校准单一机制

机制 微基准 校准指标
算术流水线 依赖链与独立指令流 latency、reciprocal throughput
Cache 不同 Working Set 与步长 容量拐点、命中率、延迟
HBM/DDR 顺序/随机、读/写、并发度 可达带宽、饱和点
Warp/线程调度 改变 occupancy 与依赖 Eligible Warp、Stall、IPC
NoC/互连 改变源宿与注入率 吞吐、拥塞、尾延迟

不要用一个端到端模型同时拟合十几个未知参数；那只能得到多组都“看似匹配”的配置。

5. Sweep 时保留完整上下文

推荐输出长表而不是只保存最终图片：

workload,shape,precision,sim_commit,config_hash,l2_mb,hbm_gbps,cycles,l2_miss,hbm_read_bytes
gemm,4096x4096x4096,fp16,<sha>,<hash>,20,1555,...,...,...
gemm,4096x4096x4096,fp16,<sha>,<hash>,40,1555,...,...,...

每次只改变一个主变量；如果做多因子设计，显式记录交互项，避免把频率、带宽和核心数同时扩大后仍声称是某一个因素导致提升。

常见陷阱

陷阱 为什么危险 修正方式
用默认配置代表某产品 参数可能来自不同代际或只是示例 对照官方规格和微基准逐项校准
只比较总周期 相同总周期可能来自不同瓶颈 同看流量、命中率、队列与 Stall
把 Trace 当作可变程序 Trace 固定了控制流与部分动态行为 改 ISA/输入时重新采集或换执行驱动模型
用峰值带宽作可达带宽 协议、访问粒度和并发都会打折 以匹配模式的实测微基准校准
把误差均值当可信度 正负误差会抵消 报 MAPE、分位数、最大误差和异常点
从一个模型推广到所有 AI 算子形状与复用模式差异很大 建立覆盖 Compute/Memory/Control 的 workload suite

最小结论模板

## 结论

- 问题与假设：
- Workload / ROI：
- Baseline 与校准误差：
- 自变量范围：
- 观测到的变化：
- 机制证据（流量/队列/Stall）：
- 对真实硬件的适用边界：
- 尚未建模的因素：
- 下一步证伪实验：

延伸阅读