LLM-Inferenz-Ökonomie: Hardware-Grenzen, Kosten & Cloud-Break-Even

LLM-Serving ist ein Sandwich aus Physik und Ökonomie. Die Physik — Speicherbandbreite, FLOPS, VRAM-Kapazität — begrenzt, wie viele Token eine GPU produzieren kann. Die Ökonomie — Anschaffungspreise, Strom, Cloud-Stundensätze, API-Listenpreise — entscheidet, ob diese Token auf eigener Hardware oder bei jemand anderem günstiger sind. Diese Seite führt durch beides, mit interaktiven Rechnern, die dieselbe Roofline-Mathematik wie der Inferenzrechner nutzen.

Einstieg: die zwei Ressourcen, die Sie begrenzen

Speicher: der Batch-1-Flaschenhals

Bei geringer Parallelität ist Decode speicherbandbreitenlimitiert. Ein Token zu generieren bedeutet, jeden aktiven Modellparameter einmal aus dem VRAM zu streamen:

$\text{tok/s} \approx \frac{\text{Speicherbandbreite}}{\text{aktive Parameter-Bytes}}$

Zwei weitere Speichergrenzen kommen hinzu:

• Kapazität: Gewichte + KV-Cache müssen in den VRAM passen. Ein 70B-Modell bei BF16 braucht ~140 GB, bevor ein einziges Token Kontext hineinkommt — keine Consumer-Karte hält das.
• Amortisierungs-Ceiling: Batching verteilt die Gewicht-Lesungen auf mehr Anfragen. Aber jede zusätzliche Sequenz wächst auch den KV-Cache, bis der VRAM voll ist und der Batch nicht mehr wächst.

Rechenleistung: die Ceiling, die Sie im Skalenbetrieb erreichen

Dieselbe GPU hat auch ein hartes FLOPS-Dach. Jedes Token kostet ~2 FLOPs pro aktivem Parameter (Multiplizieren + Akkumulieren), unabhängig von der Quantisierung:

$\text{tok/s}_{\text{max}} = \frac{\text{FLOPS}}{2 \times \text{aktive Parameter}}$

Anders als die Bandbreite ist diese Ceiling batch-unabhängig: Die Gewichte werden pro Decode-Schritt einmal gelesen, egal wie viele Anfragen sie teilen. Batching bewegt Sie auf sie zu; nichts bewegt Sie über sie hinaus.

Wann verschiebt sich die Limitierung vom Speicher zur Rechenleistung?

Pro Anfrage stoppt der Durchsatz-Gewinn, wenn die aggregierte Bandbreiten-Ceiling die Compute-Ceiling erreicht — die Break-Even-Batch-Größe B*. Unter B* reiten weitere Anfragen kostenlos auf denselben Gewicht-Lesungen mit; bei B* sättigen die Tensor-Cores; darüber hinaus verwässert jede zusätzliche Anfrage die Geschwindigkeit aller. Für ein dichtes 32B-Modell auf einer RTX PRO 6000 liegt B* um 280; bei MoE-Modellen mit kleinen aktiven Parameterzahlen kann B* im Tausenden liegen. Der Break-Even-Rechner berechnet B* für Ihre genaue Kombination.

Wirtschaftliche Aspekte und Realität

Welche Modelle passen auf welche Hardware?

Passung ist zuerst eine reine Kapazitätsfrage: Gesamtparameter × Bytes pro Parameter müssen Platz für den KV-Cache lassen. Die Matrix unten zeigt es live für Ihre gewählte Präzision und GPU-Anzahl — grün heißt ≥15% Puffer, gelb heißt es passt technisch, aber lässt fast kein KV-Budget, rot heißt es passt nicht. Quantisierung verschiebt ganze Zeilen: FP8 halbiert jeden Gewicht-Footprint, NVFP4 viertelt ihn.

Wie teuer ist die Hardware?

Daumenwerte (Sept 2026, im Rechner editierbar): eine einzelne RTX PRO 6000 kostet ~8.500 $, H100 ~25.000 $, H200 ~28.000 $, B200 ~34.000 $, MI300X ~12.000 $. Ein kompletter 8-GPU-Server multipliziert die Kartenkosten grob mit 1,8 für Gehäuse, CPUs und Netzwerk. Der Sticker-Preis ist aber nur das Eintrittsticket: Strom (ein 700-W-H100 bei 0,25 €/kWh sind ~130 $/Monat pro Karte), Housing, Personal und Kapitalkosten verdoppeln die Monatsrechnung über 36 Monate Amortisierung ungefähr.

Wie viele Token bekommen Sie aus der Hardware raus?

Token-Ertrag = Durchsatz am Betriebspunkt (das kleinere von B* und der VRAM-machbaren Batch-Größe) × Wanduhr. Eine RTX PRO 6000, die Qwen3-30B-A3B bei FP8 mit 70% Auslastung serviert, produziert grob 47 Milliarden Token pro Monat; eine B300 mit einem 6B-aktiven MoE etwa das Fünffache. Der Rechner berechnet das aus der Roofline — inklusive der Ehrlichkeit, dass die Auslastung, nicht der Peak-Durchsatz, ist, was die meisten Fleet-Betreiber falsch machen.

Wann ist Cloud günstiger — und wann eigene Hardware?

Drei Kostenlinien zählen: Cloud-Miete (pro GPU-Stunde, linear in der Zeit), eigene Hardware (meist fix pro Monat, linear in Token) und APIs (rein pro Token). Die Crossover-Logik:

• Niedrige, spiky Auslastung (< ~40%) → Cloud gewinnt. Sie zahlen nur genutzte Stunden; eigenes Silizium im Leerlauf ist die teuerste Art, nichts zu servieren.
• Konstant hohe Auslastung (> ~60%) mit einem Modell, das passt → eigene Hardware gewinnt um den Faktor 3–10 bei den Rohkosten pro Token. Eine 8.500-$-Karte, die eine 2,20-$/h-Cloud-GPU schlägt, hat sich bei 24/7 in wenigen Monaten bezahlt.
• Sporadische Workloads, viele verschiedene Modelle, kein Ops-Team → APIs gewinnen trotz Token-Aufschlag, weil der Aufschlag Elastizität und null Betrieb kauft.
• Compliance-Grenzen (ISO 27001, C5, DSGVO) → eigene Hardware oder dediziertes Hosting ist oft die einzige Option, unabhängig vom Preis; Daten dürfen das Perimeter nicht verlassen.

Der Rechner berechnet die Crossover-Auslastung und die Break-Even-Monate für Ihre konkrete Workload.

Open-Weight-Modelle vs proprietäre APIs

Die unbequeme Wahrheit für API-Anbieter: Token aus offenen Gewichten sind im Skalenbetrieb dramatisch günstiger. Eine 96-GB-Karte, die ein 30B-Klasse-MoE serviert, kostet ein paar Cent pro Million Token an Strom und Amortisierung; GPT-5 mini verlangt 0,25/2,00 $ pro Million in/out. Die Tabelle unten stellt jedem Open-Weight-Modell die proprietäre Klasse gegenüber, gegen die es realistisch antritt — gleiche Qualitätsklasse, nicht token-identisch. Zwei Einschränkungen halten es ehrlich: Ihre Zeit für den Betrieb des Stacks ist nicht zu API-Sätzen eingepreist, und die Qualität pro Token unterscheidet sich trotzdem — der Vergleich sagt, was eine Qualitätsklasse kostet, nicht dass die Modelle austauschbar sind.

Einschränkungen

• Alle Durchsatzwerte sind Roofline-Obergrenzen; reale Serving-Stacks erreichen 50–80% davon.
• Preise sind editierbare Defaults (Sept 2026 Straßen-/Listenpreise) — tragen Sie Ihre echten Vertragssätze ein.
• Die Open-vs-proprietär-Tabelle ordnet Qualitätsklassen zu; Benchmarks bewegen sich schnell, prüfen Sie gegen Ihre eigenen Evals.
• Serving-Stack-Overhead (vLLM/SGLang-Scheduling, CPU-Preprocessing, Netzwerk) ist nicht modelliert.