Jedna z prvých vecí, ktorú si všimnete po nasadení LLM do produkcie, je rozptyl náročnosti dotazov. Niektoré sú triviálne — extrakcia čísla z textu, preformátovanie adresy, overenie formátu. Iné sú genuínne komplexné — multi-krokové uvažovanie, syntéza z viacerých dokumentov, právna analýza. Problém je, že väčšina systémov posiela všetky tieto dotazy na ten istý model. Platíte za frontier model, aj keď odpovedá na otázku, s ktorou by sa bez problémov vyrovnal model za desatinu ceny.
LLM routing rieši práve toto. Myšlienka je jednoduchá: pred každým LLM volaním najskôr odhadnite, aká náročná je úloha, a pošlite ju na najlacnejší model, ktorý ju spoľahlivo zvládne. Silný model zavolajte len vtedy, keď to situácia naozaj vyžaduje. V praxi to znamená, že 75–90 % volaní ide na lacnejší model a celkové náklady klesnú bez viditeľného poklesu kvality pre väčšinu použití.
Čo je routing a čo cascading
Routing (smerovanie) je rozhodnutie pred prvým volaním: na základe vstupu zvoľte model. Klasifikátor ohodnotí dotaz a odošle ho buď na malý model, alebo rovno na silný.
Cascading (kaskáda) pridáva krok navyše: dotaz pošlete najskôr na lacný model a jeho odpoveď ohodnotíte — ak je dostatočne sebavedomá (skóre spoľahlivosti, konzistencia, formát), vrátite ju používateľovi. Ak nie, automaticky eskalujete na silnejší model a zaplatíte za neho len v tomto prípade. Oba prístupy sa dajú kombinovať: router rozhodne o vstupnom modeli, kaskáda rozhodne o eskalácii.
Kľúčový rozdiel: routing je proaktívny (klasifikácia pred volaním), cascading je reaktívny (eskalácia po volaní, keď výstup nestačí).
Prečo to funguje — rozloženie náročnosti v praxi
V reálnych produkčných systémoch, ktoré sme analyzovali, platí zhruba toto rozloženie:
- 30–40 % dotazov je rutinných — extrakcia, klasifikácia, reformátovanie, jednoduché vyhľadávanie. Zvláda ich malý model, napríklad z rodiny Phi alebo Gemma, prípadne lacný tier frontierových providerov.
- 40–50 % dotazov je strednej náročnosti — zhrnutie dlhšieho textu, jednoduché uvažovanie, odpovede na FAQ s kontextom. Tu postačí stredný model.
- 10–20 % dotazov je skutočne ťažkých — komplexné analýzy, multi-hop uvažovanie, generovanie kódu s neštandardnými požiadavkami, citlivé rozhodnutia. Tieto zaslúžia frontier model.
Ak posielate všetko na frontier, platíte cenu silného modelu za každý dotaz vrátane tých 30–40 % rutinných. Ceny frontierových modelov (napr. trieda Claude Opus, GPT-5.x) sú rádovo ~$15–25 za milión výstupných tokenov, zatiaľ čo lacný tier (Flash/Haiku ekvivalenty) sa pohybuje pod $1–2. Rozdiel je 15–25-násobný. Aj pri skromnom routingu, kde malý model zvládne len polovicu dotazov, sa náklady môžu znížiť o 40–60 %.
Akademický projekt RouteLLM (LMSYS / UC Berkeley) ukázal, že dobre natrénovaný router dokáže väčšinu jednoduchých dotazov poslať na lacný model a zachovať pritom väčšinu kvality silného modelu — v ich meraniach to znamenalo rádovo okolo 85 % úsporu nákladov pri zachovaní podstatnej časti výkonu silného modelu. Presné čísla závisia od skladby dotazov a kalibrácie routera.
Ako funguje klasifikátor náročnosti
Srdcom routera je klasifikátor, ktorý na základe vstupu rozhodne, kam ho poslať. Existuje niekoľko prístupov s rôznym trade-off:
1. Jednoduchý heuristický router
Dĺžka vstupu, kľúčové slová, typ úlohy (extrakcia vs. generovanie vs. analýza). Funguje prekvapivo dobre pre systémy s úzkym use-casom a jasne oddelenými typmi dotazov. Nulový overhead, deterministické správanie. Nevýhoda: krehký, potrebuje ručné pravidlá, neadaptuje sa na okrajové prípady.
2. Embedding-based router
Dotaz sa embeduje (napr. malým BGE modelom) a porovná s reprezentatívnymi príkladmi z každého tier-u. Ak je dotaz blízko k vzorkovníku ľahkých úloh, ide na lacný model. Embedding model beží lokálne, overhead je minimálny (~5–15 ms). Výhoda: nevyžaduje tréning klasifikátora, ľahko rozšíriteľný o nové príklady.
3. Trénovaný binárny klasifikátor
Malý model (logistická regresia alebo malý transformátor) natrénovaný na predikciu, či dotaz vyžaduje silný model. RouteLLM poskytuje práve takýto prístup s predtrénovanými klasifikátormi. Výhoda: vysoká presnosť po kalibrácii na vlastných dátach. Nevýhoda: vyžaduje trénovaciu množinu s anotáciami, priebežnú aktualizáciu.
4. LLM-as-a-judge router
Lacný model sám ohodnotí, či je dotaz ťažký. Paradoxné, ale v praxi funkčné — lacný model vie rozoznať "toto je jednoduchá extrakcia" vs. "toto je komplexná analýza", aj keď tú komplexnú analýzu sám nezvládne dobre. Overhead: jedno krátke LLM volanie navyše. Vhodné pre systémy s kaskádou.
Pre väčšinu produkčných systémov odporúčame začať s embedding-based alebo jednoduchým heuristickým routerom. Trénovaný klasifikátor pridajte vtedy, keď máte dostatočné prevádzkové logy na tréning (rádovo tisíce anotovaných príkladov).
Praktický vzor kaskády
Cascading v praxi vyzerá takto:
- 1.Dotaz príde do systému.
- 2.Malý model vygeneruje odpoveď a zároveň skóre sebavedomia (confidence).
- 3.Ak skóre presiahne prah (napr. 0.85), odpoveď sa vráti používateľovi.
- 4.Ak nie, ten istý dotaz sa pošle na stredný alebo silný model a výsledok stredného/silného sa vráti.
Skóre sebavedomia môžete odvodiť niekoľkými spôsobmi:
- Log-probabilita tokenov — priemerná log-pravdepodobnosť generovaných tokenov. Nízka hodnota naznačuje, že model "tápol". Dostupné v serving frameworkoch ako
vLLMaleboSGLangcez parameterlogprobs. - Konzistencia pri vzorkovaní — vygenerujte 3–5 rôznych odpovedí (vyššia teplota) a zmerajte zhodu. Ak si model odporuje, eskalujte.
- Verifikačný prompt — sekundárne volanie (lacným modelom): "Je táto odpoveď správna a úplná? Odpovedz len áno/nie."
Prah eskalácie je kľúčový parameter, ktorý je potrebné kalibrovať na vašom konkrétnom use-case. Príliš vysoký prah = veľa zbytočných eskalácií, stráca sa úspora. Príliš nízky prah = malý model odpovedá na veci, ktoré nezvládne, klesá kvalita.
Pre systémy s jasne definovanou úlohou (napr. klasifikácia dokumentov do kategórií, extrakcia štruktúrovaných dát) je kaskáda mimoriadne efektívna — malý model zvládne 80–90 % prípadov, silný dostane len skutočne nejednoznačné. Pre generatívne use-cases (voľný text, kreatívne písanie, komplexné odpovede na otvorené otázky) je kaskáda ťažšie nastaviteľná, pretože "správnosť" odpovede sa ťažko hodnotí automaticky.
Náklady na routing — nie sú zadarmo
Routing nie je zadarmo a je dôležité započítať jeho vlastné náklady:
- Latencia navyše — každé klasifikačné volanie pridáva čas. Embedding-based router: ~5–15 ms. LLM-as-a-judge: 50–200 ms. Pre real-time interaktívne aplikácie to môže byť citeľné.
- Kaskáda pri nesprávnej klasifikácii — ak malý model odpovedá na ťažký dotaz a odpoveď je zlá, zaplatíte za dve volania (malý + silný) namiesto jedného. Chybná klasifikácia teda náklady neznižuje, ale zvyšuje.
- Operačná komplexita — router je ďalší komponent v systéme, ktorý sa môže pokaziť, degradovať, musíte ho monitorovať a aktualizovať.
- Cold-start problém — nový router bez historických dát klasifikuje zle. Prvé týždne môžu byť horšie ako single-model stratégia.
Preto routing najlepšie funguje v systémoch s vysokým objemom, heterogénnymi dotazmi a jasným rozlíšením medzi ľahkými a ťažkými úlohami. Ak máte 100 dotazov denne a všetky sú zhruba rovnako náročné, overhead routera nepriniesie zmysluplnú úsporu.
Pred nasadením si zodpovedzte: aký je skutočný mix náročnosti vašich dotazov? Ak nemáte dáta, strávte dva týždne logovaním a ručnou anotáciou vzorky 200–300 dotazov. Toto cvičenie odhalí aj iné problémy — napríklad, že 40 % volaní obsahuje rovnaký dlhý systémový prompt, kde by prompt caching ušetril viac ako routing.
Kedy routing nestačí a čo robí inak
Routing adresuje jeden aspekt nákladov — výber modelu. Existujú situácie, kde je iná optimalizácia efektívnejšia:
Opakujúce sa prefixové prompty → Prompt caching je zvyčajne silnejší ťah. Ak 80 % vašich volaní zdieľa rovnaký 3 000-tokenový systémový prompt, prompt caching u Anthropic znižuje náklady na tie tokeny o 90 %. Routing by na rovnaký problém nestačil.
Nárast ceny kvôli agentu s dlhou históriou → Tu pomáha skrátenie kontextu a sumarizácia, nie routing. Pozri náklady AI agenta v produkcii.
Pomalá odozva pri vysokej záťaži → Tu je routing tiež len čiastočná odpoveď. Výber serving frameworku (vLLM vs. Ollama), continuous batching a veľkosť KV cache majú väčší dopad na throughput.
Routovanie podľa obsahu, nie náročnosti → Iný use-case: niektoré dotazy majú ísť na model trénovaný na konkrétnej doméne (napr. fine-tuned model pre výrobnú dokumentáciu), iné na generálny model. Toto je content-based routing a je to samostatná architektonická vrstva, nezávislá od optimalizácie nákladov.
Implementácia: kde začať
Ak chcete routing vyskúšať, tu je postupnosť, ktorú odporúčame:
- 1.Zbierajte dáta skôr, ako čokoľvek implementujete. Logujte dotazy s metadátami — dĺžka, typ úlohy, čas odpovede, skóre kvality (ak máte). Bez dát každý router kalibrujete naslepo.
- 1.Začnite s heuristickým routerom na najzrejmejšom rozdelení. Ak viete, že 30 % vašich dotazov sú klasifikácie do štyroch kategórií a 70 % sú generatívne, jednoduché pravidlo "ak typ=klasifikácia → malý model" dá okamžitú úsporu bez ML overhead.
- 1.Otestujte kvalitu malého modelu na reálnych dátach. Neopierajte sa o benchmark čísla. Vezmite 100 reálnych dotazov z vašej produkcie, spustite cez malý model a manuálne ohodnoťte. Zistíte, kde model zlyháva a kde prekvapí.
- 1.Implementujte kaskádu s logprob thresholdingom.
vLLMaSGLangoba expozujú log-pravdepodobnosti tokenov. Nastavte prah experimentálne: začnite na 0.80, merajte eskalácie a falošné pozitíva.
- 1.Monitorujte distribúciu eskalácií v čase. Ak podiel eskalácií rastie, buď sa mení typ dotazov, alebo malý model degraduje na niektorej kategórii. Router potrebuje priebežnú kalibráciu, nie je to "nastav a zabudni".
Pre open-source štartovací bod je RouteLLM od LMSYS / UC Berkeley (Apache 2.0) dobrým základom — dodáva predtrénované klasifikátory a evaluačný harness. Pre enterprise nasadenie s požiadavkou na on-prem prevádzku je embedding-based prístup s BGE-M3 embeddingami a lokálnym vektorovým úložiskom Qdrant praktickejší z pohľadu dátovej suverenity.
Kedy routing nerobiť
Napriek úsporám má routing reálne kontraindikácie:
- Nízky objem (menej ako niekoľko tisíc dotazov denne) — overhead implementácie a údržby neprevyšuje úsporu.
- Homogénny use-case — ak všetky dotazy sú rovnako náročné (napr. čisto komplexná právna analýza), routing len pridá komplexitu bez benefitu.
- Vysoká cena chyby — v regulovaných prostrediach, kde aj čiastočne nesprávna odpoveď od lacného modelu spôsobuje problém (zdravotníctvo, compliance, právne rozhodnutia), je kaskáda rizikovejšia. Tu je bezpečnejšie definovať úzku sadu úloh pre malý model so 100% manuálnou verifikáciou.
- Model nedeterminizmus pri eskalácii — ak vaša aplikácia vyžaduje reprodukovateľnosť (rovnaký dotaz vždy rovnaká odpoveď), kaskáda to komplikuje: niekedy odpovie malý model, niekedy silný, výstupy sa líšia.
Časté otázky
Ako zistím, či mám dostatok rôznorodosti dotazov na to, aby sa routing oplatil?
Exportujte vzorku 200–300 reálnych dotazov a ručne ich klasifikujte do troch skupín: ľahké, stredné, ťažké. Ak viac ako 30 % padne do "ľahké" kategórie, routing prinesie merateľnú úsporu. Ak je distribúcia rovnomerná alebo skosená k "ťažkým", efekt bude marginálny.
Ako sa líši routing od load balancingu medzi viacerými instancemi toho istého modelu?
Load balancing rieši throughput a dostupnosť — distribuuje požiadavky medzi viaceré inštancie rovnakého modelu. Routing rieši výber modelu — rozhoduje, *ktorý* model (iná trieda schopností, iná cena) daný dotaz dostane. Sú komplementárne: môžete mať routing medzi modelmi a load balancing v rámci každého modelu.
Čo robiť, keď malý model síce odpovie, ale odpoveď je hodnoverná na pohľad, no fakticky chybná?
Toto je najväčšie riziko cascadingu. Confidence skóre z log-pravdepodobností neodhaľuje faktické chyby — model môže byť "istý" a mýliť sa. Pomáhajú tri opatrenia: (1) obmedzte malý model na úlohy s verifikovateľným výstupom (extrakcia, klasifikácia), nie na faktické otázky; (2) pridajte post-processing verifikáciu výstupu (regexom, JSON schémou, kontrolným zoznamom); (3) v citlivých doménach vždy eskalujte na silný model alebo pridajte human-in-the-loop krok.
Aký je rozdiel medzi routingom a multi-agent systémom, kde agent sám rozhoduje, čo zavolá?
V multi-agent systéme agent orchestruje ďalšie nástroje a modely ako súčasť riešenia úlohy — rozhodovanie je vnútri LLM slučky. Router stojí pred LLM volaním a je externý klasifikátor. Router je rýchlejší a lacnejší na spustenie, ale nemá prístup k sémantike úlohy v takej hĺbke ako agent. Pre komplexné pipelines pozrite architektúry AI agentov.
Môžem routing uplatniť aj pri lokálnych modeloch, nie len pri cloud API?
Áno, a tu môže byť benefit ešte výraznejší. Na tom istom serveri môžete mať malý 7B model a väčší 34B model. Router posiela jednoduché dotazy na 7B (nižší VRAM, kratšia latencia), zložité na 34B. Úspora nie je finančná, ale kapacitná — 7B zvládne oveľa vyšší throughput na rovnakom hardvéri, takže 34B ostáva dostupný pre ťažké prípady bez fronty.
*V MP Industrial Solutions pomáhame firmám nastaviť routing stratégiu, ktorá dáva zmysel pre ich konkrétny mix dotazov — od jednoduchej heuristiky až po trénovaný klasifikátor s vlastnými dátami. Ak riešite náklady na LLM v produkcii alebo budujete serving infraštruktúru pre viacero use-casov, radi sa pozrieme na vašu situáciu spoločne.*