🤖 AI

Memory-Bound but Not Bandwidth-Limited: The Physical AI Inference Gap in Batch-1 LLM Decode

Diese Arbeit zeigt auf, dass während die Batch-1-LLM-Inferenz der Physical AI speicherdominiert ist, schnellere GPUs unter unverhältismäßigen Launch-seitigen Overheads leiden, die proportionale Latenzgewinne verhindern, und dass Standard-Quantisierungsmethoden oft keine erwarteten Beschleunigungen erzielen, sofern sie nicht mit hochoptimierten Kernel wie GPTQ+ExLlamaV2 kombiniert werden.

Ursprüngliche Autoren: Josef Chen

Veröffentlicht 2026-06-01

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Josef Chen

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

Das große Ganze: Das "schnelle Auto" vs. der "Stau"

Stellen Sie sich vor, Sie versuchen, mit einem Auto von Punkt A nach Punkt B zu fahren. Sie haben zwei Arten von Autos:

Das L4: Eine zuverlässige, Standard-Limousine.
Das H100: Ein hyper-schnelles Formel-1-Rennauto mit einem gewaltigen Motor.

Die Arbeit stellt eine einfache Frage: Wenn Sie alleine fahren (Batch-1) und nur eine winzige Menge Gepäck transportieren müssen (einen einzelnen Roboter oder eine Nutzersitzung), welches Auto bringt Sie schneller ans Ziel?

Die gängige Annahme war: "Das Formel-1-Auto (H100) ist 11-mal schneller, weil es einen viel größeren Motor (Speicherbandbreite) hat. Es sollte jedes Mal gewinnen."

Das Ergebnis der Arbeit: Das Formel-1-Auto verliert tatsächlich, oder gewinnt zumindest nicht nennenswert. Warum? Weil das Rennauto so schnell ist, dass die Zeit, die man benötigt, um den Motor zu starten und den Gang einzulegen (CPU-Launch-Overhead), zum größten Hindernis wird. Beim langsameren Auto ist der Motor der Flaschenhals, daher spielt das Starten des Motors keine so große Rolle.

Das Kernproblem: Die "Start-Steuer" (Launch Tax)

In der Welt der KI, wenn ein Computer ein Wort (Token) nach dem anderen generiert, muss er immer wieder eine bestimmte Reihe von Aufgaben ausführen.

Die alte Sichtweise: Die Geschwindigkeit hängt ausschließlich davon ab, wie schnell der Computer seinen Speicher lesen kann (wie schnell ein Bibliothekar zu den Regalen rennen kann, um Bücher zu holen). Das H100 hat super-schnelle Regale, also sollte es instantan sein.
Die neue Sichtweise: Die Geschwindigkeit hängt davon ab, wie oft der Computer sagen muss: "Okay, starte diese Aufgabe!" zur Hardware.

Die Analogie:
Stellen Sie sich einen Lieferfahrer (die GPU) vor, der ein Paket zustellen muss.

Beim L4 (langsamer Fahrer): Der Fahrer verbringt 20 Minuten mit der Fahrt zum Haus und 1 Minute mit dem Parken. Die Fahrt ist der Flaschenhals.
Beim H100 (schneller Fahrer): Der Fahrer kann in 1 Minute zum Haus fahren. Aber jedes Mal, wenn er ein Paket abgibt, muss er 30 Sekunden lang vom LKW zum Haus laufen, ein Formular unterschreiben und wieder zurücklaufen.
- Da die Fahrt so schnell ist, wird dieser 30-sekündige "Weg zur Tür" (die Start-Ste Steuer/Launch Tax) zum Hauptgrund, warum die Lieferung langsam ist.
- Das H100 ist so leistungsstark, dass es untätig herumsteht und darauf wartet, dass der Fahrer die Papierarbeit erledigt.

Das Experiment: "Die Graphen" als Lösung

Um dies zu beweisen, versuchten die Forscher einen Trick namens CUDA Graphs.

Die Analogie:
Anstatt den Fahrer bei jedem einzelnen Paket fragen zu lassen: "Kann ich starten? Okay, los. Kann ich starten? Okay, los", schreiben sie ein Master-Skript (einen Graphen), das besagt: "Fahren, Parken, Abgeben, Zurückkehren, Wiederholen." Sie übergeben dieses Skript dem Fahrer einmalig, und der Fahrer folgt einfach dem Skript, ohne jedes Mal um Erlaubnis zu fragen.

Die Ergebnisse:

Beim H100 (Rennauto): Dieses Skript machte einen riesigen Unterschied. Das Auto wurde um 26 % schneller. Dies bewies, dass die "Papierarbeit" (der Launch-Overhead) tatsächlich das Problem war.
Beim L4 (Limousine): Das Skript machte fast keinen Unterschied (nur 3 % schneller). Das liegt daran, dass die Limousine bereits die meiste Zeit mit dem Fahren (Lesen des Speichers) verbrachte und nicht mit dem Warten auf die Papierarbeit.

Die "invertierte" Kostenleiter

Hier ist der überraschendste Teil der Arbeit.

Normalerweise denken Unternehmen: "Wenn ich Geld sparen will, sollte ich den günstigsten, langsamsten Chip kaufen (L4). Wenn ich Geschwindigkeit will, kaufe ich den teuren, schnellen Chip (H100)."

Die Arbeit sagt: Für Single-Stream-KI (wie ein Roboter, der mit Ihnen spricht), ist das genau umgekehrt.

Das H100 ist teuer und schnell, aber es verschwendet viel seiner Geschwindigkeit auf die "Papierarbeit".
Das L4 ist günstig und langsam, aber es nutzt 100 % seiner Geschwindigkeit für die eigentliche Arbeit.

Der "magische Trick":
Die Forscher fanden heraus, dass man, wenn man das günstige L4 nimmt und eine spezielle Art der Software-"Kompression" verwendet (genannt ExLlamaV2), das L4 fast so schnell wie das H100 wird.

H100 mit Tricks: 11,78 Millisekunden pro Schritt.
L4 mit Tricks: 17,36 Millisekunden pro Schritt.

Obwohl das H100 auf dem Papier 11-mal leistungsstärker ist, ist das L4 (mit der richtigen Software) nur etwa 1,5-mal langsamer, kostet aber 10-mal weniger im Betrieb.

Zusammenfassung der wichtigsten Erkenntnisse

Schnell ist nicht immer schneller: Nur weil ein Chip eine größere "Speicherautobahn" (Bandbreite) hat, bedeutet das nicht, dass er die Aufgabe schneller erledigt, wenn die "Startzeit" (Launch-Overhead) zu lang ist.
Der Flaschenhals verschiebt sich:
- Bei günstigen Chips (L4) ist der Flaschenhals das Bewegen von Daten (Speicherbandbreite).
- Bei teuren Chips (H100) ist der Flaschenhals das Starten der Aufgaben (CPU-Launch-Overhead).
Software zählt mehr als Hardware: Für diese spezifischen "Ein-nach-dem-anderen"-KI-Aufgaben ist die Wahl der richtigen Software (wie ExLlamaV2) auf einem günstigen Chip ein besseres Geschäft als der Kauf des teuersten Chips.
Für wen ist das gedacht? Dies gilt für Physische KI: Roboter, selbstfahrende Autos und persönliche Assistenten, die in Echtzeit mit Ihnen sprechen. Es gilt nicht für Chatbots, die mit tausenden Menschen gleichzeitig kommunizieren (Batch-Verarbeitung), da hier die Regeln anders sind.

Kurz gesagt: Wenn Sie einen Roboter bauen, der in Echtzeit denken und mit Ihnen sprechen muss, kaufen Sie nicht einfach den teuersten Supercomputer. Kaufen Sie einen günstigeren Computer und optimieren Sie die Software, damit sie nicht zu viel Zeit mit "Papierarbeit" verschwendet. So erhalten Sie eine bessere Leistung für weniger Geld.

Technisches Resümee: Speichergebunden, aber nicht bandbreitenlimitiert: Die physische KI-Inferenz-Lücke beim Batch-1 LLM-Decode

Problemstellung

Physische KI-Systeme (Roboter, autonome Fahrzeuge, Edge-Copiloten) arbeiten typischerweise unter einer Single-Stream, Batch-1 autoregressiven Decode-Workload. Im Gegensatz zum Cloud-Serving, das auf Durchsatz durch große Batches optimiert, wartet die physische KI auf das nächste Token für einen einzelnen Nutzer oder Agenten. Die vorherrschende Branchenannahme ist, dass dieser Workload strikt HBM-bandbreitengebunden ist, was bedeutet, dass die Latenz invers proportional zur Spitzen-Speicherbandbreite ( $B_{peak}$ ) skaliert. Folglich wird die Deployment-Leiter als $L4 \to L40S \to A100 \to H100$ angenommen, wobei höhere Bandbreite direkt zu geringerer Latenz und niedrigeren Kosten pro Token führt.

Dieses Paper stellt diese Annahme infrage und argumentiert, dass bei einem Batch-1 Decode auf schneller Silizium-Hardware (z. B. H100) der Flaschenhals von der Speicherbandbreite zum CPU-Kernel-Launch-Overhead pro Kernel wechselt. Die Autoren postulieren, dass schnellerer Speicher nicht zu proportionalen Latenzgewinnen führt, da die fixen Kosten für den Kernel-Launch auf Hochleistungs-GPUs zum dominierenden Anteil der Schrittzeit werden, während langsamere GPUs tatsächlich bandbreitengebunden bleiben.

Methodik

Die Studie ist ein kontrolliertes Mess-Experiment, kein theoretisches Modell, durchgeführt auf Modal Cloud-Hosts mit vier NVIDIA-GPUs: H100 SXM5, A100-80GB SXM4, L40S und L4.

Workload: Drei 7–8B Parameter GQA-Transformer (Qwen-2.5-7B, Mistral-7B-v0.3, Llama-3.1-8B) mit bf16-Gewichten und SDPA-Attention.
Umfang: 44 valide Zellen abdeckend für 4 Kontextlängen (2048 bis 16384) und 4 GPUs.
Metriken:
- $R_{floor}$ : Das Verhältnis der analytischen Speicher-Untergrenze ( $t_{floor} = (W+K)/B_{peak}$ ) zur beobachteten Schrittzeit ( $t_{obs}$ ). Ein Wert von 1,0 indiziert eine perfekte Speicherbandbreitennutzung.
- CUDA Graphs A/B Test: Ein Falsifikations-Experiment, das „Eager“-Execution gegen „Graphed“-Execution (erfasste DAG-Wiedergabe) vergleicht, um den Launch-Overhead zu isolieren.
- Software-Stack-Matrix: Vergleiche verschiedener Attention-Backends (SDPA, FlashAttention-2/3, FlashInfer) und Quantisierungs-Pfade (bf16, bnb-nf4, AutoAWQ+Marlin, GPTQ+ExLlamaV2).

Kernergebnisse

1. Die invertierte Cost-Per-Token-Leiter

Die Studie zeigt eine drastische Divergenz in der Bandbreitennutzung auf:

L4 (300 GB/s): Erreicht ~81 % der Spitzen-HBM-Bandbreite ( $R_{floor} \approx 0,81$ ). Der Workload ist wahrhaft speichergebunden.
H100 (3350 GB/s): Erreicht nur ~27 % der Spitzen-HBM-Bandbreite ( $R_{floor} \approx 0,27$ ).
Implikation: Der 11-fache Bandbreitenvorteil der H100 gegenüber der L4 führt nicht zu einer 11-fachen Beschleunigung. Stattdessen wird die H100 durch den Launch-Overhead ausgebremst, während die L4 durch den Speicherverkehr gebremst wird.

2. CUDA Graphs Falsifikations-Test

Die Autoren isolierten den Mechanismus, indem sie den CPU-Launch-Overhead mittels CUDA Graphs entfernten:

Auf H100 (ctx=2048): CUDA Graphs verbesserten die Latenz um den Faktor 1,259× (95 % Konfidenzintervall [1,253, 1,267]). Dies bestätigt, dass der Launch-Overhead etwa 20 % der Schrittzeit ausmacht.
Auf L4 (ctx=2048): Dieselbe Intervention lieferte nur eine Verbesserung von 1,028×.
Fazit: Die „Launch-Steuer“ ist die bindende Beschränkung für die H100 beim Batch-1 Decode, während die Bandbreite die bindende Beschränkung für die L4 ist.

3. Auswahl der Attention-Kernel

Entgegen der Überzeugung, dass FlashAttention-Varianten immer überlegen sind:

Auf H100 Batch-1 übertraf der PyTorch Standard SDPA Dispatcher (36,05 µs/Layer) explizites FlashAttention-3 (79,25 µs), FlashInfer (48,20 µs) und sogar den FlashAttention-2 Kontext (44,35 µs).
Die bindende Beschränkung ist die Sequenz der Kernel-Launches, nicht der Durchsatz des Attention-Kernels selbst.

4. Quantisierung und Kernel-Implementierung auf L4

Auf der bandbreitengebundenen L4 reicht Quantisierung allein nicht aus; die Kernel-Implementierung ist entscheidend:

bf16: 62,32 ms/Schritt.
bnb-nf4: 59,36 ms/Schritt (vernachlässigbarer Gewinn aufgrund des Dequantisierungs-Overheads).
AutoAWQ + Marlin: 45,24 ms/Schritt (1,38× Beschleunigung). Marlin ist auf Ampere (SM80) optimiert, nicht auf Ada (SM89).
GPTQ + ExLlamaV2: 17,36 ms/Schritt (3,59× Beschleunigung). ExLlamaV2-Kernel sind auf Ada (SM89) optimiert und realisieren die theoretischen Bandbreiteneinsparungen erfolgreich.
Ergebnis: Eine L4 mit ExLlamaV2 (17,36 ms) ist signifikant schneller als eine H100 mit Standard-Eager-Execution (14,83 ms) und konkurriert mit einer H100 unter Verwendung von CUDA Graphs (11,78 ms), trotz des 11-fachen Spitzen-Bandbreitenvorteils der H100.

Bedeutung und Behauptungen

Das Paper behauptet zu demonstrieren, dass die Standard-Deployment-Leiter ( $L4 \to H100$ ) für physische KI-Workloads invertiert ist:

Dominanz des Launch-Overheads: Auf schnellen GPUs (H100) mit kurzen Kontexten dominiert der CPU-Launch-Overhead pro Kernel die Schrittzeit, wodurch die Spitzen-Speicherbandbreite weitgehend irrelevant wird.
Kernel-Implementierung > Hardware-Upgrade: Für Batch-1 Streaming-Decode liefert die Optimierung der Kernel-Implementierung (z. B. Nutzung von ExLlamaV2 auf L4) größere Latenzreduktionen als ein Upgrade auf eine GPU mit höherer Bandbreite.
Kosteneffizienz: Bei den veröffentlichten Modal-Tarifen (Mai 2026) bedient eine L4 mit optimierten Kernels Tokens zu etwa 6-mal geringeren Kosten als eine H100 mit CUDA Graphs, obwohl die H100 über überlegene Rohspezifikationen verfügt.
Einschränkung des Geltungsbereichs: Die Autoren geben explizit an, dass sich diese Ergebnisse auf 7–8B GQA-Transformer, Batch-1, bf16 und Single-Stream-Decode beziehen. Sie behaupten nicht, dass diese Ergebnisse auf große Batches (bei denen der Launch-Tax sinkt), andere Architekturen (MHA/MQA) oder andere Hardware (AMD, Blackwell) generalisierbar sind.

Das Paper schließt mit dem Schluss, dass für die physische KI-Inferenz die Bezeichnung „speichergebunden“ unvollständig ist; das System ist auf High-End-Silizium oft launch-gebunden und auf Edge-Silizium bandbreitengebunden, was unterschiedliche Optimierungshebel (CUDA Graphs vs. spezialisierte Kernel) erfordert, statt eines einfachen Hardware-Upgrade-Pfads.