Kako funkcioniše LLM gejtvej? Praktičan vodič za inženjerske timove

LLM gejtvej je reverzni proksi koji usmerava, autentifikuje, kešira i beleži vaše pozive modela; ovaj vodič prati jedan zahtev kroz gejtvej, opisuje bezbednosne rizike i rizike po pouzdanost koje treba predvideti i poredi opcije: izradu sopstvenog rešenja, samostalni hosting, upravljane usluge i API gejtveje.

Diagram of how a request moves through an LLM gateway: apps send requests to the gateway, which runs six steps (key and policy check, cache, route, translate and send, normalize and stream back, log and attribute cost) before reaching Provider A, Provider B, or a self-hosted model, with responses returning to the apps.

LLM gateway se nalazi između vaših aplikacija i provajdera modela koje preko njega povezujete i pruža vam jedno mesto za upravljanje akreditivima i praćenje korišćenja.

„Trenutno je to jedno veliko sr*nje“, napisao je na Redditu u r/LLMDevs jedan inženjer u septembru 2026.

„Svako ima svoj set ključeva za Claude, OpenAI, AWS Bedrock i sve ostale provajdere inferencije koje koristimo.“

Tekst portala BigGo o alatu llm-proxy-tk, laganom FastAPI gateway-u, ovu postavku poredi sa pretvaranjem LLM-ova u „korporativnu vodu iz slavine“, pri čemu gateway ima ulogu glavnog ventila zgrade.

Ali pre nego što toliko poverenja ukažete vodovodnim instalacijama, pogledajmo šta zapravo instalirate.

Šta je LLM gateway?

LLM gateway je reverzni proksi za pozive modela. Vaše aplikacije šalju zahteve njemu, umesto direktno kompanijama OpenAI, Anthropic, Google ili bilo kom LLM provajderu koji koristite. Gateway prosleđuje te zahteve i usput primenjuje vaša pravila.

Svaki LLM provajder ima svoj API: sopstveni format zahteva, sopstvenu autentifikaciju i sopstveni način vraćanja grešaka. Svaki ima i zasebna ograničenja broja zahteva i specifične načine otkazivanja. Ako ispred njih ne postoji zajednički sloj, svaka aplikacija koja poziva provajdera sve radi sama, i to svaka na malo drugačiji način.

Analogija sa vodom iz slavine ima svoje granice, ali do ove tačke funkcioniše: provajderi se priključuju samo jednom, na gateway-u. Od tog trenutka svaka aplikacija dobija sopstveni priključak sa meračem, tako da vidite ko šta koristi i možete da zatvorite bilo koji pojedinačni vod, a da ne dirate ostale.

LLM, AI, MCP i API gateway-i: u čemu je razlika?

Gateway

Ispred čega se nalazi?

O čemu odlučuje?

Granice njegove vidljivosti

API gateway

Vaši servisi i drugi backend API-ji

Da li je ovaj klijent autentifikovan i da li je u okviru svog ograničenja broja zahteva?

Može da pregleda telo zahteva, ali obračun tokena i druge kontrole specifične za modele zahtevaju dodatnu podršku.

LLM gateway

Provajderi modela

Koji model dobija ovaj zahtev, ko ga plaća i da li je odgovor stigao?

Vidi pozive alata predložene u odgovorima modela, ali ne i njihovo izvršavanje, osim ako i taj saobraćaj ne prolazi kroz njega.

MCP gateway

Alati i izvori podataka na koje se agent povezuje putem MCP-a

Može li ovaj agent da pozove ovaj alat, sa ovim argumentima?

Ne vidi automatski poziv modela koji je generisao zahtev ka alatu.

AI gateway

Sve što je dobavljač objedinio: modele, a potencijalno i alate i saobraćaj između agenata

Kombinacija navedenog, u zavisnosti od proizvoda

Zavisi od toga koje veze obrađuje.

Kako funkcioniše LLM gateway?

Pratite jedan zahtev od vaše aplikacije do modela i nazad.

  1. Zahtev stiže do gateway-a: Vaša aplikacija šalje naizgled običan chat zahtev, često u formatu kompatibilnom sa OpenAI API-jem, na endpoint gateway-a. Iz perspektive aplikacije, to je adresa koju poziva da bi došla do modela.
  2. Gateway proverava ko šalje zahtev i šta sme da radi: Pre prosleđivanja zahteva proverava akreditive. To je često virtuelni ključ dodeljen timu ili proizvodu. Ako ste uključili ulazne zaštitne mehanizme, promptovi se mogu skenirati i radi otkrivanja osetljivih podataka ili pokušaja da se zaobiđu instrukcije modela.
  3. Gateway proverava da li već ima odgovor: Ako je keširanje omogućeno, na odgovarajući zahtev koji ispunjava uslove može se odgovoriti sačuvanim odgovorom, bez novog poziva provajderu. Neki gateway-i nude i semantičko keširanje, koje traži zahteve procenjene kao dovoljno slične, a ne identične. To može da odgovara saobraćaju tipa čestih pitanja (FAQ).
  4. Gateway bira kuda zahtev ide: Zahtev može da navede određeni model ili alias. Gateway u vašoj konfiguraciji pronalazi odgovarajuću rutu. Možete da konfigurišete i rezervnu rutu. Ako provajder A ne odgovori na vreme, gateway može da pokuša sa provajderom B.
  5. Gateway priprema poziv i vraća odgovor: Gateway konvertuje vaš zahtev u format izabranog provajdera i autentifikuje odlazni poziv. Čim primi odgovor, konvertuje ga u format koji vaša aplikacija zahteva.
  6. Gateway beleži šta se dogodilo: Kada je evidentiranje uključeno, gateway beleži detalje, uključujući ko je uputio poziv, koji model ga je obradio, broj tokena, latenciju i trošak. To je evidencija koju inženjer sa Reddita iz uvoda nije imao.

4 stvari koje treba da znate pre nego što gateway pustite u produkciju

Sve iz prethodnog odeljka moguće je zato što gateway vidi svaki zahtev koji se kroz njega rutira. To je prodajni argument. Ali to je ujedno i opis površine napada i zavisnosti od dobavljača za koje morate da se pripremite.

Gateway je sada najvredniji deo vašeg AI steka

Gateway centralizuje pristup. Samim tim, mnogo akreditiva stavlja na domet jednog servisa. Bezbednosni tim kompanije Microsoft navodi šta LiteLLM implementacija može da čuva ili preuzima: API ključeve provajdera, sopstveni glavni ključ, zapise virtuelnih ključeva, stringove za povezivanje sa bazom podataka, podešavanja rutiranja i politike zakupaca.

U oktobru 2026. Check Point Research je objavio dve visokorizične ranjivosti u alatu LiteLLM:

  • CVE-2026-35029 je autentifikovanim korisnicima, uključujući i one sa pravom samo za čitanje, omogućavala da pristupe administrativnim funkcijama i preuzmu kontrolu nad instancom.
  • CVE-2026-59823 je korisnicima omogućavala da preusmere zahteve na server koji kontrolišu i presretnu ključeve provajdera.

Obe su ispravljene u verziji 1.83.9. Aplikacija koja koristi gateway ne bi trebalo da može da menja njegova podešavanja.

Vašim zaštitnim mehanizmima je potrebna politika za slučaj otkaza

Pregled kompanije Pillar Security od 4. oktobra 2026. dokumentuje integracije zaštitnih mehanizama trećih strana u vodećim gateway-ima, uključujući LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management i Apigee. (Pillar prodaje zaštitne mehanizme, pa to imajte na umu kada čitate njegove preporuke.)

Hook je tačka na putanji zahteva, obično pre nego što prompt ode do modela ili nakon što se odgovor vrati, u kojoj gateway može da prosledi sadržaj spoljnom skeneru radi presude. Blokirajuća provera čeka tu presudu pre nego što dozvoli da saobraćaj nastavi. Dokumentacija platforme Portkey ih naziva before_request_hooks i after_request_hooks; TrueFoundry koristi četiri, dodajući provere pre i posle poziva MCP alata.

Sada treba proveriti dve stvari:

  • Šta se dešava ako sam skener otkaže? Ako blokirate zahtev, zaustavljate neprovereni saobraćaj, ali možete da prekinete rad aplikacije. Ako ga propustite, aplikacija može da nastavi bez te provere. Evidencija otkaza vam naknadno pokazuje da provera nije izvršena, što je korisno, ali nije isto kao da je izvršena.
  • Možete li da zamenite skener? Ako drugi provajder nije podržan, možda ćete morati da ažurirate aplikaciju ili da se povežete preko drugog proksija.

MCP hook-ovi platforme TrueFoundry proširuju domet gateway-a sa zahteva ka modelima na pozive alata. Ali on može da pregleda samo saobraćaj koji prolazi kroz njega. Agent za programiranje koji pokreće komandu na računaru programera može biti van tog vidokruga.

Numbat, alat otvorenog koda kompanije Perplexity, radi na toj strani. Numbat se povezuje sa podržanim agentima preko lokalnih hook-ova i može da pregleda planirane radnje, poput shell komandi ili upisa u fajlove, pre nego što se izvrše. Funkcija blokiranja je opciona i podrazumevano je isključena. Gateway vidi saobraćaj ka modelima koji se rutira kroz njega. Numbat dodaje uvid u to šta agent radi sa odgovorom.

Morate da znate gde se završava kontrola gateway-a

Forkast News izdvaja tri razvojne linije koje gateway-u prilaze iz različitih pravaca:

  • Gateway-i fokusirani na LLM: LiteLLM i Portkey su počeli od poziva modela: prevođenja između provajdera, rutiranja zahteva i praćenja tokena. Sada dodaju kontrole za pozive alata.
  • Platforme za upravljanje API-jima: Kong, Apigee kompanije Google i Azure API Management počeli su od autentifikacije, dozvola i upravljanja saobraćajem, a zatim dodali podršku za modele i pravila specifična za AI.
  • Infrastruktura izvorno namenjena agentima: agentgateway je, na primer, izgrađen oko agenata koji komuniciraju sa modelima, alatima i drugim agentima, između ostalog i putem protokola MCP i A2A.

Ključno pitanje za razvrstavanje je šta rutirate:

  • Samo pozive modela? Gateway koji je prvenstveno namenjen LLM-ovima dobra je polazna tačka.
  • Pozive modela u preduzeću koje već ima mnoštvo API pravila? Počnite od platforme koju već imate.
  • Agente koji pozivaju alate koji pozivaju modele? Proverite da li su i te veze pokrivene.

Uvodite zajedničku tačku otkaza

Recimo da vaš chatbot za podršku koristi OpenAI, a alat za istraživanje Anthropic, i da se oba povezuju preko istog gateway-a. Ali ako taj gateway prestane da radi, oba alata gube pristup svojim modelima, čak i ako OpenAI i Anthropic normalno rade.

Ovo se zaista dogodilo. Tokom prekida rada 12. juna 2025. stopa grešaka servisa Cloudflare AI Gateway dostigla je vrhunac od 97%. Gateway se za podešavanja oslanjao na Cloudflare servis za skladištenje Workers KV, a taj servis je otkazivao.

Ako sami pokrećete gateway, držite pokrenutu još jednu kopiju koja može da preuzme posao ako jedna otkaže. Ako vaš gateway hostuje neko drugi, pitajte kako ga održavaju u radu tokom otkaza i šta se dešava sa vašim zahtevima tokom oporavka.

Ključne funkcije koje treba tražiti kod LLM gateway-a

Gateway-u ćete dati pristup svačijim akreditivima, pa bi trebalo da budete zahtevni u pogledu onoga što vam on pruža zauzvrat.

  • Jedan API ispred više provajdera: Vaš kod koristi jedan format, često kompatibilan sa OpenAI API-jem, a gateway prevodi. I LLM provajderi se prilagođavaju ovom pristupu. Na primer, Agent API kompanije Perplexity podržava interfejs OpenAI Responses API-ja, pa timovi mogu ponovo da koriste postojeće OpenAI klijentske biblioteke.
  • Virtuelni ključevi sa pridruženim pravilima: Svaki tim ili proizvod dobija sopstveni ključ, sa pravilima koja određuju dozvoljene modele, ograničenja zahteva i potrošnju.
  • Rutiranje i rezervne opcije: Gateway šalje zahteve modelima na osnovu vaših podešavanja, koja mogu davati prednost ceni, brzini ili određenom provajderu. Ako poziv ne uspe, može da pokuša sa drugim. Agent API kompanije Perplexity omogućava vam da navedete do pet modela, uključujući modele različitih provajdera, željenim redosledom.
  • Keširanje: Sačuvan odgovor može da vam uštedi još jedan poziv provajderu. Neki gateway-i prepoznaju identične zahteve, a drugi mogu da prepoznaju i zahteve sličnog značenja. Proverite da li keširani odgovori mogu da se razdvoje po korisniku ili timu i da li možete da isključite keširanje za personalizovane ili vremenski osetljive odgovore.
  • Strimovanje i dosledne greške: Odgovori stižu kako se generišu, a greške provajdera prevode se u format koji vaša aplikacija može da obradi. Proverite šta se dešava kada dodate AI zaštitne mehanizme.
  • Evidentiranje i raspodela troškova: Gateway beleži ko je uputio poziv, koji model ga je obradio, koliko je tokena potrošeno, koliko je trajao i njegov procenjeni trošak. Proverite da li evidencija sadrži promptove i odgovore i koliko dugo se čuva.
  • Hook-ovi za zaštitne mehanizme: To su tačke na putanji zahteva u kojima gateway može da pošalje sadržaj spoljnom skeneru radi presude. Obično se nalaze pre zahteva ka modelu ili nakon njegovog odgovora. Proverite da li se zahtevi zaustavljaju ili nastavljaju kada skener otkaže i da li možete da povežete drugi skener.
  • Administratorski interfejs koji možete da zaključate: Gateway upravlja pristupom akreditivima provajdera i pravilima koja svi koriste. Proverite da li možete da ograničite administratorski pristup odvojeno od saobraćaja aplikacija i da korisnici sa pravom samo za čitanje ne mogu da menjaju podešavanja. Glavnom ventilu je potrebna brava.

Koje alate možete da koristite za izgradnju LLM gateway-a?

Liste funkcija na tržištu se preklapaju. U jednoj niti na Redditu o internom pristupu modelima autor objave je pitao: koji gateway neće zahtevati posvećenog inženjera?

Po našem mišljenju, to je pravo pitanje i ima četiri odgovora, u zavisnosti od toga koliki deo posla ste spremni da preuzmete na sebe.

Napišite ga sami

Minimalni gateway obavlja kratak spisak zadataka: prihvata zahteve, proverava ključ pozivaoca, dodaje akreditiv provajdera, prosleđuje poziv i beleži rezultat. Ali podrška za različite formate provajdera donosi dodatni posao. Kao i održavanje celog sistema u radu.

Ako već koristite Envoy, njegov filter za spoljnu obradu omogućava vam da povežete servis koji pregleda i menja zahteve i odgovore. Taj servis i dalje morate sami da napravite i pokrećete.

U niti na r/LLMDevs o tome da li gateway smanjuje troškove, u/QuanTradin je naveo da im je evidentiranje tokena i oznake pogotka keša pri svakom pozivu pomoglo da pronađu dva zadatka za koje se plaćala puna cena za identične promptove.

„...ispravljanje toga vredelo je više nego što bi vredeo bilo koji sloj za rutiranje.“

To je iskustvo jednog korisnika, ali i dobra polazna tačka. Saznajte za šta plaćate pre nego što smislite složene načine za rutiranje.

Sami hostujte gateway otvorenog koda

LiteLLM je ovde čest izbor: kompatibilan je sa OpenAI API-jem, podržava širok spektar provajdera i ima veliku zajednicu. Bifrost je alternativa napravljena za male dodatne troškove po zahtevu. Helicone vredi pogledati ako vam je opservabilnost na vrhu liste željenih funkcija.

LiteLLM, kao i svaki proizvod, za neke timove ima ograničenja. U niti na r/aiagents o alternativama pravljenju sopstvenog rešenja, u/Own_Bar_920 je naveo da je LiteLLM dobro obavljao rutiranje, ali da im nije bio dovoljan za verzionisanje promptova u više timova i kontinuirane evaluacije pri zameni modela, zbog čega su prešli na zaseban alat.

Te potrebe prevazilaze osnovno rutiranje u gateway-u, i u tome je poenta: ako je rutiranje glavna potreba, LiteLLM se kod njih pokazao dobro.

Dobijate gotovu listu funkcija, pri čemu neke zavise od izdanja, a gateway ostaje unutar vaše mreže. Takođe ste odgovorni za zakrpe, što su ranije pomenuta otkrića kompanije Check Point učinila konkretnim, kao i za dostupnost gateway-a, što je pokazao odeljak o jedinstvenoj tački otkaza.

Ali u budžetu predvidite nekoga ko će biti odgovoran za njega. Jedna od briga u niti na r/LLMDevs o gateway-ima za interni pristup bilo je održavanje. u/Informal-Writer9685 je želeo nešto što „ne zahteva posvećenog inženjera za održavanje“ i pitao da li je prijavljena nestabilnost alata LiteLLM pri nadogradnjama stvaran problem pri njihovom obimu rada ili briga koja se tiče samo produkcije.

Koristite upravljani gateway

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter i hostovani gateway kompanije Portkey pokreću servis umesto vas. Za kompatibilnu aplikaciju, slanje prvog zahteva može da zahteva tek nešto više od promene URL-a i API ključa.

Kompromis je u tome što svaki prompt sada prolazi kroz treću stranu pre nego što stigne do provajdera. To je još jedan obrađivač podataka u vašoj dokumentaciji o usklađenosti, a prekid rada samog gateway-a je incident dobavljača: nije na vama da ga otklonite.

Na primer, 17. i 19. februara 2026. OpenRouter je imao prekide rada koji su trajali 38, odnosno 35 minuta, nakon što je otkazala jedna zavisnost za keširanje. Neki korisnici su dobijali greške „User not found“ i gubili vreme na otklanjanje grešaka sa potpuno ispravnim API ključevima. Kvar je bio u infrastrukturi gateway-a.

Ipak, treba odati priznanje kompaniji OpenRouter, koja je objavila detaljnu analizu incidenta i dodala zaštite kako otkaz keša ne bi preopteretio njenu bazu podataka. Upravljani gateway kao što je OpenRouter može da pojednostavi pristup, ali, kako u/QuanTradin ističe na r/LLMDevs, objedinjavanje računa ne smanjuje automatski potrošnju.

Proširite API gateway koji već imate

Ako se Kong, Apigee ili Azure API Management već nalazi ispred vaših servisa, svaki od njih ima mogućnosti specifične za AI: Kong AI Gateway, Apigee politike za AI gateway i AI gateway u okviru Azure API Management. Možete da se oslonite na postojeću autentifikaciju, mrežna pravila i operativne procedure i da dodate kontrole modela putem dodataka ili politika.

U velikoj kompaniji ovo može biti put najmanjeg organizacionog otpora. AI funkcije su mlađe od onih u samostalnim gateway-ima. Obavezno testirajte ograničavanje broja zahteva na osnovu tokena i strimovanje kroz kompletan skup dodataka ili politika koje planirate da koristite.

Zato svakako ugradite glavni ventil – svemoćni gejtvej. Ipak, inženjer iz uvoda je u pravu. Pristup modelima u kompaniji ne bi trebalo da zavisi od toga ko slučajno drži pravi ključ u fioci.

Gejtvej to rešava tako što te ključeve stavlja pod centralnu kontrolu, pa je utoliko rizičnije ostaviti fioku otvorenom. Morate znati čija je to fioka.

Česta pitanja o LLM gejtvejima

Da li je LLM gejtvej besplatan?

Ako mislite na kategoriju, neki LLM gejtveji imaju besplatne verzije.

LLM gejtveji obuhvataju sve od besplatnog softvera otvorenog koda do plaćenih paketa od oko 50 dolara mesečno, uz prilagođene cene za korporativne implementacije. Neki umesto toga naplaćuju procenat; na primer, OpenRouter u paketu Standard dodaje 5,5% na kupovinu kredita.

Koji je LLM gejtvej najbolji?

Koji deo posla ste spremni da preuzmete na sebe?

  • Ako želite sami da hostujete gejtvej i kontrolišete konfiguraciju, pogledajte Bifrost ili Helicone.
  • Upravljano rešenje, kao što su OpenRouter ili Vercel AI Gateway, odgovara timovima koji žele da uslugu umesto njih održava neko drugi.
  • Ako već koristite Kong ili Azure API Management, prvo proverite njihove AI mogućnosti.

Testirajte rešenja iz užeg izbora sopstvenim zahtevima, uključujući i to šta se dešava kada provajder otkaže.

Da li AWS ima LLM gejtvej?

Da. Amazon Bedrock AgentCore Gateway podržava pozive modela putem onoga što AWS naziva „inference targets“ (ciljevi za inferenciju). Oni omogućavaju aplikacijama da preko jedne krajnje tačke pristupe provajderima kao što su Amazon Bedrock, OpenAI i Anthropic, dok gejtvej upravlja akreditivima provajdera i rutiranjem.