怎么公平地 benchmark 一个 kernel？
不同方案怎么保证在相同环境下比？

英文问法How do you benchmark a GPU kernel fairly? · How do you make sure two candidates are compared in the same environment? · Which baseline and dtype did you compare against, and where does the speedup number come from?

考过别家面经原题：字节跳动（火山引擎方舟）Managed Agent 一面，校招，发帖 2026-08-13「如何设计 benchmark，保证不同方案是在相同环境下比较？」（牛客）· 遂原科技 AI Infra 27 实习一面 2026-05-01「对比所用的官方 baseline 选择及数据类型」「性能提升数据的来源，动态分块策略与算子配置」（牛客）· Unity 自己的材料：FlashVector §5 "The baseline measurements and all subsequent profiling of optimized variants were carried out in the same environment" · 没有 Unity 自己的面经原题

先弄清楚：每个概念是什么

异步执行: CPU 把 kernel 交给 GPU 就返回，不等它跑完。
synchronize 和 CUDA event: torch.cuda.synchronize() 让 CPU 等 GPU 跑完，再用 host timer 停表，量到的时间含 launch overhead。CUDA event 量的是 GPU 时间。
Baseline: 拿来对比的参照实现。它越弱，speedup 越好看（例子见 KernelBench）。
Speed of light: 硬件的物理上限，由峰值算力和 memory bandwidth 算出来（见 roofline）。

看图：一次计时的时间线

图 1：时间从左到右，不按比例。不同步就停表只量到 launch，在 synchronize 之后停表或用 CUDA event 才量到 kernel 本身。

30 秒回答

GPU kernels launch asynchronously, so a host timer without a sync only measures the launch. I time with CUDA events, or call synchronize before and after. Then I cut the noise: warm up, repeat and take the median, flush the L2 cache between runs, lock the GPU clock and keep the GPU exclusive. To compare candidates fairly, they run on the same machine, build, shapes and dtype, in alternating or random order. The baseline has to be strong, like torch.compile with TF32 on, not eager FP32. Finally, anything faster than the hardware's speed of light is a bug.

怎么计时，怎么去噪

措施	防什么	谁这么做
同步后再停表	只量到 launch	PyTorch 文档
Warmup，先空跑几次	初始化被算进去	KernelBench 用 3 次 warmup 加 100 次 trial；Triton `do_bench` 默认 25 ms warmup、100 ms rep
多次取 median	离群值带偏结果	CUDA-L1 取 median of bucket averages；GPU MODE 跑到 relative standard error 低于 1% 才停
每次运行前清 L2	上一次留在 cache 里的数据	`do_bench` 每次调用前执行 `clear_cache`
锁时钟、独占 GPU	频率变化，别的任务抢 GPU	SOL-ExecBench 把 B200 锁在 1,500 MHz；KernelBench 一次只跑一个 kernel
规模调到 1–15 ms	launch overhead 占主导	KernelBench v0.1 的做法，也可以用 CUDA graph

KernelBench 原来的 ReLU 一次只要 13 µs。launch overhead 按 5 µs 算（示意），占了三分之一还多。v0.1 把这题调到 6.97 ms，同样的 5 µs 不到 0.1%。

不同方案怎么在相同环境下比

同一台机器、同一套 build：KDA 要求 baseline 和候选同 ABI、同 build 路径
同样的输入：固定 shape 和 dtype，最好用生产 shape
交替或随机先后：KDA 让 A/B 交替跑，CUDA-L1 每轮随机决定谁先跑
离群值复测：CUDA-L1 把超过 3x 的结果放到第二张 GPU 上复测，相差 10% 以内才接受

比 agent 方案时，还要固定 model 版本、image 和 seed，各方案跑同一批题（见大批量跑 agent）。

必答点

kernel 异步执行，所以用 CUDA event，或在计时前后 synchronize
warmup，多次取 median，清 L2，锁时钟，独占 GPU
单次运行调到 1–15 ms，launch overhead 才不占主导
相同环境：同机器、同 build、同输入，交替或随机先后
baseline 要强：torch.compile、TF32、厂商库
比 speed of light 还快的结果是 bug（见 reward hacking）

追问

论文里的 speedup 能直接比吗，自己怎么报告？

不能，各家的 baseline、dtype、hardware、shape 和 best-of-k 的选法都不一样。自己报 geomean speedup 和 fast_p，并写清这几项和 PyTorch 版本。

FlashVector 在这方面写了什么？

baseline 和候选在同一环境测，config sweep 跑在生产机型的隔离节点上，端到端的 noise floor 是 ±6%。warmup、锁时钟和清 L2 论文都没写。

来源PyTorch CUDA notes · Triton testing.py（do_bench）· KernelBench v0.1 · CUDA-L1 · SOL-ExecBench · KernelBench-Verified · KDA · ml-八股 08 第 16 题 · 文献笔记 5.2 节 · 面经出处见中文平台调研 1.7 节

怎么公平地 benchmark 一个 kernel？不同方案怎么保证在相同环境下比？