Open-Source-Modelle, selbst gehostet.

Ein Modell ist im Kern eine Datei. In ihr stehen die Gewichte — die Zahlen, in denen das Gelernte steckt. Damit daraus eine Antwort wird, braucht es ein Programm, das diese Datei lädt, eine Frage hineingibt und Wort für Wort zurückbekommt. Bei einer fremden Schnittstelle betreibt jemand anders beides. Offen heißt, dass die Gewichte verfügbar sind und du sie selbst betreiben darfst. Selbst gehostet heißt, dass du es tust.

Der Unterschied ist also nicht die Funktion, sondern der Ort. Eine Zusammenfassung, eine Klassifizierung, eine Chat-Antwort sehen von der Website aus gleich aus — nur geht die Anfrage nicht an einen externen Anbieter, sondern an eine Maschine, die dir untersteht. Das ist der ganze Punkt, und es ist auch der ganze Aufwand.

Beim Wort „Open Source“ lohnt eine Präzisierung, weil sie später über Verträge entscheidet. Verfügbare Gewichte sind nicht dasselbe wie quelloffene KI. Die Open Source Initiative unterscheidet beides ausdrücklich: Ihre Definition für quelloffene KI verlangt neben den Gewichten auch den Trainingscode und ausreichende Angaben darüber, woher die Trainingsdaten kommen und wie sie verarbeitet wurden. Viele Modelle, die umgangssprachlich „open“ heißen, erfüllen nur den ersten Teil.

Daraus folgt der wichtigste Satz dieser Seite über Lizenzen: Die Nutzungsbedingungen offener Modelle unterscheiden sich stark. Manche erlauben kommerzielle Nutzung uneingeschränkt, andere knüpfen sie an Bedingungen oder schließen bestimmte Anwendungsfälle aus. Welches Modell in ein Projekt geht, entscheiden wir deshalb erst, nachdem die Lizenz gelesen ist — konkrete Modellnamen nennen wir hier bewusst nicht, weil sich das Feld schneller dreht als eine Agenturseite.

Am Anfang steht keine Modellwahl, sondern eine Frage: Was soll die Funktion eigentlich können? Eine Beschreibung zusammenfassen, eine Anfrage in die richtige Abteilung einsortieren, aus einem Datenblatt eine verständliche Antwort machen, im Chat auf Fragen zu den eigenen Inhalten antworten — das sind vier verschiedene Aufgaben mit vier verschiedenen Ansprüchen. Erst wenn die Aufgabe steht, lässt sich sagen, wie groß ein Modell sein muss. Und die Größe ist es, die später die Rechnung für die Hardware schreibt.

Danach klären wir die Lizenz — vor dem ersten Test, nicht nach dem Launch. Erlaubt das Modell kommerzielle Nutzung in dieser Form? Gibt es Bedingungen an Weitergabe oder Nennung? Gibt es ausgeschlossene Anwendungsfälle? Das Ergebnis notieren wir im Konzept, damit später nachvollziehbar ist, warum die Wahl so ausfiel.

Dann steht der Modell-Dienst: ein Programm auf einem Server, das die Gewichte lädt und im internen Netz über eine Adresse ansprechbar macht. Diese Adresse ist ausdrücklich nicht öffentlich. Erreichbar ist sie nur für unseren eigenen serverseitigen Endpunkt, und der steht dazwischen wie eine Anmeldung an der Pforte: Er prüft, wer fragt, begrenzt, wie oft gefragt werden darf, setzt eine Obergrenze für die Länge und entscheidet, was überhaupt protokolliert wird.

Ein Modell weiß nichts über deine Website. Dieser Satz gilt hier genauso wie bei jeder fremden Schnittstelle, und er ist der Grund, warum eine gute KI-Funktion mehr Suche als Sprachmodell ist. Die eigenen Inhalte müssen mitgegeben werden: Zur Frage sucht der Index oder das CMS die Handvoll Textstellen heraus, die dazu passen, und erst diese Ausschnitte gehen zusammen mit der Frage an das Modell. Wie wir Suche bauen, steht im Hub Suche; ein Suchdienst, den man ebenfalls selbst betreibt, passt an dieser Stelle besonders gut, weil dann auch die Suche im Haus bleibt — Meilisearch ist dafür unsere Zuordnung.

Zuletzt der Fehlerfall, den wir wie bei jeder Anbindung mitplanen: Antwortet der Modell-Dienst nicht oder dauert es zu lange, bleibt die Seite bedienbar und zeigt den Weg über Suche, Navigation oder Kontaktformular. Die buchbaren Leistungen dahinter sind KI & Automation und KI-Chatbots; die Anbindung selbst gehört zur Schnittstellenentwicklung. Wie wir KI in unserer eigenen Entwicklungsarbeit einsetzen, ist ein anderes Kapitel und steht unter KI-gestützte Entwicklung.

Hardware & Antwortzeit.

Ein Modell muss vollständig in den Speicher passen, um zu antworten. Kleinere Modelle laufen auf Arbeitsspeicher, größere brauchen eine Grafikkarte — welche genau, hängt am gewählten Modell und wird im Projekt bestimmt, nicht auf einer Agenturseite. Konkrete Zahlen nennen wir hier deshalb bewusst nicht: Sie wären geraten, und geraten hilft niemandem bei der Budgetplanung.

Daraus folgt der zweite Punkt: Antwortzeiten hängen von der Maschine ab. Ein gehosteter Dienst verteilt Last über viele Rechner; deine Maschine tut das nicht. Mehrere gleichzeitige Anfragen teilen sich dieselbe Hardware, und ab einem gewissen Punkt wird gewartet. Wir bauen deshalb von Anfang an eine Warteschlange, eine Obergrenze und eine Anzeige ein, die dem Besucher zeigt, dass gearbeitet wird — und wir messen, bevor die Funktion live geht.

Pflege & Zuständigkeit.

Ein Modell-Dienst ist Software und altert wie Software. Betriebssystem, Laufzeitumgebung und Modellstand wollen aktualisiert werden, und jedes Update ist ein kleiner Wiederholungstest: Ein anderer Stand kann anders antworten. Dazu kommt die Überwachung — Auslastung, Speicher, Antwortzeiten, Fehlerrate. Ohne sie merkt man einen Engpass erst an der Beschwerde, und das ist der teuerste Zeitpunkt.

Und es braucht jemanden, der das im Alltag macht. Wie wir Auslieferung und Umgebungen aufsetzen, steht im Stack unter Deployment & Betrieb. Wenn diese Zuständigkeit bei uns liegen soll, ist das die buchbare Leistung Betrieb, Wartung & Support. Soll sie im Haus bleiben, klären wir vorher, wer sie übernimmt — diese Frage gehört ins Konzept und nicht in die Woche nach dem Launch.