Router LLM: kieruj żądaniami, tnij koszty o 60% [2026]

Router LLM: kieruj żądaniami, tnij koszty o 60% [2026]

Router LLM to cienka warstwa między Twoją aplikacją a kilkoma modelami językowymi, która decyduje, który model obsłuży każde żądanie. Analizuje żądanie (typ zadania, złożoność, budżet tokenów), przekazuje je do najlepiej dopasowanego modelu, a w razie błędu przełącza się na rezerwę. Cel: odpowiedzi dopasowane do zadania przy najniższym koszcie tokenów.

Płacenie modelowi frontierowemu za odpowiedź na „jak wygląda polityka zwrotów?" to prosty sposób na rozdęcie rachunków. AWS zmierzył alternatywę w kwietniu 2025: router klasyfikatorowy dodaje 0,53 sekundy opóźnienia, router semantyczny 0,10 sekundy, a routing wewnątrz jednej rodziny modeli obniża rachunek nawet o 30%. Gdy powtórzyć te obliczenia dla wielu dostawców z cennikami z lipca 2026, jak robimy to poniżej, oszczędność sięga 70%. Większość z niej bierze się z jednej decyzji, podjętej zanim powstanie pierwszy token.

Najważniejsze wnioski

• Router LLM decyduje, który model obsłuży każde żądanie, na podstawie typu zadania, kosztu lub zmierzonej jakości.
• Istnieje pięć strategii: regułowa, kosztowa, latency, semantyczna (embeddingi) i routing klasyfikatorem LLM.
• Routing regułowy dodaje ~0 ms i $0; routing klasyfikatorem dodaje 300-800 ms plus koszt tokenów klasyfikatora na żądanie.
• Routing może obniżyć wydatki na tokeny nawet o 60%, gdy większość prostego ruchu trafia do modelu 10-20x tańszego.
• Jeden dostawca, mniej niż 10 tys. żądań dziennie, brak presji kosztowej? Pomiń router. Zwykłe fallbacki wystarczą.

Co właściwie robi router LLM?

Router LLM wykonuje mały krok decyzyjny przed każdym wywołaniem modelu: czyta żądanie, ocenia je według reguły routingu, wybiera model, wysyła wywołanie, a w razie błędu pierwszego modelu ponawia na rezerwie. Nic więcej w Twojej aplikacji się nie zmienia. Nadal wysyłasz jedno żądanie i dostajesz jedną odpowiedź.

Cykl życia żądania, po kolei:

1. Żądanie trafia do endpointu routera, dokładnie tak, jak trafiałoby do API modelu.
2. Analiza. Router bada prompt: słowa kluczowe, liczbę tokenów, embedding lub ocenę klasyfikatora.
3. Wybór. Strategia routingu mapuje ten sygnał na warstwę modelu (tania, średnia, frontier lub lokalna).
4. Przekazanie. Wywołanie idzie do wybranego modelu przez API kompatybilne z OpenAI.
5. Fallback. Przy timeoutie, limicie zapytań lub błędzie żądanie jest ponawiane na następnej warstwie łańcucha.

Ludzie szukają „llm gateway vs router", bo dokumentacje dostawców zacierają te pojęcia. Jedno zdanie to porządkuje: gateway jest rurą, router jest decyzją. To warstwy, nie rywale, i większość gatewayów ma router wbudowany w środku.

Według dokumentacji LiteLLM ten sam proxy, który trzyma Twoje wirtualne klucze, uruchamia też router. Porównujesz konkretnie narzędzia na poziomie rury? Nasz ranking najlepszych narzędzi LLM gateway ocenia dziesięć.

Czy w ogóle potrzebujesz routera LLM?

Większość małych aplikacji go nie potrzebuje. Router zarabia na siebie, gdy ruch dzieli się na wyraźnie różne typy zadań, gdy rachunek za tokeny to Twój największy koszt infrastruktury albo gdy używasz więcej niż jednego dostawcy i potrzebujesz failovera. Poniżej tych progów zwykłe ponowienia plus jeden model rezerwowy dają niezawodność bez dodatkowego ruchomego elementu.

Powiemy to wprost, bo nikt inny w tej branży tego nie powie: jeśli używasz jednego dostawcy przy mniej niż 10 tys. żądań dziennie, router to narzut, którego nie potrzebujesz. Zwykłe fallbacki wygrywają.

Dlaczego tak wprost? Każdy routing to twierdzenie („ta klasa zadań jest bezpieczna na tanim modelu"), które dezaktualizuje się w miarę zmian modeli, cen i Twojego produktu. Kupuj ten koszt utrzymania tylko wtedy, gdy oszczędności wyraźnie go przewyższają.

5 strategii routingu LLM (i kiedy użyć każdej)

Każda strategia routingu LLM odpowiada na jedno pytanie: jakiemu sygnałowi ufasz na tyle, by wybrać model? Reguły ufają słowom kluczowym. Routing kosztowy ufa budżetowi tokenów. Routing latency ufa stoperowi. Routing semantyczny ufa embeddingom. Routing klasyfikatorem ufa innemu LLM-owi. Kompromis ma zawsze ten sam kształt: więcej jakości sygnału, więcej dodanego opóźnienia i kosztu na żądanie.

Autouzupełnianie podpowiada frazy „llm routing strategies", „llm task routing", „llm intent routing" i „llm dynamic routing". Mapują się one na pięć wzorców:

Jeden wzorzec przecina wszystkie pięć: kaskada, zwana też warstwowaniem modeli. Zacznij tanio i eskaluj tylko przy błędzie lub niskiej pewności. Bot wsparcia odpowiada z modelu za $0,25 za milion tokenów; gdy jego pewność spadnie poniżej 0,7, to samo żądanie jest ponawiane na modelu frontierowym. Płacisz za inteligencję tylko wtedy, gdy tania warstwa przyzna, że utknęła.

Dla akademickiej głębi: biblioteka LLMRouter od ulab-uiuc kataloguje ponad 16 zbadanych algorytmów routingu (KNN, SVM, MLP, faktoryzacja macierzowa, Elo, grafowe, BERT). Jeśli wybierasz routing semantyczny, embeddingi wzorcowe decydują o niemal wszystkim; nasz przewodnik po najlepszych modelach embeddingowych opisuje, które z nich trzymają poziom na realnych korpusach.

Jak zbudować router LLM w Pythonie?

Zbudujesz go w około 80 linijkach czystego Pythona wobec dowolnego endpointu kompatybilnego z OpenAI. Bez frameworka. Cztery routery poniżej eskalują w wyrafinowaniu: reguły słów kluczowych, próg kosztowy, podobieństwo embeddingów i model klasyfikatora z failoverem. Każdy wypisuje wybrany model, więc widzisz decyzję na żywo.

Jeśli szukałeś „how to build an llm router" i znajdowałeś tylko stosy AWS CDK i akademickie repozytoria, ta sekcja jest prostą odpowiedzią. Implementacja referencyjna AWS jest solidna, ale przyspawana do Bedrocka, Lambdy i CDK. Nasza działa wszędzie tam, gdzie celuje klient OpenAI: OpenAI, Anthropic przez proxy, Ollama na laptopie, vLLM na maszynie z GPU. Oto router, który jako pierwszy szkicujemy klientom.

Krok 1: Router regułowy (słowa kluczowe na modele)

Baseline o zerowym opóźnieniu. Decyduje mapa regexów; wszystko, co nie pasuje, idzie do warstwy frontier.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Wejście: pytanie do wsparcia. Decyzja: dopasowanie regexa do „cancel". Wybrany model: gpt-5-mini. Żadne wywołanie API nie jest potrzebne, żeby to zroutingować, i dlatego to zostaje domyślnym wyborem.

Krok 2: Router kosztowy (próg budżetu tokenów)

Ten sam pomysł, ale sygnałem jest rozmiar żądania zamiast słów kluczowych. Krótkie prompty z małym budżetem wyjściowym idą tanio; wszystko inne idzie na frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Prymitywne? Tak. Skuteczne? Też tak, bo wolumen tokenów koreluje z rozmiarem zadania lepiej, niż większość ludzi oczekuje. To cała strategia stojąca za kilkoma płatnymi produktami typu „tani router LLM".

Krok 3: Router semantyczny (embeddingi do wzorców)

Dla rozmytych danych wejściowych użytkowników, które omijają słowa kluczowe: osadź prompt i porównaj go z osadzonymi promptami wzorcowymi. Ten klaster, który jest najbliżej, bierze żądanie.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

Wywołanie routingu kosztuje jeden embedding (kilkaset tokenów) i 50-150 ms. Centroidy oblicz z wyprzedzeniem przy starcie, nie na każde żądanie.

Krok 4: Router z klasyfikatorem LLM i fallbackiem

Najsilniejszy sygnał: tani model czyta prompt i ocenia jego trudność. To strategia, którą AWS zmierzył na 0,53 sekundy dodanego opóźnienia, więc owijamy ją w łańcuch fallbacków.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

To cały przykład routera LLM: cztery funkcje, jeden klient, zero infrastruktury ponad to, co już uruchamiasz. Utwardzanie produkcyjne to następna sekcja.

Ile naprawdę oszczędza routing LLM?

AWS zmierzył narzut routera na $107,90-$188,90 miesięcznie na 100 000 pytań dziennie, przy czym routing klasyfikatorem dodaje 0,53 sekundy na żądanie, a routing semantyczny 0,10 sekundy. Strona oszczędności przytłacza ten narzut. Nasz przykładowy rachunek poniżej, oparty na cennikach z lipca 2026, ląduje na redukcji wydatków o 70,7%. Haczyk to miks ruchu: potrzebujesz, by większość żądań kwalifikowała się do taniej warstwy.

Dwie tabele. Najpierw ile sam router kosztuje Cię na 1000 żądań:

Post AWS z kwietnia 2025 to jedyny niezależnie opublikowany zestaw pomiarów w tej dziedzinie, więc kotwiczymy się do niego, a nasze rozszerzenia oznaczamy jako szacunki, nie liczby, które sami zmierzyliśmy. Bedrock Intelligent Prompt Routing obniżył koszt wewnątrz rodziny nawet o 30%, według AWS.

Po drugie, przykładowy rachunek oszczędności, który stoi za naszym nagłówkiem:

Założenia, oznaczone: 100 000 żądań miesięcznie; średnio 800 tokenów wejściowych plus 200 wyjściowych na żądanie; podział 80% proste / 20% złożone; ceny katalogowe ze strony cennika Anthropic i strony cennika OpenAI na lipiec 2026, z pełną tabelą stawek w naszym porównaniu cen API LLM. Rachunek na żądanie: Sonnet 4 kosztuje 800 x $3/M + 200 x $15/M = $0,0054; GPT-5 mini kosztuje 800 x $0,25/M + 200 x $2/M = $0,0006.

Wynik to redukcja o 70,7% i stąd bierze się 60% w naszym tytule, z zapasem. Uczciwe zastrzeżenia: to przykładowy rachunek, nie benchmark, który uruchomiliśmy. Zakłada, że Twoja tania warstwa jest 10-20x tańsza i że 80% ruchu naprawdę się kwalifikuje. Routing wewnątrz rodziny, scenariusz AWS, zostaje w okolicach 30%. A routing to jedna z wielu dźwigni; cache'owanie i przycinanie promptów często zwraca się szybciej, a nasz przewodnik po sposobach na obniżenie kosztów API LLM rankinguje wszystkie dwanaście.

Produkcyjne wzorce routingu

Zabawkowy router wybiera model. Produkcyjny router także ponawia, balansuje obciążenie, cache'uje powtórzenia i izoluje klucze API na zespół. Po przekroczeniu kilku tysięcy żądań dziennie przestań pisać to ręcznie i uruchom gateway z wbudowanym routerem.

Cztery wzorce, które się liczą:

• Łańcuchy fallbacków. Najpierw tania warstwa, frontier przy błędzie lub timeoutie. Pojedynczy wzorzec o najwyższej wartości; większość Twojej niezawodności bierze się z samego tego.
• Balansowanie obciążenia. Rozłóż wywołania na zduplikowane wdrożenia lub klucze API, żeby ominąć limity na klucz.
• Cache'owanie odpowiedzi. Identyczne prompty zwracają odpowiedzi z cache'u. Ruch wsparcia powtarza się bardziej, niż byś wierzył; trafialność 10-30% jest powszechna.
• Klucze wirtualne i budżety. Wydaj klucze na zespół z miesięcznymi limitami, żeby jedna rozpędzona pętla nie spaliła całego rachunku.

To jest bliskie konfiguracji, którą uruchamiamy na naszym stagingowym stosie agentowym (plik: litellm-router.yaml, montowany w kontenerze proxy LiteLLM):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Gdzie pasuje każde narzędzie, z opiniami:

• LiteLLM. Wybierz, jeśli chcesz self-hosted i open source, a już uruchamiasz Dockera. Nasz przewodnik konfiguracji proxy LiteLLM przechodzi przez pełne wdrożenie, z kluczami i budżetami.
• OpenRouter. Wybierz, jeśli chcesz setki modeli za jednym kluczem i zero operacji. Ich strona rankingów służy podwójnie jako dane o przepustowości.
• Portkey. Wybierz, jeśli o decyzji przesądzają wymagania enterprise (SSO, logi audytowe, raporty zgodności).
• Własny kod z tego posta. Wybierz, jeśli masz poniżej ~50 tys. żądań dziennie i chcesz zero nowej infrastruktury.

Cokolwiek wybierzesz, ranking narzędzi LLM gateway porównuje dziesięć z nich łeb w łeb.

Czy można routingować między modelami lokalnymi a hostowanymi API?

Tak, a matematyka tokenów jest kusząca: model lokalny kasuje $0 za token, więc każde żądanie obsłużone przez Ollamę lub vLLM to czysta oszczędność. Kompromis to opóźnienie i jakość na wat. Lokalne wygrywa przy prostych zadaniach o dużym wolumenie na sprzęcie, który już masz; hostowane API łapie wszystko, co wymaga mózgu frontierowego.

Mechanika jest rozczarowująco prosta i o to właśnie chodzi. Ollama wystawia endpoint kompatybilny z OpenAI pod localhost:11434/v1, a vLLM serwuje ten sam kształt. Więc każdy router powyżej działa bez zmian: skieruj base_url na lokalny serwer, wstaw qwen3:8b w tanie miejsce i trzymaj gpt-5 jako warstwę fallbacku. Dla self-hostedowej skrzynki routera LiteLLM jest dostarczany jako obraz Dockera, czyli ta konfiguracja „llm router docker", której ludzie szukają.

Dwie uwagi o uczciwości. Model 70B na jednym A100 serwuje z grubsza 30-40 tokenów na sekundę; hostowane API biją to w szczytowej przepustowości, więc lokalny routing pasuje lepiej do stabilnego ruchu w tle niż do skokowego chatu dla użytkowników. A lokalne modele 8B potykają się na wieloetapowych wywołaniach narzędzi, więc trudne trasy trzymaj skierowane w chmurę. Jeśli wybierasz sam silnik serwujący, vLLM vs SGLang benchmarkuje oba.

Routing napędza też wielomodelowe konfiguracje agentów kodujących. Proxy w stylu LiteLLM pozwala Claude Code rozmawiać z modelami lokalnymi i hostowanymi przez jeden endpoint; zobacz, jak używać różnych modeli w Claude Code, po dokładne okablowanie.

Jak poznać, że routing działa?

Mierzysz go albo zgadujesz. Loguj, który model odpowiedział na każde żądanie, oceniaj próbkę wyjść według rubryki i wprowadzaj oceny z powrotem do reguł routingu. Zespoły, które pomijają ten krok, kończą ze statyczną konfiguracją, która po cichu gnije, gdy modele i ceny zmieniają się pod nią.

Ścieżka dojrzewania biegnie: reguły, potem koszt, potem mierzona jakość:

1. Loguj trasę. Zapisz wybrany model, opóźnienie i liczby tokenów na żądanie jako jedną kolumnę w Twoich istniejących śladach.
2. Oceniaj wyjścia co tydzień. Sędzia LLM lub próbka ludzka, zaliczone/niezaliczone na klasę żądań. Pięćdziesiąt ocenionych wyjść na klasę wystarczy, żeby sterować.
3. Dostrajaj. Jeśli tania warstwa zdaje 95%+ w klasie, poszerz jej regułę, żeby łapała więcej tego ruchu. Jeśli spada poniżej 90%, zacieśnij.

Oto zdanie, które powtarzamy klientom: router, którego nigdy nie dostrajasz, to po prostu statyczna konfiguracja z dodatkowym opóźnieniem. Loguj wybrany model, oceniaj wyjścia, wprowadzaj oceny z powrotem.

Ta pętla to ewaluacje plus obserwowalność zastosowane do routingu. Nasz przewodnik po ewaluacji LLM opisuje rubryki ocen; przewodnik po obserwowalności AI opisuje, gdzie żyją ślady.

Dokąd zmierza research nad routingiem LLM?

Nurt akademicki traktuje routing jako problem uczenia, nie plik konfiguracyjny. LLMRouter od ulab-uiuc, biblioteka, która rankinguje się pierwsza na to słowo kluczowe, implementuje ponad 16 algorytmów (KNN, SVM, MLP, faktoryzacja macierzowa, Elo, grafowe, BERT i routery RL) z potokiem benchmarkowym na 11 zbiorach danych. Najczęściej cytowany ostatni artykuł, RouteLLM (Ong i in., arXiv:2406.18665), trenuje routery na danych preferencji ludzkich i raportuje ponad 2x redukcję kosztu bez straty jakości na MMLU i MT-Bench. Najnowszy zwrot: routery aktywacji prefill, linia „prefill is all you need", które czytają wewnętrzne aktywacje modelu podczas prefillu, żeby przewidzieć trudność, zanim zacznie się generowanie. Kierunek rozwoju to routery, które trenują się same z Twoich danych ewaluacyjnych, co jest dokładnie pętlą sprzężenia zwrotnego z poprzedniej sekcji.

Jak Techsy do tego podchodzi: stosy agentowe, które dostarczamy klientom B2B, uruchamiają dokładnie ten wzorzec, router warstw kosztowych z łańcuchami fallbacków wpiętymi w gateway plus dostrajanie sterowane ewaluacjami. Jeśli ważysz, czy routing pasuje do Twojego stosu, umów bezpłatną konsultację, a wspólnie zmapujemy Twój miks ruchu.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i potoki głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Połącz się na LinkedIn.

Często zadawane pytania

Czym jest router LLM?

Router LLM to warstwa między Twoją aplikacją a wieloma modelami językowymi, która decyduje, który model obsłuży każde żądanie. Sprawdza typ zadania, rozmiar lub trudność żądania, a następnie przekazuje je do najlepiej dopasowanego modelu, z fallbackiem na wypadek awarii tego modelu. Pomyśl o nim jak o kontrolerze ruchu dla Twoich wywołań API modeli.

Jak działa routing LLM?

Routing LLM działa w pięciu krokach: żądanie przychodzi, router je bada (słowa kluczowe, liczba tokenów lub embedding), strategia wybiera warstwę modelu, wywołanie jest przekazywane, a model rezerwowy łapie każdą awarię. Cała decyzja dzieje się przed rozpoczęciem generowania, więc dodaje milisekundy, nie sekundy, chyba że ocenia model klasyfikatora.

Czy router LLM to to samo co gateway LLM?

Nie. Gateway to rura: klucze API, limity zapytań, budżety i logi. Router to decyzja: który model odpowiada. To warstwy, nie rywale, i większość gatewayów (LiteLLM, Portkey, OpenRouter) ma router wbudowany w środku. Możesz uruchomić router bez gatewaya, ale w produkcji zwykle chcesz oba razem.

Czy routing modeli naprawdę oszczędza pieniądze?

Tak, gdy większość Twojego ruchu kwalifikuje się do dużo tańszej warstwy. Nasz przykładowy rachunek przenosi 80% żądań z modelu za $3/$15 na milion tokenów na model za $0,25/$2 i obcina rachunek o 70,7%. AWS zaraportował nawet 30% dla routingu wewnątrz jednej rodziny modeli. Jeśli Twój ruch jest jednolicie złożony, oszczędności maleją do zera.

Jaki jest najlepszy open-source'owy router LLM?

Do produkcji LiteLLM: self-hosted, aktywnie utrzymywany, łączący gateway z routerem. Dla algorytmów klasy badawczej LLMRouter od ulab-uiuc implementuje ponad 16 strategii routingu z literatury akademickiej. RouteLLM to najsilniejszy router jakości za dolara, trenowany na danych preferencji. Większość zespołów powinna zacząć od LiteLLM i sięgnąć po biblioteki badawcze tylko wtedy, gdy potrzebuje własnej punktacji.

Jak zbudować router LLM w Pythonie?

Zacznij od klienta OpenAI i około 80 linijek kodu: mapa reguł ze słów kluczowych na modele, próg kosztowy na liczbie tokenów, podobieństwo embeddingów do promptów wzorcowych albo tani model klasyfikatora oceniający trudność. Wszystkie cztery wzorce są w sekcji budowy powyżej, uruchamialne wobec OpenAI, Ollamy lub vLLM bez zmian.

Czy mogę routingować między modelami lokalnymi a API w chmurze?

Tak. Ollama (localhost:11434/v1) i vLLM oba wystawiają endpointy kompatybilne z OpenAI, więc ten sam kod routera celuje w model lokalny dla taniego ruchu i w hostowane API dla trudnego ruchu. Lokalne tokeny kosztują $0, ale sprzęt i opóźnienie należą do Ciebie. To wzorzec stojący za większością wielomodelowych konfiguracji Claude Code.

Czym jest routing semantyczny?

Routing semantyczny osadza każdy przychodzący prompt i porównuje go z osadzonymi promptami wzorcowymi, wysyłając żądanie do tego modelu, który posiada najbliższy klaster wzorcowy. Obsługuje rozmyte, sparafrazowane dane wejściowe użytkowników, które reguły słów kluczowych przepuszczają, kosztem 50-150 ms plus tokeny embeddingu na żądanie. AWS zmierzył go na 0,10 sekundy dodanego opóźnienia.

Ile opóźnienia dodaje router z klasyfikatorem LLM?

AWS zmierzył 0,53 sekundy dodanego opóźnienia dla klasyfikacji wspomaganej LLM, wobec 0,10 sekundy dla routingu semantycznego. Routing regułowy i kosztowy dodają z grubsza zero, bo są czystymi ścieżkami kodu. Jeśli Twój produkt ma ciasne SLA czasu odpowiedzi, preferuj reguły, progi kosztowe lub embeddingi, a klasyfikator zarezerwuj dla obciążeń offline lub kolejkowanych.

Źródła

• Seifi, N. i Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (dostęp 30 lipca 2026)
• Przykładowy kod AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (dostęp 30 lipca 2026)
• Dokumentacja LiteLLM. https://docs.litellm.ai (dostęp 30 lipca 2026)
• Cennik Anthropic. https://www.anthropic.com/pricing (dostęp 30 lipca 2026)
• Cennik API OpenAI. https://openai.com/api/pricing (dostęp 30 lipca 2026)
• LLMRouter ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (dostęp 30 lipca 2026)
• Ong, I. i in. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (dostęp 30 lipca 2026)
• Rankingi OpenRouter. https://openrouter.ai/rankings (dostęp 30 lipca 2026)