executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
triton-kernelsAuthoritative guide to writing custom OpenAI Triton kernels for GPU inference optimization, focusing on block-level programming and auto-tuning.
Independent GitHub snapshot · Automated classification · Original documentation governs
OpenAI Triton abstracts the CUDA threading hierarchy into block-level operations, demanding a paradigm shift from thread-centric to block-centric programming. Execution hinges on maximizing Streaming Multiprocessor (SM) occupancy, exploiting SRAM (Shared Memory) locality, and ruthlessly minimizing High Bandwidth Memory (HBM) latency. You must conceptualize execution as tiles of memory flowing deterministically through the memory hierarchy.
Do not rely on naive broadcasting. Compute memory pointers explicitly for block geometries. HBM reads/writes dictate kernel performance; arithmetic intensity must hide memory latency.
tl.load before arithmetic.Kernels are useless without hardware-specific parameterization. Employ @triton.autotune decorators relentlessly to search the combinatorial space of block dimensions (BLOCK_M, BLOCK_N, BLOCK_K), num_warps, and num_stages. Optimal configurations are non-linear; empirical search is mandatory.
Implementing attention demands block-level softmax formulations (e.g., FlashAttention). You must fuse the exponential sum accumulations iteratively over block loops to avoid HBM materialization of the $N \times N$ attention matrix.
%%{init: {"theme": "default", "flowchart": {"useMaxWidth": true}}}%%
flowchart TD
A[Triton Kernel Launch] --> B[Block Grid Definition]
B --> C[Pointer Arithmetic & Masking]
C --> D[SRAM Staging via tl.load]
D --> E[SRAM Computation: Matmul/Reduction]
E --> F[HBM Writeback via tl.store]
subgraph AutoTuning
G[Vary BLOCK sizes] --> H[Vary num_warps]
H --> I[Vary num_stages]
end
F -.-> AutoTuning