Die Landschaft der Sprachmodelle verschiebt sich derzeit an mehreren Stellen gleichzeitig. Aus China kommen Modelle in immer größeren Dimensionen. Aus den USA kommen Modelle, die häufiger als früher offen verfügbar gemacht werden. Und in Europa melden sich neue Projekte: Neuigkeiten gibt es aus der Schweiz und, nach längerer Wartezeit, auch aus Deutschland.

Für Unternehmen, die KI-Funktionen in Websites, Portale oder interne Werkzeuge einbauen, ist das keine Randnotiz. Denn die Frage, welche Modelle offen verfügbar sind, entscheidet mit darüber, wo diese Funktionen betrieben werden können — und damit auch, welche Daten das eigene Netz verlassen.

Was "offen" in diesem Zusammenhang bedeutet

Offen verfügbar heißt in der Regel: Die Modellgewichte, also die trainierten Parameter, stehen zum Download bereit und dürfen auf eigener Infrastruktur ausgeführt werden. Das ist nicht dasselbe wie Open Source im klassischen Sinn, weil Trainingsdaten und Trainingscode meist nicht offengelegt werden und die Lizenzen unterschiedlich streng sind.

Praktisch relevant ist trotzdem vor allem der Betriebsaspekt. Ein Modell, dessen Gewichte man laden kann, läuft auf einem eigenen Server, in einer eigenen Cloud-Instanz oder im Rechenzentrum eines europäischen Anbieters. Ein Modell, das nur als Dienst über eine Schnittstelle erreichbar ist, tut das nicht.

Warum die Größe eine Betriebsfrage ist

Wenn Modelle wachsen, wachsen die Anforderungen an Speicher und Rechenleistung mit. Sehr große Modelle sind selbst dann schwer selbst zu betreiben, wenn die Gewichte frei zugänglich sind: Sie brauchen mehrere leistungsfähige Beschleunigerkarten, entsprechenden Arbeitsspeicher und eine Betriebsmannschaft, die das im Griff hat.

Genau deshalb sind kleinere Modelle für den Mittelstand oft die interessantere Nachricht. Sie lassen sich auf überschaubarer Hardware betreiben, reagieren schneller und verursachen im Dauerbetrieb kalkulierbare Kosten. Der Preis dafür ist meist weniger Allgemeinwissen und weniger Leistung bei komplexen Aufgabenstellungen.

Der praktische Nutzen kleiner Modelle

Viele Aufgaben in Web- und Softwareprojekten sind eng umrissen. Für solche Fälle reicht ein kleineres Modell häufig aus:

  • Klassifizieren und Verschlagworten: Anfragen aus Formularen einer Kategorie zuordnen, Redaktionsinhalte automatisch mit Schlagworten versehen.
  • Zusammenfassen: lange Dokumente oder Ticketverläufe auf das Wesentliche verkürzen.
  • Umformulieren und Prüfen: Textvarianten für Teaser erzeugen, Stilrichtlinien gegenlesen.
  • Strukturieren: aus unformatierten Texten saubere Datenfelder gewinnen.
  • Semantische Suche: Inhalte für eine Suchfunktion in Vektoren übersetzen, die Bedeutungsähnlichkeit abbilden.

Für Aufgaben mit hohem Anspruch an Argumentation oder Fachtiefe bleiben große Modelle im Vorteil. Das spricht für eine gemischte Architektur, in der einfache Anfragen lokal beantwortet werden und nur ausgewählte Fälle an einen externen Dienst gehen.

Souveränität ist mehr als Datenschutz

Der Datenschutz ist das offensichtliche Argument für den Betrieb im eigenen Haus: Wenn personenbezogene Daten oder Betriebsgeheimnisse nicht an einen externen Anbieter übertragen werden, entfällt ein ganzer Block an Prüfungen, Verträgen und Risikoabwägungen.

Ebenso wichtig ist die technische Kontinuität. Ein Modell, das lokal liegt, verschwindet nicht zum Quartalsende, ändert nicht ohne Vorankündigung sein Verhalten und verteuert sich nicht über Nacht. Wer produktive Funktionen auf ein Modell aufbaut, kauft mit der Offenheit vor allem Planbarkeit ein.

Dem gegenüber steht der Aufwand: Betrieb, Aktualisierung, Überwachung und Absicherung liegen dann im eigenen Verantwortungsbereich. Diese Rechnung fällt je nach Unternehmen und Anwendungsfall unterschiedlich aus.

Was das für die Architektur bedeutet

Die derzeitige Bewegung im Markt lässt sich nicht durch eine einmalige Auswahlentscheidung abfangen. Wer heute ein Modell festschreibt, wird diese Entscheidung in überschaubarer Zeit erneut treffen müssen. Sinnvoll ist deshalb eine Zwischenschicht in der eigenen Anwendung, die das Modell austauschbar hält.

Konkret heißt das: Prompts, Nachbearbeitung und Fehlerbehandlung liegen im eigenen Code, nicht in einer anbieterspezifischen Bibliothek. Für jede KI-Funktion gibt es einen kleinen Satz von Testfällen mit erwarteten Ergebnissen, an dem sich ein Modellwechsel bewerten lässt. Und es gibt einen definierten Weg, was passiert, wenn das Modell nicht antwortet oder unbrauchbaren Output liefert.

In einem TYPO3-Projekt lässt sich das gut kapseln: Die KI-Anbindung sitzt in einem eigenen Service, die Redaktion arbeitet weiter mit ihren gewohnten Feldern und Masken. Ob im Hintergrund ein lokales Modell oder eine externe Schnittstelle antwortet, muss im Backend niemanden beschäftigen.

Einordnung

Die Vielfalt an offen verfügbaren Modellen erhöht den Spielraum bei der Frage, wo KI-Funktionen betrieben werden — und genau dieser Spielraum ist für datenschutzsensible Anwendungen der eigentliche Gewinn. Für Projekte lohnt es sich deshalb, weniger Energie in die Wahl des vermeintlich besten Modells zu stecken und mehr in eine Architektur, die den Wechsel ohne Umbau zulässt. Wer so plant, kann kleinere europäische Modelle heute testen, ohne sich den Weg zu größeren Systemen zu verbauen.

Quellen