Cost-aware LLM routing: cum am redus factura LLM cu ~70% fără a sacrifica calitatea

O greșeală frecventă în arhitectura agenților AI este utilizarea unui singur model premium pentru toate sarcinile. Funcționează în pilot, scalează prost. Această abordare ignoră faptul că diferite faze ale unui workflow agent au cerințe cognitive radical diferite. Un model premium pentru proiectarea unui plan complex este investiție bună; același model pentru a parsa output-ul unei comenzi de status este risipă.

În acest articol descriem patternul de cost-aware routing pe care îl operăm intern, cu pseudocod, decision tree și cifre reale măsurate pe trei luni de operare.

TL;DR

• Un agent AI nu are un singur tip de sarcină. Are cel puțin trei: design (rar, complex), work (frecvent, semi-deterministic), polling (constant, trivial).
• Fiecare tip de sarcină se mapează pe o clasă diferită de model: premium, mediu, local mic.
• Routing-ul se face pe baza unui clasificator simplu (heuristici plus, opțional, model mic dedicat), nu pe baza userului care alege manual.
• Pe configurația noastră internă, distribuția 5% premium / 25% mediu / 70% local a redus costul agregat la ~30% din baseline.
• Calitatea agregată (rata de succes, satisfacție internă) este indistinguibilă față de mono-model premium.

De ce routing-ul nu este o optimizare ulterioară

Există tentația de a porni cu „un model bun rezolvă tot, optimizăm mai târziu”. Problema: un model premium are un cost per token cu 1-2 ordine de mărime peste un model mediu, și 2-3 ordine de mărime peste un model local. La 1.000 de invocări pe zi, factura este vizibilă; la 100.000, devine un bottleneck strategic.

Mai mult, refactoring-ul de la mono-model la multi-model este o schimbare arhitecturală, nu o optimizare locală. Schimbi cum arată sesiunea, cum păstrezi context, cum gestionezi tools. Designul cost-aware de la început este mai ieftin decât o re-architectare ulterioară.

Cele trei clase de sarcină

Toate sarcinile pe care un agent AI le execută se încadrează în una din trei clase, indiferent de domeniu (ops, devsec, finance, customer support).

Clasa A — Design. Sarcină complexă, deschisă, cu necesitate de raționament. Exemplu: utilizatorul cere „fă-mi un audit de cost pentru luna trecută și recomandă 3 optimizări”. Modelul trebuie să înțeleagă cererea ambiguă, să interogheze multe surse, să sintetizeze, să prioritizeze. Frecvență: zeci de invocări pe zi. Latență acceptabilă: 5-30 secunde.

Clasa B — Work. Sarcină structurată, cu scope clar, output bine definit. Exemplu: agentul execută pasul 3 dintr-un plan deja aprobat — „creează un DNS record cu valorile X, Y, Z, validează propagarea”. Logica este largely deterministă; LLM-ul parsează ieșiri, recunoaște erori, formează rapoarte. Frecvență: sute de invocări pe oră. Latență acceptabilă: 1-3 secunde.

Clasa C — Polling/Triage. Sarcină repetitivă, foarte limitată. Exemplu: agentul citește status-ul a 100 de servere, decide dacă există o anomalie care merită alertă. 99% din timp, răspunsul este „nimic interesant”. Frecvență: mii de invocări pe oră. Latență acceptabilă: 0.1-0.5 secunde.

Maparea pe clase de model

Clasa A → model premium. Cel mai mare context, cel mai bun raționament, cel mai mare cost per token. Folosit doar pentru design, sub 10% din volumul total. Factura per invocare este mare, dar volumul mic ține totalul controlat.

Clasa B → model mediu. Context decent, capacitate bună de tool-use, cost moderat. Folosit pentru lucrul propriu-zis. Reprezintă majoritatea volumului de invocări care contează.

Clasa C → model local mic. Self-hosted, cost zero per invocare după costul fix de infrastructură. Capacitate suficientă pentru triage și recunoaștere de pattern. Volumul mare nu împinge factura.

Pseudocod: routerul

def route(task: AgentTask) -> Model:
    # Reguli explicite înainte de orice clasificator
    if task.is_polling_or_status_check():
        return Models.LOCAL_SMALL

    if task.has_user_intent_freeform():
        # Cere proiectare, nu pași determinati
        return Models.PREMIUM

    if task.is_step_in_approved_plan():
        # Plan deja aprobat → execuție structurată
        return Models.MEDIUM

    if task.context_tokens > 100_000:
        # Context lung necesită model premium indiferent
        return Models.PREMIUM

    if task.requires_high_creativity():
        return Models.PREMIUM

    # Default: medium pentru lucru, premium dacă incertitudine
    if task.confidence_in_classification < 0.7:
        return Models.PREMIUM

    return Models.MEDIUM

Observați: clasificarea este pe metadata sarcinii, nu pe input. Dacă sarcina este „pasul 3 dintr-un plan aprobat”, aceasta este clar work; dacă este „utilizatorul a scris o cerere nouă”, este clar design.

Decision tree practic

                 Task primit
                      |
        este "polling" sau status check?
              |              |
            DA              NU
              |              |
       Model local       are user intent freeform?
                              |          |
                            DA          NU
                              |          |
                       Model premium   este pas în plan aprobat?
                                            |          |
                                          DA          NU
                                            |          |
                                     Model mediu   context > 100k tokens?
                                                          |          |
                                                        DA          NU
                                                          |          |
                                                Model premium   Model mediu

Acest tree are 3 noduri de decizie și acoperă peste 95% din cazuri. Pentru restul, default-ul este premium (mai sigur, mai scump) sau medium (mai ieftin, asumăm classificator decent).

Cifre reale

În operarea internă a IRIS pe trei luni:

• Volum total: aproximativ 1.4M invocări LLM
• Distribuție pe clasă: 4.8% premium, 23.7% medium, 71.5% local
• Cost agregat normalizat: 31% față de scenariul mono-model premium
• Erori tracate la executor (când modelul mediu a greșit ceva ce ar fi prins modelul premium): 0.4% din total. Re-routing automat la premium pentru retry.
• Satisfacție internă (calitativ, evaluat săptămânal): identic cu mono-model premium

Reducerea de 69% nu este o estimare proiectată; este măsurată. Diferența până la „70%” anunțat este în marja de variație lunară.

Greșeli comune în routing

Greșeală 1: routing pe lungimea input-ului. „Input scurt → model ieftin” este o aproximare proastă. O cerere scurtă poate fi extrem de ambiguă și să necesite premium. Lungimea nu este proxy pentru complexitate.

Greșeală 2: routing pe userul care întreabă. Tentația de a da unui CEO modelul premium și unui junior modelul ieftin este ușoară și greșită. Sarcina, nu utilizatorul, determină ruta.

Greșeală 3: lipsa de fallback. Dacă modelul ieftin eșuează (output prost, parsare greșită), nu retry-uri repetate pe modelul ieftin. Escaladare automată la modelul premium pentru un singur retry. Fără retry infinit pe ieftin.

Greșeală 4: optimizare prematură. Înainte să implementați routing, măsurați. Dacă agentul vostru face 500 de invocări pe zi și e mono-model premium funcționează economic, routing-ul este over-engineering. Pragul tipic de la care plătește este 10.000+ invocări pe zi.

Provocările tehnice

Context sharing între modele. Dacă modelul premium a inițiat o conversație și modelul mediu trebuie să continue, contextul trebuie transmis. Două abordări: (a) toate modelele primesc același prompt context; (b) un summary scurt este generat de model premium și pasat către model mediu. Varianta (b) este mai ieftină dar pierde nuanțe; pe care o alegeți depinde de domeniu.

Caching prompt-uri. Modelele premium oferă acum caching de prompt cu reducere semnificativă pentru tokens repetate. Dacă același system prompt apare de 1000 de ori pe zi, caching reduce cost fără routing. Combinați: caching plus routing dă cele mai bune rezultate.

Latency budget. Modelul local mic poate fi mai lent în absolută față de modelul cloud premium pentru contexte foarte mici. Pentru polling, latency contează puțin (rulează în background); pentru design interactiv, latency contează mult.

Concluzie

Cost-aware routing nu este o tehnică ezoterică. Este recunoașterea simplă că diferite sarcini au cerințe diferite și că tratarea lor uniformă este irosire. Patternul propose-then-act, descris într-un articol anterior, complementează routing-ul: separarea fazelor face evidentă unde modelul premium merită costul și unde un model mai mic este suficient.

Reducerea factură nu este motivul principal pentru care recomandăm acest pattern. Motivul principal este că ne permite să rulăm un agent la scară fără ca arhitectura să fie blocată de cost. Putem accepta volume mari, putem polling continuu, putem rula proceduri lungi fără să ne uităm la factura zilnic.

Articole conexe

• Arhitectura propose-then-act pentru agenți AI
• MCP server design patterns pentru agenți AI
• Pillar IRIS — agentul orchestrator CAI Technology
• Pillar Consulting — assessment AI

Surse externe

• Anthropic Claude model overview — capabilități și pricing pentru clasele de model premium și mediu
• OpenAI model selection guide — referință pentru selecția de model în funcție de sarcină
• Anthropic prompt caching — reducerea costurilor pentru system prompts repetate
• „FrugalGPT” — Chen et al., arXiv 2305.05176 — research seminal pe routing economic între LLM-uri
• Hugging Face Open LLM Leaderboard — referință pentru capacitatea modelelor open-source folosite local

Următorul pas

Dacă echipa dvs. operează un agent AI și vrea să evalueze potențialul de cost-aware routing pe workload-ul propriu, vă oferim o analiză tehnică de 30 de minute fără cost.