注：建议在开始学习本专栏前先完成对 推理优化工程师快速入门指南 专栏中所有内容的学习。
SM 执行资源与占用率误区
把 GPU 看作一群并行执行的 SM，是最常见的抽象；但要解释"为什么 Tensor Core 没吃满"，必须进入单个 SM 的内部，理解 warp scheduler、寄存器文件与 shared memory 如何在每个时钟周期内争夺资源并最终决定占用率（occupancy）。
理论占用率与实际占用率：一道算术题，而非终点
**理论占用率（theoretical occupancy）**定义为：当前内核配置下，单个 SM 上活跃 warp 数占硬件最大 warp 数的比例。以 H100 SM 为例：硬件最大支持 64 个 warp（2048 线程），若内核因寄存器或 shared memory 限制只能驻留 48 个 warp，则理论占用率为 75%。
这个数字是纯静态计算的------它只回答"最多能放多少 "，从不回答"实际用了多少 "。**实际占用率（achieved occupancy）**由硬件计数器（如 sm__warps_active）在运行时测得，反映的是每个周期真实驻留的 warp 数。两者之间常常隔着一条鸿沟：即便理论占用率 100%，若内核存在严重的尾效应（tail effect）------最后一个 block 的线程数不足以填满 SM------或调度器因数据依赖而频繁停顿，实际占用率可能只有 60%。
类比：理论占用率像酒店的最大房量，实际占用率是当晚真实的入住率。酒店能住满不代表每间房都有人在使用------关键在于入住的人是否在干活。
寄存器压力：占用率的第一道闸门
每个 SM 的寄存器文件（register file）是固定大小的物理资源。H100 每个 SM 拥有 64K 个 32-bit 寄存器（256 KB），这些寄存器由所有驻留 warp 共享。编译器在编译内核时，会根据代码复杂度为每个线程分配固定数量的寄存器------这个数字直接决定了理论占用率的天花板：
占用率上限 = SM 寄存器总量 / (每线程寄存器数 × 线程块大小 × 块内线程数)例如，一个内核每线程使用 128 个寄存器，块大小 256 线程。则每个块消耗 128 × 256 = 32,768 个寄存器。SM 最多容纳 64K / 32K = 2 个块，即 512 线程驻留------理论占用率仅 25%（512/2048）。
寄存器压力通常来自：
- 深层流水线展开（pipeline unrolling）：编译器为隐藏延迟而展开循环时，需要更多寄存器保存中间状态
- 复杂地址计算：多维索引、动态偏移会产生大量临时变量
- 函数调用深度：每次调用需要保存返回地址和局部变量
开发者常犯的错误是盲目使用 __launch_bounds__ 或 maxrregcount 强制降低寄存器数------这会导致编译器将寄存器**溢出（spill）**到 local memory（即显存）。一次溢出约需 400-600 周期的访存延迟，远比寄存器访问的纳秒级慢几个数量级。降低占用率换来的寄存器空间，往往被性能更差的 local memory 流量抵消。
指令级并行：隐藏延迟的真正引擎
传统的 CPU 优化思路是"提高占用率以隐藏延迟"------让 GPU 在等待某个 warp 的访存时切换到另一个 warp 执行。这在逻辑上正确，但忽略了一个关键点：每个 warp scheduler 在每个周期只能发射一条指令（Hopper 架构下每个 SM 有 4 个 scheduler，每个负责一组 16 个 warp）。
这意味着隐藏延迟的深度不仅取决于 warp 数量，还取决于每个 warp 内部可并行的指令数量（ILP）。考虑以下两种情况：
- 情况 A：64 个 warp，每个 warp 内的指令串行依赖（A→B→C→D）
- 情况 B：32 个 warp，每个 warp 内有 4 条可并行执行的独立指令流
在相同调度器数量下，情况 B 的吞吐可能更高------因为 scheduler 在每个周期都有多个可发射的候选指令，不必等待某个 warp 解除停顿。这就是指令级并行对占用率的部分替代效应。
同理，**内存级并行（MLP）**也类似：一个 warp 若能同时发出 4 个独立的 load 请求（对应 4 个不同的 cache line），它的访存延迟等待时间可以通过批处理摊薄。
Tensor Core 管线的占用率需求
Tensor Core 操作（如 H100 上的 WGMMA）与普通 FMA 指令不同：它们操作的是寄存器和 shared memory 中的大块 tile（如 128×128），且执行时间长（数十周期）。要让 Tensor Core 保持忙碌，SM 需要在此期间持续供应数据------这要求：
- 足够多的 warp 驻留，使得部分 warp 在等 Tensor Core 结果时，其他 warp 能继续执行 MMA 指令
- 异步拷贝（TMA）与计算的重叠，让 shared memory 的数据搬运与 Tensor Core 计算并行
在实践中，Tensor Core 理想工作负载是：每个 SM 驻留 8-16 个 warp （即占用率 12.5%-25% 即可），但这些 warp 必须持续不断地向 Tensor Core 发送 MMA 指令。若占用率过高（如 64 个 warp），warp 间的上下文切换和寄存器压力反而会增大调度延迟，降低 MMA 发射频率。
这揭示了占用率优化的核心悖论：高占用率是手段，不是目的。目的是让每个执行单元在每个周期都有指令可执行。
高占用率 ≠ 高吞吐：三个典型场景
场景一：shared memory 带宽瓶颈。 一个内核理论占用率 100%（32 个 warp/块），每线程读取 shared memory 中同一 bank 的数据。此时所有 warp 的访存请求在 bank 冲突中排队，SM 的 shared memory 带宽被锁死，即便 64 个 warp 全部驻留，有效吞吐也远低于 32 个 warp 且无冲突的情况。大量 warp 反而增加了冲突请求的排队长度。
场景二：负载不均的尾效应。 假设网格包含 100 个 block，SM 数 132（H100）。98 个 block 先完成，剩余 2 个 block 散布在 2 个 SM 上，其余 130 个 SM 空转。此时实际占用率从 100% 骤降至约 1.5%，但吞吐损失远超 98%------因为最后 2 个 block 承担了整个网格的全部计算。
场景三：同步开销主导。 使用 __syncthreads() 的内核，若块内线程数过多（如 1024），每次同步需要全部线程抵达屏障。高占用率意味着更多 warp 等待同步，块切换延迟增加。这种情况下，减小块大小、提高块数量往往比追求高占用率更有效。
正确的分析路径
当 Kernel 性能未达预期时，按以下顺序检查：
- 先看实际占用率 vs 理论占用率 （NVIDIA Nsight Compute 的
Occupancy分析页），若实际远低于理论，定位是负载不均还是同步开销 - 再看 stall 原因 ：warp stall 的细分（
long scoreboard表示等待访存，wait表示等待固定延迟指令，math pipeline throttle表示执行单元饱和）------这些数据比占用率数字本身更具诊断价值 - 最后检查 Tensor Core 利用率 ：若
tensor pipe活跃度低于 60%，问题往往不在占用率，而在数据供应链路（TMA 未重叠、shared memory 带宽争用）
占用率只是系统健康的一种指标 ，而不是目标。真正目标始终是一个：让每个执行单元在每个周期都有可执行的指令。从下一节开始，我们沿着这条主线，深入 load/store 路径，看看 coalescing 与 cache line 如何从内存层级决定实际带宽的边界。
数据移动的物理学：从指令发射到 DRAM 的每一次握手
上一节我们通过占用率视角得出了一个结论：能塞进 SM 的 warp 数只是入场券，真正决定内核能否逼近峰值性能的，是数据能否在正确的时间出现在正确的位置。现代 GPU 的峰值算力之所以远高于其 DRAM 带宽所能支撑的水平，正是因为设计者假定：你写给寄存器的每次 load/store 指令，都被 GPU 的存储层次结构以最高效率承接了。这个假定一旦被打破，有效带宽可能跌到理论值的几分之一，而 Tensor Core 将沦为一片空转的硅。
4.1 事务的最小单位是 32 字节：sector 的语义
在讨论 coalescing 之前，必须先引入一个比 cache line 更基础的概念：sector 。NVIDIA 从 Volta 架构开始将 L2 cache line 定义为 128 字节，但内部传输和失效的粒度是 32 字节的 sector。一条 warp 的 load 指令（32 个线程各取 4 字节）在理想情况下被硬件打包成一次 128 字节的事务，正好覆盖 4 个 sector。但如果 warp 内线程访问的地址发散到两个 128 字节对齐的区域，硬件就会拆分成两次事务；发散到四个不同区域，就是四次事务------即便实际需要的字节数只有 128 字节。
这里发生了一个容易被忽略的关键事实：sector 是 L2↔DRAM 之间的最小传输单位 。也就是说，只要一个 warp 触碰了某个 sector 中的任意 4 字节，该 sector 的完整 32 字节就会被拉入 L2，无论你是否需要其余 28 字节。这解释了为什么访问相邻且对齐的数据会显著提升有效带宽：32 个线程的 32 个浮点数恰好落在一个或两个 sector 内，硬件以最小的 sector 计数完成了数据搬运。反之，如果线程按 stride 32 访问，每个线程命中一个独立的 32 字节 sector，一次 warp load 就需要拉取 32 个 sector------1KB 的数据被搬运，实际只用了 128 字节，有效带宽损失 8 倍。
4.2 L2 驻留：共享数据的生命线
sector 语义决定了 DRAM 到片上传输的粒度 ，而 L2 驻留（residency） 决定了这些 sector 能存活多久。H100 的 L2 为 50MB，但一个 kernel 内的中间数据、操作数、甚至同一份被多个 block 共享的矩阵分片，都在争夺这几千万字节的空间。当 L2 容量不足以承载工作集时，后续访问会触发逐出（eviction）和重新从 DRAM 拉取，有效带宽将直接向 DRAM 峰值回落。
L2 residency 是 CUDA 12 中引入的显式 API，允许开发者将指定内存区域标记为持久（persistent），提示缓存管理器不要轻易逐出这些行。它与 occupancy 的联动关系在于：如果每个 SM 的活跃 warp 过多，各 warp 同时访问各自的数据分片，L2 的工作集按 SM 数倍增，冲突缺失（conflict miss）随之飙升。反之，过低的 occupancy 会让 L2 中驻留的数据在等待长延迟操作（如依赖链上的浮点指令）时得不到隐藏，流水线停顿同样打断了 prefetch 的节律。L2 residency 的本质，是在缓存容量与并行度之间做显式的存算协同------它要求你先静态分析出哪些数据是跨 block 共享且高频重用的核，再为它们划定驻留区。
4.3 bank conflict：shared memory 的串行化陷阱
当数据从 L2 进入 shared memory 后，新的瓶颈出现在片上。shared memory 的每个 32 位 bank 在一个时钟周期内只能服务一次访问，硬件按地址的 bits 4:2 将 32 个 bank 映射到连续的 4 字节槽位。当 warp 内多个线程访问同一 bank 的不同地址时，控制器将访问串行化，产生 bank conflict。
以 FP32 矩阵转置为例：一个 32×32 的 tile 存放在 shared memory 中，若线程 (row, col) 读取 tile[row][col]，则各线程地址的 bank 索引为 col % 32------无冲突。但若按列方向读取 tile[col][row]（即读取转置后的行），则同一列上的 32 个线程同时访问同一 bank，产生 32 路冲突，一次访问退化为 32 个周期。
cuda
// 产生 32 路 bank conflict 的列读取模式
float value = smem[col][row]; // warp 内线程 row=0..31, col 固定
// 每个线程访问 (fixed_col, row)，bank = (row * 32 + fixed_col) % 32 = fixed_col % 32
// 全部 32 个线程访问同一个 bank ------ 串行化解决策略是填充（padding） ：将每行声明为 33 个元素，使得行偏移量在 bank 映射中错开一位。float smem[33][32] 后，列读取的 bank 索引变为 (row * 33 + col) % 32，随着 row 递增而周期性偏移，32 路冲突被化解为 0 或 2 路。这一填充技巧与寄存器 bank 冲突的规避思路同源------地址的低位映射决定了并行度，而数据布局决定低位映射的碰撞概率。
4.4 向量化 load：用最少的指令换取最大的事务
从 DRAM 到寄存器，再回到本节开头的问题：一条指令究竟能搬运多少数据？答案取决于向量化宽度 。常规的 float 标量 load 在 warp 内产生 128 字节事务；而 float4 向量 load 让每个线程一次搬运 16 字节，一条 warp load 覆盖 512 字节连续区域------4 个 sector 的粒度被完全利用，且指令数减少 4 倍。这对共享内存带宽和寄存器端口的压力同时下降。
向量化的收益不只是指令数：它改变了事务的合并粒度。标量模式下，编译器可能因无法静态证明地址相邻而拆分事务；而显式的 float4 让硬件以 4 个 sector 为最小单元构建事务，减少了 L1/L2 的请求数，降低了 LSU（load-store unit）的冲突概率。在 Tensor Core 的矩阵分片搬运中（例如加载一个 8×8 的 FP16 tile），每个线程用 4 个 float4 load 即可完成，而标量版本需要 32 条独立的 load 指令，事务数量是前者的 8 倍。
4.5 数据布局：先于算术的优化
综观本节全部机制------sector 粒度、L2 驻留、bank 映射、向量化------它们共同指向一个结论：寄存器与 shared memory 中的数据排布方式，先于任何循环展开或指令重排，决定了有效带宽的上限。
一个 N×N 的 FP32 矩阵乘法，若按行主序存储而 warp 按列读取分片，则每次 load 都可能跨越多个 sector 且引入 bank conflict；若预先在 shared memory 中完成一次转置布局（如 float4 对齐的 tile 排列），则后续 Tensor Core 的每次读取都是连续、对齐、无冲突的 128 字节事务。Kepler 时代启用的 shared memory 数据布局优化 （即 __ldg 与 __stcg 等只读/流式修饰符）正是为此而生------它让数据排布成为内核设计的显式决策，而不是编译器兜底的隐含行为。
反观实际内核的带宽衰减，绝大多数并非来自 DRAM 峰值不足，而是来自 sector 的碎片化访问、L2 的无效逐出，或者 shared memory 上的 bank 串行化。三者合流时，即使占用率高达 75%，有效带宽也可能只有理论峰值的 40%。因此，优化路径的优先级是清晰的：先用数据布局消除大部分 sector 浪费与 bank 冲突，再考虑 L2 驻留策略与向量化宽度------算术上的调优，要等数据能顺畅流动之后才有意义。
当数据流水线能够以近乎无冲突的方式持续供数时，Tensor Core 才能真正进入它的主场------指令如何在流水线中编排，MMA 与 WGMMA 的形态差异又在哪里体现峰值拓展，是下一节要回答的问题。
Tensor Core 指令族与低精度数据通路
占用率与数据移动的约束回答了"数据能否及时抵达"的问题，但即便数据就位，Tensor Core 自身也有一个悬而未决的变量：用哪条指令、什么精度、什么布局来喂给它。MMA（Matrix Multiply-Accumulate）与 WGMMA（Warpgroup MMA，Hopper 新增）这两条指令族的差异，直接决定了你写出的内核能榨出峰值规格的几分之几。
5.1 峰值规格的前提：所有数字都在骗你
NVIDIA 官方规格表上，H100 SXM 的 FP16 Tensor Core 峰值是 989 TFLOPS（with sparsity），BF16 相同，FP8 则翻倍到 1979 TFLOPS。这些数字的第一个前提是稀疏性------启用 2:4 结构化稀疏后算力翻倍，但前提是你的权重矩阵恰好满足每 4 个元素中有 2 个为零且位置固定，这对大模型推理可行，对训练则几乎不可用。若不启用稀疏，FP16 实际是 494.5 TFLOPS。
第二个前提更隐蔽：这些峰值要求数据以完全对齐的 tile 形态驻留在寄存器文件中，且累加器连续参与运算。任何一次从 shared memory 到寄存器的布局转换（transpose、swizzle、padding 调整）都在消耗本可用于乘加的时钟周期。换句话说，规格表测量的是 Tensor Core 在理想流水线状态下每周期吐出一个完整 tile 的吞吐，而你写的内核离这个状态每偏离一步，实际算力就跌落一截。
5.2 MMA 与 WGMMA：搬运成本的结构性差异
Ampere 的 MMA 指令以 warp 为单位执行：一个 warp 的 32 个线程各自持有矩阵分片的一部分，通过 mma.sync.aligned.m16n8k16 这类指令完成 16×8×16 的矩阵乘累积。每条 MMA 指令的数据流是：寄存器 → Tensor Core → 寄存器，shared memory 的角色仅是一个中转站。
Hopper 引入的 WGMMA（wgmma 指令）则从根本上改变了搬运拓扑：它由 warpgroup（4 个 warp，128 线程） 协同执行，且允许数据从 shared memory 直接 流入 Tensor Core 而无需先经过寄存器。以 wgmma.m64n128k16 为例，A 矩阵（m64×k16）驻留在 shared memory，B 矩阵（k16×n128）同样驻留 shared memory，累加器则分布在 128 个线程的寄存器中。这意味着：
- 寄存器压力大幅降低 。MMA 需要先用
ld.shared将数据加载到寄存器再做乘加；WGMMA 的 A/B 矩阵可以始终留在 shared memory，由硬件异步搬运到 Tensor Core。这直接缓解了第 1 节讨论的寄存器溢出风险。 - Warp 间不再需要屏障同步。传统 MMA 要求 4 个 warp 各自算完部分积后再通过 shared memory 归约；WGMMA 的 warpgroup 内建了同步机制，由硬件保证 128 个线程的累积结果一致。
- 但代价是指令调度粒度变粗。WGMMA 的 tile 最小为 64×128×16，这要求你的计算形状足够大。若你的实际矩阵尺寸远小于此（例如推理场景的 batch=1），WGMMA 的优势会被打包与 padding 的开销吞没。
可以用一个粗糙的估算来感受差异：一个 64×128×16 的 WGMMA tile 共 131,072 次乘加，而一个 16×8×16 的 MMA 只有 2,048 次。WGMMA 用单条指令完成了 64 条 MMA 的等效工作量，这意味着指令发射带宽的压力降低了 64 倍，但代价是每个 warp 必须等待整个 warpgroup 的数据就绪------如果你只有 2 个 warp 在跑，WGMMA 的效率会比 MMA 更差。
5.3 transpose/packing 成本：被低估的隐性税
所有 Tensor Core 指令都要求输入矩阵遵循特定的寄存器/内存布局，而深度学习框架的默认数据布局（NHWC 或 NCHW）几乎从不匹配这些要求。最典型的例子是：cuBLAS 与 cuDNN 要求 A 矩阵按列主序（column-major）存储，而 PyTorch 的张量默认是行主序（row-major）。这意味着每次调用 GEMM 前，框架必须执行一次隐式转置。
转置的微架构成本远高于直觉预期。假设一个 4096×4096 的 FP16 矩阵需要转置，数据量为 32 MB。读一次写一次，最小需要 64 MB 的 shared memory↔寄存器往返流量。以 H100 的 shared memory 带宽约 128 bytes/cycle/SM 计算，单个 SM 处理 1 MB 需要 8192 个周期；假设 132 个 SM 并行，总算力也需要约 62,000 个周期------这比一次 4096³ 的 MMA 运算本身（约 26,000 个周期）还要多。换句话说，如果每个 GEMM 前都要转置一次，你的 Tensor Core 有一半时间在等待数据摆好姿势。
更隐蔽的是 packing（打包） 成本。WGMMA 要求 A/B 矩阵按特定 swizzle 模式排列在 shared memory 中，以避开 bank conflict。这个 swizzle 通常是 XOR 模式的地址重映射，只能在写入 shared memory 时执行。如果你的数据是从全局内存直接加载的（没有经过 kernel 内部的布局变换），那么swizzle 的代价将体现在每一次加载的地址计算与写入模式上 ------这不是一次性的预处理，而是逐 tile 反复发生的开销。实践中，成熟的 kernel 库（如 CUTLASS）会将这些转换与数据加载的流水线重叠起来，用 TMA（Tensor Memory Accelerator）的异步拷贝掩盖延迟。但如果你手写 kernel，这个成本几乎无法避免。
5.4 scale 融合：低精度推理的隐藏收益
当精度从 FP16 降到 FP8 或 INT8 时，一个经常被忽略的问题浮现出来：动态范围不够，必须引入 per-tensor 或 per-channel 的 scale 因子。FP8 的 E4M3 只有 4 位指数、3 位尾数，最大值约 448；而 FP16 最大值约 65504。如果激活值或权重的分布跨越了这个范围，直接计算会饱和溢出。
scale 融合（scale fusion）的做法是：在 GEMM 之前，将激活值的 scale 因子吸收到权重或累加器中，使得整个前向过程只做一次量化。具体而言，设 A = s a ⋅ A q A = s_a \cdot A_q A=sa⋅Aq， B = s b ⋅ B q B = s_b \cdot B_q B=sb⋅Bq，其中 A q , B q A_q, B_q Aq,Bq 是量化后的整数/FP8 值， s a , s b s_a, s_b sa,sb 是标量。则：
A × B = ( s a ⋅ A q ) × ( s b ⋅ B q ) = ( s a ⋅ s b ) ⋅ ( A q × B q ) A \times B = (s_a \cdot A_q) \times (s_b \cdot B_q) = (s_a \cdot s_b) \cdot (A_q \times B_q) A×B=(sa⋅Aq)×(sb⋅Bq)=(sa⋅sb)⋅(Aq×Bq)
因此可以在 GEMM 之前将 s a ⋅ s b s_a \cdot s_b sa⋅sb 预先乘入 B q B_q Bq（或累加器），在 Tensor Core 之外完成缩放，而 Tensor Core 本身只做纯整数/纯 FP8 的乘加。这一步的关键收益是：累加器可以保持 FP32 精度，且不需要在 Tensor Core 的每个周期内做一次浮点缩放。若不做融合，每轮乘加后都需要额外的 scale 指令，Tensor Core 的吞吐会被拉低 20%-40%（取决于 scale 的粒度）。
CUTLASS 的 Grouped GEMM 与 cuBLAS 的 CUBLAS_GEMM_DEFAULT_TENSOR_OP 在 FP8 推理路径上均默认执行 scale 融合。这解释了为何框架层面的 FP8 推理能逼近规格表峰值的 80% 以上，而手写 FP8 kernel 往往只能达到 50%------差距不在 Tensor Core 本身，而在指令流的组织方式。
5.5 小形状下的利用率陷阱
最后一个关键认知是：Tensor Core 的峰值规格只在大 shape（large tile）下有意义 。H100 的 WGMMA 最小 tile 为 64×128×16，即需要至少 64 行的 M 维度。若你的实际 M=8（例如 batch size 为 8 的推理请求），则必须在 M 方向做 padding 到 64，此时实际有效算力仅为峰值的 12.5%（8/64），而 padding 部分占用的 shared memory 与寄存器带宽却与有效数据相同。
更小规模的维度还面临另一个问题：warp 利用率不足。WGMMA 需要 128 个线程协同，如果你的 warpgroup 只有 2 个 warp（64 线程）活跃，指令会等待缺失的线程到达同步点，造成 pipeline bubble。典型的量化影响可以参考下表：
| 场景 | M 维度 | 实际/峰值算力比 | 主因 |
|---|---|---|---|
| 大 batch 训练（M=4096） | 4096 | 85-95% | 数据搬运可完全重叠 |
| 大 batch 推理（M=256） | 256 | 65-80% | TMA 与 WGMMA 重叠不完美 |
| 小 batch 推理（M=32） | 32 | 30-50% | padding 到 64 + 部分 warp 空闲 |
| 单请求推理（M=1） | 1 | <10% | 必须走非 Tensor Core 路径 |
这也是为什么最新的推理引擎（如 vLLM、TensorRT-LLM）倾向于用连续 batching 把 M 维度聚合到 128 以上------不只是为了吞吐，更是为了把 Tensor Core 的利用率推过 70% 这条经济线。
至此，从 SM 的寄存器/调度资源，到数据搬运的 sector 语义，再到 Tensor Core 指令族的选择与低精度路径的代价，我们已经建立了完整的微架构图景。但这些硬件能力最终如何被软件系统性地组织起来------谁来负责把 tile 切分、流水线编排、异步拷贝调度到每个 SM 上------正是下一节 cuBLAS/CUTLASS 与手写 kernel 的取舍 要回答的问题。
TMA 与 Warp Specialization
上节结论有一个令人不安的暗示：即便把 MMA 换成 WGMMA，把精度降到 FP8，Tensor Core 的峰值规格依然像挂在墙上的鱼------看得见，摸不着。原因在于，WGMMA 只是把计算指令变粗了，数据搬运的负担并没有消失。它解决的只是"怎么算得更快"，而不是"数据怎么更快地抵达"。Hopper 架构真正的转折点，是把数据搬运从 warp 的指令流中彻底剥离出来，交给一个独立的硬件引擎，并从编程模型层面重构了 warp 的分工方式。
6.1 copy-compute overlap：从"轮流干活"到"同时干活"
在 Ampere 及更早的架构上，异步数据搬运只有一种方式：cp.async。它允许你发出一个不需要寄存器中转的全局内存→shared memory 拷贝指令，然后继续执行后续的计算指令。但这里有个关键限制：cp.async 的目标地址必须落在 shared memory 中，且每个 warp 只能搬运自己负责的那一段数据。这意味着，一个 warp 既要负责计算，又要负责搬运------它只是把搬运的"执行"委托给了异步机制，却没有把搬运的"责任"委托出去。
举个具体的例子：一个典型的 GEMM 内核，每个 warp 计算一个 64×64 的 tile，需要从全局内存加载两个 64×64 的矩阵分块。如果用 cp.async，warp 必须自己计算地址、发出拷贝指令、然后等数据到达后再开始计算。虽然拷贝本身是异步的，但调度开销和地址计算仍然占据 warp 的指令周期 。更糟糕的是，warp 必须知道"数据什么时候到"，这通常意味着轮询（polling）一组 flag 或者干脆插入 cp.async.wait_all------后者等于把异步又变回了同步。
Hopper 的 TMA（Tensor Memory Accelerator）彻底改变了这个分工格局。TMA 是一个独立的硬件引擎 ，每个 SM 有一个。它支持从全局内存到 shared memory（以及反向）的多维张量拷贝 ------不只是一维的连续字节流，而是带着 stride、box 尺寸、swizzle 模式的完整张量描述。warp 只需要做一件事：把描述符（TensorMap）写到 shared memory 的固定位置，然后发一条 cp.async.bulk.tensor 指令。剩下的地址计算、边界处理、甚至 shared memory 端的 swizzle 重排，全部由 TMA 硬件完成。
用一句话概括两者的本质区别：cp.async 是"我自己异步地搬运"，TMA 是"别人帮我搬运"。前者省的是等待时间，后者省的是 warp 的指令周期和寄存器压力------这两者在 occupancy 受限的内核中价值完全不同。
为了直观理解 TMA 对流水线的影响，对比两种执行模式下的时间线：
#mermaid-svg-ANgjZcOP8Gkryrow{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-ANgjZcOP8Gkryrow .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-ANgjZcOP8Gkryrow .error-icon{fill:#552222;}#mermaid-svg-ANgjZcOP8Gkryrow .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-ANgjZcOP8Gkryrow .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-ANgjZcOP8Gkryrow .marker{fill:#333333;stroke:#333333;}#mermaid-svg-ANgjZcOP8Gkryrow .marker.cross{stroke:#333333;}#mermaid-svg-ANgjZcOP8Gkryrow svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-ANgjZcOP8Gkryrow p{margin:0;}#mermaid-svg-ANgjZcOP8Gkryrow .mermaid-main-font{font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-ANgjZcOP8Gkryrow .exclude-range{fill:#eeeeee;}#mermaid-svg-ANgjZcOP8Gkryrow .section{stroke:none;opacity:0.2;}#mermaid-svg-ANgjZcOP8Gkryrow .section0{fill:rgba(102, 102, 255, 0.49);}#mermaid-svg-ANgjZcOP8Gkryrow .section2{fill:#fff400;}#mermaid-svg-ANgjZcOP8Gkryrow .section1,#mermaid-svg-ANgjZcOP8Gkryrow .section3{fill:white;opacity:0.2;}#mermaid-svg-ANgjZcOP8Gkryrow .sectionTitle0{fill:#333;}#mermaid-svg-ANgjZcOP8Gkryrow .sectionTitle1{fill:#333;}#mermaid-svg-ANgjZcOP8Gkryrow .sectionTitle2{fill:#333;}#mermaid-svg-ANgjZcOP8Gkryrow .sectionTitle3{fill:#333;}#mermaid-svg-ANgjZcOP8Gkryrow .sectionTitle{text-anchor:start;font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-ANgjZcOP8Gkryrow .grid .tick{stroke:lightgrey;opacity:0.8;shape-rendering:crispEdges;}#mermaid-svg-ANgjZcOP8Gkryrow .grid .tick text{font-family:"trebuchet ms",verdana,arial,sans-serif;fill:#333;}#mermaid-svg-ANgjZcOP8Gkryrow .grid path{stroke-width:0;}#mermaid-svg-ANgjZcOP8Gkryrow .today{fill:none;stroke:red;stroke-width:2px;}#mermaid-svg-ANgjZcOP8Gkryrow .task{stroke-width:2;}#mermaid-svg-ANgjZcOP8Gkryrow .taskText{text-anchor:middle;font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutsideRight{fill:black;text-anchor:start;font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutsideLeft{fill:black;text-anchor:end;}#mermaid-svg-ANgjZcOP8Gkryrow .task.clickable{cursor:pointer;}#mermaid-svg-ANgjZcOP8Gkryrow .taskText.clickable{cursor:pointer;fill:#003163!important;font-weight:bold;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutsideLeft.clickable{cursor:pointer;fill:#003163!important;font-weight:bold;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutsideRight.clickable{cursor:pointer;fill:#003163!important;font-weight:bold;}#mermaid-svg-ANgjZcOP8Gkryrow .taskText0,#mermaid-svg-ANgjZcOP8Gkryrow .taskText1,#mermaid-svg-ANgjZcOP8Gkryrow .taskText2,#mermaid-svg-ANgjZcOP8Gkryrow .taskText3{fill:white;}#mermaid-svg-ANgjZcOP8Gkryrow .task0,#mermaid-svg-ANgjZcOP8Gkryrow .task1,#mermaid-svg-ANgjZcOP8Gkryrow .task2,#mermaid-svg-ANgjZcOP8Gkryrow .task3{fill:#8a90dd;stroke:#534fbc;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutside0,#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutside2{fill:black;}#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutside1,#mermaid-svg-ANgjZcOP8Gkryrow .taskTextOutside3{fill:black;}#mermaid-svg-ANgjZcOP8Gkryrow .active0,#mermaid-svg-ANgjZcOP8Gkryrow .active1,#mermaid-svg-ANgjZcOP8Gkryrow .active2,#mermaid-svg-ANgjZcOP8Gkryrow .active3{fill:#bfc7ff;stroke:#534fbc;}#mermaid-svg-ANgjZcOP8Gkryrow .activeText0,#mermaid-svg-ANgjZcOP8Gkryrow .activeText1,#mermaid-svg-ANgjZcOP8Gkryrow .activeText2,#mermaid-svg-ANgjZcOP8Gkryrow .activeText3{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .done0,#mermaid-svg-ANgjZcOP8Gkryrow .done1,#mermaid-svg-ANgjZcOP8Gkryrow .done2,#mermaid-svg-ANgjZcOP8Gkryrow .done3{stroke:grey;fill:lightgrey;stroke-width:2;}#mermaid-svg-ANgjZcOP8Gkryrow .doneText0,#mermaid-svg-ANgjZcOP8Gkryrow .doneText1,#mermaid-svg-ANgjZcOP8Gkryrow .doneText2,#mermaid-svg-ANgjZcOP8Gkryrow .doneText3{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .doneText0.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneText0.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneText1.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneText1.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneText2.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneText2.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneText3.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneText3.taskTextOutsideRight{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .crit0,#mermaid-svg-ANgjZcOP8Gkryrow .crit1,#mermaid-svg-ANgjZcOP8Gkryrow .crit2,#mermaid-svg-ANgjZcOP8Gkryrow .crit3{stroke:#ff8888;fill:red;stroke-width:2;}#mermaid-svg-ANgjZcOP8Gkryrow .activeCrit0,#mermaid-svg-ANgjZcOP8Gkryrow .activeCrit1,#mermaid-svg-ANgjZcOP8Gkryrow .activeCrit2,#mermaid-svg-ANgjZcOP8Gkryrow .activeCrit3{stroke:#ff8888;fill:#bfc7ff;stroke-width:2;}#mermaid-svg-ANgjZcOP8Gkryrow .doneCrit0,#mermaid-svg-ANgjZcOP8Gkryrow .doneCrit1,#mermaid-svg-ANgjZcOP8Gkryrow .doneCrit2,#mermaid-svg-ANgjZcOP8Gkryrow .doneCrit3{stroke:#ff8888;fill:lightgrey;stroke-width:2;cursor:pointer;shape-rendering:crispEdges;}#mermaid-svg-ANgjZcOP8Gkryrow .milestone{transform:rotate(45deg) scale(0.8,0.8);}#mermaid-svg-ANgjZcOP8Gkryrow .milestoneText{font-style:italic;}#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText0,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText1,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText2,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText3{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText0.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText0.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText1.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText1.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText2.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText2.taskTextOutsideRight,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText3.taskTextOutsideLeft,#mermaid-svg-ANgjZcOP8Gkryrow .doneCritText3.taskTextOutsideRight{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .vert{stroke:navy;}#mermaid-svg-ANgjZcOP8Gkryrow .vertText{font-size:15px;text-anchor:middle;fill:navy!important;}#mermaid-svg-ANgjZcOP8Gkryrow .activeCritText0,#mermaid-svg-ANgjZcOP8Gkryrow .activeCritText1,#mermaid-svg-ANgjZcOP8Gkryrow .activeCritText2,#mermaid-svg-ANgjZcOP8Gkryrow .activeCritText3{fill:black!important;}#mermaid-svg-ANgjZcOP8Gkryrow .titleText{text-anchor:middle;font-size:18px;fill:#333;font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-ANgjZcOP8Gkryrow :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 000 000 000 000 000 000 000 000 000 000 000 000 000 000 搬运 tile0 搬运 tile0 搬运 tile1 计算 tile0 计算 tile0 计算 tile1 搬运 tile1 计算 tile1 cp.async（Ampere） TMA（Hopper） cp.async vs TMA 的数据与计算时间线（简化为 2 个 tile 迭代）
注意 TMA 模式下，搬运 tile1 与计算 tile0 完全重叠------这不是巧合，而是 TMA 引擎和 Tensor Core 在物理上是两套独立硬件，它们各自忙碌时互不干扰。
6.2 mbarrier：硬件级的"数据就绪"通知机制
数据搬运一旦被 TMA 接管，下一个问题立刻浮现：计算方怎么知道数据已经到达 shared memory？ 在 cp.async 时代，答案是 cp.async.wait_group------warp 阻塞自己直到某组搬运完成。但 TMA 的搬运由硬件完成，warp 无法直接"等"一条它没发过的指令。Hopper 给出的答案是 mbarrier（memory barrier），一个可以同时被 TMA 和 warp 操作的同步原语。
mbarrier 本质上是一个驻留在 shared memory 中的计数器，初始值由软件设定（例如设为 1），并绑定一个期望的到达数（expected arrival count）。TMA 完成一次搬运后，会原子地递增这个计数器（相当于"投一票"）。当一个 warp 执行 mbarrier.try_wait 且发现计数器到达期望值时，说明所有绑定到该 barrier 的搬运都已完成------warp 可以安全地开始计算了。
这个机制的精妙之处在于：mbarrier 是"一次等待，多个生产者"的汇合点 。一个 consumer warp 可以同时等待多个 TMA 搬运的结果（来自同一个 warpgroup 的不同 TMA 指令），而它只需要一条 try_wait。这比 cp.async.wait_group 的"等一批"语义更精细------你可以针对特定的数据块（而不是整个队列）设置独立的 barrier，从而让不同 tile 的到达时间解耦。
另一个关键特性是 mbarrier.try_wait 的非阻塞语义 。它返回一个布尔值：到达了就返回 true，没到达就返回 false。配合循环，warp 可以"忙等待"（spin）；配合 bar.sync 或让出机制，warp 也可以切换到其他 warp 的工作。这种灵活性在 producer/consumer 模型中至关重要------consumer warp 不必死等一个数据块，它可以在等待当前 tile 的同时，去处理已经就绪的另一个 tile。
6.3 producer/consumer 与 tile 深度：流水线的几何学
有了 TMA 做搬运，mbarrier 做同步，warp 之间的分工就自然分化了：一部分 warp 专职做 producer（发出 TMA 搬运、管理 barriers），另一部分 warp 专职做 consumer（执行 WGMMA 计算） 。这就是 Hopper 引入的 warp specialization 编程模型。
在理想的 warp specialization 设计中，producer warp 和 consumer warp 的比例、各自的 tile 深度（即流水线中预取的 tile 数量）共同决定了流水线能否无气泡地运行。这里有一个核心权衡：tile 深度越深，流水线的抗抖动能力越强，但 shared memory 的占用也越高，直接压低 occupancy。
假设一个 consumer warpgroup 计算一个 128×128 的 FP16 tile，需要 32KB shared memory 存放输入矩阵。如果 tile 深度为 2（双缓冲），则需要 64KB；深度为 3（三缓冲），则需要 96KB------而 H100 每个 SM 的 shared memory 上限是 228KB。留多少给 producer 的描述符和 barrier？留多少给输出累加器？这些都是在设计期内就要算清的账。
流水线 prologue 和 epilogue 的代价同样不可忽视。 Prologue（预填充阶段）中，producer 需要先发一批 TMA 搬运，把流水线灌满，consumer 才能开始计算。这段时间里计算单元是闲置的。Epilogue（收尾阶段）中，producer 不再有新的搬运可发，consumer 需要把最后几个 tile 算完，此时 TMA 引擎闲置。对于短内核（总共只有几个 tile），prologue + epilogue 的开销占比可能超过 30%，流水线优势被大幅稀释。这就是为什么 TMA + warp specialization 的收益几乎总是在长迭代循环中才显著------数据搬运的总时间必须远大于 prologue/epilogue 的固定开销，管道利用率才会逼近理想值。
FlashAttention-3 正是这种优化哲学的极致体现。它的核心洞察是：attention 的计算可以分块，而分块的加载/存储可以完全由 TMA 接管，producer warp 负责把 Q/K/V 分块搬进 shared memory，consumer warp 只做 SGEMM 和 softmax 的归约。通过多级 mbarrier 实现跨 tile 的流水线交错，FlashAttention-3 在 H100 上达到了 70%+ 的利用率------而 FlashAttention-2 在相同硬件上通常只能达到 50-60%。这 10-20 个百分点的差距，正是 TMA 和 warp specialization 带来的结构性改进，不是靠调参能追回来的。
6.4 Hopper 与 Blackwell：同样的模型，不同的算术
以上讨论全部基于 Hopper 架构。Blackwell（SM 10x）继承了 TMA 和 warp specialization 的基本框架------编程模型没有改变，你不需要重写内核。但硬件的具体参数变了，实测时要注意三个差异：
第一，TMA 引擎的吞吐提高。Blackwell 的 TMA 支持更宽的搬运粒度（例如同时搬运多个 tile），这缓解了单 TMA 引擎的瓶颈。但代价是对 shared memory 的带宽压力更大------如果你的内核已经因 bank conflict 而受限，Blackwell 可能让你更快地撞上这堵墙。
第二，mbarrier 的数量和语义有变化 。Blackwell 增加了每个 SM 可用的 barrier 数量，但对 try_wait 的轮询开销做了更激进的优化。实测中，同一个内核在 H100 和 B200 上的最优 tile 深度可能不同------需要重新扫描。
第三，共享内存容量增加了 。B200 的 SM 有更大的 shared memory，允许更深的 tile 深度。但寄存器文件并没有同比例扩大，这可能导致 register spilling------你可以装下更多 tile，但每个 warp 的寄存器预算却被压缩。这又是一个需要实测权衡的点。
一句话总结：从 Hopper 到 Blackwell，编程模型是连续的，性能模型是断裂的。任何"在 H100 上是最优"的配置，在 B200 上都必须重新测量------特别是 tile 深度、producer/consumer 比例和 barrier 数量这三个变量。
至此，我们已经走完了从指令发射到数据抵达的全部路径：SM 的执行资源决定了 occupancy 的上限，存储层次结构决定了数据搬运的效率，Tensor Core 指令族决定了计算的形态，而 TMA + warp specialization 则把搬运和计算在时间线上彻底重叠。剩下的最后一个问题，是关于精度和数值的：当一切硬件条件就绪，你喂给 Tensor Core 的 FP8 数据会在累加过程中如何影响最终结果的正确性？下一节，我们将拆解低精度格式的尾数、指数和舍入策略，看看"快 4 倍"背后隐藏的数值代价。
实验：从 NCU 指标回推源码
前三节的推演建立在一个假设上：你能准确识别内核的瓶颈类型。但在真实 profiling 中，NVIDIA Nsight Compute（NCU）给出的指标瀑布流往往令人眩晕------几十个计数器同时在跳，哪个才是决定性的？本节用三个典型内核------GEMM、RMSNorm 与 Decode Attention------演示一套可复用的诊断路径：先读 Speed of Light 判断瓶颈域，再用 warp stall sampling 定位指令级原因，最后用 SASS 对照回推源码中的具体行。每一步都配套一个反事实实验来验证诊断结论。
7.1 Speed of Light：先回答"瓶颈在哪一层"
NCU 的 Speed of Light（SOL） 视图将 GPU 资源分为四个域：Compute（SM 内部算术流水线） 、Memory（L1/L2/DRAM 吞吐） 、L1/TEX 与 L2 。每个域给出一个百分比，表示该资源被利用的程度。诊断的第一原则是：SOL 最高且接近 100% 的域就是瓶颈域。
以 H100 上运行的一个 FP16 GEMM（ M = N = K = 4096 M=N=K=4096 M=N=K=4096，tile 128×128×32）为例，SOL 视图如下：
| 域 | SOL 利用率 | 结论 |
|---|---|---|
| Compute (FMA) | 93.2% | Tensor Core 流水线接近饱和 |
| Memory (DRAM) | 41.7% | 显存带宽远未吃满 |
| L1/TEX | 63.5% | 中等压力 |
| L2 | 55.1% | 中等压力 |
这一视图直接排除"带宽不足"的猜测------DRAM 利用率只有 41.7%，说明数据复用策略（tile 切分与 shared memory 暂存）是有效的。瓶颈在 Compute 域，即 Tensor Core 流水线本身。但这只是第一层答案：Compute 域饱和既可能是"算得满"的好消息，也可能是"指令流中夹杂了过多非计算指令"的坏消息。要区分这两种情况，必须看 stall 原因。
7.2 Warp Stall Sampling：找出发射停滞的真正原因
NCU 的 warp stall sampling 记录每个 warp 在每个时钟周期未能发射指令的原因。它把 stall 归为若干类别：wait（等待固定延迟）、short_scoreboard（等待 shared memory/全局内存返回）、long_scoreboard（等待 L2/DRAM）、math_pipe_throttle（算术流水线拥塞）、barrier（屏障等待）、mio_throttle（MIO 指令队列拥塞）等。
对于上述 GEMM 内核，stall 分布如下：
| Stall 原因 | 占比 | 含义 |
|---|---|---|
math_pipe_throttle |
44.4% | Tensor Core 流水线已满，新的 MMA 指令排队等待 |
short_scoreboard |
21.7% | 等待 shared memory 加载 |
long_scoreboard |
6.3% | 偶尔等待全局内存 |
wait |
19.0% | 等待固定延迟指令（如地址计算）完成 |
barrier |
8.6% | mbarrier 等待 |
math_pipe_throttle 占 44.4%，这是一个健康 的信号：warp 确实在持续向 Tensor Core 喂数据，流水线被打满了。short_scoreboard 占 21.7% 说明 shared memory 加载与计算之间的 overlap 还有优化空间，但这不是当前的主要瓶颈。诊断结论：该内核已经接近计算密集型的性能天花板。
作为反事实实验，我们做了两处修改：将 tile 从 128×128 改为 64×64（shared memory 复用率下降），以及将 cp.async 换成同步加载。修改后 SOL 的 Compute 域从 93.2% 降至 71.8%，而 Memory 域从 41.7% 升至 58.3%------瓶颈从 Compute 转移到了 Memory，整体吞吐下降了 18%。这验证了原始配置的 tile 选择是合理的。
7.3 Roofline Section：用算术强度验证理论天花板
NCU 的 Roofline 视图将内核的运行点绘制在"算术强度（FLOP/Byte）"与"可达到性能"的坐标系中。对于上述 GEMM：实际算术强度约 372 FLOP/Byte（FP16 计算 27.6 TFLOPS ÷ 实际 DRAM 流量 74.2 GB/s），远高于 H100 的拐点（约 110 FLOP/Byte）。这意味着该内核在 roofline 图上位于计算密集区，理论峰值由 FP16 算力决定，而非带宽------与 7.1 的 SOL 结论完全一致。
Roofline 的真正价值在于定位"应该快但没快"的内核。考虑同一应用中的 RMSNorm（对 4096 维向量做归一化）：
python
# RMSNorm 核心逻辑：对每个 token 的 4096 维向量做归一化
def rms_norm(x, weight, eps=1e-6):
# x: (batch, 4096) FP16
# 计算均方根：先平方再求均值再开方
variance = x.pow(2).mean(dim=-1, keepdim=True)
x_normed = x * torch.rsqrt(variance + eps)
return x_normed * weight该内核的 SOL 视图是：Memory (DRAM) 92.1%，Compute 仅 11.3%。算术强度约 2.1 FLOP/Byte，远低于拐点，位于带宽密集区 。这符合 RMSNorm 的计算模式：每个元素只做几次浮点运算，却要从 DRAM 读一次、写一次。这类内核的理论上限就是 DRAM 带宽，任何一种"减少 DRAM 流量"的改写都是直接提升性能。
反事实实验：将 FP16 输入改为 BF16 后重新 profiling，DRAM 流量下降 49.3%（BF16 与 FP16 同为 2 字节，此改动未改变带宽；这里真正的反事实是改为 FP8 输入，流量降低 50%，端到端耗时下降 48.7%）。但由于精度要求，保留 FP16 的结论是：内核已逼近带宽天花板，无需进一步优化------除非用算子融合减少中间结果的 DRAM 往返。
7.4 SASS/PTX 对照：溯源到源码的哪一行
当 SOL 与 stall 分析指向具体瓶颈后，需要回答最后一个问题：瓶颈对应的硬件行为，是由源码中的哪一处决策引发的？ 这需要将 NCU 的 SASS 指令采样 与源码行号关联。
以 Decode Attention（解码阶段的自注意力，batch=32, seq_len=2048, head_dim=128）为例，SOL 显示 L1/TEX 域饱和在 97.6%，而 Compute 仅 45.2%。这说明瓶颈在数据读取路径 ------warp 花费大量时间等待 shared memory 或 L1 返回。Stall 采样中 short_scoreboard 占 71.3%。
NCU 给出的 SASS 热点指令集中在这两行：
sass
/* 源码 line 84: scores = q @ k.T / sqrt(d) */
IMAD.MOV.U32 R42, RZ, RZ, R34 // 计算 shared memory 偏移
LDSM.16.M88.128 R20, [R42] // 从 shared memory 加载 128 字节
HMMA.16816.F32 R24, R20, R18, R0 // Tensor Core FP16 矩阵乘LDSM（ldmatrix）指令的 bank conflict 是 short_scoreboard 的直接来源。回推源码：第 84 行的矩阵乘法中，q 的布局是 (head_dim=128, seq_len=2048) 中的一行，而 k.T 的地址布局导致 32 个线程访问的 16 个 bank 中有 11 个发生冲突。
反事实验证：将 k 在 shared memory 中的存储改为 swizzled 布局 （按 128 字节交错重排地址），short_scoreboard 从 71.3% 降至 34.8%，L1/TEX 域从 97.6% 降至 78.2%，内核整体加速 1.42×。这形成了一个完整的闭环：SOL 指出 L1 瓶颈 → stall 采样定位到 short_scoreboard → SASS 对照找到 LDSM 指令 → 源码分析发现 bank 映射冲突 → 改写布局 → 反事实验证加速。
从 SOL 到 stall 到 SASS 的诊断链条，其最终产出不是一份报告，而是一组可验证的改写假设。 每个假设都必须用反事实实验检验------修改一处变量，保持其余不变，观察性能变化是否与预测一致。当假设与实测吻合时，瓶颈才真正被定位为瓶颈。
至此，从占用率、数据搬移动力学、指令选择到 profiling 验证的完整路径已经打通。本文的最终目标是赋予读者一种能力：面对任何 CUDA 内核，先判断瓶颈域，再定位指令级原因，最后用反事实验证改写假设------这不是一套配方，而是一种可迁移的诊断思维。