Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.
flozi00 Logoflozi00 TechHub
ENDE

LLM-Inferenzrechner & Break-Even-Analyse

Interaktive Planungstools für LLM-Serving: VRAM-Kapazität, Decode-Durchsatz, Prefill-Latenz und die Batch-Größe, ab der Decode nicht mehr bandbreitenlimitiert ist — plus die maximale Sequenzlänge an diesem Betriebspunkt.

2 Min. Lesezeitflozi00
aigpuinferencevllmdeep-learningtoolscalculator

LLM-Inferenzrechner & Break-Even-Analyse

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

Interactive Estimator

LLM inference planner beta

Total parameters drive VRAM capacity; active parameters drive decode speed (MoE only fetches routed experts per token). MLA and hybrid-attention models use compressed KV-cache math.

Capacity check (Single GPU)

Model weights (total)
64 GB
Active weights per token
64 GB
KV cache per token
0.26 MB
Total KV cache (5,120 tok × 1)
1.34 GB
Activations
0.8 GB
Runtime overhead
1.2 GB
Total VRAM needed
67.34 GB
Available VRAM
96 GB
Headroom
28.66 GB
Max batch @ current context
~22
Max context @ batch 1
~114,452 tok

Roofline alignment

  • GPU ops:byte (BF16 (2 B))279.02 ops/byte
  • Base intensity (head_dim/2)64 ops/byte
  • Effective intensity (× batch)64 ops/byte
  • Gap215.02 ops/byte

Memory-bound: raising batch size lifts effective intensity because more tokens share each active-weight fetch.

Latency snapshot

Decode throughput
21 tok/s
Time per token
47.62 ms
Throughput limit
Memory
Time to first token (4,096 tok)
745.96 ms
Total request time
49.51 s
Memory-limited ceiling
21 tok/s
Compute-limited ceiling
2,929.69 tok/s

Decode ≈ min(aggregate bandwidth ÷ per-step bytes, FLOPS(BF16) ÷ 2·active-params, per-layer sync latency). Sync model: 0 sync(s)/layer × PCIe Gen5 x16 latency, scaled by kernel efficiency — TP+EP on PCIe fabrics is sync-bound, not bandwidth-bound.TTFT = max(total weight stream, linear + quadratic attention FLOPs). MoE capacity still needs all 32B params in 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. Jede zusätzliche Anfrage im Batch reitet auf denselben Gewicht-Lesungen mit — der aggregierte Durchsatz steigt fast linear, während die Geschwindigkeit pro Anfrage ungefähr konstant bleibt.

Das kann nicht ewig weitergehen. Zwei Dinge beenden das freie Mittagessen:

  1. 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.
  2. MoE-Experten-Sättigung — bei Mixture-of-Experts-Modellen berühren größere Batches immer mehr unterschiedliche Experten, bis alle gerouteten Experten einmal pro Schritt gelesen sind. Danach erzeugt jede zusätzliche Anfrage wieder Gewicht-Traffic statt ihn zu amortisieren.

Die Break-Even-Batch-Größe B* ist das Minimum von beidem — die letzte Batch-Größe, bei der Batching noch Geschwindigkeit pro Anfrage bringt. Betreiben Sie B* für maximale interaktive Reaktionsfähigkeit; gehen Sie nur für rohen Aggregat-Durchsatz darüber hinaus.

Break-even Analyzer

Decode break-even calculator beta

At low batch, decode is bandwidth-bound: every request re-reads the active weights, so tokens/s scales with the batch. Past the break-even batch B*, weight reads amortize no further (MoE expert coverage is complete, or the compute roofline is hit) — per-request speed saturates and then only degrades. This panel finds B* and the largest context that fits there.

Break-even analysis

Break-even batch B* (memory → compute crossover)~140
Per-request tokens/s at B*20.93 tok/s
Aggregate tokens/s at B*2,929.69 tok/s
Max batch in VRAM (at 2,048 tok/seq)~56
Aggregate tokens/s at VRAM-max batch1,176 tok/s
Max sequence length at B*— (B* exceeds VRAM)
Max sequence length at VRAM-max batch~2,064 tok
KV cache per token0.26 MB
Fixed VRAM (weights + overhead)65.2 GB
Free VRAM for KV + activations30.3 GB
Effective FLOPS / bandwidth375 TFLOPS / 1,344 GB/s

B* ≈ 140 needs more KV memory than this setup holds (VRAM fits ~56 sequences at 2,048 tokens). The setup never reaches the compute-bound regime — batch as high as VRAM allows and per-request speed keeps rising toward the B* value.

Decode throughput vs batch size

07692k2k3kVRAM capB* (break-even)batch size →tok/sactual (min of both)bandwidth ceilingcompute ceiling

Aggregate tok/s = min(bandwidth ceiling, compute ceiling). The bandwidth ceiling stays flat while MoE expert coverage is incomplete (each request adds its own expert reads), then grows linearly once every routed expert is read once per step. B* is the first batch where the bandwidth ceiling reaches the flat compute ceiling — beyond it, decode is compute-bound and per-request speed degrades. The VRAM cap line shows where the batch stops fitting at a 2,048-token context.

Wie der Break-Even berechnet wird

Beide Rechner teilen dasselbe Decode-Modell:

  • Bandbreiten-Obergrenze (aggregierte tok/s) = effektive Bandbreite × GPUs ÷ Bytes pro Schritt, wobei die Bytes pro Schritt mit dem Batch wachsen, bis die MoE-Experten-Abdeckung vollständig ist (min(aktiveBytes × Batch, GesamtGewichtBytes)).
  • Compute-Obergrenze (aggregierte tok/s) = effektive FLOPS × GPUs ÷ (2 × aktive Parameter-Bytes) — 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 (bei dichten Modellen ist diese sehr groß; bei MoE-Modellen trifft die Experten-Sättigung oft zuerst ein), also der Übergang von Memory-bound zu Compute-bound.
  • 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 ~1k 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.

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.