GPU für lokale KI: VRAM zuerst, Topologie zweitens, Hostgrenzen drittens

Für lokale KI ist die entscheidende Frage nicht, welche Karte gerade am häufigsten empfohlen wird, sondern welches Modell in welchem Betriebsmodus wirklich geplant ist. Drei Dinge definieren die Auswahl:

1. Modellklasse: 3B, 8B, 14B, 32B oder 70B sind keine kosmetischen Unterschiede, sondern völlig verschiedene Speicher- und Hostklassen.
2. Runtime-Pfad: Ein lokaler Einzelplatz mit Ollama stellt andere Anforderungen als ein vLLM-Server mit mehreren gleichzeitigen Requests.
3. Hostgrenzen: Netzteil, Slotbreite, Gehäusetiefe, Luftführung und 24/7-Stromprofil entscheiden mit darüber, ob eine GPU im Alltag tragfähig ist.

Einordnung: Eine gute GPU-Wahl ist deshalb immer eine Reihenfolgeentscheidung: erst Modellziel, dann VRAM- und Topologiefrage, dann Hostgrenzen, erst danach Preis. Wer mit dem Preis beginnt, kauft sehr oft die falsche Klasse.

Die vLLM-Dokumentation ist an dieser Stelle ungewöhnlich klar: wenn ein Modell auf eine einzelne GPU passt, ist verteilte Inferenz meist unnötig. Ist das Modell dafür zu groß, aber noch auf einem einzelnen Node mit mehreren GPUs unterzubringen, soll Tensor Parallelism genutzt werden. Reicht auch ein einzelner Node nicht, kombiniert vLLM Tensor- und Pipeline-Parallelismus.

Betriebsmodus	Offizieller Anker	Praktische Folge für den Kauf
Single GPU	vLLM: wenn das Modell auf eine einzelne GPU passt, ist verteilte Inferenz meist unnötig	VRAM und Reserve entscheiden, nicht Mainboard-Slotzahl oder Clusterpläne
Single-Node Multi-GPU	vLLM: wenn es nicht auf eine Karte passt, aber auf einen Node mit mehreren GPUs, Tensor Parallelism	Board, Netzteil, Kühlung und Interconnect werden Teil der eigentlichen Architektur
Multi-Node	vLLM: Kombination aus Tensor- und Pipeline-Parallelismus über mehrere Nodes	dann planst du nicht mehr nur eine GPU, sondern ein verteiltes Serving-System

Das ist der wichtigste Anti-Fehlkauf-Hebel. Wer noch gar nicht weiß, ob ein Modell auf eine einzelne Karte passt, sollte keine Multi-GPU-Hardware auf Verdacht kaufen.

Die belastbare Untergrenze für den Speicherbedarf ergibt sich aus den Gewichten: Parameter × Präzision. Daraus folgt als einfache Herleitung:

• FP16: rund 2 Byte pro Parameter
• INT8: rund 1 Byte pro Parameter
• 4-Bit: rund 0,5 Byte pro Parameter

Diese Rechnung deckt nur die Gewichte ab. Für KV-Cache, Laufzeit-Overhead, Kontextfenster und Reserve brauchst du zusätzlichen Puffer. Genau deshalb ist jede Gewichtsrechnung eine Untergrenze und noch kein Beweis, dass sich das Modell auf einer Karte sauber betreiben lässt.

Modellklasse	Offizielle Größenanker	Gewichte FP16	Gewichte 4-Bit	Saubere Praxisplanung
Klein	Llama 3.2 3B	ca. 6 GB	ca. 1,5 GB	kleine GPU oder integrierter Einstieg mit Reserve
Standard	Llama 3.1 8B, Mistral 7B	ca. 14 bis 16 GB	ca. 3,5 bis 4 GB	8 bis 12 GB als robuster Alltagseinstieg
Gehoben	Gemma 3 12B, Qwen 2.5 14B	ca. 24 bis 28 GB	ca. 6 bis 7 GB	12 bis 16 GB eröffnen spürbar mehr Reserve
Groß	Gemma 3 27B, Qwen 2.5 32B	ca. 54 bis 64 GB	ca. 13,5 bis 16 GB	24-GB-Klasse oder bewusst geplantes Offloading
Sehr groß	Llama 3.1 70B	ca. 140 GB	ca. 35 GB	Single-GPU-Consumer-Hardware ist dafür kein sauberer Primärpfad

Mehr zur reinen Untergrenze findest du in LLM-VRAM-Anforderungen. Die Tabelle dort beantwortet die Speicherfrage, diese Seite beantwortet die Kauf- und Betriebsfrage.

Für lokale KI sind nur wenige Herstellerdaten kaufentscheidend: VRAM, Leistungsaufnahme, Formfaktor und thermischer Betriebsstil. Genau diese vier Punkte sagen dir mehr als jede Top-10-Liste.

GPU-Klasse	Offizieller Speicheranker	Offizielle Leistungsdaten	Warum sie für lokale KI relevant ist
GeForce RTX 4060 Ti Familie	16 GB oder 8 GB GDDR6	165 oder 160 W Total Graphics Power, 550 W Required System Power	markiert die obere kleine Desktop-Klasse mit 16-GB-Option, aber ohne große Reserve für sehr schwere Modelle
GeForce RTX 4090	24 GB GDDR6X	450 W Total Graphics Power, 850 W Required System Power, 3-Slot	zeigt, wie teuer 24-GB-Consumer-Leistung beim Netzteil-, Platz- und Kühlbudget wirklich wird
NVIDIA RTX A5000	24 GB GDDR6 mit ECC	230 W Max Power, Dual-Slot, aktive Kühlung	24-GB-Workstation-Pfad für engere Gehäuse- und 24/7-Randbedingungen
NVIDIA T4	16 GB GDDR6	70 W, Low-Profile, passiv	effizienter Server-Beschleuniger, aber nur mit passendem Airflow-Konzept sinnvoll

Einordnung: Die letzte Spalte ist eine Betriebsinferenz aus den offiziellen Daten, kein Benchmarkversprechen. Genau das reicht für eine saubere Vorauswahl aber aus.

Gerade im Homelab wird die GPU oft isoliert betrachtet. Das ist der eigentliche Fehler. NVIDIA nennt bei der RTX 4090 nicht nur 24 GB Speicher und 450 W TGP, sondern auch 850 W Mindest-Systemleistung, drei ungenutzte Slots und konkrete Platzanforderungen. Beim T4-Produktbrief ist der Engpass anders: passiv gekühlt und laut NVIDIA nur innerhalb der thermischen Grenzen mit System-Airflow sauber betreibbar.

Hostfrage	Worauf du offiziell belegbar achten kannst	Praxisfolge
Netzteil	4090: 850 W Required System Power; 4060 Ti Familie: 550 W	das Netzteil ist Teil der GPU-Wahl und nicht bloß Zubehör
Slot- und Gehäusebreite	4090: 3-Slot; A5000: Dual-Slot	mehrere Karten oder kleine Gehäuse scheitern oft hier, nicht erst an der Software
Thermik	T4: passives Board mit benötigtem System-Airflow	passive Serverkarten gehören nicht blind in ruhige Desktop-Gehäuse
24/7-Betrieb	Leistungsaufnahme ist offiziell dokumentiert, nicht aber deine Raum- und Lastrealität	Strom, Lüftercharakteristik und Aufstellort müssen bewusst mitgeplant werden

Darum ist die bessere Kaufreihenfolge: erst Modellklasse, dann Hostbudget, dann konkrete Karte. Mehr zur Dauerlast findest du in GPU-Stromverbrauch, Netzteil-Rechner, Inferenzkosten-Rechner und Strom sparen am Heimserver.

Die vLLM-Dokumentation ist an diesem Punkt präziser als viele Kaufberatungen: cpu_offload_gb kann den nutzbaren Speicher virtuell vergrößern, weil Modellgewichte teilweise aus CPU-Speicher nachgeladen werden. Gleichzeitig nennt vLLM die relevante Gegenleistung ausdrücklich: CPU-GPU-Datentransfer in jedem Forward-Pass. Zusätzlich gibt es getrennt davon KV-Cache-Offloading, das erst aktiv wird, wenn kv_offloading_size gesetzt ist.

Mechanismus	Was er laut offizieller Doku tut	Was das für den Kauf bedeutet
cpu_offload_gb	vergrößert den nutzbaren Speicher virtuell durch Weight-Offloading auf CPU-Speicher	kann ein Modell lauffähig machen, ist aber kein Beweis für eine komfortable GPU-Klasse
kv_offloading_size	aktiviert KV-Cache-Offloading zur CPU	zeigt, dass nicht nur Gewichte, sondern auch Laufzeitspeicher bereits unter Druck stehen
gpu_memory_utilization	begrenzt, wie viel GPU-Speicher eine vLLM-Instanz nutzt	macht sichtbar, dass Reserve bewusst geplant werden muss und nicht zufällig übrig bleibt

Einordnung: Diese Funktionen sind nützlich, aber sie ändern die Architekturfrage nicht. Wenn dein Zielmodell nur mit aggressivem Offloading halbwegs hineinpasst, dann ist das meist kein starker Einzelkarten-Fit, sondern ein Signal, dass die GPU-Klasse für den gewünschten Betriebsstil zu klein gewählt ist.

Die bessere Plattformfrage lautet nicht "NVIDIA oder AMD?", sondern welcher Integrationspfad zu deinem Runtime- und Hostmodell passt.

Pfad	Wann er gut passt	Wo du vorab prüfen musst
Consumer-Desktop-GPU	wenn ein einzelner Nutzer lokal oder in kleinem Umfang testet und das Gehäuse-/PSU-Budget vorhanden ist	VRAM, Slotbreite, Stromanschlüsse, 24/7-Stromprofil
Aktive Workstation-Karte	wenn Dual-Slot, engerer Einbauraum oder ECC-orientierte Planung wichtiger werden	Preisniveau, Host-Kompatibilität, tatsächlicher 24/7-Nutzen
Passive Serverkarte	wenn ein Server-Host mit geeigneter Luftführung ohnehin gesetzt ist	Airflow, qualifizierter Serverpfad, Lautstärke und Rack-Konzept
AMD ROCm-Pfad	wenn die exakte GPU, das OS und das Ziel-Framework in der aktuellen Kompatibilitätsmatrix auftauchen	ohne explizite Matrix-Abdeckung keine Unterstützung voraussetzen

Die aktuelle ROCm-Dokumentation für Radeon und Ryzen listet für unterstützte Konfigurationen die GPU-, OS- und Framework-Matrizen ausdrücklich aus. Genau deshalb ist bei AMD der korrekte Schritt nicht "wird schon laufen", sondern die exakte Kombination aus Karte, Betriebssystem und Framework gegen die Matrix zu prüfen.

Wenn die Plattformwahl in Richtung gebrauchte Workstation oder Server kippt, wird Gebrauchte Server kaufen unmittelbar relevant.

vLLM beschreibt Multi-GPU nicht als Komfortfeature, sondern als Konsequenz daraus, dass ein Modell nicht sinnvoll auf eine einzelne Karte passt. Erst wenn diese Grenze erreicht ist, wird Tensor- oder Pipeline-Parallelismus zum Thema.

1. Single GPU ausschöpfen: passt das Modell mit realistischer Reserve auf eine Karte?
2. Single Node prüfen: wenn nein, reicht ein Node mit mehreren GPUs?
3. Erst dann Cluster denken: falls nicht, reden wir über verteiltes Serving statt über eine einzelne GPU.

Zusätzlich nennt die vLLM-Dokumentation zwei operative Prüfwerte nach der Bereitstellung: GPU KV cache size und Maximum concurrency. Das ist entscheidend, weil es nach dem Kauf nicht mehr um Prospektdaten geht, sondern um die Frage, wie viel Kontext und wie viele gleichzeitige Requests deine konkrete Konfiguration wirklich trägt.

1. Welche Modellklasse ist wirklich Zielsystem und nicht nur Neugier?
2. Wie groß ist die Gewichts-Untergrenze und wie viel Reserve willst du darüber hinaus?
3. Bleibt das Projekt auf einer Einzelkarte oder ist Multi-GPU absehbar?
4. Trägt dein Host Netzteil, Slotbreite, Kabelführung und Luftpfad wirklich?
5. Soll die GPU nur lokal testen oder 24/7 Dienste bedienen?
6. Misst du nachher echte Laufzeitgrenzen oder sammelst du nur Hardware?

Wenn du diese sechs Fragen vor dem Kauf sauber beantwortest, schrumpft die Zahl der sinnvollen Kandidaten meist sehr schnell. Genau das ist das Ziel: nicht mehr Auswahl, sondern weniger falsche Auswahl.

Eine lokale KI-GPU ist nicht deshalb passend, weil das Modell einmal startet. Für einen sauberen Abnahmeentscheid brauchst du Messwerte. vLLM nennt dafür ausdrücklich die Log-Anker GPU KV cache size und Maximum concurrency. Ollama ergänzt für den lokalen Einzelplatz einen anderen wichtigen Blick: Mit ollama ps kannst du prüfen, ob ein Modell vollständig auf GPU, vollständig auf CPU oder nur teilweise CPU/GPU geladen wurde.

Abnahmekriterium	Warum es zählt
das Zielmodell läuft ohne ungeplantes Ausweichen auf CPU oder massives Offloading	nur dann entspricht die Karte wirklich der geplanten Modellklasse
KV-Cache und maximale Gleichzeitigkeit passen zu deinem echten Kontext- und Nutzerbild	erst dadurch wird aus "läuft" ein belastbarer Serving-Pfad
Strom, Luftpfad und Netzteil bleiben unter realer Last im akzeptablen Bereich	eine funktionierende Inferenz ohne tragfähigen Host ist kein sauberer Produktivpfad
für das Zielmodell bleibt Reserve statt nur Kante	sonst wird jede Kontextvergrößerung oder Parallelität sofort zum Re-Design

Wenn diese Punkte nicht erfüllt sind, ist die Karte nicht automatisch "falsch", aber oft für genau deinen Betriebsstil falsch eingeordnet. Genau das ist der Unterschied zwischen einer erfolgreichen Demo und einer sauberen Infrastrukturentscheidung.

Die sauberste GPU-Wahl entsteht nicht aus einer Produktseite, sondern aus drei getrennten Freigaben. Erst wenn Modellgröße, Hostbudget und Anfrageökonomie gleichzeitig passen, ist die Karte für deinen Zweck wirklich sinnvoll eingeordnet.

Prüffeld	Womit du es prüfst	Warum diese Sicht separat bleibt	Typischer Fehlkauf ohne diese Prüfung
Modellfit und VRAM-Reserve	LLM-VRAM-Anforderungen plus Lokale KI mit Ollama	die Gewichts- und Runtime-Frage entscheidet zuerst, ob eine Karte überhaupt zur Zielklasse passt	eine vermeintlich günstige GPU, die das Zielmodell nur mit aggressivem Offloading oder ohne echte Reserve trägt
Hostbudget aus Netzteil, Luftpfad und Dauerlast	Netzteil-Rechner plus GPU-Stromverbrauch	die Karte ist nie allein im System; PSU, Slots, Kabelpfad und Kühllast entscheiden mit	24 GB VRAM auf dem Papier, aber ein Host, der Netzteil, Abwärme oder Formfaktor nicht sauber trägt
Anfrageökonomie und tägliche Last	Inferenzkosten-Rechner plus KI-API-Preise Vergleich	erst hier wird sichtbar, ob lokale Inferenz für deinen Request-Stil wirtschaftlich oder nur technisch reizvoll ist	eine große Karte für einen Workload, der betriebswirtschaftlich dauerhaft besser als API oder Hybrid laufen würde

Einordnung: Diese Matrix ist eine Betriebsinferenz aus den oben dokumentierten Hersteller- und Runtime-Grenzen. Sie ist gerade deshalb wertvoll, weil sie drei Entscheidungen trennt, die im Hype um VRAM oder Straßenpreis oft vorschnell zusammengezogen werden.

Der haeufigste KI-Fehlkauf entsteht nicht beim ersten Benchmark, sondern beim stillen Rollenwechsel: Eine Karte, die fuer lokale Tests beschafft wurde, soll ploetzlich dauerhaft Requests bedienen, mit mehreren Nutzern laufen oder als GPU-Host weitere Dienste tragen. Genau hier wird aus einer Komponentenfrage eine Betriebsfrage.

Betriebsrolle	Was vor der Freigabe klar sein muss	Warum der Schritt nicht nur Hardware betrifft
lokaler Einzelplatz-Test	Modell startet mit Reserve, Messwerte sind plausibel und Warm-/Kaltverhalten ist bekannt	hier reicht oft ein lokaler Runtime-Pfad ohne dauerhafte 24/7-Annahme
interner Tool- oder API-Host	Monitoring, API-Pfad, Zugriffskontrolle und Hostdruck sind bewusst beschrieben	ab hier tragen Ollama, Monitoring und Reverse Proxy dieselbe Rolle mit
24/7-Inferenzdienst	Dauerlast, Kuehlung, Netzteilreserve und Strompfad bleiben auch ausserhalb kurzer Tests tragfaehig	damit wird die GPU Teil deiner echten Host- und Energiekosten statt nur ein Lab-Werkzeug
spaeterer Multi-GPU- oder Serverpfad	Board, PSU, Slotbreite und Airflow sind als Plattformfrage akzeptiert, nicht als spontane Nachruestung	hier kippt die Entscheidung oft in Workstation- oder Server-Hardware

Der Nutzen dieser Matrix ist direkt: Du kaufst keine GPU mehr fuer eine diffuse Zukunft, sondern fuer eine klar benannte Betriebsrolle. Genau das drueckt Fehlkaeufe, weil Hostdruck, Monitoring, API-Freigabe und Stromkosten vor dem Aufruesten sichtbar werden.

Eine brauchbare GPU für lokale KI ist die Karte, die dein Modellziel mit Reserve, im passenden Runtime-Pfad und innerhalb der realen Hostgrenzen trägt. Genau deshalb sind VRAM, TGP, Formfaktor, Airflow und Topologie wichtiger als Hype oder Straßenpreis.

Wenn du dir nur eine Regel merken willst, dann diese: erst Single-GPU sauber planen, dann über Multi-GPU oder Cluster nachdenken. Das spart Geld, Strom und Integrationszeit.