![LLM router: Směrujte požadavky, snižte náklady o 60 % [2026]](/_next/image?url=https%3A%2F%2Fmedia.techsy.io%2Ftechsy-io%2Fhero-506-1200x630.webp&w=3840&q=75)
LLM router: Směrujte požadavky, snižte náklady o 60 % [2026]
LLM router je tenká vrstva mezi vaší aplikací a několika jazykovými modely, která rozhoduje, který model zpracuje každý požadavek. Zkontroluje požadavek (typ úlohy, složitost, tokenový rozpočet), předá ho nejvhodnějšímu modelu a v případě chyby přepne na záložní. Cíl: odpovědi odpovídající velikosti úlohy za nejnižší možné tokenové náklady.
Platit špičkovému modelu za odpověď na dotaz „jaké jsou vaše podmínky vrácení peněz?" je přesně to, jak účty nabobtnají. AWS změřilo alternativu v dubnu 2025: klasifikační router přidává 0,53 sekundy latence, sémantický router 0,10 sekundy a směrování uvnitř jedné rodiny modelů srazí účet až o 30 %. Když tento výpočet přepočítáte napříč dodavateli s ceníky z července 2026, jak děláme níže, úspora dosáhne 70 %. Většina úspory pochází z jediného rozhodnutí, učiněného ještě před vygenerováním jediného tokenu.
Hlavní závěry
- LLM router rozhoduje, který model zpracuje každý požadavek, a to podle typu úlohy, nákladů nebo měřené kvality.
- Existuje pět strategií: pravidlové, nákladové, latenční, sémantické (embeddingy) a směrování LLM klasifikátorem.
- Pravidlové směrování přidá ~0 ms a 0 $; směrování klasifikátorem přidá 300-800 ms plus tokenové náklady klasifikátoru na požadavek.
- Směrování dokáže snížit tokenové výdaje až o 60 %, pokud většina jednoduchého provozu přejde na 10-20x levnější model.
- Jeden dodavatel, pod 10k požadavků denně, žádný tlak na náklady? Router přeskočte. Obyčejné záložní přepínání stačí.
Co vlastně LLM router dělá?
LLM router provede před každým voláním modelu malý rozhodovací krok: přečte požadavek, vyhodnotí ho podle směrovacího pravidla, vybere model, odešle volání a v případě chyby prvního modelu zopakuje pokus na záložním. Nic jiného se ve vaší aplikaci nemění. Stále odešlete jeden požadavek a dostanete jednu odpověď.
Životní cyklus požadavku, popořadě:
- Požadavek dorazí na endpoint routeru, přesně tak jako na API modelu.
- Analýza. Router prozkoumá prompt: klíčová slova, počet tokenů, embedding nebo skóre klasifikátoru.
- Výběr. Směrovací strategie přiřadí tento signál k úrovni modelů (levná, střední, špičková nebo lokální).
- Předání. Volání putuje do vybraného modelu přes API kompatibilní s OpenAI.
- Záloha. Při časovém limitu, rate limitu nebo chybě se požadavek zopakuje na další úrovni v řetězci.
Lidé hledají „llm gateway vs router", protože dokumentace dodavatelů tyto pojmy rozmazávají. Jedna věta to spraví: gateway je potrubí; router je rozhodnutí. Jsou to vrstvy, ne soupeři, a většina gateway v sobě router obsahuje.
| Vrstva | Rozhoduje | Typické funkce | Příklady |
|---|---|---|---|
| Proxy | Pouze přenos | URL endpointu, průchod autentizace, logy požadavků | nginx, Kong |
| Gateway | Politika na úrovni potrubí | API klíče, rate limity, rozpočty, logy využití, retry | LiteLLM proxy, OpenRouter, Portkey |
| Router | Který model odpoví | Pravidla úloh, cenové prahy, sémantické párování, skórování klasifikátorem | LiteLLM router, RouteLLM, vlastní kód |
Podle dokumentace LiteLLM táž proxy, která drží vaše virtuální klíče, provozuje i router. Porovnáváte-li konkrétně nástroje na úrovni potrubí, náš přehled nejlepších nástrojů LLM gateway jich hodnotí deset.
Potřebujete vůbec LLM router?
Většina malých aplikací ne. Router se vyplatí tehdy, když se provoz dělí na jasně odlišné typy úloh, když je tokenový účet vaše největší infrastrukturní položka, nebo když provozujete více než jednoho dodavatele a potřebujete přepínání při selhání. Pod těmito prahy vám obyčejné retry plus jeden záložní model koupí spolehlivost bez pohyblivé části navíc.
Řekneme to na rovinu, protože v tomto oboru to neřekne nikdo jiný: pokud provozujete jednoho dodavatele s méně než 10k požadavky denně, router je režie, kterou nepotřebujete. Obyčejné záložní přepínání vyhrává.
| Vaše situace | Verdikt |
|---|---|
| Jeden dodavatel, <10k požadavků/den, žádný tlak na náklady | Přeskočte ho. Použijte retry plus jeden záložní model |
| Smíšený provoz (FAQ podpory a náročné uvažování) | Směrujte podle typu úlohy (pravidlové) |
| Tokenový účet je vaše největší infrastrukturní položka | Směrujte podle cenové úrovně (nákladové nebo kaskáda) |
| Dva a více dodavatelů | Směrujte a přepínejte při selhání mezi nimi |
| Produkt kritický na kvalitu s evaluacemi v CI | Směrujte podle měřené kvality (klasifikátor nebo evaluace) |
Proč být tak přímý? Každé směrování je tvrzení („tato třída úloh je na levném modelu bezpečná"), které slábne, jak se mění modely, ceny a váš produkt. Tento náklad na údržbu si kupujte jen tehdy, když ho úspory jasně převýší.
5 strategií směrování LLM (a kdy kterou použít)
Každá strategie směrování LLM odpovídá na jednu otázku: jakému signálu důvěřujete natolik, abyste podle něj vybrali model? Pravidla důvěřují klíčovým slovům. Nákladové směrování důvěřuje tokenovému rozpočtu. Latenční směrování důvěřuje časovači. Sémantické směrování důvěřuje embeddingům. Směrování klasifikátorem důvěřuje jinému LLM. Kompromis má vždy stejnou podobu: více kvality signálu, více přidané latence a nákladů na požadavek.
Našeptávač vyhledávání tyto pojmy zobrazuje jako „llm routing strategies", „llm task routing", „llm intent routing" a „llm dynamic routing". Mapují se na pět vzorů:
| Strategie | Jak rozhoduje | Přidaná latence | Přidané náklady | Kdy použít |
|---|---|---|---|---|
| Pravidlové / směrování podle úlohy | Klíčové slovo nebo regex odpovídá mapě | ~0 ms | 0 $ | Předvídatelné záměry: vrácení peněz, shrnutí, opravy SQL |
| Nákladové směrování | Počet tokenů nebo práh rozpočtu | ~0 ms | 0 $ | Vysoký objem, tenké marže |
| Latenční směrování | Živé p95 pro každou úroveň modelů | ~0 ms (potřebuje metriky) | 0 $ | Uživatelský chat se SLA |
| Sémantické směrování | Podobnost embeddingu vůči vzorovým promptům | 50-150 ms | Embeddingové tokeny | Neurčitý, otevřený uživatelský vstup |
| Směrování LLM klasifikátorem | Levný model skóruje složitost | 300-800 ms | Tokeny klasifikátoru | Smíšeně složitý provoz, kvalita na prvním místě |
Jeden vzor protíná všech pět: kaskáda, nazývaná také vrstvení modelů. Začněte levně a eskalujte jen při selhání nebo nízké jistotě. Bot podpory odpovídá z modelu za 0,25 $ za milion tokenů; pokud jeho jistota klesne pod 0,7, týž požadavek se zopakuje na špičkovém modelu. Za inteligenci platíte jen tehdy, když levná úroveň přizná, že si neví rady.
Pro akademickou hloubku: knihovna LLMRouter od ulab-uiuc katalogizuje více než 16 prozkoumaných směrovacích algoritmů (KNN, SVM, MLP, maticová faktorizace, Elo, grafové a BERT). Pokud je vaší volbou sémantické směrování, vzorové embeddingy rozhodují téměř o všem; náš návod na nejlepší embeddingové modely pokrývá, které z nich obstojí na reálných korpusech.
Jak postavit LLM router v Pythonu?
Postavíte ho zhruba v 80 řádcích čistého Pythonu proti libovolnému endpointu kompatibilnímu s OpenAI. Žádný framework není potřeba. Čtyři routery níže postupně narůstají ve sofistikovanosti: pravidla podle klíčových slov, cenový práh, podobnost embeddingů a klasifikační model se záložním přepínáním. Každý z nich vypíše model, který vybral, takže rozhodnutí můžete sledovat v přímém přenosu.
Pokud jste hledali „how to build an llm router" a našli jen AWS CDK stacky a akademické repozitáře, tato sekce je ta přímočará odpověď. Referenční implementace AWS je solidní, ale přivařená k Bedrocku, Lambdě a CDK. Ta naše běží všude, kam míří klient OpenAI: OpenAI, Anthropic přes proxy, Ollama na notebooku, vLLM na GPU stroji. Zde je router, který klientům kreslíme jako první.
Krok 1: Pravidlový router (klíčová slova na modely)
Nulová latence jako základ. Rozhoduje mapa regulárních výrazů; vše, co neodpovídá, jde do špičkové úrovně.
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))Vstup: dotaz na podporu. Rozhodnutí: shoda regexu na „cancel". Vybraný model: gpt-5-mini. K jeho směrování není potřeba žádné API volání, a proto zůstává výchozí volbou.
Krok 2: Nákladový router (práh tokenového rozpočtu)
Stejná myšlenka, ale signálem je velikost požadavku místo klíčových slov. Krátké prompty s malým rozpočtem na výstup jdou levně; vše ostatní jde na špičku.
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 budgetHrubé? Ano. Účinné? Také ano, protože objem tokenů koreluje s velikostí úlohy lépe, než většina lidí čeká. Tohle je celá strategie, na které stojí několik placených produktů „cheap llm router".
Krok 3: Sémantický router (embeddingy na vzory)
Pro neurčitý uživatelský vstup, který se klíčovým slovům vyhýbá, vložte prompt do embeddingu a porovnejte ho se vzorovými prompty v embeddingu. Nejbližší shluk si požadavek vezme.
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 exemplarsSměrovací volání stojí jeden embedding (několik set tokenů) a 50-150 ms. Centroidy předpočítejte při startu, ne pro každý požadavek.
Krok 4: Router s LLM klasifikátorem a zálohou
Nejsilnější signál: levný model přečte prompt a ohodnotí jeho složitost. Tohle je strategie, které AWS naměřilo 0,53 sekundy přidané latence, takže ji zabalíme do záložního řetězce.
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 answersTo je celý příklad LLM routeru: čtyři funkce, jeden klient, žádná infrastruktura nad to, co už provozujete. Produkční vytvrzení je další sekce.
Kolik směrování LLM skutečně ušetří?
AWS změřilo režii routeru na 107,90-188,90 $ měsíčně na 100 000 dotazů denně, přičemž směrování klasifikátorem přidává 0,53 sekundy na požadavek a sémantické směrování 0,10 sekundy. Strana úspor tuto režii drtivě převyšuje. Náš propočtený příklad níže, postavený na cenících z července 2026, končí na snížení výdajů o 70,7 %. Háček je ve složení provozu: potřebujete, aby většina požadavků kvalifikovala pro levnou úroveň.
Dvě tabulky. Nejprve, kolik vás stojí samotný router na 1 000 požadavků:
| Strategie | Přidaná latence | Přidané náklady na 1 000 požadavků | Základ |
|---|---|---|---|
| Pravidlové | ~0 ms | 0 $ | Čistá kódová cesta |
| Sémantické (embeddingy) | 50-150 ms | 0,02-0,10 $ | Odhad: ~50 tokenů na prompt při sazbách text-embedding-3-small |
| LLM klasifikátor | 300-800 ms | 0,30-1,00 $ | Latence změřena AWS (0,53 s); náklady odhadnuty při sazbách gpt-5-mini pro ~300tokenové klasifikační volání |
Článek AWS z dubna 2025 je jediný nezávisle publikovaný soubor měření v tomto oboru, takže se o něj opíráme a naše rozšíření označujeme jako odhady, ne jako námi naměřená čísla. Bedrock Intelligent Prompt Routing snížil podle AWS náklady uvnitř rodiny až o 30 %.
Za druhé, propočtený příklad úspor, který stojí za naším titulkiem:
| Scénář | Jednoduchý provoz (80 000 pož.) | Složitý provoz (20 000 pož.) | Měsíční celkem |
|---|---|---|---|
| Bez routeru: vše na Claude Sonnet 4 (3 $ vstup / 15 $ výstup za M tokenů) | 432,00 $ | 108,00 $ | 540,00 $ |
| Se směrováním: jednoduché na GPT-5 mini (0,25 $ vstup / 2 $ výstup), složité na Sonnet 4 | 48,00 $ | 108,00 $ | 156,00 $ |
| Režie klasifikátoru (100k klasifikačních volání na GPT-5 nano, ~300 tokenů každé) | ~2,10 $ | ||
| Čistě se směrováním | ~158,10 $ |
Předpoklady, označené: 100 000 požadavků měsíčně; v průměru 800 vstupních plus 200 výstupních tokenů na požadavek; poměr 80 % jednoduché / 20 % složité; ceníky ze stránky cen Anthropic a stránky cen OpenAI k červenci 2026, s kompletní tabulkou sazeb v našem srovnání cen LLM API. Matematika na požadavek: Sonnet 4 stojí 800 × 3 $/M + 200 × 15 $/M = 0,0054 $; GPT-5 mini stojí 800 × 0,25 $/M + 200 × 2 $/M = 0,0006 $.
Výsledkem je snížení o 70,7 %, odkud pochází těch 60 % v našem titulku, a ještě zbývá rezerva. Poctivá upozornění: toto je propočtený příklad, ne benchmark, který jsme spustili. Předpokládá, že vaše levná úroveň je 10-20x levnější a že 80 % provozu skutečně kvalifikuje. Směrování uvnitř rodiny, scénář AWS, zůstává poblíž 30 %. A směrování je jen jedna páka z mnoha; ukládání do mezipaměti a prořezávání promptů se často vrátí rychleji a náš návod na způsoby, jak snížit náklady na LLM API, hodnotí všech dvanáct.
Produkční vzory směrování
Hračkářský router vybere model. Produkční router také opakuje pokusy, vyvažuje zátěž, ukládá opakování do mezipaměti a izoluje API klíče pro každý tým. Jakmile překročíte několik tisíc požadavků denně, přestaňte si tyto věci psát sami a nasaďte gateway, která router obsahuje.
Čtyři vzory, na kterých záleží:
- Záložní řetězce. Nejdřív levná úroveň, při chybě nebo časovém limitu špička. Jediný vzor s nejvyšší hodnotou; většina vaší spolehlivosti pochází jen z něj.
- Vyvažování zátěže. Rozprostřete volání mezi duplicitní nasazení nebo API klíče, abyste obešli rate limity na klíč.
- Mezipaměť odpovědí. Identické prompty vracejí odpovědi z mezipaměti. Provoz podpory se opakuje víc, než byste věřili; 10-30% míra zásahu je běžná.
- Virtuální klíče a rozpočty. Vydávejte klíče pro každý tým s měsíčními stropy, aby jedna splašená smyčka nespálila celý účet.
Tohle se blíží konfiguraci, kterou provozujeme na našem stagingovém agentním stacku (soubor: litellm-router.yaml, připojený do kontejneru 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: 30Kam který nástroj patří, s názorem:
- LiteLLM. Zvolte, pokud chcete self-hosted a open source a už provozujete Docker. Náš návod na nastavení proxy LiteLLM prochází celé nasazení, včetně klíčů a rozpočtů.
- OpenRouter. Zvolte, pokud chcete stovky modelů za jedním klíčem a nulové operace. Jejich stránka žebříčků slouží zároveň jako data o propustnosti.
- Portkey. Zvolte, pokud rozhodnutí řídí podnikové požadavky (SSO, auditní logy, compliance reporty).
- Vlastní kód z tohoto článku. Zvolte, pokud jste pod ~50k požadavky denně a chcete nulovou novou infrastrukturu.
Ať vyberete cokoli, přehled nástrojů LLM gateway porovnává deset z nich tváří v tvář.
Lze směrovat mezi lokálními modely a hostovanými API?
Ano, a tokenová matematika je svůdná: lokální model účtuje 0 $ za token, takže každý požadavek, který zodpoví Ollama nebo vLLM, je čistá úspora. Kompromisem je latence a kvalita na watt. Lokální vyhrává u vysoce objemových jednoduchých úloh na hardwaru, který už vlastníte; hostované API pochytí vše, co potřebuje špičkový mozek.
Mechanika je antiklimaktická, a to je ten point. Ollama vystavuje endpoint kompatibilní s OpenAI na localhost:11434/v1 a vLLM servíruje tentýž tvar. Takže každý router výše funguje beze změny: namiřte base_url na lokální server, dejte qwen3:8b do levné pozice a ponechte gpt-5 jako záložní úroveň. Pro self-hosted routerový stroj se LiteLLM dodává jako Docker image, což je ono nastavení „llm router docker", které lidé hledají.
Dvě poctivé poznámky. Model 70B na jedné A100 servíruje zhruba 30-40 tokenů za sekundu; hostovaná API to porazí v nárazové propustnosti, takže lokální směrování sedí lépe na klidný provoz na pozadí než na špičkový uživatelský chat. A lokální 8B modely zakopávají o vícekroková volání nástrojů, takže náročné trasy nechte mířit do cloudu. Pokud vybíráte samotný servírovací engine, vLLM vs SGLang oba benchmarkuje.
Směrování také pohání nastavení kódovacích agentů s více modely. Proxy ve stylu LiteLLM umožňuje Claude Code mluvit s lokálními i hostovanými modely přes jeden endpoint; jak přesně to zapojit, ukazuje návod na použití různých modelů v Claude Code.
Jak poznáte, že směrování funguje?
Buď ho měříte, nebo hádáte. Logujte, který model odpověděl na každý požadavek, ohodnoťte vzorek výstupů podle rubriky a skóre zpětně promítněte do směrovacích pravidel. Týmy, které tento krok přeskočí, skončí se statickou konfigurací, která tiše hnije, jak se pod ní mění modely a ceny.
Oblouk dospívání běží pravidla, pak náklady, pak měřenou kvalitu:
- Logujte trasu. Ukládejte vybraný model, latenci a počty tokenů na požadavek jako jeden sloupec ve vašich existujících trasách.
- Hodnoťte výstupy týdně. LLM soudce nebo lidský vzorek, průchod/pád pro každou třídu požadavků. Padesát ohodnocených výstupů na třídu stačí, abyste se měli čeho držet.
- Dolaďujte. Pokud levná úroveň projde na 95 %+ v nějaké třídě, rozšiřte její pravidlo, aby zachytila víc tohoto provozu. Pokud klesne pod 90 %, utáhněte.
Tady je věta, kterou klientům opakujeme stále dokola: router, který nikdy nepřeladíte, je jen statická konfigurace s latencí navíc. Logujte vybraný model, hodnotíte výstupy, promítejte skóre zpět.
Tato smyčka je evaluace plus observabilita aplikovaná na směrování. Náš návod na LLM evaluace pokrývá hodnoticí rubriky; návod na observabilitu AI pokrývá, kde trasy žijí.
Kam se ubírá výzkum směrování LLM?
Akademická linie chápe směrování jako problém učení, ne jako konfigurační soubor. LLMRouter od ulab-uiuc, knihovna, která se pro toto klíčové slovo umisťuje první, implementuje více než 16 algoritmů (KNN, SVM, MLP, maticová faktorizace, Elo, grafové, BERT a RL routery) s benchmarkovou pipeline nad 11 datasety. Nejcitovanější nedávný článek, RouteLLM (Ong a kol., arXiv:2406.18665), trénuje routery na datech lidských preferencí a reportuje více než 2x snížení nákladů bez ztráty kvality na MMLU a MT-Bench. Nejnovější zákruta: routery podle prefill aktivací, linie „prefill is all you need", které čtou vnitřní aktivace modelu během prefillu, aby odhadly složitost ještě před začátkem generování. Směr vývoje míří k routerům, které se samy trénují z vašich evaluačních dat, což je přesně ona zpětnovazební smyčka z předchozí sekce.
Jak k tomu přistupuje Techsy: agentní stacky, které dodáváme B2B klientům, běží přesně tento vzor, nákladový router se záložními řetězci zapojenými do gateway, plus dolaďování řízené evaluacemi. Pokud zvažujete, zda směrování sedí do vašeho stacku, získejte bezplatnou konzultaci a my s vámi zmapujeme složení vašeho provozu.
O autorovi
Mert Batur je spoluzakladatel Techsy.io, kde tým dodává AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů LLM, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.
Časté dotazy
Co je LLM router?
LLM router je vrstva mezi vaší aplikací a několika jazykovými modely, která rozhoduje, který model zpracuje každý požadavek. Zkontroluje typ úlohy, velikost nebo složitost požadavku a poté ho předá nejvhodnějšímu modelu, se zálohou pro případ, že tento model selže. Představte si ho jako řídicího letového provozu pro vaše volání modelových API.
Jak funguje směrování LLM?
Směrování LLM probíhá v pěti krocích: požadavek dorazí, router ho prozkoumá (klíčová slova, počet tokenů nebo embedding), strategie vybere úroveň modelu, volání se předá a záložní model odchytí případné selhání. Celé rozhodnutí proběhne před začátkem generování, takže přidá milisekundy, ne sekundy, ledaže by skórování dělal klasifikační model.
Je LLM router to samé jako LLM gateway?
Ne. Gateway je potrubí: API klíče, rate limity, rozpočty a logy. Router je rozhodnutí: který model odpoví. Jsou to vrstvy, ne soupeři, a většina gateway (LiteLLM, Portkey, OpenRouter) v sobě router obsahuje. Router můžete provozovat bez gateway, ale v produkci obvykle chcete obě dohromady.
Šetří směrování modelů skutečně peníze?
Ano, když většina vašeho provozu kvalifikuje pro mnohem levnější úroveň. Náš propočtený příklad přesune 80 % požadavků z modelu za 3 $/15 $ za milion tokenů na model za 0,25 $/2 $ a srazí účet o 70,7 %. AWS reportovalo až 30 % pro směrování uvnitř jedné rodiny modelů. Pokud je váš provoz rovnoměrně složitý, úspora se zmenšuje k nule.
Jaký je nejlepší open-source LLM router?
Pro produkci LiteLLM: self-hosted, aktivně udržovaný, a kombinuje gateway s routerem. Pro algoritmy výzkumné úrovně implementuje LLMRouter od ulab-uiuc více než 16 směrovacích strategií z akademické literatury. RouteLLM je nejsilnější router z hlediska kvality za dolar, trénovaný na preferenčních datech. Většina týmů by měla začít s LiteLLM a po výzkumných knihovnách sáhnout jen tehdy, pokud potřebují vlastní skórování.
Jak postavit LLM router v Pythonu?
Začněte s klientem OpenAI a zhruba 80 řádky kódu: mapa pravidel z klíčových slov na modely, cenový práh na počtech tokenů, podobnost embeddingů vůči vzorovým promptům, nebo levný klasifikační model, který skóruje složitost. Všechny čtyři vzory jsou v sekci o stavbě výše, spustitelné proti OpenAI, Ollama nebo vLLM beze změn.
Mohu směrovat mezi lokálními modely a cloudovými API?
Ano. Ollama (localhost:11434/v1) i vLLM vystavují endpointy kompatibilní s OpenAI, takže tentýž kód routeru míří na lokální model pro levný provoz a na hostované API pro náročný provoz. Lokální tokeny stojí 0 $, ale vlastníte hardware a latenci. Tohle je vzor, na kterém stojí většina nastavení Claude Code s více modely.
Co je sémantické směrování?
Sémantické směrování vloží každý příchozí prompt do embeddingu a porovná ho se vzorovými prompty v embeddingu, přičemž požadavek pošle tomu modelu, který vlastní nejbližší shluk vzorů. Zvládá neurčitý, parafrázovaný uživatelský vstup, který pravidla podle klíčových slov mine, za cenu 50-150 ms plus embeddingové tokeny na požadavek. AWS ho změřilo na 0,10 sekundy přidané latence.
Kolik latence přidá router s LLM klasifikátorem?
AWS změřilo 0,53 sekundy přidané latence u klasifikace asistované LLM, oproti 0,10 sekundy u sémantického směrování. Pravidlové a nákladové směrování přidávají zhruba nulu, protože jsou to čisté kódové cesty. Pokud má váš produkt těsné SLA na dobu odezvy, upřednostněte pravidla, cenové prahy nebo embeddingy a klasifikátor si nechte pro offline nebo frontové úlohy.
Zdroje
- Seifi, N. a 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/ (přístup 30. července 2026)
- Ukázkový kód AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (přístup 30. července 2026)
- Dokumentace LiteLLM. https://docs.litellm.ai (přístup 30. července 2026)
- Ceník Anthropic. https://www.anthropic.com/pricing (přístup 30. července 2026)
- Ceník OpenAI API. https://openai.com/api/pricing (přístup 30. července 2026)
- LLMRouter od ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (přístup 30. července 2026)
- Ong, I. a kol. (2024). „RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (přístup 30. července 2026)
- Žebříčky OpenRouter. https://openrouter.ai/rankings (přístup 30. července 2026)