Den Modellwechsel zur Konfigurationsänderung machen

TL;DR

Ein Gateway mit logischen Modellnamen entkoppelt Anwendungen vom Anbieter — der Wechsel wird zur Konfigurationsänderung. Vier Dinge wandern trotzdem nicht automatisch mit: Systemanweisungen, Werkzeugdefinitionen, Ausgabeformate und die Kalibrierung. Wer das einplant, wechselt in einem Tag statt in einem Projekt.

Warum das eine Architekturfrage ist

Modelle veralten schneller als jede andere Komponente Ihres Aufbaus. In den letzten anderthalb Jahren sind mehrere Modellgenerationen erschienen und wieder abgelöst worden. Anbieter stellen Versionen ab, teils mit Fristen von wenigen Monaten.

Wenn der Anbietername in Ihrem Anwendungscode steht, ist jeder dieser Vorgänge ein Entwicklungsvorhaben. Wenn er in einer Konfigurationsdatei steht, ist es eine Zeile.

Das ist auch ein Punkt für die Lieferantenbewertung: Ein Modellanbieter, den Sie nicht wechseln können, ist ein Klumpenrisiko. Für Unternehmen im Anwendungsbereich von NIS2 ist das ausdrücklich zu betrachten — die Einordnung steht im Beitrag zu NIS2 und der KI-Plattform.

Der Kern: logische Namen statt Modellnamen

Der ganze Trick besteht darin, dass Ihre Anwendungen nie einen Herstellernamen kennen. Sie kennen eine Rolle.

# config.yaml des Gateways
model_list:
  # Der Alltag — heute lokal, morgen vielleicht anders
  - model_name: standard
    litellm_params:
      model: openai/qwen3-30b-a3b
      api_base: http://vllm.intern:8000/v1

  # Anspruchsvolle Aufgaben
  - model_name: anspruchsvoll
    litellm_params:
      model: azure/<ihr-deployment>
      api_base: https://ihre-instanz.openai.azure.com
      api_key: os.environ/AZURE_API_KEY

  # Vertrauliches — bewusst ohne Ausweichroute nach außen
  - model_name: vertraulich
    litellm_params:
      model: openai/qwen3-30b-a3b
      api_base: http://vllm.intern:8000/v1

router_settings:
  # Fällt das Standardmodell aus, übernimmt das größere.
  # 'vertraulich' steht bewusst NICHT in dieser Liste.
  fallbacks:
    - standard: ["anspruchsvoll"]

Der Code der Anwendung enthält damit nur noch model="standard". Ein Wechsel des dahinterliegenden Modells ist eine geänderte Zeile in der Konfiguration und ein Neuladen.

Ein Detail, das in der Praxis wichtiger ist als es aussieht: Das Modell vertraulich darf keine Ausweichroute nach außen haben. Sonst schickt Ihr System bei einem Ausfall des lokalen Servers genau die Daten in die Cloud, die dort nicht hinsollen — und niemand merkt es, weil der Ausweichmechanismus lautlos funktioniert. Das ist ein Fehler, der uns in einer übernommenen Installation tatsächlich begegnet ist.

Die vier Dinge, die trotzdem Arbeit machen

Damit das nicht als "einfach umschalten" gelesen wird.

Systemanweisungen. Modelle reagieren unterschiedlich auf Formulierungen. Eine Anweisung, die bei einem Modell zuverlässig knappe Antworten erzeugt, führt bei einem anderen zu Aufzählungen. Rechnen Sie mit Nacharbeit an den Anweisungen — das ist der häufigste Grund, warum ein Wechsel sich "schlechter anfühlt", obwohl das neue Modell objektiv besser ist.

Werkzeugdefinitionen. Wenn Ihre Anwendung Werkzeuge aufruft, unterscheiden sich Modelle darin, wie zuverlässig sie das richtige Werkzeug wählen und die Parameter füllen. Beschreibungen, die bei einem Modell reichen, sind beim nächsten zu knapp.

Ausgabeformate. Verlangt Ihre Anwendung JSON nach einem Schema, prüfen Sie die Fehlerquote nach dem Wechsel. Bei lokalen Modellen können Sie die Ausgabe technisch gegen ein Schema einschränken, bei Cloud-Modellen hängt es vom Anbieter ab.

Kalibrierung von Schwellenwerten. Wenn irgendwo im System ein Wert steht, der auf Modellverhalten abgestimmt wurde — ein Ähnlichkeitsschwellwert, eine Konfidenzgrenze, ein Zeichenlimit —, gilt er nach dem Wechsel möglicherweise nicht mehr.

Der Ablauf, der sich bewährt hat

Fünf Schritte, in einem Tag machbar, wenn die Vorarbeit steht:

1. Neues Modell unter neuem logischem Namen einhängen, etwa standard-neu. Nichts umschalten.
2. Gegen den Testsatz messen. Wiederfindung ist unverändert, weil der Abruf gleich bleibt — was sich ändert, ist Treue und Relevanz. Die Verfahren stehen im Beitrag zur Messung der RAG-Qualität.
3. Bei auffälligen Abweichungen die Systemanweisung nachziehen und erneut messen. Diesen Schritt nicht überspringen — die erste Messung eines neuen Modells mit der alten Anweisung ist regelmäßig zu pessimistisch.
4. Einen Teil des Verkehrs umleiten. Ein Gateway kann gewichtet verteilen: 10 Prozent auf das neue Modell, den Rest auf das alte. Eine Woche laufen lassen, Rückmeldungen sammeln.
5. Umschalten — der logische Name standard zeigt auf das neue Modell. Den alten Endpunkt zwei Wochen stehen lassen, damit die Rückkehr eine Zeile bleibt.

Der Testsatz aus Schritt 2 ist die Voraussetzung für dieses ganze Vorgehen. Ohne ihn ist ein Modellwechsel eine Gefühlsentscheidung, und die dreht sich beim ersten Nutzer, der sich beschwert.

Was Sie nicht entkoppeln können

Ehrlichkeitshalber, weil das Gateway gern als Universallösung dargestellt wird:

Das Einbettungsmodell. Wenn Sie es wechseln, müssen alle Vektoren neu berechnet werden — bei einer Million Abschnitten ein Vorgang von Stunden bis Tagen. Diese Entscheidung verdient mehr Sorgfalt als die Wahl des Sprachmodells, und sie sollte selten fallen.

Modellspezifische Funktionen. Wenn Ihre Anwendung eine Besonderheit eines bestimmten Anbieters nutzt, ist genau das die Bindung, die Sie vermeiden wollten. Prüfen Sie vor der Nutzung, ob es einen anbieterübergreifenden Weg gibt.

Die Anwenderakzeptanz. Menschen gewöhnen sich an einen Antwortstil. Ein Wechsel, der objektiv eine Verbesserung ist, kann sich für die Nutzer nach einer Verschlechterung anfühlen. Kündigen Sie ihn an, statt ihn stillschweigend zu vollziehen.

Häufig gestellte Fragen

Wie vermeide ich Abhängigkeit von einem Modellanbieter?

Über ein Gateway mit logischen Modellnamen: Anwendungen sprechen eine Rolle an — etwa standard oder vertraulich —, und welcher Anbieter dahintersteht, entscheidet die Gateway-Konfiguration. Der Wechsel wird damit zu einer geänderten Zeile statt zu einem Entwicklungsvorhaben in mehreren Codebasen.

Was muss beim Modellwechsel angepasst werden?

Vier Dinge: Systemanweisungen, weil Modelle unterschiedlich auf Formulierungen reagieren; Werkzeugbeschreibungen, weil die Zuverlässigkeit der Auswahl variiert; Ausgabeformate, wenn strukturierte Antworten verlangt werden; und alle Schwellenwerte, die auf das Verhalten des alten Modells kalibriert wurden.

Sollte ein vertrauliches Modell eine Ausweichroute haben?

Nein, und das ist ein sicherheitsrelevanter Punkt. Wenn ein als vertraulich gekennzeichnetes Modell bei einem Ausfall automatisch auf ein Cloud-Modell ausweicht, verlassen genau die Daten das Haus, für die die lokale Verarbeitung eingerichtet wurde. Ein Fehler ist in diesem Fall das gewünschte Verhalten.

Wie teste ich ein neues Modell im laufenden Betrieb?

Über gewichtete Verteilung im Gateway: Ein kleiner Anteil des Verkehrs geht auf das neue Modell, der Rest bleibt beim alten. Nach einer Woche haben Sie sowohl Kennzahlen als auch Anwenderrückmeldungen. Vorher sollte das neue Modell bereits gegen den Testsatz gemessen worden sein, damit offensichtliche Verschlechterungen keine Nutzer erreichen.

Kann ich auch das Einbettungsmodell über das Gateway wechseln?

Technisch ja, praktisch nicht ohne Folgen. Ein Wechsel des Einbettungsmodells macht alle vorhandenen Vektoren unbrauchbar — der gesamte Index muss neu berechnet werden. Das ist bei größeren Beständen ein Vorgang von Stunden bis Tagen und sollte deshalb eine seltene, gut begründete Entscheidung sein.

Der nächste Schritt

Suchen Sie in Ihrem Code nach Herstellernamen und Modellbezeichnungen. Jede Fundstelle ist eine Stelle, die beim nächsten Modellwechsel angefasst werden muss. Wenn es mehr als eine ist, gehört ein Gateway davor — bevor der nächste Anbieter eine Version abkündigt. Wir richten das gern mit ein.