PyTorch 2026 北美大会的硬件加速议程出炉

这次 PyTorch 北美大会的议程表我看了一遍，最直观的感受就是：大家已经不满足于只在 H100 上跑得快了，现在的趋势是极致的“跨芯片兼容”和“内核自动化”。尤其是那些搞底层算子的人，现在的卷法已经从纯 CUDA 转向了各种 DSL（领域特定语言）和编译器后端。

最让我感兴趣的是一个细节：AWS 的 Trainium 现在号称能实现“原生 PyTorch 运行且无需修改代码”。这意味着如果你在用 torch.compile 或者 Hugging Face Transformers v5，以后可能直接把模型甩给 Trainium 就能跑，不用再写那一堆复杂的迁移脚本。而且 Google Cloud 那个 Bill Jia 提到的一个点很激进——他们在搞一种 Agent 驱动的工作流，能让模型在 GPU 和 TPU 之间自动迁移，并且通过量化和内核生成自己去“爬山”优化性能。如果这个能落地，以后我们部署模型可能根本不用关心底层是哪家芯片，AI Agent 自己会选最快的那块卡。

对于我们这种平时写代码、偶尔得调优算子的开发者来说，这次会上提到的几个工具链非常关键，我梳理了一下重点：

一、算子开发的门槛在降低，但复杂度在转移
现在的趋势是：你不需要写 C++ CUDA，但你需要学习新的 DSL。

• Triton 依然是主流： 会上有专门给 PyTorch 开发者的 Triton 入门指南，从简单的向量加法讲到矩阵乘法（GEMM）。这意味着 Triton 已经成了事实上的“通用语言”。
• NVIDIA 的 CUTLASS Python： 这点很关键，NVIDIA 终于把 CUTLASS 这种硬核库 Python 化了，引入了 CuTe DSL 扩展和零成本异步调度。以后写高性能内核可能真的只需要 Python 就能搞定，不用在 .cu 文件里死磕内存对齐了。
• AMD 的 FlyDSL： 这是一个基于 MLIR 的 GPU 内核 DSL，直接集成在 TorchInductor 的 GEMM 编译管线里。AMD 现在的策略很明显，就是通过优化编译器后端来硬刚 Triton 的生态。

二、编译器在尝试接管一切
现在的逻辑是：手动调优 → 自动调优 → 编译器预测。

• PerfModel： AMD 出了一个分析模型，能在 JIT 编译前就预测出 Triton GEMM 的高性能配置。这解决了之前最头疼的“穷举搜索” autotuning 耗时太长的问题。
• Modular 的 MAX： 他们在展示如何通过 Mojo 语言和图编译器，把融合内核自动编译到 H100、TPU 和 Trainium 上。这种“一次编写，到处运行”的愿景如果成真，对多云部署的开发者来说简直是救命药。

三、内核分发的“模型化”
Hugging Face 出了一个叫 Kernels 的库，这个逻辑非常像模型权重分发。以后你想给某个模型换一个更快的算子，可能不需要重新编译，而是像加载 checkpoint 一样直接加载一个优化过的内核，官方号称能带来 2-5 倍的加速。

如果你现在也在纠结怎么优化 PyTorch 模型的推理速度，我建议关注一下 torch.compile 配合 Triton 的组合。虽然大会还没开，但从这些 session 来看，未来的方向一定是：

# 伪代码：未来的优化路径可能是这样的
import torch
from huggingface_kernels import load_optimized_kernel

# 不再手动写 CUDA，而是加载预优化内核
model = load_model("your-llm")
model = load_optimized_kernel(model, target_hw="AMD_Instinct") 

# 配合编译器自动处理 sharding 和量化
optimized_model = torch.compile(model)

总的来说，硬件厂商现在都在拼命给 PyTorch 做适配，而 PyTorch 也在通过 TorchInductor 试图屏蔽底层差异。对于我们应用层开发者，只要盯着 torch.compile 和 Triton 这两个点，基本就能跟上这波性能红利。