评估 CUDA Occupancy 的正确起点是：先确认一个线程块消耗的寄存器和共享内存是否压缩了同一 SM 上可驻留的线程块、线程或 warp 数量，再判断额外并发是否真正改善吞吐。Occupancy 是活跃 warp 相对硬件可支持驻留 warp 的比例，能反映隐藏部分延迟的能力，但不是性能目标本身。
先把 Occupancy 视为资源结果
一个 kernel 可同时驻留多少线程块，受线程块线程数、每线程寄存器、每块静态与动态共享内存，以及目标架构的线程、warp、线程块和资源分配限制共同约束。任一限制先触顶，都会降低可驻留块数；因此即使线程块尺寸相同，只要寄存器使用或动态共享内存申请变化，Occupancy 也可能改变。
寄存器通常按线程分配。单线程寄存器需求上升会放大为整个线程块的资源消耗，导致可并发块数下降。共享内存按线程块分配，算法为分块缓存、交换或协作通信申请较大容量时，也会直接减少同一 SM 可共存的块数。资源还存在架构相关的分配粒度，不能只用简单除法估算，实际结果应以编译产物和目标设备为准。
线程块尺寸应服务于执行形态
线程块尺寸既影响 warp 组织，也影响资源消耗和任务划分。尺寸过小可能让每个块承担的工作有限，并受每 SM 可驻留块数约束；尺寸过大则可能因寄存器或共享内存总量而少驻留一个或多个块。选择时应保证线程组织适合数据映射和控制流，而不是为追求某个占用率刻意改变算法。
对于规则、独立且以全局内存访问为主的 kernel，可围绕若干合理块尺寸建立候选集；对于块内归约、分块矩阵计算或需要协作加载的 kernel，则应先满足共享内存布局、访存合并和同步边界，再比较候选尺寸。具体资源上限随计算能力和工具链变化，部署前应按现场 GPU 与编译配置复核。
寄存器压力不是单纯的坏消息
降低寄存器用量可能提高驻留量，却可能引入局部内存访问、增加指令数量，或破坏编译器保留中间结果的能力。相反，适度使用更多寄存器有时能提高指令级并行度，减少数据往返，从而在较低 Occupancy 下获得更高吞吐。因此，只有当测量显示延迟无法被现有活跃 warp 隐藏时，才应把削减寄存器列为主要优化方向。
先从编译反馈和性能分析工具读取每线程寄存器数、静态共享内存和动态共享内存，再建立资源预算。若怀疑寄存器是上限，可小范围调整代码生命周期、复用临时变量或拆分不必要的长依赖链；限制寄存器数应是受控实验，而不应作为默认修复手段，因为它可能触发溢出。
共享内存优化要同时看容量和访问方式
共享内存能减少重复的全局内存访问，也能支持线程协作，但其容量占用会限制驻留块数。使用动态共享内存时，应将实际申请字节数纳入每个配置的记录，避免只比较源代码中的静态数组。若共享内存访问存在 bank 冲突，单纯提高 Occupancy 通常无法消除该等待；应优先检查数据布局、步长和访问模式。
当算法可选择不同分块大小时，比较的不应只是共享内存更少的方案，还应包含全局内存访问次数、访问合并程度、同步次数及每次加载后的复用程度。共享内存减少造成的 Occupancy 提升，若以更多全局读写或更差的数据复用为代价，整体吞吐可能下降。
高 Occupancy 的三个常见反例
- 内存带宽已接近可用上限时，增加活跃 warp 未必增加有效数据传输，重点应转向访问合并、数据复用和读写比例。
- 长依赖链限制指令级并行度时，更多 warp 只能部分掩盖延迟；重排独立计算、减少串行依赖可能更有效。
- 频繁的块内同步、分支分歧或原子竞争主导执行时间时，资源释放出的并发空间无法消除等待来源，应先定位同步与竞争行为。
CUDA 的执行与资源模型、内存层次及编程约束应以 CUDA C++ Programming Guide 中对应版本和计算能力的说明为准。不要把跨架构、跨驱动或跨编译选项获得的 Occupancy 结论直接迁移到生产环境。
按候选配置做受控实验
- 固定问题规模、数据分布、精度、编译选项和测量方法，记录基线 kernel 的耗时与正确性结果。
- 为每个候选线程块尺寸记录寄存器、静态和动态共享内存、理论 Occupancy 及实际运行耗时；一次只改变一个影响资源的因素。
- 利用分析工具检查活跃 warp、内存访问效率、执行单元利用情况、warp 停顿原因和同步相关等待，识别主导瓶颈。
- 只保留在重复测量中稳定改善端到端耗时且不破坏结果正确性的配置，并在目标部署设备上复测。
用吞吐和停顿原因决定取舍
验证指标至少应包括 kernel 时间或端到端吞吐、理论与实测 Occupancy、寄存器和共享内存使用量，以及主要 warp 停顿类别。若提高 Occupancy 后时间无改善，同时内存相关停顿、同步等待或指令依赖仍占主导，就应停止继续压缩资源，转向相应瓶颈。性能测量的实验方法、内存访问优化与配置建议可结合 CUDA C++ Best Practices Guide 进行复核。
保留可回退的实现路径
将每次资源调整保留为独立配置或受版本控制的实现分支，并保存基线参数、编译日志和测量条件。若寄存器限制导致溢出、共享内存缩减破坏数据复用，或新块尺寸在实际负载下退化，应立即回退到已验证的基线。对于不同 GPU 架构、CUDA 版本和驱动组合，重新编译并复测后再确定默认配置，不能仅依赖理论计算结果。