企业官网建设流程全解析

拿到一个运行缓慢的 CUDA 内核，许多人的第一反应是“多加线程”“把循环展开”，结果通常是越调越玄学。真正让我从玄学转向可量化的，是反复使用 Nsight Compute 拉指标，把 GPU 内核的每一步执行拆开来看。Nsight Compute 是 NVIDIA 官方推出的内核级性能分析工具，针对单个 CUDA kernel 做深度 profiling，可以输出 SM 利用率、内存吞吐、Warp 状态、指令发射情况等底层指标。它解决的问题很明确：当你觉得某段 GPU 代码没有发挥出硬件全部实力时，帮助你判断瓶颈到底在计算单元、内存带宽、访存延迟，还是调度开销。适合所有写 CUDA、OpenCL 或做 GPU 计算优化的同学，尤其是 kernel 调优时不知道从哪里入手的人。

这篇内容我是基于实际项目里的调优经历写的。文章不会停留在“打开工具看一眼”的层面，而是把 Nsight Compute 中最常用的一批指标逐个讲清楚：它们叫什么、算的是什么、数值高低意味着什么、能指引你做什么优化。全部都是可以直接复用到你自己项目里的东西。

1. 先搞清楚 Nsight Compute 到底在测什么

1.1 它和 Nsight Systems 的分工

我最早踩过的一个坑，是把 Nsight Systems 当成万能工具，盯着 GPU Utilization 看了半天，发现“GPU 很忙”，但 kernel 依然很慢。后来才明白，Systems 和 Compute 是两个层级完全不同的工具。

用一句话概括分工：Nsight Systems 是应用级/系统级性能分析器，负责看全局时间线、CPU 与 GPU 的同步点、API 调用开销、内存拷贝耗时，它解决的是“整个程序的时间都花在哪了”；Nsight Compute 则是内核级分析器，把一个 kernel 放进“显微镜”里，逐个 SM、逐条指令地分析硬件计数器，解决的是“这个 kernel 为什么没有跑满硬件”。

实际使用中，我通常先把程序丢给 Systems 看整体分布，确认某个 kernel 确实占用大量时间，再切换到 Nsight Compute 对这一个 kernel 做深度剖析。两者是接力关系，不是替代关系。这也解释了很多人的困惑：为什么我用 Systems 看不出某个 kernel 内部的指令效率问题？因为它本来就不管那么细。

1.2 它的核心分析逻辑：三层递进

Nsight Compute 的分析逻辑，我用了几年后总结成三层递进：

第一层，先看 kernel 有没有达到硬件极限，对应的是 Speed Of Light（SOL）分析页面，类似体检报告的总评。第二层，如果没达到极限，判断它卡在哪类资源上，是计算单元饱和了、内存带宽打满了、还是延迟掩盖不足。第三层，结合 Warp Stall 原因、指令统计、源码关联，定位到具体代码行或者某条指令。

这个逻辑非常像医生看病：SOL 是给你量体温、测血压，确认“有问题”；资源分析是拍 CT，看具体哪块组织异常；Warp 状态和指令级指标就是穿刺活检，锁定病灶。你不需要每次都走到第三层，但前两层基本是每次 profiling 必看的。

很多新手容易犯的错误是打开 Nsight Compute 后一头扎进某个生僻指标里埋头研究。建议从一开始就按照三层递进的路子走，先从宏观判断方向，再逐步下钻。如果第一层已经告诉你“所有关键资源都满负荷了”，那就说明 kernel 已经逼近硬件上限，优化空间主要在算法层面而不是微调指令。

2. 最关键的一批指标：SM 利用率与 Speed Of Light

2.1 SM Active Warps 和利用率到底看哪个

“SM 利用率”这个词其实很笼统，NVIDIA 官方指标里真正值得关注的是 Achieved Active Warps Per Scheduler，也就是每个调度器上实际活跃的 warp 数量。GPU 硬件的执行单位是 warp，一个 warp 是 32 个线程，调度器负责把 warp 派发给对应的执行单元。

以 A100 为例，每个 SM 有 4 个 warp scheduler，每个 scheduler 最多管理 16 个 warp，SM 层面最大同时驻留 64 个 warp。Nsight Compute 会把这个数量以平均活跃 warp 数的形式展示出来，再除以理论最大值得到一个百分比。

这个百分比反映的是“硬件上有多少并行任务可以被调度器拿来填满流水线”。如果 Achieved Occupancy 只有 30%，那么即使计算单元规格再高，也可能因为可用 warp 太少而无法隐藏延迟，导致很多执行单元在空转等待。反过来说，如果这个数值已经接近 90% 以上，说明 SM 层面已经塞得很满，这时候性能瓶颈大概率不在占用率，而在具体的执行流水线或内存子系统。

2.2 SOL 分析图怎么看：颜色和柱状图

SOL 页面是 Nsight Compute 里最直观也最容易被误读的部分。它分为两个主区域：Compute Workload Analysis 和 Memory Workload Analysis。每个区域里会展示对应硬件单元（比如 FMA 管线、ALU 管线、LSU 管线、L1/TEX 缓存、L2 缓存、DRAM）的利用率百分比。

颜色越深代表利用率越高，深红色基本表示对应硬件已经接近满负荷运行，也就是当前瓶颈所在；浅色则表示资源大部分时间在空闲。这个设计非常像 CPU 调优里的 hotspot 分析，你只需要第一时间找出“最深的那根柱子”。

注意一个细节：SOL 图中的百分比都是相对“峰值理论性能”计算的，不同硬件架构的峰值定义不同。所以不要拿着 A100 的 SOL 数据去对照 V100 或者 RTX 3090 的绝对值，跨架构比较意义不大。重要的是看你自己这个 kernel 在不同硬件单元之间的相对关系。

2.3 判断计算密集还是内存密集

SOL 页面最核心的用途，是快速判断一个 kernel 到底是 compute-bound 还是 memory-bound。如果在 Compute Workload Analysis 中，FMA Pipe 或者 ALU Pipe 利用率已经到 90% 以上，而右侧 Memory Workload Analysis 里的 DRAM 利用率只有 20%，那么这是一个典型的计算密集 kernel。优化方向应该放在减少冗余计算、提高指令级并行、考虑使用更快的数学指令（如 __fdividef、fast math）等。

反过来，如果 DRAM 吞吐已经顶到接近带宽上限，而左侧 SM 计算单元利用率普遍不到 50%，那就是内存带宽瓶颈。此时最有效的优化是改善访存合并、提高数据复用、增加 L2 命中率、分块处理数据等。千万不要在 memory-bound 的 kernel 上花大量时间去抠指令重排，那是南辕北辙。

还有一个容易被忽略的中间态：既不是计算密集也不是带宽密集，而是延迟密集。表现为 SOL 两侧利用率都不高，SM 计算单元和内存都没打满，但 Achieved Occupancy 偏低、Warp State 里占满 Long Scoreboard 等待。这种情况靠增加并行度来掩盖延迟通常是第一优先级。

3. Occupancy、Warp Stall 与指令级指标

3.1 Occupancy 别被它骗了

Occupancy 是 Nsight Compute 里最常被引用的指标之一，但我越来越倾向于提醒别人：它重要，但不是越高越好。

从定义上看，Achieved Occupancy 是“每个 SM 上同时驻留的实际 warp 数 / SM 最大可驻留 warp 数”。这个数值高，意味着 SM 里“排队等待”的 warp 多，调度器有更多选择来隐藏各种延迟。数值低，则往往意味着硬件资源没有被填满。

但高 Occupancy 不一定带来高性能。举个例子，一个纯计算密集的 kernel，每个线程需要大量寄存器。如果为了强行提高 Occupancy 而把 block 尺寸调小以匹配寄存器数量，反而可能导致每个线程可用寄存器不足，产生 register spilling（寄存器溢出到 local memory）。local memory 物理上是放在全局内存里的，访问速度比寄存器慢几个数量级，性能损失远大于 Occupancy 提升带来的收益。

Nsight Compute 的 GUI 里提供了 Launch Configuration 分析，可以交互式调整 block size、grid size、共享内存分配量，预览 Occupancy 变化。我每次调 launch 参数都会先用这个页面预估一下，确认不会触发寄存器溢出再实际编译测试。

3.2 Warp State 里的 Stall 原因怎么读懂

Warp State 统计是 Nsight Compute 里信息密度最高、也最难快速上手的部分。它统计的是每个 warp 在周期内的状态分布，核心看点是 Stall 原因——也就是为什么 warp 没有处于可执行状态。

常见 Stall 原因按我的经验排序如下：

• Long Scoreboard：等待全局访问返回，这是最常见的 stall，几乎总是跟内存延迟相关。
• Short Scoreboard：等待共享内存、常量内存或纹理访问返回，延迟较低。
• Barrier：等待同一个 block 内的其他 warp 到达同步点。
• Wait：固定周期延迟（例如 __syncwarp 或依赖链中的固定等待）。
• Not Selected：这个 warp 本身可执行，只是调度器选择先派发其他 warp。

其中 Not Selected 占比高其实是好事，说明调度器有其他 warp 可以执行，当前 warp 只是暂时没有被选中。真正需要警惕的是 Long Scoreboard 和 Barrier 占比过高，前者代表访存延迟没被掩盖，后者代表线程间同步粒度太粗。

我在实际优化中，遇到 Barrier 占比过高的场景，通常会在满足正确性的前提下尽量压缩同步区域，或者用粗粒度任务划分代替细粒度同步，让不同 block 各干各的。遇到 Long Scoreboard 占比高，则优先考虑提高 Occupancy 或者改用更宽松的访存模式。

3.3 寄存器、local memory 与共享内存的指标

Nsight Compute 的 Resource Usage 区块会直接列出 Register Usage、Local Memory Usage、Shared Memory Usage 三项关键信息。

寄存器使用量直接决定 Occupancy 上限，这是很多优化决策的起点。比如 A100 上每个 SM 的寄存器文件是 65536 个 32 位寄存器，如果每个线程用 128 个寄存器，那么一个 SM 最多驻留 512 个线程（约 16 个 warp），对应 Occupancy 上限就压到 25% 左右。如果这时 kernel 又是延迟敏感的，性能就会很难看。

Local Memory 使用量是我每次必看的指标。如果编译器报告每个线程使用了较多 local memory，基本说明寄存器溢出发生了。优化手段包括：减少每个线程的私有数组大小、把大数组移到共享内存、降低寄存器压力（用 launch bounds 限定最大线程数）。切忌直接忽略这个指标，它是性能杀手。

共享内存使用量则是一把双刃剑。用得好可以极大减少全局内存访问，比如矩阵分块、卷积数据复用场景；用太多则会限制每个 SM 上并发 block 的数量，间接压低 Occupancy。我倾向于先确认瓶颈是全局带宽还是 Occupancy，再决定是否值得加大共享内存开销。

4. 内存指标详解：带宽、延迟与访问模式

4.1 Memory Throughput 不只是看 DRAM

很多人一谈内存指标就只盯 DRAM 利用率，这是不对的。Nsight Compute 的 Memory Workload Analysis 会同时报告 L1/TEX 缓存、L2 缓存和 DRAM 的吞吐数据。这三层需要结合起来看。

比如一个 kernel 的 L2 命中率很高，那么 DRAM 利用率低并不代表访存没问题，因为真正服务处理的是 L2 缓存。如果 L1 命中率很低、L2 命中率很高，说明数据在 L1 这一层基本没有复用，每次访问都要从 L2 拿，L2 的带宽压力很大。如果 L1 和 L2 命中率都低，那基本可以确定全局访存是海量且无规律的大规模读取，DRAM 吞吐被打满只是早晚的事。

我的经验是：每次先记录三个数字——L1 命中率、L2 命中率、DRAM 利用率，再看它们之间的组合关系。L1 命中率低但 L2 命中率尚可，重点优化线程块内的数据复用；L2 命中率也低，重点优化数据分块和访问模式。

4.2 全局加载/存储效率：合并访问的量化体现

全局访问合并（coalescing）是 GPU 性能优化的基本功。Nsight Compute 中可以通过 Memory Workload Analysis 里的 Sector/Transaction 统计来量化合并程度。

一个 warp 访问 32 个线程对应的地址，如果这 32 个地址恰好落在连续的 32 字节 sector 里，硬件只需要发起极少的 memory transaction；如果地址分散在不同页面，transaction 数量会成倍增加，造成带宽浪费。

比较直观的量化方式是看 Global Load Efficiency 或者类似指标。如果效率只有 25%，说明实际发生了大量冗余访问，相当于每 4 个字节的有效数据搬运了 16 个字节。修复办法通常是调整数据布局，尽量保证一个 warp 内相邻线程访问相邻地址，或者改用 float4、double2 等向量化访存指令，一次取多个连续数据。

我在优化一个粒子模拟项目时，就把自定义结构体的 SoA（Structure of Arrays）布局从简单指针改成 float4 对齐的向量访问，Global Load Efficiency 从 30% 直接拉到 90% 以上，整个 kernel 快了接近 3 倍。这就是合并访问的威力。

4.3 L1/L2 命中率与数据复用模式

缓存命中率往往被当作“顺手看一眼”的辅助指标，实际上它决定了内存带宽瓶颈的严重程度。在 Nsight Compute 中，L1 命中率以及 L2 命中率都可以在 Memory Workload Analysis 里看到。

如果命中率偏低，我的建议是先审视数据的复用模式，而不是急着加 __ldg 或者 const restrict。比如矩阵乘法里的 tiled 分块，就是最经典的通过 shared memory 显式复用数据来抬高缓存收益的方案。再比如卷积网络的前向计算，用滑动窗口的方式访问输入数据，同一个输入像素会被多个输出位置使用，这时如果按行缓存到 shared memory，L1 命中率会明显提升。

还有一个技巧是观察波前（wavefront）级别的行为。如果 grid 的 block 数量远大于 SM 数量，每个 SM 会先后执行多波。当第二波 block 启动时，第一波留下的 L2 缓存数据可能已经被换出。这时可以尝试调整 block 的调度顺序或者让每个 block 处理更连续的数据区间，提高缓存利用率。

4.4 L2 Cache 与 DRAM 之间的指标联动

Nsight Compute 会把 L2 到 DRAM 之间的数据流动也暴露出来。比较核心的是 DRAM 读取吞吐和写入吞吐。写入吞吐偏高时，要注意是否有不必要的全局内存写入，例如用 atomicAdd 频繁更新全局计数器的场景，或者反复在全局数组上读改写。

另一个值得关注的联动指标是“扇区访问效率”。如果同一个缓存行只被用到其中一小部分数据，那么缓存行的大部分带宽都浪费掉了。配合上一节讲的合并访问，这个指标可以帮你确认数据布局是否需要调整。

5. 实操过程：一次完整的内核 Profiling 流程

5.1 最省事的命令行方式

Nsight Compute 的命令行工具是 ncu。日常最常用的命令格式如下：

ncu --set full --launch-count 1 --launch-skip 3 ./my_application

• --set full表示收集所有类别的指标，信息最全，但最慢。
• --launch-count 1表示只对第 4 次 kernel 启动做数据收集。
• --launch-skip 3表示跳过前 3 次 kernel 启动（通常是 warmup 或初始化阶段）。

如果程序里有很多 kernel，只想分析某一个，可以用-k参数按名字过滤，例如：

ncu --set full -k my_kernel_name ./my_application

还可以配合--csv --print-details all导出 CSV 文件，方便后续用脚本做批量对比。我在做多组实验对比时，通常会把几个关键指标的 CSV 导出来，用 pandas 简单聚合，省去手动抄数据的功夫。

--metrics参数允许你只采集指定的少数指标，适合快速回归测试。比如我想确认优化没有影响 SM 利用率和运行时间，可以只采集两个指标：

ncu --metrics sm__throughput.avg.pct_of_peak_sustained_elapsed,gpu__time_duration.sum ./my_application

实测下来，这种定向采集比--set full快非常多，适合每次改完代码后跑一遍做回归。

5.2 GUI 界面操作流程

命令行适合批量脚本，但 GUI 才是日常调优的主战场。NVIDIA Nsight Compute GUI 打开后，在界面里配置 executable 路径和参数，选择 profiling scope 为全量 Section，点击 Profile 即可。

启动后建议按以下顺序过一遍：

第一，打开 SOL 页面，看 Compute 和 Memory 两侧的柱状图，记录瓶颈类型。第二，进入 Occupancy 页面，看 Achieved Occupancy 是否明显低于理论峰值，并检查 Register Usage 和 Shared Memory 是否成为限制因素。第三，进入 Warp State 页面，按 stall 原因排序，确认占比最高的是 Long Scoreboard、Barrier 还是 Wait。第四，进入 Memory Workload Analysis，看 L1/L2 命中率、全局访问效率、DRAM 吞吐。

最后，切换到 Source 或者 SASS 视图，把热点指令关联回具体代码位置。这一步往往能直接指出是哪一行循环体里的访存导致了 Long Scoreboard 占满。

5.3 优化前后对比的正确姿势

做优化前后对比时，最容易犯的错误是只比较 wall time。Nsight Compute 本身在 profiling 态下会大幅拖慢 kernel 执行，因为它要转储大量硬件计数器，所以它给出的时间绝对值不适合直接当作基准。

正确做法是：优化前后都用相同的--metrics集合采样硬件计数器，对比 SM 利用率、DRAM 吞吐、L1/L2 命中率、Stall 分布这些相对稳定的硬件指标。只要硬件指标显示瓶颈被转移或者消除，再单独用正常模式（不带 profiler）跑三次，取最短执行时间或中位数时间做最终确认。

我个人的经验是：硬件计数器的稳定性远高于 wall clock，在同一 GPU 上跑同一次 kernel，计数器值基本是确定的。所以“指标变了，时间没变”这种情况基本不会出现，如果出现，先怀疑 profiling 参数不一致，或者 GPU 频率波动太大。

6. 常见问题与排查技巧实录

6.1 全量 profiling 太慢怎么办

全量收集所有 Section 的计数器，Nsight Compute 需要对同一个 kernel 做多次重放，每次只采集一组有限的计数器。kernel 本来就要跑几十毫秒的，全量 profiling 可能拖到几十秒甚至几分钟，这很正常。

我的做法是分两步走：第一步先跑 SOL 快速剖面，只收集最核心的 SOL 相关计数器，确认瓶颈方向。第二步，根据方向选择部分 Section 做深度采集。比如瓶颈在访存，就只开 Memory Workload Analysis 相关的 Section；瓶颈在计算，就开 Warp State 和 Instruction Statistics。全量采集尽量只用于最终确认，不要作为日常迭代手段。

另外，利用-c或--cache-control参数可以控制系统缓存的影响，默认情况下可能要求较高的权限。如果你在云主机或容器里跑，建议先确认设备访问权限，否则有些计数器会采不到。

6.2 profiling 结果全是 0 或者指标不可用

这种情况我遇到过几次，基本都是环境问题。最常见的是 GPU 上没有足够权限访问硬件计数器，或者 profiling 目标进程被 GPU 优先级抢占。

解决办法包括：用 root 权限运行 ncu；确认没有其他进程占着 GPU（比如桌面环境、其他训练任务）；尽量使用无显示环境的 headless 模式。还有一种情况是 kernel 被编译器优化掉了，比如空循环体，导致数据根本不真实，这种情况下对应的指标自然没有意义。

如果只是部分指标不可用，可以先用--set basic跑一遍，确认基础指标能采到，再逐步扩大范围，把问题定位到具体哪类计数器权限受限。

6.3 同一 kernel 多次 profiling 结果不稳定

硬件计数器一般来说是稳定的，但如果你发现多次结果波动明显，首先要考虑 GPU 频率是否在动态变化。默认情况下 GPU 存在 boost 机制，频率会在负载和温度的影响下波动。调频会造成 SM 吞吐、DRAM 吞吐这类指标出现差异。

解决方法是固定 GPU 频率，例如在 Linux 下用sudo nvidia-smi -lgc 1500,1500锁定到一个中间频率，或者使用 ncu 自带的时钟控制选项。锁定频率会牺牲一些峰值性能，但换来的是一致性，这对对比测试非常关键。

如果是多用户共享的 GPU 节点，还要确认 profiling 期间没有其他任务在抢占显存带宽。可以用nvidia-smi看一眼有没有陌生的高占用进程，或者把你的测试任务放到独占节点跑。

我个人习惯是每个优化点至少跑三次收集数据，取中位数作为结论，避免单次数据里的偶然抖动误导判断。

6.4 指标与直觉不符：一个真实案例

分享一个实际案例。之前优化过一个流式计算内核，SOL 页面显示 DRAM 吞吐已经接近 95% 峰值，但是运行时间还是比我预期的高。当时直觉认为“都已经顶满带宽了，应该没法再快了”，但仔细看 Memory Workload Analysis 后发现，L2 命中率只有 20%，全局访问的 sector 效率只有 50% 左右。

这意味着虽然 DRAM 吞吐打满了，但其中一半带宽是在搬运无用数据，因为访存没有合并。我调整了数据布局，把输入数组转成结构体数组并按向量化方式读取后，同样的问题规模下 DRAM 吞吐从 95% 降到 70%，但运行时间却缩短了将近一半。这就是“指标与直觉相悖”背后的真相：单一指标只是探针，要组合着看才能反映真实瓶颈。

最后再分享一点个人习惯：拿到一个慢 kernel，我先跑一次全量 profiling，重点看 SOL 柱状图，判断是计算侧还是内存侧；然后顺着瓶颈方向做局部深度分析。这套流程前前后后只花十几分钟，但能帮我节省大量瞎调的时间。优化完，还要用同一组--metrics做回归，确保硬件指标确实向预期方向移动了，再回到正常模式下验证真实执行时间，才算真正闭环。