Stora språkmodeller (LLM) hyllas som framtiden för högpresterande beräkning, med löften om att kunna skriva snabbare GPU-kod än människor. Men ett nytt test avslöjar en hård verklighet: även om dessa modeller ibland genererar kod som faktiskt fungerar, missförstår de ofta den underliggande fysiken bakom hårdvarueffektivitet. Klyftan mellan syntaktisk korrekthet och faktisk prestanda vidgas, vilket exponerar ett kritiskt blindställe i dagens AI-förmåga.

Forskarna presenterade KernelBench-X, en omfattande testsvit som utvärderar LLM-genererade GPU-kärnor över 176 uppgifter i 15 kategorier. Studien ifrågasätter antagandet att bättre algoritmer automatiskt leder till bättre kod. Istället visar det sig att uppgiftens struktur är den avgörande faktorn för framgång. Matematiska uppgifter löses konsekvent, medan komplexa sammanslagningsuppgifter misslyckas oavsett metod. Detta tyder på att svårigheten inte ligger i AI:n design, utan i den inneboende komplexiteten med att koordinera globala operationer inom GPU-arkitekturen.

Resultaten levererar en överraskande dubbelhet. Iterativ förfining hjälper AI:n att åtgärda syntaxfel och höjer kompileringsgraden avsevärt. Men denna förbättring har en kostnad: prestandan hos de nyåtgärdade kärnorna sjunker jämfört med de som var korrekta från början. Ännu mer oroande är disconnecten mellan korrekthet och hastighet. Nästan hälften av de kärnor som lyckades kompilera var faktiskt långsammare än standardbaslinjer i PyTorch. Modellen misslyckades helt med kvantiseringsuppgifter, vilket indikerar ett grundläggande missförstånd av numerisk precision snarare än enkla kodningsfel.

Slutsatsen är tydlig: att generera kod som kompilerar räcker inte längre. Framtida framsteg kräver att man går bortom ytlagen i syntaxen och explicit modellerar numerisk precision och hårdvarueffektivitet. Så länge AI:n inte kan greppa den globala koordinering som krävs för verklig optimering, kommer LLM-genererade kärnor att förbli en kuriositet snarare än ett tillförlitligt verktyg för högpresterande beräkning.