Eine einzelne RTX 5090 mit 32 GB GDDR7 reicht für die meisten lokalen Sprachmodelle bis etwa 33 Milliarden Parameter. Wer aber ein 70B-Modell wie Llama 4 oder Qwen 3 in ordentlicher Quantisierung laufen lassen will, kommt an einer zweiten oder dritten Karte kaum vorbei. Genau hier setzt dieser Artikel an: Er zeigt, wie du eine Multi-GPU-KI-Workstation aus mehreren Consumer-Grafikkarten baust, die GPUs sauber erkennt und den verfügbaren VRAM über PCIe bündelst, statt auf teure Rechenzentrums-Hardware zu warten.
Der Zeitpunkt passt: Anfang 2026 hat sich die Preisspanne bei KI-tauglichen GPUs deutlich aufgefächert. Eine RTX 5060 Ti mit 16 GB kostet aktuell rund 560 US-Dollar und reicht bereits für 24B-Modelle, während professionelle Karten wie die RTX PRO 6000 Blackwell mit 96 GB laut Tom’s Hardware im August 2026 auf rund 16.000 US-Dollar geklettert sind, doppelt so viel wie beim Vorbestellstart. Zwei oder drei günstigere Karten zu kombinieren ist für viele Teams die realistischere Antwort auf große Modelle als eine einzelne High-End-GPU.
Parallel dazu bewegt sich auch die andere Seite des Marktes. AMD hat im August 2026 mit Helios eine Rack-Plattform vorgestellt, die sechste Generation Epyc-9006-CPUs mit den neuen Instinct-MI455X-Beschleunigern kombiniert, und Apple hat am 25. August 2026 die Chips M6 und M5 Ultra angekündigt. Beide Ansätze zeigen, wie unterschiedlich Hersteller das Speicherproblem lösen, mit riesigem Unified Memory bei Apple oder gebündeltem Rechenzentrums-Netzwerk bei AMD. Für Privatanwender und kleine Teams bleibt die pragmatische Lösung aber der eigene Rechner mit zwei oder mehr GPUs im selben Gehäuse.
shattered.io hat bereits gezeigt, wie du eine einzelne RTX 5090 für lokale KI einrichtest. Dieses Tutorial baut darauf auf und geht einen Schritt weiter: Es dreht sich um Mainboard-Auswahl, PCIe-Lanes, NUMA-Topologie, Tensor-Parallelismus mit vLLM und die Frage, wie viel Leistung eine Multi-GPU-KI-Workstation gegenüber einer einzelnen Karte tatsächlich gewinnt. Am Ende steht ein reproduzierbares Setup mit Monitoring, docker-compose-Datei und einer Checkliste für die häufigsten Stolperfallen.
Voraussetzungen: Hardware, Software und Versionen
Eine Multi-GPU-KI-Workstation stellt andere Anforderungen als ein normaler Gaming-PC. Vor allem die Anzahl der verfügbaren PCIe-Lanes und die Kühlung mehrerer Karten im selben Gehäuse entscheiden darüber, ob das Projekt gelingt. Die folgende Liste zeigt die getesteten Mindestversionen für dieses Tutorial.
- GPUs: 2 bis 4 Nvidia-Karten derselben Generation, etwa 2x RTX 5090 (32 GB) oder 2 bis 4x RTX 5070 Ti (16 GB)
- Mainboard: mit mindestens zwei PCIe-x16-Slots im elektrischen x8/x8-Modus oder besser, idealerweise HEDT- oder Workstation-Chipsatz mit mehr Lanes
- Netzteil: mindestens 1600 Watt bei zwei Karten, ATX 3.1 mit ausreichend 12V-2×6-Anschlüssen
- Betriebssystem: Ubuntu 24.04 LTS (empfohlen für Multi-GPU-Workloads gegenüber Windows)
- Treiber: Nvidia-Treiber ab Version 570.x mit CUDA 12.6 oder neuer
- Python: Version 3.11 oder 3.12
- Docker: ab Version 27.x mit installiertem NVIDIA Container Toolkit
- Software-Stack: llama.cpp (aktueller Build), vLLM ab Version 0.9
- Arbeitsspeicher (RAM): mindestens 64 GB DDR5-5600, bei vier GPUs eher 128 GB
- Speicherplatz: mindestens 500 GB freier NVMe-Speicher für mehrere große Modelldateien
Zum RAM-Kauf noch ein Praxishinweis: shattered.io hat bereits über die DRAM- und NAND-Preisentwicklung 2026 berichtet. Wer eine Multi-GPU-Workstation plant, sollte den Speicher früh bestellen, bevor die nächste Preisrunde greift. Bei zwei oder mehr GPUs zieht außerdem jede Karte eigene PCIe-Lanes vom Chipsatz ab, weshalb sich ein Blick ins Mainboard-Handbuch vor dem Kauf wirklich lohnt.
| Komponente | Mindestversion | Prüfbefehl |
|---|---|---|
| Nvidia-Treiber | 570.x | nvidia-smi |
| CUDA Toolkit | 12.6 | nvcc –version |
| Python | 3.11 oder 3.12 | python3 –version |
| Docker | 27.x | docker –version |
| vLLM | 0.9 oder neuer | python3 -c “import vllm; print(vllm.__version__)” |
Warum mehrere GPUs? VRAM-Pooling für lokale KI einfach erklärt
Der Grundgedanke hinter einer Multi-GPU-KI-Workstation ist simpel: Ein großes Sprachmodell wird in Schichten oder Tensoren zerlegt, die auf mehrere Karten verteilt werden. Jede GPU hält dabei nur einen Teil der Modellgewichte im eigenen Speicher, wodurch sich der insgesamt nutzbare VRAM addiert. Zwei Karten mit je 24 GB ergeben so effektiv 48 GB nutzbaren Speicher für ein Modell, auch wenn keine einzelne Karte allein so viel Platz hätte.
Welche Modellgröße wie viel VRAM braucht, hängt stark von der Quantisierung ab. Als grobe Richtwerte für 4-Bit-quantisierte Modelle gilt: Alles unter 13 Milliarden Parametern passt bequem auf eine einzelne 16-GB- oder 24-GB-Karte. Ab 14 bis 33 Milliarden Parametern wird es auf einer einzelnen Karte eng, und ab 34 bis 70 Milliarden Parametern führt an mehreren GPUs kaum ein Weg vorbei.
Zwei Begriffe tauchen dabei immer wieder auf und werden gerne durcheinandergebracht. Tensor-Parallelismus zerlegt einzelne Matrixmultiplikationen innerhalb einer Schicht auf mehrere GPUs, die dafür ständig Zwischenergebnisse austauschen müssen. Pipeline-Parallelismus dagegen weist jeder GPU ganze Schichten am Stück zu, sodass Daten wie am Fließband von einer Karte zur nächsten wandern. Tensor-Parallelismus braucht mehr Kommunikation, skaliert dafür bei einzelnen Anfragen oft besser. Pipeline-Parallelismus kommuniziert seltener, lohnt sich aber vor allem bei vielen gleichzeitigen Anfragen im Batch-Betrieb. llama.cpp mit –tensor-split nutzt praktisch eine einfache Form von Layer-Splitting, was näher an Pipeline-Parallelismus liegt, während vLLM mit –tensor-parallel-size echten Tensor-Parallelismus umsetzt.
| Modellgröße | VRAM-Bedarf (Q4-Quantisierung) | Empfohlenes GPU-Setup |
|---|---|---|
| 7B – 13B | ca. 8 – 10 GB | 1x GPU mit 16 GB+ |
| 14B – 33B | ca. 18 – 24 GB | 1x GPU mit 24 GB+ oder 2x GPU im Split |
| 34B – 70B | ca. 40 – 48 GB | 2x GPU mit je 24 – 32 GB |
| 70B+ (höhere Präzision) | 80 GB+ | 3 – 4x GPU im Verbund |
PCIe-Bus statt NVLink: Was das für Consumer-GPUs bedeutet
Ein wichtiger Unterschied zu Rechenzentrums-GPUs wie H100 oder H200: Nvidia hat NVLink-Brücken für GeForce-Karten seit der RTX-3090-Generation gestrichen. Eine RTX 5090 oder RTX 5070 Ti kommuniziert mit einer zweiten Karte also ausschließlich über den PCIe-Bus, nicht über eine direkte, viel schnellere GPU-zu-GPU-Verbindung. Das begrenzt, wie stark ein Multi-GPU-Aufbau mit Consumer-Karten tatsächlich skaliert, ändert aber nichts daran, dass sich der VRAM trotzdem bündeln lässt. Für Inferenz reicht die PCIe-Bandbreite in der Praxis meist aus, bei Training oder Fine-Tuning wird der fehlende NVLink deutlich spürbarer.
GPU-Wahl: RTX 5090, RTX 5070 Ti oder gebrauchte Karten kombinieren?
Für die Karten selbst gibt es drei realistische Wege. Der erste ist der teuerste: zwei neue RTX 5090 mit je 32 GB, die zusammen 64 GB VRAM bereitstellen und auch anspruchsvollere 70B-Modelle mit größerem Kontextfenster tragen. Der zweite Weg setzt auf die RTX 5070 Ti mit 16 GB, die aktuell deutlich günstiger zu bekommen ist und bei zwei oder drei Karten in Summe ebenfalls ein brauchbares VRAM-Polster ergibt, allerdings mit spürbar geringerer Rohleistung pro Karte. Noch einen Schritt darunter liegt die RTX 5060 Ti mit 16 GB, aktuell für rund 560 US-Dollar zu haben und laut mehreren Build-Guides die günstigste neue Karte, die für 24B-Modelle überhaupt noch sinnvoll infrage kommt. Drei dieser Karten zusammen kosten oft weniger als eine einzelne RTX 5090 und ergeben in Summe 48 GB VRAM, allerdings mit drei getrennten PCIe-Steckplätzen, drei Kühlkörpern und entsprechend mehr Planungsaufwand beim Gehäuse.
Der dritte Weg ist der Gebrauchtmarkt: Eine ältere RTX 3090 oder RTX 4090 mit 24 GB lässt sich oft deutlich unter Neupreis finden und eignet sich gut als Ergänzung zu einer bereits vorhandenen Karte. Der Nachteil ist die ungewisse Vorgeschichte. Karten aus dem Mining-Einsatz liefen oft jahrelang unter Dauerlast, was die Lebensdauer der Lüfterlager verkürzen kann. Prüfe gebrauchte Karten deshalb immer mit einem Stresstest über mehrere Stunden, bevor du dich auf sie verlässt, und kontrolliere die Betriebsstunden über nvidia-smi -q, falls der Verkäufer sie nicht ausgelesen hat.
Für einen neuen Multi-GPU-Aufbau ist die Empfehlung eindeutig: gleiche Karten, gleiche Speichergröße. Das vereinfacht –tensor-split und –tensor-parallel-size erheblich, weil du keine krummen Verhältnisse berechnen musst und beide Karten bei Tensor-Parallelismus gleich schnell durch ihren Anteil der Rechnung kommen.
Schritt 1-2: Mainboard, PCIe-Lanes und Netzteil planen
Bevor du eine zweite Karte kaufst, prüfe die Lane-Aufteilung deines Mainboards im Handbuch. Viele Consumer-Boards bieten zwar zwei x16-Slots physisch an, schalten den zweiten Slot elektrisch aber nur mit x4 oder x8 an, sobald beide belegt sind. Für ein funktionierendes Multi-GPU-Setup willst du mindestens x8/x8, besser x16/x16. Viele Board-Handbücher listen diese Aufteilung unter einer Tabelle namens “PCIe Configuration” oder “Slot Layout”, oft versteckt im Anhang statt im Hauptteil der Anleitung.
Ein zweiter Blick lohnt sich auf die M.2-Slots. Bei manchen Mainboards teilen sich ein M.2-Steckplatz und der zweite PCIe-x16-Slot dieselben Lanes vom Chipsatz. Steckst du dort eine NVMe-SSD ein, kann sich der GPU-Slot automatisch auf x8 oder sogar x4 reduzieren, ganz ohne dass du das im BIOS aktiv geändert hast. Prüfe diese Abhängigkeit im Handbuch, bevor du dich wunderst, warum die zweite Karte langsamer angebunden ist als erwartet.
| Anzahl GPUs | Empfohlene PCIe-Anbindung | Typische Plattform |
|---|---|---|
| 1 GPU | PCIe 4.0 x8 reicht meist aus | Consumer-Mainboard (AM5, LGA1851) |
| 2 GPUs | PCIe 4.0 x16/x16 oder x8/x8 | Consumer-Mainboard mit zwei vollwertigen Slots |
| 3-4 GPUs | PCIe 5.0 oder Workstation-Plattform | Threadripper, Epyc oder HEDT-Board |
Consumer-Mainboard vs. Workstation-Plattform
Für zwei Karten reicht in der Regel ein gutes AM5- oder LGA1851-Mainboard mit ausreichend Lanes vom Chipsatz. Ab drei oder vier GPUs wird ein Wechsel auf eine HEDT- oder Workstation-Plattform mit deutlich mehr PCIe-Lanes fast zwingend, weil sonst nicht genug Bandbreite für alle Karten gleichzeitig übrig bleibt. Wer schon länger mit dem Gedanken spielt, aus Kostengründen bei zwei Karten zu bleiben, findet dort meist das bessere Preis-Leistungs-Verhältnis.
Beim Netzteil rechnest du am besten mit Reserve. Eine RTX 5090 zieht laut bisherigen Messungen bis zu 575 Watt unter Volllast. Zwei Karten kommen damit allein auf rund 1150 Watt, dazu CPU, Mainboard und Lüfter mit weiteren 200 bis 300 Watt. Ein 1600-Watt-Netzteil ist für zwei Karten das Minimum, bei drei oder vier Karten braucht es entweder ein noch stärkeres Netzteil oder eine Zusatzlösung mit zwei gekoppelten Netzteilen. In Österreich ist die Stromversorgung mit 230 Volt hier kein limitierender Faktor, anders als in Ländern mit 120-Volt-Haushaltsnetz und niedrigerer Absicherung pro Steckdose.
Schritt 3-4: Einbau, Gehäuse-Airflow und Kabelmanagement
Setze zuerst die Karte in den obersten x16-Slot, dann die zweite eine Etage darunter. Achte auf mindestens einen freien Slot Abstand zwischen den Karten, sonst zieht die untere Karte nur noch die Abwärme der oberen an. Bei sehr dicken Kühlern mit drei Lüftern reicht ein einzelner freier Slot oft trotzdem nicht, dann helfen PCIe-Riser-Kabel, um die zweite Karte seitlich oder vertikal zu montieren. Achte beim Riser-Kabel auf die passende PCIe-Generation, denn ein günstiges PCIe-3.0-Kabel bremst eine PCIe-5.0-fähige Karte spürbar aus. Ein zertifiziertes Kabel für PCIe 4.0 oder 5.0 kostet zwar mehr, verhindert aber genau die Bandbreitenprobleme, die sich später nur schwer über nvidia-smi topo -m diagnostizieren lassen.
Für den Airflow gilt bei zwei oder mehr GPUs im selben Gehäuse eine einfache Regel: mehr Lüfter als bei einem Ein-Karten-System, und zwar konsequent von vorne nach hinten beziehungsweise unten nach oben durchgezogen. Drei Lüfter an der Front als Einlass und drei am Deckel oder Heck als Auslass sind für ein Mehr-GPU-System mit Dauerlast eine realistische Grundausstattung. Miss die Gehäusetemperatur nach den ersten Stunden Dauerbetrieb, bevor du dich auf ein bestimmtes Lüfterprofil festlegst.
Beim Kabelmanagement lohnt sich Geduld. Verlege beide 12V-2×6-Kabel getrennt voneinander, ohne sie zu verdrillen, und kontrolliere jeden Stecker mit einer Taschenlampe auf vollständigen Sitz. Ein Stecker, der nur halb einrastet, ist bei einer Karte ärgerlich, bei zwei Karten mit gemeinsamem Netzteil aber ein Sicherheitsrisiko, das du dir ersparen willst.
Schritt 5-6: Nvidia-Treiber, CUDA Toolkit und NUMA-Topologie prüfen
Für die Treiberinstallation selbst gibt es bereits einen eigenen Schritt-für-Schritt-Artikel auf shattered.io. Für dieses Tutorial reichen die folgenden Befehle unter Ubuntu 24.04, das CUDA Toolkit von Nvidia liefert dabei die Treiber- und Compiler-Basis für alles Weitere:
sudo apt update
sudo apt install -y build-essential dkms
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-6 nvidia-driver-570
sudo rebootNach dem Neustart prüfst du, ob beide Karten erkannt werden:
nvidia-smi --list-gpusDie Ausgabe sollte zwei Zeilen zeigen, etwa “GPU 0: NVIDIA GeForce RTX 5090” und “GPU 1: NVIDIA GeForce RTX 5090”, jeweils mit eigener UUID. Fehlt eine Karte in der Liste, sitzt entweder der Stromstecker nicht richtig oder der PCIe-Slot ist im BIOS deaktiviert.
Der nächste Befehl zeigt die eigentliche Topologie zwischen den Karten und der CPU. Genau dieser Schritt wird bei Multi-GPU-Setups am häufigsten übersprungen, ist aber entscheidend für die spätere Performance:
nvidia-smi topo -mAuf einem typischen Zweikarten-System mit einem Sockel sieht die Ausgabe etwa so aus:
GPU0 GPU1 CPU Affinity NUMA Affinity
GPU0 X PIX 0-15 0
GPU1 PIX X 0-15 0Die Matrix zeigt für jedes GPU-Paar, wie die Verbindung verläuft. “PIX” bedeutet Verbindung über maximal einen PCIe-Switch, “PHB” über die CPU-Host-Bridge, “SYS” über den langsameren Weg zwischen zwei CPU-Sockeln oder NUMA-Knoten. In der letzten Spalte steht außerdem, welchem NUMA-Knoten jede GPU zugeordnet ist. Liegen beide Karten wie im Beispiel auf demselben NUMA-Knoten, ist das für Inferenz-Workloads klar von Vorteil, weil der Speicherzugriff der CPU dann keine Knotengrenze überqueren muss. Zeigt deine Ausgabe stattdessen unterschiedliche NUMA-Knoten für die beiden Karten, solltest du beim nächsten Umbau gezielt Slots wählen, die am selben Prozessor hängen.
Schritt 7-8: GPU-Sichtbarkeit steuern und Python-Umgebung einrichten
Mit der Umgebungsvariable CUDA_VISIBLE_DEVICES legst du fest, welche Karten ein Prozess überhaupt sehen darf. Das ist praktisch, wenn du zum Testen nur eine GPU nutzen willst oder wenn zwei verschiedene Modelle gleichzeitig auf unterschiedlichen Karten laufen sollen:
# Nur GPU 0 verwenden
export CUDA_VISIBLE_DEVICES=0
# Beide GPUs verwenden, in dieser Reihenfolge
export CUDA_VISIBLE_DEVICES=0,1
# Reihenfolge nach PCI-Bus-ID statt CUDA-interner Nummerierung sortieren
export CUDA_DEVICE_ORDER=PCI_BUS_IDDer zweite Befehl ist kein Detail: Ohne CUDA_DEVICE_ORDER=PCI_BUS_ID kann es passieren, dass CUDA und nvidia-smi die Karten in unterschiedlicher Reihenfolge nummerieren, was bei –tensor-split oder –tensor-parallel-size später zu falsch zugeordneten Modellteilen führt. Setze diese Variable am besten dauerhaft in der ~/.bashrc.
Danach richtest du eine saubere Python-Umgebung ein:
python3 -m venv ~/ki-workstation
source ~/ki-workstation/bin/activate
pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu126
pip install vllm huggingface_hubPrüfe anschließend, ob PyTorch beide Karten erkennt:
python3 -c "import torch; print(torch.cuda.device_count(), torch.cuda.get_device_name(0))"Die Ausgabe sollte “2 NVIDIA GeForce RTX 5090” oder die entsprechende Kartenzahl und Bezeichnung zeigen. Steht dort nur “1”, stimmt entweder CUDA_VISIBLE_DEVICES nicht oder eine Karte wurde von Treiber oder BIOS nicht korrekt initialisiert.
Schritt 9: llama.cpp mit Multi-GPU-Unterstützung kompilieren
llama.cpp unterstützt Multi-GPU-Aufteilung direkt beim Kompilieren mit aktivierter CUDA-Unterstützung. Kompiliere den aktuellen Stand so:
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=native
cmake --build build --config Release -j$(nproc)Der Build dauert je nach CPU zwischen fünf und fünfzehn Minuten. Danach findest du die fertigen Binaries unter build/bin, unter anderem llama-server und llama-cli.
Schritt 10: Ein 70B-Modell auf zwei GPUs verteilen
Lade zunächst ein quantisiertes 70B-Modell im GGUF-Format, zum Beispiel über Hugging Face. Starte danach den Server mit –tensor-split, um die Modellschichten proportional auf beide Karten zu verteilen:
./build/bin/llama-server \
--model ./models/llama-4-70b-instruct.Q4_K_M.gguf \
--n-gpu-layers 999 \
--tensor-split 1,1 \
--ctx-size 8192 \
--host 0.0.0.0 \
--port 8080Das Verhältnis “1,1” bei –tensor-split bedeutet eine gleichmäßige Aufteilung auf beide Karten. Bei zwei unterschiedlich großen GPUs, etwa einer RTX 5090 neben einer RTX 4090, passt du das Verhältnis proportional zum jeweiligen VRAM an, damit die kleinere Karte nicht überläuft. –n-gpu-layers 999 weist llama.cpp an, so viele Schichten wie möglich auf die GPUs zu laden, der eigentliche Wert wird automatisch auf die tatsächliche Modelltiefe begrenzt.
So sieht eine erfolgreiche Startmeldung aus:
llama_model_load: using device CUDA0 (NVIDIA GeForce RTX 5090) - 32255 MiB free
llama_model_load: using device CUDA1 (NVIDIA GeForce RTX 5090) - 32255 MiB free
llama_new_context_with_model: KV self size = 2560.00 MiB
main: server is listening on http://0.0.0.0:8080Zeigen beide CUDA-Zeilen den freien Speicher deiner Karten, war die Aufteilung erfolgreich. Bricht der Server stattdessen mit “CUDA out of memory” ab, ist entweder die Kontextgröße zu hoch gewählt oder die Quantisierung zu grob für den verfügbaren VRAM.
Schritt 11: vLLM für echten Tensor-Parallelismus einrichten
vLLM geht einen Schritt weiter als llama.cpp: Statt Schichten einfach zwischen Karten aufzuteilen, zerlegt es einzelne Tensoren innerhalb einer Schicht und lässt beide GPUs echte Rechenoperationen parallel ausführen. Das ist technisch anspruchsvoller, bringt bei Batch-Anfragen aber spürbar mehr Durchsatz als reines Layer-Splitting:
vllm serve meta-llama/Llama-4-70B-Instruct \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.9 \
--max-model-len 8192 \
--port 8000–tensor-parallel-size 2 sagt vLLM, das Modell über zwei GPUs zu verteilen und für jede Anfrage synchron auf beiden Karten zu rechnen. –gpu-memory-utilization 0.9 reserviert 90 Prozent des VRAM für Modell und KV-Cache, was in der Praxis ein guter Kompromiss zwischen Auslastung und Sicherheitsreserve ist. Teste den Server danach mit einer einfachen Anfrage an die OpenAI-kompatible Schnittstelle:
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{"model": "meta-llama/Llama-4-70B-Instruct", "prompt": "Erkläre PCIe in einem Satz.", "max_tokens": 60}'Schritt 12-13: Benchmarking und Monitoring über mehrere GPUs
shattered.io hat für eine einzelne RTX 5090 bereits 213 Tokens pro Sekunde bei einem quantisierten Modell gemessen. Bei einer Multi-GPU-KI-Workstation ohne NVLink darfst du keine glatte Verdopplung erwarten, wenn du eine zweite Karte hinzufügst. Weil die Kommunikation zwischen den GPUs über den PCIe-Bus läuft und dort Zeit kostet, liegt die tatsächliche Skalierung bei Tensor-Parallelismus in der Praxis meist deutlich unter dem theoretischen Faktor zwei. Wofür sich die zweite Karte trotzdem lohnt: Sie ermöglicht überhaupt erst, ein Modell zu laden, das auf einer einzelnen Karte gar nicht in den VRAM passen würde.
Miss den Durchsatz konsistent mit demselben Prompt und derselben Ausgabelänge, sonst sind die Werte zwischen Testläufen nicht vergleichbar. Notiere dir außerdem, ob du llama.cpp mit –tensor-split oder vLLM mit –tensor-parallel-size getestet hast, weil beide Ansätze unterschiedlich stark von der zweiten Karte profitieren.
Für laufendes Monitoring beider Karten reicht ein einfaches Bash-Skript, das Auslastung, Speicher und Temperatur protokolliert:
#!/bin/bash
LOGFILE="$HOME/gpu-monitor.log"
while true; do
echo "$(date '+%Y-%m-%d %H:%M:%S')" >> "$LOGFILE"
nvidia-smi --query-gpu=index,utilization.gpu,memory.used,memory.total,temperature.gpu \
--format=csv,noheader >> "$LOGFILE"
sleep 30
doneStarte das Skript im Hintergrund mit nohup, oder trage es als systemd-Service ein, damit es nach jedem Neustart automatisch läuft. Ein Blick ins Log nach ein paar Stunden Dauerbetrieb zeigt zuverlässig, ob eine Karte thermisch drosselt oder deutlich unausgelasteter bleibt als die andere.
Sicherheit: Netzwerk und API-Zugriff absichern
Ein Server, der mit –host 0.0.0.0 startet, ist im lokalen Netzwerk erreichbar, aber eben auch für jedes andere Gerät darin. Das ist beim schnellen Test praktisch, im Dauerbetrieb aber ein Risiko, besonders wenn der Rechner gleichzeitig andere Aufgaben übernimmt. Öffne den Port deshalb nicht direkt zum Internet, sondern beschränke den Zugriff mit einer Firewall auf dein eigenes Subnetz:
sudo ufw allow from 192.168.0.0/24 to any port 8000
sudo ufw allow from 192.168.0.0/24 to any port 8080
sudo ufw enableWillst du die API auch von außerhalb des Heimnetzes nutzen, setz einen Reverse Proxy mit eigenem API-Key davor, statt vLLM oder llama.cpp direkt ans Internet zu hängen. Beide Projekte bieten inzwischen einfache Token-Header-Prüfung an, ein zusätzlicher Proxy mit Rate-Limiting schützt aber zuverlässiger vor versehentlich offen gelassenen Ports und vor Kostenexplosion durch missbräuchliche Dauerabfragen, falls du die Workstation später einmal öffentlich erreichbar machst.
Denk außerdem an das Netzwerk zwischen den Diensten selbst, wenn mehrere Container oder Prozesse auf derselben Maschine laufen. Eine Docker-interne Netzwerktrennung zwischen dem vLLM-Container und einer öffentlich erreichbaren Web-Anwendung verhindert, dass eine Sicherheitslücke in der Web-Oberfläche direkten Zugriff auf die Inferenz-API erlaubt. Für sensible Daten, etwa firmeninterne Dokumente, die über das Modell verarbeitet werden, lohnt sich zusätzlich ein Blick auf Logging: Speichere Prompts und Antworten nur so lange, wie du sie wirklich brauchst, und dokumentiere, wer auf die Logs zugreifen kann.
Zum Vergleich: shattered.io hat bereits über Nvidias eigenes Angebot berichtet, den RTX Spark als vorkonfigurierten Windows-KI-PC. Eine selbst gebaute Multi-GPU-Workstation braucht mehr Eigenarbeit bei Sicherheit und Wartung, bietet dafür aber volle Kontrolle über Netzwerk, Modelle und Daten, ohne von der Update-Politik eines Herstellers abhängig zu sein.
Die 5 häufigsten Fehler beim Multi-GPU-KI-Setup
Die meisten Probleme bei einer Multi-GPU-Workstation entstehen nicht in der Software, sondern schon vorher, beim Zusammenbau oder bei der Grundkonfiguration. Die folgenden fünf Fehler tauchen in Foren und Support-Anfragen immer wieder auf, meist weil sie beim ersten Ein-Karten-System noch keine Rolle gespielt haben.
- Unterschiedliche Treiberversionen pro Karte: Nach einem Kartentausch bleibt manchmal ein alter Treiber-Rest aktiv. Prüfe nach jeder Hardwareänderung mit nvidia-smi, ob beide Karten dieselbe Treiberversion melden.
- PCIe-Slot im x4-Modus übersehen: Wer den zweiten Slot nicht im Handbuch prüft, landet oft bei x4 statt x8, was Ladezeiten und Tensor-Parallelismus spürbar ausbremst.
- CUDA_DEVICE_ORDER nicht gesetzt: Ohne PCI_BUS_ID als Sortierung können –tensor-split-Werte auf der falschen Karte landen, was zu Abstürzen oder stark ungleicher Auslastung führt.
- Zu knapp bemessenes Netzteil: Zwei Karten mit je 575 Watt Spitzenlast plus System brauchen mehr Reserve, als viele beim ersten Überschlag einplanen.
- Fehlender Slot-Abstand: Zwei Karten direkt übereinander ohne freien Slot dazwischen führen fast immer zu Throttling der unteren Karte nach wenigen Minuten Volllast.
Troubleshooting: 8 Probleme und ihre Lösungen
Auch wenn Hardware und Treiber sauber eingerichtet sind, tauchen im laufenden Betrieb eines Multi-GPU-Setups typische Fehlermeldungen auf. Die folgende Liste sammelt die häufigsten Fälle aus der Praxis, sortiert von der Hardware-Erkennung bis zur laufenden Inferenz.
- Nur eine GPU wird angezeigt: Prüfe den Stromstecker der zweiten Karte und ob der PCIe-Slot im BIOS aktiviert ist. Ein loser 12V-2×6-Stecker ist die häufigste Ursache.
- CUDA out of memory trotz zwei Karten: Reduziere –ctx-size oder –max-model-len, oder senke –gpu-memory-utilization etwas ab, um Reserve für den KV-Cache zu schaffen.
- vLLM startet nicht mit tensor-parallel-size 2: Prüfe mit nvidia-smi topo -m, ob beide Karten überhaupt sichtbar sind, und stelle sicher, dass CUDA_VISIBLE_DEVICES nicht versehentlich auf eine einzelne Karte begrenzt wurde.
- Sehr ungleiche Auslastung zwischen den Karten: Passe das Verhältnis bei –tensor-split an die tatsächliche VRAM-Größe jeder Karte an, statt pauschal “1,1” zu verwenden.
- System friert unter Volllast beider Karten ein: Meist ein Netzteil-Problem. Prüfe mit einem Strommessgerät die tatsächliche Spitzenlast und vergleiche sie mit der Netzteil-Kapazität.
- Modell lädt sehr langsam von der SSD: Große GGUF-Dateien über 40 GB profitieren stark von NVMe statt SATA-SSD. Prüfe mit hdparm oder einem einfachen dd-Test die reale Lesegeschwindigkeit.
- NUMA-Warnung beim Start: Erscheint eine Warnung zu NUMA-Knoten-Grenzen, prüfe mit nvidia-smi topo -m, ob beide Karten am selben Knoten hängen. Ist das nicht der Fall, hilft oft nur ein anderer Slot oder ein Umbau auf ein Dual-Sockel-System mit bewusster Zuordnung.
- Temperatur einer Karte deutlich höher als der anderen: Meist ein Airflow-Problem. Ergänze zusätzliche Gehäuselüfter oder wechsle auf eine offene Testbank-Konfiguration für die Fehlersuche.
Erweiterte Tipps für Power-User
Wer regelmäßig zwischen mehreren Modellen wechselt, kann Pipeline-Parallelismus und Tensor-Parallelismus kombinieren: vLLM unterstützt neben –tensor-parallel-size auch –pipeline-parallel-size, was bei mehr als zwei Karten oft eine bessere Balance zwischen Kommunikationsaufwand und Rechenleistung liefert als reiner Tensor-Parallelismus über alle Karten hinweg.
Zum Stromsparen im Dauerbetrieb lohnt sich ein Power-Limit über nvidia-smi -pl, etwa auf 450 statt 575 Watt pro Karte. Der Tokens-pro-Sekunde-Verlust ist bei Inferenz-Workloads oft kleiner als der Wattzahl-Unterschied vermuten lässt, weil die GPU selten dauerhaft am absoluten Leistungslimit rechnet.
Für gemischte Karten-Generationen, etwa eine RTX 5090 neben einer älteren RTX 4090, gilt: Tensor-Parallelismus funktioniert technisch, verschenkt aber Leistung, weil sich das System am langsamsten Glied orientiert. Für ernsthafte Multi-GPU-Workloads lohnt sich der Mehrpreis für zwei identische Karten meist schneller, als man beim Kauf der zweiten, günstigeren Karte denkt.
Wer AWQ- oder GPTQ-quantisierte Modelle statt GGUF nutzt, sollte in vLLM den passenden –quantization-Parameter setzen. Diese Formate sind für Tensor-Parallelismus oft günstiger als reine GGUF-Quantisierung, weil sie von Haus aus auf parallele Matrixmultiplikation ausgelegt sind.
Statt ein einzelnes großes Modell über alle Karten zu verteilen, kannst du zwei GPUs auch getrennt betreiben und darauf zwei unterschiedliche, kleinere Modelle gleichzeitig laufen lassen. Mit CUDA_VISIBLE_DEVICES=0 startest du einen llama-server-Prozess für ein schnelles 8B-Modell für einfache Anfragen, mit CUDA_VISIBLE_DEVICES=1 einen zweiten Prozess für ein größeres 32B-Modell für komplexere Aufgaben. Ein vorgeschalteter Router leitet Anfragen dann je nach Komplexität an den passenden Endpunkt weiter. Für Teams mit gemischten Anwendungsfällen ist das oft praktischer als ein einzelnes großes Modell für alles zu erzwingen.
Bei der Wartung lohnt sich ein fixer Rhythmus. Öffne das Gehäuse alle drei bis vier Monate und blas die Kühlkörper beider Karten mit Druckluft aus, denn zwei Karten im selben Gehäuse ziehen mehr Luft und damit auch mehr Staub als ein Einzelkarten-Setup. Eine zugestaubte untere Karte verliert oft zuerst spürbar an Kühlleistung, weil sie ohnehin schon die wärmere Abluft der oberen Karte mitbekommt.
Kostenanalyse: Multi-GPU-Workstation vs. Einzelkarte in Österreich 2026
shattered.io hat bereits dokumentiert, dass eine einzelne RTX 5090 in Österreich aktuell um 5.119 Euro statt der UVP von 2.099 Euro gehandelt wird, ein direkter Effekt der GDDR7-Knappheit. Vor diesem Hintergrund wird eine Multi-GPU-Workstation mit zwei günstigeren Karten für viele Käufer plötzlich attraktiver als der Griff zur einzelnen Topkarte.
| Build-Klasse | Ziel-Modellgröße | Richtwert PSU | Typisches Budget (US-Dollar, ohne AT-Aufschlag) |
|---|---|---|---|
| Einsteiger, 1x GPU | 7B – 13B | 650 Watt | ca. 1.100 US-Dollar |
| Mittelklasse, 1-2x GPU | 14B – 33B | 850 Watt | ca. 2.400 US-Dollar |
| Multi-GPU-Enthusiast, 2-3x GPU | 34B – 70B | 1000 – 1600 Watt | ca. 5.000 US-Dollar |
Diese Richtwerte stammen aus internationalen Build-Guides und beziehen sich auf US-Straßenpreise ohne Importkosten. In Österreich liegen die realen Preise durch Verfügbarkeit und Importaufschläge meist spürbar darüber, wie das Beispiel der RTX 5090 zeigt. Als Faustregel für die Kalkulation: Rechne für den GPU-Anteil in Österreich mit einem Aufschlag von 20 bis 40 Prozent gegenüber US-Listenpreisen, bevor du ein festes Budget planst.
Zum Vergleich, wie groß die Spanne nach oben reicht: Eine professionelle RTX PRO 6000 Blackwell mit 96 GB kostet laut Tom’s Hardware aktuell rund 16.000 US-Dollar, während AMDs neue Helios-Plattform mit Epyc-9006-CPUs und Instinct-MI455X-Beschleunigern klar auf Rechenzentren zielt und für Privatanwender ohnehin keine Option ist. Zwei bis drei Consumer-GPUs im eigenen Gehäuse bleiben für die meisten Teams die realistischere Zwischenlösung.
Auch der Stromverbrauch im Dauerbetrieb gehört in die Kalkulation, gerade weil eine solche Workstation gerne stunden- oder tagelang durchläuft. Als Beispielrechnung: Zwei Karten mit auf 450 Watt begrenzter Leistung plus rund 150 Watt für den Rest des Systems ergeben etwa 1.050 Watt Dauerlast. Bei einem österreichischen Haushaltsstrompreis von grob 0,25 Euro pro Kilowattstunde kostet ein Betriebstag mit acht Stunden Volllast damit ungefähr 2,10 Euro, ein Monat mit dieser Nutzung liegt bei rund 63 Euro. Wer die Karten stattdessen nur sporadisch für einzelne Anfragen hochfährt, bewegt sich naturgemäß deutlich darunter. Die genaue Zahl hängt stark vom eigenen Tarif und Nutzungsmuster ab, dient hier aber als grobe Orientierung für die Budgetplanung.
Vollständiges Projekt: docker-compose-Setup für die Multi-GPU-KI-Workstation
Zum Abschluss ein komplettes, reproduzierbares Setup mit vLLM in Docker. Diese docker-compose.yml bindet gezielt zwei GPUs ein und startet den Server automatisch mit Tensor-Parallelismus:
services:
vllm-multi-gpu:
image: vllm/vllm-openai:latest
restart: unless-stopped
ports:
- "8000:8000"
volumes:
- ./models:/models
environment:
- CUDA_DEVICE_ORDER=PCI_BUS_ID
command: >
--model /models/llama-4-70b-instruct
--tensor-parallel-size 2
--gpu-memory-utilization 0.9
--max-model-len 8192
deploy:
resources:
reservations:
devices:
- driver: nvidia
device_ids: ["0", "1"]
capabilities: [gpu]Starte das Setup mit docker compose up -d und prüfe die Logs mit docker compose logs -f vllm-multi-gpu. Nach etwa ein bis zwei Minuten Ladezeit für ein 70B-Modell steht die OpenAI-kompatible API unter Port 8000 bereit, einsatzbereit für eigene Anwendungen, Chat-Oberflächen oder automatisierte Skripte. Damit hast du eine vollständige Multi-GPU-Workstation für lokale KI, vom BIOS-Setting bis zur laufenden API, einmal komplett durchgebaut.
Zur Erinnerung noch einmal der ganze Weg im Überblick: Mainboard und Netzteil auf zwei Karten auslegen, Treiber und CUDA installieren, NUMA-Topologie und PCIe-Anbindung mit nvidia-smi topo -m prüfen, CUDA_VISIBLE_DEVICES und CUDA_DEVICE_ORDER korrekt setzen, dann llama.cpp oder vLLM mit –tensor-split beziehungsweise –tensor-parallel-size starten. Wer diese Reihenfolge einhält, spart sich die meisten der Fehler, die in den Abschnitten weiter oben beschrieben sind, und kommt deutlich schneller zu einer laufenden Multi-GPU-Workstation als beim planlosen Ausprobieren.
Weiterführende Ressourcen
Related Coverage
- RTX 5090 für lokale KI einrichten
- Nvidia-Treiber installieren: Schritt-für-Schritt-Anleitung
- GPU Benchmark Tutorial
- Nvidia B200 vs. H200 in Österreich
- Speicherchip-Knappheit: DRAM- und NAND-Preise 2026
- RTX 5090 Preis in Österreich und die GDDR7-Knappheit
Weitere Hardware-Themen findest du gesammelt auf der Hardware-Übersichtsseite von shattered.io.
Häufig gestellte Fragen
Brauche ich für eine Multi-GPU-KI-Workstation identische Grafikkarten?
Nicht zwingend, aber empfohlen. Unterschiedliche Karten funktionieren technisch mit angepasstem –tensor-split-Verhältnis, das System orientiert sich bei Tensor-Parallelismus aber immer am langsamsten Glied.
Unterstützt die RTX 5090 NVLink für schnellere Multi-GPU-Kommunikation?
Nein. Nvidia hat NVLink-Brücken für GeForce-Karten seit der RTX-3090-Generation entfernt. Alle Consumer-Karten kommunizieren nur noch über den PCIe-Bus.
Wie viele PCIe-Lanes brauche ich für zwei GPUs?
Mindestens x8/x8 im elektrischen Modus, idealerweise x16/x16. Prüfe das im Mainboard-Handbuch, denn viele Consumer-Boards drosseln den zweiten Slot automatisch, sobald beide belegt sind.
Lohnt sich eine Multi-GPU-KI-Workstation gegenüber einer einzelnen RTX PRO 6000?
Preislich meist ja. Zwei oder drei Consumer-Karten kosten in Summe oft deutlich weniger als die rund 16.000 US-Dollar einer einzelnen RTX PRO 6000 Blackwell, auch wenn die Profikarte pro Karte mehr Speicher und bessere Skalierung bietet.
llama.cpp oder vLLM für Multi-GPU-Inferenz?
llama.cpp mit –tensor-split ist einfacher einzurichten und für einzelne Anfragen ausreichend schnell. vLLM mit –tensor-parallel-size lohnt sich vor allem bei mehreren gleichzeitigen Nutzern, weil es Anfragen effizienter bündelt.
Wie viel Netzteil-Leistung brauche ich für zwei RTX-5090-Karten?
Mindestens 1600 Watt, besser mit Reserve nach oben, da beide Karten unter Volllast zusammen auf über 1100 Watt kommen können, dazu CPU und restliche Komponenten.
Kann ich eine Multi-GPU-Workstation auch unter Windows betreiben?
Technisch ja über WSL2, in der Praxis ist Ubuntu 24.04 aber die stabilere und besser dokumentierte Wahl für Multi-GPU-Workloads mit CUDA.
Was mache ich, wenn eine GPU nach dem Einbau nicht erkannt wird?
Prüfe zuerst den Stromstecker auf vollständigen Sitz, dann mit nvidia-smi –list-gpus, ob der Treiber die Karte überhaupt sieht, und zuletzt im BIOS, ob der jeweilige PCIe-Slot aktiviert ist.
Brauche ich für eine Multi-GPU-Workstation zwingend Wasserkühlung?
Nein. Zwei Luftkühler-Karten funktionieren mit ausreichend Gehäuse-Airflow und einem freien Slot Abstand problemlos. Wasserkühlung wird erst bei drei oder mehr Karten im selben Gehäuse deutlich attraktiver, weil dort der verfügbare Platz für Luftkühler knapp wird.
Kann ich mit zwei GPUs auch zwei verschiedene Modelle gleichzeitig betreiben?
Ja. Mit CUDA_VISIBLE_DEVICES lässt sich jede Karte gezielt einem eigenen Prozess zuweisen, sodass etwa ein kleines Modell auf GPU 0 und ein größeres auf GPU 1 unabhängig voneinander laufen, statt beide Karten für ein einzelnes Modell zu bündeln.
