想象你经营一家奶茶店。顾客排队下单，店员在柜台接单（这是“内存”送数据），后厨在制作奶茶（这是“计算”在工作）。一杯奶茶的成本，有时候卡在“下单等待”（数据搬不动），有时候卡在“制作速度”（计算太慢）。你如何一眼判断这家店到底是柜台瓶颈还是后厨瓶颈？Roofline 模型就是给这个问题画的一张“成本地图”：横轴是“每杯奶茶需要的原料比例”，纵轴是“每秒能做多少杯”，天花板的高度由店铺的硬件条件决定。这张地图帮你快速定位——你的优化重点到底该放在“让柜台搬原料更快”还是“让后厨做奶茶更快”，从而避免把力气花在错误的地方。

岗位关联

对 AI 从业者而言，Roofline 模型是性能优化的“导航仪”：它让你在写 CUDA 内核、调整算子实现之前，就能判断瓶颈是计算密集还是访存密集，从而把优化资金花在最刀刃的位置，避免无效劳动。

目录
  1. 可视化演示
  2. 模型概念
  3. 关键参数
  4. 性能瓶颈
  5. 优化边界
  6. 工程实践
  7. 工具实战
  8. 误区与要点
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

模型概念

奶茶店开张了。你作为老板，最关心一件事：一天最多能卖出多少杯？店里有两条“生产线”：柜台负责接单和递原料（内存），后厨负责做奶茶（计算）。两者速度不一样。Roofline 模型就是把这幅图景抽象成一张二维图，横轴是“算术强度”——每搬运一份原料能做多少杯奶茶；纵轴是“性能”——每秒实际做多少杯奶茶。图上有两个天花板：一条是水平的“算力天花板”，代表后厨的极限速度为每秒最多做 200 杯；一条是斜向上的“带宽天花板”，代表柜台递原料的速度限制，每秒最多递 10 份原料，每份原料能转化成一定数量的奶茶。两条线交叉的位置，就是“转折点”。在转折点左边，你的产能受柜台限制；右边则受后厨限制。

这张图的价值在于，它把一个复杂的性能问题拆解成了两个独立约束：计算能力与访存能力。在 AI 硬件里，GPU 的算力由 SM（流式多处理器）数量、时钟频率和指令吞吐决定；带宽则由显存位宽和频率决定。两者都有明确的天花板，真实性能永远不可能越过这两条线构成的屋顶。Roofline（屋顶线）的名字就来源于此——它是一个由硬件能力画出的“屋顶”，软件优化只能不断逼近屋顶，永远无法突破。

设 P 为实际能达到的性能，I 为算术强度（FLOP/Byte），π 为峰值算力（FLOP/s），β 为峰值带宽（Byte/s）：

回到奶茶店：如果你通过优化让“每份原料做出更多杯奶茶”（提高算术强度），你的产能就会从柜台的限制逐渐爬升到后厨的天花板。Roofline 图正是帮助你判断：你的店现在到底卡在哪个环节，以及往哪个方向使劲最有效。

P≤min⁡(π,β×I)\displaystyle P \leq \min(\pi, \beta \times I)
这个公式用一句话概括：实际性能取两个约束中的最小值——要么被算力卡住，要么被带宽卡住。
  1. 性能上限 P指 GPU 实际运行某个算子时，每秒钟能完成的浮点运算次数（FLOP/s）。它不可能超过任何硬件天花板。
    PP
  2. 峰值算力 π后厨做奶茶的最快速度。由 GPU 的硬件规格决定，例如 V100 约为 112 TFLOPS（FP32）。
    π\pi
  3. 峰值带宽 β柜台递原料的最快速度。例如 V100 的 HBM2 显存带宽约为 900 GB/s。
    β\beta
  4. 算术强度 I平均每搬运 1 字节数据，能做多少次浮点运算。它是 Roofline 图的横坐标。
    I=FLOPByteI = \frac{\text{FLOP}}{\text{Byte}}
  5. 求最小值实际性能等于算力天花板和带宽天花板两者中较小的那个。如果 \( \beta \times I < \pi \)，说明带宽不够用，性能受访存限制。
    min⁡(π,β×I)\min(\pi, \beta \times I)

关键参数

要画出这张“屋顶图”，你需要先掌握四个参数：峰值算力、峰值带宽、算术强度，以及单位换算。峰值算力和峰值带宽是硬件出厂就决定了的，就像奶茶店的设备参数——后厨每秒最多做多少杯，柜台每秒最多递多少份原料。而算术强度则取决于你的算法和实现，就像你设计的流程——每份原料能做出多少杯奶茶。这四个参数共同决定了屋顶的形状和你所在的位置。

在 CUDA 编程中，峰值算力通常用 FLOP/s 表示，而算力由 GPU 的核心数、频率和每条指令的运算量决定。峰值带宽由显存类型（如 HBM2、GDDR6）和位宽决定。关键的是单位换算陷阱：算力常用 GFLOP/s 或 TFLOP/s，带宽常用 GB/s 或 TB/s，算术强度则是两者相除后得到的比例。因为 1 TFLOP = 1000 GFLOP，1 TB = 1000 GB，换算时要注意 10 的幂次，避免把实际性能算错一个数量级。

比如一个矩阵乘法算子，如果 A 和 B 两个矩阵各 1024×1024 的 FP32 数据，总数据量 8 MB，而一次矩阵乘法需要 2×1024³ 次浮点运算，计算强度就很高，落在转折点右侧。而一个逐元素加法（如 y = x + 1）读 4 MB 写 4 MB，只做 1M 次运算，计算强度很低，必然落在左侧。这就是为什么向量加法在 GPU 上往往达不到峰值算力——它不是算不快，而是被显存带宽按住了。

I=πβ\displaystyle I = \frac{\pi}{\beta}
转折点处的算术强度等于算力除以带宽。在 V100 上，这个值大约是 \( 112 \times 10^{12} / 900 \times 10^9 \approx 124 \) FLOP/Byte。
  1. 峰值算力 π 的获取在 CUDA 中，可以用 cudaDeviceGetAttribute 查询设备属性，或从官方 Spec 获取。单位通常为 TFLOPS。
    π=TFLOPS\pi = \text{TFLOPS}
  2. 峰值带宽 β 的获取带宽 = 显存频率 × 位宽 × 传输次数。例如 HBM2 的带宽计算。
    β=Frequency×Bus Width×Transfers\beta = \text{Frequency} \times \text{Bus Width} \times \text{Transfers}
  3. 算术强度的定义对某个具体算子，统计它总共做了多少次浮点运算和读写了多少字节数据。
    I=总浮点运算量总数据搬运量I = \frac{\text{总浮点运算量}}{\text{总数据搬运量}}
  4. 转折点 R当算力天花板等于带宽天花板时对应的算术强度，用于划分访存密集区和计算密集区。
    R=πβR = \frac{\pi}{\beta}

性能瓶颈

明白了屋顶的形状，下一步就是定位你的算子站在屋顶的哪个位置。如果算子的算术强度小于转折点 R，它就在“访存密集区”——如同柜台递原料太慢，后厨只能空等。此时无论后厨多快，产能都被柜台卡死。反之，如果算术强度大于 R，算子就在“计算密集区”——如同后厨做奶茶太慢，柜台递再多原料也积压，产能被后厨卡死。判断的方法很简单：把算子的算术强度画到图上，看它落在转折点的哪一侧，再看对应的天花板是哪一条。

这个判断对优化策略有决定性影响。在访存密集区，优化目标是减少数据搬运——例如用共享内存复用数据（让柜台一次递一大箱原料而非一杯一杯递）、合并访存、算子融合（把多个步骤的原料一次递齐）。在计算密集区，优化目标则是提升计算效率——例如使用更快的数学指令、减少分支、提高指令级并行。最怕的是在访存密集区拼命优化计算指令，或是在计算密集区拼命优化访存，这就好比在柜台瓶颈的奶茶店里雇佣更多的后厨师傅——完全白费力气。

一个典型的例子是 BatchNorm 算子。如果把它拆成“减均值、除方差、缩放、平移”四个单独 kernel，每个 kernel 都要把数据从显存读一遍再写一遍，算术强度低得可怜。但如果把四步融合成一个 kernel，数据只读写一次，算术强度翻四倍，性能立刻爬坡。这就是为什么高性能计算库（如 cuDNN、CUTLASS）里到处是融合算子——它们都在把计算点往屋顶的右边推。

实际性能≈{β×I,I<Rπ,I≥R\displaystyle \text{实际性能} \approx \begin{cases} \beta \times I, & I < R \\ \pi, & I \geq R \end{cases}
这个分段公式告诉你：在转折点左侧，性能随算术强度线性增长；右侧则封顶在算力天花板。
  1. 左侧（访存密集）当 I < R 时，带宽满载而算力闲置，性能被带宽限制，斜率为带宽 β。
    β×I\beta \times I
  2. 右侧（计算密集）当 I ≥ R 时，算力满载而带宽闲置，性能被算力限制，水平封顶。
    π\pi
  3. 观察瓶颈动态变化同一个算子的算术强度会随实现改变。例如，采用分块矩阵乘法后，I 从 2 提高到 100，算子从访存密集区移动到计算密集区。
    Iold<R<InewI_{\text{old}} < R < I_{\text{new}}

优化边界

Roofline 给出的天花板不仅有算力和带宽这两条基本约束，实际系统还有更多“隐形的屋顶”：网络边界、内存边界、延迟隐藏能力和缓存层级。在分布式训练中，即使单个 GPU 的算子已经逼近屋顶，多卡通信（如 NCCL AllReduce）也会成为新的瓶颈——就像奶茶店开了分店，但分店之间的原料运输车队成了新的瓶颈。Roofline 图可以扩展成“多层屋顶”：本地的算力屋顶、单机内存带宽屋顶、跨机网络带宽屋顶，层层叠加，形成一个阶梯状的峰值性能边界。

在实际 CUDA 内核中，内存边界通常以“有效带宽”的形式出现，而有效带宽往往远低于峰值带宽。原因之一是访存延迟：一次全局内存访问可能需要几百个周期，如果不对延迟进行隐藏，计算单元在等待数据时会大量空转。硬件通过大量并发线程（由高占用率提供）来隐藏延迟——线程 A 在等数据时，线程 B 继续计算。而缓存（L1/L2）则提供了另一个维度：如果数据能被缓存命中，实际访存量就远小于理论访存量，相当于提升了算术强度。Roofline 模型中的 I 应使用“实际搬运量”而非“理论数据量”。

回到奶茶店的比喻：如果你发现分店之间的原料运输太慢，就换用集装箱卡车一次运大批原料（减少通信次数）；如果你发现单个店员经常等柜台递料，就让多个店员交替工作（延迟隐藏）；如果你发现某几种原料经常被重复使用，就把它放在后厨门口的架子上（缓存）。每一种优化都对应屋顶图上的一个运动方向——向上移动、向右移动，或同时移动。

有效带宽=实际传输数据量耗时≤βpeak\displaystyle \text{有效带宽} = \frac{\text{实际传输数据量}}{\text{耗时}} \leq \beta_{\text{peak}}
公式揭示了一个关键事实：实际有效带宽永远不可能超过峰值带宽，而缓存命中可以让“实际传输数据量”变小，相当于拉高算术强度。
  1. 有效带宽定义用实测传输字节数除以 kernel 耗时得到，用于和峰值带宽对比。
    Effective BW=BytesTime\text{Effective BW} = \frac{\text{Bytes}}{\text{Time}}
  2. 延迟隐藏占用率越高，可供调度的线程越多，访存延迟就越容易被掩盖。
    Occupancy=活动线程数最大线程数\text{Occupancy} = \frac{\text{活动线程数}}{\text{最大线程数}}
  3. 缓存提升当数据被缓存命中时，实际访问 DRAM 的字节数下降，算术强度按比例上升。
    Ieffective=Itheoretical×1缓存命中率降幅I_{\text{effective}} = I_{\text{theoretical}} \times \frac{1}{\text{缓存命中率降幅}}

工程实践

纸上谈兵终觉浅。Roofline 模型的真正价值在于指导工程实践。针对访存密集的算子，第一条优化策略是向量化访存：在 CUDA 中使用 float4 这样的向量类型，让一个线程一次读取 16 字节，而不是拆成四个 4 字节的标量访问。这相当于把柜台从“一次递一杯”改成“一次递四杯”，显著提升有效带宽。第二条策略是算子融合：把多个连续 kernel 合并为一个，减少中间结果的显存写读。第三个策略是使用共享内存进行数据分块：让一个线程块把数据块加载到共享内存后反复使用，把算术强度成倍拉高。

对于一个具体的内核，优化步骤大致如下：先用 profiling 工具（如 NVIDIA Nsight Compute）测出实际 FLOP/s 和实际带宽；然后计算算术强度，把它放到 Roofline 图上；如果落在左侧，就按“访存优化清单”逐项尝试——向量化、合并访问、共享内存 tiling、算子融合；如果落在右侧，就按“计算优化清单”——优化循环、减少分支、使用更快的指令（如 FMA）、调整 block 大小。每做一步优化，重新测一遍，看是否向屋顶靠近。优化的终点在屋顶线上，任何实际性能都不可能越过它。

以 GEMM（矩阵乘法）为例，朴素实现每个输出元素都要从全局内存读取一整行和一整列，算术强度极低；而使用 32×32 分块的 CUTLASS 内核，数据在共享内存中复用，算术强度从个位数飙升到几百。这就是 Roofline 图上向右移动的真实案例。

优化目标=实测性能Proofline×100%\displaystyle \text{优化目标} = \frac{\text{实测性能}}{P_{\text{roofline}}} \times 100\%
这个比值叫“屋顶利用率”，越接近 100% 说明优化越到位。
  1. 向量化访存将两个 float 打包成 float2，四个打包成 float4，减少访存指令数和事务数。
    Memory Transactions↓\text{Memory Transactions} \downarrow
  2. 算子融合将 \( y = \text{ReLU}(Wx + b) \) 中的矩阵乘、加法、激活三个步骤合并为一个 kernel，中间结果不写回显存。
    DRAM Traffic=一次读入+一次写出\text{DRAM Traffic} = \text{一次读入} + \text{一次写出}
  3. 共享内存 tiling将大矩阵切成 tile，加载到共享内存后复用，减少全局内存访问次数。
    Arithmetic Intensity↑≈tile size\text{Arithmetic Intensity} \uparrow \approx \text{tile size}

工具实战

理论最终要靠工具落地。NVIDIA 提供了两个核心工具：Nsight Compute 和 Nsight Systems。Nsight Compute 是内核级分析器，能直接给出每个 kernel 的算术强度、内存吞吐量、计算吞吐量，并在 GUI 中绘制 Roofline Chart——把你的每个 kernel 以圆圈标在屋顶图上，一眼看出哪个 kernel 离开屋顶最近、哪个离得最远。Nsight Systems 则是系统级分析器，用于查看 GPU 之间的通信时间、kernel 之间的空隙、CPU 侧的瓶颈，帮助你判断瓶颈到底在 GPU 内部还是外部。

实战中，还有基于 AI 的 Roofline 模拟工具，它能在不运行程序的情况下，根据代码特征和硬件模型预测性能。例如 AMD 的 SCORPIO、学术界常用的 Palmetto，或 NVIDIA 的 Speed of Light 分析。这类工具的原理就是 Roofline 模型的机械化：解析 kernel 的访存模式，估算算术强度，然后根据目标硬件的 π 和 β 计算出理论性能上限。对一个团队来说，可以先用模拟器做设计空间探索，选定可行方向后，再用 Nsight 进行精确定位。

在实际项目中，我见过一个典型的诊断案例：一个 Transformer 模型的 layer norm 在 GPU 上运行速度远低于预期。用 Nsight Compute 一看，它的算术强度只有 0.3 FLOP/Byte，而 V100 的转折点是 124——妥妥落在访存密集区。团队之前一直在优化计算指令（用更快的近似函数、减少除法），效果甚微。改用向量化访存和融合 kernel 后，运行时间下降了 60%。这就是 Roofline 工具带来的方向感。

性能预测=min⁡(πmodel,βmodel×Iestimated)\displaystyle \text{性能预测} = \min(\pi_{\text{model}}, \beta_{\text{model}} \times I_{\text{estimated}})
模拟器只是把 Roofline 公式搬到更大的代码规模上，用自动化方式完成人工画图。
  1. Nsight Compute 的 Roofline 图它统计每个 kernel 的 FLOP 数和内存字节数，自动计算算术强度，并叠加在硬件屋顶上。
    Speed of Light=实测吞吐理论峰值\text{Speed of Light} = \frac{\text{实测吞吐}}{\text{理论峰值}}
  2. Nsight Systems 的通信时间获得 host、device、memcpy、communication 等阶段的时间线。
    瓶颈定位=arg⁡max⁡(耗时占比)\text{瓶颈定位} = \arg\max(\text{耗时占比})
  3. AI 模拟器用解析模型和机器学习模型，对目标代码在新硬件上的性能做快速预估。
    P^=min⁡(π,β×I^)\hat{P} = \min(\pi, \beta \times \hat{I})

误区与要点

关于 Roofline 模型，初学者最容易陷入几个误区。第一个误区是“优化方向误判”——在访存密集区纠结算法复杂度，或在计算密集区纠结数据布局。就好比奶茶店明明卡在柜台递料慢，却拼命给后厨添置高级设备。用 Roofline 图先定位，再行动，就能避免这个错误。第二个误区是“忽略存储层级”——把显存带宽当成唯一带宽，忽略了 L1/L2 缓存和共享内存。实际上，不同层级的带宽天差地别（寄存器 > 共享内存 > L1 > L2 > 显存），选择合适的层级能让算术强度大幅提升。

第三个误区是“过度优化复用”——为了让数据在缓存中复用，把 tile 设得过大，导致共享内存溢出或占用率下降，反而让性能降低。Roof line 模型指出的是边界，而不是越接近越好；实际性能还要考虑线程调度、同步开销等因素。最后一个要点是“理论边界指导实践”——Roof line 模型的价值不在于精确预测性能，而在于给出上限，告诉你当前代码距离理论上限还有多远，如果差距过大，就应该先检查访存模式，而不是盲目微调参数。

把 Roofline 当作地图而不是教条，它就能真正成为性能优化的导航仪。每次写 CUDA 内核之前，先在图上找位置，再定方向；每次优化之后，把实测性能标到图上，看是否接近屋顶。这套方法对 AI 工程师的价值，就像航海图对船长的价值——它不保证一帆风顺，但保证不迷失方向。

可用性能=min⁡(π,β×I,调度开销)\displaystyle \text{可用性能} = \min(\pi, \beta \times I, \text{调度开销})
实际的“屋顶”除硬件的算力和带宽外，还包括调度、同步、延迟等软性开销，它们会让屋顶更低。
  1. 修正认知Roof line 的“屋顶”是理论上界，真实性能会因开销而低于屋顶。
    Preal≤ProoflineP_{\text{real}} \leq P_{\text{roofline}}
  2. 优先级排序先判断访存密集还是计算密集，再选优化方向。
    策略={访存优化,I<R计算优化,I≥R\text{策略} = \begin{cases} \text{访存优化}, & I < R \\ \text{计算优化}, & I \geq R \end{cases}
  3. 分层带宽不同存储层的带宽差异巨大，优化时要意识到访问发生的位置。
    βregister≫βshared≫βglobal\beta_{\text{register}} \gg \beta_{\text{shared}} \gg \beta_{\text{global}}

AI 应用场景

场景一：训练大模型的算子性能瓶颈诊断

阶段：模型训练与性能调优

解决的问题：训练 Transformer 模型时，某些算子（如 LayerNorm、Softmax、Attention）占用了大量时间，但开发者不清楚是计算慢还是访存慢。传统方式靠猜测，反复优化却收效甚微。AI 通过 Roofline 模型，把每个 kernel 的算术强度自动计算并绘制在屋顶图上，快速定位哪些算子落在访存密集区，针对性优化。

具体案例：某团队训练 7B 参数大模型，发现 GPU 利用率只有 35%。用 Nsight Compute 绘制 Roofline 图后发现，80% 的 kernel 算术强度低于 2 FLOP/Byte，属于访存密集。他们将多个 element-wise kernel 融合后，显存读写量降低 60%，训练吞吐提升 1.8 倍。

场景二：AI 推理引擎的算子融合决策

阶段：推理部署与优化

解决的问题：推理引擎（如 TensorRT、ONNX Runtime）在做算子融合时，需要决定哪些算子值得融合。传统规则依赖专家经验，容易漏判或误判。AI 利用 Roofline 模型计算每个算子融合前后的算术强度，自动判断融合是否能把算子从访存密集区拉高到计算密集区，从而做出数据驱动的融合决策。

具体案例：在部署 Stable Diffusion 时，编译器通过 Roofline 分析发现，Attention 中的两个矩阵乘法之间插入了一个 reshape，导致中间结果写回显存。编译器自动消除 reshape 并融合两个 GEMM，算术强度从 8 提升到 55，推理延迟降低 22%。

场景三：异构 AI 芯片的设计空间探索

阶段：AI 芯片设计与验证

解决的问题：设计一款面向 AI 的新芯片时，需要决定算力和带宽的配比。传统方法多凭经验拍板，容易造出“带宽够大但算力闲置”或“算力冗余但带宽不足”的芯片。AI 用 Roofline 模型对目标工作负载（如 Transformer、CNN）进行统计，得到每个算子的算术强度分布，从而计算出最优的算力带宽比。

具体案例：某芯片公司设计 NPU 时，用 100 个代表性模型构建 Roofline 图，发现大多数算子的算术强度集中在 4-16 FLOP/Byte，于是将原本 1:2 的算力带宽比调整为 1:1，芯片面积减少 15%，跑分提升 10%。

Python 演示

python58 行
# -*- coding: utf-8 -*-"""一个极简的 Roofline 性能分析工具箱"""import math class RooflineModel:    def __init__(self, peak_flops, peak_bw):        self.peak_flops = peak_flops  # 峰值算力 FLOP/s        self.peak_bw = peak_bw        # 峰值带宽 Byte/s        self.ridge_point = peak_flops / peak_bw     def perf_bound(self, arithmetic_intensity):        """给定算术强度 FLOP/Byte，返回理论性能上限 FLOP/s"""        return min(self.peak_flops, self.peak_bw * arithmetic_intensity)     def classify(self, arithmetic_intensity):        """判断瓶颈类型"""        if arithmetic_intensity < self.ridge_point:            return "访存密集 (memory-bound)"        else:            return "计算密集 (compute-bound)"     def roofline_utilization(self, flops, bytes_moved, measured_time):        """实测性能 / 理论上限，得到屋顶利用率"""        measured_perf = flops / measured_time        arithmetic_intensity = flops / bytes_moved        bound = self.perf_bound(arithmetic_intensity)        return measured_perf / bound * 100.0  def estimate_arithmetic_intensity(shape):    """估算一个矩阵乘法的算术强度: C[M,N] = A[M,K] x B[K,N]"""    m, k, n = shape    flops = 2.0 * m * k * n    # 假设所有数据均为 FP32 (4 字节)    bytes_moved = (m * k + k * n) * 4.0  # 读取 A 和 B    return flops / bytes_moved  def main():    # 用 V100 的参数做演示: 112 TFLOPS FP32, 900 GB/s HBM2    v100 = RooflineModel(112e12, 900e9)    print("V100 转折点(FLOP/Byte): {:.1f}".format(v100.ridge_point))     shapes = [(1024, 1024, 1024), (4096, 4096, 4096), (128, 512, 128)]    for shape in shapes:        ai = estimate_arithmetic_intensity(shape)        bound = v100.perf_bound(ai)        kind = v100.classify(ai)        print("矩阵{}: 算术强度={:.2f} FLOP/Byte, 理论峰值={:.2f} TFLOPS, 类型={}".format(            shape, ai, bound / 1e12, kind))     # 模拟一个实际测量: 读取 8MB 数据做 1GFLOP, 耗时 2ms    util = v100.roofline_utilization(1e9, 8e6, 2e-3)    print("示例算子屋顶利用率: {:.1f}%".format(util))  if __name__ == "__main__":    main()
目的：用 Python 复现 Roofline 模型的核心计算逻辑，帮助你为任意算子估算算术强度、判断瓶颈类型、计算屋顶利用率。
  1. class RooflineModel:定义了一个描述硬件屋顶的类，用峰值算力和峰值带宽构造实例。后续所有判断都调用这个类。
  2. self.ridge_point = peak_flops / peak_bw在初始化时就算出转折点，之后只需比较算术强度和转折点就能判断瓶颈方向。
  3. min(self.peak_flops, self.peak_bw * arithmetic_intensity)这就是 Roofline 公式本身：理论上限等于算力和带宽两个约束中的较小值。
  4. estimate_arithmetic_intensity(shape)根据矩阵乘法形状估算算术强度，注意只算读取 A 和 B 的字节数，忽略了中间结果，实际分析中需要更精细的访存统计。
  5. flops / bytes_moved算术强度的定义：每搬运一个字节的数据对应多少次浮点运算，是这个模型最核心的横坐标。
  6. util = v100.roofline_utilization(...)用实测数据计算屋顶利用率，如果利用率远低于 100%，说明还有优化空间。

常见误区

误区我以为程序跑得慢就是 GPU 算得慢，于是把精力放在优化计算指令上，比如把除法改成近似指令、用更快的数学函数。结果性能几乎没变，白白浪费了几天时间。

正解性能瓶颈可能不在算力，而在访存。用 Roofline 模型先判断算子的算术强度：如果落在转折点左侧（访存密集），算力再快也无济于事，因为数据根本送不过来。这就好比奶茶店卡在柜台递料慢，后厨再快也白搭。正确做法是先优化访存模式（数据复用、算子融合、向量化访存），把计算强度向右推。

为何常见：常见原因是我们习惯性地把“慢”归因于“计算量大”，而忽略了现代 GPU 算力极强，许多算子实际被内存带宽锁死。没有数据支撑时，只能靠直觉猜测优化方向。

误区我把所有数据访问都算作显存访问，计算算术强度时直接用总数据量除以显存带宽，结果发现很多算子明明很访存密集，但实际性能却没那么差，于是觉得 Roofline 模型不准。

正解Roofline 模型中的“字节数”应该使用实际发生的最低层级访存量。如果数据被 L1/L2 缓存命中，或通过共享内存复用，真实的 DRAM 流量会远小于理论数据量。例如，一个分块矩阵乘法把数据加载到共享内存后复用，实际访存量可比朴素实现少一个数量级。使用有效带宽和有效算术强度重新画图，才能得到正确的结论。

为何常见：因为初学者接触到的 Roofline 图大多只画了全局显存带宽一条“屋顶线”，而忽略了多级存储结构。实际硬件是分层的，每一层有各自的带宽和容量。

误区我计算出一个算子的理论上限是 80 TFLOPS，但实测只有 50，以为是代码写错了或者工具测错了。后来反复验证，实测仍然只有 50，我开始怀疑 Roofline 模型的正确性。

正解Roofline 给出的是“理论上限”，即一切条件完美时的最大性能。真实性能还会受到延迟、占用率、同步开销、指令调度等因素影响，通常只能接近而无法达到屋顶。它的价值在于告诉你“差距还有多大”——如果实测只有理论值的 30%，说明优化空间很大；如果已经到 85%，就该考虑是不是值得继续折腾了。

为何常见：因为名字里带“模型”，让人误以为它像精确的数学公式一样可以算准性能。实际上它与硬件运行机制中许多难以建模的细节相抽象，只保留了两个最主要的约束。

误区我听说提高算术强度能提升性能，于是把共享内存的 tile 调到最大，让数据尽量复用，结果占用率大幅下降，性能反而更差了。我想不通，明明算术强度提高了，为什么变慢？

正解算术强度提高并不总能带来性能提升。Roofline 只给出了两个边界，但实际性能还要考虑并行度。共享内存 tile 过大，会导致每个 block 使用的寄存器或共享内存太多，SM 上能并发的 block 数减少，线程调度无法隐藏访存延迟，有效性能反而下降。因此要在 Roofline 的指导和实际测量之间寻找平衡点。

为何常见：因为 Roofline 是“一维”的，只考虑了算力和带宽，而实际 GPU 性能是算力、带宽、容量、延迟的多维平衡。把某个指标推到极端，往往会引发其他维度坍塌。

面试题

Q1. Roofline 模型中的“屋顶”是由哪两个量共同确定的？

单选题 · easy

  • A.峰值算力和峰值带宽← 正确答案
  • B.显存容量和缓存大小
  • C.线程数量和寄存器数量
  • D.核心频率和功耗限制

答案：A。Roofline 图的“屋顶”由两条线组成：水平线是峰值算力（FLOP/s），斜线是峰值带宽（Byte/s）乘以算术强度。二者共同围成性能上限。显存容量、线程数量、功耗都不是直接定义屋顶的坐标轴。

Q2. 如果一个算子的算术强度远小于转折点，它属于哪种类型？

单选题 · easy

  • A.计算密集
  • B.访存密集← 正确答案
  • C.延迟敏感型
  • D.缓存命中型

答案：B。当算术强度小于转折点（π/β）时，性能被带宽约束，也就是访存密集。此时即使算力再高，数据搬运速度也限制了整体性能，好比柜台递料太慢导致后厨空等。

Q3. 算术强度（Arithmetic Intensity）的定义是：

单选题 · mid

  • A.每秒浮点运算次数
  • B.每秒字节搬运量
  • C.浮点运算次数除以字节搬运量← 正确答案
  • D.字节搬运量除以浮点运算次数

答案：C。算术强度 = 总浮点运算量 / 总数据搬运量，单位是 FLOP/Byte。它衡量的是“每搬一个字节做多少计算”，是 Roofline 模型的横坐标，决定了算子落在屋顶的哪个位置。

Q4. 在 V100 上（112 TFLOPS，900 GB/s），转折点大约是多少 FLOP/Byte？

单选题 · mid

  • A.约 8
  • B.约 124← 正确答案
  • C.约 500
  • D.约 900

答案：B。转折点 = 峰值算力 / 峰值带宽 = 112e12 / 900e9 ≈ 124。实际中单位换算要仔细，如果忘记把 TFLOPS 和 GB/s 化为同一单位，就会得到错误的数量级。

Q5. 对于访存密集的算子，以下哪种优化策略最有效？

单选题 · mid

  • A.使用更快的近似除法
  • B.合并多个 kernel 以减少中间数据写回← 正确答案
  • C.增大一个线程的循环迭代次数
  • D.降低并行线程数以减少调度开销

答案：B。访存密集的性能瓶颈在数据搬运，因此算子融合、共享内存复用、向量化访存这类减少 DRAM 流量的手段最有效。优化计算指令对访存密集算子没有帮助，因为算力本来就没有饱和。

Q6. Roofline 模型中，为什么实际有效带宽往往低于峰值带宽？

单选题 · hard

  • A.因为显存会被计算单元占用
  • B.因为存在访存延迟、缓存未命中和并发不足← 正确答案
  • C.因为峰值带宽是厂商虚标
  • D.因为显存容量有限

答案：B。有效带宽低于峰值带宽的主要原因是延迟和利用率问题。线程需要足够多的并发来隐藏访存延迟，否则内存系统无法保持满负荷运转。另外，访存模式不连续、缓存未命中也都会让实际传输效率下降。

Q7. 以下哪些做法可以提升一个访存密集算子的算术强度？

多选题 · mid

  • A.使用共享内存分块复用数据← 正确答案
  • B.将多个逐元素 kernel 融合← 正确答案
  • C.使用向量化访问一次读取多个数据← 正确答案
  • D.提高 GPU 核心频率

答案：ABC。共享内存分块能减少全局访存次数，算子融合能避免中间数据反复读写，向量化访问能提高每次访存请求的字节效率——三者都能降低实际搬运字节数，从而提升算术强度。提高核心频率改的是算力天花板，而不会改算术强度。

Q8. 下列关于 Roofline 模型的说法，正确的有哪些？

多选题 · mid

  • A.它只能用于 GPU 性能分析
  • B.它给出的是性能上限而不是精确预测← 正确答案
  • C.转折点左侧应优先优化访存← 正确答案
  • D.缓存命中不会影响算术强度

答案：BC。Roofline 模型适用于任何有明确算力和带宽约束的硬件，不仅限于 GPU。它给出的是理论上限，真实性能通常低于屋顶。缓存命中会降低实际 DRAM 流量，因此应使用有效算术强度。转折点左侧就是访存密集区，优先优化访存。

Q9. 在 CUDA kernel 优化中，延迟隐藏的作用是什么？

多选题 · hard

  • A.用并发线程掩盖访存等待时间← 正确答案
  • B.提高算术强度
  • C.让计算单元在数据到达前不空转← 正确答案
  • D.减少缓存未命中

答案：AC。延迟隐藏靠提高占用率，让多个线程交替执行。线程 A 等数据时线程 B 算数，计算单元就不至于空转。它并不改变算术强度本身，只是让实际吞吐更接近理论极限。缓存未命中是访存模式问题，与延迟隐藏手段不同。

Q10. 一个矩阵乘法算子的峰值算力利用率为 90%，访存带宽利用率为 30%，瓶颈最可能是哪一类？

单选题 · hard

  • A.网络通信瓶颈
  • B.访存密集瓶颈
  • C.计算密集瓶颈← 正确答案
  • D.延迟隐藏瓶颈

答案：C。算力利用率很高而带宽利用率很低，说明算力接近饱和，属于计算密集。此时优化访存几乎没有收益，应该聚焦于减少冗余计算、提升并行效率、使用更快的数学指令。若带宽利用率高而算力低，才是访存密集。