Zwei interaktive Tools zur Planung von LLM-Serving-Hardware. Der Planer schätzt VRAM-Bedarf, Decode-Durchsatz und Time-to-First-Token für eine konkrete Kombination aus Modell, GPU, Präzision und Batch-Größe ein. Die Break-Even-Analyse beantwortet die tiefere Kapazitätsfrage: Ab welcher Batch-Größe ist Decode nicht mehr bandbreitenlimitiert, ab welchem Punkt ist er compute-limitiert, und welche maximale Sequenzlänge ist bei dieser Batch-Größe noch machbar.
Alle Zahlen sind theoretische Obergrenzen aus Hersteller-Spezifikationen und Roofline-Mathematik — reale Deployments erreichen typischerweise 60–80% dieser Werte. Der Guide zur Inferenz-Mathematik erklärt die zugrunde liegenden Formeln.
1. Der Planer: Kapazität, Durchsatz, Latenz
Interaktiver Rechner
LLM-Inferenz-Planer beta
Die Gesamtzahl der Parameter bestimmt die VRAM-Kapazität; aktiven Parameter bestimmen die Decode-Geschwindigkeit (nur MoE lädt pro Token die gerouteten Experten). MLA- und Hybrid-Attention-Modelle nutzen komprimierte KV-Cache-Berechnung.
Kapazitätsprüfung (Einzelne GPU)
- Modellgewichte (gesamt)
- 65,52 GB
- Aktive Gewichte pro Token
- 65,52 GB
- KV-Cache pro Token
- 0,26 MB
- KV-Cache gesamt (5.120 Tok × 1)
- 1,34 GB
- Aktivierungen
- 0,8 GB
- Runtime-Overhead
- 1,2 GB
- Benötigter VRAM gesamt
- 68,86 GB
- Verfügbarer VRAM
- 96 GB
- Puffer
- 27,14 GB
- Max. Batch @ aktuellem Kontext
- ~21
- Max. Kontext @ Batch 1
- ~108.639 tok
Roofline-Abgleich
- GPU-Ops/Byte (BF16 (2 B))279,02 ops/byte
- Decode-Intensität (Batch 1)1 ops/byte
- Effektive Intensität (Batch 1)1 ops/byte
- Abstand278,02 ops/byte
Speicherlimitiert: eine größere Batch erhöht die effektive Intensität, weil sich mehr Tokens jeden Active-Weight-Lesevorgang teilen.
Latenz-Momentaufnahme
- Decode-Durchsatz
- 20,51 tok/s
- Zeit pro Token
- 48,75 ms
- Durchsatzgrenze
- Speicher
- Zeit bis zum ersten Token (4.096 Tok)
- 809,52 ms
- Gesamtzeit pro Anfrage
- 50,73 s
- Speicherbegrenzte Obergrenze
- 20,51 tok/s
- Rechenbegrenzte Obergrenze
- 5.723,09 tok/s
Decode ≈ min(aggregierte Bandbreite ÷ Bytes pro Schritt, FLOPS(BF16) ÷ 2·aktive Parameter, Sync-Latenz pro Ebene). Sync-Modell: 0 Sync(s)/Ebene × PCIe Gen5 x16 Latenz, skaliert mit der Kernel-Effizienz — TP+EP auf PCIe-Fabrics ist sync-limitiert, nicht bandbreiten-limitiert.TTFT = max(vollständiger Gewichtsstrom, lineare + quadratische Attention-FLOPS).MoE-Kapazität benötigt trotzdem alle 32.762B Parameter im VRAM.
2. Break-Even: Ab wann hilft Batching nicht mehr?
Bei Batch-Größe 1 ist Decode bandbreitenlimitiert: Ein Token zu generieren bedeutet, jedes aktive Gewicht einmal aus dem HBM zu streamen, also gilt tok/s ≈ Speicherbandbreite ÷ aktive Gewicht-Bytes. Ob zusätzliche Anfragen kostenlos mitreiten, hängt von der Architektur ab: Ein dichtes Modell streamt seinen vollständigen Gewichtssatz pro Schritt ohnehin einmal, jede neue Anfrage reitet auf denselben Lesungen mit — der aggregierte Durchsatz steigt fast linear, während das Tempo pro Anfrage ungefähr konstant bleibt. Ein MoE-Modell liest mit wachsendem Batch mehr Gewichte pro Schritt (jede Anfrage berührt neue Experten); dort bleibt die Aggregat-Obergrenze zunächst flach und das Tempo pro Anfrage sinkt — bis die Experten-Abdeckung sättigt (Punkt 2 unten).
Das kann nicht ewig weitergehen. Zwei Dinge beenden das freie Mittagessen:
- Compute-Crossover — die gesamten FLOPs, die der Batch pro Schritt braucht, übersteigen, was die Tensor-Cores der GPU in einer Speicher-Runde liefern können. Oberhalb dieser Batch-Größe ist die GPU compute-limitiert und die Geschwindigkeit pro Anfrage sinkt. Er definiert B*.
- MoE-Experten-Abdeckung — unterhalb des Sättigungs-Batches (≈ Gesamt- ÷ aktive Parameter) berührt jede zusätzliche Anfrage frische Experten, daher bleibt die Aggregat-Obergrenze flach und das Tempo pro Anfrage sinkt von Anfang an. Oberhalb davon werden alle gerouteten Experten ohnehin einmal pro Schritt gelesen, und der Aggregat-Durchsatz steigt wieder fast linear — hier beginnt das MoE-Batching sich zu lohnen.
Die Break-Even-Batch-Größe B* ist die Batch, bei der die Bandbreiten-Obergrenze die flache Compute-Obergrenze trifft — der Übergang vom speicher- zum rechenlimitierten Betrieb. Darunter ist Batching kostenlos (bei MoE: ab dem Sättigungs-Batch); ab B* verwässert jede zusätzliche Anfrage das Tempo aller. Fahren Sie unterhalb von B* für maximale interaktive Reaktionsfähigkeit; nur für rohen Aggregat-Durchsatz darüber. Bei dichten Modellen ist B* ≈ GPU-FLOPS × Bytes-pro-Parameter ÷ (2 × Bandbreite) — bei BF16 entspricht das dem Ops:Byte-Verhältnis der GPU, einige hundert bei modernen Karten, oft mehr als der VRAM fasst; MoE-Modelle multiplizieren diesen Wert mit Gesamt- ÷ aktive Parameter und landen in den Tausenden.
Break-even-Analyse
Decode-Break-even-Rechner beta
Bei kleiner Batch ist das Decode bandbreiten-limitiert: jede Anfrage liest die aktiven Gewichte erneut, daher skaliert Tokens/s mit der Batch. Jenseits des Break-even-Batch B* amortisieren die Gewichtszugriffe nicht weiter (die MoE-Expertenabdeckung ist vollständig, oder die Compute-Roofline ist erreicht) — das Tempo pro Anfrage gesättigt sich und fällt danach nur noch. Dieser Bereich findet B* und den größten Kontext, der dort passt.
Break-even-Betrachtung
B* ≈ 280 braucht mehr KV-Speicher, als dieses Setup bietet (VRAM passt ~53 Sequenzen bei 2.048 Tokens). Das Setup erreicht nie den rechenlimitierten Bereich — Batch so hoch wie der VRAM erlaubt, und das Tempo pro Anfrage steigt weiter Richtung B*..
Decode-Durchsatz über Batch-Größe
Aggregate Tokens/s = min(Speicherbandbreiten-Decke, Compute-Decke). Die Bandbreiten-Decke bleibt flach, solange die MoE-Expertenabdeckung unvollständig ist (jede Anfrage fügt eigene Experten-Lesevorgänge hinzu), und wächst linear, sobald jeder geroutete Experte pro Schritt einmal gelesen wird. B* ist die erste Batch, bei der die Bandbreiten-Decke die flache Compute-Decke erreicht — dahinter ist das Decode rechenlimitiert und das Tempo pro Anfrage sinkt. Die VRAM-Grenzen-Linie zeigt, wo die Batch nicht mehr in einen 2.048-Token-Kontext passt.
Wie der Break-Even berechnet wird
Beide Rechner teilen dasselbe Decode-Modell:
- Bandbreiten-Obergrenze (aggregierte tok/s) = Batch × effektive Bandbreite × GPUs ÷ Bytes pro Schritt, wobei die Bytes pro Schritt
min(aktiveBytes × Batch, GesamtGewichtBytes)sind — vor der Sättigung kürzt sich der Batch heraus, die Aggregat-Obergrenze bleibt also flach, wie oben beschrieben. - Compute-Obergrenze (aggregierte tok/s) = effektive FLOPS × GPUs ÷ (2 × aktive Parameter) — batch-unabhängig, weil die Gewichte pro Schritt unabhängig vom Batch einmal gelesen werden.
- B* = die Batch-Größe, an der sich beide Obergrenzen schneiden, also der Übergang von Memory-bound zu Compute-bound. Dicht: ≈ FLOPS ÷ (2 × Bandbreite), GPU-bestimmt (einige hundert). MoE: dieser Wert mal Gesamt- ÷ aktive Parameter (Tausende).
- Maximale Sequenzlänge bei B* = (Gesamt-VRAM − Gewichte − Laufzeit-Overhead) ÷ (KV-Bytes pro Token × B*), begrenzt durch das Kontextfenster des Modells.
Die Analyse zeigt außerdem die VRAM-machbare maximale Batch-Größe bei einem Kontext von ~2k Token. Wenn B* darüber liegt, erreicht das Setup das Compute-bound-Regime nie wirklich — batchen Sie so hoch, wie der VRAM es erlaubt, und die Geschwindigkeit pro Anfrage steigt weiter Richtung B*-Obergrenze.
Verwandte Artikel
- LLM-Inferenz-Ökonomie: Kosten & Cloud-Break-Even — was die Break-Even-Kurve in Dollar kostet.
- LLM-VRAM-Bedarf: Ein mathematischer Deep Dive — das Speichermodell hinter der Fit-Spalte.
Einschränkungen
- Keine Continuous-Batching-Ankunftsdynamik: B* ist eine Ceiling im Gleichgewichtszustand, keine Scheduling-Policy.
- Attention-Decode-FLOPs (die mit der Kontextlänge wachsen) sind nicht in der Compute-Obergrenze enthalten; bei sehr langen Kontexten kommt der reale Crossover früher.
- Multi-GPU nimmt Tensor-Parallelität mit perfekter Bandbreiten-Skalierung an; PCIe-Fabrics fügen Sync-Latenz hinzu, die der Planer modelliert, die Kurve aber nicht.