Triton 3.7 Plugin Extensions: Drop Your Fork Now

Triton 3.7's new plugin extension system lets GPU kernel developers load custom MLIR compiler passes at runtime as shared libraries, eliminating the need to maintain a Triton fork. Meta's TLX extensions, previously fork-only, now ship as triton-utlx on PyPI and deliver identical performance, with PyTorch benchmarks showing a 1.61x speedup over cuBLAS + torch.compile on H100 for multi-GEMM pipelines. The migration takes three commands, and the plugin system introduces zero runtime overhead.

Triton 3.7 ended the fork era for GPU kernel developers. The new plugin extension system lets you load custom MLIR compiler passes at runtime as shared libraries — no Triton rebuild, no upstream divergence, no merge hell. Meta’s TLX extensions, which previously required maintaining a Triton fork, now ship as triton-utlx on PyPI https://pypi.org/project/triton-utlx/ and deliver identical performance to the fork. If you’re still carrying a Triton fork into late 2026, you’re carrying debt that no longer has a justification. The Problem Every ML Infra Team Knows High-performance GPU kernels for production workloads frequently need more than what the standard Triton compilation pipeline offers. Persistent GEMMs require fine-grained shared memory control. Warp-specialized pipelines need custom scheduling passes. Hardware-specific intrinsics — on Hopper, MI350, or RDNA4 — need lowering paths that Triton doesn’t ship by default. Before Triton 3.7, the only way to add these capabilities was to fork the compiler. That meant constant rebasing against upstream, merge conflicts on every Triton release, blocked security patches, and an internal team tasked with watching the upstream diff. Meta ran exactly this setup with TLX. Many ML infra teams at AI labs, cloud providers, and hardware vendors ran similar forks. The plugin extension system, landed in 3.7, eliminates this. Your custom pass lives in a shared library. Triton loads it at runtime via TRITON PLUGIN PATHS . The pipeline runs your pass alongside upstream passes. When Triton ships 3.8, you upgrade Triton and your plugin independently. Three Levels of Extension The plugin API https://pytorch.org/blog/triton-plugin-extensions-enabling-tlx-and-custom-compiler-passes-out-of-the-box/ supports three levels of extensibility, and which one you need depends on how deep into the compiler you want to go. Level 1: Custom transformation passes. A single MLIR pass inserted at an arbitrary point in the pipeline — TTIR, TTGIR, LLVM IR, or PTX — without an associated dialect. This is the lowest barrier to entry. Good for optimization passes that work on existing Triton IR patterns. Level 2: Custom MLIR dialects and conversion passes. A full dialect compiled as a separate shared library and loaded dynamically. Plugin passes rewrite standard Triton IR patterns into your custom dialect ops for specialized lowering. This is how TLX works — it defines a TLX dialect with ops like local alloc and PingPong , loads them via plugin, and lowers them through its own conversion pipeline. Level 3: Custom top-level DSL ops. New Python-level syntax that extends the Triton language itself — new programming abstractions without touching the Triton source tree. Highest complexity, but enables kernel programming patterns that don’t exist in upstream Triton. For most teams migrating off a fork, Level 1 or Level 2 covers the use case. Drop the TLX Fork — Three Commands If you’re on a TLX-based Triton fork, migration to the plugin version takes three commands: pip install triton==3.7.0 pip install triton-utlx export TRITON PLUGIN PATHS=$ python -c "import triton utlx; print triton utlx.lib path " The triton-utlx package µTLX ships local alloc , local view , local store , local load , and alloc barriers — the same shared memory primitives from the TLX fork. Custom passes including PingPong and PruneUnusedBarriers are included. The full TLX dialect and Python DSL bindings are bundled. Performance is not a concern: the plugin system introduces zero runtime overhead. PyTorch’s benchmarks show that TLX via plugin delivers 1.61x speedup over cuBLAS + torch.compile baseline on H100 for multi-GEMM pipelines — identical to what the fork produced. On AMD MI350, the plugin enables Cluster Launch Control, previously a fork-only feature on CDNA4. Your existing kernel code that uses TLX primitives runs unchanged. The only difference is you’re now pulling the extension from PyPI instead of a vendored fork. Writing Your Own Level-1 Pass If you need a custom optimization pass rather than TLX’s memory ops, here’s the structure. A Level-1 pass plugin is a shared library with a triton-ext.toml manifest: extension name = "my optimization pass" status = "experimental" pass pipeline stage = "TTGIR" priority = 100 The pass itself is a standard MLIR pass written in C++ or using the Triton pass infrastructure. Build it as a .so file, add its path to TRITON PLUGIN PATHS , and Triton loads it at the pipeline stage you specified. The triton-ext repository https://github.com/triton-lang/triton-ext on GitHub contains complete reference implementations for all three levels, including the MLIR boilerplate that’s otherwise easy to get wrong. For per-kernel toggling, a compiler hook in kernel code activates the plugin for all kernels in that call context until unset — meaning you apply a custom pass to specific kernels without it affecting your entire workload. Migrate Off make block ptr Now Triton 3.7 also deprecates tl.make block ptr . The compiler emits a deprecation warning on every use. The replacement is tl.make tensor descriptor : Deprecated in 3.7 — migrate now to avoid breakage in 3.8+ Before: ptr = tl.make block ptr base, shape, strides, offsets, block shape, order data = tl.load ptr After: desc = tl.make tensor descriptor base, shape, strides, block shape data = desc.load offset m, offset k The new API enables Tensor Memory Accelerator TMA integration on Hopper GPUs, which the block pointer API could not. This is not optional maintenance — it will break in a future release. Community patches for common patterns are tracked in pytorch/pytorch 154025 https://github.com/pytorch/pytorch/issues/154025 . Upgrade Checklist Here’s what to do this week if you’re running Triton in production: - Upgrade to pip install triton==3.7.0 - If on a TLX fork: install triton-utlx , drop the fork, set TRITON PLUGIN PATHS - Audit all make block ptr usage and migrate to make tensor descriptor - Check triton kernels.matmul call sites — the matmul API has backwards-incompatible changes in 3.7 - For custom passes: scaffold a Level-1 plugin using triton-ext https://github.com/triton-lang/triton-ext as the reference The plugin system is the right architecture for this class of problem. Teams that built forks to solve real performance problems weren’t wrong — they were working around a gap in Triton’s design. That gap is now closed. Read the full Triton 3.7 release notes https://github.com/triton-lang/triton/releases/tag/v3.7.0 before upgrading — the matmul API changes and block pointer deprecation require review before you update in production.