PyTorch's Triton 3.7 Lets Developers Load Custom GPU Compilers Without Forking
PyTorch-Triton 3.7 ships a plugin system that loads custom compiler passes at runtime, ending the era of maintaining Triton forks for hardware-specific optimizations
- Plugin system ships in Triton 3.7: custom compiler passes, dialects, and DSL ops now load at runtime via
TRITON_PLUGIN_PATHS, no forking required. - Meta's TLX is the first plugin: install
pip install triton-utlxto get persistent GEMM kernels and explicit shared memory control out of the box. - Beats cuBLAS on H100: Triton + TLX exceeds cuBLAS by up to 3.7% on large LLM-relevant matrix shapes; beats rocBLAS by 12-15% on AMD MI350.
- Zero codegen overhead: plugin-loaded path produces identical PTX/AMDGCN to the compiled-in Meta fork, confirmed by benchmark parity.
- Cross-hardware: same TLX programming model targets both NVIDIA Hopper (TMA + WGMMA) and AMD MI350 (register-based pipelining).
- Ecosystem play: the triton-ext repo opens the door to community-built extensions for custom backends, distributed primitives, and specialized ops.
For years, anyone who wanted to push Triton beyond its defaults faced the same painful choice: maintain a fork. Fork Triton, add your custom compiler passes, your hardware-specific memory ops, your specialized dialects, and then spend the next several months fighting merge conflicts every time upstream moved. The PyTorch-Triton 3.7 release changes that with the Triton Plugin Extensions system, a framework for dynamically loading custom compiler passes, dialects, and DSL extensions into upstream Triton at runtime, without forking or recompiling.
The fork tax was real
Writing high-performance GPU kernels often requires going beyond what the default Triton compiler pipeline provides. Custom optimization passes, hardware-specific intrinsics, and specialized memory management patterns are essential for squeezing out the last drops of performance on production workloads. Until now, enabling these capabilities meant maintaining a fork of Triton, and said forks come with real costs.
Forks fall behind upstream. Every update risks merge conflicts, broken APIs, and subtle behavioral changes. Teams that pin to a forked version miss upstream bug fixes, new hardware support, and community improvements. The maintenance burden compounds, and the fork becomes a bottleneck. The plugin system is a direct answer to this.
How the plugin system works
The framework lets you develop Triton compiler extensions that extend functionality without modifying the core Triton codebase. Extensions are built as shared libraries that can be dynamically loaded by Triton at runtime. You point Triton at your plugin via a single environment variable, TRITON_PLUGIN_PATHS, and the extensions are immediately available, no recompilation of Triton required.
The system provides three levels of extensibility:
- Custom transformation passes: single passes inserted at arbitrary points in the compilation pipeline, with no associated dialect needed.
- Custom MLIR dialects and conversion passes: separately compiled dialects loaded into Triton, with plugin passes that rewrite standard Triton IR into custom dialect ops for specialized lowering. MLIR (Multi-Level Intermediate Representation) is the compiler IR framework Triton uses internally to represent and transform GPU programs.