⚡

TileGymcuTile内核性能迭代优化Skill tilegym-improve-cutile-kernel-perf

本技能用于在TileGym项目中系统化地优化cuTile GPU内核性能。通过性能剖析、瓶颈分析、IR对比和自动调优，迭代改进内核延迟，同时确保正确性不回归。涵盖tile大小、occupancy、TMA、持久化调度、num_ctas、flush_to_zero等关键调优参数。关键词：cuTile、性能优化、内核调优、TileGym、GPU kernel、TMA、自动调优、延迟优化、IR调试。

TileGym内核优化 0 次安装 1 次浏览 更新于 9/7/2026
名称 tilegym-improve-cutile-kernel-perf
描述 通过系统性剖析、瓶颈分析、IR对比和针对性调优，迭代优化cuTile内核性能。涵盖tile大小、占用率、自动调优配置、TMA、延迟提示、持久化调度、num_ctas、flush_to_zero以及IR级调试。当用户要求“优化cutile内核”、“提升内核性能”、“调优cutile性能”、“让内核更快”或希望在TileGym项目中迭代基准测试并优化cuTile GPU内核时使用。
开源协议 CC-BY-4.0 AND Apache-2.0 metadata:
作者 ‘TileGym Team TileGym@nvidia.com’
版本 ‘2026.4.11’ environment: ‘IDE: Claude Code, Cursor (Agent模式); 模型: Opus 4.6’ requires: ‘用于基准测试的GPU节点Blackwell、Hopper和Ampere’ tags: - cutile - performance - optimization - kernel - profiling

迭代式cuTile内核性能优化

在TileGym仓库中系统化剖析、诊断瓶颈并迭代调优cuTile内核性能。

指令

按顺序执行三个阶段：设置环境和基线，运行带有跟踪日志的实验循环，然后迭代实验循环，直到达到性能目标或进一步增益趋于平缓。

设置

与用户合作准备优化环境：

  1. 创建新的git分支：建议一个分支名称，例如从当前分支创建 cutile-perf-<kernel_name>-<date>。执行 git checkout -b <branch name>

  2. 定位目标内核：

    • cuTile内核位于 src/tilegym/suites/<suite>/cutile/ 或 src/tilegym/ops/cutile/
    • 阅读内核文件并识别：带有 @ct.kernel 装饰器的函数、启动包装器（ct.launch() 或 ct_experimental.autotune_launch()）、@register_impl 注册，以及当前的自动调优配置（如果有）

  3. 对内核分类：

    • 算术强度 < 10 -> 内存受限
    • 算术强度 10-50 -> 均衡
    • 算术强度 > 50 -> 计算受限

    注意：分类仅用于在实验循环中选择优化优先级顺序。核心指标始终是 latency (ms)。

  4. 检查GPU环境：

    • 确保GPU节点可用（Blackwell或Ampere GPU）
    • 所有后续基准测试命令都应在GPU节点上运行

  5. 研究相关参考：

    • references/optimization-playbook.md：每个优化（A到J）的分步配方，包含前后代码示例
    • references/perf-knobs-catalog.md：所有可调参数的完整目录（TMA、持久化调度、占用率、tile大小、延迟提示等）
    • references/cutile-api-reference.md：cuTile API参考及18条关键规则
    • references/performance-model.md：Roofline/性能模型、瓶颈诊断、自动调优
    • references/ir-dump-guide.md：IR转储、分析和错误诊断
    • references/cutile-patterns-reference.md：常见cuTile模式和转换快速参考

  6. 创建 @sandbox/perf_results.md 以跟踪进度。第一次运行将写入基线

  7. 确认并继续：获得用户确认后，启动实验

实验

每个实验迭代对目标内核应用一个优化，验证正确性，重新基准测试，并记录结果。每次迭代应在10分钟内完成。

目标

  • 改进核心指标：降低 latency (ms)
  • 受核心约束限制：正确性不得回退——每个优化必须保证数值正确性。与基线相比，latency (ms) 回退不得超过2%。

可更改的内容

  • 目标内核文件位于 src/tilegym/suites/<suite>/cutile/ 或 src/tilegym/ops/cutile/：内核函数体、tile大小、占用率、num_ctas、TMA使用、延迟提示、flush_to_zero、自动调优配置、持久化调度以及其他cuTile特定参数
  • 内核的启动包装器：网格计算、自动调优配置空间
  • @sandbox/：可自由添加新文件或修改由你创建的文件，但不要提交到git

不可更改的内容

  • 内核功能语义（输入、输出和容差范围内的数值行为）
  • 测试基础设施和基准测试工具
  • 上述未列出的任何内容

实验输出预期

正确性测试：

python -m pytest tests/suites/.../test_<kernel_name>.py -k 'test_ and cutile and not test_perf' -v

性能基准测试：

对于每次迭代：

  1. 运行pytest基准测试：python -m pytest ... --print-record → 提取 latency (ms)
  2. 将延迟记录在 perf_results.md 中

基准测试命令行：

python -m pytest tests/suites/.../test_<kernel_name>.py -k 'test_perf and cutile' --print-record -v

延迟示例：

Cutile: {'forward': {'mean': 3.7903138461538455, 'std': 0.0016941310873207053, 'rel_std': 0.044696327430505396, 'median': 3.789880999999999, 'min': 3.7883389999999992, 'max': 3.7941230000000004, 'nrep': 13, 'peak_mem_mb': 913}} ms

跟踪实验进度

使用 @sandbox/perf_results.md 记录每次迭代的结果。该文件应只包含一个带有5列的Markdown表格：

  • iteration：迭代编号，从0（基线）开始
  • optimization：应用了什么优化（例如，‘baseline’、‘TMA replace gather’、‘persistent scheduling’）
  • latency_ms：内核延迟（毫秒），保留六位小数
  • correctness：PASS 或 FAIL
  • status：该迭代是 ‘keep’、‘revert’ 还是 ‘crash’

示例内容：

| iteration | optimization       | latency_ms | correctness | status |
|----------:|:-------------------|-----------:|:------------|-------:|
| 0         | baseline           |   0.820000 | PASS        | keep   |
| 1         | TMA replace gather |   0.390000 | PASS        | keep   |

如果文件为空，则创建表头。每次迭代追加一行。

基线

第一次迭代（迭代0）不修改任何代码，只运行正确性测试和性能基准测试。结果作为基线写入第一行。

实验循环

核心方法论是每次迭代从playbook中应用一个优化，验证正确性，进行基准测试，并决定保留还是回退。一次尝试一种优化，并保留干净的实验记录。

循环：

  1. 检查git状态：确认当前所在的git分支/提交

  2. 从 references/optimization-playbook.md 中选择并应用一个优化：

  3. 验证正确性——如果失败，立即回退。常见原因：flush_to_zero/rounding_mode=APPROX 改变了结果、tile大小越界、allow_tma=False 语义、持久化循环边界错误

  4. 重新基准测试并与当前基线比较

  5. git提交

  6. 将结果记录到 @sandbox/perf_results.md

  7. 决策规则：

    结果 操作
    改进(latency (ms)) >= 5% 接受为新基线，继续
    改进2-5% 接受，降低下一次迭代的优先级
    改进< 2% 接受但停止，除非用户希望继续
    任一配置回退 立即回退，尝试下一个优化
    连续两次迭代无改进 停止
    根因是 ‘scheduling’ 或 ‘unknown’ 升级给用户

  8. 如果保留，则推进基线数字并继续循环

  9. 如果回退，则git reset回到起点，并按优先级顺序尝试下一个优化 直到：所有尝试完成，或超过25次迭代，或用户中断

保持自主：在设置阶段询问用户明确说明。一旦进入实验循环，不要暂停征求用户反馈：基于你的最佳判断做决策，及时查阅优化playbook和性能旋钮目录，卡住时深入思考。