Lokale LLM: Welche Hardware und GPU brauchst du wirklich

Eine Anwaltskanzlei aus Warschau wollte einen Assistenten für die Vertragsanalyse einsetzen. Die erste Frage war technisch: Reicht ein Server mit einer RTX 3090? Die zweite, treffendere: Welches Modell wird für diese Aufgabe überhaupt benötigt? Die Antwort auf die erste Frage hängt von der Antwort auf die zweite ab. Ohne Modellanforderungen ist die Hardware-Entscheidung ein Glücksspiel.

Im Folgenden beschreibe ich, wie man beides verbindet — von den Modellanforderungen über die Hardware bis hin zum realen Kostenplan für polnische Unternehmen, die Self-Hosting von LLM in Betracht ziehen.

Lokale LLM können auf der CPU laufen (z. B. über llama.cpp), aber die Generierungsgeschwindigkeit auf dem Prozessor allein beträgt in der Regel 2–8 Token pro Sekunde für ein 7B-Modell. Für Produktionsanwendungen, bei denen der Nutzer auf eine Antwort wartet, ist dieser Wert zu niedrig: Die menschliche Wahrnehmung von Komfort liegt bei mindestens 20–30 Token pro Sekunde.

GPU beschleunigt die Inference durch parallele Matrixmultiplikation — eine Operation, die in LLM-Berechnungen dominiert. Entscheidend sind jedoch nicht die Megaflops, sondern zwei andere Werte:

VRAM (GPU-Speicher) entscheidet, ob das Modell überhaupt geladen werden kann. Wenn das Modell nicht in den VRAM passt, wird es in den RAM oder auf die Festplatte ausgelagert, und die Geschwindigkeit sinkt um eine Größenordnung. Die erste Frage bei der GPU-Auswahl lautet immer: Passt das gesamte Modell in den VRAM?

Memory bandwidth (Speicherbandbreite) entscheidet, wie schnell die GPU die Modellgewichte während der Generierung ausliest. Die Generierung jedes Tokens erfordert das Auslesen des gesamten Modells aus dem Speicher. Eine Karte mit einer Bandbreite von 800 GB/s generiert Token schneller als eine Karte mit 400 GB/s bei gleicher Anzahl von Kernen. Beim GPU-Vergleich sollte man die Bandbreite prüfen, nicht nur die TFLOPS.

Der VRAM-Bedarf hängt von der Modellgröße und der Quantisierung ab. Quantisierung reduziert die Genauigkeit der Gewichte von 16 Bit auf 8, 4 oder sogar 3 Bit, wodurch die Modellgröße bei akzeptablem Qualitätsverlust verringert wird.

Die Werte sind Näherungswerte; der tatsächliche Bedarf variiert je nach Länge des Context Window und der Implementierung. Zu den oben genannten Werten kommt ein Puffer für Aktivierungen hinzu: Bei einem Kontext von 8K sind das zusätzliche 1–2 GB, bei 32K 4–8 GB. Große Kontexte verbrauchen schnell VRAM.

Der GPU-Markt im Jahr 2026 lässt sich für LLM-Anwendungen in drei Klassen einteilen:

Consumer-Karten (RTX-Serie 30xx/40xx) haben einen erschwinglichen Preis, aber begrenzten VRAM (bis zu 24 GB bei RTX 3090/4090). Die Bandbreite der RTX 4090 beträgt 1.008 GB/s, was sie zur schnellsten verfügbaren Consumer-Karte für LLM macht. Einschränkung: Keine NVLink-Unterstützung für viele Modelle, was das Kombinieren von Karten erschwert. Der Preis einer neuen RTX 4090 liegt bei 8.000–10.000 PLN.

Professionelle Karten (RTX A-Serie, L40S, RTX 6000 Ada) bieten mehr VRAM (48–80 GB), ECC, NVLink-Unterstützung und Treiber für stabilen Uptime. Die RTX 6000 Ada (48 GB VRAM, ~24.000 PLN) ermöglicht das Ausführen eines 34B-Modells in voller Präzision oder eines 70B-Modells in Q4. Die L40S (48 GB) ist das Server-Äquivalent.

Datacenter-Karten (H100, A100, H200) bieten den größten Speicher (80–141 GB) und die höchste Bandbreite (HBM3, ~3,35 TB/s für H100 SXM), aber die Preise beginnen bei 150.000 PLN und sind in der Regel nur in der Cloud oder über Leasing verfügbar.

Für polnische Unternehmen, die Modelle von 7B–13B für RAG- und Klassifizierungsaufgaben einsetzen möchten, bieten die RTX 4090 oder eine gebrauchte RTX 3090 das beste Preis-Leistungs-Verhältnis. Für 70B-Modelle sind entweder zwei 24-GB-Karten (NVLink oder PCIe) oder eine 48-GB+-Karte erforderlich.

Zwei GPU-Karten können auf zwei Arten verbunden werden:

NVLink (nur ausgewählte NVIDIA-Karten, einschließlich RTX 3090/4090 mit passendem Mainboard) verbindet den Speicher beider Karten zu einem Pool. Ein 70B-Q4-Modell auf 2×24 GB funktioniert, als hätte es 48 GB einheitlichen Speicher. Die Kommunikationsbandbreite beträgt ~600 GB/s, sodass der Engpass minimal ist.

PCIe (Standard-Mehrkarten-Konfigurationen) verbindet den Speicher nicht. Das Modell muss auf eine Karte passen oder wird mit Transfer über den PCIe-Bus (16 GB/s) geteilt, was die Inference drastisch verlangsamt. PCIe-Multi-GPU-Konfigurationen sind nützlich für Throughput (viele parallele Anfragen auf verschiedenen Karten), nicht für die Arbeit mit einem großen Modell.

Für ein Produktionssystem, das viele parallele Anfragen verarbeitet, ermöglicht eine Konfiguration mit 2–4 PCIe-Karten auf demselben Modell eine Erhöhung der Anzahl der verarbeiteten Anfragen pro Sekunde ohne Skalierung des VRAM. Jede Karte verarbeitet eine eigene Modellinstanz; ein LLM-Router verteilt den Verkehr.

CPU und RAM spielen eine zweitrangige, aber nicht marginale Rolle.

System-RAM wird benötigt, um das Modell in den VRAM zu laden (das Modell wird zunächst in den RAM geladen und dann in die GPU kopiert) sowie zur Verwaltung der Orchestrierungsschicht: API-Server, RAG-Pipeline, Abfragevorverarbeitung. Das Minimum beträgt das Doppelte des VRAM, praktisch: 64 GB für eine Einzelkarten-Konfiguration, 128 GB für Multi-GPU.

CPU ist nur bei CPU-only-Betrieb (ohne GPU) oder bei intensiver Vorverarbeitung (Tokenisierung großer Dokumente, Embedding auf der CPU) ein Engpass. Für die Verwaltung eines API-Servers bei GPU-beschleunigter Inference reicht jeder moderne Server- (z. B. AMD EPYC, Intel Xeon) oder Desktop-Prozessor (AMD Ryzen 9, Intel Core i9). Die Anzahl der Kerne ist wichtig für die API-Parallelität, nicht für die Generierungsgeschwindigkeit.

NVMe-SSD beschleunigt das Laden des Modells beim Serverstart. Ein 7B-Modell ist eine ~4 GB große Datei, 70B-Modelle sind 40 GB groß. Das Laden von einer HDD kann mehrere Minuten dauern, von einer NVMe — nur wenige Sekunden. Für Systeme mit mehreren dynamisch wechselnden Modellen (wie unser OpenClaw-Router) reduziert eine schnelle SSD die Bereitschaftszeit.

Fine-Tuning und Quantisierung sind zwei Methoden zur hardwarebezogenen Modelloptimierung. Quantisierung ist der einfachere Weg für die meisten Implementierungen.

Das beliebteste Format im Jahr 2026 ist GGUF mit Quantisierung Q4_K_M oder Q5_K_M (unterstützt von llama.cpp, Ollama, LM Studio). Q4_K_M reduziert den VRAM um ~72 % gegenüber BF16 bei einem Qualitätsverlust von 1–3 % in allgemeinen Benchmarks. Für spezialisierte Aufgaben (Recht, Finanzen, Medizin) sollte empirisch getestet werden — die Degradation kann in Nischendomänen höher ausfallen als Benchmarks zeigen.

GPTQ und AWQ sind Quantisierungsformate für NVIDIA-Karten, die auf GPU-Kernebene arbeiten, schneller als GGUF bei gleichem VRAM, aber mit mehr Konfigurationsaufwand. Nützlich für produktive NVIDIA-Server.

bitsandbytes 4-bit (QLoRA) wird beim Fine-Tuning auf GPUs mit begrenztem VRAM verwendet, nicht zum Serving. Nicht mit Inference-Formaten verwechseln.

Praktische Regel: Beginne mit Q4_K_M, teste die Qualität mit deinem eigenen Fragenkatalog und wechsle nur dann zu Q5 oder Q8, wenn du einen messbaren Qualitätsverlust feststellst. Für 7B-Modelle ist der Unterschied zwischen Q4 und Q8 bei Geschäftsanwendungen meist minimal.

Die Entscheidung für lokale LLM ist eine finanzielle, nicht nur eine technische. Gegenüberstellung für eine typische polnische Implementierung:

Produktionskonfiguration für ein 13B-Modell: Server mit RTX 4090 (9.000 PLN), 128 GB RAM (3.000 PLN), AMD Ryzen 9 + Mainboard + Netzteil (5.000 PLN), NVMe 2 TB (800 PLN). Gesamtkosten Hardware: ~18.000–22.000 PLN einmalig. Dazu kommen Konfigurations- und Administrationszeit (in der Regel 2–4 Tage Ingenieursarbeit für den Start, 1–2 Stunden pro Woche Wartung).

Der Stromverbrauch der RTX 4090 beträgt ~350–400 W bei Volllast. Bei polnischen Strompreisen (ca. 0,80 PLN/kWh) und 8 Stunden Betrieb pro Tag sind das etwa 65–75 PLN pro Monat.

Vergleich mit Cloud-API: Bei 100.000 kurzen Anfragen pro Monat (Input ~200 Token, Output ~300 Token) betragen die Kosten für ein API eines Modells der Klasse GPT-4o etwa 1.500–3.000 PLN pro Monat. Ein lokaler LLM der Klasse 13B verarbeitet dieselben Anfragen nach der Amortisation der Hardware nur mit Stromkosten (einige Dutzend PLN). Die Rentabilitätsschwelle für lokale LLM gegenüber Cloud-API liegt bei 100.000 Anfragen pro Monat: Die Hardware amortisiert sich in 6–12 Monaten. Unter 20.000 Anfragen pro Monat ist Cloud-API in der Regel günstiger, wenn man die Administrationszeit berücksichtigt. Einen präzisen Kostenplan für deinen Umfang generiert der Inference-Rechner.

Für viele polnische Unternehmen ist die Hardware-Frage sekundär gegenüber regulatorischen Anforderungen. RODO verlangt die Kontrolle über personenbezogene Daten, die von KI-Systemen verarbeitet werden. Wenn Anfragen an LLM personenbezogene Daten enthalten (Kundennamen, PESEL, Adressen), erfordert die Nutzung externer Cloud-API unter anderem:

• den Abschluss eines Auftragsverarbeitungsvertrags (DPA) mit dem API-Anbieter,
• die Überprüfung, ob die Server des Anbieters im EWR liegen oder eine geeignete Grundlage für den Transfer in Drittländer besteht,
• die Durchführung einer DPIA, wenn die Verarbeitung ein hohes Risiko darstellt.

Self-Hosting eliminiert diese Anforderungen für die Generierungsschicht: Der LLM läuft auf der eigenen Infrastruktur, Daten verlassen das Unternehmen nicht. Dieser Ansatz wird ausführlicher im Artikel über Self-Hosted LLM und RODO beschrieben. Unabhängig von der Hardware-Wahl sollten PII vor dem Senden an das Modell maskiert werden — das gilt sowohl für lokale LLM als auch für API.

Beschreibe deinen Anwendungsfall für lokale LLM (Branche, Art der Anfragen, geschätztes Volumen, Datensensibilität), und das Modell wählt die Hardware-Konfiguration und die optimale Quantisierung aus (Playground: PII maskiert, keine Speicherung):

Die RTX 4090 mit 24 GB VRAM unterstützt Modelle bis etwa 13B in voller Präzision oder Modelle bis 34B in Q4-Quantisierung. Für die meisten Geschäftsanwendungen — Assistenten für RAG, Dokumentenklassifizierung, FAQ-Antworten — reicht ein 7B- oder 13B-Modell aus, und die RTX 4090 generiert es mit 50–80 Token pro Sekunde. Wenn du ein 70B-Modell benötigst (z. B. für komplexeres Reasoning), brauchst du entweder zwei Karten mit NVLink oder eine Karte mit 48 GB+.

Ein 70B-Modell in Q4_K_M-Quantisierung belegt etwa 40–42 GB VRAM. Dazu kommt ein Puffer für den Kontext: Bei einem Fenster von 8K sind das 2–4 GB, bei 32K 8–12 GB. Die minimale Hardware sind zwei RTX 3090/4090-Karten mit NVLink (insgesamt 48 GB) oder eine professionelle 48-GB-Karte, z. B. RTX 6000 Ada oder L40S. Eine PCIe-Zweikarten-Konfiguration verbindet den Speicher nicht, daher passt ein 70B-Q4-Modell nicht auf 2×24 GB ohne NVLink.

Ja, Tools wie llama.cpp ermöglichen den Betrieb von LLM ausschließlich auf der CPU. Die Generierungsgeschwindigkeit beträgt jedoch 2–8 Token pro Sekunde für 7B-Modelle, was für Produktionsanwendungen (Chat, Assistent) zu langsam ist. Der CPU-Modus ist nützlich für Tests, Prototyping und Batch-Aufgaben ohne Zeitanforderungen (z. B. nächtliche Batch-Zusammenfassungen). Für produktiven Throughput ist eine GPU notwendig.

Q4_K_M reduziert den VRAM um mehr als die Hälfte gegenüber voller Präzision bei einem Qualitätsverlust von 1–3 % in allgemeinen Benchmarks. Q8 reduziert den VRAM um ~50 % bei einem Verlust von unter 1 %. Der empfohlene Ausgangspunkt ist Q4_K_M: Es passt mehr Modell in den verfügbaren VRAM, und bei den meisten Geschäftsaufgaben ist der Qualitätsunterschied vernachlässigbar. Wechsle nur dann zu Q5 oder Q8, wenn du einen konkreten Qualitätsverlust in deinem eigenen Testset misst, nicht aufgrund abstrakter Benchmarks. Die Wahl des Basismodells und der Quantisierung wird im Artikel über Kosten lokaler vs. API-LLM beschrieben.

Die beliebtesten Optionen im Jahr 2026 sind: Ollama (einfachste Installation, OpenAI-kompatibles API, unterstützt GGUF), vLLM (produktiver Server für GPTQ/AWQ, optimiert für Throughput, benötigt CUDA), llama.cpp mit HTTP-Server (flexibel, unterstützt CPU und GPU, GGUF-Format) und LM Studio (grafische Oberfläche für Prototyping). Für Produktionsumgebungen sind Ollama oder vLLM mit einem LLM-Router zur Verkehrsverwaltung und Cloud-Fallback bei Überlastung ein bewährtes Muster. Details zur Architektur beschreibt der Artikel über Firmen-GPT auf Wissensbasis.