RightNow AI har frigivet AutoKernel som open source, og det er faktisk en nyhed, der er værd at tage alvorligt. Ikke fordi verden manglede endnu et AI-værktøj med et lidt for friskt navn, men fordi AutoKernel går direkte efter et af de mest besværlige hjørner af AI-infrastruktur: GPU-kerneloptimering for vilkårlige PyTorch-modeller. Det er normalt ikke noget, man lige ordner mellem to møder og en lunken kaffe. Det er dyr specialisttid, ofte uger med tuning, og det er præcis derfor historien er større end produktlanceringen selv.

Kort fortalt bygger AutoKernel på et autonomt agent-loop, hvor en model ændrer kernel-kode, kører et fast benchmark-harness, måler korrekthed og throughput og så enten beholder eller ruller ændringen tilbage. Det lyder næsten banalt. Det er også lidt pointen. Det stærke her er ikke løftet om maskinmagi, men at RightNow AI forsøger at gøre kerneloptimering til en systematisk arbejdsgang med måling, versionsstyring og mange små forsøg i træk.

Der hvor GPU-regningen gemmer sig

En GPU-kernel er i praksis de små stykker kode, der udfører de tunge regneoperationer på tværs af tusindvis af GPU-kerner. Når man kører transformer-modeller, ligger en stor del af arbejdet inde i operationer som matrixmultiplikation, softmax, layer normalization og attention. Ikke særligt romantisk, men ofte præcis dér tiden og pengene forsvinder, hvis noget kører bare lidt skævt.

Det er også her, mange beslutningstagere mister overblikket. De taler om modelvalg, leverandør, compliance og licenser, og alt det er fair nok. Men vi ser hos Snilld ret tit, at regningen i praksis vælter ind fra ineffektiv kørsel, for mange unødige ventecykler og pipelines, der aldrig blev trimmet ordentligt. Man kan sagtens vælge den rigtige model og stadig køre den på en dum måde. Av.

Grunden til at kerneloptimering er så sær en disciplin, er at man skal jonglere mange ting samtidig: hukommelsesadgang, registerpres, tile-størrelser, synkronisering mellem tråde og valg af instruktioner til tensor cores. Både MarkTechPosts omtale og AutoKernels arxiv-paper peger samme vej her, bare med lidt forskellig tone: det her er hårdt arbejde, og ekspertisen er sjælden. Ifølge arxiv-beskrivelsen kan bare én højtydende matrixmultiplikations-kernel kræve ugers finjustering fra folk, der ved præcis hvad de laver.

Nej, modeller kan ikke bare trylle optimal GPU-kode frem

Det måske vigtigste korrektiv i hele historien er, at frontier-modeller ifølge KernelBench ikke er særligt imponerende til one-shot kernelgenerering. MarkTechPost refererer til benchmark-suiten KernelBench, som vurderer modeller på 250 GPU-kernelproblemer. Her matchede de bedste one-shot-modeller PyTorch-baseline i færre end 20 procent af tilfældene. Det er et ret brutalt tal.

Det knuser den dovne fortælling om, at man bare kan bede en stor sprogmodel om at skrive optimal CUDA eller Triton, læne sig tilbage og lade blæserne snurre. Sådan virker det tydeligvis ikke. Jeg synes egentlig, det er den mest opløftende del af nyheden, fordi den tvinger os væk fra teater og over mod ingeniørarbejde. Mindre show, mere skruenøgle.

AutoKernel er interessant netop fordi RightNow AI ikke ser ud til at bygge på idéen om det perfekte første svar. Hele systemet er lavet omkring iteration. En kandidat skrives, testes, benchmarkes, og hvis resultatet er dårligere eller forkert, ryger den ud igen. Hver eksperimentrunde bliver ifølge kilderne knyttet til git-commits, så historikken kan gennemses med helt almindelige værktøjer. Det er voksent. Næsten irriterende voksent.

Det egentlige greb er loopet

Ifølge MarkTechPost fungerer AutoKernel ved, at en LLM-agent redigerer en kernel-fil, hvorefter et fast benchmark-harness både tjekker korrekthed og måler throughput. Resultatet afgør så, om ændringen bliver beholdt eller rullet tilbage. Den mekanik er værd at dvæle ved, for det er her den praktiske værdi bor. Ikke i at modellen er klog, men i at systemet er stædigt.

Arxiv-versionen går et skridt dybere og beskriver, at AutoKernel først profilerer modellen for at finde beregningsmæssige flaskehalse og derefter rangerer dem efter effekt målt med Amdahls lov. Det er ikke bare et akademisk navn smidt ind for pynt. I praksis betyder det, at systemet starter dér, hvor en forbedring faktisk kan mærkes på den samlede køretid. For tekniske ledere er det ærlig talt mere interessant end selve agentdelen.

Når vi sidder med tunge workloads, er det sjældent de små skævheder i kanten, der gør ondt. Det er de få operationer, der æder størstedelen af tiden. Hvis et værktøj systematisk kan finde de værste syndere først, så ændrer det økonomien i optimeringsarbejdet. Ikke nødvendigvis dramatisk fra dag ét, men nok til at det bliver svært at ignorere.

Mere stædig mekaniker end digital troldmand

Arxiv-kilden beskriver også, at AutoKernel kan raffinere Triton- eller CUDA C++-implementeringer gennem hundredvis af eksperimenter uden menneskelig indgriben. Det billede kan jeg godt lide. Det ligner mindre en genial engangsopfindelse og mere en meget stædig mekaniker, der prøver, måler, smider væk og prøver igen.

MarkTechPost nævner, at hver iteration tager cirka 90 sekunder fordelt på korrekthedstjek, performance-benchmark og selve agentens kodeændring. Det giver omkring 40 eksperimenter i timen, og over en nat kan det blive til 300 til 400 forsøg på tværs af flere kernels. Man behøver ikke være kernel-specialist for at forstå værdien i det. Mange små, kontrollerede forsøg slår ofte én stor smart idé.

Det er i øvrigt derfor overskrifter om, at man bare kan aflevere sin model inden sengetid og vågne op til hurtigere kernels, både er rammende og lidt for glatte. Ja, det er ambitionen. Men værdien står og falder med, om benchmark-loopet er robust, om korrektheden holder, og om forbedringerne faktisk kan reproduceres næste dag, næste uge, på næste driver-version. Det er her de kedelige spørgsmål begynder. Det er også de rigtige spørgsmål.

Hastighed er værdiløs, hvis output bliver forkert

AutoKernels paper beskriver en femtrins correctness harness, som dækker smoke tests, shape-sweeps på tværs af mere end ti konfigurationer, numerisk stabilitet under vanskelige input, determinisme og edge cases. Den detalje skal ikke gemmes væk nede i et bilag. Den er central. Hurtigere forkert kode er ikke en sejr, det er bare en mere effektiv måde at lave fejl på.

Vi har set den slags problem i mindre dramatisk form hos kunder, hvor en pipeline ser flot ud i en benchmark, men falder fra hinanden så snart input varierer lidt mere end demo-sættet gjorde. Ikke fordi folk er inkompetente. Mere fordi optimering under tidspres næsten altid frister til at måle det, der er nemt. Derfor er correctness-harnesset måske den mest betryggende del af hele projektet.

Det betyder ikke, at risikoen forsvinder. Arxiv er trods alt forskningsformidling og ikke det samme som bred produktionserfaring over år. Det bør siges højt. Paperet viser en seriøs metodik, men det er ikke det samme som at have bevist, at AutoKernel uden videre passer ind i alle virkelige driftsmiljøer med sære afhængigheder, ældre kode og teams, der allerede har for lidt tid.

Hvorfor danske ledere bør følge med alligevel

Hvis man driver egne modeller eller tunge PyTorch-jobs, er den potentielle forretningsværdi ret enkel at forstå. Bedre kernels kan i princippet give lavere omkostninger til inferens, hurtigere træning, kortere eksperimentcyklusser og bedre udnyttelse af eksisterende GPU-kapacitet. Jeg skriver med vilje i princippet, for kilderne dokumenterer ikke et universelt procenttal på tværs af alle workloads, og det skal vi ikke opfinde. Men retningen er logisk nok.

Det her er måske lidt niche, men vi oplever tit, at samtalen om AI i danske organisationer bliver for abstrakt. Folk diskuterer strategi i powerpoint-lag, mens den reelle flaskehals ligger i latency, drift og GPU-regning. Der sidder nogen et sted og kigger på en månedlig faktura, som ikke bliver mindre af, at man har haft en inspirerende workshop. Hvis værktøjer som AutoKernel virker i praksis, kan de flytte noget værdi netop dér.

Og nej, de fleste danske tekniske ledere kommer aldrig selv til at skrive Triton eller CUDA C++. Det er heller ikke pointen. Pointen er, at kerneloptimering måske kan bevæge sig fra at være en sjælden specialistdisciplin til at blive en agentstyret, målelig proces, som flere teams kan styre. Det er en vigtig forskydning, hvis den holder.

Sund skepsis er stadig den rigtige holdning

Skeptikerne har også nogle fair argumenter. For det første er arxiv ikke en garanti for moden drift. For det andet kan et benchmark-harness være fremragende og stadig favorisere bestemte mål frem for andre, for eksempel rå throughput over mere komplekse driftskrav. Og for det tredje lyder formuleringen vilkårlige PyTorch-modeller bredere, end den måske viser sig at være i praksis, når værktøjet møder rodede, hjemmebyggede produktionsmiljøer.

Det er ikke en afmontering af historien. Tværtimod. Det er bare jordforbindelse. Den rigtige prøve bliver, om AutoKernel kan levere reproducerbare forbedringer, være til at vedligeholde over tid og passe ind i workflows, hvor teams allerede bruger profileringsværktøjer, CI, kodegennemgang og en sund frygt for regressionsfejl. Man opdager først forskellen, når man sidder med det i hænderne.

Alligevel peger AutoKernel på noget vigtigt. Ikke AI som magisk kernel-guru, men agentisk optimering som en disciplineret arbejdsgang med benchmark, rollback, versionsstyring og logfiler. Hvis den model holder uden for paperet, kan den flytte ret meget værdi. Hvis ikke, står der stadig en nyttig lektie tilbage: de bedste AI-værktøjer ligner ofte ikke trolddom. De ligner gode, lidt tørre ingeniørloops, der gør arbejdet, mens resten af os sover. Måske.

Kilder

• RightNow AI Releases AutoKernel: An Open-Source Framework that Applies an Autonomous Agent Loop to GPU Kernel Optimization for Arbitrary PyTorch Models
• AutoKernel: Autonomous GPU Kernel Optimization via Iterative Agent-Driven Search
• Writing a high-performance GPU kernel can take weeks of expert …
• (PDF) AutoKernel: Autonomous GPU Kernel Optimization via …
• Marktechpost AI Dev News – Twitter
• LLM News Today (April 2026) – AI Model Releases – LLM Stats