Lokale KI im Unternehmen: Wann sich ein lokales LLM lohnt

Lokale KI lohnt sich für Unternehmen vor allem dann, wenn Daten das Haus nicht verlassen dürfen, wenn die Aufgaben klar umrissen sind und wenn das Anfragevolumen hoch und gleichmäßig ist. Für komplexe Agenten, lange Dokumente und schwankende Nutzung ist ein Cloud-Modell mit EU-Vertrag meist günstiger und besser. In der Praxis landen die meisten Mittelständler bei einer hybriden Lösung: sensible Daten und Routineaufgaben lokal, anspruchsvolle Aufgaben mit unkritischen Daten über eine API.

Das klingt nach einer einfachen Faustregel, und im Kern ist es auch eine. Die Schwierigkeit liegt im Detail: Welche Daten sind wirklich sensibel? Welche Modellgröße reicht für Ihren Anwendungsfall? Und ab welchem Volumen rechnet sich eigene Hardware überhaupt? Wir bei TAISC bauen KI-Systeme für den Mittelstand, mal mit Cloud-Modellen, mal auf der Infrastruktur unserer Kunden. In diesem Beitrag ordnen wir ehrlich ein, wann sich lokale KI im Unternehmen lohnt, was sie kostet und wo die Grenzen liegen.

Was bedeutet lokale KI überhaupt?

Lokale KI bedeutet, dass ein Sprachmodell auf Hardware läuft, die Sie selbst kontrollieren: ein Laptop, eine Workstation, ein Server im eigenen Rechenzentrum oder eine exklusiv gemietete Maschine. Eingaben, Dokumente und Antworten verlassen dabei nicht Ihre Infrastruktur. Fachlich spricht man von einem lokalen LLM.

Möglich wird das durch sogenannte Open-Weight-Modelle. Deren Gewichte, also das eigentliche „Wissen“ des Modells, sind veröffentlicht und dürfen heruntergeladen werden. Bekannte Modellfamilien sind Llama, Mistral, Qwen, Gemma, DeepSeek und gpt-oss. Betrieben werden sie mit einer Laufzeitumgebung wie Ollama, LM Studio, llama.cpp oder vLLM, die das Modell lädt und über eine Schnittstelle für andere Anwendungen bereitstellt.

Wichtig ist eine Abgrenzung, die in Gesprächen oft verschwimmt: Lokale KI ist nicht dasselbe wie On-Premise-Hosting einer KI-Anwendung. Eine Anwendung kann vollständig auf Ihren Servern laufen und trotzdem für die eigentliche Textgenerierung ein Cloud-Modell aufrufen. Umgekehrt kann ein lokales Modell auch auf einem gemieteten GPU-Server in einem deutschen Rechenzentrum stehen. Entscheidend ist die Frage, wo welche Daten verarbeitet werden.

Wann lohnt sich ein lokales LLM im Unternehmen?

Aus unseren Projekten sehen wir vier Situationen, in denen lokale KI klar die bessere Wahl ist.

Daten dürfen das Haus nicht verlassen. Konstruktionsdaten, Patientendaten, Personalakten, Mandantenunterlagen oder Verträge mit strengen Vertraulichkeitsklauseln: Wenn Ihre Rechtsabteilung oder Ihr Kunde eine Verarbeitung bei Dritten ausschließt, ist ein lokales Modell oft die einzige Möglichkeit, KI überhaupt einzusetzen. Das ist der häufigste und stärkste Grund.

Die Aufgabe ist klar umrissen. Klassifizieren, Daten aus Dokumenten extrahieren, Texte zusammenfassen, Antworten aus gefundenen Textstellen formulieren: Für solche Aufgaben reichen aktuelle Open-Weight-Modelle mittlerer Größe heute oft aus. Ein Modell, das in einem RAG-System nur formulieren muss, was die Suche gefunden hat, braucht keine Spitzenleistung im freien Denken.

Das Volumen ist hoch und gleichmäßig. Wenn ein System rund um die Uhr Dokumente verarbeitet, etwa Eingangsrechnungen, Servicemeldungen oder Logdateien, wird die Hardware gut ausgelastet. Dann sinken die Kosten pro Anfrage deutlich unter API-Preise.

Unabhängigkeit ist strategisch wichtig. Preisänderungen, geänderte Nutzungsbedingungen oder abgekündigte Modelle betreffen lokale Systeme nicht. Ein Modell, das heute auf Ihrem Server läuft, läuft dort auch in drei Jahren noch genauso. Für Prozesse, die über Jahre stabil funktionieren müssen, ist das ein echtes Argument.

Wann ist die Cloud die bessere Wahl?

Genauso ehrlich muss man sagen, wo lokale KI an Grenzen stößt. In diesen Fällen raten wir in der Regel zur Cloud, idealerweise mit EU-Datenresidenz und einem Vertrag, der das Training mit Ihren Daten ausschließt.

• Komplexe Agenten und mehrstufiges Denken. Die stärksten Modelle für Planung, Werkzeugnutzung und lange Aufgabenketten sind meist nur als Cloud-Dienst verfügbar. Wer KI-Agenten bauen will, die selbstständig mehrere Systeme bedienen, fährt mit einem Spitzenmodell besser.
• Lange Dokumente und große Kontexte. Lokale Modelle können zwar oft lange Kontexte verarbeiten, brauchen dafür aber sehr viel Grafikspeicher. Ganze Vertragswerke in einem Zug zu analysieren, ist in der Cloud deutlich einfacher.
• Geringes oder stark schwankendes Volumen. Wenn ein Assistent ein paar Hundert Anfragen pro Tag beantwortet, steht eine teure GPU die meiste Zeit still. Eine API rechnet nur ab, was tatsächlich genutzt wird.
• Kein Betriebs-Know-how im Haus. Ein lokales Modell ist Infrastruktur. Es braucht Updates, Monitoring, Zugriffskontrolle und jemanden, der sich kümmert, wenn es um drei Uhr nachts nicht antwortet.

Lokal, EU-Cloud oder US-Cloud: Der direkte Vergleich

Zwischen „alles in der US-Cloud“ und „alles im eigenen Keller“ gibt es Abstufungen. Für die meisten Entscheidungen reichen drei Varianten.

Die EU-Cloud ist dabei oft der unterschätzte Mittelweg. Große Anbieter bieten ihre Modelle inzwischen in europäischen Rechenzentren an, und mit Auftragsverarbeitungsvertrag und klarer Datenklassifizierung ist das für viele Anwendungsfälle ausreichend. Unser IntranetGPT für einen mittelständischen IT-Dienstleister läuft zum Beispiel auf Azure: Firmenwissen aus SharePoint wird per Chat zugänglich, ohne dass das Modell mit den Daten trainiert wird. Für interne Richtlinien und Prozessdokumente war das die passende Abwägung.

Welche Hardware braucht lokale KI?

Der größte Kostenblock ist die Hardware für die Inferenz, also für das Beantworten von Anfragen. Entscheidend ist dabei weniger die Rechenleistung als der Speicher, auf den der Grafikprozessor zugreifen kann: Das Modell muss vollständig hineinpassen, plus Platz für den Kontext der laufenden Anfragen. Durch Quantisierung, eine komprimierte Speicherung der Modellgewichte, passen größere Modelle auf kleinere Hardware, mit leichten Abstrichen bei der Qualität.

Lange hieß lokale KI deshalb: teure Grafikkarten mit viel Grafikspeicher. Das hat sich verändert. Inzwischen gibt es kompakte Geräte, bei denen CPU und GPU einen großen gemeinsamen Speicher nutzen. Damit laufen Modelle, für die man vor zwei Jahren noch einen Server gebraucht hätte, auf dem Schreibtisch. Als Orientierung, Stand Oktober 2026:

• Apple MacBook Pro und Mac Studio: Apple-Rechner mit M-Chips teilen sich den Arbeitsspeicher zwischen CPU und GPU. Ein MacBook Pro mit M5 Max und 128 GB reicht für Modelle der 70-Milliarden-Klasse. Der Mac Studio mit M5 Ultra lässt sich mit bis zu 512 GB ausstatten und schafft damit auch sehr große Open-Weight-Modelle. Die US-Listenpreise beginnen laut Apple bei 2.499 US-Dollar (M5 Max) und 5.499 US-Dollar (M5 Ultra), in Deutschland liegen sie höher, und große Speicherausbauten kosten deutlich mehr. Für Pilotprojekte und Einzelplätze ist das oft der einfachste Einstieg.
• Nvidia DGX Spark: Ein Mini-Rechner mit Nvidias GB10-Chip und 128 GB gemeinsamem Speicher, den neben Nvidia auch Hersteller wie Dell, HP, Lenovo, ASUS und Acer anbieten. Laut Händlerangaben vom September 2026 kosten die 128-GB-Modelle in Deutschland etwa 5.000–7.000 Euro netto, eine Variante mit 64 GB ist angekündigt. Zwei Geräte lassen sich koppeln, laut Nvidia für Modelle bis rund 405 Milliarden Parameter. Der Vorteil ist das Nvidia-Software-Ökosystem, das auch auf großen Servern läuft.
• GPU-Server: Sobald viele Mitarbeitende gleichzeitig mit dem Modell arbeiten oder große Dokumentenmengen automatisch verarbeitet werden, braucht es Server mit Rechenzentrums-GPUs. Diese liefern deutlich mehr Durchsatz, liegen nach unserer Schätzung aber schnell im sechsstelligen Bereich.

Ein Punkt, der bei Datenblättern oft untergeht: Wie schnell ein Modell antwortet, hängt stark von der Speicherbandbreite ab. Ein Mac Studio mit M5 Ultra kommt laut Apple auf 1,2 TB/s, ein DGX Spark auf rund 273 GB/s. Der Spark hat dafür mehr Rechenleistung für das Einlesen langer Eingaben. Welches Gerät für Ihren Fall schneller ist, zeigt nur ein Test mit Ihrem Modell und Ihren Aufgaben. Beachten Sie außerdem: Die Speicherpreise sind 2026 deutlich gestiegen, Nvidia hat den Spark zum Beispiel im Februar 2026 von 3.999 auf 4.699 US-Dollar verteuert. Holen Sie aktuelle Angebote ein, bevor Sie planen.

Dazu kommen Strom, Platz und vor allem Arbeitszeit für Einrichtung, Updates und Betrieb. Eine Alternative ohne eigene Hardware ist ein dedizierter GPU-Server bei einem deutschen Hoster: Die Daten bleiben in einer Umgebung, die nur Sie nutzen, und Sie zahlen monatlich statt einmalig.

Rechnet sich lokale KI? Ein ehrliches Rechenbeispiel

Die Kostenfrage wird oft falsch herum gestellt. Viele erwarten, dass lokale KI günstiger ist, weil keine Gebühren pro Anfrage anfallen. Ob das stimmt, hängt fast ausschließlich vom Volumen ab.

Ein Anhaltspunkt aus unserem Projekt Logify: Dort liegen die Modellkosten bei rund 1 US-Dollar pro 100 Abfragen. Angenommen, ein Support-Team stellt 10.000 Anfragen im Monat. Dann kostet das Modell über eine API rund 100 US-Dollar monatlich, mit neueren, günstigeren Modellen eher weniger. Ein Mac Studio oder DGX Spark für rund 6.000 Euro hätte sich bei diesem Volumen erst nach etwa fünf Jahren amortisiert, Betriebsaufwand noch nicht eingerechnet.

Bei 500.000 Anfragen im Monat sieht die Rechnung völlig anders aus. Dann reden wir über mehrere Tausend Euro API-Kosten pro Monat, und eigene Hardware rechnet sich nach unserer Schätzung oft innerhalb eines Jahres. Das gilt besonders für automatisierte Prozesse, die große Mengen an Dokumenten verarbeiten, nicht für Chat-Assistenten mit gelegentlicher Nutzung.

Die ehrliche Konsequenz: Für die meisten Mittelständler ist lokale KI keine Sparmaßnahme, sondern eine Entscheidung für Datenkontrolle und Unabhängigkeit. Wenn das der Grund ist, ist sie oft jeden Euro wert. Wenn der einzige Grund die erhofften Einsparungen sind, lohnt sich ein zweiter Blick auf die Zahlen.

Wie sieht das in der Praxis aus? Logify als hybride Lösung

Ein Beispiel aus unserer Arbeit zeigt, dass die Entscheidung selten „alles lokal“ oder „alles Cloud“ lautet. Für BCT, ein Softwareunternehmen für Industriesoftware, haben wir mit Logify ein System gebaut, das im IT-Support Logdateien analysiert, Fehler erkennt und über RAG passende Stellen aus rund 500 MB technischer Dokumentation heraussucht. Daraus entstehen priorisierte Lösungsvorschläge für das Support-Team.

Begonnen hat Logify als Prototyp, der in 48 Stunden auf einem Hackathon entstand und prämiert wurde. Der längere Teil war der Weg in den Betrieb. Seit April 2026 laufen Anwendung und Indexierung On-Premise auf der Infrastruktur des Kunden: Der Dokumentenbestand und der Suchindex bleiben im Haus. Das Sprachmodell selbst nutzen wir über die OpenAI-API in der Cloud. An das Modell geht also nur die jeweilige Anfrage mit den relevanten Ausschnitten, nicht der gesamte Bestand. Daher stammen auch die oben genannten Modellkosten.

Drei Erkenntnisse aus dem Projekt lassen sich gut übertragen:

1. Die Architektur entscheidet mehr als das Modell. Weil die Suche die relevanten Stellen liefert, muss das Modell vor allem sauber formulieren und ein festes Ausgabeformat einhalten. Genau das können auch kleinere lokale Modelle gut, wenn die Ausgaben validiert werden. Logify ist deshalb so gebaut, dass sich das Cloud-Modell gegen ein lokales tauschen ließe, ohne den Rest des Systems anzufassen.
2. On-Premise heißt nicht, dass alles lokal laufen muss. Bei Logify laufen Anwendung und Index beim Kunden, das Modell in der Cloud. Welche Komponente wo läuft, ist eine bewusste Entscheidung pro Datenklasse, kein Glaubensbekenntnis.
3. Der Betrieb ist der eigentliche Aufwand. Installation, Zugriffsrechte, Updates und Monitoring auf fremder Infrastruktur brauchen mehr Abstimmung als der Prototyp. Das sollte von Anfang an im Plan stehen.

Das geschätzte Potenzial liegt bei über 1.000 Support-Stunden pro Jahr, bei konservativ 30 Minuten Ersparnis pro Fall. Belastbare Messwerte aus dem laufenden Betrieb stehen noch aus. Wie RAG-Systeme technisch aufgebaut sind und wo sie typischerweise scheitern, beschreiben wir ausführlich im Beitrag RAG-System aufbauen.

Ist lokale KI automatisch DSGVO-konform?

Nein, aber sie macht es deutlich einfacher. Wenn keine Daten an Dritte übertragen werden, entfallen Auftragsverarbeitung mit einem Modellanbieter und die Frage nach Drittlandtransfers. Die übrigen Pflichten der DSGVO bleiben aber bestehen: Sie brauchen eine Rechtsgrundlage für die Verarbeitung, ein Berechtigungskonzept, Löschfristen und eine Protokollierung, die selbst wiederum datenschutzkonform sein muss.

Ein häufig übersehener Punkt sind Zugriffsrechte. Ein lokales Modell, das auf alle Dokumente des Unternehmens zugreift, kann Mitarbeitenden Inhalte zeigen, die sie im Dateisystem nie hätten öffnen dürfen. Die Rechte müssen deshalb bis in die Suche durchgereicht werden, egal ob das Modell lokal oder in der Cloud läuft. Auch der EU AI Act stellt je nach Anwendungsfall Anforderungen, die unabhängig vom Standort des Modells gelten.

Wie starten Sie mit lokaler KI?

Wir empfehlen einen schrittweisen Weg, der früh zeigt, ob sich der Aufwand lohnt.

1. Daten klassifizieren. Bevor es um Modelle geht, klären Sie, welche Daten in welche Klasse fallen: öffentlich, intern, vertraulich, streng vertraulich. Oft zeigt sich dabei, dass nur ein Teil der Anwendungsfälle wirklich lokal laufen muss.

2. Einen konkreten Anwendungsfall wählen. Nicht „lokale KI einführen“, sondern zum Beispiel „Eingangsrechnungen automatisch prüfen“ oder „Servicehandbücher durchsuchbar machen“. Ein klarer Fall macht Qualität messbar.

3. Mit echten Aufgaben testen. Stellen Sie ein Testset aus 50–100 realen Beispielen zusammen und vergleichen Sie ein lokales Modell mit einem Cloud-Modell. Erst dieser Vergleich zeigt, ob die kleinere Variante für Ihren Fall reicht. Für erste Tests genügt oft ein Laptop mit Ollama.

4. Betrieb planen. Wer kümmert sich um Updates, Monitoring und Ausfälle? Gibt es eine eigene Maschine, einen gemieteten GPU-Server oder eine bestehende Server-Infrastruktur? Diese Fragen entscheiden über die Gesamtkosten mehr als der Kaufpreis der Hardware.

5. Hybrid denken. Bauen Sie die Anwendung so, dass das Modell austauschbar bleibt. Dann können Sie sensible Fälle lokal verarbeiten, anspruchsvolle Fälle mit unkritischen Daten an ein Cloud-Modell geben und später wechseln, wenn sich Modelle oder Preise ändern.

Genau bei diesen Schritten unterstützen wir Unternehmen, von der Datenklassifizierung über den Modellvergleich bis zur Installation auf Ihrer Infrastruktur. Einen Überblick über unsere Leistungen finden Sie unter Services.

Häufige Fragen

Was ist lokale KI?

Lokale KI bezeichnet Sprachmodelle und KI-Anwendungen, die auf eigener oder exklusiv genutzter Hardware laufen, statt über die Cloud eines Anbieters. Eingaben und Daten verlassen dabei nicht die eigene Infrastruktur. Möglich wird das durch Open-Weight-Modelle wie Llama, Mistral, Qwen oder gpt-oss.

Sind lokale Modelle so gut wie ChatGPT oder Claude?

Für klar umrissene Aufgaben wie Zusammenfassen, Klassifizieren, Extrahieren oder Antworten in RAG-Systemen reichen aktuelle Open-Weight-Modelle oft aus. Bei komplexem Denken, langen Aufgabenketten und Agenten liegen die führenden Cloud-Modelle meist noch vorn. Ein Test mit echten Aufgaben zeigt, was für Ihren Fall reicht.

Welche Hardware brauche ich für ein lokales LLM?

Für kleine Modelle reicht ein aktueller Rechner mit 32 GB Arbeitsspeicher. Für größere Modelle eignen sich inzwischen kompakte Geräte mit viel gemeinsamem Speicher, etwa ein MacBook Pro oder Mac Studio mit 128 GB und mehr oder ein Nvidia DGX Spark, der in Deutschland laut Händlerangaben bei etwa 5.000–7.000 Euro netto liegt (Stand September 2026). Für viele gleichzeitige Nutzer braucht es Server mit Rechenzentrums-GPUs.

Ist lokale KI günstiger als die Cloud?

Nur bei hohem und gleichmäßigem Volumen. Bei einigen Tausend Anfragen im Monat ist eine API meist deutlich günstiger, weil eigene Hardware lange stillsteht. Bei Hunderttausenden Anfragen, etwa in automatisierten Dokumentenprozessen, kann sich eigene Hardware nach unserer Schätzung innerhalb eines Jahres rechnen.

Was ist Ollama und eignet es sich für Unternehmen?

Ollama ist ein kostenloses Open-Source-Werkzeug, mit dem sich Open-Weight-Modelle mit wenigen Befehlen lokal ausführen lassen. Für Tests und Einzelplätze ist es ideal. Für den produktiven Betrieb mit vielen gleichzeitigen Nutzern setzen wir eher auf Laufzeitumgebungen wie vLLM, ergänzt um Zugriffskontrolle und Monitoring.

Kann man lokale und Cloud-KI kombinieren?

Ja, und das ist in der Praxis der häufigste Weg. Sensible Daten und Routineaufgaben verarbeitet ein lokales Modell, anspruchsvolle Aufgaben mit unkritischen Daten gehen an ein Cloud-Modell mit EU-Vertrag. Voraussetzung ist eine Architektur, in der das Modell austauschbar ist, und eine klare Klassifizierung der Daten.

Sie überlegen, ob ein lokales LLM für Ihr Unternehmen sinnvoll ist, oder wollen einen konkreten Anwendungsfall mit lokalem und Cloud-Modell vergleichen? Wir prüfen mit Ihnen, welche Variante zu Ihren Daten, Ihrem Volumen und Ihrem Team passt. Buchen Sie ein unverbindliches Erstgespräch.