🤖 machine learning

Tile-Level Activation Overlap for Efficient LLM Inference

Dieses Paper führt zwei spezialisierte CUTLASS-basierte SM90-Kernel ein, die SwiGLU-Aktivierung auf Tile-Ebene mit Matrixmultiplikation fusionieren, um den Overhead durch die Materialisierung intermediärer Tensoren zu eliminieren, wodurch eine bis zu 2,47-fache Beschleunigung und eine Spitzenauslastung von 79,5 % auf NVIDIA H100-GPUs erreicht werden, während sie sowohl PyTorch als auch cuBLAS in Bezug auf Effizienz und numerische Genauigkeit übertreffen.

Ursprüngliche Autoren: Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Veröffentlicht 2026-07-07

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Abhinav Jangda, Tyler Sorensen, Sebastian Burckhardt, Jianlan YE, Chaoyin Li, Atul Gupta

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie betreiben eine Hochgeschwindigkeitsfabrik, die komplexe Roboter baut (diese Roboter sind Large Language Models, wie sie die Chatbots antreiben). Um jeden Roboter zu bauen, verfügt Ihre Fabrik über eine spezielle Montagelinie, die der MLP (ein Kernteil des Gehirns des Roboters) entspricht.

Lange Zeit hatte diese Montagelinie eine erhebliche Ineffizienz. Hier ist das Problem und die in diesem Paper vorgestellte Lösung, einfach erklärt.

Das Problem: Der „Mittelsmann“-Engpass

In modernen Roboterfabriken wird ein spezieller Schritt namens SwigLU verwendet, um die Roboter intelligenter zu machen. Stellen Sie sich SwigLU wie eine Qualitätskontrolle vor, die zwei separate Berechnungen erfordert:

Berechnung A: Den aktuellen Zustand des Roboters messen.
Berechnung B: Das Potenzial des Roboters messen.
Der Kleber (The Glue): Diese beiden Messungen kombinieren, um das Endergebnis zu erhalten.

Der alte Weg (Der Engpass):
Im Standard-Fabrikszenario (wie es etwa von PyTorch verwendet wird) müssen die Arbeiter nach der Durchführung von Berechnung A die Ergebnisse auf ein riesiges Whiteboard im Flur schreiben (High-Bandwidth Memory). Dann müssen sie zum Whiteboard gehen, das Whiteboard lesen, Berechnung B durchführen, das Ergebnis von B ebenfalls auf ein zweites Whiteboard schreiben und schließlich zurückgehen, um beide Whiteboards zu lesen, um den „Kleber“-Schritt auszuführen.

Das Paper stellte fest, dass dieser „Weg zum Whiteboard“ bei kleineren Robotern (kleineren KI-Modellen) 30 % bis 37 % der gesamten Zeit ausmacht. Es ist, als würde ein Koch die Hälfte seiner Zeit damit verbringen, in die Speisekammer zu laufen, um ein einzelnes Gewürz zu holen, anstatt zu kochen.

Die Lösung: Zwei neue „Super-Küchen“

Die Autoren haben zwei neue, speziell entwickelte Küchen (genannt Kernels) gebaut, die die Whiteboards komplett eliminieren. Anstatt die Ergebnisse aufzuschreiben und zurückzugehen, behalten die Arbeiter die Zutaten direkt in den Händen (in den Registern) und erledigen alles in einer kontinuierlichen Bewegung.

Sie entwickelten zwei verschiedene Strategien für unterschiedliche Fabrikgrößen:

1. Die „Ping-Pong“-Küche (Kernel-1)

Wie es funktioniert: Stellen Sie sich ein Staffellauf vor. Während ein Arbeiter die nächste Ladung der Zutaten holt (Daten lädt), mischt ein anderer Arbeiter bereits die aktuelle Ladung.
Der Trick: Sie nutzen einen „Ping-Pong“-Zeitplan. Während die Maschine mit dem Abrufen des zweiten Satzes an Zutaten beschäftigt ist, nutzen die Arbeiter genau diese Zeit, um die Mathematik des „Klebers“ auf dem ersten Satz auszuführen.
Bestens geeignet für: Fabriken, die riesige Roboter (Große Modelle) bauen oder viele Roboter gleichzeitig laufen lassen (Große Batches). Es ist wie eine massive Montagelinie, bei der genügend Arbeiter vorhanden sind, um die großen Maschinen voll auszulasten.

2. Die „Interleaved“-Küche (Kernel-2)

Wie es funktioniert: Stellen Sie sich vor, Sie packen Kartons. Anstatt erst alle roten Gegenstände und dann alle blauen zu packen, packen Sie abwechselnd einen roten, dann einen blauen, dann wieder einen roten usw.
Der Trick: Sie mischen die beiden Gewichtmatrizen (die „Rezepte“ für die Berechnungen) zusammen, bevor Sie beginnen. Dies ermöglicht es den Arbeitern, eine „rote“ und eine „blaue“ Zutat gleichzeitig zu greifen und sie sofort gemeinsam zu verarbeiten.
Bestens geeignet für: Fabriken, die kleinere Roboter bauen oder weniger Roboter gleichzeitig laufen lassen (Kleine Batches). Diese Methode ist so effizient, dass sie den Fabrikboden voll mit Arbeitern besetzt hält und verhindert, dass jemand untätig herumsteht und wartet.

Die Ergebnisse: Geschwindigkeit und Genauigkeit

Die Autoren testeten diese neuen Küchen auf NVIDIA H100-Chips (den leistungsfähigsten KI-Prozessoren, die verfügbar sind) unter Verwendung verschiedener Robotergrößen (von winzigen 0,5B-Modellen bis hin zu massiven 72B-Modellen).

Massive Beschleunigungen: Für die kleineren Roboter waren die neuen Küchen 2,47-mal schneller als der alte Standard. Das ist, als würde man eine 10-minütige Aufgabe auf 4 Minuten verkürzen.
Verschiebung des Engpasses: Das alte System war „speichergebunden“ (Memory-Bound – es verbrachte zu viel Zeit mit dem Gehen zum Whiteboard). Das neue System ist „rechengebunden“ (Compute-Bound – es verbringt die gesamte Zeit mit der eigentlichen Mathematik). Sie erreichten 79,5 % der maximal theoretischen Geschwindigkeit des Chips.
Der Compiler kann es nicht: Die Autoren versuchten, die Standard-„Autopiloten“-Software (PyTorchs torch.compile) zu nutzen, um dies automatisch zu beheben. Er scheiterte. Der Autopilot war 3- bis 7-mal langsamer als ihre maßgeschneiderten Küchen. Dies beweist, dass man für dieses spezifische Problem einen menschlichen Experten benötigt, der die Lösung handverlesen erstellt; der Computer kann es noch nicht allein herausfinden.
Bessere Genauigkeit: Überraschenderweise waren die neuen maßgeschneiderten Küchen auch genauer als die Standardmethode. Die Standardmethode wies bei 4,5 % bis 11 % der Ergebnisse kleine mathematische Fehler auf, während die neuen Küchen null Fehler aufwiesen.

Zusammenfassung

Das Paper zeigt, dass durch die Umgestaltung der Arbeitsweise auf dem Fabrikboden – insbesondere durch das Verhindern des ständigen Gehens der Arbeiter zum Whiteboard, um Zwischennotizen zu lesen oder zu schreiben – KI-Modelle signifikant schneller laufen können, besonders bei kleineren Modellen, die auf Edge-Geräten (wie Telefonen oder Laptops) eingesetzt werden. Sie haben bewiesen, dass Standard-Softwaretools diese Effizienz nicht replizieren können und dass spezialisierter, handgeschriebener Code erforderlich ist, um diese Ergebnisse zu erzielen.

Technisches Resümee: Tile-Level Activation Overlap für effiziente LLM-Inferenz

Problemstellung

Moderne Large Language Models (LLMs), einschließlich Qwen-2.5, LLaMA, Mistral und Gemma, verwenden vorwiegend die SwiGLU-Aktivierungsfunktion. Diese gated MLP-Struktur berechnet $Y = \text{SiLU}(A \times W_1) \odot (A \times W_2)$ , was zwei unabhängige Matrixmultiplikationen (GeMMs) gefolgt von einer elementweisen Gated-Aktivierung erfordert.

In Standardimplementierungen führt dieser Prozess dazu, dass zwei vollständige Zwischen-Tensoren ($Gate$ und $Up$) zwischen der GeMM- und der Aktivierungsphase im High-Bandwidth Memory (HBM) materialisiert werden. Profiling auf NVIDIA H100-GPUs zeigt, dass diese Materialisierung der Zwischen-Tensoren und die damit verbundene Aktivierungsberechnung 9–37 % der gesamten MLP-Ausführungszeit beanspruchen. Der Overhead ist bei kleineren Modellen (z. B. Qwen-2.5 0.5B) am stärksten ausgeprägt, wo SwiGLU über 30 % der MLP-Zeit ausmacht. Da die Arithmetik-Dichte der Tensor Cores durch Quantisierung (FP8, INT4) steigt, wächst die relativen Kosten dieser speichergebundenen Operationen, was einen signifikanten Flaschenhals schafft.

Die bestehende Compiler-Infrastruktur, insbesondere PyTorchs torch.compile, kann dies nicht adressieren. Sie ist nicht in der Lage, Operationen über zwei separate GeMMs mit unterschiedlichen Gewichtmatrizen hinweg zu fusionieren, was auf grundlegende Einschränkungen in den Graph-Level-Fusion-Passes zurückzuführen ist. Experimente zeigen, dass torch.compile lediglich 34–94 % der Eager-PyTorch-Performance für dieses Muster erreicht, wobei explizite Fusion-Hinweise nur vernachlässigbare Verbesserungen bringen.

Methodik

Die Autoren präsentieren zwei komplementäre, handgefertigte CUTLASS-basierte SM90-Kernel, die SwiGLU auf Tile-Ebene in das GeMM fusionieren und so die Materialisierung von Zwischen-Tensoren im HBM eliminieren. Beide Kernel nutzen den Tensor Memory Accelerator (TMA) und das warp-spezialisierte Scheduling der H100 (SM90).

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

Mechanismus: Dieser Kernel nutzt das CUTLASS Pingpong-Warp-spezialisierte-Scheduling, welches Warps in Produzenten (Laden von Daten via TMA) und Konsumenten (Ausführung von MMA) unterteilt.
Strategie: Er erstellt ein $[M, N]$ Threadblock-Grid. Innerhalb der Konsumentenphase gibt es nach der Berechnung des Gate-Tiles, aber vor dem Eintreffen der Up-Tile-Daten, ein kurzes Zeitfenster, in dem die Konsumenten-Warps untätig sind. Der Kernel nutzt dieses Fenster, um die Swish-Aktivierung ( $\text{SiLU}(Gate)$ ) auf dem im Register befindlichen Gate-Akkumulator zu berechnen.
Overlap: Die Swish-Berechnung überlappt zeitlich mit den TMA-Loads der Up-Gewicht-Tiles durch den Produzenten. Die abschließende elementweise Multiplikation ( $\text{SiLU}(Gate) \odot Up$ ) und das Speichern erfolgen im Epilog.
Optimierung: Dieses Design ist für große Batch-Größen ( $M \ge 2048$ ) optimiert, bei denen das $[M, N]$ Grid die Streaming Multiprocessors (SMs) der GPU ausreichend sättigt.

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

Mechanismus: Dieser Kernel führt einen benutzerdefinierten Epilogue Visitor Tree (EVT) Knoten namens PairMulStore ein.
Strategie: Er konkateniert die Gewichtmatrizen $W_1$ und $W_2$ zu einer einzigen fusionierten Matrix $W_{fused} \in \mathbb{R}^{K \times 2N}$ mit verschachtelten Spalten (gerade Spalten für Gate, ungerade für Up). Der Kernel startet ein Standard-GeMM über $[M, 2N, K]$ , wodurch ein $[M, 2N]$ Threadblock-Grid entsteht.
Fusion: Der PairMulStore-Knoten operiert auf dem $[M, 2N]$ Akkumulator innerhalb jedes Threadblocks. Er liest benachbarte Spaltenpaare $(D[m, 2n], D[m, 2n+1])$ , wendet $\text{SiLU}(D[m, 2n]) \odot D[m, 2n+1]$ an und speichert das Ergebnis.
Overlap: Dieses Design verschachtelt die SwiGLU-Berechnung mit den Tile-Speicheroperationen. Die Arithmetik des aktuellen Tiles überlappt mit den asynchronen TMA-Speicheroperationen des vorherigen Tiles, was einen Compute-Store-Overlap ermöglicht.
Optimierung: Die Verdoppelung der Anzahl der Threadblocks verbessert die SM-Belegung bei kleinen Batch-Größen ( $M \le 2048$ ) erheblich, was ihn zur bevorzugten Standardlösung für die meisten Konfigurationen macht.

Zentrale Beiträge

Tile-Level Fusion: Die erste Implementierung, die SwiGLU auf Tile-Ebene in GeMM fusioniert und damit 4 Zwischen-HBM-Operationen (Lese-/Schreibvorgänge von Gate und Up) pro Inferenzschritt eliminiert.
Dual-Kernel-Strategie: Ein komplementärer Ansatz unter Verwendung von Kernel-1 für große Batches (sequentiell Gate $\rightarrow$ Swish $\rightarrow$ Up) und Kernel-2 für kleine Batches (verschachtelte Gewichte mit benutzerdefiniertem EVT), der Besetzungs- und Scheduling-Beschränkungen unterschiedlich adressiert.
Numerische Überlegenheit: Die fusionierten Kernel erreichen null Mismatch (0 % Elemente mit $>1\,\%$ relativer Abweichung) im Vergleich zu einer FP32-Referenz, während die Baseline-cuBLAS-Implementierung aufgrund aggressiver BF16-Teilakkumulation über Tiles hinweg 4,5–11 % Mismatches aufweist.
Validierung von Compiler-Limitierungen: Empirische Belege, dass torch.compile diese Fusion nicht replizieren kann und dabei 3–7-mal langsamer bleibt als die handgefertigten Kernel.

Ergebnisse

Evaluierung auf Qwen-2.5 Modellen (0.5B bis 72B) auf NVIDIA H100:

Beschleunigung: Die Kernel erzielen eine bis zu 2,47-fache Beschleunigung gegenüber PyTorch Eager (cuBLAS + separate SwiGLU). Kernel-2 gewinnt in 13 von 20 getesteten Konfigurationen, während Kernel-1 in 7 von 20 gewinnt (primär für große Modelle bei hohen Batch-Größen).
Regime Shift: Eine Roofline-Analyse bestätigt, dass die Fusion die Arbeitslast von speichergebunden zu rechengebunden verschiebt. Für kleine Modelle steigt die arithmetische Intensität um bis zu 247 %, wodurch der Betriebspunkt über den Roofline-Grat verschoben wird.
Auslastung: Die Spitzen-BF16-Auslastung erreicht 79,5 % auf der H100, was die Auslastung der Baseline für kleine Modelle nahezu verdoppelt.
Effizienz: Die Fusionseffizienz (tatsächliche Beschleunigung vs. theoretische Speicherersparnis) liegt bei kleinen Modellen nahe 100 %. Für Kernel-2 übersteigt die Effizienz in mehreren Konfigurationen 100 %, was auf die Vorteile des Compute-Store-Overlaps zurückzuführen ist.
Skalierbarkeit: Die Beschleunigung nimmt mit der Modellgröße ab (2,47× für 0.5B vs. ~1,0× für 72B bei hohen Batch-Größen), da die GeMM-Berechnung die Gesamtzeit dominiert und der relative Anteil des Zwischenspeicher-Traffics sinkt.

Bedeutung

Das Paper argumentiert, dass sich der Flaschenhals für moderne LLM-Inferenz, insbesondere bei Edge-Deployment und mobilen Modellen (0.5B–14B), von der reinen Rechenleistung hin zum Speicherverkehr verschoben hat, der durch die Materialisierung von Zwischen-Tensoren verursacht wird. Die Autoren zeigen, dass ein handgefertigtes, hardware-bewusstes Tile-Level-Design notwendig ist, um die Einschränkungen aktueller Compiler-Infrastrukturen zu überwinden. Durch die Eliminierung von Zwischen-HBM-Zugriffen und das Überlappen der Aktivierungsberechnung mit der Datenbewegung reduzieren diese Kernel die Inferenzlatenz signifikant und verbessern die Rechenauslastung, was eine kritische Optimierung für produktive Serving-Systeme darstellt, bei denen Latenz und Durchsatz begrenzt sind.