Viele mittelständische Unternehmen starten 2025/26 mit lokalem LLM-Betrieb – und scheitern leise. Nicht mit einem lauten Projektabbruch, sondern so: Das Modell läuft noch, aber niemand nutzt es mehr. Der Server steht in einer Ecke. Die Antwortqualität hat sich verschlechtert, seit das Basismodell ein Update bekommen hat, das nie eingespielt wurde. Dieses Muster ist kein Einzelfall.
Warum Local-LLM überhaupt attraktiv wirkt
Die Ausgangslage ist nachvollziehbar. Typisches Beispiel: ein Steuerberater mit 18 Mitarbeitenden, der Mandantendaten keinesfalls an externe Server schicken will. Oder ein Maschinenbauer mit 60 Mitarbeitenden, dessen IT-Leiter die monatlichen OpenAI-Kosten nicht gut schlafen lässt. Local-LLM löst beide Probleme scheinbar elegant – Daten bleiben im Haus, Kosten sind kalkulierbar, kein Vendor-Lock-in.
Das stimmt alles. Aber es stimmt nur für den Moment der Inbetriebnahme.
Das Hardware-Problem: Die Rechnung geht nicht auf
Ein brauchbares Modell – sagen wir Llama 3.1 70B oder Mistral Large – braucht Hardware, die KMUs selten im Bestand haben. Zwei NVIDIA-GPUs mit je 48 GB VRAM kosten neu rund 20.000–30.000 Euro. Dazu kommen Server-Chassis, Kühlung, unterbrechungsfreie Stromversorgung, Wartungsvertrag.
Alternativ: kleinere Modelle, 7B oder 13B Parameter, laufen auch auf Consumer-Hardware. Aber die Antwortqualität ist spürbar schwächer. Für einfache Textzusammenfassungen reicht das. Für komplexe Vertragsanalysen oder mehrschrittige Auswertungen nicht.
Das KMU kauft also entweder zu viel Hardware für den tatsächlichen Use-Case – oder zu wenig für die erwartete Qualität. Beides führt zu Enttäuschung.
Total Cost of Ownership, ehrlich gerechnet:
- Hardware: 15.000–40.000 Euro (einmalig)
- Strom: Ein GPU-Server mit zwei A100 zieht 600–900 Watt unter Last. Bei 8 Stunden Betrieb täglich und 0,25 Euro/kWh: 400–650 Euro pro Jahr – unter optimistischen Annahmen
- IT-Betreuung: 2–4 Stunden pro Woche für Updates, Monitoring, Nutzeranfragen; bei einem internen IT-Mitarbeiter mit 60.000 Euro Jahresgehalt sind das 3.000–6.000 Euro pro Jahr
- Modell-Updates: Dazu gleich mehr
Dem gegenüber stehen Cloud-API-Kosten von typischerweise 200–800 Euro pro Monat für einen KMU-Betrieb mittlerer Intensität. Break-even bei lokaler Hardware liegt selten unter drei Jahren – wenn alles funktioniert.
Das Modell-Pflege-Problem: Die versteckte Vollzeitstelle
Hier scheitern die meisten Projekte. Nicht an der Hardware, sondern an der Erwartung, dass ein lokales Modell läuft wie ein ERP-System: einmal installiert, läuft es Jahre.
LLMs sind keine Datenbanken. Die Modelllandschaft bewegt sich schnell. Was im Februar 2026 state-of-the-art ist, ist im August 2026 zwei Generationen veraltet. Konkurrenzmodelle überholen, Sicherheitslücken werden bekannt, neue Quantisierungsformate verbessern die Effizienz erheblich.
Ein lokales Modell nicht zu aktualisieren bedeutet:
- Sicherheitsprobleme bleiben offen (Jailbreaks, Prompt-Injection-Anfälligkeit)
- Die Antwortqualität stagniert, während Nutzer bessere Ergebnisse von ChatGPT oder Claude kennen
- Integration mit neuen Tools (z. B. neue RAG-Frameworks, Embedding-Modelle) funktioniert nicht mehr
Ein Modell-Update ist kein „Plugin installieren”. Es bedeutet: neues Modell herunterladen (50–150 GB), testen, Prompts anpassen, Quantisierungsformat prüfen, Serving-Framework aktualisieren, Nutzer informieren. Realistisch: 8–20 Stunden pro Update-Zyklus.
Wer macht das im KMU? In den meisten Fällen niemand. Der IT-Leiter hat genug mit der ERP-Pflege. Ein externer Dienstleister kostet 120–180 Euro pro Stunde. Plötzlich ist der Kostenvorteil gegenüber der Cloud weg.
Das Organisations-Problem: Kein Mensch übernimmt Verantwortung
Häufiges Muster: Das Projekt startet mit Enthusiasmus aus der Geschäftsführung oder einer technisch affinen Führungskraft. Die Pilotphase läuft gut. Dann kommt der Alltag.
Niemand wurde formal zum „LLM-Administrator” ernannt. Niemand hat Budget für Wartung bekommen. Niemand weiß, was passiert, wenn das Modell falsche Antworten liefert und ein Mitarbeiter darauf vertraut hat.
Dazu kommt: Local-LLM-Projekte haben selten klare Erfolgsmessung. „Die Kollegen nutzen es” ist kein Ziel. Ohne Metriken – Nutzungsfrequenz, Zeitersparnis, Fehlerquote – gibt es keine Rechtfertigung für laufende Investitionen. Und ohne Rechtfertigung stirbt das Budget beim ersten Sparrunde.
Wann Local-LLM im KMU trotzdem funktioniert
Es gibt Use-Cases, in denen lokaler Betrieb sinnvoll ist. Aber die Bedingungen sind enger, als die meisten annehmen.
Kriterium 1: Datenschutz ist existenziell, nicht nur wünschenswert. Kanzleien, Arztpraxen, Unternehmen mit Geschäftsgeheimnissen in regulierten Branchen. Hier rechtfertigt der Compliance-Wert die Mehrkosten.
Kriterium 2: Volumen ist hoch genug. Wer täglich 500+ LLM-Anfragen hat, erreicht den Break-even schneller. Für ein Unternehmen mit 15 gelegentlichen Nutzern rechnet sich lokale Hardware fast nie.
Kriterium 3: Interne technische Kapazität ist vorhanden. Nicht als Nebenaufgabe, sondern als fixer Bestandteil einer IT-Rolle. Mindestens 20 % eines IT-Vollzeitäquivalents, realistisch eher 30 %.
Kriterium 4: Das Modell passt zum Use-Case ohne ständige Updates. Spezialisierte, feingetunete Modelle für einen eng definierten Prozess – z. B. Rechnungsdaten extrahieren – sind stabiler als General-Purpose-Modelle, die für alles genutzt werden sollen.
Treffen alle vier Kriterien zu? Dann ist Local-LLM eine ernsthafte Option. Treffen zwei oder weniger zu? Mein Rat: Cloud-API mit durchdachtem Datenschutzkonzept.
Die Alternative, die kaum jemand prüft: Hybrid-Ansatz
Zwischen „alles lokal” und „alles Cloud” gibt es Zwischenwege, die für KMUs oft besser passen.
Beispiel: Sensitive Dokumente werden lokal vorverarbeitet – Anonymisierung, Extraktion relevanter Felder – bevor sie an eine Cloud-API gehen. Das lokale Modell ist klein (7B, läuft auf einem normalen Server) und macht nur das, was es gut kann. Die eigentliche Inferenz passiert in der Cloud.
Oder: Daten bleiben in einer europäischen Private-Cloud (Azure, AWS EU-Regionen, Hetzner) mit eigenem Tenant und Data-Processing-Agreement. Kein US-Datentransfer, volle DSGVO-Konformität, keine Hardware-Verantwortung.
Diese Optionen werden in der Diskussion oft übergangen, weil „lokal” einfacher zu erklären ist. In der Praxis sind sie für die meisten KMUs das bessere Modell.
Was vor dem Start zu klären ist
Vor jedem Local-LLM-Projekt sollten diese Fragen beantwortet sein:
- Wer ist namentlich verantwortlich für Modell-Updates, Monitoring und Nutzersupport?
- Wie hoch ist das jährliche Budget für Wartung – Hardware, Software, Personalzeit?
- Was ist der Mindest-Nutzungsumfang, bei dem das Projekt als erfolgreich gilt?
- Was passiert, wenn das Modell falsche Antworten liefert und jemand darauf vertraut?
- Wann wird das Projekt evaluiert – und wer entscheidet über Weiterführung oder Abbruch?
Kann das Unternehmen alle fünf Fragen klar beantworten? Dann kann ein Pilotprojekt starten. Kann es das nicht? Dann scheitert das Projekt nicht am Modell, sondern an fehlender Organisationsreife – und das ist kein technisches Problem.
Fazit
Local-LLM ist eine legitime Option. Aber die Entscheidung dafür gehört auf dieselbe Stufe wie der Kauf einer Produktionsmaschine: Anschaffungskosten sind ein Posten, Betriebskosten und Personalaufwand sind zwei weitere, und Opportunitätskosten – was passiert, wenn das System nicht gepflegt wird – sind der entscheidende dritte.
Die meisten Projekte sterben, weil nur der erste Posten wirklich durchgerechnet wurde.