cuDNN/cuBLAS：性能基准benchmark

可视化演示

算子库与性能基准

品鉴师上任第一天要摸清家底。他把两位大厨叫到跟前：cuBLAS 刀工组，负责切切剁剁，一切矩阵乘法的活计都归它；cuDNN 掌勺组，负责煎炒烹炸，神经网络里最耗时的卷积操作是它的招牌菜。这两个算子库是 NVIDIA 官方精心调校过的“后厨班底”，普通人写矩阵乘法像用菜刀削土豆，它们却用上了特制的高速刀组——GPU 上的 SIMT 并行、寄存器和共享内存的层层调度，全被封装成了一个个开着现成接口的老火灶。

但“官方出品”不等于“永远最快”。同样一道矩阵乘法，换一批客人（batch size）、换一种食材分量（矩阵行列数），两位大厨的发挥天差地别。于是性能基准测试有了第一重意义：把抽象的“快”翻译成可比较的数字。它像品鉴师拿着秒表，记录每道菜从下单到上桌的真实时间，为后厨排班（算子选择）、食材采购（精度设置）提供不容辩驳的定量依据。

算法工程师做模型优化时，常常遇到两难：这个卷积该用 FP16 还是 FP32？batch size 开到 64 还是 128？没有基准数据，你就只能轮询试错、靠玄学调参。而一套规范化的 benchmark 能产出一张“性能地图”，让你在动手优化前就看清每条路的大致走向。

回看这几位后厨大厨：cuBLAS 和 cuDNN 再厉害，也需要品鉴师用吞吐量这把尺子量一量。尺子拿稳了，后面每道“菜”的评测才站得住脚。

核心算子原理

品鉴师要写评测方案，先得看懂两道招牌菜是怎么做的。第一道是 GEMM——通用矩阵乘法（General Matrix Multiply）。想象你要把一批样本从输入层变换到隐藏层，每个样本的向量都要和权值矩阵做一次乘法累加。对 batch size 为 $b$ 的输入 $A$ 和权值 $B$，输出的第 $i$ 行第 $j$ 列，是 $A$ 的第 $i$ 行与 $B$ 的第 $j$ 列逐元素相乘后求和。这个过程的浮点运算量是固定的 $2mnk$：三个维度分别是输出行数、输出列数和累加长度。

第二道是卷积。它像一个滑动窗口在输入特征图上扫描，每滑到一个位置，就把窗口内的像素与卷积核逐元素相乘再求和，得到输出特征图的一个点。图像分类、目标检测这些任务几乎全靠它在底层撑腰。cuDNN 为卷积准备了多套算法：直接计算、隐式 GEMM、Winograd 变换……不同 shape 下各有胜负。

这套原理直接决定了 benchmark 设计的方向：既然耗时主要由 $m,n,k$ 和 batch size 决定，那么测试用例就要围绕这些维度展开；既然不同算法各有优劣，那么就要在统一接口下替算子库做“算法探试”。

理解了这两道菜，品鉴师才明白：原来出菜快慢，很大程度上已经被菜量（$m,n,k$）和做菜方式（算法）写死在剧本里了。接下来要做的，就是设计一桌能覆盖各种口味的“评测套餐”。

测试用例设计

设计套餐，最忌讳的是漫无目的地乱点菜。品鉴师遵循的第一原则叫控制变量：一次只动一个因素，其他全部锁死。他要摆弄的调料主要有三味。

第一味是 batch size——一次同时处理多少样本。GPU 是个流水线厨房，批量越大，每道菜的固定准备成本（内核启动、显存搬运）就被摊得越薄，吞吐量通常先涨后趋于饱和。第二味是矩阵维度 M/N/K——菜的分量。分量越大，计算密度越高，越能发挥 GPU 的算力。第三味是精度模式：FP32 像用精细电子秤称量每一位小数，FP16 像用托盘天平，速度快一半但可能称不准。此外还有 TF32、BF16 等变体。

把这三维组合起来，就形成了一个测试矩阵。用枚举法生成：batch size 取 {1, 4, 16, 64, 256}，维度取 {128, 256, 512}，精度取 {FP16, FP32}，排列组合出几十到上百个用例。组合数量随维度增长呈乘积式爆炸，所以必须用手写脚本批量生成，而不是一个个手动敲。

三味调料齐了，套餐单子也拉好了。但光有点菜的单子还不够——后厨什么时候开火、每次烧几遍、记录本怎么填，这些流程细节，直接决定了评测数据可不可信。

基准测试流程

品鉴师把评测流程拆成四步走，每一步都像标准化厨房的 SOP（标准作业程序）。

第一步是制定测试计划。明确测试对象（是 cuBLAS 的 GEMM 还是 cuDNN 的卷积）、硬件环境（GPU 型号、驱动版本、算子库版本）和测量口径（以毫秒记还是微秒记）。环境不锁死，数据就是废纸。第二步是批量生成用例。用脚本把设计好的参数组合循环展开，每一条用例包含完整的输入 shape、精度和预热次数，自动生成可执行的测试代码。

第三步是采集性能数据。这里有个关键细节：正式计时前必须预热（warmup）。GPU 像刚启动的发动机，频率还没拉起来，缓存也是空的。先空跑几次让“水温上来了”，再开始计时。同样一个用例要重复多次，取中位数或最小值，而不是第一次的数值——因为环境抖动、临近任务的干扰都会让单次测量失真。第四步是结果记录与存储。每次实验的结果按统一格式写入 CSV 或数据库，附上环境信息，方便日后回溯比较。没有一个结构化的记录，测一百次也只是一堆散沙。

这套四步流程跑完后，品鉴师手上就有了一大摞记录。但“耗时 2.3 毫秒”这种孤零零的数字没有意义——它需要放在算力的天秤上称一称，才知道这道菜到底有没有发挥出厨房的全部潜力。

吞吐量分析

拿到一个个耗时的原始记录，品鉴师要做的第二步是换算成吞吐量和利用率。先把 FLOPs 除以耗时得到实测 TFLOPS：计算量是固定的 $2mnk$，时间是测出来的，它们一比，就得到每秒完成了多少次浮点运算。接着把实测 TFLOPS 除以 GPU 的理论峰值 TFLOPS，得到算力利用率。利用率 80% 说明后厨火力全开；利用率只有 20%，就要警惕了：是不是菜量太小（小矩阵），大部分时间浪费在“端菜”（数据传输和内核启动）上？

这就是著名的瓶颈定位逻辑。当矩阵很小时，GPU 计算核心大部分时间在等待数据从显存搬进来，此时是带宽瓶颈；当矩阵足够大时，计算核心满负荷运转，此时才逼近计算瓶颈。品鉴师要把每个用例的利用率标注在图表上，一眼看出哪道菜是“配菜拖累了主厨”。

分析做完，品鉴师手里的零散记录终于拼出了一张有洞察的性能地图。但单份地图只对一次评测有效——他把所有地图装订成册，就建起了后厨最宝贵的资产：性能基线数据库。

性能基线数据库

最后一步，是把所有评测结果沉淀成一本可以反复查阅的“点菜攻略”。这本攻略的第一项功能是横向对比：同样一个 GEMM，batch 32 和 batch 128 谁快？FP16 比 FP32 快多少？一目了然。第二项功能是版本回归：NVIDIA 更新了 cuDNN 版本，你担心升级后某些 shape 反而变慢。怎么办？把新旧版本在相同用例集上各跑一遍，拿新结果去和基线库里的旧记录比，慢于基线 5% 就报警。第三项功能是最优配置推荐：模型训练时该不该把 torch.backends.cudnn.benchmark 打开？打开后算子库会在第一次调用时遍历所有算法，选最快的那个，后续复用。而这个选型决策的依据，正是基线数据库中积累的 shape→最优算法映射。

更好的做法是把这套基准做成自动化回归：每次代码提交或环境变更，CI 流水线自动跑一遍核心用例集，把关键指标画成趋势图。某天曲线突然下跌，说明最新的改动引入了性能回退，开发者能第一时间定位。这就把一次性的评测，升级为持续保障性能的引擎。对模型优化来说，基线数据库是“参考书”——面对新的网络结构，先查库，再决定精度、batch size 与算子算法，避免从零试错。

从最初的秒表计时，到如今的自动化回归与智能选型，性能基准就这样完成了从“一次评测”到“持续资产”的跃迁。品鉴师的这本攻略，让后厨的每一次决策都有了据可查、有数可依。

AI 应用场景

Python 演示

import timeimport csvimport numpy as np  def run_gemm_like(a_shape, b_shape, dtype=np.float32):    """模拟一次 cuBLAS GEMM 调用, 返回耗时秒数与输出形状。"""    a = np.random.rand(*a_shape).astype(dtype)    b = np.random.rand(*b_shape).astype(dtype)    t0 = time.perf_counter()    np.dot(a, b)    elapsed = time.perf_counter() - t0    return elapsed  def measure_once(batch, m, k, dtype, repeat=3):    """测试一个用例, 重复多次取最小耗时, 换算成 TFLOPS。"""    n = k    times = []    for _ in range(repeat):        a_shape = (batch, m, k)        b_shape = (k, n)        times.append(run_gemm_like(a_shape, b_shape, dtype))    best = min(times)    flops = 2.0 * batch * m * n * k    return best, flops / best / 1e12  def main():    dtype_map = {"fp32": np.float32, "fp16": np.float16}    configs = [        (1, 128, 128, "fp32"),        (4, 128, 128, "fp32"),        (16, 128, 128, "fp32"),        (64, 128, 128, "fp32"),        (64, 256, 256, "fp32"),        (64, 512, 512, "fp16"),    ]    rows = []    for batch, m, k, name in configs:        sec, tflops = measure_once(batch, m, k, dtype_map[name])        rows.append([batch, m, k, name, round(sec, 5), round(tflops, 2)])        print("%4d x %4dx%-4d %-5s 耗时 %7.5fs  吞吐 %7.2f TFLOPS" % (batch, m, k, name, sec, tflops))    with open("gemm_bench.csv", "w", newline="") as f:        writer = csv.writer(f)        writer.writerow(["batch", "m", "k", "dtype", "time_s", "tflops"])        writer.writerows(rows)    print("结果已写入 gemm_bench.csv")  if __name__ == "__main__":    main()

1. configs = [...]定义测试用例集合，包含 batch size、M/K 维度与精度档位，对应正文“测试用例设计”中的组合矩阵。
2. times.append(run_gemm_like(a_shape, b_shape, dtype))对同一用例重复执行，把多次耗时收进列表，供后续取最小稳定值。
3. best = min(times)取最小耗时而不是平均耗时，用来模拟“热身后最优状态”，对应 warmup 后取最优的行业惯例。
4. flops = 2.0 * batch * m * n * k用正文公式 FLOPs = 2mnk 计算该用例的浮点运算总量。
5. round(tflops, 2)把 TFLOPS 保留两位小数，便于阅读与归档。
6. writer.writerow([...])将每条用例的结果串行写入 CSV，对应“结果记录存储”环节，为性能基线数据库提供原始素材。

常见误区

面试题