What Language Should LLMs Write GPU Kernels In? Disentangling Abstraction Level from Resource Level

LLM-based GPU kernel generation systems target different output representations — CUDA C++, Triton, PTX, tile-level DSLs — yet no controlled comparison isolates that choice, leaving two explanations entangled: do models succeed because a language is high-level, or because it is well-represented in training corpora? We disentangle them with a 2×2 study (abstraction level × resource level) over CUDA, PTX, Triton and TileLang on identical KernelBench tasks, two open-weight models and fixed prompts. In a single turn without documentation, only the high-abstraction/high-resource cell (Triton) produces correct kernels (up to 30.6%); the other three fail at 0%, each for a different, diagnosable reason. A 5k-token specification flips outcomes in a model-dependent way, rescuing CUDA (0 to 49%) and TileLang (0 to 29%) for one model while collapsing another to 0% compiled. Execution-feedback repair rescues the interface- and API-level failures without documentation — so documentation is not a prerequisite, though its advantage persists to turn ten — but leaves PTX unrecovered (5/490 and 4/320 chains). The cell structure and the CUDA/PTX failure signatures replicate on a second GPU generation, where a single correct CUDA kernel out of 370 is the only departure from a clean zero. Representation choice is thus a first-order factor, and neither mechanism bridges the low-level/low-resource gap.