Routing und Modellauswahl: Das Zusammenspiel von Kanälen, Modellen und Clients
Bei der Arbeit mit einem KI-Gateway sorgen drei Konzepte am häufigsten für Verwirrung: Kanäle, Modelle und Clients. Wer ihr Zusammenspiel versteht, kann das Routing korrekt konfigurieren und Fragen wie „Warum ist meine Anfrage nicht über den erwarteten Kanal gelaufen?" gar nicht erst aufkommen lassen.
Drei Grundkonzepte
- Kanal ist eine Upstream-Verbindung: etwa eine Ollama-Instanz oder ein Konto bei einem Cloud-Anbieter.
- Modell ist eine Fähigkeit auf einem Kanal: zum Beispiel ein konkreter Modellname wie
qwen3:8b. - Client ist dein AI-Tool für den Alltag: Claude Code, Codex, opencode und andere.
Ihr Verhältnis zueinander ist eine unidirektionale Kette:
Client → (virtueller Schlüssel) → Gateway (Routing-Strategie) → Kanal → Modell
Bei jeder Anfrage legt der Client den Modellnamen in der Anfrage fest. Das Gateway sucht anhand dieses Modellnamens den Kanal, der ihn bedienen kann, und leitet die Anfrage dorthin weiter.
Was bedeutet „Modell (Kanalname)" in der Modellliste?
In der Modellauswahl von Clients wie Claude Code oder opencode siehst du Einträge wie qwen3:8b (Ollama Qwen3). Der Name in den Klammern gibt den Quellkanal dieses Modells an – nicht etwa „eine weitere Verbindung":
- Zwischen deinem Client und dem Gateway besteht immer nur eine einzige Verbindung (eine Adresse + ein virtueller Schlüssel).
- Ein und dasselbe Modell kann auch auf mehreren Kanälen konfiguriert sein. In der Auswahl wird dennoch nur eine Zeile angezeigt (in Klammern erscheint einer der Quellkanäle). Über welchen Kanal eine Anfrage tatsächlich bedient wird, entscheidet die Routing-Strategie (siehe unten).
Die drei Routing-Modi: Fixed, Failover und Balanced
Die Routing-Strategie beantwortet folgende Frage: Wenn mehrere Kanäle dasselbe Modell bedienen können – welcher wird genutzt?
| Modus | Verhalten | Geeignete Szenarien |
|---|---|---|
| Fixed (fest) | Verwendet immer denselben Kanal | Stabile Kanalqualität, wenn die Quelle fixiert werden soll |
| Failover (Primär/Backup) | Wechselt bei Ausfall des Hauptkanals oder erschöpftem Kontingent der Reihe nach zu den Backup-Kanälen | Konfigurationen mit primärem Kanal und Ersatzkanälen |
| Balanced (Lastverteilung) | Verteilt die Anfragen abwechselnd auf die verfügbaren Kanäle | Lastaufteilung über mehrere gleichwertige Kanäle |
Zwei wichtige Abgrenzungen:
- Routing wechselt nur zwischen Kanälen, niemals zwischen Modellen. Welches Modell angefragt wird, bestimmt immer dein Client – das Gateway tauscht dir kein Modell aus.
- Unterschiedliche Modelle laufen ohnehin über ihre jeweils eigenen Kanäle. Balanced bedeutet nicht „diesmal das Modell von Kanal A, nächstes Mal das von Kanal B" – es rotiert nur zwischen den Kanälen ein und desselben Modells.
Das Modell bestimmt der Client: So wechselst du das Modell
Das Gateway leitet nur weiter: Dein Tool schickt bei jeder Anfrage den Modellnamen mit, und das Gateway routet entsprechend. Der Modellwechsel geschieht im Client:
- opencode: Gib in der TUI
/modelsein, um ein Modell zu wählen; oder konfiguriere inopencode.jsondie Feldermodel(Hauptmodell) undsmall_model(für leichtgewichtige Aufgaben wie die Titelgenerierung). - Claude Code: Wechsle das Modell mit dem Befehl
/model. - Codex: Gib das Modell über den Parameter
-m <model>oder in der Konfigurationsdatei an.
Tägliche Tools sicher an das Gateway anbinden
Befürchtest du Auswirkungen auf deinen Arbeitsalltag? Folge diesem Ablauf:
- Erst mit einem Nebenprojekt testen: Führe die Ein-Klick-Anbindung in einem unwichtigen Projektverzeichnis durch und vergewissere dich, dass dein Workflow normal läuft.
- Mit einer Anfrage prüfen: Sende eine Testanfrage und schau auf der Seite „Nutzungsverlauf" nach, bei welchem Modell und welchem Kanal sie gelandet ist und welche Kosten angefallen sind.
- Jederzeit rückgängig machen: Stoppe die Übernahme auf der Seite „Anbindungsverwaltung". Nach dem Stopp werden die von ServBay geschriebenen Konfigurationen entfernt und die im Zuge der Übernahme erstellten virtuellen Schlüssel widerrufen; deine zuvor vorgenommenen benutzerdefinierten Konfigurationen werden nicht automatisch wiederhergestellt – passe sie bei Bedarf manuell an. Die Änderung tritt nach einem Neustart des Clients in Kraft.
Zusammenfassung
- Kanal = Upstream-Verbindung; Modell = Fähigkeit auf einem Kanal; den Modellnamen gibt der Client bei jeder Anfrage an.
- Die Routing-Strategie wählt ausschließlich zwischen den Kanälen ein und desselben Modells: Fixed (fest), Failover (Primär/Backup), Balanced (Rotation).
- Wechsle Modelle in der Modellauswahl des Clients; prüfe auf der Seite „Nutzungsverlauf" die Zuordnung und Kosten jeder einzelnen Anfrage.
