AI Gateway: routing inteligent între OpenAI, Claude și Gemini pentru cost optim

01De ce un singur furnizor nu mai este suficient

Strategia mono-furnizor a funcționat în 2023, când diferențele între modele erau mari și API-urile încă imature. Astăzi, peisajul s-a maturizat: OpenAI excelează la cod și la function calling structurat, Anthropic Claude domină raționamentul lung și prompturile complexe, iar Google Gemini oferă context ferestre uriașe la prețuri agresive. Niciun furnizor nu este simultan cel mai bun, cel mai ieftin și cel mai rapid pentru toate task-urile.

În plus, dependența de un singur furnizor introduce risc operațional. Incidentele de mai multe ore pe anumite regiuni au demonstrat că lipsa fallback-ului transformă o problemă a unui terț într-o problemă a produsului tău. Echipele serioase nu mai acceptă acest risc: ele construiesc gateway-uri care comută automat traficul către un furnizor secundar atunci când rata erorilor sau latența urcă peste un prag definit.

În fine, există presiunea conformității. Anumite seturi de date trebuie procesate exclusiv în UE, altele necesită zero retention, iar unele cerințe interne interzic accesul la anumiți furnizori. Un gateway îți oferă punctul central unde aplici aceste politici, fără să atingi codul aplicației.

• →Diferențe mari de cost între modele pentru același task
• →Fereastre de context și capabilități function calling diferite
• →Riscuri de incident pe un singur furnizor
• →Cerințe de rezidență a datelor pe regiuni
• →Politici de retention și logging diferite

02Arhitectura unui AI Gateway production-ready

Un gateway matur are minim cinci componente: un router care alege modelul, un strat de cache pentru prompturi identice sau aproape identice, un mecanism de fallback și retry, o componentă de observabilitate care colectează tokeni și cost per cerere, plus un strat de policy enforcement pentru tenants și rate limiting. Aceste componente comunică printr-un pipeline asincron, cu timeout-uri agresive și circuit breakers.

Datele de configurare nu trăiesc în cod. Toate regulile, modelele active, prețurile per token și politicile per client se țin într-o bază de date sau într-un store gen Redis cu hot reload, astfel încât echipa de produs poate ajusta routing-ul fără deploy. Echipa Blackbone preferă să modeleze regulile ca un mic DSL, ușor de citit de stakeholders non-tehnici, iar interpretorul rulează pe edge pentru latență minimă.

Toate cererile primesc un identificator de corelație care ajunge până în log-urile furnizorului. Așa poți reproduce o problemă raportată de un client pe baza unui singur ID, fără să cauți în patru sisteme diferite.

03Routing semantic: cum alegi modelul potrivit pentru fiecare cerere

Routing-ul naiv folosește reguli statice: cererile sub un anumit număr de token-uri merg pe modelul ieftin, restul pe cel premium. Funcționează surprinzător de bine ca punct de pornire, dar lasă valoare pe masă. Routing-ul semantic mai inteligent clasifică intenția cererii folosind un model mic de tip embeddings sau un clasificator dedicat, apoi alege modelul potrivit.

În practică, definești un set de buckete: clasificare, extragere date, generare cod, raționament complex, generare conținut, sumarizare. Fiecare bucket are un model preferat și unul de fallback. Un clasificator rulat local sau prin embeddings ieftine atribuie cererea unui bucket în câteva milisecunde. Costul acestui pas suplimentar este neglijabil în comparație cu economiile pe ruta principală.

Pentru cazuri foarte sensibile la calitate, gateway-ul poate rula două modele în paralel și alege răspunsul mai bun printr-un judge LLM. Strategia se numește n-of-m și se aplică selectiv, pe cele 5-10% din cereri unde calitatea contează mai mult decât costul.

• →Clasificare prin embeddings ieftine sub 5ms
• →Reguli per bucket cu model primar și de fallback
• →Override manual pentru clienți enterprise
• →Strategii n-of-m pentru cereri critice
• →Învățare offline din feedback și telemetrie

04Fallback chains, retry și controlul latenței

Un lanț de fallback bine construit nu înseamnă să încerci toți furnizorii pe rând. Înseamnă să ai trei nivele clare: primary, secondary și emergency. Primary este alegerea optimă a router-ului. Secondary este un model echivalent la un alt furnizor, activat dacă primary returnează 429, 500 sau dacă latența depășește un prag definit. Emergency este un model lightweight, foarte rapid, folosit doar pentru a evita timeout-ul complet către utilizator.

Retry-ul are propriile capcane. Un retry agresiv pe o eroare de rate limit doar agravează problema. Folosește exponential backoff cu jitter și păstrează un buget total de timp pentru întreaga cerere. Dacă utilizatorul așteaptă, e mai bine să livrezi un răspuns parțial degraded decât niciunul.

Latența percepută contează mai mult decât latența medie. Construiește gateway-ul astfel încât p95 și p99 să fie monitorizate separat, iar regulile de routing să țină cont de profilul recent al fiecărui furnizor pe regiunea respectivă. Un furnizor care era cel mai rapid acum o oră poate fi al doilea cel mai bun acum.

05Prompt cache: cea mai mare economie pe care o ratează multe echipe

În aplicațiile reale, există un set surprinzător de mare de prompturi identice sau cvasi-identice: același system prompt, aceleași tool definitions, aceleași exemple few-shot. Cache-ul de prompturi exploatează această realitate. La nivel de furnizor, anumite modele oferă cache nativ pentru porțiunile statice ale prompt-ului, cu reduceri de cost de până la 90% pe acele porțiuni.

La nivel de gateway, poți merge mai departe cu un cache de răspunsuri pentru cereri identice deterministe, cu chei calculate pe hash de prompt plus parametri. Pentru cereri aproape identice, un cache semantic bazat pe embeddings poate returna răspunsuri suficient de bune cu praguri de similaritate ajustabile. La firma de IT Blackbone aplicăm cache semantic doar pe fluxuri unde tolerăm aproximarea, niciodată pe răspunsuri tranzacționale.

Cache-ul trebuie să fie observabil. Trebuie să știi rata de hit, economia generată, dimensiunea totală și politica de invalidare. Fără aceste metrici, cache-ul se transformă rapid într-o sursă de bug-uri tăcute.

06Observabilitate cost: ce metrici contează cu adevărat

Costul lunar agregat nu este util pentru deciziile zilnice. Ai nevoie de breakdown pe trei axe simultan: tenant, feature și model. Doar așa identifici că un singur client a sărit cu 400% din cauza unui prompt prost gândit, sau că o anumită feature consumă disproporționat din buget. Salvezi metricile într-un warehouse de tip ClickHouse, BigQuery sau Snowflake, separat de logging-ul operațional.

Construiește dashboards care răspund la întrebări de business, nu doar la întrebări tehnice: care este costul mediu per utilizator activ lunar, care este costul per conversație rezolvată, care este marja brută per tier de subscripție. Aceste numere conduc deciziile de pricing și de roadmap, nu graficele cu tokeni totali.

Alertele pe cost trebuie să fie multistratificate. O alertă la +20% peste media săptămânală, o alertă pe spike instant pe un singur tenant și o alertă pe schimbarea bruscă a ratei de cache hit. Echipa Blackbone implementează aceste alerte direct în Slack sau în PagerDuty, cu link-uri către dashboard-ul relevant.