KI
·
3 MIN
Lokales LLM im Unternehmen: Hardware, Kosten, Realität
Ein lokales LLM braucht weniger Hardware als gedacht. Entscheidend ist die passende Modellgröße zur Aufgabe.
LOCATION
Rheinland-Pfalz
SERIES
Sovereign & Offline AI
AUTHOR
Aashwin Shrivastava
PUBLISHED
Ein Sprachmodell im eigenen Haus zu betreiben ist heute näher am Mittelstand, als die Diskussion vermuten lässt. Viele praktische Anwendungsfälle laufen auf einer einzelnen professionellen Grafikkarte, nicht auf einem Rechenzentrum. Der häufigste teure Fehler ist nicht zu wenig Hardware, sondern die Wahl eines zu großen Modells für eine Aufgabe, die ein kleineres ebenso erledigt.
Dieser Beitrag ordnet ein, welche Hardware welche Modellgröße trägt, wie die Kostenrechnung über drei Jahre aussieht und was der Betrieb im Alltag wirklich verlangt.
01.
Welche Hardware ein lokales LLM wirklich braucht
Die entscheidende Größe ist der Grafikspeicher, also der VRAM der GPU. Er bestimmt, welches Modell überhaupt geladen werden kann. Durch Quantisierung, also eine sparsamere Zahlendarstellung der Modellgewichte, sinkt dieser Bedarf deutlich, meist ohne spürbaren Qualitätsverlust für Fachaufgaben.
Grob gilt: Ein Modell der 7- bis 8-Milliarden-Klasse läuft quantisiert auf einer Karte mit etwa 16 bis 24 Gigabyte VRAM. Modelle um 30 Milliarden Parameter brauchen meist eine Karte mit rund 48 Gigabyte. Für die wirklich großen Modelle jenseits von 70 Milliarden Parametern werden mehrere Karten nötig. Viele Mittelstandsfälle bleiben in den ersten beiden Klassen.
02.
Modellgröße: kleiner ist oft genug
Die Versuchung ist groß, das stärkste verfügbare Modell zu nehmen. In der Praxis ist die passende Modellgröße eine Funktion der Aufgabe, nicht des Ehrgeizes. Für Klassifizierung, Extraktion aus Dokumenten oder die Beantwortung von Fragen aus einer Wissensdatenbank genügt oft ein kleineres Modell, sobald ein gutes Retrieval die richtigen Stellen liefert.
Genau hier zahlt sich der Zusammenhang aus, den wir an anderer Stelle gezeigt haben: Ein abgestimmter Retriever macht ein kleineres Modell brauchbar und spart Hardware. Wie weit offene Modelle inzwischen tragen, lässt sich an aktuellen Veröffentlichungen ablesen, etwa Kimi K2.7 Code und Nemotron 3 von NVIDIA, die offen verfügbar sind und auf eigener Hardware laufen.
| Klasse | Typische Aufgabe | Hardware (Richtwert) |
|---|---|---|
| 7 bis 8 Mrd. | Extraktion, Klassifizierung, RAG-Antworten | eine GPU, 16 bis 24 GB VRAM |
| ~30 Mrd. | anspruchsvollere Analyse, längerer Kontext | eine GPU, ~48 GB VRAM |
| 70 Mrd. und mehr | breite, offene Aufgaben, Agenten | mehrere GPUs |
03.
Die Kostenrechnung über drei Jahre
Eine einzelne professionelle GPU kostet je nach Klasse einen mittleren bis hohen vierstelligen Betrag, dazu kommen Server, Strom und Betrieb. Das ist eine einmalige Investition. Ihr steht bei einem Cloud-Dienst die Bezahlung pro Anfrage gegenüber, die mit der Nutzung mitwächst.
Der faire Vergleich rechnet nicht den Tagespreis, sondern die Gesamtkosten über zwei bis drei Jahre bei Ihrer erwarteten Last. Bei konstanter, hoher Nutzung amortisiert sich die lokale Hardware in diesem Zeitraum oft. Bei niedriger oder stark schwankender Last bleibt die Cloud meist günstiger. Die vollständige Abwägung steht in On-Premise vs. Cloud-LLM: Wann lokale KI die richtige Wahl ist.
04.
Betrieb, Wartung und der Realitätscheck
Die Hardware ist der sichtbare Teil, der Betrieb der unterschätzte. Ein lokales Modell will aktualisiert, überwacht und abgesichert werden. Es braucht jemanden, der Modelle einspielt, die Vektor-Datenbank pflegt und im Fehlerfall eingreift. Für kleinere Teams ist das der eigentliche Aufwand, nicht der Kauf der Karte.
Der Vorteil: Werkzeuge, die lokal arbeiten und nichts nach außen geben, fügen sich in diese Architektur ein. Ein Beispiel aus unserer eigenen Arbeit ist Graphify, das eine Codebasis lokal zu einem Wissensgraphen macht, ohne dass Code das Gerät verlässt. Solche lokalen Bausteine senken den Betriebsaufwand, weil sie keine zusätzliche Datenfreigabe nach außen erfordern.
05.
Ein realistischer Einstieg
Der sinnvolle Start ist klein und konkret: ein klar umrissener Anwendungsfall, ein Modell der kleineren Klasse, eine einzelne GPU und ein sauber aufgesetztes Retrieval. Daraus lernt das Team den Betrieb, und die nächste Ausbaustufe wird aus Erfahrung entschieden, nicht aus dem Datenblatt.
Wer mit dem Wissen aus Dokumenten beginnen will, findet den passenden Aufbau in Was ist RAG? Retrieval-Augmented Generation für den Mittelstand erklärt. Warum operative Kontrolle über die Modelle langfristig zählt, steht in Die Fable-5-Lektion zur Souveränität.
