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.

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 müssen wir die arithmetische Intensität unseres Modells berechnen. Bei Transformern konzentriert sich der Prefill-Rechenaufwand auf die Attention: Eine Eingabe zu verarbeiten bedeutet einen Durchlauf, in dem jede Query gegen jeden früheren Key gematcht wird.

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

Berechnen wir die arithmetische Intensität mit dem vereinfachten Roofline-Modell:

Arithmetic Intensity = (4 * N^2 * d_head) / (8 * N^2)
                     = d_head / 2
                     = 128 / 2
                     = 64.0 ops/byte

Die Prefill-Intensität unseres Modells beträgt ungefähr 64,0 Operationen pro Byte. Das ist eine Prefill-Größe — beim Batch-1-Decode sinkt die Intensität auf ≈1 FLOP/Byte (2 FLOPs pro 2-Byte-Gewichtslektüre), doch Decode ist stärker memory-bound, nicht schwächer: Jeder aktive Gewichts-Byte muss pro generiertem Token einmal gestreamt werden. Die volle Roofline-Form (mit Basetens +3N²-Operanden im Zähler und +8N·d-Bytes im Nenner) ergibt ≈62,4 ops/byte bei N=4096 — das vereinfachte d_head/2 überzeichnet also um ~3 %.

Schritt 4: Identifizierung des Engpasses

Nun vergleichen wir die beiden Verhältnisse:

• GPU Ops:Byte Ratio: 281.1 ops/byte
• Model Arithmetic Intensity: 64.0 ops/byte

Da 64,0 < 281,1 gilt, ist unsere Arbeitslast eindeutig memory-bound. Dies ist bei LLM-Inferenz üblich und bedeutet, dass die Speicherbandbreite der primäre begrenzende Faktor für die Inferenzgeschwindigkeit ist.

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 for Weights = 32.76 Billion Parameters * 2 Bytes/Parameter = 65.5 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 ~65,5-GB-Modells zur Verfügung:

Spare VRAM = 96 GB - 65.5 GB = 30.5 GB

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

Batch Size = Spare VRAM / (KV Cache pro Token * Sequence Length) ≈ 28 Sequenzen

Leistungsschätzung

Zeit pro Ausgabetoken (Decodierlatenz):

Time/Token = Model Size (Bytes) / Memory Bandwidth (Bytes/s) ≈ 36.6 ms/token

Dies entspricht einem theoretischen Durchsatz von ~27 Token/Sekunde.

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

Prefill Time = (512 tokens * 2 * 32.76e9 params) / 503.8 TFLOPS = 66.6 ms

Fazit

Unsere Analyse zeigt:

1. Inference ist speichergebunden: Der Hauptengpass ist die 1792 GB/s Speicherbandbreite, nicht die 503.8 TFLOPS Tensor-Rechenleistung.
2. VRAM für Batching: Die 96 GB VRAM sind ein bedeutender Vorteil und ermöglichen eine theoretische Batch-Größe von ~28 gleichzeitigen 4k-Token-Sequenzen (≈30,5 GB frei ÷ ~1,07 GB KV pro Sequenz), um die Rechenleistung der GPU besser auszunutzen.
3. Leistungserwartungen: Wir können einen theoretischen Durchsatz von etwa 27 Tokens/Sekunde und eine Prefill-Zeit von ungefähr 66,6 ms für eine 512-Token-Eingabe erwarten.

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