IBM upozorňuje, že smerovanie medzi modelmi je systémový problém, nie iba klasifikácia úloh

IBM Research zverejnil na Hugging Face text, ktorý stojí za pozornosť každému tímu optimalizujúcemu náklady na agentov. Smerovanie požiadaviek medzi viacerými modelmi vyzerá na prvý pohľad jednoducho: ľahké úlohy pošlite lacnejšiemu modelu, ťažké silnejšiemu, prípadne vyberte špecialistu na kód, obraz alebo dlhý kontext. V praxi však IBM tvrdí, že router nie je iba klasifikátor náročnosti, ale optimalizačná vrstva celého systému.

Najsilnejší príklad sa týka ceny. IBM očakával, že GPT-4.1 bude lacnejší než Claude Sonnet 4.6, pretože cenníkové ceny vstupných a výstupných tokenov vyzerali priaznivejšie. Pri 417 úlohách z AppWorld Test Challenge s rovnakým CodeAct agentom však Sonnet vyšiel približne na 79 dolárov, kým GPT-4.1 na 155 dolárov. To je opačný výsledok, než by naznačoval jednoduchý pohľad na tabuľku cien.

Vysvetlením bola cache. Agentické workloady často opakovane používajú veľké časti kontextu medzi krokmi. Ak infraštruktúra modelu lepšie alebo lacnejšie využije cache čítania, reálna cena vstupu sa dramaticky zmení. Router, ktorý porovnáva iba nominálnu cenu za milión tokenov, preto optimalizuje nesprávnu veličinu. Musí poznať aj to, koľko krokov agent typicky potrebuje, koľko kontextu sa opakuje a ako daný poskytovateľ účtuje cache.

Druhý problém je zložitosť. Bežná predstava hovorí, že stačí odhadnúť náročnosť úlohy a podľa toho vybrať model. IBM upozorňuje, že pri agentoch je náročnosť závislá od trajektórie, nie iba od zadania. Rovnaká otázka môže byť jednoduchá, ak agent rýchlo nájde správny nástroj, alebo drahá a pomalá, ak sa dostane do série neúspešných pokusov. Router tak musí brať do úvahy históriu priebehu, nie iba prvý prompt.

Tretí rozmer je latencia. Rýchlosť modelu na jeden výstup nemusí znamenať rýchly agentický workflow. Model s nižšou latenciou môže spraviť viac chybných krokov, znovu volať nástroje alebo produkovať výstupy, ktoré treba opravovať. Silnejší model môže byť pri jednom kroku pomalší, ale celkovo skončiť skôr, ak potrebuje menej iterácií. Pre používateľa je dôležitý čas do správneho dokončenia úlohy, nie izolovaná rýchlosť jedného volania.

To mení aj úlohu evaluácie. Router sa nedá spoľahlivo hodnotiť na statickej tabuľke úloh, kde každá položka dostane jednu nálepku „ľahká“ alebo „ťažká“. Potrebné je merať celý agentický beh: počet krokov, náklady, cache hit rate, úspešnosť nástrojov, počet opráv, latenciu a kvalitu finálneho riešenia. Inak môže tím vybrať lacnejší model na papieri a v produkcii zaplatiť viac.

Praktický dopad je najväčší v podnikových agentoch, kde sa často kombinuje viac poskytovateľov, interné modely, retrieval, nástroje a dlhé kontexty. Model routing tu nie je okrajová funkcia, ale riadiaca vrstva medzi používateľom, dátami, nástrojmi a rozpočtom. Ak je zle navrhnutá, zhorší spoľahlivosť aj ekonomiku nasadenia. Ak je dobrá, môže umožniť používať drahšie modely len tam, kde naozaj prinášajú hodnotu.

IBM zároveň nepriamo varuje pred príliš univerzálnymi tvrdeniami v benchmarkoch modelov. Výsledok závisí od workloadu a infraštruktúry. Model, ktorý je lacnejší pri krátkych otázkach, nemusí byť lacnejší pri dlhých agentických trajektóriách. Model s dobrým všeobecným skóre nemusí byť najlepší v kombinácii s konkrétnym nástrojovým rámcom.

Pre tímy budujúce agentov je odporúčanie jasné: pred zavedením routera treba najprv merať reálne trajektórie vlastných úloh. Nestačí pozrieť sa na cenník a zostaviť pravidlo „ak je prompt krátky, použi lacný model“. Dôležité je sledovať, ktoré modely robia menej opráv, ako využívajú cache, kde vzniká latencia a kedy sa zdanlivo lacná voľba mení na drahú sériu pokusov. Model routing tak dozrieva z jednoduchého prepínača na disciplínu LLMOps.

Pre nákup a architektúru AI platforiem to znamená, že routing nemožno oddeliť od observability. Tím potrebuje ukladať nielen finálnu odpoveď, ale aj celé rozhodovanie: ktorý model bol zvolený, koľko krokov spravil, koľko tokenov bolo čítaných z cache, ktoré nástroje volal a kde vznikla chyba. Až potom sa dá spätne zistiť, či router šetrí peniaze, alebo len presúva náklady do dlhších trajektórií. Bez tejto dátovej vrstvy je model routing skôr pocitový tuning než spoľahlivá optimalizácia.