Triton 3.7 Plugin Extensions: Drop the Meta Fork

If you have been maintaining a clone of Meta’s experimental Triton fork just to get persistent GEMM kernels, you can stop. Triton 3.7 shipped on July 15 with a Plugin Extensions system that makes Meta’s TLX (Triton Language Extensions) available as a standalone pip package. The tradeoff between vendor libraries and fork maintenance is gone. One install gets you cuBLAS-competitive performance on both NVIDIA and AMD hardware without touching a single line of upstream Triton source.

What the Plugin Extensions System Actually Does

Before 3.7, extending Triton meant forking and recompiling. Want a custom compiler pass? Fork. Want TLX’s persistent kernel primitives? Fork. Every fork is a maintenance debt that accumulates interest every time upstream ships a new release.

The Plugin Extensions system changes the model. Extensions are now self-contained shared libraries that Triton loads at runtime via the TRITON_PLUGIN_PATHS environment variable. Build your extension once, point an env var at it, and it works with any compatible Triton install. No rebuilding Triton. No merge conflicts. No drift.

The system supports four extension types:

• Pass extensions — custom MLIR compiler passes, loaded via TRITON_PASS_PLUGIN_PATH
• Dialect extensions — custom MLIR dialects and ops
• Language extensions — Python DSL additions
• Backend extensions — hardware-specific backend customizations

Each extension ships with a triton-ext.conf file that declares its name and status. The triton-ext repository hosts the official collection of out-of-tree extensions and serves as the reference for building your own.

Getting TLX Without the Fork

Meta’s TLX is the first major consumer of the plugin system, and it is now the only tool you need for most inference optimization work. Install it:

pip install "triton==3.7" triton-utlx

The triton-utlx package (µTLX) is a standalone plugin that delivers the core TLX primitives without requiring you to modify or build Triton itself. What you get:

• Local memory operations: local_alloc, local_view, local_store, local_load, alloc_barriers
• Custom passes: PingPong and PruneUnusedBarriers
• The TLX dialect with conversion patterns
• Python DSL bindings for all of the above

Load the plugin before running your kernel:

TRITON_PLUGIN_PATHS=/usr/local/lib/libutlx.so python your_kernel.py

TLX hands kernel authors direct control over shared memory allocation, data movement, and instruction scheduling — the primitives that matter for persistent kernels that need to saturate GPU hardware rather than just keep it busy.

The Performance Case

The reason engineers were maintaining that Meta fork is performance. Here is whether the standalone path delivers it.

On large, compute-bound shapes — the shapes dominating production LLM inference — Triton with TLX matches cuBLAS on square GEMM and exceeds it on wide and large shapes. The headline number: a TLX-WS plus fusion kernel at 12.0ms, a 1.61x speedup over the cuBLAS plus torch.compile baseline on H100.

The cross-vendor story is solid. TLX generates identical PTX on NVIDIA H100 and identical AMDGCN on AMD MI350. AMD published their own guide on optimizing GEMM with TLX on CDNA4, which signals that MI350 support is production-grade rather than a port in progress. If you run on both NVIDIA and AMD clusters — increasingly common in 2026 — writing a single kernel that performs competitively on both is now a realistic target.

Before You Upgrade: What Will Break

Triton 3.7 only works with PyTorch 2.12. Upstream enforces strict minor-version pairing, and mixing versions produces failures that are annoying to trace. Review the PyTorch 2.12 compatibility RFC before upgrading.

Breaking changes in 3.7:

• AttrsDescriptor removed from the backend/jit interface. Code that generates or inspects AttrsDescriptor directly — common in TorchInductor customizations — needs updating.
• % operator follows C semantics. If your kernels assumed Python behavior for modulo with negative operands, audit them.

There is also a bug in the base v3.7.0 release: TLX ops return None due to a binding issue in python/src/ir.cc where the plugin custom-op handler discards the op result. If you hit this, upgrade to 3.7.1 or later — all 3.7.x patch versions are interchangeable for PyTorch 2.12 compatibility.

What to Do Now

If you are running inference workloads on H100 or MI350 hardware and have not moved to persistent GEMM kernels, Triton 3.7 plus TLX is the fastest path there. The fork maintenance problem is solved. The performance numbers justify the move.

If you want to build your own Triton extensions — custom passes, domain-specific dialect ops, hardware-specific backends — the triton-ext repository has templates that make the plugin system practical to work with from day one.

The Meta fork served a purpose. It is not the right answer anymore.