Model routing v praxi: nenech drahý model dělat levnou práci

Když se řekne "úspora na AI", většina lidí myslí na zrušení předplatného nebo kradmé počítání tokenů. Ale největší položka, kterou dnes firmy řeší, je úplně jiná: posílají úlohy, které zvládne model za deset korún, modelu za sto.

Data to začínají jasně ukazovat. Analytika firemních útrat z platební platformy Ramp, která sleduje spend za AI nástroje napříč desítkami tisíc firem, letos ukázala zajímavý obrat: vlajkové modely špičkových laboratoří tvoří jen zlomek reálného provozu. Nejnovější top model jednoho z předních vendorů měsíce po spuštění drží jen kolem 11 % útrat jeho vlastních firemních zákazníků — zbytek jde na levnější modely ve stejném katalogu. Firemní zákazníci prostě rutinní práci přesunuli dolů a drahý model si nechávají na těžké případy. Jak to shrnul jeden z analytiků: nejlepší model není vždy nejlepší byznys. Většina firem nepotřebuje nejvýkonnější model, ale model, který je pro danou práci dost dobrý za správnou cenu.

Dobrá zpráva: totéž můžeš udělat i ty, ať platíš API jako developer, nebo řídíš AI agenta v malém týmu. Zlá zpráva: uděláš to blbě, když to uděláš podle citu. Tady je postup, který funguje.

Krok 1: Udělej si inventuru úloh, ne modelů

Chyba číslo jedna je začít u nástrojů. Začni u své práce. Vezmi si poslední měsíc a rozepiš, co přesně svým AI nástrojům zadáváš. U každé úlohy si odpověz na dvě otázky: Jak často se opakuje? a Kolik stojí chyba?

Rozdělení je pak překvapivě jednoduché:

Typ úlohy	Kam s ní
Extrakce dat, převod na JSON, formátování, překlad	levný model, klidně nejlevnější tier
Shrnutí dokumentů, commit messages, generování testů k boilerplate kódu	levný až střední tier
Dopis zákazníkovi, jednoduché edity, dotazy do dokumentace	střední tier
Architektura, vícekrokový debugging, refaktoring, bezpečnostní audit	vlajkový model
Agentní smyčky (mnoho volání za sebou)	plánování draze, dílčí kroky levně

To poslední řádek je klíčové a většina lidí ho přeskočí. Když běží agent, který dělá třicet mezivolání, a každé z nich trefuje drahý model, tak ti peníze tečou i tehdy, když agent řeší banalitu typu "vypiš mi obsah adresáře a naformátuj to". Agentní práce je přirozeně hierarchická — rozhodování patří silnému modelu, rutina slabšímu.

Typický výsledek inventury? Kolem 70–80 % volání nemá důchod na vlajkovou loď. To není názor, to je aritmetika — právě to vidí i ve firemních datech.

Krok 2: Vyber si router, který bude rozhodovat

Na to, kdo úlohu rozdělí, máš tři cesty:

OpenRouter — nejjednodušší začátek. Jedno API, za ním stovky modelů, ceny per model bez paušálů a praktická věc: můžeš nastavit fallbacky, takže když levný model spadne nebo přetíží, požadavek automaticky přejde na náhradníka. Proč o něm mluví právě teď? Podle zpráv z konce srpna se stal cílem akvizice Stripe v řádu miliard dolarů — trh s routingem modelů je natolik lukrativní, že o něj stojí platební gigant. To je jen potvrzení, že jde o reálnou disciplínu, ne hackerův trik.

LiteLLM proxy — open-source vrstva, kterou si hostuješ sám. Definuješ si pravidla směrování v konfiguráku a tvůj stávající kód se nemusí dozvědět nic. Rozhraní zůstává, modely za ním se mění podle pravidel. Pro týmy s vlastní infrastrukturou a citlivými daty je to nejčistší cesta.

Nativní konfigurace nástrojů — Claude Code, Codex CLI a další dnes umí nastavit model per úloha, resp. per subagent. Hlavní agent běží na silném modelu, subagenti pro rutinní kroky na levnějším. Žádná nová infrastruktura, jen dobře napsaná konfigurace. Když máš agentní setup, začně tady — zisk je nejrychlejší.

Pro většinu jednotlivců a malých týmů doporučuju pořadí: nejdřív nativní konfigurace (hodina práce), pak OpenRouter, až když rostete nad deset lidí nebo máte compliance požadavky, LiteLLM.

Krok 3: Konfigurace, která přežije pondělí

Routovací pravidla piš jako kód, ne jako klikání v UI. Příklad pravidel pro proxy:

router_settings:
  model_group_tags:
    cheap:
      - provider-small
      - provider-mini
    smart:
      - provider-flagship

routing_rules:
  - match:
      task_type: [extraction, formatting, summarization]
    route_to: cheap
  - match:
      task_type: [architecture, debugging, refactoring]
    route_to: smart

V tomhle přístupu platí tři zásady:

Klasifikace podle typu úlohy, ne podle délky promptu. Krátký prompt může být těžký ("proč nám race condition v tomhle modulu?") a dlouhý lehký (vložený dokument ke shrnutí). Rozhoduje povaha práce, ne počet tokenů.
Fallback vždy. Levný model občas spadne, přetíží se nebo ti dočasně zablokuje účet. Bez fallbacku si zaděláš na výpadek v nejhorší možnou chvíli.
Výjimky přepisují pravidla. Někdy budeš potřebovat vlajkovou loď i na extrakci (složitá struktura, citlivá data). Nech si zadní vrátka — explicitní přepínač v requestu, který obejde router.

Krok 4: Nejdřív utrhni slevy, které máš zadarmo

Než vůbec začneš routovat, zkontroluj, zda nevynecháváš slevy, které routing nemusíš:

Batch endpointy. Když úloha nemusí běžet okamžitě (denní summarizace, hromadné zpracování dat), pošli ji batch API. Sleva bývá kolem 50 % oproti synchronnímu volání — u stejně kvalitního modelu.
Prompt caching. Pokud tvůj agent posílá pořád stejný systémový prompt a dokumentaci (a posílá), caching opakovaný kontext zlevní zlomkem původní ceny. U agentů s dlouhým kontextem je to často větší úspora než samotný routing.
Uzavřené outputy. Když chceš jen JSON, nastav minimální max tokens a neměj zbytečně dlouhé instrukce. Levné modely jsou paradoxně často disciplinovanější v krátkých odpovědích.

Routing má smysl až po tomhle. Jinak optimalizuješ třetí největší položku.

Krok 5: Měř cost per task, ne cenu per token

Poslední chyba, které se bojím nejvíc: lidé si po nasazení routingu kouknou na cenu per token, vidí nižší číslo a spokojeně odejdou. Ale to je špatná metrika. Správná metrika je cena za dokončenou úlohu — včetně retry, oprav a tvého času.

Rutinní úloha zvládnutá levným modelem na třetí pokus tě může vyjít dráž než napoprvé dražším modelem. A naopak. Proto si pro každý typ úlohy sleduj:

počet volání do dokončení,
celkovou cenu včetně oprav,
podíl úloh, které musíš ručně doupravit.

Když ti levnější model zvládá 95 % úloh bez zásahu, je to výhra. Když to je 70 % a zbytek dvakrát přepisuješ, prohráváš — protože tvůj čas je v té rovnici nejdražší položka.

Kdy routing NE nasazovat

Abych to nepřeháněl s růžovými brýlemi — existují situace, kde routing ubližuje:

Malý objem. Když platíš za API pár stovek měsíčně, hodina konfigurace a měření se ti nikdy nevrátí. Nastav batch API a caching a jdi dál.
Malý tým bez údržby. Router je infrastruktura. Má vlastní výpadky, vlastní konfiguraci, vlastní způsoby, jak se rozbít. Kdo ho bude udržovat, když odjedeš na dovolenou?
Kritická kvalita. Když ti jde o maximum kvality v každém kroku (specifikace, bezpečnost, právní texty), průměrovat dolů nemá cenu. Routing je optimalizace, ne víra.

Plán na odpoledne

Chceš to zkusit? Takhle:

30 minut: vypiš 10 nejčastějších AI úloh, zařaď je do tabulky výše. Označ ty, kde tě chyby nezabijí.
30 minut: zkontroluj batch API a prompt caching ve svém hlavním nástroji — tohle je zadarmo.
60 minut: nastav modely per úloha v Claude Code / Codex (nebo si založ OpenRouter a přesměruj jeden projekt).
Týden: měř cenu za úlohu u obou skupin. Porovnej. Teprve pak rozhodni, co routovat dál.

Firemní data jasně říkají, kam to celé jde: budoucnost není "jeden model na všechno", ale portfolio modelů s jasnými pravidly, kdo co dělá. Nemusíš čekat, až to udělá tvůj dodavatel. Můžeš to mít hotové dnes odpoledne.