tile-ai/tilelang

The problem

Writing a fast attention or GEMM kernel today means hand-tuning against a specific GPU generation: you juggle shared-memory layouts, tensor-core paths, pipelining and TMA copies by hand, and the result is rarely portable. Rewriting for a new GPU or an NPU means starting over. TileLang gives kernel authors a Python-embedded DSL where you describe the tiling and schedule, and the compiler lowers it to CUDA, ROCm, Metal, CPU via LLVM, or Huawei Ascend NPUs.

What's different

The usual routes are raw CUDA (maximum control, minimum portability), or Triton (Pythonic, but with its own opinionated abstraction and heavy reliance on compiler-generated scheduling). TileLang sits closer to a tile-level DSL built on TVM's TIRX IR: you get explicit control over TMA copies, warp specialization, cluster copies and atom-level MMA ops while the backend handles codegen and synchronization. The concrete differentiators are the range of backends from one source (CUDA, ROCm, Metal, LLVM CPU, Ascend), the library of operator building blocks (GEMM, block-scaled MXFP4/MXFP8 GEMM, FlashAttention, sparse MLA, scan, TMA gather/scatter), and first-class debugging tooling — IR pass diffing, a pass visualizer, and timing instrumentation — that most kernel DSLs lack.

Who it's for

Inference and training engineers writing custom kernels for LLMs (attention variants, quantized GEMMs, dequant paths), and teams that need one kernel source to run across NVIDIA, AMD and increasingly other accelerators. It is not for people who just want to call an existing operator library or use torch.compile — if torch.nn.functional.scaled_dot_product_attention covers you, TileLang is overkill. It is also a poor fit for those who need a stable, frozen API: releases still remove legacy APIs and the project is under 2 years old.

Cost of adoption

Python package plus a heavier compile-time toolchain: you need working CUDA/ROCm/Metal or LLVM setup, and per-release dependency churn (multiple releases in the README's news log, with v0.1.13 explicitly removing legacy APIs). The license field reports NOASSERTION, so check the actual license text before adopting it in a commercial product. Upfront investment is real: kernel programming is a specialization, and results depend on your target hardware.

Verdict

The project is young — created October 2024, roughly 8.7k stars — yet the release cadence in the news log is unusually dense, with monthly releases and steady hardware support (Blackwell, RDNA4, Ascend 950, Apple M5). Momentum looks genuine: it gained +1,312 stars this month, ranking #14 on the monthly Python board, though it hasn't appeared on the daily board. That profile fits a serious niche tool with a real community rather than a hype spike. Adopt it if you write kernels for a living and value portability and IR debugging; wait if you need API stability or are not prepared to track rapid changes.