Perplexity explică mecanismele gateway-urilor LLM și riscurile din producție

Perplexity a publicat pe 27 octombrie 2026 un ghid practic despre gateway-urile LLM, explicând echipelor de inginerie cum direcționează, autentifică, stochează în cache și înregistrează stratul intermediar apelurile către modele și prezentând riscurile de securitate și fiabilitate asociate concentrării acreditărilor furnizorilor într-un singur serviciu.

Definiția și taxonomia gateway-urilor

Ghidul definește un gateway LLM drept un proxy invers pentru apelurile către modele: aplicațiile trimit solicitări gateway-ului, în loc să se conecteze direct la furnizori precum OpenAI, Anthropic sau Google, iar gateway-ul le transmite mai departe aplicând regulile operatorului. Ghidul prezintă această categorie drept o soluție la proliferarea necontrolată a acreditărilor și începe cu o postare din septembrie 2026 pe Reddit, în r/LLMDevs, în care un inginer descria un loc de muncă unde fiecare avea propriile chei pentru Claude, OpenAI, AWS Bedrock și alți furnizori de inferență.

Tabelul comparativ din ghid distinge patru tipuri de gateway. Un gateway API se află în fața serviciilor de backend și decide dacă un client este autentificat și dacă se încadrează în limita de solicitări. Un gateway LLM se află în fața furnizorilor de modele și decide ce model primește o solicitare, cine o plătește și dacă a primit un răspuns. Un gateway MCP decide dacă un agent poate apela un anumit instrument cu argumentele date. Ghidul folosește termenul „gateway AI” pentru produsele furnizorilor care reunesc o combinație a acestor roluri.

Ciclul de viață al unei solicitări în șase pași

Ghidul explică mecanismele urmărind o solicitare de la aplicație la model și înapoi. Mai întâi, aplicația trimite gateway-ului, la punctul său de acces, o solicitare de chat, adesea într-un format compatibil cu OpenAI. Gateway-ul validează acreditările, de regulă o cheie virtuală atribuită unei echipe sau unui produs, și, dacă sunt configurate controale de protecție pentru datele de intrare, poate scana solicitările pentru a detecta date sensibile sau încercări de a suprascrie instrucțiunile modelului. Dacă memorarea în cache este activată, solicitările eligibile care se potrivesc pot primi un răspuns salvat; unele gateway-uri oferă și memorare semantică în cache, care identifică solicitări considerate similare, nu neapărat identice. Apoi, gateway-ul caută ruta corespunzătoare în configurația sa și poate apela un furnizor de rezervă dacă primul furnizor nu răspunde în intervalul de timp alocat. Transformă solicitarea în formatul furnizorului ales, autentifică apelul de ieșire și adaptează răspunsul înapoi pentru aplicație. Dacă înregistrarea în jurnal este activată, notează cine a făcut apelul, ce model l-a procesat, numărul de tokenuri, latența și costul.

Riscuri de securitate și fiabilitate

Avertismentul central al ghidului este că gateway-ul concentrează acreditările. Echipa de securitate a Microsoft a enumerat ce poate conține sau prelua o implementare LiteLLM: chei API ale furnizorilor, cheia principală LiteLLM, înregistrări ale cheilor virtuale, șiruri de conectare la baze de date, configurația de rutare și date despre politicile pentru locatari. În postarea din 26 august 2026, Microsoft a descris un caz observat de compromitere a unui gateway LiteLLM, în care atacatorii au sustras acreditări din mediul de execuție al gateway-ului.

Pe 13 octombrie 2026, Check Point Research a dezvăluit două vulnerabilități cu risc ridicat în LiteLLM: CVE-2026-35029, o breșă de control al accesului care le permitea utilizatorilor autentificați, inclusiv celor cu acces doar pentru citire, să acceseze funcții administrative și să preia controlul asupra gateway-ului, și CVE-2026-59823, o vulnerabilitate de falsificare a solicitărilor pe partea serverului, care le permitea utilizatorilor să redirecționeze solicitările gateway-ului către un server controlat de atacator și să captureze cheile API ale furnizorilor de AI. Ambele vulnerabilități au fost remediate în versiunea 1.83.9 a LiteLLM. Check Point a raportat că LiteLLM avea 97 de milioane de descărcări pe lună și peste 59.000 de stele pe GitHub și a declarat că procesul de divulgare coordonată către LiteLLM a început în octombrie 2025.

Ghidul le recomandă echipelor să stabilească o politică pentru situațiile în care controalele de protecție eșuează. Acesta descrie hook-urile drept puncte din fluxul solicitării în care gateway-ul transmite conținutul unui sistem extern de scanare, pentru a primi o evaluare. Ghidul notează că documentația Portkey menționează before_request_hooks și after_request_hooks, iar TrueFoundry rulează patru hook-uri, adăugând verificări înainte și după apelurile către instrumentele MCP.

În privința fiabilității, ghidul indică întreruperi documentate. Relatarea Cloudflare despre întreruperea din 12 iunie 2025 afirmă că rata de eroare a AI Gateway a atins un vârf de 97% dintre solicitări, deoarece AI Gateway se bazează pe Workers KV pentru configurațiile clientului și cele interne; întreruperea generală a durat 2 ore și 28 de minute. Analiza ulterioară publicată de OpenRouter despre întreruperile din 17 și 19 februarie 2026 precizează că incidentele au durat 38, respectiv 35 de minute, după ce a cedat o dependență terță de memorare în cache. Acestea au generat erori 401 „Utilizatorul nu a fost găsit” și au dus la măsuri de remediere, inclusiv întrerupătoare de circuit și returnarea erorilor 503 în locul celor 401 atunci când problemele de infrastructură blochează verificările de autorizare.

Opțiuni de implementare, prețuri și detalii despre furnizori

Ghidul prezintă patru modalități de implementare. Echipele pot dezvolta intern un gateway minimal — care acceptă solicitări, verifică cheia apelantului, adaugă acreditarea furnizorului, transmite apelul și înregistrează rezultatul — sau pot găzdui pe propriile servere un gateway cu sursă deschisă, LiteLLM, Bifrost și Helicone fiind prezentate ca opțiuni. Printre gateway-urile gestionate se numără Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter și gateway-ul găzduit de Portkey. A patra opțiune constă în extinderea unui gateway API pe care compania îl utilizează deja; exemplele menționate sunt Kong AI Gateway, politicile de gateway AI ale Apigee și gateway-ul AI din Azure API Management.

În privința costurilor, ghidul precizează că gateway-urile LLM variază de la software gratuit cu sursă deschisă la planuri plătite, cu prețuri începând de la aproximativ 50 $ pe lună și tarife personalizate pentru companii, iar unele percep în schimb un procent: planul Standard al OpenRouter, menționează ghidul, adaugă 5,5% la achizițiile de credite.

Ghidul se încheie cu răspunsuri specifice fiecărui furnizor. Acesta precizează că Amazon Bedrock AgentCore Gateway acceptă apeluri către modele prin ceea ce AWS numește „ținte de inferență”, permițând aplicațiilor să folosească un singur punct final pentru a accesa furnizori precum Amazon Bedrock, OpenAI și Anthropic. Ghidul menționează că propriul Agent API al Perplexity acceptă interfața Responses API a OpenAI, astfel încât echipele să poată reutiliza bibliotecile de client OpenAI existente, și că Agent API le permite utilizatorilor să enumere până la cinci modele, inclusiv modele de la furnizori diferiți, în ordinea preferată. Ghidul menționează și Numbat, soluția open-source a Perplexity, care se conectează la agenții acceptați prin hook-uri locale și poate inspecta acțiunile planificate, precum comenzile shell sau scrierea fișierelor, înainte ca acestea să fie executate; blocarea este opțională și dezactivată implicit.