ThunderKittens (and the HipKittens AMD port)

The strongest answer to the task's '2025-2026 kernel DSL that has become load-bearing', reading 'DSL' as the C++-embedded kind rather than the Python kind - ThunderKittens is what a frontier lab writes when Triton is not low-level enough. It sits deliberately between Triton and raw CUDA: high-level enough to express a full attention kernel in a page, low-level enough to call WGMMA and TCGEN05 directly. Compare w7k-tilelang (Python DSL, portable across three vendors) and w7k-modular-max-mojo (Python-shaped MLIR frontend) for the other two points on that spectrum. HIPPITTENS IS INCLUDED IN THIS RECORD RATHER THAN AS ITS OWN because its most valuable content is comparative: the authors state that core tile and bulk-compute interfaces carry over from TK to HK 'but decisions around memory access patterns, scheduling compute and memory, and ordering thread blocks within the chiplet architecture differ'. Chiplet-aware thread-block ordering has no NVIDIA analogue, which is the concrete content of why a ROCm port is not a recompile. It supports CDNA3 and CDNA4 and is now an AITER backend, so on AMD it reaches production through flops/amd-rocm-aiter-kernels rather than as a standalone library. autotuning is false: performance comes from hand-written primitives matching the hardware, not from a search. input_languages carries cutlass-cpp as the schema's term for a C++-template kernel library, which is the right shape but strictly these are not CUTLASS headers - a vocabulary stretch, flagged. The production_evidence line is explicitly vendor-published and unquantified, the same standard the existing flops/tilelang record applies to DeepSeek's 'close to hardware limits'. compile_time_seconds is null: these are headers, so compile time is instantiation cost inside the consumer's build, not a per-kernel number.