Skip to main content
Inteligentny routing jest w wersji beta. Sygnały oceny, wartości domyślne i zakres konfiguracji mogą się zmieniać między wydaniami; nagłówki odpowiedzi i metryki pozwalają zweryfikować każdą podjętą decyzję.

​
Przegląd

Inteligentny routing składa się z dwóch licencjonowanych rozszerzeń, które współpracują z modelami wirtualnymi z Core:
  • Smart tier routing odpowiada na pytanie: na jaki poziom jakości zasługuje ten request? Klasyfikuje skonfigurowany alias modelu do poziomu easy lub hard przed wyborem providera, więc krótki czat trafia do taniego modelu, a praca wymagająca intensywnego rozumowania, kodu lub narzędzi – do mocnego.
  • Adaptive routing odpowiada na pytanie: który provider w ramach tego poziomu? Wybiera cel upstream z puli modelu wirtualnego na podstawie obserwowanych opóźnień, błędów, okresów cooldownu i skonfigurowanego celu kosztowego lub opóźnieniowego.
Oba mechanizmy się nakładają: request o model: "normal" jest przepisywany na normal-easy lub normal-hard, a jeśli którykolwiek z nich jest modelem wirtualnym ze strategią adaptive, selektor wybiera dla niego najlepszego providera.

​
Smart tier routing

Skonfiguruj alias z poziomami, używając zwykłych nazw modeli GoModel. Celami poziomów mogą być konkretne modele lub modele wirtualne:
Przepisywane są tylko aliasy wymienione w PRO_SMART_ROUTING_ROUTES; każda inna nazwa modelu przechodzi bez zmian. Bez skonfigurowanych tras funkcja jest bezczynna, a logi startowe wyświetlają podpowiedź.

​
Jak oceniany jest request

Klasyfikacja jest deterministyczna, działa w procesie i nie wywołuje żadnego modelu. Request, który jawnie prosi o reasoning (reasoning_effort medium lub wyższy albo blok thinking Anthropic), trafia od razu do poziomu hard. W przeciwnym razie request zbiera punkty, a wynik równy lub wyższy od PRO_SMART_ROUTING_THRESHOLD (domyślnie 4) wybiera poziom hard: Przy wartościach domyślnych sam krótki fragment kodu (3) pozostaje na poziomie easy, a kod plus 2k znaków kontekstu (4) eskaluje. Obniż próg, aby wysyłać więcej ruchu na poziom hard, lub podnieś go, aby chronić tani poziom.

​
Przypinanie sesji

Wybrany poziom jest przypinany per kierowany alias i wykryta sesja (zobacz Utrzymywanie sesji). Przypięcie działa tylko w górę: rozmowa może przejść z easy na hard, gdy przypięcie jest aktywne, ale nigdy nie zostaje po cichu zdegradowana, więc kolejna wiadomość w rodzaju „thanks!” nie może przerzucić trudnej rozmowy na tani poziom ani unieważnić prompt cache jej providera. Przypięcie wygasa po PRO_SMART_ROUTING_SESSION_TTL bezczynności.

​
Konfiguracja smart tier routing

​
Nadpisywanie i podgląd decyzji

Wyślij X-GoModel-Smart-Routing: off, aby pominąć klasyfikację dla jednego requestu, lub X-GoModel-Tier: easy albo X-GoModel-Tier: hard, aby wymusić jego poziom bez zmiany przypięcia sesji. Każda kierowana odpowiedź raportuje decyzję:
Ten sam werdykt i jego uzasadnienie są zapisywane w szczegółach rewizji audytu. Prometheus udostępnia metryki requestów, eskalacji i wyników pod prefiksem gomodel_pro_smartroute_; histogram wyników służy do strojenia progu na podstawie rzeczywistego ruchu.

​
Adaptive routing

Adaptive routing zastępuje strategie round_robin i cost z Core selektorem uwzględniającym stan zdrowia celów. Jest rejestrowany raz przy starcie dla całego gatewaya, ale używają go tylko modele wirtualne skonfigurowane ze strategy: adaptive – każdy inny model wirtualny zachowuje swoją strategię.
W dashboardzie adaptive pojawia się na liście strategii modelu wirtualnego tylko wtedy, gdy działa build Pro z uprawnieniem routing. W buildzie open source model wirtualny ze strategy: adaptive wraca do round-robin.

​
Jak wybierany jest cel

Wybór działa metodą power-of-two-choices: losowane są dwa kandydaty proporcjonalnie do ich wag, a wygrywa ten z mniejszym chwilowym obciążeniem (szacowane opóźnienie × requesty w toku). Wagi są przeliczane dla każdego requestu na podstawie stanu w procesie – na ścieżce requestu nie ma zewnętrznego magazynu.
  • Opóźnienie – każdy cel utrzymuje szacunek opóźnienia peak-EWMA (czas do pierwszego bajtu dla streamów), zasilany przez każdą próbę do upstreamu, w tym retry i failovery.
  • Cooldowny – 429 uruchamia cooldown o długości PRO_ROUTING_COOLDOWN_BASE, który podwaja się przy każdym kolejnym wyzwoleniu aż do PRO_ROUTING_COOLDOWN_MAX; 401, 403 i 404 od razu dostają maksymalny cooldown; powtarzające się błędy 5xx lub sieciowe uruchamiają cooldown po trzech z rzędu. Cele w cooldownie są pomijane, dopóki dostępny jest jakikolwiek inny cel.
  • Minimalna waga – każdy cel poza cooldownem zachowuje co najmniej PRO_ROUTING_MIN_WEIGHT_FRACTION wagi najcięższego kandydata, więc wolny lub dochodzący do siebie cel nadal otrzymuje strużkę ruchu, a jego powrót do sprawności jest potwierdzany na prawdziwych requestach.
  • Ciepły prompt cache – provider, który ostatnio obsłużył wykrytą sesję, dostaje wzmocnienie PRO_ROUTING_WARM_CACHE_WEIGHT na czas PRO_ROUTING_WARM_CACHE_TTL, więc rozmowa pozostaje przy tych samych danych uwierzytelniających, endpoincie i regionie, dopóki jej prompt cache jest prawdopodobnie ciepły. Cel w cooldownie traci to wzmocnienie.
Cel optymalizacji decyduje, jak cena wpływa na wagę:

​
Konfiguracja adaptive routing

​
Utrzymywanie sesji i stan zdrowia

Przy włączonym utrzymywaniu sesji (domyślnie) gateway przekazuje selektorowi cel, który już obsługuje daną sesję, i pozwala mu decydować, request po requeście, czy sesja go zachowa – zawsze, gdy dostępny jest więcej niż jeden cel. (Przy jednym dostępnym celu nie ma wyboru, więc selektor jest pomijany). Przypięcie trwa, dopóki cel jest zdrowy – przeniesienie sesji przekreśla prompt cache providera, który przypięcie ma chronić, więc nawet znacznie tańsza lub znacznie szybsza alternatywa go nie przejmie. Przypięcie jest zwalniane tylko wtedy, gdy jego cel wchodzi w cooldown, a sesja zostaje wtedy przypięta do celu wybranego przez selektor. To jedyna ocena, której gateway nie może dokonać samodzielnie: cel, który zwraca 429 lub przekracza timeouty, nadal jest skonfigurowanym, obsługiwanym przez katalog celem, więc przechodzi każdą kontrolę stosowaną przez przypięcie w Core. Bez selektora na ścieżce sesja agenta – jedno id sesji, tysiące requestów – przypina się przy pierwszym requeście i jedzie na zawodnym celu przez cały czas życia przypięcia, co widać jedynie jako opóźnienia i zmarnowane wydatki w upstreamie, bo failover nadal zwraca klientowi 200. gomodel_pro_routing_session_affinity_total{outcome} zlicza przypięcia honored i przypięcia released z powodu cooldownu, więc to zachowanie jest widoczne w Prometheusie, a nie tylko na fakturze od providera. Metryki Prometheus używają prefiksu gomodel_pro_routing_ (wybory, odrzucenia, wyniki, cooldowny, powinowactwo sesji i gauge szacowanego opóźnienia). Stan oceny jest per węzeł; repliki uczą się niezależnie i niczego nie współdzielą.
Ostatnia modyfikacja 24 października 2026