Modelle anbinden und bereitstellen

Modelle anbinden und bereitstellen

0:00 Willkommen zu Modul sechs. Lotsenhaus steht, die Menschen von Brandtner Fördertechnik melden sich über den Identitätsanbieter an, und die Rechte sind belegt. Was noch fehlt, ist das, wofür alle eigentlich kommen: die Modelle. In diesem Modul schließen wir zwei Zugänge an, einen lokalen auf inferenz-01 und einen externen bei einem Anbieter.

0:19 Wir schauen uns an, wann ein Gateway dazwischen sinnvoll ist, wie man ein Modell nach Fähigkeiten auswählt statt nach Ranglisten, und wie man unternehmensweite Vorgaben setzt. Und wir planen einen Modellwechsel so, dass niemand am Montagmorgen eine Überraschung erlebt. Denn eines ist sicher: Die Modelle von heute sind nicht die von nächstem Jahr.

Modelle anbinden und bereitstellen

0:40 Der dritte Tag macht aus der Plattform ein Werkzeug: erst Modelle, dann Assistenten, dann Unternehmenswissen. Der Satz auf der Folie setzt den Maßstab für heute. Die Oberfläche bleibt, die Modelle wechseln. Gut angebunden ist also nicht, was heute läuft, sondern was sich morgen ohne Überraschung austauschen lässt.

Lokale und externe Modelle

1:00 Wir beginnen mit der wichtigsten Weiche der ganzen Architektur: Läuft das Modell im eigenen Haus oder bei einem Anbieter? Davon hängt ab, welche Daten es sehen darf. Denken Sie an eine Steckdose. Ihr Gerät fragt nicht, welches Kraftwerk den Strom liefert, solange der Stecker passt. Open WebUI funktioniert genauso: Es spricht Protokolle, keine Anbieter. Die Ollama-API, die Chat-Completions-API von OpenAI und experimentell Open Responses.

1:27 Jeder Server, der eines davon versteht, lässt sich mit Adresse und Schlüssel eintragen. Das ist bequem, hat aber eine Kehrseite, die man nicht übersehen darf. Die Verbindung entscheidet, wo gerechnet wird. Und ein externes Modell bekommt alles, was mitgeschickt wird, also den Prompt samt Dateien und Verlauf. Die Wahl der Verbindung ist deshalb keine technische Kleinigkeit, sondern eine Datenschutzentscheidung.

1:54 Hier stehen die beiden Zugänge von Lotsenhaus nebeneinander. Links der lokale Weg über Ollama auf inferenz-01. Modelle laden, aktualisieren und löschen Sie direkt aus Open WebUI heraus. Rechts der externe Anbieter, dessen Modelle über die Modellliste erkannt oder von Hand eingetragen werden. Der eigentlich wichtige Unterschied steht in der dritten Zeile, und er kommt aus der Governance-Matrix von Modul zwei: Lokal darf bis zur Datenklasse vertraulich gearbeitet werden, extern höchstens bis intern.

2:24 Die letzte Zeile zeigt, dass beide Wege kosten, nur anders. Lokal zahlen Sie Hardware und Betrieb, extern zahlen Sie je Token. Beides gehört in eine ehrliche Rechnung. Im Admin-Panel lassen sich Verbindungen zusammenklicken, aber für Lotsenhaus gehören sie in die Konfiguration von lotsenhaus-betrieb. Das Muster ist schlicht.

2:44 Eine Adresse für Ollama auf inferenz-01, eine für den externen Anbieter, und dessen Schlüssel kommt aus dem Tresor statt aus der Datei. Direkte Verbindungen, mit denen Anwender eigene Endpunkte eintragen könnten, sind abgeschaltet, sonst wäre die Datenklassen-Regel nach fünf Minuten umgangen. Dazu zwei Zeitlimits: ein großzügiges für Antworten, ein kurzes für die Modellliste. Beachten Sie die Fußzeile.

3:08 Was einmal im Admin-Panel gespeichert wurde, schlägt standardmäßig diese Variablen, und dann wundert man sich, warum eine Änderung in der Datei nicht greift. OpenAI-kompatibel klingt nach einem festen Standard, ist in der Praxis aber eher eine Familienähnlichkeit. Diese Tabelle zeigt, worauf es ankommt. Unverzichtbar ist nur ein Endpunkt, der für den Chat. Die Modellliste ist empfohlen, ohne sie tippen Sie Modellkennungen von Hand ein.

3:36 Alles andere ist Zusatz: Embeddings, Sprache, Bilder. Wichtig ist die Unterscheidung beim Einkauf. Wenn ein Anbieter sagt, er sei kompatibel, fragen Sie nach, welche dieser Endpunkte er tatsächlich bedient. Und die Fußzeile verdient besondere Aufmerksamkeit. Werkzeuge funktionieren nur, wenn Modell und Server die Parameter für Tool Calling wirklich beherrschen. Das steht selten auf dem Datenblatt.

4:02 Vier Fallen beim ersten Anschließen. Die erste: Speichern prüft gar nichts. Erst die Verbindungsprüfung fragt die Modellliste ab, und selbst ein Fehler dort heißt nicht zwingend, dass der Chat scheitert. Die zweite ist ein Klassiker aus der Container-Welt. localhost im Container meint den Container selbst, nicht den Rechner, auf dem der Modellserver läuft.

4:22 Die dritte ist ein Denkfehler mit Folgen für den Datenschutz: Ein lokales Chatmodell macht Embedding, Websuche oder Werkzeuge nicht automatisch lokal, die laufen getrennt. Und die vierte ist besonders tückisch. Streamt ein Anbieter Tool Calls ohne Index, bleiben Antworten einfach leer, ganz ohne Fehlermeldung.

Das API-Gateway als Baustein

4:41 Zwei Endpunkte lassen sich direkt verwalten. Aber was, wenn es mehr werden und andere Anwendungen dieselben Anbieter nutzen wollen? Dann kommt ein weiterer Baustein ins Spiel. Ein API-Gateway ist so etwas wie die Telefonzentrale eines Unternehmens. Nach außen gibt es eine Nummer, und dahinter wird vermittelt, protokolliert und abgerechnet.

5:03 Für Open WebUI ist das Gateway eine ganz gewöhnliche OpenAI-kompatible Verbindung. Alles Weitere passiert dahinter: Richtlinien, Budgets, die Entscheidung, welcher Anbieter eine Anfrage bekommt, und die eigentlichen Anbieterschlüssel. Die Doku nennt LiteLLM und OpenRouter als Beispiele und bietet für LiteLLM sogar eine eigene Provider-Einstellung an. Der Gewinn ist eine klare Arbeitsteilung.

5:27 Lotsenhaus kümmert sich um Menschen und Assistenten, das Gateway um Anbieter und Kosten. Folgen wir einer Anfrage von links nach rechts. In Lotsenhaus wird geprüft, wer fragt und welcher Assistent antwortet, und auf Wunsch werden Angaben zur Person als Kopfzeilen mitgegeben. Im Gateway entscheidet sich, mit welchem Schlüssel, aus welchem Budget und an welches Ziel die Anfrage geht, und dort wird sie protokolliert.

5:52 Erst ganz rechts wird gerechnet, lokal auf inferenz-01 oder beim externen Anbieter. Der Charme dieser Reihenfolge: Jede Station hat genau eine Verantwortung. Wenn etwas schiefgeht, wissen Sie, wo Sie suchen müssen. Und wenn ein Anbieter wechselt, merkt Lotsenhaus davon nichts. Ein Gateway ist kein Selbstzweck, und diese Folie wägt ab. Es lohnt sich, wenn mehrere Anwendungen dieselben Schlüssel und Budgets teilen, nicht nur Lotsenhaus.

6:19 Es lohnt sich, wenn Sie Kosten je Person sehen wollen, denn Open WebUI kann die Kennung des Nutzers als Kopfzeile mitschicken. Und es ist laut Doku die empfohlene Lösung, wenn ein Anbieter vom Schema abweicht. Dann übersetzt das Gateway, und Open WebUI bekommt saubere Antworten. Die Gegenrechnung gehört aber dazu. Im Pilot mit zwei Endpunkten lohnt es sich oft noch nicht, denn jede zusätzliche Schicht ist auch eine zusätzliche Fehlerquelle.

6:45 Bewusst entscheiden, nicht reflexhaft einbauen. Diese Tabelle ist eine kleine Landkarte für die Fehlersuche. Die Logik dahinter: Jedes Fehlerbild hat eine bevorzugte Heimat. Statuscodes für fehlende Rechte deuten auf Schlüssel, ein erschöpftes Kontingent auf das Anbieterkonto. Zeitüberschreitungen und zerstückeltes Markdown entstehen dagegen oft gar nicht beim Modell, sondern im Reverse Proxy oder bei zu knappen Zeitlimits.

7:11 Und die leere Antwort mit Werkzeug kennen Sie schon aus den Stolpersteinen. Den wichtigsten Rat gibt die Fußzeile. Testen Sie zuerst den Anbieter direkt, dann über das Gateway. Erst so trennen Sie einen Fehler des Anbieters von einem Fehler in Ihrer eigenen Kette.

Modelle auswählen

7:27 Die Leitungen liegen. Jetzt die Frage, welches Modell durch sie laufen soll. Und die ehrliche Antwort beginnt mit einem Satz, der Ranglisten-Fans enttäuscht: Das stärkste Modell ist selten das passende. Wer von einem Modell spricht, meint in Lotsenhaus eigentlich vier. Das Chatmodell kennen alle, es versteht, antwortet und ruft Werkzeuge auf.

7:48 Lokal ist das Qwen 3.6 mit 27 Milliarden Parametern, dazu ein Modell beim externen Anbieter. Im Hintergrund arbeiten aber weitere Modelle mit. Das Embedding-Modell macht Texte für die Suche vergleichbar, ein optionales Reranking-Modell sortiert Treffer nach Relevanz. Und ein Aufgabenmodell erzeugt Titel, Tags und Suchanfragen. Genau diese Nebenrollen werden oft vergessen, dabei laufen sie bei jedem Chat mit.

8:14 Embedding und Reranking wählen wir in Modul acht, gemeinsam mit der Wissensbasis Richtlinien. Statt auf Benchmarks zu schauen, prüft diese Tabelle Fähigkeiten, die Lotsenhaus wirklich braucht. Beachten Sie die rechte Spalte, denn sie trennt zwei Welten. Manche Fähigkeiten kann Open WebUI ein- und ausschalten, etwa Bildeingabe oder die Art des Tool Callings.

8:36 Andere sind schlicht Sache des Modells, wie gutes Deutsch oder verlässlich strukturierte Ausgaben. Da hilft kein Schalter, nur ein Test. Die mittlere Spalte sagt jeweils, wie man prüft, und fast immer lautet die Antwort: mit eigenen Fragen aus dem Arbeitsalltag. Ein Modell, das auf Englisch glänzt, aber Brandtners interne Texte holprig formuliert, hilft im Pilot wenig.

8:59 Warum gerade dieses Modell auf inferenz-01? Die Begründung kommt aus der Doku, nicht aus einer Rangliste. Sie nennt Qwen 3.6 mit 27 Milliarden Parametern als verifizierte Mindestklasse für lokales Tool Calling im nativen Modus. Kleinere lokale Modelle liefern laut Doku in mehrstufigen Werkzeugketten oft fehlerhaftes JSON, und das zeigt sich erst, wenn es darauf ankommt.

9:22 Dieselbe Klasse nennt die Doku auch für selbst verwaltete Memory. Damit deckt ein einziges Modell alle Pilotfälle ab, was Betrieb und Tests deutlich vereinfacht. Ein Bonus: Ollama trennt Überlegung und Antwort, und Sie können steuern, ob und wie viel das Modell nachdenkt. Das Kontextfenster ist das Arbeitsgedächtnis eines Modells, und es ist schneller voll, als man denkt.

9:45 Nicht nur die Frage zählt, sondern der Systemprompt, der ganze Verlauf, angehängte Dateien, Werkzeugdefinitionen und Wissen aus der Suche. Ollama legt die Größe abhängig vom Grafikspeicher fest, auf kleinen Karten sehr knapp. Und hier lauert eine Falle. Wer den Wert in Open WebUI einschaltet, überschreibt den Serverwert, und das Feld ist mit einem kleinen Wert vorbelegt. Das Ergebnis ist tückisch: Zu wenig Kontext kürzt still.

10:11 Mit Werkzeugen sehen Sie dann leere Antworten oder rohes JSON, ohne dass irgendwo ein Fehler steht.

Vorgaben und Wechsel

10:18 Ein Modell auszuwählen ist eine Entscheidung. Es im Betrieb zu halten und irgendwann zu ersetzen, ist ein Prozess. Und jeder solche Prozess braucht einen Vorher-Nachher-Vergleich. Parameter wie die Temperatur lassen sich auf vier Ebenen setzen, und die Regel ist einfach: Die speziellere Ebene gewinnt. Global gibt es Grundwerte, das Modell überschreibt sie, ein Chat überschreibt das Modell, und eine API-Anfrage behält immer ihren eigenen Wert.

10:45 Das klingt nach Freiheit, ist für ein Unternehmen aber eine Gestaltungsfrage. Darf jede Anwenderin selbst an den Reglern drehen? Die Fußzeile gibt die Antwort für Lotsenhaus. Ohne das Recht auf Chat-Steuerung gelten für Anwender die Modellwerte. Dadurch verhalten sich Assistenten für alle gleich, und eine Beschwerde lässt sich nachvollziehen, weil nicht jeder mit eigenen Einstellungen arbeitet.

11:08 Diese Vorgaben stehen in der compose.yaml von lotsenhaus-betrieb und gelten für alle Modelle. Das Muster: Lotsenhaus legt fest, womit ein neuer Chat startet, nämlich mit dem lokalen Qwen-Modell. Eine niedrige Temperatur sorgt für sachliche, gut reproduzierbare Antworten, wie man sie für Richtlinien und Projekttexte möchte.

11:27 Auch Titel und Tags erzeugt dasselbe lokale Modell, damit keine Inhalte nebenbei nach draußen wandern. Dazu ein Fallback, falls ein Modell fehlt, und ein Cache für die Modellliste. Die Fußzeile erklärt ein Detail, das sonst Rätsel aufgibt: Der Fallback greift nur, wenn ein Standardmodell gesetzt ist, und genau das erledigt hier die erste Zeile.

11:48 Ein Modellwechsel ist wie ein Umzug im laufenden Betrieb. Die alte Wohnung kündigt man nicht, bevor die neue eingerichtet ist. Deshalb wird das neue Modell zusätzlich geladen, das alte bleibt aktiv. Dann läuft der Testdatensatz mit beiden nebeneinander, und die Ergebnisse werden gegen die Akzeptanzkriterien aus Modul eins bewertet, nicht gegen das Bauchgefühl.

12:10 Erst danach werden die Assistenten gesichert und umgestellt. Und das alte Modell verschwindet erst nach einer Beobachtungsfrist. Die Fußzeile erklärt, warum diese Vorsicht nötig ist. Löschen entfernt ein Modell vom Ollama-Server, und zwar für alle, die diese Verbindung nutzen. Die erste Falle versteckt sich in einem harmlos klingenden Knopf.

12:31 Alle Modelle zu aktualisieren zieht neue Stände derselben Tags, und auch das ist ein Modellwechsel, nur ohne Vergleich. Die zweite verwirrt bei der Fehlersuche: Ein bereits geladenes Modell läuft nach dem Update mit der alten Version weiter, bis es entladen wird. Die dritte trifft die Assistenten. Wer ein Basismodell abschaltet statt es nur auszublenden, lässt alle darauf aufbauenden Assistenten mit einer Fehlermeldung scheitern. Und die vierte ist ein Denkfehler.

12:57 Daumen hoch und Daumen runter zeigen, was Menschen gefällt, aber nicht, ob eine Antwort fachlich stimmt.

Übung

13:04 Jetzt sind Sie dran. Zwei Endpunkte, ein eigener Testdatensatz und am Ende eine Empfehlung, die Sie gegenüber Datenschutz und Fachbereichen begründen können. In dieser Übung geht es nicht darum, einen Sieger zu küren. Es geht um die Fähigkeit, eine Modellwahl so zu begründen, dass sie jemand anderes nachvollziehen kann.

13:23 Sie binden einen lokalen und einen externen Endpunkt an und vergleichen beide mit Fragen, die Sie selbst zusammenstellen. Fertig sind Sie, wenn beide Modelle in Lotsenhaus antworten, je Modell zehn Testfragen bewertet sind und Ihre Empfehlung ausdrücklich sagt, für welche Datenklassen sie gilt. Ein Hinweis, der wichtiger ist, als er aussieht: Der externe Endpunkt darf nur Daten bis intern sehen. Ihr Testdatensatz enthält also nichts Vertrauliches.

13:49 Der Ablauf folgt dem Modul. Zuerst die lokale Verbindung zu inferenz-01 prüfen und das Qwen-Modell bereitstellen, dann die externe Verbindung anlegen und tatsächlich prüfen, nicht nur speichern. Die zehn Testfragen stammen aus IT, Projektmanagement und interner Kommunikation, also aus dem Alltag der Pilotbereiche. Im Vergleich nebeneinander achten Sie auf Richtigkeit, Antwortzeit und Format. Am Ende steht eine Empfehlung mit Grenzen und offenen Risiken.

14:16 Die Fußzeile mahnt zur Bescheidenheit: Eine einzelne Messung sagt wenig über das Verhalten unter Last. Im nächsten Modul machen wir aus diesen Modellen Assistenten mit einem klaren fachlichen Auftrag.