Die meisten legen einen Inferenz-Server nach TFLOPS aus. Dann passt das Modell nicht - oder es passt und läuft mit einem Drittel der erwarteten Geschwindigkeit. Beide Fehlschläge haben dieselbe Ursache: Inferenz ist speicher-, nicht rechengebunden.
Hier die Rechnung, und der Teil davon, den Schätzungen gern auslassen.
Schritt 1: die Gewichte
Die Gewichte brauchen Parameter × Bytes pro Parameter:
| Präzision | Bytes/Param | 7B | 13B | 34B | 70B |
|---|---|---|---|---|---|
| FP16 / BF16 | 2 | 14 GB | 26 GB | 68 GB | 140 GB |
| INT8 | 1 | 7 GB | 13 GB | 34 GB | 70 GB |
| INT4 | 0,5 | 3,5 GB | 6,5 GB | 17 GB | 35 GB |
Bei dieser Tabelle hört die Planung meist auf. Sie sollte es nicht.
Schritt 2: der KV-Cache - der vergessene Teil
Jeder bereits gesehene Token wird als Key/Value-Tensor vorgehalten, damit er nicht neu berechnet werden muss. Dieser Cache wächst mit der Kontextlänge und mit der Zahl gleichzeitiger Anfragen:
KV_Bytes = 2 × Layer × KV-Heads × Head-Dim × Kontext × Batch × Bytes
Die 2 steht für K und V. Für ein Modell der 70B-Klasse mit 80 Layern, 8 KV-Heads (Grouped-Query Attention) und Head-Dim 128, in FP16:
- 8k Kontext, Batch 1 → ~2,6 GB
- 32k Kontext, Batch 1 → ~10 GB
- 32k Kontext, Batch 16 → ~168 GB
Die letzte Zeile ruiniert Planungen. Die Gewichte waren 140 GB und sahen nach dem ganzen Problem aus; sechzehn gleichzeitige Nutzer bei langem Kontext mehr als verdoppeln den Bedarf.
Praktische Folge: Legen Sie Kontextlänge und Parallelität fest, bevor Sie eine Karte wählen. Ein Server, ausgelegt auf Batch 1, ist eine Demo, kein Dienst.
Schritt 3: Overhead einrechnen
Framework, CUDA-Kontext, Aktivierungen und Fragmentierung brauchen echten Platz. Rechnen Sie 10-15 % obendrauf. Landet das Ergebnis innerhalb weniger Gigabyte an der Kapazität einer Karte, behandeln Sie es als „passt nicht" - die Differenz zahlen Sie beim ersten langen Prompt.
Warum Bandbreite mehr zählt als TFLOPS
Für jeden erzeugten Token müssen die aktiven Gewichte vollständig aus dem Speicher gelesen werden. Bei Batch 1 dominiert das die Kosten, und die Obergrenze lautet:
Token/Sekunde ≈ Speicherbandbreite / aktive_Bytes_pro_Token
Ein 70B-Modell in INT8 liest rund 70 GB je Token. Auf einer Karte mit ~1400 GB/s liegt die Grenze bei etwa 20 Token/Sekunde - unabhängig davon, wie viele TFLOPS auf dem Datenblatt stehen. Die Recheneinheiten warten auf den Speicher.
Deshalb verdient bei Inferenz die Bandbreitenangabe mehr Aufmerksamkeit als die FLOPS-Angabe. An unserem eigenen Aufbau haben wir 1.396,4 GB/s gemessen - die Zahl steht in der Fallstudie zur Vast.ai-Verifizierung, zusammen mit dem, was die Plattform sonst noch prüft.
Batching ändert das Bild: Bei vielen gleichzeitigen Anfragen bedient derselbe Lesevorgang mehrere Token, und Rechenleistung zählt wieder. Genau deshalb gehört die Parallelität in die Auslegungsentscheidung und nicht in eine Fußnote.
Die Karte wählen
VRAM pro Karte schlägt VRAM gesamt. Zwei Karten mit 48 GB sind nicht eine mit 96 GB. Ein über GPUs verteiltes Modell schickt jeden Token über den Interconnect, und der Tensor-Parallel-Overhead ist real. Wenn möglich: in eine Karte packen.
- RTX 5090, 32 GB - bequem für 7B-13B in FP16 oder ~30B in INT8 bei moderatem Kontext. Ausgezeichnete Token pro Euro, solange das Modell hineinpasst.
- RTX PRO 6000 Blackwell, 96 GB - hält ein 70B in INT8 mit Platz für einen echten KV-Cache, auf einer Karte. Ab dieser Größe ist 70B auf einer Karte kein Kompromiss mehr.
- Mehrere Karten - darüber hinaus nötig, oder bei vielen gleichzeitigen Long-Context-Strömen. Planen Sie den Interconnect mit, nicht nur die Kartenzahl.
Der Host ist kein Detail
Die GPU wird nur dann zum Engpass, wenn der Host sie lässt. Einplanen:
- Arbeitsspeicher ≥ VRAM. Modelle werden über den Hostspeicher geladen; zu wenig davon macht jeden Start zum Swap-Gewitter.
- NVMe statt SATA. Ein 140-GB-Modell von langsamer Platte bedeutet Minuten Ladezeit bei jedem Neustart.
- CPU-Threads für Vorverarbeitung. Tokenisierung, Video-Decoding und Request-Handling sind CPU-Arbeit. Ein unterversorgter Host lässt eine teure GPU warten.
- Netzwerk, wenn Sie andere bedienen: 10 GbE ist die vernünftige Untergrenze.
Durchgerechnetes Beispiel
Ein 70B-Modell in INT8, 16k Kontext, bis zu 8 gleichzeitige Anfragen:
Gewichte 70 GB
KV-Cache (16k × 8) ~42 GB
Overhead (~12 %) ~13 GB
───────────────────────────
gesamt ~125 GB
Das passt nicht auf eine 96-GB-Karte. Optionen: auf INT4 gehen (~35 GB Gewichte, gesamt ~90 GB - passt), die Parallelität auf 4 senken (~104 GB - weiterhin knapp), oder zwei Karten. Auslegung und Quantisierung sind dieselbe Entscheidung - weshalb sie nicht von verschiedenen Leuten zu verschiedenen Zeiten getroffen werden sollten.
Rechnen Sie Ihren Fall durch
Führen Sie Modell, Kontext und Parallelität durch die obige Rechnung, bevor Sie Hardware in die engere Wahl nehmen. Fällt das Ergebnis zugunsten des Kaufs aus, konfigurieren Sie einen Server - wir melden uns binnen 24 Stunden mit Spezifikation und Preis. Falls Sie noch überlegen, ob Sie die Hardware überhaupt besitzen wollen, ist der Break-even zwischen Mieten und Kaufen der Text davor, und der GPU-ROI-Rechner rechnet das mit Live-Marktpreisen.
Zum Schluss eine Einschränkung, weil Auslegungsratgeber gern zu viel versprechen: Das sind Planungswerte. Der reale Durchsatz hängt von Framework, Quantisierungsqualität, Batch-Scheduler und Prompt-Form ab. Nutzen Sie sie, um Konfigurationen auszuschließen, die offensichtlich nicht funktionieren - und benchmarken Sie die, die übrig bleibt.