Triton does not replace CUDA. It sits above it: a kernel-authoring DSL that compiles down to the vendor compute layer, today mostly through NVIDIA targets, with other backends still maturing. Treating the two as competing options is the most common misreading we encounter when teams start writing their own kernels, and it leads to the wrong question being asked.
Is Triton an alternative to CUDA, or does it sit on top of it?
CUDA is a vendor compute API plus a toolchain. Triton is a language for writing kernels that a compiler then lowers onto that toolchain. So the real divergence is not syntax — it is who owns the memory and scheduling decisions. Triton auto-generates tiling, shared-memory staging, and vectorisation choices that a CUDA author writes out by hand. That is a large win for fused elementwise chains and attention-style kernels. It is a liability the moment you need exact control over occupancy, warp specialisation, or an unusual data layout.
The lock-in consequence follows directly: Triton code is still tied to the vendor stack it compiles for. Teams that frame this as an API selection question conflate it with the CUDA/OpenCL/SYCL decision and inherit the portability constraint they thought they were sidestepping. Choosing Triton buys authoring leverage, not hardware freedom.
Which kernels justify hand-written CUDA?
| Kernel class | Usually well served by Triton | Usually still needs CUDA |
|---|---|---|
| Fused elementwise chains | Yes — fusion is the main payoff | Rarely |
| Attention-style kernels | Yes — tiling patterns map cleanly | When warp specialisation matters |
| Memory-bound reductions | Yes — bandwidth is the ceiling anyway | When layout is irregular |
| Compute-bound GEMM-like work | Starting point only | When the last utilisation increments carry cost value |
| Unusual data layouts | No | Yes — explicit staging required |
The measurable outcome is engineering time per optimised kernel against the achieved bandwidth or FLOP utilisation you end up with. In our experience, Triton collapses a multi-week hand-tuned fusion effort into days for memory-bound and fusion-heavy kernels, landing within a workable margin of a tuned CUDA implementation (observed across TechnoLynx GPU engagements; not a published benchmark). Hand-written CUDA earns its cost where a compute-bound kernel is hot enough that the final increments of utilisation move the inference bill.
Record the decision per kernel class, with measured latency, throughput, and utilisation before and after. That is what keeps a tuning budget pointed at the kernels that change the bill rather than the ones that are interesting to optimise. Our GPU engineering practice works this way because kernel-level profiling, not language preference, is what tells you where hand-written CUDA is worth the weeks.
The practical question is therefore not which to pick. It is which kernels in your workload justify hand-written CUDA at all — and how much of the gap you can actually measure before committing engineers to it.
