Infrastruktura routingu OrcaRouter: Routing świadomy sesji i eskalacja graniczna

ORCAROUTER · ARCHITEKTURA ROUTINGU

Każda brama LLM, która buforuje prompty, musi przypinać konwersację do jednego modelu. Każda brama, która przypina konwersację, podejmuje decyzję o routingu na podstawie najmniej informacyjnej tury tej konwersacji. To raport na temat tego kompromisu oraz mechanizmu warstwowej stickiness, który OrcaRouter dostarcza, aby go uniknąć.

Temat: OrcaRouter bramka LLM (Go / Gin / Redis) · Komponent: session affinity + Frontier Escalation engine · Metoda: Odtworzenie 400 sesji względem produkcyjnego kodu decyzyjnego · Data: 14 sierpnia 2026

STRESZCZENIE — Routing LLM na poziomie żądania — ocena każdego żądania niezależnie i kierowanie go do najtańszego odpowiedniego modelu — to podejście, któremu poświęcone są niemal wszystkie publikowane prace dotyczące routerów. Jest to jednak niewłaściwe podejście dla ruchu, który obecnie dominuje w wolumenie bramek: wieloturowe sesje agentowe, w których prompt w 90 % stanowi przeniesiony kontekst, a pamięć podręczna promptów dostawcy opłaca ciągłość. Zmiana modelu w trakcie rozmowy powoduje utratę 10-krotnej zniżki na współdzielony prefiks, dlatego bramki przypinają sesje. Ale przypięcie dokonane w turze 1 to przypięcie dokonane w turze z najmniejszą ilością dowodów i utrzymuje się przez cały czas trwania rozmowy.

100 / 100 — sesje latent-hard, których wynik w turze 1 jest nieodróżnialny od trywialnego

+16% — dryf wyniku trudności wynikający wyłącznie z długości transkryptu, przy identycznym poziomie trudności zadania

45% — kosztu bycia zawsze na granicy, dla 67 % jego pokrycia podczas twardego skrętu

0.019 — margines między dostarczoną bramką a sufitem realistycznych wyników

1 Dwa reżimy routingu

Brama LLM, która stanowi punkt wejścia do wielu dostawców, musi przy każdym żądaniu odpowiedzieć na jedno pytanie: który model to obsłuży? Istnieją dwa strukturalnie różne sposoby, aby na nie odpowiedzieć, a literatura i praktyka produkcyjna rozjechały się co do tego, który z nich ma znaczenie.

Routing na poziomie żądań traktuje każde żądanie jako niezależne. Scorer szacuje trudność zapytania lub przewidywaną jakość odpowiedzi, a żądanie jest kierowane do najtańszego modelu, który powinien sobie z nim poradzić. Jest to podejście charakterystyczne dla zasadniczo wszystkich opublikowanych prac nad routerami: RouteLLM trenuje routery na danych preferencyjnych, które osiągają 95 % jakości GPT-4 przy 14 % wywołań silnych modelisup>[1]/sup>; FrugalGPT kaskaduje modele od tanich do drogich z kontrolą akceptacji/odrzucenia i raportuje redukcję kosztów nawet o 98 %sup>[2]/sup>; RouterArena tworzy benchmark składający się z 8 400 zapytań, aby porównać routery właśnie pod tym względemsup>[3]/sup>. Jednostką analizy jest zapytanie.

Routing świadomy sesji

Powodem, dla którego istnieje routing świadomy sesji, nie jest elegancja. To arytmetyka.

2 Ekonomia cache, która sprawia, że stickiness jest obowiązkowy

W wieloturowej sesji agenta, prompt tury n jest promptem tury n−1 plus delta. Do tury 10 przenoszony prefiks stanowi przytłaczającą większość tokenów wejściowych. Każdy duży dostawca wycenia teraz ten prefiks różnie w zależności od tego, czy jest to trafienie w pamięć podręczną:

Tabela 1.Semantyka pamięci podręcznej promptów według dostawcy. Klucz pamięci podręcznej stanowią dokładny prefiks oraz klucz serwujący — zmiana modelu lub rotacja klucza to pełnopłatny odczyt na zimno.

OrcaRouter koduje dokładnie te czasy życia jako TTL pinów: mapę okien pamięci podręcznej dostawcy dla każdego typu kanału — 5 minut dla OpenAI, Anthropic i Gemini, 60 minut dla DeepSeek — z domyślną wartością 5 minut dla nieprzypisanego dostawcy. Pin kanał+klucz wygasa wraz z tym oknem, ponieważ nieaktualny indeks klucza nie ma wartości pamięci podręcznej i tylko zaburza równoważenie obciążenia. Ten modelowy pin, we wdrożeniu opartym na Redis i dla identyfikatora sesji kwalifikującego się do długiego pinu, utrzymuje się przez 30 dni — nie ze względu na wartość pamięci podręcznej, która już dawno nie istnieje, ale dla ciągłości formatu żądań. Zmiana modelu w trakcie rozmowy wymusza konwersję formatu żądań, która może być niezgodna z danymi: bloki myślenia i identyfikatory wywołań narzędzi niekoniecznie przetrwają tłumaczenie między schematami dostawców.

NIEDOCENIANY SZCZEGÓŁ

Pamięci podręczne promptów są indeksowane według klucza API, a nie według modelu. Brama, która przypina model, ale równoważy obciążenie między trzema kluczami na tym samym kanale, nadal w dwóch na trzy tury odczytuje z zimnej pamięci podręcznej. Dlatego pin kanału w OrcaRouter przechowuje {ChannelID, KeyIndex} zamiast identyfikatora kanału, i dlatego pin jest usuwany, gdy zapisany indeks klucza nie mapuje się już na aktywny klucz — klucz wzmocniony, ale rotowany, skłaniałby ku zimnej pamięci podręcznej, jednocześnie omijając równoważenie, co jest najgorszym z obu światów.

Przypięcia są miękkie w każdym przypadku: brak rozwiązywalnego identyfikatora sesji jest operacją pustą, wyłączony lub niezdrowy przypięty kanał ulega degradacji do normalnego zrównoważonego wyboru, a przypięcie do kanału o zerowej wadze w mieszanej puli jest pomijane, aby administrator opróżniający kanał nie został pokonany przez przyczepność. Nigdy nie powodują błędu żądania.

3 Pułapka: lepkość wyłącza router

Oto tryb awarii. W OrcaRouter ścieżce kodu przed eskalacją, dla routera świadomego sesji w dowolnej strategii innej niż DSL, pin sesja→model zwrócił

To byłoby do zniesienia, gdyby tura 1 była reprezentatywna. Systematycznie tak nie jest, z dwóch nakładających się powodów.

3.1 Tura 1 jest najmniej informacyjną turą.

Skalar trudności (service/model_router_difficulty.go) jest ważoną kombinacją liniową sześciu cech leksykalnych:

LogPromptTokens × 0.20 limit log(8001) ≈ 8.99

ReasoningCueCount × 0.15, limit 5

SystemPromptLogLen × 0.10 z limitem log(2001) ≈ 7.60

CodeKeywordDensity × 0.20 limit 5.0 (dopasowania na 100 znaków)

HasTools × 0.15 już 0/1

MathMarkerCount × 0,20, maksymalnie 5

Krótka wiadomość otwierająca bez historii uzyskuje niski wynik niemal z definicji: składnik tokenowy o wadze 0,20 jest blisko swojego minimum, a składniki rozumowania/matematyki uruchamiają się na słownictwie, którego użytkownik nie miał jeszcze powodu użyć. Sesje w związku z tym angażują się w model słabej puli w momencie, gdy informacji jest najmniej — a dzięki 30-dniowemu przypięciu modelu z zapleczem Redis, to zobowiązanie jest długotrwałe.

Rysunek 1. Średnia trudność ostatniej tury w zależności od tury konwersacji, dla 100 sesji latent-hard i 200 sesji prawdziwie łatwych, oceniana przez produkcyjny skorer. W turze 1 — turze, w której zapisywana jest pinezka — obie populacje są nieodróżnialne (0,210 wobec 0,208). Populacja trudna przekracza próg w turze 5. W polityce opartej wyłącznie na pinezce wszystkie 100 sesji latent-hard trafia do taniej puli, zanim zaistnieje jakikolwiek z tych dowodów.

3.2 Długość podszywa się pod trudność

Drugi problem jest bardziej subtelny i podważa oczywiste rozwiązanie. Jeśli po prostu ponownie uruchamiasz bramkę trudności co turę, uruchamiasz ją na wyniku obliczonym na podstawie całego połączonego transkryptu. Ten wynik ma wbudowany trend wzrostowy: człon LogPromptTokens z wagą 0.20 rośnie monotonicznie wraz z długością rozmowy, a dla każdej sesji agenta człony HasTools z wagą 0.15 i SystemPromptLogLen z wagą 0.10 są w praktyce stałymi minimami. Długa, nudna sesja wygląda na coraz trudniejszą.

Rysunek 2. Artefakt obciążenia długością, zmierzony na 60 sesjach składających się wyłącznie z trywialnych edycji („zmień nazwę tej zmiennej”, „dodaj sprawdzenie nil”). Wynik pełnego transkryptu dryfuje o +16 % przez 25 tur przy stałym poziomie trudności zadania; wynik ostatniej tury (delta) jest płaski. Naiwna ponowna ocena wyniku pełnego transkryptu w każdej turze eskalowałaby sesje za to, że są długie.

Poprawka, którą dostarcza OrcaRouter, to osobny delta-ekstraktor (service/model_router_delta.go), który ocenia tylko ostatnią turę — nowy tekst użytkownika oraz wszelkie wyniki narzędzi dołączone po ostatniej wiadomości asystenta — wykorzystując te same wagi i limity, ale celowo zerując SystemPromptLogLen, który nie jest częścią delty. Płaska niebieska linia na rysunku 2 to ten ekstraktor.

4 Projekt: warstwowa przyczepność

Naiwnym wyjściem z zablokowania po pierwszej turze jest ponowne przekierowywanie każdej tury — co sprowadza się do routingu na poziomie żądania i rezygnacji z pamięci podręcznej. Naiwnym rozwiązaniem w drugim kierunku jest uczynienie przypięcia pamięcią tego, że „ta sesja stała się trudna” — co nie potrafi wyrazić deeskalacji i nie może być objęte limitem. Projekt OrcaRouter odrzuca oba te podejścia.

Przeformułowanie: sesja jest przypięta do modelu w obrębie warstwy, i w Redis mały stan warstwy jest jedyną pamięcią eskalacji. Przypięcie modelu nigdy nie jest pamięcią.

Pule warstw. Silna warstwa to ostateczna pula eskalacji (escalation_pool, z domyślną wartością strong_pool routera). Warstwa bazowa to AllowedModels \ pula silnej warstwy; model należący do obu zbiorów należy do silnej warstwy. Wewnątrz warstwy bazowej podział na pasma trudności weak/mid/strong w gated_adaptive działa dokładnie tak jak wcześniej.

Piny przypisane do poziomu. Klucz przypięcia modelu w poziomie silnym otrzymuje sufiks :t:strong; poziom bazowy zachowuje starszy klucz bez zmian. Dlatego eskalacja zachowuje pin bazowy, więc sesja po deeskalacji — lub wznowiona po wygaśnięciu stanu poziomu — wraca na dokładnie ten model, na którym zaczęła, a nie na dowolnie ponownie wybrany model. Silne piny są zapisywane wyłącznie z krótkim TTL okna dostawcy: 30-dniowy silny pin przetrwałby 4-godzinny stan poziomu, który go uzasadniał.

Bramka uruchamia się najpierw. W selectByStrategy (service/model_router.go:1374) poziom jest ustalany z góry, zbiór kandydatów jest zawężany do puli tego poziomu, i tylko wtedy sprawdzany jest sticky pin — w obrębie tego poziomu. To jest strukturalna poprawka dla §3: obliczanie trudności i wyzwalacze eskalacji działają w każdej turze, zanim pin będzie mógł je zwarć.

4.1 Trzy klasy wyzwalaczy, uszeregowane według zaufania

Tabela 2. Wyzwalacze eskalacji. Żaden niejednoznaczny sygnał nigdy nie eskaluje samodzielnie; tylko wyraźna prośba klienta wyzwala działanie przy n=1, a nawet ona podlega limitom.

Trzy niezmienniki higieniczne mają kluczowe znaczenie. Strajki są deduplikowane według ID żądania za pomocą bufora pierścieniowego, więc przeplatane ponowienia klienta nie mogą być liczone podwójnie. Awaria infrastruktury nigdy nie jest awarią zdolności — 429, 5xx i fallbacki kanałów nigdy nie generują strajków; liczą się tylko sygnały jakości po sukcesie. A „tura” jest definiowana jako ukończone żądanie z rozliczonym sukcesem, które przeszło ocenę strajków, więc nieudane żądania nie liczą się ani do wygaszania strajków, ani do licznika czystych tur.

4.2 Rozwiązywanie jest czyste; zatwierdzanie jest odroczone.

Najistotniejszą właściwością strukturalną silnika jest to, że ResolveEscalation niczego nie zapisuje. Zwraca decyzję oraz listę oczekujących intencji. Dystrybutor stosuje te intencje w swoim bloku po sukcesie, na świeży odczyt w transakcji Redis WATCH. To jest istotne, ponieważ resolver działa na ścieżkach, które nigdy nie mogą mutować stanu: spekulatywne rozwiązywanie łańcuchów awaryjnych, diagnostyczne punkty końcowe tylko do odczytu oraz żądania, które później zwracają 403 lub kończą się niepowodzeniem w nadrzędnym systemie. Ponowne zastosowanie intencji do świeżego stanu oznacza również, że nieaktualny współbieżny proces zapisujący nie może nadpisać zatwierdzonej eskalacji, a dwie identyczne eskalacje rywalizujące ze sobą łączą się idempotentnie.

4.3 Caps i dlaczego wiążą wszystko

Fałszywie dodatnia eskalacja kosztuje (strong − base) cenę × pozostałe tokeny ciepłego epizodu i ponosi ten koszt po cichu — nic nie zawodzi. Promień rażenia jest ograniczony limitami odnoszącymi się do każdej klasy:

escalation_max_per_session (domyślnie 1). Deeskalacja i restarty klienta nie zwracają go, co eliminuje możliwość wykorzystywania pętli resetów.

Limit udziału eskalacji na router (domyślnie 20 %) w przesuwającym się oknie 24–48 h dziennych zasobników Redis, a także limit cross-router dla całego obszaru roboczego. Po osiągnięciu limitu całe kierowanie eskalacji jest wyłączone — w tym jawne prośby i jednorazowe podbicia.

De-eskalacja tylko na granicach zimnej pamięci podręcznej, więc fałszywie dodatni wynik jest ograniczony do jednego ciepłego epizodu.

Powód, dla którego klasa A przestrzega limitów, to wniosek z modelu zagrożeń, a nie preferencja polityczna: na bramie API każdy, kto posiada token obszaru roboczego, kontroluje nagłówki. Ścieżka zwolniona z limitów typu „klient o to poprosił” to nieopomiarowany kanał wydatków. §7 mierzy, co się dzieje, gdy każdy klient z tego nadużywa.

4.4 Deeskalacja jest z założenia asymetryczna

Eskaluj na podstawie potwierdzonych dowodów; deeskaluj tylko wtedy, gdy jest to bezkosztowe. Silna sesja wraca do stanu bazowego tylko wtedy, gdy wszystkie z: sesja jest zimna w pamięci podręcznej (bezczynna dłużej niż okno dostawcy zarejestrowane przy eskalacji), zgromadziła ≥3 ocenione tury bez błędów, a najnowsza delta trudności jest poniżej T1. Wewnątrz ciepłego okna przełączenie wiąże się z pełnopłatnym zimnym ponownym odczytem — migotanie to jedyny gwarantowany sposób, aby eskalacja była kosztowo ujemna.

5 Metoda

Zmierzyliśmy ten mechanizm, odtwarzając syntetyczny korpus sesji przez rzeczywisty produkcyjny kod decyzyjny. Ten harness to test w Go w pakiecie service, który dla każdej tury wywołuje ResolveEscalation i CommitEscalationDecision względem magazynu warstw opartego na miniredis, z prawdziwymi modułami oceny trudności, prawdziwymi producentami strajków po stronie żądań i prawdziwym mechanizmem limitów udziałów. Nic w ścieżce decyzyjnej nie jest zaimplementowane ponownie ani zamockowane, z wyjątkiem ujścia zdarzeń audytowych.

CO JEST PRAWDZIWE, A CO NIE

Rzeczywiste: Każda decyzja routingu, wskaźnik trudności, wykrywanie trafień, reguła serii, ocena limitu i przejście stanu Redis — to są wdrożone funkcje. Syntetyczne: ruch. Korpus jest generowany, a nie próbkowany z logów produkcyjnych. Jego mieszanka archetypów (50 % trudnych) to mieszanka obciążeniowa wybrana w celu przetestowania mechanizmu, a nie oszacowanie rzeczywistego ruchu; §6.4 podaje wrażliwość na ten wybór, i jest ona duża. Przedstawione poniżej czyste liczby precyzji odzwierciedlają korpus, którego klasy są rozdzielne z założenia, i należy je czytać jako „mechanizm uruchamia się w sytuacjach, dla których został zaprojektowany”, a nie jako oszacowanie precyzji produkcyjnej.

5.1 Korpus

400 sesji, 3968 tur, z ustalonym seedem i w pełni deterministyczne. Każda tura to pełna treść żądania chat-completions, zawierająca skumulowaną historię, tablicę definicji dwóch narzędzi oraz realistyczny prompt systemowy — strukturę, jaką faktycznie wysyła agent kodujący. Pięć archetypów, każdy z etykietą ground-truth:

Tabela 3. Skład korpusu. „Needs strong” stanowi prawdę podstawową wykorzystywaną do obliczania wskaźników precyzji i pokrycia.

Trudne tury zawierają wklejony zrzut goroutine lub fragment kodu źródłowego o rozmiarze 3–8 KB oprócz tekstu opisowego, ponieważ właśnie to zawiera prawdziwa trudna tura debugowania. Ten szczegół okazał się mieć ogromne znaczenie — patrz §6.2.

5.2 Model kosztów

Koszty są obliczane na podstawie opublikowanych cen katalogowych z semantyką pamięci podręcznej dla każdego dostawcy; model jest przedstawiony w całości, aby można było się z nim nie zgodzić.

Tabela 4. Parametry modelu kosztów. Ceny podane są w $ za 1M tokenów, cennik z sierpnia 2026 r.

Ciepłe wywołanie kosztuje 0.1·p_in·prefix + write·p_in·delta; zimne wywołanie kosztuje write·p_in·prompt. Wywołanie 1 to zawsze pełny zapis do cache. Wywołanie przełączające poziom w ramach polityki eskalacji jest wprost rozliczane jako zimne, więc mechanizm sam pokrywa koszt unieważnienia własnego cache.

Jakość jest podawana jako pokrycie trudnych zakrętów — odsetek trudnych zakrętów z danych referencyjnych faktycznie obsłużonych przez silny model — a nie jako miara dokładności. Nie uruchamialiśmy wnioskowania upstream, więc nie będziemy wymyślać liczb dotyczących dokładności.

6 wyników

6.1 Mechanizm odpala tam, gdzie został zaprojektowany.

Tabela 5. Wyniki eskalacji według archetypu, tryb automatyczny, canary 100 %, T2 = 0.70 (domyślne ustawienie).

Zero fałszywych pozytywów na 200 łatwych sesjach, w tym 60 długich, które przy pełnotranskryptowym skorerze dryfowałyby do trudnego przedziału. Klasy wyzwalaczy specjalizują się w sposób czysty i bez nakładania się: trudność wyłapuje pracę o dużej zawartości rozumowania, a strajki wyłapują pętle niepowodzeń. Zauważ, że najwyższy wynik trudności failure_loop wynosi 0,262 — bramka trudności w ogóle nie widzi tych sesji. Agent uwięziony w pętli błędów kompilacji nie produkuje prozy o dużej gęstości tropów rozumowania; produkuje ten sam krótki prompt z innym stack trace'em. Bez strajków klasy C każda z tych 60 sesji ciągnęłaby się w nieskończoność na tanim modelu.

Rysunek 3. Gdy sesje eskalują, rozdziela się je według wyzwalacza. Eskalacje wywołane strike'ami są wyraźnie skoncentrowane (tura 4, pierwsza tura, w której dwa strike'i mogły się skumulować w oknie zaniku); eskalacje wywołane trudnością rozkładają się na tury 2–11, zgodnie z rozkładem początków w korpusie. Reguła dwóch kolejnych tur oznacza, że najwcześniejsza możliwa eskalacja trudności następuje w turze 2.

6.2 Ustalenie: dostarczona bramka znajduje się na krawędzi przepaści

Nasz pierwszy korpus wygenerował zero eskalacji wynikających z trudności. Trudne przypadki — pełne wyścigów, niezmienników, analizy złożoności i słownictwa dowodowego — osiągnęły szczyt 0.658 przy progu 0.70. Dodanie wklejonych śladów stosu, które faktycznie niosą prawdziwe przypadki debugowania, podniosło je do 0.719. Próg został przekroczony marginesem 0.019.

Rysunek 4.Gdzie faktycznie idzie budżet trudności, uśredniony dla 855 trudnych i 3 113 łatwych tur. Realistyczna trudna tura osiąga 0,719 z teoretycznego maksimum delta wynoszącego 0,90. Termin CodeKeywordDensity wnosi 0,069 ze swojego budżetu 0,20 — zmierzona gęstość to 1,72 dopasowania na 100 znaków przy limicie nasycenia 5,0 — a wartość SystemPromptLogLen wynosząca 0,10 jest strukturalnie zerowa w ekstraktorze delta. Z grubsza jedna trzecia nominalnego zakresu wyniku jest nieosiągalna dla realistycznego tekstu.

Przemiatanie progu potwierdza, że to klif, a nie zbocze. W zakresie T2 od 0.35 do 0.65 wynik jest identyczny — 200 z 400 sesji eskaluje, bez żadnych chybień. Przy wdrożonym 0.70 klasyfikator zaczyna tracić sesje; przy 0.75 eskalacja napędzana trudnością załamuje się ze 122 sesji do 23.

Rysunek 5. Czułość progowa. Cały zakres 0,35–0,65 jest behawioralnie identyczny, ponieważ żaden realistyczny tekst delta nie trafia w ten zakres — rozkład wyników jest dwumodalny: łatwe tury skupiają się wokół 0,23, a trudne wokół 0,72, a pomiędzy nimi nie ma nic. Domyślna wartość dostępna w wersji wydanej znajduje się na górnej krawędzi górnej mody.

Implikacja inżynierska

T2 jest skalibrowany dla pełnotranskryptowego rozkładu, na którym dostrojono pasma gated_adaptive, i jest ponownie używany jako próg ekstraktora delta. Dokument projektowy wskazuje, że ekstraktor delta „wymaga własnego strojenia”; ten pomiar określa, jak bardzo. Albo bramka delta potrzebuje własnego niższego T2 — gdziekolwiek w zakresie 0,45–0,60 daje to identyczne zachowanie z realnym marginesem — albo próg percentylowy już zaplanowany na Fazę 3 („górne X % ostatniego ruchu tego rutera”) powinien trafić, co czyni eskalacyjny wskaźnik pokrętłem operatora i całkowicie omija kalibrację bezwzględną.

6.3 Koszt i zakres

Rysunek 6. Pięć polityk na tych samych 400 sesjach. Po lewej: koszt na 1 000 sesji (skala logarytmiczna). Po prawej: ułamek naprawdę trudnych tur obsłużonych przez silny model.

Tabela 6. Porównanie polityk. Koszt na 1 000 sesji w modelu z Tabeli 4.

Dwa wyniki warto rozdzielić. Po pierwsze, samo powinowactwo sesji oszczędza 24 % przy identycznym wyborze modelu (16.64 → 12.63) i 35 % na parze granicznej (290.93 → 188.30). To czysta ekonomia pamięci podręcznej — te same modele, wszystko to samo, różni się tylko przywiązanie klucza. Oszczędność jest większa na parze granicznej, ponieważ premia za zapis 1.25× Anthropica sprawia, że zimne tury są nieproporcjonalnie drogie.

Po drugie, eskalacja trafia tam, gdzie powinien mechanizm ratunkowy: 45 % kosztu zawsze najnowocześniejszego modelu za 67 % jego pokrycia trudnych tur, używając silnego modelu tylko w 21,4 % tur.

Brakująca jedna trzecia pokrycia nie jest wadą; to cena zapadki. Zasady potwierdzania, które dają zero fałszywych pozytywów, oznaczają również, że mechanizm nie może zadziałać w pierwszej turze problemu:

Tabela 7. Opóźnienie eskalacji — ostre skręty serwowane na tanim modelu, zanim zadziała zapadka.

Dwa obroty to dokładnie to, co określa zasada dwóch kolejnych obrotów, a jeden obrót to dokładnie to, co określa zasada dwóch uderzeń do zapadki. Opóźnienie jest zamierzone i jest to ta sama właściwość, która dała zero fałszywych pozytywów. Każdy, kto chce szybszego ratunku, ma nagłówek klasy A, który działa przy n=1 — właśnie dlatego ręczna klapa ratunkowa została wydana jako pierwsza.

6.4 Współczynnik nagłówków zależy całkowicie od ruchu na Twojej stronie.

Korpus jest w 50 % trudny z założenia. Rzeczywisty ruch routerów nie jest, a porównanie kosztów jest na to niezwykle wrażliwe. Dokonując ponownego ważenia zmierzonych kosztów dla poszczególnych archetypów w zakresie częstości występowania trudnych sesji:

Rysunek 7.Koszt na 1000 sesji w funkcji tego, jaka część Twojego ruchu naprawdę potrzebuje silnego modelu. Zachowanie w obrębie klas jest utrzymywane na zmierzonych wartościach; zmienia się tylko proporcja.

Tabela 8. Czułość rozpowszechnienia, $ na 1 000 sesji.

Przy docelowym wskaźniku eskalacji z dokumentu projektowego wynoszącym ≤5 % sesji, koszt eskalacji wynosi 1,6× rachunku za tanią pulę i 12 % rachunku za pulę frontier. Przy mieszance stresowej 50 % wynosi on 6,7× rachunku za tanią pulę. Oba stwierdzenia są prawdziwe; odpowiadają na różne pytania. Istotne operacyjnie jest to pierwsze i dlatego limit udziału domyślnie wynosi 20 %, a nie „wyłączony” — to limit, a nie precyzja wyzwalania, faktycznie ogranicza rachunek.

6.5 Nakładki utrzymują się w warunkach celowego nadużycia.

Ponownie uruchomiliśmy korpus z prawdziwym mechanizmem share-cap — bez stuba, z prawdziwymi dziennymi zasobnikami Redis — w modelu zagrożeń z §8: każdy klient wysyła X-OrcaRouter-Tier: strong w każdej turze.

Rysunek 8. Atak polegający na nadużyciu nagłówków wobec limitu 20 % udziału eskalacji. Pierwsze 20 żądań jest celowo nieograniczonych — próg rozgrzewania zapobiega odczytaniu „1 eskalacja z 2” jako 50 % i zablokowaniu funkcji na nowym routerze — po czym udział zbiega i utrzymuje się. Stan końcowy: 296 z 1439 żądań obsłużonych jako silne (20,6 %), a 1143 wyraźne żądania odrzucono i zarejestrowano jako zdarzenia denied_cap.

Pozostałe przekroczenie o 0,6 % jest zamierzonym zachowaniem porównania typu „ściśle większe” na przybliżonym liczniku przesuwnym, a limit na sesję wynoszący 1 uniemożliwia pojedynczym sesjom zużycie budżetu. Każde odrzucenie jest widoczne dla klienta w nagłówku odpowiedzi X-Orca-Session-Tier: base; reason=denied:share_cap oraz dla operatora w tabeli audytu — stłumiona eskalacja nigdy nie jest cicha.

7 Co byśmy zmienili

Przyznaj ekstraktorowi delty własny próg. Ponowne użycie T2 z pełnego transkryptu pozostawia margines 0.019 (§6.2). T2 specyficzny dla delty w zakresie 0.45–0.60 jest behawioralnie identyczny na tym korpusie, z zapasem większym o dwa rzędy wielkości. Zaplanowane już prace nad progiem percentylowym obejmują to i są lepszym rozwiązaniem.

Nie pozwól, aby składnik gęstości kodu pozostał czysto dekoracyjny. Wnosi on 0,069 ze swojego budżetu 0,20 na najgęstszym realistycznym tekście, jaki mogliśmy skonstruować, ponieważ jego limit nasycenia wynoszący 5 dopasowań na 100 znaków oznacza mniej więcej jedno słowo kluczowe kodu co dwadzieścia znaków. Albo ustaw mu nowy limit na podstawie zmierzonego rozkładu produkcyjnego, albo ponownie przydziel jego wagę.

Klasa C jest koniem roboczym dla ruchu agentów i jest najmniej rozwinięta. Populacja failure_loop jest niewidoczna dla bramki trudności (szczyt 0.262) i jest w całości wychwytywana przez strikes. Sesje agentów zawodzą przez zapętlanie, a nie przez wzrost trudności leksykalnej. Pozostali producenci po stronie odpowiedzi — oraz wciąż brakujący natywny hook przechwytywania strumienia Gemini — są warci więcej niż dalsze dostrajanie trudności.

Opublikuj opóźnienie eskalacji. Dwie tury ciężkiej pracy serwowane na tanim modelu to uczciwy koszt potwierdzającego mechanizmu zapadkowego, a operatorzy powinni zobaczyć je w panelu analitycznym obok precyzji, zamiast odkrywać je samodzielnie.

8 Ograniczenia

Korpus jest syntetyczny. Został skonstruowany tak, aby rozdzielać się czysto, dlatego wynik zerowej liczby fałszywych trafień charakteryzuje specyficzność mechanizmu na danych separowalnych, a nie jego precyzję na ruchu produkcyjnym. Rzeczywista wartość precyzji może pochodzić wyłącznie z zadania etykietowania w trybie cienia, które przewiduje projekt — pełny potok wyzwalaczy działający, niczego nie kierujący, decyzje etykietowane retrospektywnie — z bramką wdrożenia produkcyjnego na poziomie ≥70 % precyzji etykietowania.

Model kosztów zakłada stałe 500 tokenów wyjściowych na turę, co maskuje rzeczywisty efekt: modele z czołówki generują więcej tokenów rozumowania, przez co prawdziwa premia za korzystanie z nich jest niedoszacowana. Modeluje on również ciepło pamięci podręcznej na poziomie żądań jako jednolite 1/N dla kluczowych slotów; ważona pula wykorzystałaby indeks Herfindahla Σw², a kanał z pojedynczym kluczem nie wykazywałby żadnej przewagi pamięci podręcznej dla afinityzacji sesji na poziomie kanału — chociaż przypięcie na poziomie modelu wciąż ma znaczenie dla strategii adaptacyjnych.

Nie przeprowadziliśmy inferencji upstream, więc nie formułujemy żadnych twierdzeń o dokładności ani o powodzeniu zadania. Pokrycie trudnych tur jest substytutem jakości i zakłada, że silny model jest faktycznie lepszy w tych turach — co jest prawdopodobne dla skonstruowanych archetypów, ale tutaj niezweryfikowane.

Wreszcie, mierzy to implementację jednej bramy. Tryb awarii polegający na zablokowaniu w pierwszej turze powinien mieć zastosowanie do każdego routera świadomego pamięci podręcznej, który przypina sesje, ale konkretne liczby są właściwościami tych progów, tych wag i tych cen.

9 Praca pokrewna

Routing na poziomie żądań jest dobrze udokumentowany. FrugalGPTsup>[2]/sup> wprowadził kaskadę LLM — zapytaj tani model, oceń odpowiedź, eskaluj przy niskiej pewności — osiągając redukcję kosztów do 98 % przy zachowanej dokładności. RouteLLMsup>[1]/sup> trenuje rutery na danych o preferencjach z Chatbot Arena i raportuje 95 % jakości GPT-4 przy 14 % wywołań silnego modelu, przy czym rutery przenoszą się na inne pary modeli bez ponownego trenowania. RouterArenasup>[3]/sup> dostarcza brakującą podstawę ewaluacyjną: 8 400 zapytań z różnych dziedzin i poziomów trudności, ocenianych pod kątem dokładności, kosztów, optymalności routingu, odporności i narzutu rutera.

To, czego żadne z tych nie uwzględnia, to konwersacja jako jednostka routingu. Kaskada eskaluje żądanie i zapomina; następna tura ponownie uruchamia ten sam tani model na tym samym zadaniu, które obecnie jest już znane jako trudne. Router trenowany preferencjami ocenia zapytanie, a nie trajektorię. Luka, którą ten raport się zajmuje, to to, co router powinien pamiętać między turami, jak długo, oraz co powinno mieć możliwość zmiany zdania — pytanie, które staje się pilne dopiero wtedy, gdy buforowanie promptów sprawia, że zapominanie jest kosztowne.

OrcaRouter zawiera w drzewie źródłowym zestaw narzędzi RouterArena (eval/), który testuje pięć strategii na poziomie żądań — cheapest, quality, balanced, linucb, gated_adaptive — na otwartym zbiorze danych bez modyfikowania repozytorium nadrzędnego. Opisany tutaj mechanizm na poziomie sesji jest ortogonalny względem wszystkich pięciu strategii i można go z nimi łączyć.

10 Podsumowanie

Buforowanie promptów zmieniło ekonomikę routingu modeli LLM w sposób, którego literatura o routingu jeszcze nie uwzględniła. Gdy ciągłość jest warta 10-krotnego rabatu na większości tokenów wejściowych, router musi się przypiąć — a w momencie przypięcia podejmuje decyzję w turze, w której wie najmniej, i pozostaje z tą decyzją przez całą długość rozmowy. Routing na poziomie żądań nie ma tego problemu, ale płaci za to chybieniami w cache; naiwne ponowne ocenianie w każdej turze na nowo wprowadza te chybienia i dodatkowo dorzuca artefakt błędu zależnego od długości.

Warstwowe przypinanie rozwiązuje to, rozdzielając dwie rzeczy, które wyglądają jak jedna: który model obsługuje tę sesję (przypięcie, stabilne w obrębie warstwy) oraz do której warstwy należy ta sesja (niewielki, ograniczony, potwierdzony, wygasający element stanu). W naszym powtórzeniu to rozdzielenie odzyskuje 87% sesji, których trudność jest niewykrywalna w turze 1, z zerową liczbą fałszywych pozytywów na 200 łatwych sesjach, przy 45% kosztów wariantu always-frontier — i utrzymuje 20-procentowy limit wydatków nawet wobec klientów aktywnie próbujących go obejść.

Rzeczywiste słabości mechanizmu to kalibracja, nie architektura: próg trudności ponownie użyty z rozkładu, do którego nie był dopasowany, termin cechy, który nie może osiągnąć swojego budżetu, oraz dwie tury nieuniknionego opóźnienia ratunkowego. Są one do opanowania. Twierdzenie architektoniczne — że pamięć eskalacji musi być oddzielona od pinu, że żaden rozmyty sygnał nie może samodzielnie narastać, oraz że limity muszą wiązać wyraźne żądanie samego klienta, ponieważ klient posiada token — to część, którą byśmy zachowali.

11 źródeł

1. LMSYS Org. RouteLLM: Otwartoźródłowy framework do ekonomicznego routingu LLM. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · kod: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia i Zou. FrugalGPT: Jak korzystać z dużych modeli językowych, jednocześnie redukując koszty i poprawiając wydajność. arXiv:2305.05176. a href="https://arxiv.org/abs/2305.05176">u>arxiv.org/abs/2305.05176/u>/a>

3. Lu, Liu, Yuan, Cui, Zhang, Liu & Xing. RouterArena: Otwarta platforma do wszechstronnego porównywania routerów LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Buforowanie promptów w API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — automatyczne buforowanie, prefiks ≥1 024 tokenów w przyrostach co 128 tokenów, usuwanie po 5–10 minutach bezczynności, ≤1 godzina; zniżka na buforowane dane wejściowe w zależności od poziomu modelu. Cennik: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Buforowanie promptów. a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching">u>platform.claude.com/docs/en/build-with-claude/prompt-caching/u>/a> — odczyt z cache: 0,1× podstawowego wejścia, zapis: 1,25× (TTL 5 minut) lub 2× (TTL 1 godzina), odświeżany przy użyciu. Cennik: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. DeepSeek API wprowadza buforowanie kontekstu na dysku. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automatyczne, rozliczane na podstawie rzeczywistych trafień pamięci podręcznej, redukcja o rząd wielkości przy trafieniu.

7. Google. Buforowanie kontekstu w Gemini API. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — niejawne i jawne buforowanie z TTL rozliczanym według przechowywania.

8. Kod źródłowy OrcaRouter, to repozytorium: service/session_affinity.go (piny, TTL, klucze ograniczone do poziomu tier) · service/session_escalation.go (silnik) · service/model_router.go:1374 (selectByStrategy: zawężanie tier przed odczytem pinu) · service/model_router_difficulty.go (wagi i limity) · service/model_router_delta.go (ekstraktor delty) · service/escalation_strikes.go (producenci po stronie żądań) · service/escalation_caps.go (limity udziału) · docs/features/frontier-escalation.md (projekt, rundy przeglądu 1–4).

Powtarzalność. Aparat pomiarowy to test w Go w pakiecie usługi, który steruje ResolveEscalation / CommitEscalationDecision wobec miniredis, a także potok analiz i tworzenia wykresów w Pythonie. Generowanie korpusu ma ustalone ziarno (rand.NewSource(20260814)), a całe uruchomienie jest deterministyczne: 400 sesji, 3968 tur, trzy eksperymenty (główny replay, przebieg z limitem adwersarialnym, 9-punktowe przeszukiwanie progu). Wykresy wykorzystują paletę kategoryczną zwalidowaną pod kątem CVD; każdemu wykresowi towarzyszy odpowiadająca mu tabela źródłowa. Nie uzyskano dostępu do danych produkcyjnych, a żadna część tej analizy nie została wprowadzona do repozytorium.