Lokale KI-Modelle im Mittelstand: Modellfamilien, Software, Hardware und Betrieb

Die Landschaft offener Modelle verändert sich laufend. Zum Recherchezeitpunkt im November 2026 veröffentlichen mehrere Hersteller regelmäßig neue Versionen auf Hugging Face: Google die Gemma-4-Reihe in verschiedenen Größen, Alibaba die Qwen3.8-Generation, Mistral unter anderem Mistral Small 4 und Mistral Large 4, DeepSeek die V4-Reihe und OpenAI die Modelle gpt-oss-20b und gpt-oss-120b. Die jüngsten Llama-Sprachmodelle auf der Hugging-Face-Seite von Meta stammen aus der Llama-4-Generation vom April 2025.

Die Größen reichen von kompakten Modellen für Laptops bis zu sehr großen Mixture-of-Experts-Modellen, die Rechenzentrumshardware erfordern. Für den Mittelstand sind meist mittlere Größen interessant, die auf einer oder wenigen GPUs laufen. Wichtiger als Ranglisten ist die Frage, wie ein Modell bei den eigenen Aufgaben abschneidet: deutsche Fachtexte, strukturierte Extraktion, Werkzeugaufrufe oder Zusammenfassungen. Das lässt sich nur mit eigenen Testfällen beantworten.

Offen bedeutet nicht automatisch frei verwendbar. Laut den Lizenzangaben auf Hugging Face stehen gpt-oss und Gemma 4 unter Apache 2.0, DeepSeek V4 unter MIT. Innerhalb einer Familie gibt es aber Unterschiede: Qwen3.8-27B ist mit Apache 2.0 gekennzeichnet, Qwen3.8-Flash-Next dagegen mit einer eigenen Qwen-Community-Lizenz. Bei Mistral trägt Mistral Small 4 die Apache-Lizenz, Mistral Large 4 eine eigene Lizenz.

Llama 4 unterliegt der Llama 4 Community License. Sie verlangt unter anderem, bei Weitergabe den Hinweis Built with Llama sichtbar anzubringen, und sieht für Anbieter mit mehr als 700 Millionen monatlich aktiven Nutzern eine gesonderte Lizenz vor. Für ein mittelständisches Unternehmen ist die zweite Bedingung selten relevant, die Kennzeichnungspflicht bei eigenen Produkten dagegen schon. Ein Lizenzregister mit Modell, Version, Lizenztext und Nutzungszweck schafft hier Klarheit; eine rechtliche Einzelfallprüfung ersetzt es nicht.

Die Laufzeitsoftware lädt das Modell und stellt es über eine Schnittstelle bereit. llama.cpp ist eine Inferenzbibliothek in C und C++, die auf vielen Plattformen läuft und quantisierte Modelle im GGUF-Format verarbeitet. Ollama bietet eine einfache Verwaltung lokaler Modelle und eine API, die laut Dokumentation auch OpenAI- und Anthropic-kompatible Clients bedient. Ollama bietet inzwischen ebenfalls Cloud-Modelle an; wer strikt lokal arbeiten will, muss ausschließlich lokale Modelle verwenden. LM Studio ist eine Desktop-Anwendung, mit der sich Modelle ohne Kommandozeile testen lassen.

Für den Mehrbenutzerbetrieb auf Servern ist vLLM verbreitet. Laut Dokumentation optimiert es den Durchsatz durch kontinuierliches Batching und effiziente Speicherverwaltung, unterstützt zahlreiche Quantisierungsverfahren, strukturierte Ausgaben und Werkzeugaufrufe und stellt einen OpenAI-kompatiblen API-Server bereit. Diese Kompatibilität ist praktisch: Anwendungen, die für eine kommerzielle API geschrieben wurden, lassen sich oft durch Ändern der Basis-URL auf ein lokales Modell umstellen.

Der entscheidende Engpass ist meist der Grafikspeicher. Er muss die Modellgewichte und den Kontext der laufenden Anfragen aufnehmen. Der Bedarf steigt mit der Parameterzahl, der gewünschten Kontextlänge und der Zahl gleichzeitiger Nutzer. Qualitativ lassen sich drei Klassen unterscheiden: Arbeitsplatzrechner mit einer Grafikkarte oder viel gemeinsamem Speicher für kleine Modelle und Einzelpersonen, Server mit einer oder mehreren Rechenzentrums-GPUs für Teams und Abteilungen sowie gemietete GPU-Instanzen in einer EU-Cloud für schwankende Last.

Quantisierung reduziert die Genauigkeit, mit der Gewichte gespeichert werden, etwa von 16 auf 8 oder 4 Bit. Dadurch sinkt der Speicherbedarf deutlich, und größere Modelle passen auf kleinere Hardware. Der Preis ist ein möglicher Qualitätsverlust, der je nach Modell und Aufgabe unterschiedlich ausfällt. Einige Hersteller veröffentlichen zusätzlich eigene quantisierte Varianten ihrer Modelle. Ob eine Quantisierung für die eigene Aufgabe ausreicht, zeigt nur der Vergleich im eigenen Testset.

Ein lokales Modell ist kein einmal installiertes Produkt. Laufzeitsoftware erhält Sicherheitskorrekturen, Hersteller veröffentlichen neue Modellversionen, und Anwendungen ändern ihre Anforderungen. Bewährt hat sich, Modelle und Laufzeit wie andere Software zu behandeln: feste Versionen, Änderungen über einen Freigabeprozess, Überwachung von Antwortzeit und Auslastung sowie eine dokumentierte Rückfallversion.

Kern der Qualitätssicherung ist ein Evaluationsset: eine Sammlung realer, bereinigter Aufgaben mit erwarteten Ergebnissen oder Bewertungskriterien. Jeder Modellwechsel und jede neue Quantisierung durchläuft dieses Set, bevor sie in den Betrieb geht. So wird aus der Frage, ob ein neues Modell besser ist, eine messbare Entscheidung. Zuständigkeit für dieses Set gehört in den Fachbereich, nicht allein in die IT.

Lokale Modelle bieten Kontrolle über Datenfluss, Speicherung und Modellversion. Sie verursachen dafür Fixkosten für Hardware und Personal, unabhängig von der Auslastung. Kommerzielle Dienste sind schneller verfügbar und bei komplexen Aufgaben oft leistungsfähiger, verlagern die Datenverarbeitung aber zu einem Dritten. Für die meisten Unternehmen ist deshalb weder rein lokal noch rein extern die passende Antwort.

In einer Hybrid-Architektur steht ein Gateway vor allen Modellen. Es prüft die Datenklasse jeder Anfrage und leitet sie nach festen Regeln weiter: vertrauliche Inhalte an das lokale Modell, freigegebene Aufgaben mit hohem Anspruch an einen externen Dienst. Weil lokale Laufzeiten OpenAI-kompatible Schnittstellen anbieten, bleibt die Anwendung dieselbe. Der Router protokolliert, welches Modell welche Anfrage bearbeitet hat, und schafft damit die Grundlage für Audit und Kostenvergleich.