Jedną z pierwszych rzeczy, którą dostrzeżesz po wdrożeniu LLM na produkcję, jest rozpiętość trudności zapytań. Część z nich jest trywialna — wyciągnięcie liczby z tekstu, przeformatowanie adresu, sprawdzenie formatu. Inne są genuinalnie złożone — wieloetapowe wnioskowanie, synteza z kilku dokumentów, analiza prawna. Problem w tym, że większość systemów kieruje wszystkie te zapytania do tego samego modelu. Płacisz za model frontier, nawet gdy odpowiada na pytanie, z którym bez trudu poradziłby sobie model za ułamek ceny.
LLM routing rozwiązuje dokładnie ten problem. Idea jest prosta: przed każdym wywołaniem LLM oceń najpierw, jak trudne jest zadanie, i wyślij je do najtańszego modelu, który niezawodnie je obsłuży. Mocny model wywołaj tylko wtedy, gdy sytuacja naprawdę tego wymaga. W praktyce oznacza to, że 75–90 % wywołań trafia do tańszego modelu, a całkowite koszty spadają bez widocznego obniżenia jakości w większości przypadków użycia.
Czym jest routing, czym cascading
Routing (trasowanie) to decyzja podjęta przed pierwszym wywołaniem: na podstawie wejścia wybierz model. Klasyfikator ocenia zapytanie i wysyła je albo do małego modelu, albo od razu do mocnego.
Cascading (kaskada) dodaje jeden krok: zapytanie trafia najpierw do taniego modelu, a jego odpowiedź jest oceniana — jeśli jest wystarczająco pewna (wskaźnik pewności, spójność, format), zwracasz ją użytkownikowi. Jeśli nie, automatycznie eskalujesz do mocniejszego modelu i płacisz za niego tylko w tym przypadku. Oba podejścia można łączyć: router decyduje o modelu wejściowym, kaskada decyduje o eskalacji.
Kluczowa różnica: routing jest proaktywny (klasyfikacja przed wywołaniem), cascading jest reaktywny (eskalacja po wywołaniu, gdy wynik nie wystarcza).
Dlaczego to działa — rozkład trudności w praktyce
W realnych systemach produkcyjnych, które analizowaliśmy, obowiązuje mniej więcej taki rozkład:
- 30–40 % zapytań to zapytania rutynowe — ekstrakcja, klasyfikacja, reformatowanie, proste wyszukiwanie. Poradzi z nimi sobie mały model, na przykład z rodziny Phi lub Gemma, ewentualnie tani tier dostawców frontier.
- 40–50 % zapytań ma średnią trudność — streszczenie dłuższego tekstu, proste wnioskowanie, odpowiedzi na FAQ z kontekstem. Tu wystarczy model średniej klasy.
- 10–20 % zapytań jest naprawdę trudnych — złożone analizy, wnioskowanie wieloskokowe, generowanie kodu z niestandardowymi wymaganiami, wrażliwe decyzje. Te zasługują na model frontier.
Jeśli wszystko kierujesz na frontier, płacisz cenę mocnego modelu za każde zapytanie — w tym za te 30–40 % rutynowych. Ceny modeli frontier (np. klasa Claude Opus, GPT-5.x) to rzędu ~15–25 USD za milion tokenów wyjściowych, podczas gdy tani tier (odpowiedniki Flash/Haiku) oscyluje poniżej 1–2 USD. Różnica jest 15–25-krotna. Nawet przy skromnym routingu, gdzie mały model obsługuje tylko połowę zapytań, koszty mogą spaść o 40–60 %.
Akademicki projekt RouteLLM (LMSYS / UC Berkeley) wykazał, że dobrze wytrenowany router potrafi kierować większość prostych zapytań do taniego modelu, zachowując przy tym większość jakości mocnego modelu — w ich pomiarach oznaczało to rzędu 85 % oszczędności kosztów przy zachowaniu istotnej części wydajności mocnego modelu. Dokładne liczby zależą od składu zapytań i kalibracji routera.
Jak działa klasyfikator trudności
Sercem routera jest klasyfikator, który na podstawie wejścia decyduje, dokąd je wysłać. Istnieje kilka podejść z różnymi kompromisami:
1. Prosty router heurystyczny
Długość wejścia, słowa kluczowe, typ zadania (ekstrakcja vs. generowanie vs. analiza). Działa zaskakująco dobrze w systemach z wąskim przypadkiem użycia i wyraźnie oddzielonymi typami zapytań. Zerowy overhead, deterministyczne zachowanie. Wada: kruchy, wymaga ręcznych reguł, nie adaptuje się do przypadków brzegowych.
2. Router oparty na embeddingach
Zapytanie jest embeddowane (np. małym modelem BGE) i porównywane z reprezentatywnymi przykładami z każdego tiera. Jeśli zapytanie jest bliskie próbce lekkich zadań, trafia do taniego modelu. Model embeddingowy działa lokalnie, overhead jest minimalny (~5–15 ms). Zaleta: nie wymaga trenowania klasyfikatora, łatwy do rozszerzenia o nowe przykłady.
3. Trenowany klasyfikator binarny
Mały model (regresja logistyczna lub mały transformator) wytrenowany do przewidywania, czy zapytanie wymaga mocnego modelu. RouteLLM dostarcza właśnie takie podejście z pretrenowanymi klasyfikatorami. Zaleta: wysoka precyzja po kalibracji na własnych danych. Wada: wymaga zbioru treningowego z adnotacjami i bieżącej aktualizacji.
4. Router LLM-as-a-judge
Tani model sam ocenia, czy zapytanie jest trudne. Paradoksalne, ale w praktyce działa — tani model potrafi rozróżnić „to prosta ekstrakcja" od „to złożona analiza", nawet jeśli tej złożonej analizy sam nie wykona dobrze. Overhead: jedno krótkie dodatkowe wywołanie LLM. Odpowiedni dla systemów z kaskadą.
W większości systemów produkcyjnych rekomendujemy rozpoczęcie od routera opartego na embeddingach lub prostego routera heurystycznego. Trenowany klasyfikator dodaj wtedy, gdy masz wystarczające logi operacyjne do treningu (rzędu tysięcy zaadnotowanych przykładów).
Praktyczny wzorzec kaskady
Cascading w praktyce wygląda tak:
- 1.Zapytanie trafia do systemu.
- 2.Mały model generuje odpowiedź i jednocześnie wskaźnik pewności (confidence).
- 3.Jeśli wskaźnik przekracza próg (np. 0,85), odpowiedź jest zwracana użytkownikowi.
- 4.Jeśli nie, to samo zapytanie jest wysyłane do średniego lub mocnego modelu i wynik średniego/mocnego jest zwracany.
Wskaźnik pewności można uzyskać na kilka sposobów:
- Log-prawdopodobieństwo tokenów — średnie log-prawdopodobieństwo generowanych tokenów. Niska wartość oznacza, że model „nie był pewny". Dostępne w frameworkach serving takich jak
vLLMlubSGLangprzez parametrlogprobs. - Spójność przy próbkowaniu — wygeneruj 3–5 różnych odpowiedzi (wyższa temperatura) i zmierz zgodność. Jeśli model sobie przeczy, eskaluj.
- Prompt weryfikacyjny — dodatkowe wywołanie (tanim modelem): „Czy ta odpowiedź jest poprawna i kompletna? Odpowiedz tylko tak/nie."
Próg eskalacji to kluczowy parametr, który trzeba kalibrować pod konkretny przypadek użycia. Zbyt wysoki próg = dużo zbędnych eskalacji, oszczędność przepada. Zbyt niski próg = mały model odpowiada na rzeczy, z którymi sobie nie radzi, spada jakość.
W systemach z wyraźnie zdefiniowanym zadaniem (np. klasyfikacja dokumentów do kategorii, ekstrakcja danych strukturalnych) kaskada jest wyjątkowo skuteczna — mały model obsługuje 80–90 % przypadków, mocny dostaje tylko naprawdę niejednoznaczne. Dla generatywnych przypadków użycia (wolny tekst, kreatywne pisanie, złożone odpowiedzi na otwarte pytania) kaskada jest trudniejsza do ustawienia, bo „poprawność" odpowiedzi trudno ocenić automatycznie.
Koszty routingu — nie są darmowe
Routing nie jest darmowy i ważne jest uwzględnienie jego własnych kosztów:
- Dodatkowa latencja — każde wywołanie klasyfikacyjne dodaje czas. Router oparty na embeddingach: ~5–15 ms. LLM-as-a-judge: 50–200 ms. Dla aplikacji interaktywnych w czasie rzeczywistym może być to odczuwalne.
- Kaskada przy błędnej klasyfikacji — jeśli mały model odpowiada na trudne zapytanie i odpowiedź jest zła, płacisz za dwa wywołania (mały + mocny) zamiast jednego. Błędna klasyfikacja nie obniża kosztów, lecz je podnosi.
- Złożoność operacyjna — router to kolejny komponent w systemie, który może się zepsuć, degradować, wymaga monitorowania i aktualizacji.
- Problem zimnego startu — nowy router bez danych historycznych klasyfikuje źle. Pierwsze tygodnie mogą być gorsze niż strategia z jednym modelem.
Dlatego routing najlepiej sprawdza się w systemach z wysokim wolumenem, heterogenicznymi zapytaniami i wyraźnym rozróżnieniem między lekkimi a ciężkimi zadaniami. Jeśli masz 100 zapytań dziennie i wszystkie są mniej więcej jednakowo trudne, overhead routera nie przyniesie sensownych oszczędności.
Przed wdrożeniem odpowiedz sobie: jaki jest rzeczywisty miks trudności Twoich zapytań? Jeśli nie masz danych, poświęć dwa tygodnie na logowanie i ręczną adnotację próbki 200–300 zapytań. To ćwiczenie ujawni też inne problemy — na przykład, że 40 % wywołań zawiera ten sam długi prompt systemowy, gdzie prompt caching zaoszczędzi więcej niż routing.
Kiedy routing nie wystarczy i co działa inaczej
Routing adresuje jeden aspekt kosztów — wybór modelu. Istnieją sytuacje, gdzie inna optymalizacja jest skuteczniejsza:
Powtarzające się prefiksy promptów → Prompt caching to zwykle mocniejszy ruch. Jeśli 80 % Twoich wywołań dzieli ten sam 3 000-tokenowy prompt systemowy, prompt caching u Anthropic obniża koszty tych tokenów o 90 %. Routing tego samego problemu by nie rozwiązał.
Rosnące koszty przez agenta z długą historią → Tu pomaga skracanie kontekstu i sumaryzacja, nie routing. Zobacz koszty agenta AI w produkcji.
Wolna odpowiedź przy dużym obciążeniu → Routing to tu jedynie częściowa odpowiedź. Wybór frameworku serving (vLLM vs. Ollama), continuous batching i rozmiar KV cache mają większy wpływ na throughput.
Routing według treści, nie trudności → Inny przypadek użycia: część zapytań powinna trafiać do modelu wytrenowanego w konkretnej domenie (np. fine-tuned model dla dokumentacji produkcyjnej), inne do modelu ogólnego. To jest routing oparty na treści i jest to osobna warstwa architektoniczna, niezależna od optymalizacji kosztów.
Implementacja: od czego zacząć
Jeśli chcesz wypróbować routing, oto sekwencja, którą rekomendujemy:
- 1.Zbieraj dane, zanim cokolwiek zaimplementujesz. Loguj zapytania z metadanymi — długość, typ zadania, czas odpowiedzi, wskaźnik jakości (jeśli masz). Bez danych kalibrujesz każdy router na ślepo.
- 1.Zacznij od routera heurystycznego na najoczywistszym podziale. Jeśli wiesz, że 30 % Twoich zapytań to klasyfikacje do czterech kategorii, a 70 % to generatywne, prosta reguła „jeśli typ=klasyfikacja → mały model" da natychmiastowe oszczędności bez overhead'u ML.
- 1.Przetestuj jakość małego modelu na realnych danych. Nie opieraj się na liczbach benchmarkowych. Weź 100 realnych zapytań ze swojej produkcji, przepuść przez mały model i oceń ręcznie. Zobaczysz, gdzie model zawodzi, a gdzie zaskoczy.
- 1.Zaimplementuj kaskadę z logprob thresholdingiem.
vLLMiSGLangoba eksponują log-prawdopodobieństwa tokenów. Ustaw próg eksperymentalnie: zacznij od 0,80, mierz eskalacje i fałszywe pozytywy.
- 1.Monitoruj rozkład eskalacji w czasie. Jeśli udział eskalacji rośnie, albo zmienił się typ zapytań, albo mały model degraduje w jakiejś kategorii. Router wymaga bieżącej kalibracji — to nie jest "ustaw i zapomnij".
Dla open-source'owego punktu startowego RouteLLM od LMSYS / UC Berkeley (Apache 2.0) jest dobrą bazą — dostarcza pretrenowane klasyfikatory i harness ewaluacyjny. Dla wdrożeń enterprise z wymogiem pracy on-prem podejście oparte na embeddingach z embeddingami BGE-M3 i lokalnym magazynem wektorowym Qdrant jest praktyczniejsze z perspektywy suwerenności danych.
Kiedy routingu nie robić
Pomimo oszczędności routing ma realne przeciwwskazania:
- Niski wolumen (mniej niż kilka tysięcy zapytań dziennie) — overhead implementacji i utrzymania nie przewyższa oszczędności.
- Homogeniczny przypadek użycia — jeśli wszystkie zapytania są jednakowo trudne (np. wyłącznie złożona analiza prawna), routing tylko doda złożoności bez korzyści.
- Wysoki koszt błędu — w środowiskach regulowanych, gdzie nawet częściowo błędna odpowiedź od taniego modelu stwarza problem (ochrona zdrowia, compliance, decyzje prawne), kaskada jest ryzykowniejsza. Tu bezpieczniej jest zdefiniować wąski zestaw zadań dla małego modelu ze 100% ręczną weryfikacją.
- Niedeterminizm modelu przy eskalacji — jeśli Twoja aplikacja wymaga odtwarzalności (to samo zapytanie, zawsze ta sama odpowiedź), kaskada to komplikuje: raz odpowiada mały model, innym razem mocny — wyniki się różnią.
Najczęstsze pytania
Jak sprawdzić, czy mam wystarczające zróżnicowanie zapytań, by routing się opłacił?
Wyeksportuj próbkę 200–300 realnych zapytań i ręcznie zaklasyfikuj je do trzech grup: lekkie, średnie, trudne. Jeśli ponad 30 % wpadnie do kategorii „lekkie", routing przyniesie mierzalne oszczędności. Jeśli rozkład jest równomierny lub skrzywiony ku „trudnym", efekt będzie marginalny.
Czym różni się routing od load balancingu między wieloma instancjami tego samego modelu?
Load balancing rozwiązuje problem throughputu i dostępności — dystrybuuje żądania między wiele instancji tego samego modelu. Routing rozwiązuje wybór modelu — decyduje, *który* model (inna klasa możliwości, inna cena) otrzyma dane zapytanie. Są komplementarne: możesz mieć routing między modelami i load balancing w ramach każdego modelu.
Co zrobić, gdy mały model co prawda odpowiada, ale odpowiedź wygląda wiarygodnie, a jest faktycznie błędna?
To największe ryzyko cascadingu. Wskaźnik pewności z log-prawdopodobieństw nie wykrywa błędów faktycznych — model może być „pewny" i mylić się. Pomagają trzy środki: (1) ogranicz mały model do zadań z weryfikowalnym wyjściem (ekstrakcja, klasyfikacja), nie do pytań faktograficznych; (2) dodaj weryfikację post-processingu wyjścia (regex, schemat JSON, lista kontrolna); (3) w wrażliwych domenach zawsze eskaluj do mocnego modelu lub dodaj krok human-in-the-loop.
Jaka jest różnica między routingiem a systemem multi-agent, gdzie agent sam decyduje, co wywoła?
W systemie multi-agent agent orkiestruje inne narzędzia i modele jako część rozwiązywania zadania — podejmowanie decyzji odbywa się wewnątrz pętli LLM. Router stoi przed wywołaniem LLM i jest zewnętrznym klasyfikatorem. Router jest szybszy i tańszy w uruchomieniu, ale nie ma dostępu do semantyki zadania w takiej głębokości jak agent. W przypadku złożonych pipeline'ów zobacz architektury agentów AI.
Czy routing można stosować też przy lokalnych modelach, nie tylko przy cloud API?
Tak, i tu korzyść może być jeszcze wyraźniejsza. Na tym samym serwerze możesz mieć mały model 7B i większy model 34B. Router kieruje proste zapytania do 7B (mniejsze zużycie VRAM, krótsza latencja), złożone do 34B. Oszczędność nie jest finansowa, lecz pojemnościowa — 7B obsłuży znacznie wyższy throughput na tym samym sprzęcie, dzięki czemu 34B pozostaje dostępny dla trudnych przypadków bez kolejki.
*W MP Industrial Solutions pomagamy firmom skonfigurować strategię routingu, która ma sens dla ich konkretnego miksu zapytań — od prostej heurystyki po trenowany klasyfikator z własnymi danymi. Jeśli rozwiązujesz kwestię kosztów LLM na produkcji lub budujesz infrastrukturę serving dla wielu przypadków użycia, chętnie razem przyjrzymy się Twojej sytuacji.*