Lokales LLM für Unternehmen

Ein lokales LLM beginnt in vielen Unternehmen mit einem einzigen Downloadbefehl und wirkt in der ersten Woche beeindruckend. Die Probleme kommen später: wenn die zweite Abteilung angebunden wird, wenn das erste Modellupdate ansteht oder wenn die Revision fragt, wer welche Dokumente gesehen hat. Dieser Leitfaden ordnet die Entscheidungen, die vor jeder Serverbestellung fallen sollten: welche Aufgabe, welches Modell, welche Hardware und welche Zugriffsregeln.

Fachbegriffe erklären wir dort kurz, wo sie zuerst auftauchen. Ziel ist, dass Sie selbst beurteilen können, ob ein anbietendes Team die richtigen Fragen stellt und ob die Einrichtung auch in einem Jahr noch beherrschbar bleibt.

01Vier Fragen, die die Entscheidung klären

Ein lokales LLM lohnt sich, wenn Daten das Haus nicht verlassen dürfen, die Aufgabe täglich anfällt und jemand den Server verantwortet. Fehlt eine dieser drei Bedingungen, prüfen Sie zuerst den Weg über die Cloud. Die Klärung gelingt in einer Besprechung, wenn die folgenden Fragen schriftlich beantwortet werden.

• Datenklasse: Enthalten die Dokumente personenbezogene Daten, Geschäftsgeheimnisse oder vertragliche Verschwiegenheitsklauseln; falls ja, in welchen Systemen liegen sie heute und wer darf sie öffnen.
• Häufigkeit: Fällt die Aufgabe täglich an oder nur einige Male im Monat; ein eigener Server für seltene Arbeit steht die meiste Zeit still.
• Verantwortung: Gibt es eine Person in der IT, die Patches, Speicherplatz und Alarme im Blick behält, oder übernimmt das ein externes Team mit Wartungsvertrag.
• Qualitätsanspruch: Hängt das Ergebnis vom stärksten Modell am Markt ab, oder genügt ein Modell, das zitiert, klassifiziert und kurze Zusammenfassungen schreibt.

Sind die Daten nicht sensibel, Sie wollen aber KI in Ihre Systeme einbinden, geht eine KI Integration mit Cloudmodellen schneller in Betrieb. Eine hybride Lösung, die beide Wege nutzt, ist ebenfalls möglich; dazu mehr im Abschnitt zur Architektur.

Bleiben die Antworten vage, ist es zu früh. Einige Wochen lang notieren die Teams, bei welchem Dokument sie Hilfe gebraucht hätten; diese Liste klärt die Lage und wird später zum Rohstoff des Testsets.

02Typische Aufgaben je nach Unternehmensart

Ein lokales Modell spielt seine Stärke bei klar umrissener, dokumentgestützter Arbeit aus; bei freier, kreativer Arbeit wird der Abstand zu Cloudmodellen sichtbar. Die folgenden Beispiele sind keine Kundenfälle, sondern typische Einsatzfelder solcher Projekte.

• Kanzlei: Klauseln in Vertragsentwürfen vergleichen und in alten Akten die passende Passage finden, gerade wenn die berufliche Schweigepflicht eine Verarbeitung in der Cloud fraglich macht.
• Steuerberatung: Für Buchungstexte aus Kontoauszügen Konten vorschlagen und Mandantenpost nach Themen sortieren.
• Produktionsbetrieb: Wartungsprotokolle nach Störungshistorie durchsuchen und wiederkehrende Fehler aus Qualitätsberichten herausziehen; im abgeschotteten Werksnetz oft die einzige Option.
• Arztpraxis oder Klinik: Aus Befundnotizen Entwürfe für Verwaltungsschreiben erstellen, zur Entlastung bei Papierarbeit und nicht für medizinische Entscheidungen.
• Softwareteam: Code erklären und Testentwürfe schreiben, ohne dass Quellcode das Unternehmen verlässt.

Geht es eigentlich darum, Felder aus gescannten Rechnungen, Verträgen oder Antragsformularen auszulesen, wird das lokale Modell zum Motor einer KI Dokumentenverarbeitung. Texterkennung und Prüfregeln laufen dann als eigene Schritte vor und nach dem Modell.

Halten Sie für jeden Anwendungsfall auch fest, was das Modell nie tun soll, etwa Rechtsauskünfte geben oder Diagnosen stellen. Diese Liste liefert die Fangfragen für das Testset.

03Aufbau in Schichten: Bereitstellung, Gateway, Oberfläche

Eine belastbare Einrichtung besteht aus vier Schichten, die sich unabhängig austauschen lassen; wechselt das Modell, sollen Nutzer das nur an der Antwortqualität merken.

• Bereitstellungsschicht: Die Software, die das Modell in den Speicher lädt und Anfragen beantwortet. Ollama ist schnell eingerichtet und reicht für kleine Teams; vLLM bündelt gleichzeitige Anfragen und nutzt den Grafikspeicher bei vielen Nutzern effizienter; llama.cpp ist eine schlanke Variante, die auch ohne Grafikkarte läuft.
• Gateway: Eine Zwischenschicht, die Identitäten prüft, für jede Anfrage das Modell wählt und das Protokoll schreibt. Anwendungen sprechen mit dem Gateway, nie direkt mit dem Modell.
• Dokumentindex: Eine Vektordatenbank, in der Dokumente in Abschnitte zerlegt und als Zahlenvektoren abgelegt werden, damit sie nach Bedeutung statt nach exaktem Wortlaut durchsuchbar sind.
• Oberfläche: Eine selbst betriebene Chatoberfläche für Mitarbeitende oder eine Schaltfläche in einer Fachanwendung, die Sie bereits nutzen.

Weil Ollama und vLLM eine mit der OpenAI API kompatible Schnittstelle bieten, lassen sich viele vorhandene Werkzeuge durch Änderung einer Adresse an das lokale Modell anbinden. In der hybriden Variante leitet das Gateway Anfragen mit personenbezogenen Daten an das lokale Modell und unkritische Aufgaben mit hohem Anspruch an das Schlussfolgern an ein Cloudmodell. Braucht es eigene Masken oder eine Freigabeansicht, planen wir das als individuelle Softwareentwicklung.

04Modellwahl: Größe, Lizenz und Sprachqualität

Das richtige Modell ist nicht der Favorit öffentlicher Ranglisten, sondern das kleinste Modell, das in Ihrem eigenen Testset ausreichend abschneidet. Kleiner heißt weniger Speicher, schnellere Antworten und einfachere Wartung; deshalb wird von klein nach groß gesucht.

• Parameterzahl: Das Maß für die Modellgröße. Mit ihr steigt meist die Qualität, aber ebenso Speicherbedarf und Antwortzeit.
• Lizenz: Offene Modelle gewähren nicht alle dieselben Freiheiten. Qwen3 steht unter Apache 2.0, Llama 3.1 dagegen unter einer eigenen Community License mit Nutzungsrichtlinie und Vorgaben zur Namensnennung.
• Deutsch im Fachkontext: Öffentliche Benchmarks stützen sich stark auf Englisch. Wie ein Modell mit Amtsdeutsch, Vertragssprache oder Fachbegriffen Ihrer Branche umgeht, zeigen nur eigene Beispiele.
• Kontextfenster: Wie viel Text das Modell in einem Durchgang liest; wichtig bei langen Verträgen, und jede zusätzliche Seite kostet Speicher.
• Denkmodus: Manche Modellfamilien, etwa Qwen3, lassen sich so umschalten, dass sie vor der Antwort einen Lösungsweg ausschreiben; die Qualität kann steigen, die Wartezeit steigt sicher.

Das Testset besteht aus echten Fragen je Anwendungsfall, erwarteten Antworten und einigen Fangfragen, die das Modell ablehnen soll. Kandidaten laufen auf derselben Hardware mit denselben Einstellungen; bewertet wird gemeinsam mit jemandem, der die Arbeit täglich macht.

Neben dem Chatmodell wird ein zweites Modell gewählt: das Embeddingmodell, das Dokumente nach Bedeutung durchsuchbar macht. Versteht es Deutsch schlecht, wird die passende Passage nie gefunden. Ein Angebot für ein lokales LLM sollte beide Modelle mit Lizenz und Testergebnis getrennt nennen.

05Grobe Rechnung für die Hardwareplanung

Drei Größen bestimmen den Speicherbedarf: die Modellgewichte, der Kontextspeicher und die Zahl gleichzeitiger Anfragen. Die Überschlagsrechnung zeigt die Richtung; entscheiden sollte die Messung auf der Zielhardware oder einer vergleichbaren.

• Gewichte: Bei 16 Bit Genauigkeit belegt jeder Parameter etwa 2 Byte; ein Modell mit 8 Milliarden Parametern braucht also rund 16 GB allein für die Gewichte.
• Quantisierung: Zahlen werden mit weniger Bits gespeichert. Mit 4 Bit sinkt der Speicher für die Gewichte auf etwa ein Viertel, bei gewissem Qualitätsverlust; ob der für Ihre Arbeit zählt, zeigt das Testset.
• Kontextspeicher: Der Bereich, in dem das Modell den gelesenen Text vorhält. Er wächst mit Textlänge und gleichzeitigen Anfragen und kann auf einem stark genutzten Server mit langen Dokumenten mehr Platz belegen als die Gewichte.
• Geschwindigkeit: Die Zeit bis zum ersten Token zeigt, wie lange jemand auf einen leeren Bildschirm schaut; Token pro Sekunde zeigen, wie flüssig die Antwort läuft.

Drei Varianten sind üblich: eine leistungsfähige Workstation für ein Team, ein GPU Server im eigenen Haus oder ein in Ihrem Namen gemieteter dedizierter Server in einem Rechenzentrum. Im eigenen Haus kommen Strom, Kühlung und unterbrechungsfreie Stromversorgung hinzu; den Jahresverbrauch eines dauerhaft laufenden Servers schätzen Sie mit unserem Rechner für Stromkosten vorab ab.

Beim gemieteten Server gehen Hardwaredefekte und physische Sicherheit auf den Anbieter über, dessen Zugriff auf die Maschine vertraglich begrenzt sein muss. In jedem Fall erleichtert ein Gehäuse mit Platz für eine zweite Grafikkarte späteres Wachstum.

06Datenquellen anbinden, ohne Berechtigungen zu verlieren

Sobald das Modell Firmendokumente liest, liegt das Hauptrisiko bei den Berechtigungen: Niemand darf über das Modell den Inhalt einer Datei erfahren, die er selbst nicht öffnen kann. Quellen anzubinden heißt deshalb nicht, Dateien zu kopieren, sondern Rechte mitzuführen.

Das Verfahren hinter dokumentgestützten Antworten heißt RAG, Retrieval Augmented Generation: Bei einer Frage werden passende Abschnitte im Index gesucht und dem Modell als Quelle mitgegeben. Gefiltert werden muss schon bei dieser Suche; filtert man erst die fertige Antwort, hat das Modell den Inhalt bereits gesehen. Wie ein Assistent mit Quellenangaben aus Firmendokumenten antwortet, beschreiben wir beim KI Wissensassistenten für Unternehmen.

Legen Sie vor jeder Anbindung schriftlich fest:

• Quelle und Verantwortliche: Dateiserver, Dokumentenmanagement, ERP, Mailarchiv oder internes Wiki, jeweils mit der Person, die für den Inhalt zuständig ist.
• Rechteabgleich: Wie Ordner und Gruppenrechte der Quelle in den Index übernommen und wie oft sie abgeglichen werden.
• Löschverhalten: Wie schnell ein in der Quelle gelöschtes oder archiviertes Dokument aus dem Index verschwindet.
• Ausschlüsse: Ordner, die nie in den Index gelangen, etwa Personalakten oder Arbeitsunfähigkeitsbescheinigungen.
• Versionsregel: Welche Fassung als Quelle gilt, wenn alte und neue Versionen eines Dokuments nebeneinander liegen.

07Den Server bei der Einrichtung härten

Ein lokales LLM im eigenen Haus ist nicht automatisch sicherer als ein Cloudkonto; das entscheiden die Festlegungen bei der Einrichtung. Die folgenden Punkte gehören in Ihre Abnahmecheckliste.

• Geprüfte Modelldateien: Modelle stammen nur aus dem offiziellen Repository des Herausgebers, die Prüfsumme jeder Datei wird mit dem veröffentlichten Wert verglichen. Bei kleineren Dateien geht das auch selbst mit unserem Hash Generator.
• Sicheres Dateiformat: safetensors hat Vorrang; Dateien auf Basis von pickle können beim Laden Code ausführen und kommen nie aus unbekannten Quellen.
• Anmeldung vor der Schnittstelle: Ollama lauscht standardmäßig nur auf dem eigenen Rechner und prüft keine Nutzer. Soll es im Netz erreichbar sein, gehört ein Reverse Proxy mit Anmeldung und verschlüsselter Verbindung davor.
• Ausgehender Verkehr: An der Firewall gesperrt und nur in freigegebenen Updatefenstern zu bestimmten Adressen geöffnet.
• Administration: Persönliche Administratorkonten mit zweitem Faktor und eigenem Protokoll.
• Versteckte Anweisungen: Ein Satz wie "ignoriere alle vorherigen Anweisungen" in einem Dokument kann das Modell lenken, bekannt als Prompt Injection. Deshalb erhält das Modell keine Rechte, E-Mails zu senden oder Datensätze zu löschen.

Lassen Sie vor der Abnahme drei Punkte prüfen und protokollieren: Die Schnittstelle ist von außen nicht erreichbar, niemand kann Dokumente einer fremden Abteilung abfragen, und der Server erreicht keine Adressen außerhalb der Freigabeliste.

08Freigaben, Protokollierung und Rückkehr zur Vorversion

Lesen und Entwürfe schreiben darf das Modell frei; alles, was das Unternehmen verlässt oder einen dauerhaften Datensatz ändert, braucht eine menschliche Freigabe. Diese Trennung steht in einer schriftlichen Rechtetabelle, die mit jedem neuen Anwendungsfall nachgeführt wird.

Bei der Protokollierung gibt es zwei Ebenen. Metadaten werden bei jeder Anfrage erfasst: wer, wann, welche Modellversion, wie lange, wie viele Token. Volltexte werden nur zur Fehlersuche, kurzzeitig und mit engem Zugriff gespeichert, weil Anfrage und Antwort selbst personenbezogene Daten oder Geschäftsgeheimnisse enthalten können.

Für Versionen haben sich diese Regeln bewährt:

• Festschreiben: Die produktive Modelldatei wird mit ihrer Prüfsumme dokumentiert, sodass unter gleichem Namen keine andere Datei unbemerkt eingespielt werden kann.
• Versionierte Anweisungen: Der Systemprompt, also die Aufgabenbeschreibung, die das Modell bei jeder Anfrage sieht, wird wie Code versioniert und mit Änderungsnotiz abgelegt.
• Erst das Testset: Neues Modell oder neue Anweisungen durchlaufen zuerst das Testset; fällt das Ergebnis unter die Vorversion, geht nichts live.
• Schneller Rückweg: Die vorherige Modelldatei bleibt auf der Platte; zurück geht es mit einer Konfigurationsänderung statt einer Neuinstallation.

09DSGVO, Betriebsrat und KI Verordnung

Daten im eigenen Netz zu halten, hebt Datenschutzpflichten nicht auf. Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen; Rechte, Protokolle und Netztrennung aus diesem Leitfaden sind deren konkrete Form.

• Gemieteter Server: Der Hoster ist Auftragsverarbeiter und braucht einen Vertrag nach Art. 28 DSGVO, der physischen und entfernten Zugriff, Datenträgervernichtung und Meldung von Vorfällen regelt.
• Server außerhalb des EWR: Dann greifen die Regeln für Übermittlungen in Drittländer nach Kapitel V, also Angemessenheitsbeschluss oder Garantien wie Standardvertragsklauseln.
• Betriebsrat: Protokolliert das System, wer wann was fragt, kann es Verhalten oder Leistung von Beschäftigten erfassen; für solche technischen Einrichtungen sieht § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht vor. Binden Sie den Betriebsrat vor dem Pilotbetrieb ein.
• Kundenkontakt: Spricht das Modell direkt mit Menschen, verlangt Art. 50 der KI Verordnung, dass sie erkennen, mit einem KI System zu interagieren.

Für Unternehmen in Österreich und der Schweiz gelten zusätzlich die jeweiligen nationalen Regeln. Wir liefern die technische Beschreibung; die rechtliche Bewertung übernehmen Ihre Datenschutzbeauftragten und Rechtsberater.

10In sechs Schritten vom Pilot zum Regelbetrieb

Ein lokales LLM sollte mit einem Team und einem begrenzten Dokumentbestand starten und jede weitere Stufe nur nach einem schriftlichen Kriterium erreichen. Die Reihenfolge schiebt Hardwareausgaben auf, bis Messwerte vorliegen.

1. Anwendungsfälle und Testset: Pilotteam wählen, höchstens drei Aufgaben festlegen und das Testset aus echten Beispielen dieser Aufgaben bauen.
2. Messung auf Mietservern: Kandidaten auf einem stundenweise gemieteten GPU Server durch das Testset schicken; Qualität und Geschwindigkeit gemeinsam berichten.
3. Hardwareentscheidung: Anhand der Messung Workstation, eigenen Server oder gemieteten dedizierten Server wählen und bestellen.
4. Gehärtete Installation: Bereitstellungsschicht, Gateway, Anmeldung und Protokollierung einrichten; die Sicherheitscheckliste wird Teil des Abnahmeprotokolls.
5. Pilotbetrieb: Das Team arbeitet einige Wochen mit echten Aufgaben; falsche oder lückenhafte Antworten werden mit einem Klick markiert und ins Testset übernommen.
6. Stufenweiser Ausbau: Ist das Kriterium erfüllt, kommen Abteilungen einzeln hinzu, jeweils mit eigenem Rechteabgleich und kurzer Schulung.

Schreiben Sie das Kriterium vor dem Start auf: Zielwert im Testset, vertretbare Wartezeit zu Spitzenzeiten und regelmäßige Nutzung im Team. Nachträglich formulierte Kriterien passen sich dem Ergebnis an.

11Nutzen messen: Qualität, Tempo, Akzeptanz

Ob sich ein lokales LLM rechnet, entscheiden drei Fragen: Stimmen die Antworten, kommen sie schnell genug, und wird das System tatsächlich genutzt. Ist eine davon schwach, retten die beiden anderen das Projekt nicht.

• Quellentreue: Ob eine Antwort zum zitierten Dokument passt, wird regelmäßig im Testset und an Stichproben aus dem Livebetrieb bewertet.
• Antworten ohne Quelle: Bei Aufgaben, die auf Dokumenten beruhen müssen, werden Antworten ohne Quellenangabe gesondert gezählt; steigt der Anteil, liegt ein Problem im Index oder in den Anweisungen.
• Spitzenzeiten: Beobachtet wird die Wartezeit in den stärksten Stunden, nicht der Durchschnitt; Nutzer beurteilen ein System nach seinen langsamsten Momenten.
• Nutzung je Abteilung: Welche Teams es wie oft pro Woche nutzen; geringe Nutzung bedeutet meist, dass das Modell nie in den Arbeitsablauf eingebaut wurde.
• Zeit pro Vorgang: Einige echte Vorgänge vor dem Pilot stoppen und dieselben am Ende erneut.

Rechnen Sie zudem regelmäßig nach, was dasselbe Volumen über eine Cloud API kosten würde; mit Preisen und der Qualität offener Modelle kann sich das Gleichgewicht verschieben.

12Grenzen und realistische Risiken

Ein lokales Modell bringt Kontrolle über Daten, hat aber Grenzen bei Fähigkeiten und Betrieb. Sprechen Sie diese zu Beginn offen an.

• Erfundene Antworten: Wie jedes Sprachmodell kann auch ein lokales Falsches überzeugend formulieren. Pflicht zur Quellenangabe, die Regel "keine Quelle, keine Antwort" und menschliche Kontrolle bei kritischer Arbeit senken das Risiko, beseitigen es aber nicht.
• Komplexes Schlussfolgern: Bei mehrstufigen Berechnungen, langer Planung oder dem Abgleich vieler Dokumente können offene Modelle hinter den stärksten Cloudmodellen bleiben.
• Wartungsaufwand: Grafiktreiber, Bereitstellungssoftware und Betriebssystem müssen zueinander passen; ein unpassendes Treiberupdate kann den Server lahmlegen.
• Einzelner Ausfallpunkt: Legen Sie vorab fest, was bei einem Serverausfall geschieht: warten, auf eine Ersatzmaschine wechseln oder vorübergehend an ein freigegebenes Cloudmodell leiten.
• Abhängigkeit von einer Person: Kennt nur eine Person die Einrichtung, ist das größte Risiko organisatorisch. Betriebshandbuch und Übergabedokument gehören deshalb zur Lieferung.

Keiner dieser Punkte ist für sich ein Grund aufzuhören, aber jeder braucht eine verantwortliche Person und einen schriftlichen Plan. Planen Sie ein lokales LLM im Budget wie laufende Infrastruktur, nicht wie ein einmaliges Projekt.

13Häufige Fehler beim lokalen LLM

Die meisten Fehler entstehen nicht aus fehlendem Fachwissen, sondern aus der falschen Reihenfolge. Die sechs folgenden Punkte eignen sich als Checkliste beim Prüfen von Angeboten.

• Hardware zuerst kaufen: Die Grafikkarte wird ohne Messung beschafft und das Modell danach passend gemacht. Besser: das Testset auf gemieteter Hardware laufen lassen und nach den Werten beschaffen.
• Ranglisten vertrauen: Ein Modell, das englische Benchmarks anführt, kann an deutscher Vertragssprache scheitern. Besser: Kandidaten mit einem Testset aus eigenen Dokumenten vergleichen.
• Offene Schnittstelle: Die Adresse der Bereitstellungsschicht wird ohne Anmeldung im Netz freigegeben. Besser: Gateway mit Anmeldung und verschlüsselter Verbindung davorschalten.
• Alle Ordner indexieren: Der gesamte Dateiserver landet ohne Rechteabgleich im Index. Besser: Rechte Quelle für Quelle übernehmen und eine schriftliche Ausschlussliste führen.
• Volltexte unbegrenzt speichern: Jede Anfrage und Antwort wird jahrelang aufbewahrt. Besser: Metadaten von kurzlebigen Volltextprotokollen mit engem Zugriff trennen.
• Updates direkt live schalten: Eine neue Modellversion geht ungetestet in Betrieb. Besser: Testsetergebnisse vergleichen und die Vorversion für den Rückweg behalten.

14Fragen an das umsetzende Team und nächster Schritt

Ein gutes Angebot erklärt die Messmethode, bevor es ein Modell nennt, und die Anwendungsfälle, bevor es Hardware nennt. Stellen Sie den Teams, mit denen Sie sprechen, diese Fragen und bitten Sie um schriftliche Antworten:

• Auf welchem Testset und welcher Umgebung beruht die Hardwareempfehlung?
• Auf wessen Namen laufen Server, Konten, Konfigurationsdateien und Modelldateien?
• Welche Betriebshandbücher erhalten wir, damit unser Team die Einrichtung ohne Sie weiterführen kann?
• Wie sehen Wartungsplan und Rückweg bei Modellupdates, Treiberupdates und Sicherheitspatches aus?
• Was ändert sich in unseren Anwendungen, wenn später für einzelne Aufgaben ein Cloudmodell hinzukommt?

Wir setzen solche Projekte im Rahmen unserer KI Automatisierung um: zuerst Anwendungsfälle und Testset, dann Messung, danach Hardwareentscheidung und gehärtete Installation. Hardware oder Servermiete zahlen Sie direkt an den Lieferanten, und alle Konten und Dateien gehen an Ihr Unternehmen.

Einstiegsoptionen nach Umfang finden Sie unter Preise für KI Automatisierung. Nennen Sie uns über das Kontaktformular drei echte Aufgaben für das Modell und die beteiligten Dokumentarten; wir schlagen passende Modellfamilien und Hardwareoptionen vor und senden ein schriftliches Angebot.