Lokale LLMs auf eigener Hardware: Was wirklich funktioniert

Lokale Sprachmodelle haben sich in den letzten Jahren von einer Bastelei für Enthusiasten zu einer ernstzunehmenden Betriebsoption entwickelt. Wer wissen will, wann sich der Aufwand tatsächlich lohnt, muss drei Fragen ehrlich beantworten: Was schützt lokal, was spart lokal, und wo stößt lokal an Grenzen, die man nicht wegdiskutieren kann.

Warum lokale Modelle

Drei Gründe treiben in unserer Praxis die Entscheidung für lokale LLMs, meist in Kombination:

• Datenschutz – sensible Anfragen (Verträge, Kundendaten, interne Dokumente) verlassen nie das eigene Netz. Für regulierte Branchen oft der entscheidende Punkt, nicht die Kosten.
• Kosten bei hohem Volumen – wer täglich tausende Anfragen verarbeitet, zahlt bei Cloud-APIs pro Token; ab einem gewissen Volumen wird die eigene, abgeschriebene GPU günstiger als der laufende API-Preis.
• Latenz – ein Modell im eigenen Rechenzentrum antwortet ohne Umweg über das offene Internet, relevant für interaktive Anwendungen mit vielen kurzen Anfragen.

Wichtig ist die Reihenfolge: Datenschutz und Kontrolle sind meist der eigentliche Auslöser, Kostenersparnis kommt oft erst bei genauerem Hinsehen als zweiter Vorteil dazu – oder eben nicht, siehe unten.

VRAM-Faustregeln und Quantisierung verständlich erklärt

Die zentrale Ressource für lokale LLMs ist nicht Rechenleistung im klassischen Sinn, sondern VRAM – der Grafikkartenspeicher, in dem das Modell während der Inferenz vollständig liegen muss. Als grobe Faustregel gilt: ein Modell mit X Milliarden Parametern braucht in voller Präzision (FP16) etwa 2 Gigabyte VRAM pro Milliarde Parameter. Ein 7-Milliarden-Modell braucht also grob 14 GB, ein 70-Milliarden-Modell entsprechend 140 GB – jenseits dessen, was eine einzelne Consumer-GPU stemmt.

Hier kommt Quantisierung ins Spiel: Statt jede Modellzahl mit voller Genauigkeit (16 Bit) zu speichern, rundet man sie auf weniger Bits – üblich sind Q8 (8 Bit) und Q4 (4 Bit). Das klingt nach Qualitätsverlust, und ein wenig ist es das auch, aber in der Praxis bleibt bei Q8 die Antwortqualität für die meisten Anwendungsfälle nahezu unverändert, während der Speicherbedarf halbiert wird. Bei Q4 ist der Effekt stärker spürbar – für einfache, klar strukturierte Aufgaben oft noch ausreichend, für anspruchsvolle Textarbeit oder komplexes Schlussfolgern spürbar schwächer. Als Daumenregel: ein 7B-Modell in Q4 läuft komfortabel mit 6 GB VRAM, ein 13B-Modell in Q4 mit etwa 10 GB – beides auf gängigen Workstation-GPUs machbar.

Sinnvolle Hardware-Klassen

Nicht jede Anwendung braucht einen GPU-Server. Drei realistische Einstiegsstufen:

Die Workstation

Eine gut ausgestattete Workstation mit einer Consumer-GPU (24 GB VRAM-Klasse) reicht für den Betrieb kleinerer bis mittlerer Modelle (7B bis 13B, quantisiert) für ein einzelnes Team oder eine Handvoll paralleler Nutzer. Der günstigste und schnellste Einstieg, ideal für Pilotprojekte und interne Tools.

Der dedizierte Inferenz-Server

Ein Server mit einer oder mehreren Profi-GPUs (48 GB und mehr VRAM je Karte) trägt größere Modelle oder mehr gleichzeitige Nutzer. Hier lohnt sich der Aufwand, wenn ein ganzes Unternehmen dieselbe Instanz nutzt – die Kosten pro Nutzer sinken deutlich gegenüber Einzel-Workstations.

Der GPU-Cluster

Mehrere GPU-Server im Verbund, nötig für sehr große Modelle oder hohe parallele Last (viele hundert gleichzeitige Anfragen). Für die meisten mittelständischen Anwendungsfälle Overkill – relevant wird das erst bei unternehmensweitem, produktionskritischem Einsatz mit vielen Nutzern gleichzeitig.

Embeddings lokal als Sweet Spot

Ein Anwendungsfall, der bei der Diskussion um lokale LLMs oft untergeht, aber besonders gut passt: Embeddings – die Umwandlung von Text in Vektoren für Suche und Ähnlichkeitsvergleiche. Embedding-Modelle sind deutlich kleiner als generative Sprachmodelle, laufen komfortabel auf bescheidener Hardware und werden oft in hoher Frequenz aufgerufen (jede Suche, jede Dokumenteneinordnung). Genau diese Kombination – klein, häufig, oft mit sensiblen Inhalten – macht Embeddings zum unkompliziertesten und meist auch wirtschaftlichsten Einstieg in lokale KI-Infrastruktur, noch bevor man über ein komplettes generatives Modell nachdenkt.

Fine-Tuning und Anpassung

Ein weiterer Vorteil lokaler Modelle, der oft übersehen wird: Man kann sie auf eigene Daten feinjustieren, ohne diese Daten je an einen externen Anbieter zu übermitteln. Für Branchen mit sehr spezifischem Vokabular – etwa juristische oder medizinische Fachterminologie – liefert ein feinjustiertes kleines Modell in der Praxis oft bessere Ergebnisse als ein sehr viel größeres, aber generisches Cloud-Modell. Der Aufwand für sauberes Fine-Tuning ist real, aber deutlich geringer als noch vor wenigen Jahren, dank etablierter Werkzeuge für parametereffizientes Training.

Grenzen lokaler LLMs

So attraktiv lokale Modelle sind, sie lösen nicht jedes Problem. Zwei Grenzen, die man vorab kennen sollte:

• Große Kontexte – sehr lange Dokumente oder umfangreiche Gesprächsverläufe brauchen proportional mehr VRAM für den Kontext selbst, zusätzlich zum Modell. Ein System, das knapp genug für das Modell dimensioniert ist, gerät bei langen Eingaben schnell an seine Grenze.
• Spitzenlast – ein lokaler Server hat eine feste Kapazitätsgrenze. Kommt es zu unvorhersehbaren Lastspitzen (z. B. viele gleichzeitige Anfragen bei einer Kampagne), gibt es keine elastische Cloud-Reserve, auf die man kurzfristig zurückgreifen kann, ohne vorher zu investieren.

Für beide Fälle ist ein hybrider Ansatz meistens die pragmatischste Lösung: lokale Modelle für die Routinelast, ergänzt durch Cloud-Kapazität für Ausreißer nach oben. Wer ausschließlich auf lokale Hardware setzt, kauft am Ende für den seltenen Spitzenfall, statt ihn flexibel abzufedern.

Eine dritte, praktische Grenze betrifft Wartung und Betrieb: Ein lokal betriebenes Modell braucht jemanden, der Updates einspielt, Sicherheitslücken im Blick behält und bei Fehlverhalten eingreift. Bei einer Cloud-API übernimmt der Anbieter diese Aufgaben; bei eigener Hardware liegt sie beim eigenen Team. Für kleinere Unternehmen ohne eigene KI-Betriebserfahrung ist das ein realer Aufwand, den man von Anfang an einplanen sollte – etwa durch einen erfahrenen Infrastrukturpartner, der Monitoring und Updates als laufenden Service übernimmt, statt es als einmaliges Projekt zu betrachten.