Triton

What it is

Triton is a Python-embedded language and compiler for writing custom GPU kernels, primarily targeting NVIDIA and AMD hardware. It sits between "write raw CUDA" and "hope your framework's kernel is fast enough" — you write tile-based kernels in a Python-like syntax, and Triton's compiler (built on MLIR) handles memory coalescing, shared memory allocation, and instruction scheduling that you'd otherwise hand-tune in CUDA C++. It's the backend torch.compile uses to generate fused kernels in PyTorch 2.x, which is how most people encounter it without ever writing Triton code directly.

Who builds it and why

Originated at OpenAI, now developed as an openai/triton project with heavy external contribution — 625 contributors is a large number for a compiler project and reflects both PyTorch's dependency on it and independent adoption by hardware vendors and ML infra teams writing custom attention variants, quantization kernels, and MoE routing logic. NVIDIA, AMD, and Intel all have people contributing backend support, which tells you this isn't a single-vendor tool anyone can quietly deprecate. Corporate users write custom Triton kernels because hand-rolled CUDA is expensive to maintain and iterate on, and Triton gets you 80-95% of CUDA's performance for a fraction of the engineering time on common kernel patterns (attention, layernorm, fused MLPs).

Production readiness signal

19.5K GitHub stars and a commit as recent as the data cutoff indicate active, ongoing development, not a research artifact left to rot. 625 contributors and integration as PyTorch's default compiler backend means this code path is exercised by essentially every torch.compile user in production today — that's a much stronger signal than star count alone. Release cadence (v3.7.1) suggests a project past the "breaking API every minor version" phase, though Triton's IR and lowering internals still change enough that pinning versions matters if you write custom kernels directly. No CNCF maturity level applies here — this isn't a CNCF project, and framing it that way would be misleading.

Who should use this

Teams writing custom attention mechanisms, fused kernels for novel model architectures, or quantization/dequantization logic that stock PyTorch ops don't cover efficiently. If you're already using torch.compile and it's generating Triton kernels under the hood, you're using it whether you know it or not — no action needed. If you're hitting a performance wall where PyTorch eager mode or existing compiled kernels aren't fast enough and profiling shows kernel launch overhead or lack of fusion as the bottleneck, Triton is the right next step before dropping to raw CUDA.

Who should NOT use this

If you're not writing custom GPU kernels — i.e., you're using standard model architectures with off-the-shelf ops — you don't need to touch Triton directly; let torch.compile handle it. If you need to squeeze the absolute last percentage points of performance on a fixed, well-understood kernel (e.g., cuBLAS-level GEMM), hand-written CUDA or vendor libraries (cuDNN, cuBLAS, CUTLASS) will still beat Triton in many cases. If your team has no GPU kernel-level performance problems, adding Triton is solving a problem you don't have. And if you need first-class support on non-NVIDIA/AMD hardware (TPUs, custom ASICs), Triton's backend coverage isn't there yet — check current backend support before committing.

Alternatives

• CUDA C++ / CUTLASS — lower-level, maximum control and performance ceiling, much higher engineering cost.
• TVM — a full compiler stack for cross-hardware deployment, broader scope than Triton's GPU-kernel focus but heavier to adopt.
• Pallas (JAX) — Google's equivalent for JAX/XLA users wanting Triton-like kernel authoring inside that ecosystem.

Pricing

Fully open source, MIT licensed. No paid tier, no enterprise edition. Cost is entirely the engineering time to write and maintain kernels.