De ce instrumentele de urmărire a LLM-urilor construiesc acum gateway-uri AI

În 2026, LangSmith, Langfuse, Opik și Braintrust au adăugat toate câte un gateway în fața furnizorilor de modele. Principalul motiv este controlul: un instrument de urmărire poate doar să înregistreze un apel către un model, în timp ce un gateway îl poate opri.

Două instrumente cu roluri distincte

În ultimii doi ani, multe echipe au rulat aplicații bazate pe modele lingvistice mari (LLM) folosind două instrumente separate. Între aplicație și furnizorii de modele se afla un gateway. Acesta stoca cheile API ale furnizorilor, traducea între API-urile acestora și reîncerca apelurile eșuate. LiteLLM, un proxy open-source, a devenit o alegere frecventă pentru acest rol. Lângă aplicație se afla un instrument de urmărire, precum LangSmith sau Langfuse, care înregistra fiecare apel către un model, apel de instrument și etapă de recuperare, astfel încât inginerii să poată vedea ce făcuse un agent.

Separarea avea sens, deoarece un gateway trebuie să fie rapid și să accepte API-ul fiecărui furnizor, în timp ce un instrument de urmărire are nevoie de o interfață bună, de spațiu de stocare pentru încărcături utile mari și de un SDK care să încapsuleze codul aplicației. Langfuse documentează în continuare configurația cu două instrumente, cu o integrare LiteLLM Proxy care trimite fiecare apel prin proxy și apoi către Langfuse. În 2026, furnizorii de instrumente de urmărire au început să-și construiască propriul gateway.

Patru lansări în șase luni

LangChain a anunțat gateway-ul LLM LangSmith în versiune beta privată în mai 2026 și l-a lansat în versiune beta publică pe 30 iulie, iar de atunci l-a inclus și în implementările LangSmith în propriul cloud ale clienților. Braintrust a retras din uz proxy-ul său AI anterior și a îndrumat utilizatorii către un gateway nou, aflat în versiune preliminară și gratuit până la disponibilitatea generală. Comet a lansat gateway-ul LLM Opik ca endpoint beta care acceptă solicitări în format OpenAI. Pe 4 noiembrie, Langfuse și-a lansat gateway-ul AI în versiune beta publică, atât pe Langfuse Cloud, cât și pentru implementările găzduite de utilizatori. Gateway-ul este publicat sub licența MIT și scris în Rust.

MLflow, care a început ca instrument de gestionare a ciclului de viață al învățării automate, nu ca instrument de urmărire, are de mai mult timp un gateway AI, cu alerte și limite de buget.

Gateway-urile există de ani de zile, iar riscurile asociate rulării unuia sunt bine documentate. Noile gateway-uri provin de la companii a căror activitate consta în înregistrarea apelurilor către modele, iar acum acestea vor ca fiecare apel să treacă mai întâi prin ele.

De ce bugetul are nevoie de acces la fluxul solicitărilor

Un instrument de urmărire înregistrează un apel către un model după ce furnizorul a răspuns și s-a plătit pentru tokenuri. Acea înregistrare este suficientă pentru a genera un grafic al cheltuielilor, însă instrumentul de urmărire nu poate opri cheltuielile. Respectarea bugetului unei echipe, blocarea unui model sau eliminarea unui secret dintr-un prompt presupun verificarea solicitării înainte ca aceasta să ajungă la furnizor. Numai componenta aflată pe fluxul solicitării poate face acest lucru.

LangChain susține acest argument în articolul său de lansare. Acesta descrie echipe care combină un gateway separat, un produs de protecție și un instrument de observabilitate și afirmă că prevenirea problemelor presupune aplicarea politicilor la nivelul solicitării. Gateway-ul său răspunde cu codul de stare HTTP 402 la un apel care ar depăși bugetul, în loc să-l redirecționeze către furnizor.

Un singur punct de acces înregistrează fiecare apel

Al doilea motiv este acoperirea. Un SDK înregistrează doar căile de execuție a codului pentru care cineva a configurat instrumentarea. În afara acestor căi, erorile agenților tind să treacă neobservate. Un script rulat pe un laptop, un notebook sau un agent de programare care folosește o cheie API copiată nu lasă nicio urmă. Un gateway care deține cheile furnizorilor vede fiecare apel, deoarece nu există altă cale de a ajunge la furnizor.

Langfuse își construiește gateway-ul pornind de la această idee. Potrivit documentației gateway-ului, fiecare cheie de gateway aparține unui utilizator sau unui cont de serviciu și poate include metadate precum o echipă sau un centru de costuri. Numai gateway-ul deține datele de autentificare ale furnizorului, iar administratorii aprobă modelele pe care le poate apela fiecare set de date de autentificare. LangSmith publică pagini de configurare pentru direcționarea apelurilor Claude Code, Codex și Gemini CLI prin gateway-ul său. Acești agenți apelează modele de pe calculatorul unui dezvoltator, în afara codului de urmărire al oricărei aplicații.

Ce adaugă gateway-ul unui instrument de urmărire

Furnizorii de instrumente de urmărire susțin și argumentul invers: un gateway autonom nu este suficient de unul singur. Articolul de lansare al Langfuse afirmă că un gateway autonom poate doar să numere tokenurile și să calculeze costurile, în timp ce gateway-ul propriu integrează fiecare apel într-o urmă completă. Gateway-ul Langfuse acceptă un antet W3C traceparent, astfel încât un apel care trece prin el este inclus în urma pe care aplicația a început-o deja. În mod implicit, acesta înregistrează utilizarea și costul, nu conținutul promptului și al răspunsului.

Acesta este cel mai puternic argument tehnic pentru integrarea gateway-ului în instrumentul de urmărire. Un gateway autonom vede o listă simplă de completări. Instrumentul de urmărire are deja, prin SDK-ul său, apelurile de instrumente și etapele de recuperare ale agentului și poate integra fiecare apel prin gateway în această structură.

Există și o interpretare comercială, pe care furnizorii nu o menționează ei înșiși. Cine operează gateway-ul deține cheile furnizorilor și raportul cheltuielilor, iar acesta din urmă este consultat de echipele financiare și de platformă. Astfel, un gateway este mai greu de înlocuit decât un vizualizator de trasee. LangSmith și Langfuse valorifică deja diferit această poziție: LangSmith vinde Gateway Credits, care le permit clienților să apeleze modele găzduite, precum Kimi, fără propria cheie de furnizor, în timp ce în secțiunea de întrebări frecvente Langfuse precizează că nu revinde tokenuri.

Ce nu pot încă gateway-urile beta

Aceste gateway-uri sunt la început, iar furnizorii își documentează propriile limitări. În prezent, gateway-ul Langfuse acceptă doar OpenAI și Anthropic, iar Amazon Bedrock, Google Vertex AI și Google AI Studio figurează în foaia sa de parcurs. Mecanismele de rezervă între furnizori și limitele stricte de cheltuieli pentru fiecare echipă, utilizator sau cheie sunt planificate, dar nu au fost încă lansate; deocamdată, gateway-ul oferă un tablou de bord al cheltuielilor și alerte. Documentația sa nu menționează limite de rată sau memorarea în cache a răspunsurilor.

Gateway-ul Langfuse nu convertește formatele API, așa că un client OpenAI poate apela doar modele OpenAI. Versiunea găzduită local apelează numai URL-uri oficiale ale furnizorilor, ceea ce exclude deocamdată Azure OpenAI, Bedrock sau un proxy intern. Comet descrie gateway-ul Opik ca fiind conceput pentru dezvoltare și testare. Braintrust nu a anunțat prețurile pentru gateway-ul său.

Gateway-ul LangSmith oferă deja mai multe funcții decât celelalte. Documentația sa enumeră mecanismele de rezervă, limitele de cheltuieli, limitele de rată și politicile privind datele drept funcții disponibile în prezent; de asemenea, acceptă formatele OpenAI Chat Completions, OpenAI Responses și Anthropic Messages. În mai, mecanismele de rezervă și limitele de rată figurau printre funcțiile planificate, așadar au fost lansate în perioada beta. Produsul este în continuare etichetat ca beta.

Testele de încărcare scot la iveală un alt tip de limitare. Un test de performanță găzduit local, realizat pentru gateway-ul Langfuse, LiteLLM și AcruxCore, a constatat că gateway-ul Langfuse adăuga mai puțină latență pentru fiecare apel decât LiteLLM. Cu toate acestea, folosind setările Docker implicite, acesta a eșuat în cazul a 739 dintre cele 1.000 de fluxuri simultane, deoarece procesul său păstra limita implicită de 1.024 de fișiere deschise din Docker. O singură linie din fișierul Compose al Langfuse a rezolvat problema.

Spre deosebire de aceste versiuni beta, LiteLLM, un gateway independent de ani buni, acceptă peste 100 de furnizori și include deja chei virtuale, urmărirea cheltuielilor, măsuri de protecție, echilibrarea încărcării și un tablou de bord de administrare. LiteLLM își mută, de asemenea, calea de procesare a solicitărilor din Python în Rust. Gateway-ul AI în Rust este în versiune beta, iar echipa LiteLLM se așteaptă ca solicitările /v1/messages, în stilul Anthropic, să fie procesate integral în Rust până la 1 decembrie, cu o latență de aproximativ 20 de ori mai mică. Câteva platforme open-source, precum MLflow și AcruxCore, oferă deja într-un singur produs atât un gateway, cât și funcții de urmărire.

Argumente pentru a le păstra separate

Integrarea gateway-ului în sistemul de urmărire implică anumite costuri, iar cel mai important este interdependența. Cu un gateway separat, o echipă poate schimba furnizorul de servicii de urmărire modificând un apel de înregistrare. Dacă sistemul de urmărire este și gateway, se schimbă și adresa URL de bază, cheile și identificatorii modelelor pentru fiecare serviciu. De exemplu, Langfuse scrie identificatorii modelelor în formatul acreditare:model.

Sistemul de urmărire devine, de asemenea, o dependență la rulare. Dacă serviciul de urmărire nu mai funcționează, echipa pierde traseele. Dacă nu mai funcționează un gateway, apelurile către modele eșuează. Un furnizor de servicii de urmărire care operează gateway-ul trebuie acum să asigure disponibilitatea necesară unei infrastructuri critice.

Furnizorii de soluții de securitate vor să ocupe aceeași poziție pe traseul solicitărilor. În mai 2026, Palo Alto Networks a finalizat achiziția Portkey, un gateway independent, și l-a integrat ca gateway AI în platforma sa Prisma AIRS. O echipă de securitate poate dori ca gateway-ul să fie sub controlul său, nu integrat într-un instrument de observabilitate. Gateway-urile au devenit și ținte pentru atacatori, după cum a arătat atacul asupra lanțului de aprovizionare LiteLLM din martie.

Cum pot alege echipele

Echipele pot începe prin a enumera ce trebuie să se întâmple înainte de un apel către un model. Dacă au nevoie doar de vizibilitate, este suficient un sistem de urmărire amplasat în afara traseului solicitărilor, care nu adaugă nicio dependență la rulare. Dacă au nevoie și de bugete, politici privind cheile sau aprobarea modelelor, le trebuie un gateway de un anumit fel.

Următorul pas este să verifice acoperirea furnizorilor. O echipă ar trebui să noteze toți furnizorii și formatele API pe care le apelează în mediul de producție, inclusiv Azure OpenAI și Bedrock, apoi să compare lista cu funcțiile acceptate în prezent de fiecare gateway, nu cu cele prevăzute în foaia sa de parcurs.

Echipele care folosesc deja LiteLLM au puține motive să migreze înainte ca un gateway beta să ofere ceva ce le lipsește. Principalul avantaj pe care îl aduce gateway-ul unui sistem de urmărire este includerea apelului către gateway în traseul agentului, iar acest beneficiu trebuie să justifice migrarea. Echipele care pornesc de la zero pot păstra gateway-ul ca strat separat chiar și atunci când același furnizor le oferă pe amândouă. Dacă adresa URL de bază și cheile sunt păstrate într-un singur modul de configurare, o migrare ulterioară va necesita modificarea configurației, nu a codului.

Majoritatea acestor gateway-uri sunt etichetate ca versiuni beta sau de previzualizare, așa că lista limitărilor se va scurta rapid. Întrebarea deschisă este cine va controla traseul solicitărilor într-o companie obișnuită: echipa de observabilitate, echipa de platformă care operează un gateway independent sau echipa de securitate. Anul acesta, LangSmith și Langfuse și-au construit propriile gateway-uri, iar Palo Alto Networks a cumpărat unul; cu toate acestea, în multe configurații, solicitările trec în continuare prin LiteLLM.