🤖 machine learning

Tile-Level Activation Overlap for Efficient LLM Inference

Dit artikel introduceert twee gespecialiseerde CUTLASS-gebaseerde SM90-kernels die SwiGLU-activatie fuseren met matrixvermenigvuldiging op tile-niveau om de overhead van de materialisatie van intermediaire tensoren te elimineren, waarbij tot 2,47x versnelling en 79,5% piekbenutting op NVIDIA H100 GPU's worden bereikt terwijl zowel PyTorch als cuBLAS wordt overtroffen in efficiëntie en numerieke nauwkeurigheid.

Oorspronkelijke auteurs: Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Gepubliceerd 2026-07-07

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een hogesnelheidsfabriek runt die complexe robots bouwt (deze robots zijn Large Language Models, zoals de modellen die chatbots aansturen). Om elke robot te bouwen, heeft je fabriek een specifieke assemblagelijn die de MLP is (een kernonderdeel van het brein van de robot).

Lange tijd had deze assemblagelijn een grote inefficiëntie. Hier is het probleem en de oplossing uit dit paper, eenvoudig uitgelegd.

Het Probleem: De "Tussenpersoon"-bottleneck

In moderne robotfabrieken wordt een specifieke stap genaamd SwiGLU gebruikt om de robots slimmer te maken. Denk aan SwiGLU als een kwaliteitscontrole die twee aparte berekeningen vereist:

Berekening A: Meet de huidige staat van de robot.
Berekening B: Meet het potentieel van de robot.
De Lijm: Combineer deze twee metingen om het eindresultaat te krijgen.

De Oude Manier (De Bottleneck):
In de standaard fabrieksopstelling (zoals die gebruikt door PyTorch), moeten de arbeiders na het uitvoeren van Berekening A de resultaten opschrijven op een gigantisch whiteboard in de gang (High-Bandwidth Memory). Daarna moeten ze naar dat whiteboard lopen, het lezen, Berekening B uitvoeren, de resultaten van die berekening op een tweede whiteboard schrijven, en vervolgens weer teruglopen om beide whiteboards te lezen om de "Lijm"-stap te doen.

Het paper ontdekte dat voor kleinere robots (kleinere AI-modellen), dit "naar het whiteboard lopen" 30% tot 37% van de totale tijd in beslag neemt. Het is alsof een chef de helft van zijn tijd doorbrengt met naar de voorraadkast lopen om een enkel kruidenpotje te pakken, in plaats van daadwerkelijk te koken.

De Oplossing: Twee Nieuwe "Superkeukens"

De auteurs hebben twee nieuwe, op maat gemaakte keukens (genaamd Kernels) gebouwd die de whiteboards volledig elimineren. In plaats van de resultaten op te schrijven en terug te lopen, houden de arbeiders de ingrediënten in hun handen (in de Registers) en voeren ze alles in één vloeiende beweging uit.

Ze creëerden twee verschillende strategieën voor verschillende fabrieksgroottes:

1. De "Ping-Pong" Keuken (Kernel-1)

Hoe het werkt: Stel je een estafette voor. Terwijl de ene arbeider de volgende lading ingrediënten ophaalt (data laden), is een andere arbeider al bezig met het mengen van de huidige lading.
De Truc: Ze gebruiken een "Ping-Pong"-schema. Terwijl de machine druk is met het ophalen van de tweede set ingrediënten, gebruiken de arbeiders precies die tijd om de "Lijm"-berekening uit te voeren op de eerste set.
Beste voor: Fabrieken die enorme robots maken (Grote Modellen) of veel robots tegelijkertijd laten draaien (Grote Batches). Het is als een enorme assemblagelijn waar genoeg arbeiders zijn om de grote machines volledig bezig te houden.

2. De "Interleaved" Keuken (Kernel-2)

Hoe het werkt: Stel je voor dat je dozen inpakt. In plaats van eerst alle rode items in te pakken en dan alle blauwe, pak je een rood item, dan een blauw item, dan weer een rode, en zo perfect afwisselend.
De Truc: Ze mengen de twee gewichtsmatrices (de "recepten" voor de berekeningen) samen voordat ze beginnen. Dit stelt de arbeiders in staat om een "rood" en een "blauw" ingrediënt tegelijkertijd te pakken en deze direct samen te verwerken.
Beste voor: Fabrieken die kleinere robots maken of minder robots tegelijkertijd laten draaien (Kleine Batches). Deze methode is zo efficiënt dat het de fabrieksvloer volledig bezet houdt met arbeiders, zodat niemand stilstaat te wachten.

De Resultaten: Snelheid en Nauwkeurigheid

De auteurs hebben deze nieuwe keukens getest op NVIDIA H100 chips (de krachtigste AI-processors die momenteel beschikbaar zijn) met diverse robotgroottes (van minuscule 0.5B modellen tot enorme 72B modellen).

Enorme Snelheidsverbeteringen: Voor de kleinere robots waren de nieuwe keukens 2,47 keer sneller dan de oude standaard. Dat is alsof je een taak van 10 minuten terugbrengt naar 4 minuten.
Verschuiving van de Bottleneck: Het oude systeem was "Memory-Bound" (het besteedde te veel tijd aan het lopen naar het whiteboard). Het nieuwe systeem is "Compute-Bound" (het besteedt al zijn tijd aan het daadwerkelijk doen van de wiskunde). Ze bereikten 79,5% van de maximale theoretische snelheid van de chip.
De Compiler Kan het Niet: De auteurs probeerden de standaard "auto-piloot" software (PyTorch's torch.compile) te gebruiken om dit automatisch op te lossen. Dat mislukte. De auto-piloot was 3 tot 7 keer langzamer dan hun aangepaste keukens. Dit bewijst dat voor dit specifieke probleem een menselijke expert nodig is om een handgemaakte oplossing te maken; de computer kan het nog niet zelf uitzoeken.
Betere Nauwkeurigheid: Verrassend genoeg waren de nieuwe aangepaste keukens ook nauwkeuriger dan de standaardmethode. De standaardmethode had kleine rekenfouten in 4,5% tot 11% van de resultaten, terwijl de nieuwe keukens nul fouten hadden.

Samenvatting

Het paper laat zien dat door de werking van de fabrieksvloer te reorganiseren — specifweg door de arbeiders te stoppen met het constant naar het whiteboard lopen om tussentijdse aantekeningen te lezen of te schrijven — ze AI-modellen aanzienlijk sneller kunnen laten draaien, vooral voor kleinere modellen die gebruikt worden op randapparaten (zoals telefoons of laptops). Ze bewezen dat standaard softwaretools deze efficiëntie niet kunnen evenaren; er is gespecialiseerde, handgeschreven code nodig om deze resultaten te behalen.

Technische Samenvatting: Tile-Level Activatie Overlap voor Efficiënte LLM Inferentie

Probleemstelling

Moderne Large Language Models (LLM's), inclusief Qwen-2.5, LLaMA, Mistral en Gemma, maken voornamelijk gebruik van de SwiGLU activatiefunctie. Deze gated MLP-structuur berekent $Y = \text{SiLU}(A \times W_1) \odot (A \times W_2)$ , wat twee onafhankelijke matrixvermenigvuldigingen (GeMM's) vereist, gevolgd door een elementgewijze gated activatie.

In standaardimplementaties materialiseert dit proces twee volledige intermediaire tensoren ($Gate$ en $Up$) in High-Bandwidth Memory (HBM) tussen de GeMM- en de activatiefase. Profiling op NVIDIA H100 GPU's onthult dat deze intermediaire materialisatie en de bijbehorende activatieberekening 9–37% van de totale MLP-executietijd in beslag nemen. De overhead is het grootst voor kleinere modellen (bijv. Qwen-2.5 0.5B), waarbij SwiGLU meer dan 30% van de MLP-tijd beslaat. Naarmate de Tensor Core rekenkundige dichtheid toeneemt via kwantisatie (FP8, INT4), groeit de relatieve kosten van deze geheugen-gebonden operaties, wat een significante bottleneck creëert.

Bestaande compiler-infrastructuur, specifiek PyTorch's torch.compile, slaagt er niet in dit aan te pakken. Het kan operaties niet fuseren over twee afzonderlijke GeMM's met verschillende gewichtsmatrices vanwege fundamentele beperkingen in graph-level fusion passes. Experimenten tonen aan dat torch.compile slechts 34–94% van de eager PyTorch-prestaties bereikt voor dit patroon, waarbij expliciete fusion-hints slechts marginale verbetering bieden.

Methodologie

De auteurs presenteren twee complementaire, handgemaakte CUTLASS-gebaseerde SM90-kernels die SwiGLU op tile-niveau in de GeMM fuseren, waardoor intermediaire HBM-materialisatie wordt geëlimineerd. Beide kernels maken gebruik van de Tensor Memory Accelerator (TMA) en de warp-specialized scheduling die beschikbaar is op de H100 (SM90).

1. Kernel-1: Sync SwiGLU via Pingpong Schedule Overlap

Mechanisme: Deze kernel maakt gebruik van de CUTLASS Pingpong warp-specialized schedule, die warps partitioneert in producenten (die data laden via TMA) en consumenten (die MMA uitvoeren).
Strategie: Het creëert een $[M, N]$ threadblock grid. Binnen de consumentenfase, nadat de Gate-tile is berekend maar voordat de Up-tile data arriveert, is er een kort venster waarin de consument-warps idle zijn. De kernel benut dit venster om de Swish-activatie ( $\text{SiLU}(Gate)$ ) uit te voeren op de register-resident Gate-accumulator.
Overlap: De Swish-berekening overlapt temporeel met de TMA-loads van de producer voor de Up-gewicht-tiles. De uiteindelijke elementgewijze vermenigvuldiging ( $\text{SiLU}(Gate) \odot Up$ ) en opslag vinden plaats in de epiloog.
Optimalisatie: Dit ontwerp is geoptimaliseerd voor grote batchgroottes ( $M \ge 2048$ ) waar het $[M, N]$ grid de Streaming Multiprocessors (SM's) van de GPU voldoende verzadigt.

2. Kernel-2: Interleave SwiGLU via Custom Epilogue Visitor Tree

Mechanisme: Deze kernel introduceert een aangepaste Epilogue Visitor Tree (EVT) node genaamd PairMulStore.
Strategie: Het concateneert gewichtsmatrices $W_1$ en $W_2$ tot een enkele gefuseerde matrix $W_{fused} \in \mathbb{R}^{K \times 2N}$ met geïnterleavde kolommen (even kolommen voor Gate, oneven voor Up). De kernel lanceert een standaard GeMM over $[M, 2N, K]$ , wat een $[M, 2N]$ threadblock grid creëert.
Fusion: De PairMulStore node opereert op de $[M, 2N]$ accumulator binnen elke threadblock. Het leest aangrenzende kolomparen $(D[m, 2n], D[m, 2n+1])$ , past $\text{SiLU}(D[m, 2n]) \odot D[m, 2n+1]$ toe, en slaat het resultaat op.
Overlap: Dit ontwerp interleaveert SwiGLU-berekening met tile-stores. De aritmetiek van de huidige tile overlapt met de asynchrone TMA-stores van de vorige tile, wat zorgt voor compute-store overlap.
Optimalisatie: De $2\times$ toename in het aantal threadblocks verbetert de SM-occupancy aanzienlijk voor kleine batchgroottes ( $M \le 2048$ ), waardoor dit de geprefereerde standaard wordt voor de meeste configuraties.

Belangrijkste Bijdragen

Tile-Level Fusion: De eerste implementatie die SwiGLU op tile-niveau in GeMM fuseert, waardoor 4 intermediaire HBM-operaties (lezen/schrijven van Gate en Up) per inferentiestap worden geëlimineerd.
Dual-Kernel Strategie: Een complementaire aanpak met gebruik van Kernel-1 voor grote batches (sequentiële Gate→Swish→Up) en Kernel-2 voor kleine batches (geïnterleveerde gewichten met custom EVT), die bezettings- en scheduling-beperkingen verschillend aanpakken.
Numerieke Superieuriteit: De gefuseerde kernels bereiken nul mismatches (0% elementen met >1% relatieve fout) vergeleken met een FP32-referentie, terwijl de baseline cuBLAS-implementatie 4,5–11% mismatches vertoont door agressieve BF16 partiële accumulatie over tiles.
Validatie van Compiler Beperkingen: Empirisch bewijs dat torch.compile deze fusion niet kan repliceren, waarbij het 3–7× trager blijft dan de handgemaakte kernels.

Resultaten

Geëvalueerd op Qwen-2.5 modellen (0.5B tot 72B) op NVIDIA H100:

Versnelling: De kernels bereiken tot wel 2,47× versnelling ten opzichte van PyTorch eager (cuBLAS + aparte SwiGLU). Kernel-2 wint in 13/20 geteste configuraties, terwijl Kernel-1 wint in 7/20 (voornamelijk voor grote modellen bij hoge batchgroottes).
Regime Shift: Roofline-analyse bevestigt dat fusion de workloads verschuift van geheugen-gebonden naar rekenkundig-gebonden. Voor kleine modellen neemt de rekenkundige intensiteit met tot wel 247% toe, waardoor het werkpunt over de roofline-rand verschuift.
Utilisatie: De piek BF16-utilisatie bereikt 79,5% op H100, wat bijna de verdubbeling is van de utilisatie van de baseline voor kleine modellen.
Efficiëntie: De fusion-efficiëntie (werkelijke versnelling vs. theoretische geheugenbesparing) is bijna 100% voor kleine modellen. Voor Kernel-2 overstijgt de efficiëntie in enkele configuraties zelfs de 100% vanwege de voordelen van compute-store overlap.
Schaalbaarheid: De versnelling neemt af met de modelgrootte (2,47× voor 0.5B vs. ~1,0× voor 72B bij hoge batchgroottes), omdat de GeMM-berekening de totale tijd domineert en het relatieve aandeel van het intermediaire geheugentrafiek afneemt.

Betekenis

Het paper betoogt dat voor moderne LLM-inferentie, met name voor edge-deployment en mobiel-georiënteerde modellen (0.5B–14B), de bottleneck is verschoven van ruwe rekenkracht naar geheugentraffic veroorzaakt door de materialisatie van intermediaire tensoren. De auteurs demonstreren dat handgemaakte, hardware-bewuste tile-level design noodzakelijk is om de beperkingen van de huidige compiler-infrastructuur te overwinnen. Door intermediaire HBM-toegang te elimineren en activatieberekening te overlappen met datamovement, verminderen deze kernels de inferentielatentie aanzienlijk en verbeteren ze de rekenkundige utilisatie, wat een cruciale optimalisatie biedt voor productie-serving systemen waar latentie en throughput beperkt zijn.