Towards Feature Complete Triton Support in JAX-Triton

2026-07-08 · Source: AMD ROCm Blogs · Field: Technology & Digital — Artificial Intelligence & Machine Learning, Software Development & Engineering · Depth: Intermediate, extended

Summary

Recent improvements to the JAX-Triton project, particularly those contributed by AMD and available in its fork, significantly advance its compatibility with upstream Triton. By version 0.5.1, JAX-Triton now supports the Gluon dialect (since v0.4.0), introduces a "@jt.kernel" decorator for cleaner launch syntax, and ensures proper backend object initialization with full access to two dozen options. The update also brings feature-complete support for all Triton argument types, including tuples, callables, and "tl.constexpr" values, by delegating kernel specialization to Triton's original code. Furthermore, handling of output-only and input-output arguments has been simplified through new "out_names=" and dictionary-based "out_shape=" parameters, replacing error-prone raw index mapping. These changes move JAX-Triton from an experimental prototype towards maturity, enabling efficient execution of most Triton or Gluon kernels within JAX with minimal modifications, though some limitations like "jax.grad" support remain. Installation recommends Triton 3.6.0.

Key takeaway

For AI Engineers or ML Architects integrating custom GPU kernels into JAX workflows, these JAX-Triton updates significantly simplify development and improve performance. You can now port most existing Triton or Gluon kernels with minimal changes, leveraging features like the "@jt.kernel" decorator and improved output argument handling. Be aware that JAX-level transformations like "jax.grad" are not yet supported, and ensure you install Triton 3.6.0 from the AMD fork for full compatibility.

Key insights

JAX-Triton now supports most Triton features, enabling efficient integration of GPU kernels into JAX compute graphs.

Principles

• JAX's immutability requires explicit output specification.
• Kernel specialization optimizes performance for specific arguments.
• Delegate complex logic to underlying frameworks.

Method

JAX-Triton's kernel specialization pipeline parses signatures once, dynamically building optimized functions to handle argument splitting and specialization description computation for each launch.

In practice

• Use "@jt.kernel" decorator for cleaner kernel launch syntax.
• Specify output parameters via "out_names=" or dictionary "out_shape=".
• Install from AMD fork for latest features, using Triton 3.6.0.

Topics

• JAX-Triton
• GPU Kernels
• Triton Language
• Gluon Dialect
• Kernel Specialization
• AMD ROCm

Code references

• ROCm/jax-triton
• ROCm/jax-triton

Best for: Machine Learning Engineer, AI Engineer, AI Architect

Related on AIssential

• JAX-AITER: Bringing AMD’s Optimized AI Kernels to JAX on ROCm™ — JAX-AITER bridges JAX with AMD's optimized AITER kernels for significant performance gains on ROCm GPUs.
• ParallelKernelBench: Frontier LLMs can't write fast multi-GPU kernels (yet) — Frontier LLMs struggle with multi-GPU kernel generation, but can occasionally produce novel, high-performance solutions.
• TorchTPU: Running PyTorch Natively on TPUs at Google Scale — TorchTPU enables native PyTorch execution on Google TPUs, prioritizing usability, performance, and hardware portability.
• Taking on CUDA With ROCm: ‘One Step After Another’ — AMD's ROCm software stack is rapidly maturing, leveraging open-source tools and community engagement to challenge Nvidia's CUDA dominance.
• From Naive to Near-Peak: Building High-Performance GEMM Kernels with Gluon — Achieving near-peak GPU kernel performance requires explicit hardware control and a profiling-driven, iterative optimization methodology.
• Speed-up JAX LLM Training on Intel® Xeon® 6 CPU: Activation Offloading on Heterogeneous Systems — JAX-based activation offloading to Intel Xeon 6 CPU memory improves LLM training throughput by 3-15.5% on heterogeneous systems.

Open in AIssential →

Editorial summary, takeaway, and curation by AIssential. Original article published by AMD ROCm Blogs.