Lokale LLMs: Wann sich KI auf dem eigenen Server wirklich lohnt

Noch vor einem Jahr drehte sich die Diskussion über lokale LLMs oft um Demos, Heim-GPUs und die Begeisterung darüber, dass ein Modell überhaupt ohne Cloud läuft. Im Jahr 2026 ist das Thema deutlich erwachsener geworden. Unternehmen haben inzwischen API-Rechnungen gesammelt, Compliance-Fragen auf dem Tisch und genug Erfahrung mit der Abhängigkeit von externen Anbietern. Deshalb lautet die eigentliche Frage heute nicht mehr: „Kann man ein Modell selbst betreiben?“, sondern: In welchen Szenarien ist das tatsächlich wirtschaftlicher und sicherer, als sich nur auf OpenAI, Google oder Anthropic zu verlassen?

Wichtig ist, gleich etwas Pathos aus der Debatte zu nehmen. Lokale Modelle haben die Cloud nicht „getötet“, und Cloud-AI-Plattformen sind auch nicht plötzlich nutzlos geworden. Im Gegenteil: OpenAI, Anthropic und Google betonen für ihre kommerziellen Produkte jeweils ausdrücklich, dass sie Geschäftsdaten und API-Traffic standardmäßig nicht zum Training ihrer Modelle verwenden. (6 8) Der Streit dreht sich also nicht mehr um die primitive Vorstellung, dass „in der Cloud alles abfließt“. Es geht um Kontrolle über den Perimeter, planbare Kosten, Latenz, Integration in interne Systeme und um die Frage, wie viel betriebliche Komplexität ein Unternehmen selbst tragen will.

Warum Unternehmen sich überhaupt von Cloud-AI wegbewegen

Meistens gibt es dafür nicht nur einen Grund, sondern mehrere zugleich.

Der erste und bodenständigste Grund ist die Ökonomie. Solange die Last gering ist, ist eine Cloud-API fast immer bequemer. Aber sobald ein konstanter Strom an Requests, lange Kontexte, interne RAG-Szenarien und Dutzende Mitarbeitende dazukommen, die täglich Dokumente durch ein Modell schicken, wirkt die Rechnung nicht mehr wie „ein kleiner Posten auf der Karte“. Dann sieht der fixe Preis eigener Hardware plötzlich weniger nach Ingenieurslaune aus und mehr nach einer Möglichkeit, das Budget planbar zu machen.

Der zweite Grund ist Kontrolle. Wenn das Modell innerhalb des eigenen Perimeters läuft, lassen sich Daten, Logs, Vektorindizes und Integrationen leichter nahe an der restlichen Infrastruktur halten. Für Branchen mit Residency-Anforderungen, internen Richtlinien und segmentierten Netzwerken ist das oft wichtiger als die bloße Kostenfrage.

Der dritte Grund ist die Abhängigkeit von einem externen Anbieter. In der Cloud kauft man nicht nur die Intelligenz eines Modells, sondern auch das SLA eines anderen, dessen Limits, dessen Roadmap und dessen geänderte Bedingungen. Für ein experimentelles Produkt ist das normal. Für eine interne AI-Schicht, die schon Teil operativer Prozesse ist, wünschen sich viele Unternehmen weniger Abhängigkeit.

Ollama, LM Studio und wie ein lokaler Stack heute tatsächlich aussieht

Heute sieht ein lokaler Stack nicht mehr aus wie eine Sammlung seltsamer Shell-Skripte aus Stack Overflow.

Ollama ist zu einer praktischen Möglichkeit geworden, einen lokalen oder serverseitigen Runtime für Modelle bereitzustellen, Modelle über CLI und API zu betreiben, GGUF-Modelle zu importieren und Laufzeitparameter zu steuern. In der Dokumentation von Ollama steht ausdrücklich, dass der Dienst bei lokalem Betrieb weder Prompts noch Daten sieht und dass sich Cloud-Funktionen bei Bedarf komplett deaktivieren lassen. Dort wird auch beschrieben, wie sich der Dienst in Bezug auf CPU, GPU, VRAM, Queues und parallele Requests verhält. (1)

LM Studio löst ein benachbartes Problem. Es ist eine komfortable Desktop-Umgebung zum Bewerten von Modellen und zugleich ein lokaler API-Server, der sich auf localhost starten lässt. Die Dokumentation zeigt den Start über die GUI oder mit lms server start, OpenAI-kompatible Schnittstellen sowie eine separate Konfiguration des API-Tokens für den Zugriff. (3) Vereinfacht gesagt eignet sich LM Studio sehr gut für schnelles Model-Screening und Desktop-Szenarien, während Ollama häufiger dort besser passt, wo ein stärker serverorientierter Betrieb gefragt ist.

In der Praxis ist genau das ein erwachsener lokaler Stack: Runtime, Modell, Dokumenten- oder Vektorspeicher, saubere Authentifizierung, Monitoring, Zugriffsbeschränkungen und ein nachvollziehbarer Weg zur Aktualisierung der Weights. Das Schwierige ist nicht, einmal eine Antwort im Terminal zu erzeugen. Das Schwierige ist, diese Antwort später sicher und planbar in einen echten Arbeitsprozess einzubauen.

Welche Modelle man sich realistisch ansehen sollte: Llama, Mistral, Mixtral

Für die meisten Teams beginnt die Auswahl nicht bei „dem intelligentesten Modell der Welt“, sondern bei der Art der Aufgabe.

Wenn ein universeller Einstieg gefragt ist, schauen viele zuerst auf die Familie Llama. Sie hat ein starkes Ökosystem, viele kompatible Runtimes, zahlreiche quantisierte Builds und eine nachvollziehbare technische Entwicklung von kleinen zu großen Modellen. Meta betont in der eigenen Dokumentation außerdem, dass Quantisierung Speicher- und Rechenanforderungen reduziert, allerdings um den Preis gewisser Qualitätsverluste. (5) Genau das erklärt, warum lokaler Betrieb heute massentauglich geworden ist: Man kann ein Modell deutlich schrumpfen und trotzdem ein brauchbares Ergebnis erhalten.

Wenn eher eine kompakte Arbeitsoption ohne übermäßige Schwere gebraucht wird, landet man oft bei Mistral. Im Ollama-Katalog erscheint mistral als 7B-Modell mit einer Distributionsgröße von rund 4,1 GB. (1) Das ist bereits ein Bereich, den man ohne exotische Hardware sinnvoll testen kann. Für interne Assistenten, Entwürfe, Dokumentensuche und leichtere Copilot-Szenarien ist das häufig ein realistischeres Startniveau als die Jagd nach maximal vielen Parametern.

Mixtral wird dort interessant, wo kleine dense Modelle nicht mehr ausreichen. In der Dokumentation von Mistral wird Mixtral 8x22B als offenes MoE-Modell mit 141B Gesamtparametern, 39B aktiven Parametern und einem 64k-Kontext beschrieben. (4) Das ist bereits eine ganz andere Klasse von Anforderungen und ein völlig anderes Gespräch über GPU-RAM, Latenz und Betriebskosten. Solche Modelle sind dort sinnvoll, wo ein Team tatsächlich eine höhere Qualitätsobergrenze braucht und nicht bloß einen schöneren Namen im README.

Die praktische Regel ist deshalb einfach: Nicht nach Hype auswählen, sondern nach der Kombination Aufgabentyp -> akzeptable Latenz -> verfügbare Hardware -> Kosten eines Fehlers.

Wie die Hardware in der Praxis aussieht

Das größte Missverständnis beim Thema lokale LLMs lautet ungefähr so: „Wenn das Modell heruntergeladen wurde, taugt es auch für Production.“

Ein Modell kann sich problemlos auf ein Notebook laden. Die eigentliche Frage ist aber, wie schnell es antwortet, wie viele gleichzeitige Requests es aushält und wie schmerzhaft die Latenz bei langen Kontexten ansteigt.

Als groben Ausgangspunkt liefert die Ollama-Dokumentation eine klare Untergrenze: Für 7B-Modelle sollte man mindestens 8 GB RAM haben, für 13B-Modelle 16 GB und für 33B-Modelle 32 GB. (1) Das ist kein Komfortversprechen, sondern eher die untere Schwelle, unterhalb derer das Ganze sehr schnell unerquicklich wird.

Vereinfacht sieht das Bild meistens so aus:

Szenario	Was realistisch möglich ist
Nur CPU oder normales Notebook	Kleine quantisierte Modelle für Demos, Entwürfe, einfaches Q&A und seltene Requests
Eine GPU mit 16-24 GB VRAM	Die praktischste Klasse für produktive 7B-14B-Modelle, internes RAG und lokale Copilot-Szenarien
48 GB VRAM und mehr oder Multi-GPU	Schwerere Modelle, größere Kontexte, MoE-Experimente und mehr Parallelität

Zwei Dinge sind dabei besonders wichtig. Erstens fressen parallele Requests und lange Kontexte sehr schnell Speicher: Ollama weist ausdrücklich darauf hin, dass die RAM-Anforderungen mit der Zahl paralleler Requests und der Kontextgröße wachsen. (2) Zweitens hilft Quantisierung, aber sie bleibt immer ein Kompromiss. Meta formuliert das in der Llama-Dokumentation genauso deutlich: weniger Speicher und schnellere Inferenz gegen einen gewissen Qualitätsverlust. (5)

Damit wird die Diskussion über lokale LLMs sehr schnell nicht mehr zu einer Diskussion über das Modell selbst, sondern über Infrastrukturkapazität.

Datenschutz und Sicherheit: was lokaler Betrieb löst und was nicht

Lokaler Betrieb hat tatsächlich ein starkes Datenschutzargument. Wenn Modell, Dokumente und Inferenz innerhalb des eigenen Perimeters bleiben, sinkt die Zahl externer Datenübergaben. Es wird leichter, Auditoren zu erklären, wo Prompts liegen, wer Zugriff auf Embeddings hat, wie Logs behandelt werden und welche Dienste überhaupt an der Kette beteiligt sind.

Aber die Details sind entscheidend. Der Vorteil des lokalen Betriebs liegt nicht darin, dass Cloud-Anbieter angeblich grundsätzlich nicht sauber mit Unternehmensdaten umgehen könnten. Im Gegenteil: OpenAI, Anthropic und Google erklären jeweils separat, dass sie solche Daten in kommerziellen und API-Produkten standardmäßig nicht zum Training verwenden. (6 8) Der Vorteil des lokalen Stacks ist ein anderer: Man nimmt den externen Inferenz-Perimeter aus der Kette heraus und kontrolliert die Zugriffsgrenze selbst.

Und Lokalität allein macht ein System noch nicht sicher. Wer einen lokalen Server ohne saubere Authentifizierung hochzieht, ihn im Netzwerk freigibt, interne Datenbanken unkontrolliert anbietet und Agenten-Werkzeuge nicht einschränkt, baut nicht „sichere AI“. Er verlagert das Problem nur näher heran. Bei LM Studio ist API-Authentifizierung zum Beispiel nicht standardmäßig erzwungen, sondern muss separat konfiguriert werden. (3) Auch NIST erinnert im GenAI-Profil daran, dass Generative AI eigene Risikoklassen mitbringt und es für Organisationen nicht darum geht, die Technologie zu bewundern, sondern ihre Risiken über den gesamten Lebenszyklus hinweg zu steuern. (9)

Deshalb lautet die richtige Frage bei lokalen LLMs nicht „Die Daten sind jetzt im Haus, also ist alles gut“, sondern „Wie sind Zugriff, Segmentierung, Logs, Secrets, Retrieval und die Kontrolle über Modellaktionen innerhalb unseres Perimeters organisiert?“

Wann lokale Modelle besser sind als OpenAI, Google und Anthropic

Ein lokaler Stack ist vor allem in fünf Arten von Szenarien stark.

Erstens, wenn man mit internen Dokumenten, Kundendaten, Finanzmaterialien, Code oder interner Kommunikation arbeitet, die das Unternehmen nicht regelmäßig in einen externen Inferenz-Perimeter schicken will.

Zweitens, wenn es einen Offline-Modus, ein isoliertes Netzsegment oder Data-Residency-Anforderungen gibt, bei denen „die Cloud ist im Allgemeinen sicher“ keine ausreichende Antwort ist.

Drittens, wenn die Last stabil und planbar ist. Wenn ein Team weiß, dass es jeden Tag Tausende ähnlicher Requests für Summarization, Extraction, RAG oder einen internen Helpdesk ausführen wird, liefert eigene Infrastruktur oft die besser kalkulierbare Ökonomie.

Viertens, wenn geringe Latenz nahe an internen Systemen wichtig ist. Manchmal liegt der Vorteil nicht darin, dass das lokale Modell billiger ist, sondern darin, dass es im selben Perimeter sitzt wie Dokumente, Queues, Datenbanken und Services.

Fünftens, wenn die Aufgabe keine Frontier-Qualität um jeden Preis braucht. Für viele interne Szenarien zählt nicht „das beste Modell auf dem Markt“, sondern ein Modell, das zuverlässig 80 % der täglichen Routine abdeckt, ohne den Perimeter zu verlassen.

Wann die Cloud weiterhin die vernünftigere Wahl ist

Es gibt auch die umgekehrte Wahrheit: In vielen Fällen wäre lokaler Betrieb schlicht Overengineering.

Wenn ein Team innerhalb weniger Tage starten muss, keine freien Engineers für den Betrieb eines GPU-Stacks hat oder sofort maximale Reasoning-Qualität und Multimodalität braucht, bieten Cloud-Modelle weiterhin den kürzesten Weg zum Ergebnis. Man kauft keine Server, kümmert sich nicht um Treiber, plant kein VRAM und rätselt nicht darüber, warum eine neue Quantisierungsvariante die Antworten auf der eigenen Domänen-Stichprobe plötzlich verschlechtert hat.

Cloud-Plattformen gewinnen auch dort, wo die Last schwankt. Wenn ein Modell nicht dauerhaft, sondern nur in Schüben gebraucht wird, kann API-Nutzung schlicht vernünftiger sein, als eigene Hardware für Lastspitzen vorzuhalten, die zweimal pro Woche auftreten.

Deshalb sieht die reale Entscheidung fast nie wie ein ideologischer Krieg „lokal gegen Cloud“ aus. Meistens ist sie eine Frage der Reife:

wie sensibel die Daten sind;
wie planbar die Last ist;
wie wichtig Latenz und Autonomie sind;
wie bereit das Team ist, den Stack selbst zu betreiben;
wie sehr die absolute Qualitätsobergrenze gebraucht wird und nicht nur ein solides Arbeitsergebnis.

Lokale LLMs haben nichts mit der Romantik von Self-Hosting zu tun. Es geht um Grenzen

Die nützlichste Einsicht in diesem ganzen Thema ist eine ziemlich nüchterne.

Lokale LLMs braucht man nicht, weil „der eigene Server immer besser ist als der fremde“. Man braucht sie dann, wenn Kontrolle über Grenzen wichtiger ist als die Bequemlichkeit einer externen API. Wenn es wichtiger ist, Daten, Retrieval, Logs und Zugriffe im eigenen Perimeter zu halten. Wenn es wichtig ist, die Kosten jedes neuen AI-Szenarios im Voraus zu verstehen. Und wenn die Qualität eines kompakten oder mittelgroßen Open-Weight-Modells für das Geschäft bereits ausreicht.

In allen anderen Fällen bleiben Cloud-AI-Plattformen eine normale und oft vernünftigere Wahl.

Nicht weil lokale Modelle schlecht wären.

Sondern weil lokale AI sich erst dort auszahlt, wo ein Unternehmen bereits einen Grund hat, nicht nur die Prompts, sondern die gesamte Infrastruktur darum herum zu kontrollieren.