🤖 AI

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

Dit artikel onthult dat hoewel de batch-1 LLM-inferentie van Physical AI geheugendominant is, snellere GPU's te maken hebben met disproportionele launch-zijde overheads die proportionele latentiewinsten verhinderen, en dat standaard kwantisatiemethoden vaak niet de verwachte versnellingen behalen tenzij ze worden gecombineerd met hooggeoptimaliseerde kernels zoals GPTQ+ExLlamaV2.

Oorspronkelijke auteurs: Josef Chen

Gepubliceerd 2026-06-01

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Josef Chen

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

Het Grote Plaatje: De "Snelle Auto" vs. De "File"

Stel je voor dat je met een auto van punt A naar punt B probeert te rijden. Je hebt twee soorten auto's:

De L4: Een betrouwbare, standaard sedan.
De H100: Een hyper-snelle Formule 1-raceauto met een enorme motor.

De paper stelt een simpele vraag: Als je alleen rijdt (Batch-1) en slechts een heel klein beetje bagage moet verplaatsen (één robot of één gebruikerssessie), welke auto brengt je dan sneller op de bestemming?

De algemene overtuiging was: "De Formule 1-wagen (H100) is 11 keer sneller omdat hij een veel grotere motor heeft (geheugenbandbreedte). Hij zou altijd moeten winnen."

De bevinding van de paper: De Formule 1-wagen verliest eigenlijk, of wint in ieder geval niet met veel. Waarom? Omdat de raceauto zo snel is dat de tijd die het kost om de motor te starten en de versnelling in te schakelen (CPU launch overhead) de grootste vertraging wordt. Bij de langzamere sedan is de motor de flessenhals, dus maakt het starten van de motor minder uit.

Het Kernprobleem: De "Launch Tax" (De Startbelasting)

In de wereld van AI, wanneer een computer één woord (token) tegelijk genereert, moet hij steeds opnieuw een specifieke reeks taken uitvoeren.

De Oude Visie: De snelheid hangt volledig af van hoe snel de computer zijn geheugen kan lezen (zoals hoe snel een bibliothecaris naar de planken kan rennen om boeken te pakken). De H100 heeft super-snelle planken, dus het zou direct moeten gaan.
De Nieuwe Visie: De snelheid hangt af van hoe vaak de computer moet zeggen: "Oké, start deze taak!" tegen de hardware.

De Analogie:
Stel je een bezorger (de GPU) voor die een pakketje moet afleveren.

Bij de L4 (Langzame Chauffeur): De chauffeur brengt 20 minuten onderweg naar het huis en 1 minuut om te parkeren. De rit is de flessenhals.
Bij de H100 (Snelle Chauffeur): De chauffeur kan in 1 minuut bij het huis zijn. Maar elke keer dat hij een pakketje aflevert, moet hij 30 seconden besteden aan het lopen van de wagen naar de deur, het tekenen van een formulier en het teruglopen naar de wagen.
- Omdat de rit zo snel is, wordt die 30 seconden "lopen naar de deur" (de Launch Tax) de belangrijkste reden waarom de bezorging traag verloopt.
- De H100 is zo krachtig dat hij stilzit te wachten tot de chauffeur klaar is met het papierwerk.

Het Experiment: "De Grafieken" Fix

Om dit te bewijzen, probeerden de onderzoekers een truc genaamd CUDA Graphs.

De Analogie:
In plaats van de chauffeur voor elk pakketje te laten vragen: "Mag ik starten? Oké, ga. Mag ik starten? Oké, ga," schrijven ze een meesterscript (een grafiek) dat zegt: "Rijd, Parkeer, Lever af, Keer terug, Herhaal." Ze overhandigen dit script één keer aan de chauffeur, en de chauffeur volgt simpelweg het script zonder telkens toestemming te vragen.

De Resultaten:

Op de H100 (Raceauto): Dit script maakte een groot verschil. De auto werd 26% sneller. Dit bewees dat het "papierwerk" (launch overhead) inderdaad het probleem was.
Op de L4 (Sedan): Het script maakte bijna geen verschil (slechts 3% sneller). Dit komt omdat de sedan al het grootste deel van de tijd besteedde aan het rijden (het lezen van het geheugen), en niet aan het wachten op papierwerk.

De "Omgekeerde" Kostenladder

Dit is het meest verrassende deel van de paper.

Meestal denken bedrijven: "Als ik geld wil besparen, moet ik de goedkoopste, langzaamste chip kopen (L4). Als ik snelheid wil, koop ik de dure, snelle chip (H100)."

De paper zegt: Voor single-stream AI (zoals een robot die met je praat), is dit precies andersom.

De H100 is duur en snel, maar verspilt veel van zijn snelheid aan "papierwerk."
De L4 is goedkoop en langzaam, maar gebruikt 100% van zijn snelheid aan het eigenlijke werk.

De "Magische Truc":
De onderzoekers ontdekten dat als je de goedkope L4 gebruikt met een specifiek type software "compressie" (genaamd ExLlamaV2), de L4 bijna net zo snel wordt als de H100.

H100 met trucjes: 11,78 milliseconden per stap.
L4 met trucjes: 17,36 milliseconden per stap.

Hoewel de H100 op papier 11 keer krachtiger is, is de L4 (met de juiste software) slechts ongeveer 1,5 keer langzamer, terwijl hij 10 keer minder kost om te draaien.

Samenvatting van de Belangrijkste Punten

Snel is niet altijd sneller: Alleen omdat een chip een grotere "geheugenweg" (bandbreedte) heeft, betekent niet dat hij de klus sneller klaart als de "opstarttijd" (launch overhead) te lang is.
De Flessenhals verschuift:
- Op goedkope chips (L4) is de flessenhals het verplaatsen van data (geheugenbandbreedte).
- Op dure chips (H100) is de flessenhals het starten van de taken (CPU launch overhead).
Software is belangrijker dan Hardware: Voor deze specifieke "één-voor-één" AI-taken is het kiezen van de juiste software (zoals ExLlamaV2) op een goedkope chip een betere deal dan het kopen van de duurste chip.
Voor wie is dit bedoeld? Dit is van toepassing op Physical AI: robots, zelfrijdende auto's en persoonlijke assistenten die met je praten via één zin tegelijk. Het geldt niet voor chatbots die met duizenden mensen tegelijk praten (batch processing), waar de regels anders zijn.

Kortom: Als je een robot bouwt die in real-time met je moet kunnen nadenken en praten, koop dan niet zomaar de duurste supercomputer. Koop een goedkopere computer en optimaliseer de software om te voorkomen dat het tijd verspilt aan "papierwerk". Je krijgt betere prestaties voor minder geld.

Technische Samenvatting: Geheugen-gebonden maar niet Bandbreedte-beperkt: De Fysieke AI-inferentie Gap in Batch-1 LLM Decode

Probleemstelling

Fysieke AI-systemen (robots, autonome voertuigen, edge copilots) werken doorgaans onder een single-stream, batch-1 autoregressieve decode workload. In tegenstelling tot cloud-serving, dat optimaliseert voor throughput via grote batches, wacht fysieke AI op de volgende token voor een enkele gebruiker of agent. De heersende industriële aanname is dat deze workload strikt HBM-bandbreedte-gebonden is, wat betekent dat latentie evenredig afneemt met de piek geheugenbandbreedte ( $B_{peak}$ ). Bij consequentie wordt de implementatie-ladder aangenomen te zijn als $L4 \to L40S \to A100 \to H100$ , waarbij hogere bandbreedte direct leidt tot lagere latentie en lagere kosten per token.

Dit artikel daagt die aanname uit en stelt dat voor batch-1 decode op snelle silicon (bijv. H100), de bottleneck verschuift van geheugenbandbreedte naar de per-kernel CPU-launch overhead. De auteurs beweren dat sneller geheugen niet vertaalt naar proportionele latentiewinst omdat de vaste kosten van het lanceren van kernels de dominante fractie van de stap-tijd worden op high-bandwidth GPU's, terwijl tragere GPU's werkelijk bandbreedte-gebonden blijven.

Methodologie

De studie is een gecontroleerd meetexperiment, geen theoretisch model, uitgevoerd op Modal cloud hosts met vier NVIDIA GPU's: H100 SXM5, A100-80GB SXM4, L40S, en L4.

Workload: Drie 7–8B parameter GQA transformers (Qwen-2.5-7B, Mistral-7B-v0.3, Llama-3.1-8B) met bf16 gewichten en SDPA attention.
Omvang: 44 geldige cellen die 4 contextlengtes dekken (2048 tot 16384) en 4 GPU's.
Metrieken:
- $R_{floor}$ : De ratio van de analytische geheugenvloer ( $t_{floor} = (W+K)/B_{peak}$ ) tot de geobserveerde stap-tijd ( $t_{obs}$ ). Een waarde van 1.0 geeft perfecte bandbreedte-utilisatie aan.
- CUDA Graphs A/B Test: Een falsificatie-experiment waarbij "eager" executie wordt vergeleken met "graphed" executie (captured DAG replay) om de launch overhead te isoleren.
- Software Stack Matrix: Vergelijkingen van attention backends (SDPA, FlashAttention-2/3, FlashInfer) en kwantisatiepaden (bf16, bnb-nf4, AutoAWQ+Marlin, GPTQ+ExLlamaV2).

Belangrijkste Resultaten

1. De Inverteerde Kosten-per-Token Ladder

De studie onthult een scherpe divergentie in bandbreedte-utilisatie:

L4 (300 GB/s): Bereikt ~81% van de piek HBM-bandbreedte ( $R_{floor} \approx 0.81$ ). De workload is werkelijk geheugen-gebonden.
H100 (3350 GB/s): Bereikt slechts ~27% van de piek HBM-bandbreedte ( $R_{floor} \approx 0.27$ ).
Implicatie: Het 11x grotere bandbreedtevoordeel van de H100 ten opzichte van de L4 levert geen 11x versnelling op. In plaats daarvan wordt de H100 gehinderd door launch overhead, terwijl de L4 wordt gehinderd door geheugentrafiek.

2. CUDA Graphs Falsificatie Test

De auteurs isoleerden het mechanisme door de CPU-launch overhead te verwijderen via CUDA Graphs:

Op H100 (ctx=2048): CUDA Graphs verbeterde de latentie met 1.259× (95% CI [1.253, 1.267]). Dit bevestigt dat de launch overhead ongeveer 20% van de stap-tijd beslaat.
Op L4 (ctx=2048): Dezelfde interventie leverde slechts een 1.028× verbetering op.
Conclusie: De "launch tax" is de beperkende factor op de H100 voor batch-1 decode, terwijl bandbreedte de beperkende factor is op de L4.

3. Attention Kernel Selectie

In tegen tegenstelling tot de overtuiging dat FlashAttention varianten altijd superieur zijn:

Op H100 batch-1 presteerde PyTorch's standaard SDPA dispatcher (36.05 µs/layer) beter dan expliciete FlashAttention-3 (79.25 µs), FlashInfer (48.20 µs), en zelfs de FlashAttention-2 context (44.35 µs).
De beperkende factor is de sequentie van kernel-launches, niet de throughput van de attention kernel zelf.

4. Kwantisatie en Kernel Implementatie op L4

Op de bandbreedte-gebonden L4 is kwantisatie alleen niet voldoende; de kernel-implementatie doet er toe:

bf16: 62.32 ms/step.
bnb-nf4: 59.36 ms/step (verwaarloosbare winst door dequantisatie-overhead).
AutoAWQ + Marlin: 45.24 ms/step (1.38× versnelling). Marlin is getuned voor Ampere (SM80), niet Ada (SM89).
GPTQ + ExLlamaV2: 17.36 ms/step (3.59× versnelling). ExLlamaV2's kernels zijn getuned voor Ada (SM89), waardoor de theoretische bandbreedtebesparingen succesvol worden gerealiseerd.
Resultaat: Een L4 met ExLlamaV2 (17.36 ms) is aanzienlijk sneller dan een H100 met standaard eager executie (14.83 ms) en concurreert met een H100 die CUDA Graphs gebruikt (11.78 ms), ondanks het feit dat de H100 11x meer piekbandbreedte heeft.

Betekenis en Claims

Het artikel beweert aan te tonen dat de standaard implementatie-ladder ( $L4 \to H100$ ) geïnverteerd is voor fysieke AI-workloads:

Dominantie van Launch Overhead: Op snelle GPU's (H100) met korte contexten domineert de CPU-launch overhead per kernel de stap-tijd, waardoor de piek geheugenbandbreedte grotendeels irrelevant wordt.
Kernel Implementatie > Hardware Upgrade: Voor batch-1 streaming decode levert het optimaliseren van de kernel-implementatie (bijv. het gebruik van ExLlamaV2 op L4) grotere reducties in latentie op dan het upgraden naar een GPU met een hogere bandbreedte.
Kostenefficiëntie: Bij de gepubliceerde tarieven van Modal (mei 2026), serveert een L4 met geoptimaliseerde kernels tokens tegen ongeveer 6x lagere kosten dan een H100 met CUDA Graphs, ondanks de superieure ruwe specificaties van de H100.
Scope Beperking: De auteurs stellen expliciet dat deze bevindingen van toepassing zijn op 7–8B GQA transformers, batch-1, bf16, en single-stream decode. Ze beweren niet dat deze resultaten generaliseren naar grote batches (waar de launch tax afneemt), andere architecturen (MHA/MQA), of andere hardware (AMD, Blackwell).

Het artikel concludeert dat voor fysieke AI-inferentie de term "geheugen-gebonden" incompleet is; het systeem is vaak launch-gebonden op high-end silicon en bandbreedte-gebonden op edge silicon, wat verschillende optimalisatie-hefbomen vereist (CUDA Graphs vs. gespecialiseerde kernels) in plaats van een eenvoudige hardware-upgrade pad.