这周工作日，我和两位同事饭后漫步在太平洋边，感叹如今AI infra工作层出不穷，这不，有了以下对话，大家看了后也去和自己同事和朋友和同学出去吹个牛。
同事1：最近 算子方向 很多新工作啊， cuTile、Triton 还有 TileLang，以及pytorch新出的helion 这几个新东西好像很有讨论度啊。都是说能简化算子开发，降低门槛，还能榨干硬件性能，你们两位首席科学家有没有深入研究过？
同事 2：巧了，我今天刚看了 NVIDIA 关于 cuTile 的博客，正好想跟你们聊聊。它最核心的点就是 “让开发者聚焦算法，硬件细节交给框架”—— 以前写 CUDA 得自己管线程块划分、共享内存分配这些琐事，现在 cuTile 直接帮你搞定 tile 级别的调度优化，不用手动调那些复杂的硬件参数了。
我：我补充下，cuTile 是 NVIDIA 原生的，而且现在已经支持 Python 接口了。这对咱们这种习惯用 Python 做数据科学、深度学习的人太友好了，不用再切换到 C++ 写 CUDA 核心，直接在 Python 里就能调用，性能还不打折。比如矩阵乘法、卷积这些常用算子，用 cuTile 封装后，代码量少了很多，但能接近手写优化 CUDA 的性能。
同事1：那它和 OpenAI 的 Triton 比起来呢？我记得 Triton 也是主打 “Python 写 GPU 高性能代码”，而且很多大模型框架都在用它。
同事 2：这俩核心目标有点像 —— 都是降低 GPU 编程门槛，同时保证性能。但底层逻辑不一样。Triton 是跨硬件的，不仅支持 NVIDIA GPU，还能跑在 AMD 甚至 CPU 上；而 cuTile 是 NVIDIA 专属，深度绑定 CUDA 生态和 NVIDIA 硬件，比如 Hopper、Ada 架构的新特性，它能直接调用，优化会更极致。
我：对，Triton 更像一个通用的 “高级 GPU 编程语言”，有自己的编译器和 IR 中间表示，你写的时候还是要考虑一些并行逻辑，只是不用管底层硬件细节。而 cuTile 更像 “CUDA 高阶工具包”，它是在 CUDA 基础上封装的，专门针对 tile-based 算法优化，比如矩阵运算、深度学习算子，这些场景下它能自动做 tile 划分、数据复用，比手动写更高效。
同事 1：那 TileLang 又是个什么定位？我听说是个今年才新兴的 DSL，性能也很能打。
同事 2：TileLang 更偏向 “领域专用编译器”，它的核心设计就是围绕 “tile” 这个概念 —— 把计算和数据都按 tile 组织，然后编译器自动做并行调度、内存优化。它和前两者的区别在于，它不绑定特定硬件或生态，既可以针对 NVIDIA GPU 优化，也能适配其他架构，而且它的抽象层次更高，你甚至不用写并行代码，只需要描述清楚计算逻辑，编译器就会自动生成最优的 GPU 代码。
我：我看过一些测试数据，TileLang 在矩阵乘法、卷积这些算子上的性能，能和 cuTile、Triton 以及很多手写的算子持平甚至略高，因为它的编译器在 tile 调度和内存复用的优化上更极致。但它的生态还比较新，支持的场景不如前两者多 ——cuTile 背靠 NVIDIA，能无缝集成到 PyTorch、TensorFlow 这些框架里；Triton 有 OpenAI 背书，很多大模型都在用它做自定义算子；而 TileLang 现在还正在逐渐流行起来的阶段。
同事 1：这么说来，这三者的技术路线差异还挺明显的。那从场景选择来看，咱们该怎么选？
同事 2：如果是做深度学习、数据科学，而且是用 NVIDIA GPU，优先选 cuTile—— 它和 CUDA 生态无缝衔接，Python 接口简单，性能又有保障，不用折腾跨平台的问题。比如你要给 PyTorch 写个自定义算子，用 cuTile 比手动写 CUDA 快多了，还不容易出错。
我：如果需要跨硬件，比如既要支持 NVIDIA 又要支持 AMD，那 Triton 更合适。它的语法和 Python 很像，学习成本低，而且社区活跃，遇到问题容易找到解决方案。比如 OpenAI 的 GPT 系列模型，很多自定义算子都是用 Triton 写的，就是看中了它的跨平台性和易用性。
同事 1：那 TileLang 什么时候会用到呢？
我：如果是做底层算子开发，而且追求极致性能，去tune极致性能，又不想绑定特定硬件，TileLang 可以试试。比如你要开发一个通用的高性能算子库，适配多种 GPU 架构，TileLang 的编译器优化能力能帮你省很多事。但要注意，它的文档和生态还不够完善，开发效率可能会低一些。
同事 1：除了技术本身，你们觉得这几家推出这些工具背后的战略考量是什么？
同事 2：NVIDIA 推 cuTile 很明显 —— 巩固 CUDA 生态壁垒。以前很多开发者觉得 CUDA 学习成本高，会转向其他框架，cuTile 降低了 Python 开发者的使用门槛，让更多人留在 CUDA 生态里，同时又能发挥 NVIDIA GPU 的硬件优势，进一步拉开和其他 GPU 厂商的差距。
我：OpenAI 推 Triton 则是为了 “打破硬件依赖”。大模型训练需要大量 GPU 资源，如果绑定 NVIDIA，成本太高，而且容易被卡脖子，这不，meta和google传出绯闻，搞不好大概率就是让NVIDIA降点价。。。Triton 能跨硬件，意味着未来可以根据成本和性能选择不同的 GPU，甚至 CPU，掌握更多主动权。同时，Triton 也能让更多开发者轻松写出高性能算子，推动大模型生态的发展。
同事 1：TileLang 则更像是 “技术探索”—— 它代表了未来高性能编程的一个方向：更高层次的抽象，让开发者完全聚焦算法，编译器负责搞定所有硬件优化。它的作者可能更多是想解决现有工具的痛点，比如 Triton 还需要开发者考虑一些并行逻辑，cuTile 绑定 NVIDIA 硬件，而 TileLang 想做到 “一次编写，多硬件最优运行”。
同事 1：这么一想，这几个工具其实是各自生态和战略的体现。那未来的发展趋势会是怎样的？
我：我觉得会是 “抽象层次越来越高，硬件感知越来越智能”。不管是 cuTile、Triton 还是 TileLang，核心都是让开发者不用关心底层硬件，专注业务逻辑。未来可能会出现更通用的工具，既能像 cuTile 一样深度适配特定硬件，又能像 Triton 一样跨平台，还能有 TileLang 那样的极致性能优化。
同事 2：而且生态整合会越来越重要。比如 cuTile 已经集成到 CUDA Python 里，Triton 被 PyTorch 内置支持，未来这些工具可能会直接成为深度学习框架的一部分，开发者甚至不用特意去学习它们，直接调用高层 API 就能获得高性能。而 TileLang 要想发展起来，可能需要和主流框架合作，完善生态支持。
我：总结下来就是，这三个工具都是 GPU 高性能编程的 “降维打击”，但各有侧重：cuTile 是 NVIDIA 生态的 “易用性 + 极致性能” 选择，Triton 是跨平台的 “通用性 + 低学习成本” 选择，TileLang 是追求 “极致优化 + 跨硬件” 的新兴选择。咱们以后可以根据具体项目的硬件环境、生态需求来选，不用再死磕手动写 CUDA 了。
同事 2：没错！这些工具的出现，其实是高性能计算的一个大趋势 —— 把复杂的硬件优化交给编译器和框架，让开发者把精力放在算法创新上，这才是提高研发效率的关键。
同事 1：后续我打算做个实际测试并且搜集一下网上已有的数据，把这三个工具在同一个算子上的性能、开发效率做个对比，到时候再跟你们吹一吹，天下苦CUDA久矣啊！
我：对了，今年 PyTorch 新出了个叫 Helion 的 DSL，说是 “PyTorch 语法 + Tile 编程”，写 GPU 内核不用学新语法，直接用 torch 接口就行，你们俩关注到没？
同事 1：看了一下，这东西最戳我的是 “零学习成本”—— 以前写 Triton 得记 tl.load、num_warps 这些专属接口，Helion 直接让你在 hl.tile 循环里写 torch.addmm、torch.empty，主机端代码就是纯 PyTorch，适合喜欢炼丹师写算子。比如它文档里的矩阵乘法，外层用 hl.tile 分块，内层直接调 torch.addmm 做计算，比 Triton 代码少了快一半，还不用手动管线程块映射。
同事 2：对，它本质是 “Triton 的上层包装 + PyTorch 的语法壳”，但不是简单套壳 ——Helion 会自动把 PyTorch 算子翻译成优化过的 Triton 实现，连内存索引都帮你处理。
我：但这玩意听起来确实像triton套娃，只不过pytorch塞了点私货，那他相比triton的优劣势你们有了解没
同事1：有些劣势，比如社区反馈，Helion 自动调优选出的 “最优配置”，在 Tritonbench 实测中延迟指标不匹配—— 例如某 RMSNorm 算子（输入 (2048,2048)），Helion 判定 “block_sizes=(2)、num_warps=4” 为最优（延迟 0.0145ms），但 Tritonbench 实测该配置延迟为 0.0133ms，且另一未被 Helion 选中的配置（block_sizes=(8)）在 Tritonbench 中表现更优。这一问题源于两者测量方法差异（Helion 内置 profiler 与 Tritonbench 计时逻辑不同），可能导致理论最优与实际性能不一致。
同事2： 还有这玩意相比triton调优更耗时，且灵活性更差，triton 允许开发者进行硬件级细粒度控制，例如手动调整 eviction_policy 优化 L1 缓存、自定义持久化内核（Persistent Kernel）的线程块复用策略；而 Helion 的高层抽象会 “屏蔽” 这些底层控制 —— 若需特殊优化（如针对稀疏张量的定制化内存访问、非标准循环展开策略），Helion 缺乏接口支持，需退回到 Triton 或 CUDA 实现。
我：有意思，现在还真是做出了各种花啊，各家都想分个蛋糕啊，看看后面这些个vendor厂商以及苦CUDA久矣的大厂还会有哪些有创新性的工作出来，好了，回去搬砖了，下午害得拉通对齐呢。