LLM-Inferenz-Mathematik: Theorie trifft Hardware

Large Language Models (LLMs) sind zu einer grundlegenden Technologie in der modernen KI geworden, aber ihr effizienter Betrieb erfordert ein tiefes Verständnis des Zusammenspiels zwischen Modellarchitektur und Hardwarefähigkeiten. Es ist nicht immer die kosteneffizienteste Lösung, einfach die leistungsstärkste GPU auszuwählen. Entscheidend ist, ob Ihr Workload compute-bound oder memory-bound ist.

Dieser Leitfaden führt Sie durch die wesentlichen mathematischen Grundlagen, um ein LLM für Inferenz zu profilieren, damit Sie die richtige Hardware auswählen und deren Leistung optimieren können. Wir wenden diese Prinzipien auf ein Praxisbeispiel an: den Betrieb des Qwen/Qwen3-VL-32B-Instruct Modells auf der leistungsstarken NVIDIA RTX PRO 6000 Blackwell Edition Workstation-GPU.

Dieser Artikel ist inspiriert von dem mathematischen Ansatz, der im Baseten Blogbeitrag "A guide to LLM inference and performance." beschrieben wird.

Als vermessenes Beispiel prüft die MI350P-vLLM-Fallstudie 118 Beobachtungen und erklärt weniger Zustands-Writes, K/V-Wiederverwendung und Routing für wenige Zeilen. Sie trennt logische Byte-Zahlen von Hardware-Transfers und vollständige Deployment-Ergebnisse von isolierten Kernelzeiten.

Schritt 1: Verstehen Sie die Fähigkeiten Ihrer Hardware

Der erste Schritt besteht darin, die wichtigsten Spezifikationen unserer GPU zu analysieren. Diese Zahlen definieren die theoretischen Grenzen unserer Hardware. Für die NVIDIA RTX PRO 6000 Blackwell Edition sind die entscheidenden Spezifikationen:

• GPU Speicher (VRAM): 96 GB GDDR7 ECC ¹
• GPU Speicherbandbreite: 1792 GB/s ¹
• FP16/BF16 Tensor Core Leistung (dense): 503.8 TFLOPS ²

Diese drei Kennzahlen – Kapazität, Geschwindigkeit und rohe Leistung – sind die Säulen unserer Analyse.

Schritt 2: Berechnung der Operational Intensity (Ops:Byte-Verhältnis) der GPU

Die operational intensity einer GPU, also das ops:byte-Verhältnis, gibt an, wie viele Berechnungen sie für jedes Byte an Daten durchführen kann, das sie aus dem VRAM bewegt. Dies ist ein entscheidendes, hardware-spezifisches Verhältnis, das das Gleichgewicht zwischen Berechnung und Speicherzugriff aufzeigt.

Die Formel ist einfach:

ops:byte Ratio = Compute Bandwidth (FLOPS) / Memory Bandwidth (Bytes/s)

Berechnen wir es für unsere RTX PRO 6000:

• Compute: 503.8 TFLOPS = 503,800,000,000,000 FLOPS
• Memory: 1792 GB/s = 1,792,000,000,000 Bytes/s

ops_to_byte_ratio = 503,800,000,000,000 / 1,792,000,000,000
                  = 281.1 ops/byte

Das bedeutet, damit unsere Hardware vollständig ausgelastet ist, muss unsere Anwendung ungefähr 281,1 Gleitkommaoperationen für jedes einzelne Byte ausführen, das sie aus dem VRAM abruft.

• Führt unser Modell weniger Operationen pro Byte aus, sind wir memory-bound.
• Benötigt unser Modell mehr Operationen pro Byte, sind wir compute-bound.

Schritt 3: Berechnung der arithmetischen Intensität des Modells

Als Nächstes berechnen wir die arithmetische Intensität für den gesamten Forward-Pass, getrennt nach Prefill und Decode. Attention trägt Rechenarbeit bei, ist aber nicht das ganze Modell: Im einfachen linearen Term dominieren die Gewichtsmatrix-Multiplikationen.

Wir verwenden die Parameter für das Modell Qwen/Qwen3-VL-32B-Instruct ³:

• Sequenzlänge (N): 4096
• Modelldimension (d_model): 5120
• Anzahl der Attention Heads (n_heads): 64
• Anzahl der KV-Heads (n_kv_heads): 8 (GQA)
• Dimension pro Head (d_head): 128

Bei einem Prompt von 4.096 Tokens hat der Checkpoint mit 33,357 Mrd. Parametern ungefähr 66,7 GB fp16-Gewichte. Die übliche Näherung für lineare Schichten ergibt:

Lineare FLOPs ≈ 2 × 33,357 Mrd. Parameter × 4.096 Tokens ≈ 273,3 TFLOPs
Gewichts-Lesevolumen ≈ 33,357 Mrd. Parameter × 2 Bytes ≈ 66,7 GB
Lineare arithmetische Intensität ≈ 273,3 TFLOPs / 66,7 GB = 4.096 FLOPs/Byte

Die 4.096 FLOPs/Byte teilen die Rechenarbeit der linearen Schichten nur durch das Lesen der Gewichte. Attention ergänzt FLOPs, während Lesen und Schreiben der Aktivierungen weitere Bytes hinzufügt. Der Wert ist daher eine Illustration, keine gemessene Intensität des ganzen Modells. Bei Batch-1-Decode fällt dasselbe Verhältnis auf ungefähr 1 FLOP je fp16-Gewichtsbyte. Kontextabhängige Attention-Lesevorgänge erzeugen zusätzlichen Datenverkehr.

Schritt 4: Identifizierung des Engpasses

Nun vergleichen wir die beiden Verhältnisse:

• GPU Ops:Byte Ratio: 281.1 ops/byte
• Illustration für linearen Prefill: 4.096 FLOPs/Byte Gewichtsverkehr
• Illustration für linearen Batch-1-Decode: 1 FLOP/Byte Gewichtsverkehr

Der vereinfachte 4k-Prefill benötigt je Gewichtsbyte mehr FLOPs als die GPU-Schwelle von 281,1 FLOPs/Byte und kann bei den linearen Schichten rechenlimitiert sein. Batch-1-Decode hat viel weniger Rechenarbeit je Gewichtsbyte und ist bei Gewichten im VRAM typischerweise bandbreitenlimitiert. Der echte Engpass hängt auch von Attention, Batchform, Kernels und Caches ab; eine reine Attention-Intensität klassifiziert nicht den gesamten Inferenz-Workload.

Schritt 5: VRAM- und Leistungsschätzung

VRAM für Modellgewichte

Ein Modell mit ~32,8 Milliarden Parametern (der Qwen3-32B-Textstack; die VL-Variante fügt einen Vision-Tower für ~33,4 Mrd. hinzu) in Halbpräzision (FP16) benötigt:

VRAM für Gewichte = 33,357 Mrd. Parameter × 2 Bytes/Parameter ≈ 66,7 GB

VRAM für den KV-Cache

Die KV-Cache-Größe pro Token beträgt:

KV Cache pro Token = 2 * num_hidden_layers * n_kv_heads * d_head * 2 = 262.144 Bytes/token (Qwen3-VL-32B nutzt Grouped-Query Attention mit 8 KV-Heads statt 64 — der KV-Cache ist daher 8× kleiner als ein vollständiges Multi-Head-Layout.)

Mit unserer 96-GB-GPU stehen nach dem Laden des ~66,7-GB-Modells zur Verfügung:

Freier VRAM = 96 GB − 66,7 GB ≈ 29,3 GB

Dies ermöglicht eine theoretische Batchgröße von:

Batchgröße = floor(29,285 GB / (262.144 B/Token × 4.096 Tokens)) = 27 Sequenzen (vor Reserven für Runtime, Aktivierungen und Allocator)

Leistungsschätzung

Zeit pro Ausgabetoken (Decodierlatenz):

Zeit/Token ≥ Modellgröße (Bytes) / maximale Speicherbandbreite (Bytes/s) ≈ 37,2 ms/Token (nur Gewichte, Batch 1)

Das ist eine Bandbreiten-Obergrenze von ~26,9 Tok/s vor KV-Lesevorgängen und weiterer Arbeit, keine gemessene Erwartung.

Time to First Token (Prefill Latency): Für eine Eingabe von 512 Tokens:

Lineare Rechenzeit ≥ (512 Tokens × 2 × 33,357e9 Parameter) / 503,8 TFLOPS ≈ 67,8 ms

Fazit

Unsere Analyse zeigt:

1. Der Engpass hängt von der Phase ab: Der lineare Teil eines 4k-Prefills kann rechenlimitiert sein; Decode mit kleinem Batch ist typischerweise bandbreitenlimitiert.
2. VRAM für Batching: Die 96-GB-Karte bietet nach dem 66,7-GB-Checkpoint eine rohe Kapazitätsgrenze von 27 gleichzeitigen 4k-Token-KV-Sequenzen. Mit Runtime- und Aktivierungsspeicher ist die echte Grenze niedriger.
3. Leistungsgrenzen: Allein das Gewichtslesen begrenzt Batch-1-Decode auf ~26,9 Tok/s; allein der lineare Rechenanteil setzt eine Prefill-Untergrenze von ~67,8 ms für 512 Prompt-Tokens. Beides ist weder Betriebsprognose noch vollständige TTFT.

Diese Berechnungen bieten eine solide Grundlage, um die LLM-Inferenzleistung zu verstehen und fundierte Hardware-Entscheidungen zu treffen.

Verwandte Artikel

• LLM-VRAM-Bedarf: Ein mathematischer Deep Dive — die Speicher-Achse der Roofline.
• Tensor Parallelism: Silizium zerschneiden — ein Modell auf mehrere GPUs aufteilen, wenn eine Karte nicht reicht.

References