Soms zit je niet vast op strategie, maar op doorvoer. Je model is goed, je data is op orde, en toch voelt het alsof je GPU op halve kracht draait. Dat komt vaak doordat je pipeline leunt op generieke bouwstenen, terwijl jouw use case nét andere vormen, lengtes of precisies gebruikt.

Hugging Face heeft daarom twee puzzelstukken bij elkaar gebracht: een manier om custom kernels te distribueren via de Kernel Hub, én een agent skill die coding agents leert hoe je zulke kernels daadwerkelijk bouwt en aansluit op PyTorch, diffusers en transformers. In dit artikel leg ik uit wat er precies is gebouwd, hoe je het installeert, wat er in de skill zit, hoe de benchmarks uitpakken, en hoe je je eigen kernel publiceert zodat anderen hem in één regel kunnen gebruiken.

Waarom een skill voor kernels?

Als je ooit aan CUDA kernel development hebt geroken, weet je dat het niet voelt als “even een stukje code schrijven”. Je hebt te maken met GPU generatie verschillen, geheugenbandbreedte, vectorisatie, warp reducties, en daarna moet het ook nog netjes in PyTorch landen zodat het samenwerkt met dingen als torch.compile.

De Kernel Hub lost één groot probleem al op: distributie. Je kunt pre gecompileerde kernels laden met één get_kernel call. Geen lokale builds, geen flags, geen “werkt alleen op mijn machine”. Alleen, dat lost nog niet op dat iemand die kernel wel moet schrijven.

Daar zit de waarde van een skill. Je stopt de praktische kennis die normaal verspreid zit over docs, GitHub issues en Stack Overflow in een compacte set instructies en voorbeelden. Een agent kan die context inladen wanneer nodig, en vervolgens niet alleen de kernel genereren, maar ook de binding, de build configuratie en de benchmark scripts opleveren. Dat scheelt vooral tijd, maar belangrijker, het verkleint de kans op fouten die je later duur betaalt in instabiliteit of tegenvallende performance.

De skill installeren zonder gedoe

De skill wordt geleverd via de kernels library. Je installeert hem en voegt hem toe aan je agent omgeving met een paar commando’s.

pip install kernels

kernels skills add cuda-kernels --claude

Daarna staat hij in .claude/skills/cuda-kernels/, zodat tools zoals Claude Code en Cursor hem automatisch kunnen vinden. Gebruik je een andere agent, dan kan dat ook:

# Codex

kernels skills add cuda-kernels --codex

OpenCode

kernels skills add cuda-kernels --opencode

Eigen locatie

kernels skills add cuda-kernels --dest ./my-agent/skills/

Globaal, voor alle projecten

kernels skills add cuda-kernels --global

Overschrijven

kernels skills add cuda-kernels --claude --force

Daarna kun je je agent heel direct aan het werk zetten. Bijvoorbeeld:

“Bouw een gevectoriseerde RMSNorm kernel voor H100, gericht op Qwen3 8B in transformers.”

Of, als je wat breder wilt gaan:

“Bouw een attention kernel voor H100 voor Qwen3 8B, benchmark tegen de PyTorch baseline en controleer het effect van begin tot eind.”

Wat belangrijk is om te begrijpen: die skill is geen magische knop. Het is een goed gevulde gereedschapskist die een agent helpt om minder te gokken en sneller tot een werkend project te komen.

Wat zit er in de skill?

De kern is een set van ongeveer 550 tokens aan gestructureerde instructies, aangevuld met referenties, voorbeeldscripts en troubleshooting. Dit is expres zo opgebouwd dat agents kunnen zoeken en matchen op bestandsnamen en patronen.

De mapstructuur ziet er grofweg zo uit:

.claude/skills/cuda-kernels/

├── SKILL.md

├── scripts/

│ ├── benchmark_example.py

│ ├── benchmark_rmsnorm.py

│ ├── ltxkernel_injectionexample.py

│ ├── transformersinjectionexample.py

│ └── huggingfacekernelsexample.py

└── references/

├── diffusers-integration.md

├── transformers-integration.md

├── huggingface-kernels-integration.md

├── h100-optimization-guide.md

├── a100-optimization-guide.md

├── t4-optimization-guide.md

├── kernel-templates.md

└── troubleshooting.md

Inhoudelijk gaat het om drie dingen die in de praktijk vaak misgaan.

Ten eerste: GPU bewust ontwikkelen. Een H100, A100 en T4 gedragen zich anders. Denk aan compute capability, shared memory, bandbreedte en wat logisch is qua block sizing.

Ten tweede: integratie met libraries. Diffusers en transformers hebben elk hun eigen patronen, naming, normalisatie conventies en plekken waar je kernels kunt injecteren. Als je dat verkeerd doet, lijkt de kernel te werken, maar pakt PyTorch hem niet mee in compiled graphs.

Ten derde: benchmarken op twee niveaus. Je wilt micro benchmarks om te zien of je kernel echt sneller is, en je wilt pipeline benchmarks om te controleren of het ook verschil maakt in de echte doorlooptijd.

De skill stuurt agents aan om niet alleen één .cu bestand te maken, maar een compleet project dat je kunt bouwen en testen. Bijvoorbeeld:

examples/your_model/

├── kernel_src/

│ └── rmsnorm.cu

├── torch-ext/

│ ├── your_kernels/init.py

│ └── torch_binding.cpp

├── benchmark_rmsnorm.py

├── build.toml

├── setup.py

└── pyproject.toml

Benchmark 1: diffusers met LTX Video op H100

De eerste echte test was LTX Video, een video generatie pipeline uit diffusers. De agent bouwde meerdere kernels, waaronder RMSNorm, RoPE 3D, GEGLU en AdaLN. De focus in de resultaten ligt vooral op RMSNorm, omdat daar de grootste winst zat.

Alles is getest op een H100 80GB HBM3 met BFloat16.

Geïsoleerde RMSNorm benchmark (LTX Video)

In de micro benchmark werd de custom RMSNorm kernel vergeleken met de PyTorch baseline. Dit is de kern van de versnelling in deze set.

Een paar gemeten punten uit de tabel:

Custom rond 0,039 tot 0,173 ms, PyTorch rond 0,064 tot 0,393 ms, met speedups die oplopen tot 2,26 keer.

Gemiddeld kwam de winst uit op 1,88 keer sneller, met een bandbreedte efficiëntie van 34,7 procent van de theoretische H100 bandbreedte van 3.350 GB per seconde.

Dat laatste is een nuttige reality check. Ook met een goede kernel zit je zelden direct aan theoretische maxima, zeker niet als shapes variëren of je pipeline meer doet dan alleen één operator.

Van begin tot eind video generatie (49 frames, 30 stappen)

Uiteindelijk maakt het je weinig uit of één operator sneller is, als het totaal nauwelijks beweegt. Daarom is er ook van begin tot eind gebenchmarkt.

De vergelijking zag er zo uit:

Baseline zonder compile: 2,87 s, 12,58 it per seconde.

Met de gegenereerde kernels: 2,70 s, 13,52 it per seconde, ongeveer 1,06 keer sneller.

Baseline met torch.compile: 2,14 s, 19,05 it per seconde.

Kernels plus torch.compile: 2,01 s, 18,45 it per seconde, ongeveer 1,43 keer sneller dan de ongecompileerde baseline.

Een detail dat ik prettig vind aan deze rapportage: er wordt ook uitgelegd waarom de winst beperkt blijft. RMSNorm is ongeveer 5 procent van de totale compute in LTX Video. De rest zit in attention, lineaire projecties en VAE decode. Dan is 6 procent totale winst door één type kernel heel logisch.

Benchmark 2: transformers met Qwen3 8B op H100

De tweede test richtte zich op Qwen3 8B, een groot taalmodel uit transformers. In dit model zitten 65 RMSNorm modules over 32 lagen. Ook hier werd een RMSNorm kernel gebouwd voor H100, weer op BFloat16 en H100 80GB.

Als je ooit performance issues in inferentie hebt gehad, herken je dit patroon: één relatief klein blokje code komt zó vaak terug dat het ineens een serieuze post op je latency wordt.

Geïsoleerde RMSNorm benchmark (Qwen3 8B)

De custom kernel liet hier gemiddeld 1,94 keer winst zien, met een bandbreedte efficiëntie van 22,3 procent van het theoretische maximum.

Wat interessant is, is hoe de winst meegroeit met langere context. In de metingen liep het van 1,58 keer bij 128 tokens op naar 2,47 keer bij 8.192 tokens. Voor long context inferentie halveert de RMSNorm latency daarmee grofweg.

Dat betekent niet dat je hele model ineens twee keer zo snel is, maar het is wel precies het soort verbetering dat je bij veel requests per dag direct terugziet in GPU kosten en capaciteit.

Je kernel publiceren naar de Hub

Een werkende kernel in je eigen repo is mooi, maar de echte schaal zit in delen. De Kernel Hub maakt dat praktisch, omdat anderen je kernel kunnen laden zonder zelf te compileren.

De skill en de Hub vullen elkaar aan. De skill helpt bij ontwikkeling en testen. De Hub regelt distributie.

1. Controleer je projectstructuur

De output van de agent volgt al de kernel builder layout. Dit is wat je minimaal nodig hebt:

your_kernel/

├── build.toml

├── kernel_src/

│ └── rmsnorm.cu

└── torch-ext/

├── torch_binding.cpp

└── your_kernels/

└── init.py

In build.toml staat wat er gebouwd moet worden en voor welke GPU capabilities. Voor een H100 hoort daar bijvoorbeeld de juiste capability bij, zodat je geen binaire bestanden publiceert die alleen op de verkeerde kaarten werken.

2. Bouw alle varianten met Nix

Dit is een punt waar teams vaak onderschatten hoeveel werk distributie is. Je kernel moet meerdere combinaties van PyTorch en CUDA ondersteunen. Dat levert al snel een matrix aan builds op.

Kernel builder gebruikt hiervoor een Nix flake. In de praktijk komt het neer op een flake kopiëren en dan:

nix flake update

nix run .#build-and-copy -L

De output komt in build/.

Als je sneller wilt bouwen, kun je de Hugging Face Nix cache gebruiken:

nix run nixpkgs#cachix -- use huggingface

3. Maak een Hub repo en upload

Daarna maak je een model repo aan op de Hub en upload je de build map.

huggingface-cli repo create your-org/your-kernel --type model

huggingface-cli upload your-org/your-kernel ./build

Wat je hiermee koopt is rust. Jij bouwt één keer netjes alle varianten, en gebruikers krijgen automatisch de juiste binary voor hun omgeving.

4. Anderen laden hem in één regel

Voor de gebruiker ziet het er vervolgens heel simpel uit:

from kernels import get_kernel

rmsnorm = get_kernel("your-org/your-kernel")

get_kernel kijkt naar Python, PyTorch en CUDA versies en haalt de passende binary op. In de praktijk is dit vaak binnen seconden geregeld, zonder build tooling op de machine van de gebruiker.

Wat je hier als ondernemer of marketingteam mee kunt

Als je vooral met e commerce, marketing en AI toepassingen bezig bent, voelt CUDA kernel werk misschien ver van je bed. Toch kom je het sneller tegen dan je denkt.

Zodra je eigen AI producten draait, of je nu personalisatie, beeldgeneratie, video, of chat inzet, betaal je voor inferentie. Iedere procent winst die je haalt uit latency of throughput wordt op termijn gewoon budget en ruimte. Tegelijk wil je niet dat je team maanden verliest in laag niveau tuning.

Daarom vind ik dit interessant: het gaat niet om “sneller om sneller”, maar om een volwassen workflow. Agents kunnen een groot deel van het specialistische werk opzetten, inclusief benchmarks en integratie. En via de Hub kun je resultaten delen, hergebruiken en standaardiseren. Dat is precies hoe je technische voorsprong bouwt zonder jezelf in een moeras van maatwerk vast te zetten.

Conclusie

De kern van het verhaal is eenvoudig. CUDA kernels schrijven blijft lastig, zeker als je ze goed wilt laten samenwerken met diffusers en transformers. Maar door die kennis te verpakken in een agent skill, kunnen Codex en Claude nu complete kernel projecten opleveren, inclusief PyTorch bindings en benchmarks.

In de tests leverde dat werkende kernels op voor zowel een diffusers pipeline als een transformers model. Bij RMSNorm zie je in micro benchmarks grofweg een verdubbeling van de snelheid, en in echte pipelines een kleinere maar meetbare winst die past bij hoeveel tijd die operator in het totaal inneemt.

Als je serieus AI workloads draait, is dit een nette stap richting herhaalbare performance verbetering, zonder dat je alles zelf hoeft uit te vinden.

Resources

Wil je verder kijken, zoek dan op de CUDA Kernels Skill (SKILL.md), de LTX Video example, de Qwen3 8B example, de blog over de Hugging Face Kernel Hub, Kernels Hub in TRL, en de artikelen over Claude die open modellen leert en fine tunen ondersteunt. Ook de Hugging Face Kernels Community is een goede plek om te volgen wat anderen publiceren.