Lokale LLMs betreiben: Workstation oder GPU-Server?
Lokale LLMs betreiben wird für Unternehmen zunehmend zur strategischen Notwendigkeit. Unter dem Druck von Datenschutzanforderungen, niedrigen Latenzzielen und langfristiger Kostenoptimierung entscheiden sich CTOs und IT-Direktoren immer häufiger dafür, große Sprachmodelle auf der eigenen Infrastruktur zu betreiben statt auf Cloud-APIs zu setzen. Die zentrale Frage dabei: Workstation oder GPU-Server?
Was braucht man für den Betrieb lokaler LLMs?
Die wichtigste Ressource für lokale LLM-Inferenz ist VRAM. Die Modellgewichte werden in den GPU-Speicher geladen; ohne ausreichend VRAM lädt das Modell entweder nicht oder fällt auf CPU-Offloading zurück, wodurch die Inferenz praktisch unbrauchbar langsam wird.
Große Sprachmodelle auf der eigenen Infrastruktur zu betreiben war bis vor wenigen Jahren ausschließlich großen Forschungslaboren vorbehalten. Heute ermöglichen Consumer-GPUs und Open-Source-Werkzeuge wie Ollama es Enterprise-IT-Teams unkompliziert. Dennoch ist ein korrektes Verständnis der Hardware-Anforderungen für ein erfolgreiches Deployment unerlässlich.
Ein LLM benötigt, dass alle Gewichte — oder eine quantisierte Teilmenge — in den VRAM der GPU geladen werden. Ist dies nicht möglich, weichen Frameworks wie PyTorch oder llama.cpp auf CPU-Offloading aus, wodurch die Inferenzgeschwindigkeit auf Sekunden pro Token sinkt — für interaktive Workloads praktisch unbrauchbar. System-RAM und CPU-Geschwindigkeit sind für Preprocessing und I/O relevant, doch der eigentliche Flaschenhals ist stets der VRAM.
Auf der Speicherseite belegen Modelle auf dem Dateisystem zwischen 4 GB und über 1,3 TB. Schnelle NVMe-SSDs verkürzen die Modell-Ladezeit erheblich; für große Modelle wird PCIe 5.0 NVMe empfohlen. Die Netzwerkbandbreite spielt für die lokale Inferenz nach dem initialen Modell-Download keine Rolle.
- VRAM: Primäre Ressource für die Modellgewichte — nicht verhandelbar
- CPU: Wichtig für Tokenisierung, Preprocessing und Systemkoordination; moderner EPYC oder Xeon empfohlen
- System-RAM: Mindestens 64 GB, 128 GB+ empfohlen für Offloading oder komplexes Kontext-Management
- NVMe-SSD: Bestimmt die Modell-Ladegeschwindigkeit; PCIe 5.0 NVMe für große Modelle empfohlen
- Netzteil und Kühlung: Dual-RTX-5090-Konfigurationen können ein Netzteil mit 1000 W+ erfordern
VRAM und Modellgröße: Welches Modell passt auf welche GPU?
Modellgröße und Quantisierungsstufe bestimmen den VRAM-Bedarf direkt. Ein 7B-Modell benötigt bei FP16 ca. 14 GB, bei Q4-Quantisierung aber nur 4–5 GB. Ein 70B-Modell erfordert selbst bei Q4 noch 35–40 GB VRAM.
Quantisierung reduziert die Präzision der Modellgewichte (z. B. von FP16 auf INT4) und senkt damit den VRAM-Bedarf dramatisch. Der Genauigkeitsverlust bei Q4 ist in der Regel minimal und für die meisten Enterprise-Anwendungsfälle akzeptabel. Q8 bietet einen ausgewogenen Kompromiss zwischen Genauigkeit und VRAM-Effizienz.
| Modellgröße | FP16 VRAM | Q8 VRAM | Q4 VRAM | Geeignete GPU (Q4) |
|---|---|---|---|---|
| 7B | ~14 GB | ~7 GB | ~4–5 GB | RTX 3090 24 GB, RTX 4080 16 GB |
| 13B | ~26 GB | ~13 GB | ~8 GB | RTX 3090 24 GB, RTX 4090 24 GB |
| 30B | ~60 GB | ~30 GB | ~17 GB | RTX 4090 24 GB (knapp), RTX 5090 32 GB |
| 70B | ~140 GB | ~70 GB | ~35–40 GB | RTX 5090 32 GB (grenzwertig), Dual RTX 5090 64 GB |
| 120B (MoE) | ~240 GB+ | ~120 GB | ~65–70 GB | RTX PRO 6000 Blackwell 96 GB, Dual A100 80 GB |
| 405B+ | ~800 GB+ | ~400 GB | ~200 GB+ | Multi-GPU-Server, A100/H100-Cluster |
Die Tabellenwerte stellen theoretische Minima dar. Der tatsächliche VRAM-Bedarf steigt mit der Kontextlänge und der KV-Cache-Größe. Bei langen Kontextfenstern (32K+ Token) sollte man mindestens 20–30 % auf die angegebenen Werte aufschlagen.
Auf dem Gebrauchtmarkt sind RTX-3090-24-GB-Karten für ca. 650–750 USD erhältlich und bieten für 7B- und 13B-Modelle ein ausgezeichnetes Preis-Leistungs-Verhältnis. Im Enterprise-Umfeld sprechen Garantie, Support und Zuverlässigkeit in der Regel für neue RTX 5090 oder Datacenter-Karten.
Lokale LLMs auf der Workstation: Einzelentwickler und kleine Teams
Eine KI-Workstation ist der ideale Einstiegspunkt für lokale LLM-Inferenz in Einzelentwickler- oder Kleinteam-Szenarien. Die RTX 5090 mit 32 GB VRAM betreibt ein 70B-Q4-Modell komfortabel; eine zweite Karte verdoppelt den VRAM auf 64 GB.
Workstation-basierte lokale LLM-Setups sind besonders beliebt für Modellentwicklung, Fine-Tuning-Experimente und Prototyping. Eine Desktop- oder Tower-Workstation kann im Büroumfeld ohne Rechenzentrumsinfrastruktur betrieben werden und bietet ein besser handhabbares Lärm- und Kühlungsprofil.
Die NVIDIA RTX 5090 mit 32 GB GDDR7-VRAM steht derzeit an der Spitze des Consumer-Segments. Sie kann ein Q4-quantisiertes 70B-Modell auf einer einzelnen Karte betreiben — Modelle wie Meta LLaMA 3.1 70B Q4 wurden in der Praxis auf dieser Konfiguration validiert. Mit zwei RTX-5090-Karten beträgt der Gesamt-VRAM 64 GB, was 70B-Modellen komfortable Reserven gibt und längere Kontextlängen ermöglicht.
Die Auswahl einer KI-Workstation erfordert die gemeinsame Bewertung von GPU-Anzahl, PCIe-Bandbreite und Kühlungsanforderungen. Weitere wichtige Faktoren sind die NVLink- oder PCIe-5.0-Unterstützung des Mainboards, ausreichende Netzteilkapazität und ECC-Speicheroptionen.
- Vorteile: Geringere Anfangsinvestition, einfache Einrichtung, bürotauglich, handhabbarer Lärmpegel
- Vorteile: Ausreichend für einen Einzelentwickler oder ein kleines Team; mit Ollama in Minuten betriebsbereit
- Einschränkungen: Begrenzte gleichzeitige Nutzer (typischerweise 1–4 aktive Sitzungen)
- Einschränkungen: Mehr als zwei GPUs in einem Tower-Gehäuse schwierig; ab 4 Karten wird ein Server-Chassis benötigt
- Einschränkungen: Für Business Continuity können USV und redundante Stromversorgung erforderlich sein
Skalierbarer LLM-Betrieb mit GPU-Server
Ein GPU-Server ist die richtige Wahl für Enterprise-LLM-Deployments, die mehrere gleichzeitige Nutzer, hohe Verfügbarkeit und Skalierbarkeit erfordern. In Kombination mit vLLM ist der Durchsatz erheblich höher als bei einer Workstation.
In einer Unternehmensumgebung muss ein LLM-Dienst möglicherweise Dutzende oder Hunderte gleichzeitiger Nutzer bedienen. In diesem Szenario reicht eine Workstation-Infrastruktur schnell nicht mehr aus; GPU-Server und hochdurchsatzfähige Inferenz-Frameworks kommen zum Einsatz. Bei der Auswahl von GPU-Server und KI-Infrastruktur müssen Durchsatz, Latenz und Speicherbandbreite gemeinsam bewertet werden.
Die RTX PRO 6000 Blackwell mit 96 GB GDDR7-ECC-VRAM ist eine professionelle GPU für Enterprise-Workloads. Sie kann 120B-Parameter-MoE-Modelle auf einer einzelnen Karte bei Q4-Quantisierung betreiben. Im Datacenter-Bereich erreichen A100-80-GB- und H100-80-GB-Karten, verbunden über NVLink, ausreichende Kapazität für Modelle mit 405B+ Parametern.
Die Prozessorarchitektur spielt bei der Auswahl der Server-Plattform ebenfalls eine entscheidende Rolle. AMD EPYC und Intel Xeon Scalable mit Mehrkanal-Speicherarchitekturen und hoher PCIe-Leitungsanzahl haben sich auf GPU-Server-Plattformen als Standard etabliert. Die Auswahl des Server-Prozessors — ein dedizierter Vergleich von Xeon, EPYC und Threadripper Pro — behandelt dies ausführlich.
| Szenario | Empfohlene Hardware | Gesch. gleichz. Nutzer | Geeignete Modellgröße |
|---|---|---|---|
| Einzelentwickler / Prototyp | RTX 5090 32 GB (Einzelkarte) | 1–2 | 7B–70B Q4 |
| Kleines Team (5–15 Nutzer) | Dual RTX 5090 64 GB | 3–8 | 70B Q4 oder 30B FP16 |
| Abteilung (15–50 Nutzer) | RTX PRO 6000 Blackwell 96 GB | 10–20 | 120B MoE Q4 |
| Enterprise (50+ Nutzer) | Multi-GPU-Server (A100/H100 80 GB x4+) | 50+ | 405B+ oder Multi-Modell |
| Hybrid (kritisch + allgemein) | On-Premise + Cloud-Burst | Flexibel | Alle Größen |
Der Software-Stack: Ollama, vLLM und LM Studio
Ollama ist der einfachste Einstieg — ein Modell wird mit einem einzigen Befehl heruntergeladen und gestartet. vLLM liefert hohen Durchsatz für gleichzeitigen Produktionsbetrieb. LM Studio ist eine GUI-Desktop-Anwendung für alle, die eine grafische Oberfläche bevorzugen.
Das Ökosystem für lokale LLMs hat sich in den vergangenen zwei Jahren bemerkenswert weiterentwickelt. Heute gibt es spezialisierte Werkzeuge für ML-Ingenieure an der Kommandozeile, Produktmanager, die GUI-Anwendungen bevorzugen, und DevOps-Ingenieure, die hochdurchsatzfähige Dienste auf Kubernetes betreiben.
| Tool | Zielgruppe | Einrichtungsaufwand | Durchsatz | API-Kompatibilität | Bestes Szenario |
|---|---|---|---|---|---|
| Ollama | Entwickler, DevOps | Sehr einfach (ein Befehl) | Mittel | OpenAI-kompatibles REST | Prototyping, Einzelnutzung, schnelle Tests |
| vLLM | ML-Ingenieur, DevOps | Mittel (Python-Umgebung) | Sehr hoch | OpenAI-kompatibles REST | Produktionsdienst, viele gleichzeitige Anfragen |
| LM Studio | Entwickler, Analyst | Sehr einfach (GUI) | Niedrig–Mittel | Begrenzte lokale API | Desktop-Nutzung, Modell-Erkundung |
| llama.cpp | Fortgeschrittener Entwickler | Mittel–Schwer | Mittel (CPU-fähig) | Basis-API | Geräte mit geringer Leistung, CPU-Inferenz |
| text-generation-webui | Forscher | Mittel | Mittel | Breite Plugin-Unterstützung | Modellvergleich, Fine-Tuning-Experimente |
Ollamas größter Vorteil ist der konfigurationsfreie Start: Der Befehl `ollama run llama3.1:70b` lädt das Modell automatisch herunter, erkennt die GPU und stellt eine REST-API bereit. Die Quantisierungsstufe wird automatisch gewählt; Nutzer können bei Bedarf aber auch explizit Q4 oder Q8 angeben.
vLLM nutzt den PagedAttention-Algorithmus, um den KV-Cache-Speicher wesentlich effizienter zu verwalten. Bei hoher gleichzeitiger Anfragelast liefert vLLM deutlich mehr Token pro Sekunde als Ollama. Für Produktionsumgebungen mit 10+ gleichzeitigen Nutzern ist vLLM die bevorzugte Wahl. Es kann per Docker, Python-Virtual-Environment oder Kubernetes-Helm-Chart deployt werden.
Datenschutz und On-Premise: Lokale LLMs unter der KVKK
Die Verarbeitung personenbezogener Daten gemäß KVKK erfordert, dass Daten nicht auf ausländische Server übertragen werden. On-Premise-LLM-Deployment erfüllt diese Anforderung direkt; Cloud-API-Aufrufe erfordern zusätzliche vertragliche und technische Schutzmaßnahmen.
Das türkische Datenschutzgesetz Nr. 6698 (KVKK) verlangt ausdrückliche Einwilligung oder ausreichende Schutzgarantien für die Übermittlung personenbezogener Daten ins Ausland. Wenn Patientenakten, Finanzdaten oder Mitarbeiterinformationen als Prompts an eine LLM-API gesendet werden, werden diese Daten technisch an die Infrastruktur des API-Anbieters übermittelt — ein erhebliches rechtliches Risiko für Gesundheits-, Finanz- und öffentliche Einrichtungen.
On-Premise-LLM-Deployment löst dieses Problem grundlegend: Daten verlassen die Infrastruktur der Organisation physisch nicht, Protokolldatensätze verbleiben unter organisatorischer Kontrolle und Audit-Trails liegen in den Händen der Organisation. Der Vergleich von On-Premise-KI-Servern mit Cloud-GPUs — mit ausführlicher Behandlung von Kosten und Compliance — ist in unserem dedizierten Leitfaden verfügbar.
Netzwerksegmentierung ist aus technischer Isolationsperspektive ebenso kritisch. Der Betrieb des LLM-Dienstes in einem isolierten Netzwerksegment ohne Internet-Egress minimiert das Datenleck-Risiko. Die Speicherung der Modellgewichte in einer sicheren internen Artifact-Registry und die Durchsetzung der Modell-Versionskontrolle stärken die Ausrichtung an den unternehmensweiten Sicherheitsrichtlinien weiter.
- KVKK Artikel 9: Grenzüberschreitende Übermittlung erfordert ausdrückliche Einwilligung oder ausreichenden Schutz — On-Premise eliminiert dieses Risiko
- Gesundheitssektor: Das Senden von Patientendaten in Prompts an ausländische APIs birgt das Risiko der Nichteinhaltung von Vorschriften des Gesundheitsministeriums
- Finanzsektor: BDDK- und CMB-Vorschriften erfordern Datensouveränität für Kundenfinanzdaten
- Öffentliche Einrichtungen: Cybersicherheitsgesetzgebung verpflichtet zur inländischen Verarbeitung sensibler Daten
- ISO-27001-Konformität: On-Premise-LLM erfüllt Anforderungen an Zugriffskontrolle und Audit-Trail leichter
Workstation oder Server? Die Entscheidungsmatrix
Für einen Einzelentwickler oder ein kleines Team ist die Workstation die richtige Wahl; für Enterprise-Multi-User-Deployments ist der GPU-Server korrekt. Die Entscheidung hängt von gleichzeitigen Nutzern, Modellgröße, Budget und Verwaltbarkeit ab.
Beide Plattformen können lokale LLMs betreiben, unterscheiden sich aber in Skalierung, Verwaltungskomplexität und Kostenprofil. Die folgende Entscheidungsmatrix hilft dabei, die Anforderungen Ihrer Organisation den verfügbaren Optionen zuzuordnen. Was ist eine Workstation vs. ein Server? — unser Grundlagenleitfaden — behandelt Plattformunterschiede aus einer breiteren Perspektive.
| Kriterium | Workstation (RTX 5090) | GPU-Server (Multi-GPU) |
|---|---|---|
| Anfangsinvestition | Mittel (5.000–15.000 USD) | Hoch (20.000–100.000 USD+) |
| Gleichzeitige Nutzer | 1–8 (mit vLLM) | 10–100+ (mit vLLM) |
| Max. VRAM (ein Gehäuse) | 64 GB (Dual RTX 5090) | 96–640 GB+ (RTX PRO 6000 / H100) |
| Skalierbarkeit | Begrenzt (2–4 GPUs) | Hoch (8+ GPUs, Cluster-Unterstützung) |
| Verwaltungskomplexität | Niedrig | Mittel–Hoch (Kubernetes, Slurm) |
| Hohe Verfügbarkeit | Nein (Single Point) | Ja (redundante Konfiguration) |
| Lärm und Kühlung | Handhabbar (Büro) | Erfordert Rechenzentrum |
| Amortisierung vs. Cloud | 5–7 Monate | 8–18 Monate (skalierungsabhängig) |
| KVKK-Konformität | Ja (Daten bleiben lokal) | Ja (Daten bleiben lokal) |
| Bestes Szenario | Prototyp, kleines Team | Enterprise-Dienst, Mehrbenutzer |
Aus Kostenperspektive zeigt der Vergleich eines lokalen RTX-5090-basierten Servers mit äquivalenter Cloud-GPU-Kapazität (z. B. stündliche A10G- oder A100-Miete), dass sich die lokale Infrastruktur in etwa 5–7 Monaten intensiver Nutzung amortisiert. Bei intensiverer Nutzung verkürzt sich dieser Zeitraum weiter.
Hybride Ansätze gewinnen ebenfalls an Popularität: Basis-Workloads laufen auf On-Premise-Workstations oder GPU-Servern, während Cloud-GPU-Kapazität für Lastspitzen als Burst genutzt wird. Dieses Modell bietet eine ausgewogene Lösung für Kostenoptimierung und KVKK-Konformität.
Häufig gestellte Fragen
Welche GPU ist am besten für lokale LLMs geeignet?
Das hängt von Ihren Anforderungen ab. Für einen Einzelentwickler sind die RTX 5090 (32 GB) oder die kostengünstige RTX 3090 (24 GB) ideal. Für Enterprise-Multi-User-Betrieb wird die RTX PRO 6000 Blackwell (96 GB) oder Datacenter-Klasse A100/H100 empfohlen.
Wie viel VRAM benötigt ein 70B-Modell?
Ein 70B-Modell benötigt bei FP16-Präzision etwa 140 GB VRAM; Q4-Quantisierung reduziert dies auf 35–40 GB. Eine einzelne RTX 5090 (32 GB) betreibt es mit knapper Reserve; Dual RTX 5090 (64 GB) bietet einen komfortablen Puffer für 70B Q4.
Ollama oder vLLM — was sollte ich verwenden?
Ollama für schnellen Einstieg und Einzelnutzung — ein Befehl, null Konfiguration. Wenn Ihre Produktionsumgebung 10+ gleichzeitige Anfragen anstrebt, liefert der PagedAttention-Mechanismus von vLLM wesentlich höheren Durchsatz. Beide schließen sich nicht aus: prototypieren mit Ollama, produzieren mit vLLM.
Ist lokale LLM-Inferenz günstiger als Cloud-LLM-APIs?
Bei intensiver Nutzung ist lokale Infrastruktur generell wirtschaftlicher; ein RTX-5090-Setup amortisiert sich gegenüber äquivalenter Cloud-Kapazität in etwa 5–7 Monaten. Bei geringer oder variabler Auslastung kann Cloud vorteilhafter sein.
Wie sicher ist On-Premise-LLM aus Datenschutzsicht?
Bei On-Premise-LLM verlassen Daten das Netzwerk Ihrer Organisation physisch nicht — es besteht kein grenzüberschreitendes Übermittlungsrisiko gemäß KVKK Artikel 9. Mit Netzwerkisolierung und Zugriffskontrollrichtlinien wird das höchste Datensouveränitätsniveau erreicht.
Wie stark beeinflussen CPU und RAM die LLM-Leistung?
Wenn der VRAM erschöpft ist und Offloading stattfindet, wird die CPU-Geschwindigkeit kritisch. Bei normaler GPU-Inferenz übernimmt die CPU Tokenisierung und Preprocessing; ein moderner Mehrkern-CPU (EPYC, Xeon) mit 64 GB+ System-RAM wird empfohlen. Der primäre Engpass bleibt VRAM.
Was ist Quantisierung und beeinträchtigt sie das Modell?
Quantisierung reduziert die Präzision der Modellgewichte (FP16 → INT8 → INT4) und senkt den VRAM-Bedarf. Bei Q4 ist der Genauigkeitsverlust für die meisten Enterprise-Aufgaben vernachlässigbar, weshalb Q4 oder Q8 zur Standardwahl für lokales Deployment geworden sind.
Fazit
Die Entscheidung für den Betrieb lokaler LLMs basiert auf VRAM-Kapazität, Anzahl gleichzeitiger Nutzer, Datenschutzverpflichtungen und langfristiger Kostenbalance. Für einen Einzelentwickler oder ein kleines Team kann eine RTX-5090-Workstation kombiniert mit Ollama innerhalb von Tagen in Betrieb genommen werden; Enterprise-Multi-User-Dienste erfordern GPU-Server-Infrastruktur und vLLM. In durch die KVKK regulierten Sektoren bietet On-Premise-Deployment nicht nur einen Kostenvorteil, sondern auch rechtliche Compliance-Sicherheit.
Wenn Sie die lokale LLM-Infrastruktur Ihrer Organisation planen, den richtigen GPU- und Software-Stack auswählen oder Ihre bestehenden Cloud-Ausgaben mit einer On-Premise-Investition vergleichen möchten, steht Ihnen unser Sora-Team für lokale LLMs für ein kostenloses Erstgespräch zur Verfügung.