Skip to main content
Intelligentes Routing befindet sich in der Beta. Bewertungssignale, Standardwerte und Konfigurationsoptionen können sich zwischen Releases ändern; mit den Response-Headern und Metriken können Sie jede getroffene Entscheidung überprüfen.

​
Übersicht

Intelligentes Routing umfasst zwei lizenzierte Erweiterungen, die mit den virtuellen Modellen des Core zusammenspielen:
  • Smart Tier Routing beantwortet die Frage Welche Qualitätsstufe verdient dieser Request? Es ordnet einen konfigurierten Modell-Alias vor der Provider-Auswahl der Stufe easy oder hard zu, sodass kurzer Chat an ein günstiges Modell geht und Reasoning-, Code- oder Tool-intensive Arbeit an ein leistungsstarkes.
  • Adaptives Routing beantwortet die Frage Welcher Provider innerhalb dieser Stufe? Es wählt aus dem Pool eines virtuellen Modells ein Upstream-Ziel anhand der beobachteten Latenz, Fehler, Cooldowns und des konfigurierten Kosten- oder Latenzziels.
Beide lassen sich kombinieren: Ein Request für model: "normal" wird zu normal-easy oder normal-hard umgeschrieben, und ist eines davon ein virtuelles Modell mit der Strategie adaptive, wählt der Selektor anschließend den besten Provider dafür.

​
Smart Tier Routing

Konfigurieren Sie einen gestuften Alias mit gewöhnlichen GoModel-Modellnamen. Die Ziele der Stufen können konkrete Modelle oder virtuelle Modelle sein:
Nur in PRO_SMART_ROUTING_ROUTES aufgeführte Aliase werden umgeschrieben; jeder andere Modellname wird unverändert durchgereicht. Sind keine Routen konfiguriert, ist das Feature inaktiv, und beim Start wird ein Hinweis protokolliert.

​
Wie ein Request bewertet wird

Die Klassifizierung ist deterministisch, läuft im Prozess und ruft kein Modell auf. Ein Request, der explizit Reasoning anfordert (reasoning_effort ab medium oder ein Anthropic-thinking-Block), geht direkt an die Stufe hard. Andernfalls sammelt der Request Punkte, und ein Wert ab PRO_SMART_ROUTING_THRESHOLD (Standardwert 4) wählt die Stufe hard: Mit den Standardwerten bleibt ein kurzes Code-Snippet allein (3) auf der Stufe easy, während Code plus 2k Zeichen Kontext (4) eskaliert. Senken Sie den Schwellenwert, um mehr Traffic an die Stufe hard zu senden, oder erhöhen Sie ihn, um die günstige Stufe zu schützen.

​
Session-Pinning

Die gewählte Stufe wird pro gerouteten Alias und erkannter Session festgehalten (siehe Session Keeping). Das Pinning eskaliert nur: Eine Unterhaltung kann bei aktivem Pin von easy zu hard wechseln, wird aber nie stillschweigend herabgestuft. Eine Folgenachricht wie „thanks!“ kann eine anspruchsvolle Unterhaltung daher nicht auf die günstige Stufe zurückwerfen oder ihren Prompt-Cache beim Provider ungültig machen. Der Pin läuft nach PRO_SMART_ROUTING_SESSION_TTL Inaktivität ab.

​
Smart Tier Routing konfigurieren

​
Eine Entscheidung überschreiben und prüfen

Senden Sie X-GoModel-Smart-Routing: off, um die Klassifizierung für einen Request zu umgehen, oder X-GoModel-Tier: easy bzw. X-GoModel-Tier: hard, um seine Stufe zu erzwingen, ohne den Session-Pin zu ändern. Jede geroutete Response meldet die Entscheidung:
Dasselbe Urteil samt Begründung wird im Detail der Audit-Revision erfasst. Prometheus stellt Metriken zu Requests, Eskalationen und Bewertungen unter dem Präfix gomodel_pro_smartroute_ bereit; mit dem Histogramm der Bewertungen stimmen Sie den Schwellenwert auf echten Traffic ab.

​
Adaptives Routing

Adaptives Routing ersetzt die Core-Strategien round_robin und cost durch einen zustandsbewussten Selektor. Er wird beim Start einmal für das gesamte Gateway registriert, aber nur virtuelle Modelle, die mit strategy: adaptive konfiguriert sind, verwenden ihn – jedes andere virtuelle Modell behält seine Strategie.
Im Dashboard erscheint adaptive in der Strategie-Auswahl für virtuelle Modelle nur, wenn ein Pro-Build mit der Berechtigung routing läuft. Bei einem Open-Source-Build fällt ein virtuelles Modell mit strategy: adaptive auf Round-Robin zurück.

​
Wie ein Ziel gewählt wird

Die Auswahl folgt dem Power-of-Two-Choices-Verfahren: Zwei Kandidaten werden proportional zu ihren Gewichten gezogen, und der mit der geringeren momentanen Last (Latenzschätzung × laufende Requests) gewinnt. Die Gewichte werden pro Request aus dem Zustand im Prozess neu berechnet – im Request-Pfad gibt es keinen externen Speicher.
  • Latenz – jedes Ziel führt eine Peak-EWMA-Latenzschätzung (Time to First Byte bei Streams), gespeist von jedem Upstream-Versuch, einschließlich Retries und Failovers.
  • Cooldowns – ein 429 startet einen Cooldown von PRO_ROUTING_COOLDOWN_BASE, der sich bei jedem aufeinanderfolgenden Auslöser bis zu PRO_ROUTING_COOLDOWN_MAX verdoppelt; 401, 403 und 404 lösen sofort den maximalen Cooldown aus; wiederholte 5xx- oder Netzwerkfehler lösen nach drei in Folge einen Cooldown aus. Ziele im Cooldown werden übersprungen, solange ein anderes Ziel verfügbar ist.
  • Gewichtsuntergrenze – jedes Ziel, das sich nicht im Cooldown befindet, behält mindestens PRO_ROUTING_MIN_WEIGHT_FRACTION des Gewichts des schwersten Kandidaten. So erhält ein langsames oder sich erholendes Ziel weiterhin ein wenig Traffic, und seine Erholung wird an echten Requests nachgewiesen.
  • Warmer Prompt-Cache – der Provider, der eine erkannte Session zuletzt bedient hat, wird für PRO_ROUTING_WARM_CACHE_TTL um PRO_ROUTING_WARM_CACHE_WEIGHT bevorzugt, sodass eine Unterhaltung bei denselben Zugangsdaten, demselben Endpunkt und derselben Region bleibt, solange ihr Prompt-Cache wahrscheinlich warm ist. Ein Ziel im Cooldown verliert diesen Bonus.
Das Ziel (Objective) bestimmt, wie der Preis in das Gewicht einfließt:

​
Adaptives Routing konfigurieren

​
Session Keeping und Zustand

Bei aktiviertem Session Keeping (Standard) übergibt das Gateway dem Selektor das Ziel, das die jeweilige Session bereits bedient, und lässt ihn Request für Request entscheiden, ob die Session es behält – sofern mehr als ein Ziel infrage kommt. (Bei nur einem infrage kommenden Ziel gibt es nichts zu wählen, daher wird der Selektor übersprungen.) Der Pin bleibt bestehen, solange dieses Ziel gesund ist – das Verschieben einer Session verwirft den Prompt-Cache beim Provider, den der Pin schützen soll. Daher übernimmt selbst eine deutlich günstigere oder deutlich schnellere Alternative die Session nicht. Ein Pin wird nur freigegeben, wenn sein Ziel in einen Cooldown geht, und die Session wird dann stattdessen an das Ziel gebunden, das der Selektor wählt. Das ist die eine Beurteilung, die das Gateway nicht allein treffen kann: Ein Ziel, das 429-Fehler liefert oder in Timeouts läuft, ist weiterhin ein konfiguriertes, vom Katalog unterstütztes Ziel und besteht damit jede Prüfung, die der Core-Pin anwendet. Ohne den Selektor im Pfad bindet sich eine Agenten-Session – eine Session-ID, Tausende von Requests – bei ihrem ersten Request und bleibt für die gesamte Lebensdauer des Pins an einem fehlerhaften Ziel hängen. Das ist nur als Latenz und verschwendete Upstream-Ausgaben sichtbar, da das Failover dem Client weiterhin 200 liefert. gomodel_pro_routing_session_affinity_total{outcome} zählt beibehaltene (honored) und wegen eines Cooldowns freigegebene (released) Pins, sodass das Verhalten in Prometheus sichtbar ist und nicht erst auf einer Provider-Rechnung. Prometheus-Metriken verwenden das Präfix gomodel_pro_routing_ (Auswahlen, Ablehnungen, Ergebnisse, Cooldowns, Session-Affinität und ein Gauge für die Latenzschätzung). Der Bewertungszustand gilt pro Knoten; Replikas lernen unabhängig voneinander und teilen nichts.
Zuletzt geändert am 24. Oktober 2026