Welche Hardware zählt (und welche nicht)

Die Leistung lokaler LLMs läuft auf drei Ressourcen hinaus, und die sind nicht
gleichwertig. Die VRAM-Kapazität entscheidet, was Sie überhaupt ausführen können.
Die Speicherbandbreite entscheidet, wie schnell sich Generierung anfühlt. Die rohe
Rechenleistung entscheidet vor allem, wie lange Sie direkt nach dem Druck auf Enter
warten. Ordnen Sie sie richtig ein, und jede Hardware-Entscheidung wird offensichtlich;
ordnen Sie sie falsch ein, und Sie zahlen für Teraflops, die Sie nie nutzen.

Die Rangfolge: Kapazität, Bandbreite, Rechenleistung

1. VRAM-Kapazität (GB) — die bindende Beschränkung. Ein Model, das nicht
   hineinpasst, läuft nicht — oder überläuft in den System-RAM und robbt. Die
   Kapazität entscheidet Modellgröße, Quantisierungsstufe und Kontextlänge
   gleichzeitig, und nichts anderes auf der Karte gleicht ihr Fehlen aus.
2. Speicherbandbreite (GB/s) — wie schnell Tokens herauskommen. Jedes generierte
   Token liest im Wesentlichen das gesamte Model aus dem VRAM, also ist die
   Decode-Geschwindigkeit Bandbreite geteilt durch Modellgröße in Bytes. Die
   Rechenleistung liegt während der Generierung meist brach.
3. Rechenleistung (TFLOPS) — zählt für den Prefill: das Verdauen Ihres Prompts,
   bevor das erste Token erscheint. Mehr FLOPs bedeuten kürzeres Time-to-First-Token
   und mehr gebatchten Durchsatz, wenn mehrere Anfragen die GPU teilen. Die
   Single-Stream-Tokens pro Sekunde bewegt sie kaum.

Welche Ressource kauft welches Erlebnis

Zwei Formeln tragen fast die gesamte Intuition:

decode tok/s   ≈ effective bandwidth (GB/s) ÷ model size (GB)
prefill FLOPs  ≈ 2 × parameters × prompt tokens

Durchgerechnet: Ein 8B-Modell bei Q4_K_M sind etwa 5 GB Gewichte. Auf einer GPU
mit ~1.000 GB/s Bandbreite liegt die Decode-Decke bei 1.000 ÷ 5 ≈ 200 tok/s;
echte Engines landen bei 100–150, sobald der Overhead bezahlt ist. Derselbe
2.000-Token-Prompt braucht grob 2 × 8×10⁹ × 2×10³ ≈ 32 TFLOPs Prefill — unter
einer Sekunde auf jeder modernen diskreten GPU, langsam genug zum Spüren auf der
CPU. Der Simulator lässt Sie mit echten Zahlen an diesen Abwägungen
herumspielen.

Warum eine neue GPU-Generation den Decode kaum beschleunigt

Jede GPU-Generation verdoppelt grob die Rechenleistung: mehr Kerne, höhere
Taktraten, bessere Tensor-Einheiten. Prefill und TTFT bessern sich entsprechend —
RAG mit langen Prompts und Agenten im Codebase-Maßstab fühlen sich auf neueren
Karten sichtbar flinker an. Aber das Speichersystem bewegt sich weit weniger:
GDDR6 zu GDDR6X zu GDDR7 kauft vielleicht 20–50% mehr Bandbreite pro Generation,
und Bandbreite ist das, worauf Decode läuft. Eine neue Karte verdaut also Prompts
schneller und generiert dann fast so schnell wie die vorherige Stufe mit ähnlicher
Bandbreite. Vergleichen Sie Karten für lokale LLMs, lesen Sie zuerst die GB/s- und
VRAM-Spalten, TFLOPS zuletzt.

Was meistens nicht zählt

• Netzteil-Reserve. LLM-Inferenz zieht deutlich weniger als der Gaming-Peak der
  Karte. Ein hochwertiges Netzteil, ausgelegt auf die offizielle Anforderung der
  Karte, reicht reichlich; planen Sie kein 1.600-W-Monster ein, das Sie nie
  auslasten.
• Kühlung. Nur stundenlanges Serving zählt, wo thermisches Throttling Taktraten
  abschält. Jede ordentliche Dual- oder Triple-Fan-Karte hält durch.
• PCIe-Lanes. x8 vs. x16, Gen 4 vs. Gen 5 — beeinflusst die Ladezeit des Modells
  und den CPU-Offload-Verkehr, nicht die Generierung. Ignorieren Sie es, außer Sie
  verlagern Layer auf andere Geräte.
• NVLink und Pro-Treiber. Hobby-Serving schiebt beim Decode fast nichts zwischen
  Karten hin und her. Nett zu haben, hier nie das Geld wert.
• NPUs. Die NPU in modernen Laptops und Desktop-SoCs ist wirklich gut in kleinen
  Vision- und Audio-Modellen, aber zum Zeitpunkt dieses Textes gibt es keinen
  praktikablen LLM-Serving-Stack, der sie ansteuert. Planen Sie mit GPU, CPU oder
  Apple Silicon — nicht mit NPU — für Chat-Modelle.

Denkweise zur Bemessung: zuerst das Model, dann die Karte

Fragen Sie nicht „was kann meine GPU ausführen“. Fragen Sie, welche Klasse von
Model Sie wirklich wollen, und kaufen Sie dann die billigste Karte, die es mit
Reserve hält:

1. Wählen Sie die Arbeitslast: beiläufiger 8B-Chat, ein ernsthafter
   32B-Coding-/Reasoning-Assistent oder 70B-Klasse-Qualität, wo das Budget es
   hergibt.
2. Berechnen Sie seinen Footprint bei einem guten Quant mit dem Kontext, den Sie
   wirklich nutzen — VRAM-Mathematik hat die Formel und
   Rechentabellen.
3. Passen Sie es an eine Kartenklasse mit 10–20% Reserve an —
   GPU-Klassen ordnet Klassen Modellen zu.
4. Erst dann optimieren Sie die Bandbreite innerhalb dieser Klasse.

Von einem GPU-Budget vorwärts zu arbeiten bringt Leute zu einer schnellen Karte,
auf die nur zu kleine, unbrauchbare Modelle passen, oder zu einer Riesenkarte, die
zu 40% ausgelastet ist. Budgetieren Sie das Model, dann den Speicher, und lassen
Sie die Rechenleistung sich selbst sortieren. Und bevor Sie irgendetwas aufrüsten,
prüfen Sie, was Sie tatsächlich haben:

nvidia-smi --query-gpu=name,memory.total,memory.used --format=csv

Verwandt: VRAM-Mathematik · GPU-Klassen ·
Geschwindigkeit · CPU-Inferenz