Cum funcționează un gateway LLM? Ghid practic pentru echipele de inginerie

Un gateway LLM se află între aplicațiile tale și furnizorii de modele pe care îi conectezi prin intermediul lui, oferindu-ți un singur loc în care să gestionezi credențialele și să urmărești utilizarea.

„Momentan e un bordel total”, scria pe Reddit, în r/LLMDevs, un inginer în septembrie 2026.

„Fiecare are propriul set de chei pentru Claude, OpenAI, AWS Bedrock și toți ceilalți furnizori de inferență pe care îi folosim.”

Articolul BigGo despre llm-proxy-tk, un gateway FastAPI ușor, compară această configurație cu transformarea LLM-urilor în „apă de la robinet pentru companii”, gateway-ul fiind vana principală a clădirii.

Dar înainte de a acorda atâta încredere instalației, să vedem ce anume instalezi.

Ce este un gateway LLM?

Un gateway LLM este un reverse proxy pentru apelurile către modele. Aplicațiile tale trimit cererile către el, în loc să le trimită direct la OpenAI, Anthropic, Google sau la orice alți furnizori de LLM folosești. Gateway-ul redirecționează aceste cereri și îți aplică regulile pe parcurs.

Fiecare furnizor de LLM are propriul API, cu propriul format al cererilor, propria autentificare și propriul mod de a returna erorile. Fiecare are, de asemenea, limite de rată și moduri de defectare separate. Așadar, dacă nu există un strat comun în fața lor, fiecare aplicație care apelează un furnizor face totul singură și o face puțin diferit.

Analogia cu apa de la robinet are limitele ei, dar te duce până aici: furnizorii sunt racordați o singură dată, la gateway. De acolo încolo, fiecare aplicație primește propria conexiune contorizată, astfel încât poți vedea cine ce folosește și poți închide orice linie fără să le atingi pe celelalte.

Gateway-uri LLM, AI, MCP și API: care este diferența?

Cum funcționează un gateway LLM?

Să urmărim o cerere de la aplicația ta până la model și înapoi.

1. Cererea ajunge la gateway: Aplicația ta trimite o cerere de chat obișnuită, adesea într-un format compatibil cu OpenAI, către endpointul gateway-ului. Din punctul de vedere al aplicației, aceasta este adresa pe care o apelează pentru a ajunge la model.
2. Gateway-ul verifică cine face cererea și ce are voie să facă: Înainte de a redirecționa cererea, validează credențialele. Adesea, este vorba de o cheie virtuală emisă unei echipe sau unui produs. Dacă ai configurat mecanisme de protecție pentru intrări, prompturile pot fi scanate și pentru date sensibile sau pentru încercări de a suprascrie instrucțiunile modelului.
3. Gateway-ul verifică dacă are deja răspunsul: Dacă memorarea în cache este activată, o cerere eligibilă care corespunde uneia anterioare poate primi un răspuns salvat, fără un nou apel către furnizor. Unele gateway-uri oferă și cache semantic, care caută cereri considerate suficient de asemănătoare, în loc de cereri identice. Acest lucru se poate potrivi traficului de tip întrebări frecvente.
4. Gateway-ul alege unde ajunge cererea: Cererea poate indica un anumit model sau un alias. Gateway-ul caută ruta corespunzătoare în configurația ta. Poți configura și o rută de rezervă. Dacă furnizorul A nu răspunde la timp, gateway-ul poate încerca furnizorul B.
5. Gateway-ul pregătește apelul și returnează răspunsul: Gateway-ul convertește cererea ta în formatul furnizorului ales și autentifică apelul de ieșire. Imediat ce primește răspunsul, îl convertește în formatul de care are nevoie aplicația ta.
6. Gateway-ul înregistrează ce s-a întâmplat: Când jurnalizarea este activată, gateway-ul înregistrează detalii precum cine a făcut apelul, ce model l-a servit, numărul de tokenuri, latența și costul. Acesta este jurnalul pe care inginerul de pe Reddit din introducere nu îl avea.

Cele 4 lucruri pe care trebuie să le știi înainte de a pune un gateway în producție

Tot ce am descris în secțiunea de mai sus este posibil pentru că gateway-ul vede fiecare cerere direcționată prin el. Acesta e argumentul de vânzare. Dar este și o descriere a suprafeței de atac și a dependenței de furnizor pe care trebuie să le iei în calcul.

Gateway-ul este acum cea mai valoroasă componentă din stack-ul tău AI

Gateway-ul centralizează accesul. Prin urmare, pune și o mulțime de credențiale la îndemâna unui singur serviciu. Echipa de securitate Microsoft enumeră ce poate deține sau prelua o implementare LiteLLM: cheile API ale furnizorilor, propria cheie master, înregistrările cheilor virtuale, șirurile de conexiune la baza de date, setările de rutare și politicile tenanților.

În octombrie 2026, Check Point Research a dezvăluit două vulnerabilități cu risc ridicat în LiteLLM:

• CVE-2026-35029 permitea utilizatorilor autentificați, inclusiv celor cu acces doar în citire, să ajungă la funcții administrative și să preia controlul asupra instanței.
• CVE-2026-59823 permitea utilizatorilor să redirecționeze cererile către un server controlat de ei și să capteze cheile furnizorilor.

Ambele au fost remediate în versiunea 1.83.9. O aplicație care folosește gateway-ul nu ar trebui să-i poată modifica setările.

Mecanismele de protecție au nevoie de o politică pentru cazurile de eșec

O analiză publicată de Pillar Security pe 4 octombrie 2026 documentează integrările de mecanisme de protecție terțe din principalele gateway-uri, inclusiv LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management și Apigee. (Pillar vinde mecanisme de protecție, așa că ține cont de acest lucru când îi citești recomandările.)

Un hook este un punct din traseul cererii, de obicei înainte ca promptul să ajungă la model sau după ce revine răspunsul, în care gateway-ul poate transmite conținutul unui scanner extern pentru un verdict. O verificare blocantă așteaptă acest verdict înainte de a permite traficului să continue. Documentația Portkey le numește before_request_hooks și after_request_hooks; TrueFoundry rulează patru, adăugând verificări înainte și după apelurile de instrumente MCP.

Acum, două lucruri de verificat:

• Ce se întâmplă dacă scannerul însuși cade? Dacă blochezi cererea, oprești traficul neverificat, dar îți poți întrerupe aplicația. Dacă o lași să treacă, aplicația poate continua fără acea verificare. Jurnalul de erori îți arată ulterior că verificarea a lipsit, ceea ce e util, dar nu înlocuiește efectuarea ei.
• Poți înlocui scannerul? Dacă un alt furnizor nu este acceptat, s-ar putea să fie nevoie să-ți actualizezi aplicația sau să folosești un alt proxy pentru conectare.

Hook-urile MCP ale TrueFoundry extind raza de acțiune a gateway-ului de la cererile către modele la apelurile de instrumente. Dar acesta poate inspecta doar traficul care trece prin el. Un agent de programare care rulează o comandă pe mașina unui dezvoltator se poate afla în afara acestui câmp vizual.

Numbat, proiectul open-source al Perplexity, acoperă exact această parte. Numbat se conectează la agenții acceptați prin hook-uri locale și poate inspecta acțiunile planificate, precum comenzile shell sau scrierile de fișiere, înainte ca acestea să ruleze. Funcția de blocare este opțională și dezactivată implicit. Gateway-ul vede traficul către modele direcționat prin el. Numbat adaugă vizibilitate asupra a ceea ce face agentul cu răspunsul.

Trebuie să știi unde se termină controlul gateway-ului

Forkast News identifică trei linii de evoluție care ajung la gateway din direcții diferite:

• Gateway-uri axate pe LLM: LiteLLM și Portkey au pornit de la apelurile către modele: traducerea între furnizori, rutarea cererilor și urmărirea tokenurilor. Acum adaugă controale pentru apelurile de instrumente.
• Platforme de management al API-urilor: Kong, Apigee de la Google și Azure API Management au pornit de la autentificare, permisiuni și gestionarea traficului, apoi au adăugat suport pentru modele și reguli specifice AI.
• Infrastructură nativă pentru agenți: agentgateway, de exemplu, a fost construit în jurul agenților care comunică cu modele, instrumente și alți agenți, inclusiv prin MCP și A2A.

Întrebarea care face diferența este ce anume direcționezi:

• Doar apeluri către modele? Un gateway orientat spre LLM este un bun punct de plecare.
• Apeluri către modele într-o companie care are deja o mulțime de reguli pentru API-uri? Începe cu platforma pe care o ai.
• Agenți care apelează instrumente care apelează modele? Verifică dacă și acele conexiuni sunt acoperite.

Introduci un punct comun de eșec

Să zicem că chatbotul tău de asistență folosește OpenAI, iar instrumentul tău de cercetare folosește Anthropic, ambele conectate prin același gateway. Dar dacă acel gateway nu mai funcționează, ambele instrumente pierd accesul la modelele lor, chiar dacă OpenAI și Anthropic funcționează normal.

Chiar s-a întâmplat. Rata de erori a AI Gateway de la Cloudflare a atins un vârf de 97% în timpul întreruperii din 12 iunie 2025. Gateway-ul depindea de serviciul de stocare Workers KV al Cloudflare pentru setări, iar acel serviciu avea defecțiuni.

Dacă rulezi singur gateway-ul, ține pornită încă o instanță care poate prelua sarcina dacă una cade. Dacă gateway-ul tău este găzduit de altcineva, întreabă cum îl mențin funcțional în timpul defecțiunilor și ce se întâmplă cu cererile tale în timpul recuperării.

Funcțiile-cheie pe care să le cauți la un gateway LLM

Urmează să-i dai gateway-ului acces la credențialele tuturor, așa că ar trebui să fii exigent cu ceea ce oferă în schimb.

• Un singur API în fața mai multor furnizori: Codul tău folosește un singur format, adesea unul compatibil cu OpenAI, iar gateway-ul face traducerea. Furnizorii de LLM vin și ei în întâmpinare. De exemplu, Agent API de la Perplexity acceptă interfața Responses API de la OpenAI, astfel încât echipele pot reutiliza bibliotecile client OpenAI existente.
• Chei virtuale cu reguli atașate: Fiecare echipă sau produs primește propria cheie, cu reguli care stabilesc modelele permise, limitele de cereri și cheltuielile.
• Rutare și rute de rezervă: Gateway-ul trimite cererile către modele pe baza setărilor tale, care pot favoriza costul, viteza sau un anumit furnizor. Dacă un apel eșuează, poate încerca altul. Agent API de la Perplexity îți permite să enumeri până la cinci modele, inclusiv modele de la furnizori diferiți, în ordinea pe care o preferi.
• Memorare în cache: Un răspuns salvat te poate scuti de încă un apel către furnizor. Unele gateway-uri potrivesc cererile identice; altele pot potrivi și cereri cu sensuri similare. Verifică dacă răspunsurile din cache pot fi separate pe utilizator sau pe echipă și dacă poți dezactiva cache-ul pentru răspunsurile personalizate sau pentru cele care depind de momentul cererii.
• Streaming și erori uniforme: Răspunsurile sosesc pe măsură ce sunt generate, iar erorile furnizorilor sunt traduse într-un format pe care aplicația ta îl poate gestiona. Verifică ce se întâmplă când adaugi mecanisme de protecție AI.
• Jurnalizare și atribuirea costurilor: Gateway-ul înregistrează cine a făcut un apel, ce model l-a servit, câte tokenuri a folosit, cât a durat și costul estimat al acestuia. Verifică dacă jurnalele includ prompturile și răspunsurile și cât timp sunt păstrate.
• Hook-uri pentru mecanismele de protecție: Acestea sunt puncte din traseul cererii în care gateway-ul poate trimite conținut către un scanner extern pentru un verdict. De obicei, se află înainte de o cerere către model sau după răspunsul acestuia. Verifică dacă cererile se opresc sau continuă când scannerul cade și dacă poți conecta un alt scanner.
• O interfață de administrare pe care o poți securiza: Gateway-ul gestionează accesul la credențialele furnizorilor și regulile pe care le folosește toată lumea. Verifică dacă poți restricționa accesul de administrator separat de traficul aplicațiilor și dacă utilizatorii cu acces doar în citire nu pot modifica setările. Vana principală are nevoie de un lacăt.

Ce instrumente poți folosi pentru a-ți construi gateway-ul LLM?

Listele de funcții ale produselor de pe piață se suprapun. Într-un fir de discuție de pe Reddit despre accesul intern la modele, autorul a întrebat: ce gateway nu necesită un inginer dedicat?

În opinia noastră, aceasta este întrebarea potrivită și are patru răspunsuri, în funcție de cât de mult din muncă ești dispus să-ți asumi.

Scrie-l singur

Un gateway minimal se ocupă de o listă scurtă de sarcini: acceptă cereri, verifică cheia apelantului, adaugă credențialul furnizorului, redirecționează apelul și înregistrează rezultatul. Dar suportul pentru formatele diferite ale furnizorilor adaugă muncă. La fel și menținerea întregului sistem în funcțiune.

Dacă folosești deja Envoy, filtrul său de procesare externă îți permite să conectezi un serviciu care inspectează și modifică cererile și răspunsurile. Totuși, trebuie să construiești și să rulezi tu acel serviciu.

Într-un fir de discuție din r/LLMDevs despre dacă un gateway reduce costurile, u/QuanTradin a spus că înregistrarea tokenurilor și a unui indicator de cache hit la fiecare apel a ajutat la identificarea a două joburi care plăteau prețul întreg pentru prompturi identice.

„...remedierea acestui lucru a valorat mai mult decât ar fi valorat orice strat de rutare.”

Este o experiență relatată și un bun punct de plecare. Află pentru ce plătești înainte să construiești metode elaborate de rutare.

Găzduiește singur un gateway open-source

LiteLLM este o alegere frecventă aici: este compatibil cu OpenAI, acceptă o gamă largă de furnizori și are o comunitate mare. Bifrost este o alternativă, construită pentru un overhead redus per cerere. Helicone merită luat în calcul dacă observabilitatea este pe primul loc în lista ta de funcții.

LiteLLM, ca orice produs, are limite pentru unele echipe. Într-un fir de discuție din r/aiagents despre alternative la a-ți construi propriul gateway, u/Own_Bar_920 a spus că LiteLLM s-a descurcat bine cu rutarea, dar, în cazul lor, a fost insuficient pentru versionarea prompturilor între echipe și pentru evaluările continue la schimbarea modelelor, ceea ce i-a determinat să treacă la un instrument separat.

Acestea depășesc rutarea de bază a unui gateway, și tocmai asta e ideea: dacă rutarea este principala nevoie, LiteLLM le-a făcut față.

Primești o listă de funcții gata făcută, unele dintre ele în funcție de ediție, și păstrezi gateway-ul în interiorul rețelei tale. Tot tu răspunzi de aplicarea patch-urilor, aspect ilustrat concret de dezvăluirile Check Point de mai sus, și de disponibilitatea gateway-ului, ilustrată de secțiunea despre punctul comun de eșec.

Dar include în buget pe cineva care să răspundă de el. Una dintre îngrijorările dintr-un fir de discuție din r/LLMDevs despre gateway-uri pentru acces intern era mentenanța. u/Informal-Writer9685 își dorea ceva care „să nu necesite un inginer dedicat pentru mentenanță” și a întrebat dacă instabilitatea raportată a LiteLLM la actualizări era o problemă reală la scara lor sau o grijă valabilă doar în producție.

Folosește un gateway gestionat

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter și gateway-ul găzduit de Portkey rulează serviciul în locul tău. Pentru o aplicație compatibilă, trimiterea primei cereri poate să nu necesite mai mult decât schimbarea unui URL și o cheie API.

Compromisul aici este că fiecare prompt trece acum printr-o terță parte înainte de a ajunge la furnizor. Asta înseamnă încă o persoană împuternicită de operator în documentația ta de conformitate, iar o întrerupere a gateway-ului devine incidentul unui furnizor, a cărui remediere nu ține de tine.

De exemplu, pe 17 și 19 februarie 2026, OpenRouter a avut întreruperi de 38, respectiv 35 de minute, după ce o dependență de cache a cedat. Unii clienți au primit erori „User not found” și au pierdut timp depanând chei API perfect valide. Defecțiunea se afla în infrastructura gateway-ului.

Dar, spre meritul său, OpenRouter a publicat un postmortem detaliat și a adăugat protecții pentru ca o defecțiune a cache-ului să nu-i mai poată suprasolicita baza de date. Un gateway gestionat precum OpenRouter poate simplifica accesul, dar, așa cum subliniază u/QuanTradin pe r/LLMDevs, consolidarea facturilor nu reduce automat cheltuielile.

Extinde gateway-ul API pe care îl ai deja

Dacă Kong, Apigee sau Azure API Management se află deja în fața serviciilor tale, fiecare are capabilități specifice AI: Kong AI Gateway, politicile de gateway AI din Apigee și gateway-ul AI din Azure API Management. Poți porni de la autentificarea, regulile de rețea și procedurile operaționale pe care le ai deja, adăugând controale pentru modele prin pluginuri sau politici.

Aceasta poate fi calea cu cea mai mică rezistență organizațională într-o companie mare. Funcțiile AI sunt mai noi decât cele ale gateway-urilor independente. Asigură-te că testezi limitarea ratei bazată pe tokenuri și streamingul prin întregul set de pluginuri sau politici pe care plănuiești să le folosești.

Așadar, instalați fără ezitare robinetul principal — atotputernicul gateway. Totuși, inginerul din introducere are dreptate. Accesul unei companii la modele nu ar trebui să depindă de cine se întâmplă să aibă cheia potrivită într-un sertar.

Un gateway rezolvă această problemă punând cheile respective sub control centralizat, ceea ce face ca un sertar lăsat deschis să fie cu atât mai riscant. Trebuie să știți al cui este sertarul.

Întrebări frecvente despre gateway-urile LLM

Gateway-ul LLM este gratuit?

Dacă vă referiți la categorie, unele gateway-uri LLM au versiuni gratuite.

Gateway-urile LLM variază de la software open-source gratuit până la planuri plătite care pornesc de la aproximativ 50 USD pe lună, cu prețuri personalizate pentru implementările enterprise. Iar unele percep în schimb un procent; de exemplu, planul Standard de la OpenRouter adaugă 5,5% la achizițiile de credite.

Care este cel mai bun gateway LLM?

Ce parte din muncă sunteți dispus să vă asumați?

• Aruncați o privire la Bifrost sau Helicone dacă doriți să găzduiți singur soluția și să controlați configurația.
• O opțiune gestionată, precum OpenRouter sau Vercel AI Gateway, se potrivește echipelor care vor ca altcineva să opereze serviciul.
• Dacă folosiți deja Kong sau Azure API Management, verificați mai întâi capabilitățile lor de AI.

Testați opțiunile de pe lista scurtă cu propriile cereri, inclusiv ce se întâmplă atunci când un furnizor întâmpină o defecțiune.

Are AWS un gateway LLM?

Da. Amazon Bedrock AgentCore Gateway acceptă apeluri către modele prin ceea ce AWS numește „inference targets” (ținte de inferență). Acestea permit aplicațiilor să folosească un singur endpoint pentru a ajunge la furnizori precum Amazon Bedrock, OpenAI și Anthropic, iar gateway-ul gestionează credențialele furnizorilor și rutarea.