Lokale KI-Modelle im Vergleich: der Leitfaden

„Lokale KI“ steht inzwischen in jedem zweiten Strategie-Meeting auf der Agenda. Der Grund ist konkret: Mit GLM-5.2, Kimi und DeepSeek liegen gleich mehrere Spitzenmodelle offen lizenziert vor, dazu Kimi K3 als größtes offenes Modell überhaupt. Nur hat niemand Zeit, 49 Modelle und sieben Quantisierungsstufen zu durchdringen.

Hier steht, wann sich der Eigenbetrieb für dich lohnt und wann die Cloud die ruhigere Wahl bleibt.

Was lokale KI-Modelle sind

Lokale KI-Modelle sind offen lizenzierte Sprachmodelle, die du ohne Lizenzgebühr herunterlädst und auf eigener Hardware betreibst. Tools wie Ollama, LM Studio oder llama.cpp laden das Modell, die Inferenz läuft auf deiner GPU. „Open-Weight“ heißt dabei: Die Gewichte sind frei verfügbar, der Trainingsprozess nicht zwingend.

Hier setzt das erste Missverständnis an. „Lokal“ klingt nach Rechenzentrum, nach eigener GPU-Farm, nach einem Ops-Team, das niemand hat. Tatsächlich läuft ein brauchbares 14B-Modell auf einer einzelnen Consumer-GPU. „Lokal“ bedeutet nur eins: Die Anfrage geht nicht über eine fremde Cloud-API.

Open-Weight ist wie ein gekauftes Auto statt eines Mietwagens. Einmal angeschafft fährt es ohne Abrechnung pro Kilometer, Wartung und Stellplatz liegen aber bei dir.

Datenhoheit ist eine Achse, kein Schalter

Das ist das Denkraster, das die ganze Entscheidung trägt. Es gibt nicht „Cloud oder sicher“, es gibt drei Stufen:

• Stufe 1: Cloud-API mit EU-Auftragsverarbeitung. Daten bleiben in der EU, das Backend ist fremd.
• Stufe 2: Open-Source, EU-gehostet. Dieselben offenen Modelle, auf EU-Servern, mit Vertrag, ohne eigenes Ops-Team.
• Stufe 3: Echt lokal oder Air-Gap. Eigene Hardware, die Inferenz verlässt das Haus nie.

Auf LinkedIn klingt die Sache dagegen so: „US-Cloud heißt unsicher, also brauchen wir eine eigene GPU-Farm.“ Das ist die falsche Frage, weil sie eine Achse mit drei Stufen in zwei Kästchen presst. Wer mit dieser Binär-Logik startet, verbaut sich die einfachste Antwort: Dieselbe Souveränität gibt es EU-gehostet, ohne Serverraum.

Zur Vollständigkeit gehört, dass es auch europäische Modelle gibt: Teuken 7B vom Fraunhofer IAIS aus dem Projekt OpenGPT-X, trainiert auf allen 24 EU-Sprachen, und EuroLLM 9B aus dem UTTER-Projekt. Beide stehen unter Apache 2.0 und sind im Deutschen stark. Beide haben aber nur 4K Kontext, und das ist heute die harte Grenze: Für ein längeres Dokument reicht das nicht. Als Beleg, dass europäisches Training funktioniert, sind sie wertvoll, als Arbeitspferd für den Alltag noch nicht.

Und noch etwas wird dabei übersehen. Offene Gewichte bedeuten Unabhängigkeit von jeder Anbieter-Roadmap. Kein Vendor ändert über Nacht die Bedingungen, kein Modell wird abgekündigt und zwingt dich zur Migration. Heute Gemma, morgen Qwen3, übermorgen das nächste Release: Der Tooling-Stack bleibt, nur die Gewichtsdatei wechselt. Das ist kein Datenschutz-Argument, sondern ein strategisches, und es gilt auch dann, wenn die Inferenz EU-gehostet läuft.

Sieben Kriterien statt Glaubensfrage

Halt diese Tabelle Zeile für Zeile gegen deinen Anwendungsfall.

Kriterium	Lokal	Cloud-API	Hinweis
Sensible Daten (Personen, Gesundheit, Mandanten)	Ja	Teils	Lokal eliminiert das Schrems-II-Risiko komplett, Cloud nur mit EU-Vertrag
Hohes Anfrage-Volumen	Ja	Teils	Ab stabilem Dauerbetrieb wird Eigenbetrieb günstiger als pay-per-token
Air-Gap oder Offline-Setup	Ja	Nein	Nur lokal möglich, etwa in Behörden oder Produktionshallen ohne Internet
Schnelle Iteration, wechselnde Modelle	Teils	Ja	Die Cloud liefert neue Modelle ohne Hardware-Bindung
Frontier-Leistung in Reasoning und Coding	Teils	Ja	Spitzen-Benchmarks sind lokal noch nicht 1:1 erreichbar
Einzelnutzer statt Team	Teils	Ja	Lokal lohnt erst bei Team-Auslastung
Niedrige Latenz	Teils	Teils	Lokal stark bei kleinen Modellen, bei 70B eher langsamer

Wer Mandantendaten verarbeitet, braucht also keine GPU-Farm, sondern erst eine klare Souveränitäts-Stufe und dann das passende Modell. Welche Modelle es gibt und was sie brauchen, siehst du tagesaktuell in der filterbaren Modell-Datenbank.

Der ehrliche Kostenpunkt

Cloud-Kosten wachsen linear mit der Nutzung. Lokale Inferenz hat fixe Hardware-Kosten plus Strom. Als Größenordnung kippt die Rechnung bei stabilem, hohem Volumen Richtung Eigenbetrieb, grob ab 50 Millionen Token pro Monat.

Das ist eine Faustregel, kein Schwellenwert. Das echte Break-even hängt an Modellgröße, Auslastung und Strompreis. Wichtig ist die Logik, nicht die zweite Nachkommastelle: Niedriges Volumen spricht für die Cloud, hohes Dauervolumen für eigene Hardware.

Welche Hardware du brauchst

„Lokal“ heißt nicht „Rechenzentrum“. Drei Klassen decken fast jeden Bedarf ab. Die Budgets sind eigene Recherche (DE-Preise inkl. MwSt., Stand Mai 2026), eine Größenordnung, keine Listenpreis-Garantie.

Klasse	Budget	GPU	Läuft mit
Consumer	2.000–4.500 €	RTX 5070 (12 GB) bis RTX 5090 (32 GB)	Modelle bis rund 24B bei Q4, MoE bis rund 30B
Workstation	8.000–18.000 €	RTX 6000 Ada (48 GB) oder 2× RTX 5090	Modelle bis rund 70B bei Q4, 5 bis 15 parallele Nutzer
Server	ab 40.000 €	NVIDIA B200 (192 GB), H100 (80 GB) oder H200 (141 GB)	Frontier-MoEs lokal

Für die allermeisten Unternehmen reicht die Workstation-Klasse. Apple Silicon (M4 Max mit 64 bis 128 GB Unified Memory) ist die latenzärmste Single-Box-Alternative ohne große Stromrechnung. Die Faustregel für den Speicher: rund 0,55 GB pro Milliarde Parameter bei Q4-Quantisierung. Ein 14B-Modell läuft damit auf einer 12-GB-GPU, ein 32B-Modell auf 24 GB.

Eine Ausnahme gibt es, und sie kostet Geld, wenn man sie übersieht. Manche Modelle werden von vornherein quantisiert trainiert, statt hinterher heruntergerechnet zu werden. Bei gpt-oss und Kimi K3 unterschätzt die Faustregel den echten Bedarf deutlich: Für gpt-oss 20B rechnet sie 11,5 GB aus, der Hersteller nennt 16 GB. Wer danach die Grafikkarte kauft, kauft eine Nummer zu klein. Die Modell-Datenbank rechnet bei diesen Modellen deshalb nicht mit der Formel. Sie nennt die Herstellerangabe, und wo der Hersteller nie eine veröffentlicht hat, wie bei Kimi K3, das Gewicht der Dateien selbst.

Womit du sie betreibst

Tool	Rolle	Gut für	Nicht für
Ollama	Einsteiger-Standard	Schneller Start auf Laptop und Desktop	Produktion mit hohem Durchsatz
LM Studio	GUI ohne Terminal	Lokale Experimente, Modelle vergleichen	Server-Deployment
llama.cpp	Die Engine unter allem	Maximale Kontrolle, eigene Builds	Wer schnell starten will
vLLM	Production-Server	Multi-User, OpenAI-kompatible API	Single-User auf dem Laptop

Für die ersten Schritte genügt Ollama oder LM Studio. Sobald mehrere Leute gleichzeitig zugreifen, führt der Weg zu vLLM mit einer OpenAI-kompatiblen API.

Ist lokale KI automatisch DSGVO-konform?

Nein, und das ist der Punkt, an dem ich die meisten Missverständnisse sehe.

Lokaler Betrieb beseitigt den Drittlandtransfer und damit die Schrems-II-Frage: Solange die Inferenz auf eigener Hardware läuft, verlassen Eingaben die eigene Infrastruktur nicht. Damit entfällt die Übermittlung nach Artikel 44 DSGVO und den folgenden. Die technischen und organisatorischen Maßnahmen nach Artikel 32 erfüllst du auf eigener Hardware oft leichter.

Zwei Punkte bleiben trotzdem. Zweckbindung, Löschkonzept und Dokumentation gelten unverändert weiter. Und sobald die Hardware bei einem externen Hoster steht, etwa per Colocation, brauchst du einen Auftragsverarbeitungsvertrag nach Artikel 28 mit diesem Betreiber. Die Inferenz selbst ist dabei keine Auftragsverarbeitung: Der Vertrag hängt an der Hardware, nicht am Modell. Bei echtem Air-Gap fällt auch das weg.

Wie du den Verarbeitungsort bei einem Anbieter konkret prüfst, steht in EU-Hosting und DSGVO.

Beide Wege in einer Plattform

Die Binär-Frage löst sich auf, wenn beide Wege nebeneinander liegen. Genau das macht RelationFlow.

Der erste Weg ist Bring Your Own Model: Du bindest einen eigenen Modell-Endpunkt mit deinem eigenen Schlüssel ein, OpenAI-kompatibel wie vLLM oder llama.cpp, oder einen gesicherten Ollama-Endpunkt. Das Modell läuft auf deiner Hardware oder bei deinem Wunsch-Hoster, abgerechnet über deinen Vertrag.

Der zweite Weg sind dieselben offenen Modelle, EU-gehostet: kein eigenes Ops-Team, Daten trotzdem in der EU, mit Vertrag und ohne US-Transfer.

Der entscheidende Punkt ist nicht der eine oder der andere Weg. Es ist, dass du pro Anwendungsfall wechselst, ohne den Stack zu tauschen. Warum das mehr als Bequemlichkeit ist, steht in Warum ein KI-Modell nie reicht.

Drei Schritte

Prüf zuerst im Hardware-Rechner, welche Modelle überhaupt auf deine vorhandene Hardware passen. Vergleich dann in der Modell-Datenbank ELO, Speicherbedarf und Lizenz nebeneinander. Und ordne zuletzt jeden Anwendungsfall einer der drei Souveränitäts-Stufen zu, bevor ihr über ein konkretes Modell redet.

In der Reihenfolge hast du eine belastbare Antwort auf die Lokal-oder-Cloud-Frage, bevor das erste Audit sie stellt. Andersherum diskutiert ihr drei Wochen über Modellnamen und habt am Ende trotzdem keine Entscheidung.