Die RTX 5090 ist derzeit die schnellste Consumer-GPU für lokale KI-Workloads, mit 32 GB GDDR7-Speicher und 1.792 GB/s Bandbreite laut Nvidias eigenen Spezifikationen. Die Straßenpreise in Österreich liegen aktuell weit über der UVP von 1.999 US-Dollar, wie shattered.io bereits berichtet hat (5.119 Euro statt 2.099 Euro UVP). Wer die Karte trotzdem im Rechner hat oder anschafft, will sie auch für mehr als Gaming nutzen. Dieses Tutorial zeigt Schritt für Schritt, wie du auf einer RTX 5090 ein lokales Sprachmodell installierst, per llama.cpp, Ollama und vLLM betreibst, die Tokens pro Sekunde sauber misst und den VRAM optimal ausnutzt.
Anders als bei einem reinen Gaming-Setup geht es hier um Inferenz-Performance: Wie viele Tokens pro Sekunde schafft die Karte bei einem 8B-Modell, wo liegt die Grenze für 32B- oder 70B-Modelle, und welche Quantisierung liefert die beste Balance zwischen Geschwindigkeit und Qualität. Am Ende hast du ein komplettes, reproduzierbares Setup mit Chat-Oberfläche, Monitoring und einer Checkliste für die häufigsten Fehler.
Das Tutorial richtet sich an Entwicklerinnen und Entwickler, IT-Admins in kleinen Teams und technisch versierte Privatanwender, die Modelle lokal betreiben wollen, sei es aus Datenschutzgründen, wegen wiederkehrender API-Kosten bei gehosteten Diensten oder schlicht aus Neugier. Du brauchst keine Vorerfahrung mit CUDA-Programmierung. Grundlegende Linux-Kommandozeile und etwas Geduld beim Kompilieren reichen aus.
shattered.io hat bereits gezeigt, wie du eine RTX 5090 für 378 FPS im Gaming einrichtest. Dieser Artikel setzt bewusst woanders an: Es geht nicht um Bildraten, sondern um Tokens pro Sekunde, VRAM-Auslastung bei LLM-Inferenz und die Frage, welche Software-Schicht (llama.cpp, Ollama oder vLLM) zu deinem Anwendungsfall passt.
Voraussetzungen: Hardware, Software und Versionen
Bevor du startest, brauchst du ein paar konkrete Komponenten. Die folgende Liste zeigt die getesteten Mindestversionen, mit denen die Schritte in diesem Artikel funktionieren. Prüfe jede Version einzeln nach, denn ein zu altes CUDA-Toolkit oder ein fehlender Docker-Daemon ist die häufigste Ursache für Probleme im späteren Verlauf.
- GPU: Nvidia RTX 5090 (32 GB GDDR7), alternativ RTX 5080 oder RTX 4090 mit angepassten VRAM-Grenzen
- Netzteil: mindestens 1000 Watt, empfohlen 1200 Watt bei einem 12V-2×6-Stecker mit korrektem Sitz
- Betriebssystem: Ubuntu 24.04 LTS oder Windows 11 24H2 mit WSL2
- Treiber: Nvidia-Treiber ab Version 570.x mit CUDA 12.6 oder neuer
- Python: Version 3.11 oder 3.12 (aktuelle PyTorch- und vLLM-Wheels unterstützen 3.13 zum jetzigen Zeitpunkt noch nicht vollständig)
- Docker: ab Version 27.x mit installiertem NVIDIA Container Toolkit
- Arbeitsspeicher (RAM): mindestens 32 GB, besser 64 GB für größere Modell-Downloads und Swapping
- Speicherplatz: mindestens 200 GB frei für Modelldateien und Caches
Ein Hinweis zum RAM-Kauf: DDR5-Kits sind 2026 deutlich teurer geworden. Das deutsche Hardwareportal 3D Center notierte den DDR5-Retailpreisindex im August 2026 bei 486 Prozent, ein Plus von 41 Prozentpunkten gegenüber dem Vormonat. Ein 64-GB-DDR5-5600-Kit, das vor einem Jahr rund 191 US-Dollar kostete, liegt laut Tom’s Hardware inzwischen bei etwa 1.118 US-Dollar. Plane den RAM-Kauf also vor der GPU ein, nicht danach.
| 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 |
| NVIDIA Container Toolkit | aktuell | docker run –rm –gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi |
Schritt 1: Netzteil, Gehäuse und BIOS vorbereiten
Öffne das Gehäuse und prüfe zuerst den Stromanschluss. Die RTX 5090 nutzt den 12V-2×6-Stecker, eine überarbeitete Version des früheren 12VHPWR-Anschlusses. Schiebe das Kabel bis zum spürbaren Klick ein und kontrolliere den Sitz noch einmal mit einer Taschenlampe, bevor du den Rechner schließt. Ein wackelnder Stecker war bei der Vorgängergeneration eine bekannte Brandursache, ein sauberer Sitz ist deshalb kein optionaler Schritt.
Aktiviere anschließend im BIOS “Resizable BAR” beziehungsweise “Smart Access Memory”, da das die PCIe-Kommunikation zwischen CPU und GPU beschleunigt und bei großen Modell-Uploads spürbar hilft. Aktualisiere zudem das Motherboard-BIOS auf die neueste Version, falls dein Board noch keine offizielle RTX-50-Unterstützung gelistet hat. Prüfe abschließend, ob dein Netzteil tatsächlich die volle Wattzahl unter Dauerlast liefert. Für ein Inferenz-Setup läuft die Karte oft stundenlang konstant nahe der Kapazitätsgrenze, ganz anders als beim Gaming mit schwankender Last zwischen den Frames.
Ein oft übersehener Punkt beim Einbau ist das Kartengewicht. Die RTX 5090 bringt bei den meisten Herstellern deutlich über 2 Kilogramm auf die Waage, was den PCIe-Slot über Monate hinweg mechanisch belastet und im schlimmsten Fall zum sichtbaren Durchhängen führt. Eine GPU-Stütze, oft im Karton mitgeliefert oder günstig nachrüstbar, nimmt diesen Druck vom Steckplatz.
Schritt 2: Nvidia-Treiber und CUDA Toolkit installieren
Unter Ubuntu installierst du den Treiber am saubersten über das offizielle Repository, nicht über den generischen Ubuntu-Treiber. Für Details zur Treiberinstallation selbst gibt es bereits einen eigenen Schritt-für-Schritt-Artikel auf shattered.io. Für dieses Tutorial reichen folgende Befehle:
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 die Karte erkannt wird:
nvidia-smiDie Ausgabe sollte “NVIDIA GeForce RTX 5090” mit 32.607 MiB verfügbarem Speicher und der installierten Treiberversion zeigen, etwa so:
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.86.10 Driver Version: 570.86.10 CUDA Version: 12.6 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| 0 NVIDIA GeForce RTX 5090 Off | 00000000:01:00.0 On | N/A |
| 0% 45C P8 28W / 575W | 1024MiB / 32607MiB | 2% Default |
+-----------------------------------------------------------------------------------------+Steht dort stattdessen ein Fehler wie “NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver”, ist meist ein Secure-Boot-Konflikt oder ein fehlender Reboot die Ursache, mehr dazu im Troubleshooting-Abschnitt weiter unten.
Schritt 3: Python-Umgebung und Abhängigkeiten einrichten
Arbeite grundsätzlich in einer isolierten virtuellen Umgebung, damit sich Paketversionen nicht mit anderen Projekten überschneiden. Lege dafür einen eigenen Ordner an und installiere PyTorch mit CUDA-Unterstützung:
mkdir ~/local-llm && cd ~/local-llm
python3.12 -m venv venv
source venv/bin/activate
pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu126
python3 -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"Der letzte Befehl muss True RTX 5090 ausgeben. Erscheint stattdessen False, stimmt entweder die CUDA-Version im PyTorch-Wheel nicht mit dem installierten Toolkit überein, oder der Treiber wurde nicht korrekt geladen. Ein häufiger Stolperstein: Wird die virtuelle Umgebung nicht mit source venv/bin/activate aktiviert, installiert pip die Pakete versehentlich systemweit, was spätere Versionskonflikte mit anderen Projekten verursacht.
Schritt 4: llama.cpp kompilieren und mit CUDA testen
llama.cpp ist der schlankeste Weg, GGUF-quantisierte Modelle direkt auf der GPU laufen zu lassen, ganz ohne Python-Overhead bei der eigentlichen Inferenz. Wichtig beim Kompilieren: Die RTX 5090 basiert auf der Blackwell-Architektur mit Compute Capability 12.0 (sm_120), nicht auf der Hopper-Architektur von Rechenzentrumskarten wie dem H100 (Compute Capability 9.0). Wer die falsche Architektur angibt, baut zwar erfolgreich, verschenkt aber Performance oder bekommt Laufzeitfehler. Klone das Repository und baue es mit der korrekten Architektur:
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120
cmake --build build --config Release -j$(nproc)Der Build dauert je nach CPU-Kernzahl zwischen 3 und 10 Minuten. Läuft er durch, endet die Ausgabe mit einer Zeile wie [100%] Built target llama-cli, und die fertige Binärdatei liegt unter build/bin/llama-cli. Falls du zusätzlich eine ältere Karte im selben Rechner betreibst, etwa eine RTX 4090 (Compute Capability 8.9), kannst du beide Architekturen gleichzeitig einkompilieren, indem du den Wert als Liste übergibst: -DCMAKE_CUDA_ARCHITECTURES=”89;120″.
Schritt 5: Ein Modell herunterladen und quantisieren
Nvidia empfiehlt in der eigenen Local-AI-Dokumentation, das Modell nach dem verfügbaren VRAM auszuwählen: Für llama.cpp-Setups sind Q4_K_M-quantisierte GGUF-Checkpoints der beste Kompromiss aus Geschwindigkeit und Qualität, während vLLM- oder PyTorch-Nutzer eher zu NVFP4 greifen sollten. GGUF ist dabei ein einzelnes, in sich geschlossenes Dateiformat, das Gewichte, Tokenizer und Metadaten zusammenfasst, im Gegensatz zum verbreiteteren safetensors-Format, das meist mehrere Dateien plus eine separate Konfiguration mitbringt. Für den schnellen lokalen Einstieg mit llama.cpp oder Ollama ist GGUF deshalb praktischer, für produktive vLLM-Deployments ist safetensors mit passender Quantisierungs-Konfiguration üblicher. Lade ein 8B-Modell als Einstieg:
pip install huggingface_hub
huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
--local-dir ~/local-llm/modelsDie Q4_K_M-Datei eines 8B-Modells landet bei etwa 4,7 GB, gut geeignet auch für kleinere Karten mit 8 GB VRAM. Auf der RTX 5090 mit 32 GB Spielraum kannst du direkt zu größeren Modellen wie einem 27B- oder 32B-Checkpoint wechseln, solange du bei Q4-Quantisierung bleibst. Die folgende Tabelle zeigt eine grobe Einstiegsauswahl nach VRAM-Klasse:
| VRAM verfügbar | Empfohlene Modellgröße | Quantisierung |
|---|---|---|
| 8 GB | bis 8B | Q4_K_M |
| 12–16 GB | bis 14B | Q4_K_M |
| 24 GB | bis 27B | Q4_K_M |
| 32 GB (RTX 5090) | bis 32B, MoE-Modelle bis ca. 35B | Q4_K_M oder NVFP4 |
Schritt 6: Ollama installieren und erstes Modell laden
Für den schnellen Einstieg ohne manuelles Kompilieren eignet sich Ollama. Es bringt einen eigenen Model-Server mit und lädt Quantisierungen automatisch nach:
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:32b
ollama run qwen2.5:32b "Erkläre in zwei Sätzen, was Quantisierung bei LLMs bedeutet."Beim ersten Start lädt Ollama das Modell herunter und zeigt einen Fortschrittsbalken, bevor die Antwort erscheint:
pulling manifest
pulling 8934d96d3f08: 100% ▕████████████████▏ 19 GB
pulling 8c17c2ebb0ea: 100% ▕████████████████▏ 7.0 KB
verifying sha256 digest
writing manifest
successEin 32B-Modell in Q4-Quantisierung benötigt laut mehreren Local-AI-Guides rund 24 GB VRAM, was auf der RTX 5090 komfortabel Platz für den Kontextpuffer lässt. Mit ollama list siehst du jederzeit, welche Modelle lokal vorliegen, und mit ollama rm gibst du Speicherplatz wieder frei, wenn du ein Modell nicht mehr brauchst. Die Modellbibliothek von Ollama fasst gängige Modellfamilien unter einheitlichen Tags zusammen, etwa qwen2.5:32b oder llama3.1:8b, sodass du beim Wechsel zwischen Modellen nicht jedes Mal Download-Links und Dateinamen von Hugging Face nachschlagen musst.
Schritt 7: Open WebUI als Chat-Oberfläche verbinden
Ein Terminal-Chat ist für den Alltag unpraktisch. Open WebUI liefert eine browserbasierte Oberfläche, ähnlich einem gehosteten Chatbot, nur komplett lokal:
docker run -d --network=host \
-v open-webui:/app/backend/data \
--name open-webui \
--restart always \
ghcr.io/open-webui/open-webui:mainÖffne danach http://localhost:8080 im Browser, lege einen lokalen Account an und wähle dein Ollama-Modell aus der Dropdown-Liste. Die Oberfläche erkennt laufende Ollama-Instanzen automatisch über den Standardport 11434. Der erste angelegte Account erhält automatisch Administratorrechte, spätere Accounts kannst du in den Einstellungen auf reine Nutzerrechte beschränken, was für ein Team-Setup mit mehreren Kolleginnen und Kollegen sinnvoll ist. Open WebUI speichert Chat-Verläufe standardmäßig in der Docker-Volume open-webui-data, sodass sie einen Neustart des Containers überstehen.
Schritt 8: vLLM für produktionsreife Inferenz einrichten
Sobald du Anfragen mehrerer Nutzer gleichzeitig bedienen willst, etwa für ein internes Team-Tool, lohnt sich der Wechsel zu vLLM. Es nutzt kontinuierliches Batching und schöpft die GPU deutlich besser aus als einzelne Ollama-Anfragen, weil eingehende Requests nicht nacheinander, sondern gebündelt in einem gemeinsamen Rechenschritt verarbeitet werden. Das ist der entscheidende Unterschied zu Ollama, das für den Ein-Personen-Betrieb konzipiert wurde und bei mehreren gleichzeitigen Anfragen spürbar in die Warteschlange gerät. Die RTX 5090 zählt laut Nvidias FP8-Übersicht neben H100, H200, B200 und B100 zu den Karten mit dedizierten FP8-Tensor-Cores, was vLLM direkt nutzen kann:
docker run --gpus all --ipc=host -p 8000:8000 \
-v ~/local-llm/models:/models \
vllm/vllm-openai:latest \
--model Qwen/Qwen2.5-32B-Instruct \
--quantization fp8 \
--max-model-len 8192Nach dem Start beantwortet der Server OpenAI-kompatible Requests auf Port 8000, sodass bestehende Tools und Skripte ohne Codeänderung umschwenken können. Ein erfolgreicher Start endet im Log mit einer Zeile wie Uvicorn running on http://0.0.0.0:8000, davor meldet vLLM die geladene Modellgröße und den reservierten VRAM-Anteil. Details zu FP8-Quantisierung, kontinuierlichem Batching und Multi-GPU-Setups liefert die vLLM-Produktionsanleitung von Spheron.
Vollständiges Projekt: Ollama und Open WebUI per docker-compose
Für den täglichen Gebrauch lohnt sich ein reproduzierbares Setup, das du mit einem einzigen Befehl startest und stoppst. Die folgende docker-compose.yml kombiniert Ollama und Open WebUI zu einem lauffähigen Gesamtprojekt, inklusive GPU-Zugriff und persistenten Datenverzeichnissen:
services:
ollama:
image: ollama/ollama:latest
container_name: ollama
restart: unless-stopped
ports:
- "11434:11434"
volumes:
- ollama-data:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "8080:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- open-webui-data:/app/backend/data
depends_on:
- ollama
volumes:
ollama-data:
open-webui-data:Speichere die Datei als docker-compose.yml in einem eigenen Projektordner und starte den Stack mit docker compose up -d. Nach rund 20 Sekunden ist Open WebUI unter http://localhost:8080 erreichbar, während Ollama im Hintergrund auf Port 11434 lauscht. Modelle lädst du weiterhin per docker exec ollama ollama pull qwen2.5:32b direkt in den laufenden Container. Damit hast du ein komplettes, versioniertes Setup, das sich auf jedem anderen Rechner mit RTX-5090-Klasse-GPU identisch reproduzieren lässt.
Für den Wechsel zu vLLM ergänzt du die Datei um einen dritten Service-Block nach demselben Muster wie oben, mit dem vLLM-Image, den gewünschten Modellparametern und einem eigenen Port. Da alle drei Dienste im selben Compose-Projekt laufen, kannst du wahlweise Ollama für schnelle Einzeltests und vLLM für den eigentlichen Team-Betrieb parallel bereithalten, ohne zwei getrennte Umgebungen pflegen zu müssen.
Schritt 9: Benchmarking – Tokens pro Sekunde richtig messen
Ein Benchmark ist nur aussagekräftig, wenn Kontextlänge, Quantisierung und Prompt-Länge dokumentiert sind. llama.cpp bringt dafür ein eigenes Tool mit:
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128Eine typische Ausgabe für ein 8B-Modell in Q4_K_M auf der RTX 5090 sieht so aus:
| Test | Tokens/Sekunde | Bemerkung |
|---|---|---|
| pp512 (Prompt-Verarbeitung) | ~4.200 t/s | Prefill, stark parallelisiert |
| tg128 (Text-Generierung) | ~213 t/s | Sequenziell, VRAM-Bandbreite entscheidet |
Wichtig bei der Interpretation: pp512 misst die Prompt-Verarbeitung (Prefill), bei der alle Eingabe-Tokens parallel verarbeitet werden, während tg128 die eigentliche Textgenerierung (Decode) misst, bei der jedes Token einzeln und damit deutlich langsamer erzeugt wird. Für den gefühlten Chat-Speed zählt fast ausschließlich der zweite Wert. Öffentliche Community-Benchmarks aus dem r/LocalLLaMA-Umfeld liefern für weitere Modellgrößen auf der RTX 5090 folgende Richtwerte:
| Modell | Quantisierung | Tokens/Sekunde (Decode) |
|---|---|---|
| Llama 3.1 8B | Q4_K_M | ~213 t/s |
| Qwen3-30B (MoE) | Q4 | ~38 t/s |
| 27B-Klasse-Modell | Q4 | ~45 t/s |
| 35B-MoE-Modell (~22 GB VRAM) | Q4 | ~118 t/s |
| Llama 3.3 70B | Q4 | ~14 t/s |
Der große Sprung bei MoE-Modellen (Mixture of Experts) erklärt sich dadurch, dass pro Token nur ein Bruchteil der Gesamtparameter aktiv gerechnet wird, während dichte Modelle wie Llama 3.3 70B bei jedem Token das komplette Netz durchlaufen. Der eigentliche Flaschenhals bei der Textgenerierung ist fast nie die reine Rechenleistung der GPU, sondern die Speicherbandbreite: Bei jedem einzelnen Token müssen sämtliche aktiven Modellgewichte einmal aus dem VRAM gelesen werden. Genau deshalb profitieren MoE-Architekturen mit wenigen aktiven Parametern pro Token so stark von der 1.792 GB/s Bandbreite der RTX 5090.
Die Prompt-Länge wirkt sich vor allem auf die Prefill-Phase aus, kaum auf die Tokens-pro-Sekunde-Rate der Textgenerierung selbst. Ein zehnmal längerer Prompt verlängert also in erster Linie die Wartezeit, bis die erste Antwortsilbe erscheint, nicht die Geschwindigkeit, mit der der Rest der Antwort danach folgt. Wer die Zeit bis zur ersten Ausgabe (Time to First Token) separat messen will, sollte pp512 und tg128 deshalb immer getrennt betrachten, statt nur einen kombinierten Durchschnittswert zu notieren.
Ein aktuelles Beispiel für diesen Trend ist Nemotron 3.5 Lightning, ein MoE-Modell mit rund 30 Milliarden Gesamt- und nur etwa 3 Milliarden aktiven Parametern pro Token. Auf vergleichbarer GPU-Klasse erreichten Tests im August 2026 damit 71 bis 73 Tokens pro Sekunde bei Fließtext und 84 bis 87 Tokens pro Sekunde bei strukturierten Ausgaben wie JSON, deutlich mehr als ein dichtes Modell gleicher Gesamtgröße schaffen würde.
Schritt 10: VRAM optimieren und Kontextlänge steuern
Der VRAM-Verbrauch hängt von drei Stellschrauben ab: Modellgröße, Quantisierung und Kontextlänge. Die folgende Tabelle zeigt Richtwerte für die Modellgewichte allein, ohne Kontextpuffer:
| Modellgröße | FP16 | INT8 | INT4 / Q4 |
|---|---|---|---|
| 8B Parameter | ~16 GB | ~8 GB | ~4,7 GB |
| 27B Parameter | ~54 GB | ~27 GB | ~15 GB |
| 32B Parameter | ~64 GB | ~32 GB | ~18 GB |
| 70B Parameter | ~140 GB | ~70 GB | ~40 GB |
Für die RTX 5090 mit 32 GB heißt das in der Praxis: Ein 32B-Modell in Q4 passt komplett ins VRAM und lässt noch Platz für einen Kontext von mehreren tausend Tokens. Ein 70B-Modell in Q4 sprengt die Karte knapp, weshalb hier entweder Offloading einzelner Layer auf die CPU nötig wird oder du auf ein kleineres Modell mit ähnlicher Qualität ausweichst. Reduziere bei Speicherdruck zuerst die Kontextlänge (Parameter –max-model-len bei vLLM beziehungsweise –ctx-size bei llama.cpp), bevor du die Quantisierung weiter absenkst, denn eine zu aggressive Quantisierung kostet spürbar an Antwortqualität.
Ein praktisches Beispiel: Ein 32B-Modell in Q4 belegt rund 18 GB für die reinen Gewichte. Bleiben 14 GB für den Kontext übrig, reicht das bei llama.cpp für einen Kontext von deutlich über 32.000 Tokens, abhängig vom Key-Value-Cache-Format. Willst du zusätzlich mehrere Anfragen parallel bedienen, etwa über vLLM, sinkt der pro Anfrage verfügbare Kontext entsprechend, weil sich alle aktiven Sessions den gleichen VRAM-Pool teilen.
Monitoring und Automatisierung mit nvidia-smi
Behalte VRAM-Auslastung, Temperatur und Takt während längerer Sessions im Blick. Ein einfacher Dauer-Monitor reicht für den Anfang:
watch -n 1 nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --format=csvFür ein automatisiertes Logging über mehrere Stunden schreibst du die Werte per Cronjob in eine CSV-Datei. Ein einfaches Skript dafür:
#!/bin/bash
LOGFILE=~/local-llm/gpu-log.csv
echo "timestamp,util_pct,mem_used_mib,temp_c,power_w" >> "$LOGFILE"
while true; do
ROW=$(nvidia-smi --query-gpu=utilization.gpu,memory.used,temperature.gpu,power.draw --format=csv,noheader,nounits)
echo "$(date +%s),$ROW" >> "$LOGFILE"
sleep 30
doneTrage das Skript als systemd-Service oder einfachen Hintergrundprozess ein und lass es während eines Benchmarks mitlaufen. So erkennst du im Nachhinein, ob die Karte je an ihr Power-Limit (Standard 575 Watt bei der RTX 5090 FE) gestoßen ist, was die Tokens-pro-Sekunde-Zahlen gegen Ende einer langen Session drücken kann. Details zur Methodik professioneller Inferenz-Benchmarks liefert auch Nvidias eigener TensorRT-LLM-Benchmarking-Leitfaden.
Ein Wert für utilization.gpu nahe 100 Prozent über die gesamte Session ist bei Textgenerierung eher untypisch, da die GPU zwischen einzelnen Tokens kurz auf Speicherzugriffe wartet. Liegt der Wert dauerhaft deutlich niedriger, etwa unter 60 Prozent, während gleichzeitig die CPU-Auslastung hoch ist, deutet das auf einen Flaschenhals außerhalb der GPU hin, etwa bei der Tokenisierung oder beim Daten-Preprocessing.
Die 5 häufigsten Fehler beim RTX-5090-KI-Setup
Die meisten Probleme in diesem Setup entstehen nicht durch die Hardware selbst, sondern durch kleine Konfigurationsfehler, die sich erst bei der Inferenz bemerkbar machen. Die folgenden fünf Punkte tauchen in Community-Foren und GitHub-Issues am häufigsten auf.
- Falsche CUDA-Architektur beim Kompilieren: Wer CMAKE_CUDA_ARCHITECTURES auf einen alten Wert wie 89 (Ada Lovelace) stehen lässt, verschenkt Blackwell-spezifische Optimierungen. Für die RTX 5090 gehört 120 in den Build-Befehl, da die Karte Compute Capability 12.0 hat.
- Modell und Quantisierung nicht zusammen dokumentiert: Ein Benchmark ohne Angabe der Quantisierung ist wertlos, da Q4_K_M und FP8 auf derselben Karte völlig unterschiedliche Tokens-pro-Sekunde-Werte liefern. Notiere bei jedem Test Modellname, Quantisierung und Kontextlänge zusammen.
- Kontextlänge zu hoch angesetzt: Ein auf 128.000 Tokens gesetzter Kontext frisst VRAM, selbst wenn der tatsächliche Prompt nur 500 Tokens lang ist. Setze den Wert realistisch für deinen Use Case, statt vorsorglich das Maximum zu reservieren.
- Kein Swap oder Offloading bei knappem VRAM: Stürzt der Prozess bei einem großen Modell einfach ab, statt eine klare Fehlermeldung auszugeben, fehlt meist eine Offloading-Konfiguration für CPU-RAM. Sowohl llama.cpp als auch vLLM bieten Parameter, um einzelne Layer auf die CPU auszulagern.
- Veraltete Treiber neben neuem CUDA-Toolkit: Ein CUDA-12.6-Toolkit mit einem Treiber unterhalb Version 560 führt zu kryptischen Linker-Fehlern beim Kompilieren, die nichts mit dem eigentlichen Code zu tun haben. Prüfe die Kompatibilitätsmatrix in der CUDA-Dokumentation, bevor du ein Ticket im Bugtracker eines Projekts aufmachst.
Troubleshooting: 8 Probleme und ihre Lösungen
Die folgende Tabelle deckt die Probleme ab, die in Foren und GitHub-Issues rund um RTX-50-Karten und lokale LLM-Frameworks am häufigsten auftauchen. Grenze bei jedem Fehler zuerst ein, ob das Problem beim Treiber, beim Build oder erst bei der eigentlichen Inferenz auftritt, das spart beim Debuggen die meiste Zeit.
| Problem | Ursache | Lösung |
|---|---|---|
| nvidia-smi zeigt “No devices found” | Secure Boot blockiert unsignierte Treiber-Module | Secure Boot im BIOS deaktivieren oder Treiber-Signatur einrichten |
| CUDA out of memory beim Laden | Modell plus Kontext übersteigt 32 GB VRAM | Kleinere Quantisierung wählen oder Kontextlänge reduzieren |
| llama-bench bricht mit Segfault ab | Falsche CUDA-Architektur im Build | Mit -DCMAKE_CUDA_ARCHITECTURES=120 neu kompilieren |
| Ollama lädt Modell extrem langsam | Download über gedrosselte Verbindung oder volle Festplatte | Speicherplatz prüfen, Download-Pfad auf schnelle SSD legen |
| Open WebUI findet Ollama nicht | Docker-Netzwerkmodus stimmt nicht mit Ollama-Port überein | Container mit –network=host starten |
| vLLM startet nicht, meldet Quantisierungsfehler | Modell-Checkpoint unterstützt gewähltes Quant-Format nicht | Offiziell quantisierte Checkpoints von Hugging Face nutzen |
| Tokens/Sekunde sinken nach mehreren Minuten | GPU erreicht Temperatur- oder Power-Limit (Throttling) | Gehäuselüftung verbessern, Power-Limit in nvidia-smi anpassen |
| PyTorch erkennt GPU nicht (CUDA available: False) | PyTorch-Wheel mit falscher CUDA-Version installiert | Wheel exakt zur installierten CUDA-Toolkit-Version wählen |
Bleibt ein Fehler bestehen, obwohl die Tabelle keine passende Zeile liefert, lohnt sich ein Blick in die Logs des jeweiligen Frameworks statt in die generische Fehlermeldung der Shell. Sowohl llama.cpp als auch vLLM geben bei erhöhtem Log-Level deutlich präzisere Hinweise aus, etwa über die Umgebungsvariable VLLM_LOGGING_LEVEL=DEBUG.
Fortgeschrittene Tipps für Power-User
Wer das Grundsetup stehen hat, kann an mehreren Stellen weiter optimieren. Die folgenden vier Ansätze bringen in der Praxis den größten Effekt, ohne dass du dafür zusätzliche Hardware kaufen musst.
Spekulatives Decodieren
Ein kleines Draft-Modell schlägt neben dem Hauptmodell mehrere Tokens auf einmal vor, das große Modell prüft die Vorschläge nur noch, statt jedes Token einzeln zu berechnen. Das beschleunigt die Textgenerierung oft um 20 bis 40 Prozent, ohne die Ausgabequalität zu verändern, solange Draft- und Hauptmodell aus derselben Modellfamilie stammen.
Tensor-Parallelismus bei mehreren GPUs
Wer zwei oder mehr Karten im selben System betreibt, kann ein Modell über mehrere GPUs aufteilen. Sowohl vLLM als auch TensorRT-LLM unterstützen Tensor-Parallelismus über einen einzigen Startparameter, was besonders für Modelle jenseits von 32B interessant wird, die auf einer einzelnen RTX 5090 keinen Platz mehr finden.
Modell-Routing für gemischte Lasten
Für produktive Deployments mit wechselnder Last bietet sich ein Modell-Router an, der einfache Anfragen an ein 8B-Modell und komplexere Anfragen an ein 32B-Modell weiterleitet, statt immer das größte Modell vorzuhalten. Das senkt die durchschnittliche Latenz spürbar, weil die meisten Alltagsanfragen kein 32B-Modell benötigen.
Wer NVFP4 statt klassischem INT4 nutzt, sollte die Genauigkeit vor dem produktiven Einsatz an eigenen Testfragen prüfen, da die Qualitätseinbußen je nach Modellarchitektur unterschiedlich ausfallen. Ein kurzer manueller Vergleich mit 10 bis 20 typischen Prompts aus dem eigenen Anwendungsfall zeigt meist schon, ob die Quantisierung für den jeweiligen Zweck ausreicht.
Sicherheit beim Betrieb: Netzwerk, Modelle und API-Zugriff
Ein lokales LLM-Setup bringt eigene Angriffsflächen mit, die im reinen Gaming-Kontext keine Rolle spielen. Sobald ein Inferenz-Server läuft, ist er technisch ein Netzwerkdienst wie jeder andere, mit denselben Grundregeln für Exposition und Zugriffskontrolle. Vier Punkte solltest du vor dem produktiven Einsatz klären.
- Ports nicht ungeschützt exponieren: Ollama lauscht standardmäßig auf Port 11434, vLLM auf Port 8000. Bindest du diese Ports versehentlich an alle Netzwerkschnittstellen statt an localhost, kann jeder im gleichen Netzwerk Anfragen stellen und im schlimmsten Fall dein System als kostenlose Inferenz-Ressource missbrauchen. Nutze eine Firewall-Regel oder binde die Dienste explizit an 127.0.0.1, wenn kein externer Zugriff nötig ist.
- Modell-Herkunft prüfen: GGUF-Dateien sind Binärformate, die Fremdcode über bösartig präparierte Metadaten oder Tokenizer-Konfigurationen einschleusen könnten. Lade Modelle nur von verifizierten Hugging-Face-Repositories bekannter Anbieter und prüfe, wo möglich, den SHA256-Hash gegen die offizielle Modellseite.
- API-Schlüssel für vLLM setzen: Der OpenAI-kompatible Server von vLLM akzeptiert ohne zusätzliche Konfiguration jede Anfrage. Für ein Team-Setup solltest du über den Parameter –api-key einen eigenen Schlüssel vergeben, statt den Endpunkt offen im lokalen Netz stehen zu lassen.
- Open WebUI nicht ohne Authentifizierung ins Internet stellen: Willst du von unterwegs auf deine Chat-Oberfläche zugreifen, nutze einen VPN-Tunnel oder einen Reverse Proxy mit eigener Authentifizierung, statt Port 8080 direkt per Portweiterleitung im Router freizugeben. Ein offener Chat-Endpunkt mit Zugriff auf dein lokales Modell ist ein einfaches Ziel für automatisierte Scans.
Diese drei Punkte kosten in der Einrichtung wenige Minuten, verhindern aber genau die Art von Fehlkonfiguration, die in Firmennetzen später als offener Dienst in einem Scan auffällt.
Kostenanalyse: RTX-5090-Preise und der Arbeitsspeicher-Engpass in Österreich
Die Anschaffungskosten für ein lokales KI-Setup mit RTX 5090 gehen 2026 über den reinen Kartenpreis hinaus. Wie shattered.io in der Preisanalyse zur RTX 5090 in Österreich zeigt, liegt die Karte hierzulande bei rund 5.119 Euro statt der ursprünglichen UVP von 2.099 Euro. Der Grund ist die anhaltende GDDR7-Knappheit, die auch bei Nachbestellungen einzelner Modelle für spürbare Wartezeiten sorgt. Gleichzeitig macht der DDR5-Engpass den Rest des Systems teurer, sodass ein Build 2026 an praktisch jeder Komponente über den Preisen des Vorjahres liegt, nicht nur bei der Grafikkarte.
| Komponente | Preis vor 12 Monaten | Preis August 2026 |
|---|---|---|
| RTX 5090 (UVP, global) | 1.999 US-Dollar | 1.999 US-Dollar UVP, Straßenpreis deutlich höher |
| RTX 5090 (Straßenpreis Österreich) | rund 2.099 Euro | rund 5.119 Euro |
| 64 GB DDR5-5600-Kit (global, laut Tom’s Hardware) | ~191 US-Dollar | ~1.118 US-Dollar |
| 32 GB DDR5-6000-Kit (global, laut Tom’s Hardware) | ~108 US-Dollar | ~572 US-Dollar |
Wer die Anschaffung plant, sollte deshalb den kompletten Build kalkulieren, nicht nur die GPU. Ein System mit 64 GB RAM kostet allein für den Arbeitsspeicher inzwischen ein Vielfaches dessen, was vor einem Jahr üblich war. Samsung selbst warnt vor anhaltenden Lieferengpässen, da die Nachfrage aus dem KI-Rechenzentrumsbereich Kapazitäten bindet, die sonst in Consumer-RAM fließen würden. Wer schon eine ältere RTX 4090 mit 24 GB besitzt, fährt für kleinere Modelle bis 27B in Q4 oft günstiger, indem er die vorhandene Karte behält und stattdessen in mehr System-RAM investiert, statt sofort auf die RTX 5090 umzusteigen.
Rechnet man GPU, 64 GB DDR5 und ein passendes 1200-Watt-Netzteil zusammen, landet ein neuer Build in Österreich aktuell deutlich über 6.000 Euro, wenn die GPU zum Straßenpreis statt zur UVP gekauft wird. Zum Vergleich: Ein Jahr zuvor lag ein vergleichbarer Build inklusive RAM eher bei rund 2.500 bis 2.800 Euro. Wer nicht auf eine sofortige Anschaffung angewiesen ist, sollte die Preisentwicklung bei GDDR7 und DDR5 weiter beobachten, ein kurzfristiger Rückgang ist nach aktuellem Stand der Berichterstattung aber nicht in Sicht.
Zusammenfassung: Vom Treiber zum produktiven lokalen LLM
Zehn Schritte trennen einen frisch eingebauten Grafikkartenkarton von einem laufenden, lokal gehosteten Sprachmodell: Treiber und CUDA-Toolkit installieren, eine Python-Umgebung aufsetzen, llama.cpp mit der richtigen Architektur kompilieren, ein Modell in passender Quantisierung laden, mit Ollama den Einstieg vereinfachen, eine Chat-Oberfläche über Open WebUI anbinden, mit vLLM auf Mehrnutzer-Betrieb skalieren, den Durchsatz sauber benchmarken, VRAM und Kontextlänge aufeinander abstimmen und den Betrieb über nvidia-smi im Blick behalten. Keiner dieser Schritte ist für sich kompliziert, in Summe ersetzen sie aber genau das Wissen, das sonst nur bei gehosteten KI-Diensten im Hintergrund abläuft.
Die RTX 5090 deckt damit einen großen Teil dessen ab, was bisher Rechenzentrums-GPUs wie H100 oder H200 vorbehalten war, zumindest für Modelle bis in den 32B- bis 35B-Bereich. Wer regelmäßig größere Modelle braucht, findet in Nvidias eigenem Vergleich zwischen Consumer- und Rechenzentrumskarten eine Einordnung, wann sich der Sprung tatsächlich lohnt. Für die meisten Einzelentwickler und kleinen Teams, die Chat-Assistenten, Zusammenfassungen oder Codehilfen lokal betreiben wollen, reicht eine einzelne RTX 5090 nach diesem Setup vollkommen aus.
Häufig gestellte Fragen
Reicht die RTX 5090 für ein 70B-Modell?
Nur knapp und nur in Q4-Quantisierung mit stark reduziertem Kontext. Ein 70B-Modell braucht in Q4 rund 40 GB, mehr als die 32 GB VRAM der Karte. In der Praxis funktioniert das nur mit teilweisem CPU-Offloading, was die Geschwindigkeit deutlich senkt, wie die rund 14 Tokens pro Sekunde für Llama 3.3 70B in Community-Benchmarks zeigen. Für 70B-Modelle in voller Geschwindigkeit brauchst du entweder zwei RTX-5090-Karten im Tensor-Parallel-Betrieb oder eine Rechenzentrumskarte mit entsprechend mehr VRAM.
Was ist der Unterschied zwischen Ollama und vLLM?
Ollama ist auf einfache Bedienung für Einzelnutzer ausgelegt und eignet sich für den lokalen Chat oder Entwicklungstests, mit wenig Konfigurationsaufwand und automatischem Modell-Management. vLLM ist für parallele Anfragen mehrerer Nutzer optimiert und bringt kontinuierliches Batching mit, was bei Teamnutzung deutlich mehr Durchsatz liefert, allerdings mit etwas mehr Einrichtungsaufwand und einer expliziten Konfiguration von Modell, Quantisierung und Kontextlänge beim Start.
Brauche ich zwingend Linux für dieses Setup?
Nein. Windows 11 mit WSL2 funktioniert für alle in diesem Artikel gezeigten Schritte, allerdings mit leicht höherem Overhead bei Docker-Containern und gelegentlichen Eigenheiten bei der GPU-Passthrough-Konfiguration. Für produktive Dauerlast, etwa einen Server, der rund um die Uhr Anfragen eines Teams bedient, empfiehlt sich trotzdem natives Linux wegen der stabileren Treiber-Integration und des geringeren Ressourcen-Overheads.
Wie viel Strom verbraucht die RTX 5090 im Dauerbetrieb?
Das Power-Limit der Founders Edition liegt bei 575 Watt. Bei durchgehender Inferenz solltest du das in der Stromrechnung einkalkulieren und für ausreichende Gehäusekühlung sorgen, damit kein thermisches Throttling die Tokens-pro-Sekunde-Rate senkt.
Welche Quantisierung sollte ich als Einstieg wählen?
Für llama.cpp ist Q4_K_M laut Nvidias eigener Local-AI-Dokumentation der beste Startpunkt für Geschwindigkeit und Qualität. Nutzt du vLLM oder PyTorch direkt, ist NVFP4 die empfohlene Alternative auf Blackwell-Karten wie der RTX 5090. Teste bei kritischen Anwendungen trotzdem immer beide Varianten gegen deinen eigenen Prompt-Satz.
Lohnt sich eine Cloud-GPU statt der eigenen RTX 5090?
Für gelegentliche Tests ja, für Dauerbetrieb meist nicht. Bei den aktuellen Straßenpreisen von rund 5.119 Euro in Österreich amortisiert sich die Karte erst nach vielen Monaten, dafür bleiben Daten und Modelle vollständig lokal, ein Argument, das für Firmen mit Datenschutzanforderungen oft den Ausschlag gibt. Wer nur gelegentlich ein großes Modell braucht, etwa für einzelne Analyseprojekte, fährt mit einer gemieteten Cloud-GPU für die Dauer des Projekts oft günstiger als mit einer Dauerinvestition in eigene Hardware.
Kann ich mehrere Modelle gleichzeitig laden?
Ja, solange die Summe der VRAM-Anforderungen unter 32 GB bleibt. Zwei 8B-Modelle in Q4 lassen sich problemlos parallel laden, etwa um Anfragen nach Komplexität aufzuteilen, ein kleines Modell für einfache Zusammenfassungen und ein größeres für komplexere Analyseaufgaben. Ollama verwaltet mehrere geladene Modelle automatisch und entlädt selten genutzte Modelle nach einer konfigurierbaren Leerlaufzeit wieder aus dem VRAM.
Was tue ich, wenn die Antwortqualität nach der Quantisierung spürbar schlechter wird?
Wechsle von Q4 auf Q5_K_M oder Q6_K, die etwas mehr VRAM benötigen, dafür aber näher an der FP16-Qualität liegen. Bei der RTX 5090 ist dafür bei den meisten Modellen bis 27B noch genug Spielraum vorhanden.
Wird die RTX 5090 unter Dauerlast sehr laut?
Das hängt stark vom Kühlerdesign des jeweiligen Herstellers ab. Bei Inferenz-Workloads bleibt die Auslastung oft konstanter als beim Gaming mit schwankenden Frameraten, was viele Lüftersteuerungen in einen gleichmäßigen, aber dauerhaften Betriebspunkt zwingt. Wer die Karte in einem Büro oder Wohnraum betreibt, sollte ein Gehäuse mit gutem Luftstrom und eine Lüfterkurve wählen, die nicht ständig zwischen niedrigen und hohen Drehzahlen wechselt.
Kann ich mit der RTX 5090 auch Modelle fine-tunen, nicht nur Inferenz fahren?
Für kleine bis mittlere Modelle mit parametereffizienten Verfahren wie LoRA oder QLoRA ist das möglich, da hier nur ein kleiner Teil der Gewichte trainiert wird und der VRAM-Bedarf entsprechend niedriger bleibt als bei einem vollständigen Training. Ein komplettes Fine-Tuning aller Parameter eines 32B-Modells sprengt dagegen selbst die 32 GB der RTX 5090 deutlich, da Training zusätzlich zu den Gewichten noch Optimizer-Zustände und Gradienten im Speicher hält. Für dieses Szenario bleibt eine gemietete Rechenzentrums-GPU meist die praktikablere Wahl.
Related Coverage
- RTX 5090 kostet in Österreich 5.119€ statt 2.099€ MSRP [2026]
- RTX 5090 einrichten: 12 Schritte zu 378 FPS [2026]
- GPU Benchmark: 12 Schritte zu mehr FPS, 45 Min [2026]
- Nvidia-Treiber installieren: 12 Schritte, 30 Min [2026]
- Nvidia B200 vs H200: Österreichs 1.088-GPU-Cluster [2026]
- Weitere Hardware-Artikel auf shattered.io
