AI-gegenereerde CUDA-code verschuift het werk van ingenieurs steeds vaker naar begeleiding en controle. Op 2 oktober 2026 werd gemeld dat AI-systemen honderden kernelkandidaten kunnen maken, testen en op snelheid selecteren, terwijl specialisten doelen stellen, resultaten beoordelen en ingrijpen als een agent vastloopt. Afzonderlijke experimenten laten snelheidswinsten zien voor specifieke GPU-taken. De menselijke controle wordt ondertussen naar verluidt intensiever.

AI maakt en test kernelkandidaten

CUDA is het softwareplatform van NVIDIA waarmee je GPU’s programmeert. Een GPU-kernel is een klein programma dat op de GPU een bepaalde taak uitvoert, bijvoorbeeld een matrixvermenigvuldiging. Een AI-gegenereerde CUDA-kernel is dus GPU-code die een AI-systeem schrijft om een bewerking uit te voeren of te optimaliseren, bijvoorbeeld ter vervanging van een operatie in PyTorch, een softwareframework voor onder meer machinelearning.

Het interessante zit niet alleen in het schrijven van die code. De beschreven systemen doorlopen een hele zoeklus: ze bedenken optimalisaties, maken verschillende implementaties, controleren de uitvoer en meten de snelheid. De uitkomsten sturen vervolgens een nieuwe zoekronde. Een AI-agent is hier een systeem dat zulke stappen achter elkaar uitvoert, in plaats van alleen een tekstueel antwoord te geven.

Stanford Scaling Intelligence Lab beschrijft een vertakkende zoekmethode waarbij verschillende optimalisatie-ideeën tot parallel onderzochte codekandidaten leiden. Daarmee krijgt het systeem meerdere routes om een snellere implementatie te vinden. Gimlet Labs beschrijft een aanpak met een toezichthoudende agent, meerdere deelagents en een testomgeving die kandidaatkernels beoordeelt.

De onderzochte optimalisaties zijn behoorlijk concreet. Ze omvatten andere toegangspatronen voor geheugen, asynchrone laadoperaties en caching in gedeeld geheugen: geheugen dat samenwerkende GPU-threads kunnen gebruiken. Ook wijzigingen in numerieke precisie, het gebruik van Tensor Cores voor matrixberekeningen en het samenvoegen van bewerkingen komen voor. De AI verkent dus technische keuzes die ook bij handmatige GPU-optimalisatie een rol spelen.

Waarom menselijke controle nodig blijft

Bij deze werkwijze stellen ingenieurs de doelen, beoordelen ze de gevonden resultaten en helpen ze een agent verder als die vastloopt. Het werk verschuift daarmee deels van iedere implementatie zelf schrijven naar een zoekproces begeleiden en de uitkomst controleren.

Dat kan veeleisend zijn. Naar verluidt bevatten sommige gegenereerde kernels ongebruikelijke fouten en vraagt de beoordeling om intensievere controle. Sommige code is bovendien moeilijk te doorgronden, terwijl ingenieurs de uitkomsten wel kunnen toetsen.

Een resultaat controleren en de implementatie begrijpen zijn verschillende taken. Een uitvoertest vergelijkt antwoorden; codebeoordeling onderzoekt hoe die antwoorden tot stand komen. Die twee activiteiten vullen elkaar aan, zeker wanneer een systeem veel kandidaten produceert en de snelste daarvan selecteert.

Voor een ingenieur verandert daardoor ook de vraag die centraal staat. Naast het zoeken naar een snellere implementatie komt het beoordelen van die implementatie: welke invoer is getest, welke nauwkeurigheid is toegestaan en tegen welke bestaande uitvoering is de snelheid gemeten? De experimenten maken duidelijk hoe bepalend die keuzes zijn.

Wat de KernelBench-experimenten aantonen

KernelBench is een verzameling testtaken waarmee onderzoekers en ontwikkelaars gegenereerde GPU-kernels evalueren. Stanford Scaling Intelligence Lab en Gimlet Labs gebruikten die verzameling voor afzonderlijke experimenten, met verschillende GPU’s, taakselecties en meetmethoden.

Stanford: zoeken op een NVIDIA L40S

Stanford Scaling Intelligence Lab rapporteerde een experiment met OpenAI o3 en Gemini 2.5 Pro, vijf zoekrondes en tien KernelBench-problemen van niveau 1 op een NVIDIA L40S. Het lab paste de probleemgroottes aan zodat de tijd die nodig is om een kernel te starten verwaarloosbaar was ten opzichte van de uitvoeringstijd.

De referentiecode gebruikte standaard FP32, oftewel 32-bits drijvendekommagetallen. Oplossingen met een lagere precisie werden geaccepteerd binnen een numerieke tolerantie van 0,01. De controle vergeleek de uitvoer met die van de referentie voor veel willekeurige invoerwaarden. Correctheid had in dit experiment dus een expliciete numerieke grens.

Bij een matrixvermenigvuldiging met matrices van 4096 × 4096 rapporteerde het lab 101,3% van de prestaties van de FP32-referentie torch.matmul. Dat komt neer op 1,3% hogere prestaties voor die taak. Voor torch.softmax met invoervorm (4096, 65536) bedroeg de gerapporteerde verhouding 111,8% van de referentieprestatie.

Het grootste verschil van deze voorbeelden zat bij torch.nn.LayerNorm, een normalisatiebewerking die in neurale netwerken wordt gebruikt. Met invoervorm (16, 64, 256, 256) rapporteerde Stanford 484,4% van de FP32-referentieprestatie, oftewel 4,844× die prestatie. De verschillen tussen de bewerkingen zijn dus aanzienlijk: een kleine winst bij de genoemde matrixvermenigvuldiging, een veel grotere bij deze specifieke normalisatietaak.

Het lab onderzocht ook een samengevoegd blok met Conv2D, ReLU en MaxPool, zoals dat in AlexNet-achtige netwerken voorkomt. Voor dat blok rapporteerde het 2,901× de prestaties van de gewone PyTorch-referentie en 1,89× die van de torch.compile-referentie. Hier worden meerdere bewerkingen gezamenlijk geoptimaliseerd, in plaats van ieder onderdeel apart te behandelen.

Stanford beschrijft de taken als gebonden aan specifieke invoerformaten. Daardoor kan een kernel sterk op precies zo’n formaat worden afgestemd; voor andere afmetingen kan het prestatiebeeld veranderen. Als je met andere matrixgroottes werkt, is juist die afstemming een relevante eigenschap van het resultaat.

Gimlet Labs: de snelste PyTorch-referentie per taak

Gimlet Labs publiceerde op 18 oktober 2025 resultaten van een experiment op een NVIDIA H100. Het bedrijf gebruikte KernelBench-niveaus 1 tot en met 3 en koos per taak de snelste van twee referenties: PyTorch in de directe uitvoeringsmodus, ook wel eager genoemd, of torch.compile.

Die keuze maakt de referentie belangrijker dan een vergelijking met één vaste uitvoeringsmodus. Een gegenereerde kernel werd telkens afgezet tegen de best presterende van die twee opties voor dezelfde taak.

Gimlet rapporteerde ongeveer 1,8× versnelling als geometrisch gemiddelde over de geëvalueerde verzameling. Een geometrisch gemiddelde combineert de afzonderlijke snelheidsverhoudingen multiplicatief. Het bedrijf gebruikte 1× als terugvalwaarde in de berekening. Per KernelBench-niveau rapporteerde het tegenover dezelfde, per taak gekozen referentie:

  • Niveau 1: 2,3× versnelling.
  • Niveau 2: 1,5× versnelling.
  • Niveau 3: 1,4× versnelling.

Gimlet liet verschillende oorspronkelijke KernelBench-gevallen buiten de evaluatie omdat agents technisch correcte verkorte oplossingen vonden die buitenproportionele snelheidswinsten opleverden. De gemiddelden beschrijven de overgebleven geëvalueerde taken.

Daarnaast selecteerde het bedrijf 124 taken waarin torch.compile sneller was dan de directe PyTorch-uitvoering. Binnen die selectie rapporteerde Gimlet gemiddeld 1,6× versnelling tegenover torch.compile. Ook met de gecompileerde uitvoering als referentie bleef er in die afgebakende test dus ruimte voor snellere kernels.

Welke omstandigheden bepalen de winst?

Wil je zo’n resultaat koppelen aan je eigen GPU-code, dan zijn vier zaken doorslaggevend: het GPU-model, de bewerking en invoerafmetingen, de toegestane numerieke afwijking en de referentie-uitvoering. Die bepalen samen welke vergelijking je daadwerkelijk maakt.

Een vaste invoervorm biedt ruimte voor specialisatie. Een soepelere nauwkeurigheidseis kan andere implementaties mogelijk maken. En een vergelijking met directe PyTorch-uitvoering stelt een andere eis dan een vergelijking met de snelste van direct en gecompileerd uitvoeren. De genoemde tests laten zien waarom een snelheidsfactor pas bruikbaar wordt wanneer die omstandigheden erbij staan.

De vraag naar CUDA-kennis in de VS

De gerapporteerde verschuiving naar AI-begeleiding ging gepaard met sterke Amerikaanse vacaturecijfers voor CUDA-kennis. Volgens de gerapporteerde gegevens van Lightcast waren er in de eerste acht maanden van 2026 in de Verenigde Staten meer vacatures die CUDA-vaardigheden vereisten dan in heel 2025.

Daarnaast had NVIDIA naar verluidt in september 2026 meer dan 300 actieve vacatures in de VS waarvoor CUDA-kennis vereist was.