LLM on premise im Industriebetrieb: Hardware, kleine Modelle, Betrieb

Ein LLM on premise zu betreiben heißt: Sie kaufen keine Antworten, sondern eine Anlage – mit Dimensionierung, Wartungsplan, Backup und einer Person, die im Störfall angerufen wird. Ob sich das lohnt, entscheiden drei Fragen: Dürfen die Daten das Haus verlassen, wie groß muss das Modell sein, und wer betreibt das System nach dem Projektende? Dieser Artikel liefert den Rechenweg von der Nutzerzahl zur GPU, die Begründung für kleine Modelle und die Fälle, in denen eine EU-Cloud die vernünftigere Wahl ist.

Warum überhaupt LLM on premise – und wann das Argument nicht trägt

Drei Gründe rechtfertigen den Eigenbetrieb eines Sprachmodells: Datenhoheit, Verfügbarkeit ohne Internetanbindung und Kostenkontrolle bei hohem Dauervolumen. Drei weitere werden oft genannt und halten nicht stand: ein allgemeines Unbehagen gegenüber der Cloud, eine vermeintliche Ersparnis bei geringem Volumen und die pauschale Ablehnung externer Dienste. Tab. 01 stellt beide Seiten nebeneinander.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) führt in „Generative KI-Modelle: Chancen und Risiken für Industrie und Behörden“ (Version 2.0, Januar 2025) die fehlende Vertraulichkeit eingegebener Daten als Risiko R2: Bei Modellen als Internetdienst könne der Betreiber auf die Daten zugreifen und sie zum Training nutzen. Genau dieses Risiko schließt der Eigenbetrieb aus – und nur dieses. Von den 28 Risiken des BSI bleiben die meisten im eigenen Netz bestehen.

Der lokale Betrieb verlagert Verantwortung, er schafft sie nicht ab. Wer ein Sprachmodell selbst hosten will, übernimmt Patchen, Testen, Backup, Zugriffskontrolle und Störungsbereitschaft. Lokale KI im Unternehmen ist deshalb weniger eine technische als eine organisatorische Entscheidung.

Kleine Modelle statt großer: die eigentliche Voraussetzung

Ein Allzweckmodell mit mehreren hundert Milliarden Parametern ist für die typischen Aufgaben im Werk überdimensioniert. Störmeldungen in zwanzig Kategorien sortieren, Nennweite und Werkstoff aus einem Datenblatt ziehen, Artikelnummern normalisieren – das sind eng umrissene, wiederkehrende Aufgaben mit wenig Variation. Für genau diesen Fall argumentiert NVIDIA Research (Belcak et al., 2025), dass kleine Sprachmodelle ausreichend leistungsfähig sind – und in ihren Worten:

Für den Eigenbetrieb ist das die entscheidende Weichenstellung, denn der Speicherbedarf der Gewichte skaliert mit Parameterzahl mal Byte pro Parameter. Nach der Transformers-Dokumentation von Hugging Face werden Gewichte in fp32 mit 4 Byte oder in fp16/bf16 mit 2 Byte gespeichert; Quantisierung reduziert sie auf int8 oder int4 und versucht, möglichst viel Genauigkeit zu erhalten. Tab. 02 zeigt das als Rechenbeispiel.

Der Trade-off ist real: Quantisierung kostet Genauigkeit, und wie viel, hängt von Modell, Methode und Aufgabe ab. Ein int4-Modell kann Störmeldungen weiter sauber klassifizieren und bei Toleranzen aus Tabellen sichtbar nachlassen. Deshalb gehört vor jede Quantisierung ein Test mit eigenen Dokumenten. Das Mittelstand-Digital Zentrum Chemnitz hält fest, dass dank Retrieval Augmented Generation (RAG) häufig kleinere Sprachmodelle genügen, die sich on premise betreiben lassen – wodurch die sicherheitskritische Datenübertragung an Dritte entfällt.

Ein zweites Argument für das Small Language Model in der Industrie ist die Nähe zur Anlage. Ein Modell mit wenigen Milliarden Parametern läuft auf einer Workstation-GPU im Leitstand und bleibt bei Ausfall der WAN-Strecke verfügbar – für einen Störungsassistenten an der Linie wichtiger als die letzte Nuance Sprachqualität. Welche Aufgaben in der technischen Dokumentation sich überhaupt für ein Sprachmodell eignen, steht in KI für technische Dokumentation.

GPU-Dimensionierung: von der Nutzerzahl zur Hardware

Die GPU-Dimensionierung für ein LLM beginnt bei fünf Größen: gleichzeitige Nutzer, Anfragen pro Stunde, mittlere Kontextlänge, mittlere Antwortlänge und akzeptierte Wartezeit bis zum ersten Token. Daraus folgen Speicherbedarf (Gewichte plus KV-Cache) und Durchsatz. Der KV-Cache ist der Posten, den fast jede Planung unterschätzt.

Rechenbeispiel mit den Werten, die NVIDIA für Llama 2 7B nennt: 32 Schichten, Hidden Size 4096, fp16. Pro Token sind das 2 × 32 × 4096 × 2 Byte, rund 0,5 MB; bei 4.096 Token ergibt das laut NVIDIA etwa 2 GB. Bei 16.000 Token Kontext für eine Dokumentenauswertung sind das rund 8 GB pro Anfrage; acht gleichzeitige Anfragen belegen etwa 64 GB – zusätzlich zu 14 GB Gewichten. Deshalb ist die Kontextlänge der Haupttreiber, nicht die Nutzerzahl. Neuere Architekturen brauchen pro Token weniger Cache; die Werte stehen im Modellsteckbrief.

Beim Durchsatz kommt hinzu: Die Decode-Phase, in der das Modell Token für Token erzeugt, ist laut NVIDIA speicherbandbreitenbegrenzt – die Latenz hängt davon ab, wie schnell Gewichte und Cache aus dem GPU-Speicher gelesen werden. Speichergröße begrenzt also die Parallelität, Speicherbandbreite die Antwortzeit.

1. 01

   Lastprofil erheben

   Gleichzeitige Nutzer in der Spitzenstunde, Anfragen pro Stunde, Token pro Prompt inklusive abgerufener Dokumentabschnitte, Token pro Antwort.

2. 02

   Modellklasse festlegen

   Mit 50 bis 200 eigenen Dokumenten die kleinste Modellklasse bestimmen, die die Aufgabe zuverlässig löst – in fp16 und quantisiert.

3. 03

   Speicher rechnen

   Gewichte nach Tab. 02 plus KV-Cache für die Spitzenlast plus Reserve für Embedding-Modell und Laufzeit ergeben die Speicherklasse der GPU.

4. 04

   Durchsatz gegen Wartezeit prüfen

   Ein Extraktionsjob im Batch darf Minuten dauern, ein Assistent an der Linie nicht; die akzeptierte Zeit bis zum ersten Token entscheidet.

5. 05

   Vor dem Kauf unter Last testen

   Auf gemieteter Hardware mit echtem Lastprofil messen, erst danach bestellen – mit Stand-Datum und Wiedervorlage in der Akte.

Was neben der GPU noch gebraucht wird

Ein KI-Server auf eigener Hardware besteht aus mehr als der Grafikkarte; die Inferenz ist selten der Engpass, die Ingest-Strecke fast immer. Jeder Baustein will installiert, überwacht und gesichert werden.

Embedding-Modell

Wandelt Textabschnitte in Vektoren. Wird es getauscht, muss der Index neu aufgebaut werden.

Vektorindex

Speichert Vektoren, Textabschnitte und Metadaten wie Quelle, Version und Berechtigung. Zweiter Datenbestand mit Schutzbedarf: Backup, Rechtefilter, Löschpfad.

Ingest-Pipeline

OCR, Layout-Erkennung, Tabellenextraktion, Chunking, Re-Indexierung bei Änderungen. Hier entstehen die meisten Fehler und oft mehr Rechenaufwand als bei der Inferenz.

Reverse Proxy mit Authentifizierung

Anbindung an das Verzeichnis, Rollen, Anfragelimits pro Nutzer, Trennung der Netzzonen.

Monitoring

Latenz, Fehlerquote, GPU-Auslastung, Abbrüche, Anfragen pro Nutzer – ohne diese Zahlen ist weder ein Modellwechsel bewertbar noch ein Angriff erkennbar.

Infrastruktur

Rackplatz, Strom und Kühlung für mehrere hundert Watt pro GPU, Netzanbindung, USV für geordnetes Herunterfahren.

Betrieb: der Teil, über den niemand schreibt

Die wichtigste Frage lautet nicht, welche GPU, sondern wer das System in achtzehn Monaten betreibt. Laut Bitkom Research fehlen in Deutschland 2026 rund 79.000 IT-Fachkräfte (Erhebung KW 18 bis 25 2026); die meistgesuchte Gruppe sind mit 26 % Fachkräfte für IT-Administration und Systembetrieb – genau das Profil, das ein lokales Sprachmodell braucht. Ein extern aufgebautes System, das an eine ausgelastete IT-Abteilung ohne Stundenbudget übergeht, ist das häufigste Muster für stillen Verfall.

Der zweite unterschätzte Posten ist der Modellwechsel. Ein neues Modell oder eine neue Quantisierung verändert Antworten ungleichmäßig: Was gestern korrekt extrahiert wurde, kann heute falsch sein. Das BSI empfiehlt in Maßnahme M11, Tests periodisch und anlassbezogen zu wiederholen und dabei das gesamte System mit allen Schnittstellen zu betrachten.

Sicherheit im eigenen Netz: on premise heißt nicht automatisch sicher

Der Eigenbetrieb nimmt genau ein Risiko vom Tisch – den Zugriff eines externen Betreibers auf Ihre Eingaben. Alle anderen Angriffsflächen bleiben in Ihrer Verantwortung. Das OWASP GenAI Security Project führt sie in den Top 10 for LLM Applications 2025 auf, das BSI in seiner Maßnahmensystematik. Tab. 04 ordnet die Punkte zu, die für ein Dokumentensystem im Werk am meisten wiegen.

Zwei Punkte verdienen Nachdruck. Erstens die indirekte Prompt Injection: Das BSI beschreibt in R28, dass Angreifende Anweisungen in Dokumenten verstecken können, die das Modell auswertet – bis hin zu Zeichen, die verarbeitet, aber nicht angezeigt werden. Ein Lieferantendatenblatt im Index ist damit eine Eingabe von außen, auch wenn der Server im Keller steht. Zweitens das Rechtekonzept: Das BSI rät in M14 ausdrücklich davon ab, Rechte und Rollen über textuelle Instruktionen umzusetzen. Die Berechtigung muss vor dem Retrieval als Filter greifen, nicht danach als Bitte im Prompt.

Zur Ressourcenbegrenzung nennt OWASP unter LLM10 strikte Validierung der Eingabegröße, Rate-Limits, Nutzerkontingente und Timeouts. In der Cloud führt ein solcher Angriff zu unerwarteten Rechnungen – OWASP spricht von Denial of Wallet –, im Eigenbetrieb zu einem stehenden System. Beim Logging weist das BSI in M19 auf rechtliche Anforderungen hin: Zweck, Pseudonymisierung und Aufbewahrungsfrist gehören vor die erste Zeile Log.

Kostenstruktur ehrlich aufgeschlüsselt

Die Kosten eines lokalen Sprachmodells bestehen aus mehreren Blöcken, von denen die Hardware der sichtbarste, aber selten der größte ist. Eine Preisliste gibt es bewusst nicht: Hardware-, Strom- und Cloud-Preise ändern sich schneller als dieser Artikel. Tab. 05 zeigt, wo die Blöcke im Eigenbetrieb und in der nutzungsabhängigen EU-Cloud liegen.

Ab welchem Volumen sich die Rechnung dreht, lässt sich nur mit eigenen Zahlen beantworten, aber die Logik ist immer dieselbe: Fixkosten pro Jahr aus Hardware, Strom, Personal und Bereitschaft gegen den nutzungsabhängigen Preis mal tatsächlichem Jahresvolumen. Eine GPU, die rund um die Uhr Lieferscheine verarbeitet, rechnet sich anders als eine, die auf zwanzig Fragen am Tag wartet. Wie Sie Einrichtung und Integration realistisch schätzen, zeigt Was kostet Individualsoftware in der Industrie.

Wann EU-Cloud die vernünftigere Wahl ist

Eine EU-Cloud ist die vernünftigere Wahl, wenn mindestens zwei dieser Punkte zutreffen: unregelmäßiges oder unbekanntes Volumen; kein Team für den Betrieb; Bedarf an Modellen, die auf eigener Hardware nicht laufen; ein Pilot mit offenem Ausgang; Daten ohne besonderen Schutzbedarf. KI ohne Cloud betreiben ist dann kein Wert an sich, sondern ein Kostenblock ohne Gegenwert. Tab. 06 fasst die Entscheidung in acht Kriterien zusammen.

Der hybride Zwischenweg – Index und Dokumente lokal, Sprachmodell extern – ist technisch sinnvoll, weil der aufwendige Ingest im Haus bleibt und das Modell austauschbar wird. Datenschutzrechtlich ist er aber kein lokaler Betrieb: Bei jeder Anfrage gehen die abgerufenen Dokumentabschnitte an den Anbieter. Der Wegfall der Datenübertragung an Dritte, den das Mittelstand-Digital Zentrum Chemnitz dem lokalen Betrieb zuschreibt, gilt hier nicht; der hybride Weg braucht dieselbe Prüfung wie ein Cloud-Szenario.

Fazit: erst das Modell verkleinern, dann die Hardware rechnen

Ein LLM on premise lohnt sich, wenn Daten das Haus nicht verlassen dürfen, die Anwendung ohne Internet laufen muss oder ein gleichmäßig hohes Volumen anfällt – und wenn jemand da ist, der die Anlage betreibt. Die Wirtschaftlichkeit entsteht nicht durch die GPU, sondern durch das kleinste Modell, das die Aufgabe zuverlässig löst. Rechnen Sie Gewichte und KV-Cache für Ihre tatsächliche Kontextlänge, testen Sie vor dem Kauf unter Last und legen Sie das Regressionsset vor dem Produktivgang an.

Sprechen zwei oder mehr Kriterien aus Tab. 06 gegen den Eigenbetrieb, ist eine EU-Cloud oder ein hybrider Aufbau die ehrlichere Antwort. Wenn Sie für Ihren Dokumentenbestand klären möchten, welche Modellklasse und welcher Betriebsweg passen, ist das eine typische Fragestellung für die KI-Lösungen von ralwo.