Kako funkcionira LLM pristupnik? Praktični vodič za inženjerske timove
LLM pristupnik obrnuti je proxy koji usmjerava, autentificira, sprema u predmemoriju i bilježi vaše pozive modela; ovaj vodič prati zahtjev kroz jedan takav pristupnik, obrađuje sigurnosne rizike i rizike pouzdanosti koje treba predvidjeti te uspoređuje izradu vlastitog pristupnika, samostalno hostanje, upravljane usluge i API pristupnike.

LLM pristupnik (engl. LLM gateway) nalazi se između vaših aplikacija i pružatelja modela s kojima se preko njega povezujete te vam pruža jedno mjesto za upravljanje vjerodajnicama i praćenje korištenja.
„Trenutačno je to potpuno s****e“, jedan je inženjer napisao na Redditu u r/LLMDevs u rujnu 2026.
„Svatko ima svoj komplet ključeva za Claude, OpenAI, AWS Bedrock i sve ostale pružatelje inferencije koje koristimo.“
Članak portala BigGo o alatu llm-proxy-tk, laganom FastAPI pristupniku, uspoređuje takvo rješenje s pretvaranjem LLM-ova u „korporativnu vodu iz slavine“, pri čemu je pristupnik glavni ventil zgrade.
No prije nego što toliko povjerenja ukažete vodovodu, pogledajmo što zapravo ugrađujete.
Što je LLM pristupnik?
LLM pristupnik je obrnuti proxy (reverse proxy) za pozive modelima. Vaše aplikacije šalju zahtjeve njemu umjesto izravno OpenAI-ju, Anthropicu, Googleu ili bilo kojem drugom pružatelju LLM-ova kojim se služite. Pristupnik prosljeđuje te zahtjeve i usput primjenjuje vaša pravila.
Svaki pružatelj LLM-ova ima svoj API: s vlastitim oblikom zahtjeva, vlastitom autentifikacijom i vlastitim načinom vraćanja pogrešaka. Svaki ima i zasebna ograničenja učestalosti zahtjeva i vlastite obrasce kvarova. Ako ispred njih nema zajedničkog sloja, svaka aplikacija koja poziva nekog pružatelja sve radi sama – i svaka to radi malo drukčije.
Usporedba s vodom iz slavine ima svoje granice, ali dovodi vas barem dovde: pružatelji se priključuju samo jednom, na pristupniku. Od tada svaka aplikacija dobiva vlastiti priključak s brojilom, pa vidite tko što troši i možete zatvoriti bilo koji pojedinačni vod, a da ne dirate ostale.
LLM, AI, MCP i API pristupnici: u čemu je razlika?
Pristupnik | Ispred čega se nalazi? | O čemu odlučuje? | Granice njegova uvida |
API pristupnik | Vaše usluge i ostali pozadinski API-ji | Je li ovaj klijent autentificiran i je li unutar svog ograničenja učestalosti zahtjeva? | Može pregledavati tijela zahtjeva, ali za obračun tokena i druge kontrole specifične za modele potrebna je dodatna podrška. |
LLM pristupnik | Pružatelji modela | Koji model dobiva ovaj zahtjev, tko ga plaća i je li se odgovor vratio? | Vidi pozive alata predložene u odgovorima modela, ali ne i njihovo izvršavanje, osim ako i taj promet ne prolazi kroz njega. |
MCP pristupnik | Alati i izvori podataka s kojima se agent povezuje putem MCP-a | Smije li ovaj agent pozvati ovaj alat s ovim argumentima? | Ne vidi automatski poziv modelu iz kojeg je proizašao zahtjev za alatom. |
Sve što je dobavljač uključio u paket: modeli, a možda i alati te promet između agenata | Kombinacija navedenog, ovisno o proizvodu | Ovisi o tome koje veze obrađuje. |
Kako radi LLM pristupnik?
Pratimo jedan zahtjev od vaše aplikacije do modela i natrag.
- Zahtjev stiže na pristupnik: Vaša aplikacija šalje naizgled običan chat zahtjev, često u formatu kompatibilnom s OpenAI-jem, na krajnju točku pristupnika. Sa stajališta aplikacije, to je adresa koju poziva kako bi došla do modela.
- Pristupnik provjerava tko šalje zahtjev i što smije raditi: Prije prosljeđivanja zahtjeva provjerava vjerodajnice. To je često virtualni ključ izdan timu ili proizvodu. Ako ste uključili ulazne zaštitne mehanizme (guardrails), upiti se mogu i skenirati u potrazi za osjetljivim podacima ili pokušajima zaobilaženja uputa modela.
- Pristupnik provjerava ima li već odgovor: Ako je predmemoriranje uključeno, na prikladan podudarni zahtjev može se odgovoriti spremljenim odgovorom bez novog poziva pružatelju. Neki pristupnici nude i semantičko predmemoriranje, koje traži zahtjeve procijenjene kao dovoljno slične, a ne identične. To može odgovarati prometu nalik čestim pitanjima (FAQ).
- Pristupnik odabire kamo zahtjev ide: Zahtjev može navesti određeni model ili zamjenski naziv (alias). Pristupnik u vašoj konfiguraciji traži odgovarajuću rutu. Možete konfigurirati i pričuvnu rutu. Ako pružatelj A ne odgovori na vrijeme, pristupnik može pokušati s pružateljem B.
- Pristupnik priprema poziv i vraća odgovor: Pristupnik pretvara vaš zahtjev u format odabranog pružatelja i autentificira odlazni poziv. Čim primi odgovor, pretvara ga u format koji vaša aplikacija zahtijeva.
- Pristupnik bilježi što se dogodilo: Kad je zapisivanje uključeno, pristupnik bilježi pojedinosti kao što su tko je uputio poziv, koji ga je model obradio, broj tokena, latencija i trošak. Upravo takav zapisnik nije imao inženjer s Reddita iz uvoda.
4 stvari koje morate znati prije nego što pristupnik pustite u produkciju
Sve opisano u prethodnom odjeljku moguće je zato što pristupnik vidi svaki zahtjev koji prolazi kroz njega. To je glavni prodajni argument. No to je ujedno i opis površine napada i ovisnosti o dobavljaču koje morate uzeti u obzir pri planiranju.
Pristupnik je sada najvrjedniji dio vaše AI infrastrukture
Pristupnik objedinjuje pristup na jednom mjestu. Zbog toga i mnoštvo vjerodajnica stavlja nadohvat jedne usluge. Microsoftov sigurnosni tim navodi što sve implementacija LiteLLM-a može sadržavati ili dohvaćati: API ključeve pružatelja, vlastiti glavni ključ, zapise virtualnih ključeva, nizove za povezivanje s bazom podataka, postavke usmjeravanja i pravila za zakupce (tenante).
U listopadu 2026. Check Point Research objavio je dvije visokorizične ranjivosti u LiteLLM-u:
- CVE-2026-35029 omogućivala je autentificiranim korisnicima, uključujući one samo s pravom čitanja, pristup administrativnim funkcijama i preuzimanje instance.
- CVE-2026-59823 omogućivala je korisnicima preusmjeravanje zahtjeva na poslužitelj pod vlastitom kontrolom i presretanje ključeva pružatelja.
Obje su ispravljene u verziji 1.83.9. Aplikacija koja koristi pristupnik ne bi smjela moći mijenjati njegove postavke.
Vašim zaštitnim mehanizmima potrebno je pravilo za slučaj kvara
Pregled tvrtke Pillar Security od 4. listopada 2026. dokumentira integracije zaštitnih mehanizama trećih strana u vodećim pristupnicima, uključujući LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management i Apigee. (Pillar prodaje zaštitne mehanizme, pa to imajte na umu dok čitate njegove preporuke.)
Hook (kuka) je točka na putu zahtjeva, obično prije nego što upit ode modelu ili nakon što se odgovor vrati, u kojoj pristupnik može predati sadržaj vanjskom skeneru na procjenu. Blokirajuća provjera čeka tu procjenu prije nego što propusti promet dalje. Dokumentacija za Portkey naziva ih before_request_hooks i after_request_hooks; TrueFoundry ih pokreće četiri, dodajući provjere prije i nakon poziva MCP alata.
Dvije stvari koje treba provjeriti:
- Što se događa ako sam skener zakaže? Ako blokirate zahtjev, zaustavljate neprovjereni promet, ali možete prekinuti rad aplikacije. Ako ga propustite, aplikacija može nastaviti raditi bez te provjere. Zapisnik pogrešaka naknadno će vam pokazati da provjera nije provedena, što je korisno, ali nije isto kao da je provedena.
- Možete li zamijeniti skener? Ako drugi pružatelj nije podržan, možda ćete morati ažurirati aplikaciju ili se povezati preko drugog proxyja.
MCP hookovi platforme TrueFoundry proširuju doseg pristupnika sa zahtjeva modelima na pozive alata. No pristupnik može pregledavati samo promet koji prolazi kroz njega. Agent za programiranje koji pokreće naredbu na računalu razvojnog inženjera može biti izvan tog vidokruga.
Alat otvorenog koda Numbat tvrtke Perplexity djeluje upravo na toj strani. Numbat se povezuje s podržanim agentima putem lokalnih hookova i može pregledati planirane radnje, poput naredbi u ljusci ili zapisivanja datoteka, prije nego što se izvrše. Značajka blokiranja nije obavezna i zadano je isključena. Pristupnik vidi promet modela koji se usmjerava kroz njega. Numbat dodaje uvid u ono što agent radi s odgovorom.
Morate znati gdje prestaje kontrola pristupnika
Forkast News izdvaja tri razvojne linije koje pristupniku prilaze iz različitih smjerova:
- Pristupnici usmjereni na LLM-ove: LiteLLM i Portkey počeli su s pozivima modelima – prevođenjem između pružatelja, usmjeravanjem zahtjeva i praćenjem tokena. Sada dodaju kontrole za pozive alata.
- Platforme za upravljanje API-jima: Kong, Googleov Apigee i Azure API Management počeli su s autentifikacijom, dopuštenjima i upravljanjem prometom, a zatim su dodali podršku za modele i pravila specifična za AI.
- Infrastruktura izvorno namijenjena agentima: agentgateway je, primjerice, izgrađen oko agenata koji komuniciraju s modelima, alatima i drugim agentima, među ostalim i putem MCP-a i A2A-a.
Ključno pitanje za odabir jest što usmjeravate:
- Samo pozive modelima? Pristupnik prvenstveno namijenjen LLM-ovima dobra je polazna točka.
- Pozive modelima unutar velike tvrtke koja već obiluje API pravilima? Krenite od platforme koju već imate.
- Agente koji pozivaju alate koji pozivaju modele? Provjerite jesu li pokrivene i te veze.
Uvodite zajedničku točku kvara
Recimo da vaš chatbot za podršku koristi OpenAI, a vaš alat za istraživanje Anthropic – i oba se povezuju preko istog pristupnika. Ako taj pristupnik prestane raditi, oba alata gube pristup svojim modelima, čak i ako OpenAI i Anthropic rade normalno.
To se zaista dogodilo. Stopa pogrešaka Cloudflareove usluge AI Gateway dosegnula je vrhunac od 97 % tijekom ispada 12. lipnja 2025. Pristupnik se za postavke oslanjao na Cloudflareovu uslugu pohrane Workers KV, a ta je usluga zakazivala.
Ako pristupnik pokrećete sami, održavajte i drugu pokrenutu instancu koja može preuzeti rad ako jedna zakaže. Ako vaš pristupnik hostira netko drugi, pitajte kako osigurava njegov rad tijekom kvarova i što se događa s vašim zahtjevima tijekom oporavka.
Ključne značajke na koje treba obratiti pozornost kod LLM pristupnika
Pristupniku ćete dati pristup svačijim vjerodajnicama, pa budite zahtjevni u pogledu onoga što vam zauzvrat nudi.
- Jedan API ispred više pružatelja: Vaš kôd koristi jedan format, često kompatibilan s OpenAI-jem, a pristupnik prevodi. Pružatelji LLM-ova izlaze mu ususret. Primjerice, Agent API tvrtke Perplexity podržava OpenAI-jevo sučelje Responses API, pa timovi mogu ponovno koristiti postojeće OpenAI klijentske biblioteke.
- Virtualni ključevi s pridruženim pravilima: Svaki tim ili proizvod dobiva vlastiti ključ s pravilima koja određuju dopuštene modele, ograničenja zahtjeva i potrošnju.
- Usmjeravanje i pričuvne opcije: Pristupnik šalje zahtjeve modelima na temelju vaših postavki, koje mogu davati prednost cijeni, brzini ili određenom pružatelju. Ako poziv ne uspije, može pokušati s drugim. Agent API tvrtke Perplexity omogućuje vam da navedete do pet modela, uključujući modele različitih pružatelja, redoslijedom koji vam odgovara.
- Predmemoriranje: Spremljeni odgovor može vam uštedjeti još jedan poziv pružatelju. Neki pristupnici prepoznaju identične zahtjeve, a drugi mogu prepoznati i zahtjeve sličnog značenja. Provjerite mogu li se predmemorirani odgovori odvojiti po korisniku ili timu te možete li isključiti predmemoriranje za personalizirane odgovore ili one osjetljive na vrijeme.
- Strujanje odgovora i dosljedne pogreške: Odgovori stižu dok se generiraju, a pogreške pružatelja prevode se u format s kojim vaša aplikacija može raditi. Provjerite što se događa kada dodate AI zaštitne mehanizme.
- Zapisivanje i raspodjela troškova: Pristupnik bilježi tko je uputio poziv, koji ga je model obradio, koliko je tokena potrošeno, koliko je poziv trajao i koliki je njegov procijenjeni trošak. Provjerite sadrže li zapisnici upite i odgovore te koliko se dugo čuvaju.
- Hookovi za zaštitne mehanizme: To su točke na putu zahtjeva u kojima pristupnik može poslati sadržaj vanjskom skeneru na procjenu. Obično se nalaze prije zahtjeva modelu ili nakon njegova odgovora. Provjerite zaustavljaju li se zahtjevi ili nastavljaju kad skener zakaže te možete li povezati drugi skener.
- Administratorsko sučelje koje možete zaključati: Pristupnik upravlja pristupom vjerodajnicama pružatelja i pravilima koja svi koriste. Provjerite možete li ograničiti administratorski pristup odvojeno od prometa aplikacija te jesu li korisnicima samo s pravom čitanja onemogućene promjene postavki. Glavnom ventilu treba lokot.
Koje alate možete upotrijebiti za izgradnju svog LLM pristupnika?
Popisi značajki na tržištu se preklapaju. U jednoj niti na Redditu o internom pristupu modelima autor objave pitao je: koji pristupnik neće zahtijevati inženjera koji će se baviti samo njime?
Po našem mišljenju, to je pravo pitanje, a na njega postoje četiri odgovora, ovisno o tome koliko ste posla spremni preuzeti na sebe.
Napišite ga sami
Minimalni pristupnik obavlja kratak popis zadataka: prima zahtjeve, provjerava ključ pozivatelja, dodaje vjerodajnicu pružatelja, prosljeđuje poziv i bilježi rezultat. No podrška za različite formate pružatelja donosi dodatan posao. Kao i održavanje cijelog sustava u radu.
Ako već koristite Envoy, njegov filtar za vanjsku obradu omogućuje vam povezivanje usluge koja pregledava i mijenja zahtjeve i odgovore. Tu uslugu i dalje morate sami izgraditi i pokretati.
U niti na r/LLMDevs o tome smanjuje li pristupnik troškove u/QuanTradin rekao je da mu je bilježenje tokena i oznake pogotka u predmemoriji pri svakom pozivu pomoglo pronaći dva zadatka koja su plaćala punu cijenu za identične upite.
„...ispravljanje toga vrijedilo je više nego što bi vrijedio bilo kakav sloj za usmjeravanje.“
To je iskustvo koje je netko podijelio, ali i dobro polazište. Saznajte za što plaćate prije nego što izgradite složene načine usmjeravanja.
Sami hostirajte pristupnik otvorenog koda
LiteLLM je ovdje čest izbor: kompatibilan je s OpenAI-jem, podržava širok raspon pružatelja i ima veliku zajednicu. Bifrost je alternativa izgrađena za nisko opterećenje po zahtjevu. Helicone vrijedi pogledati ako vam je opažljivost (observability) na vrhu popisa željenih značajki.
LiteLLM, kao i svaki proizvod, za neke timove ima ograničenja. U niti na r/aiagents o alternativama izradi vlastitog rješenja u/Own_Bar_920 rekao je da je LiteLLM dobro obavljao usmjeravanje, ali da im nije bio dovoljan za verzioniranje upita među timovima i kontinuirane evaluacije pri zamjeni modela, zbog čega su prešli na zaseban alat.
To nadilazi osnovno usmjeravanje putem pristupnika, i upravo je u tome poanta: ako je usmjeravanje glavna potreba, LiteLLM se kod njih pokazao dobrim.
Dobivate gotov skup značajki, od kojih neke ovise o izdanju, a pristupnik ostaje unutar vaše mreže. No na vama je i krpanje sigurnosnih propusta, što su ranije opisana otkrića tvrtke Check Point jasno pokazala, kao i dostupnost pristupnika, što je pokazao odjeljak o jedinstvenoj točki kvara.
No predvidite resurse za nekoga tko će biti odgovoran za njega. Jedna od briga u niti na r/LLMDevs o pristupnicima za interni pristup bilo je održavanje. u/Informal-Writer9685 želio je nešto što „ne zahtijeva zasebnog inženjera za održavanje“ i pitao je je li prijavljena nestabilnost LiteLLM-a pri nadogradnjama stvaran problem u njihovim razmjerima ili problem koji se javlja samo u produkciji.
Koristite upravljani pristupnik
Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter i hostirani pristupnik tvrtke Portkey pokreću uslugu umjesto vas. Za kompatibilnu aplikaciju prvi uspješan zahtjev možda neće tražiti mnogo više od promjene URL-a i API ključa.
Kompromis je u tome što svaki upit sada prolazi kroz treću stranu prije nego što stigne do pružatelja. To je još jedan izvršitelj obrade podataka u vašoj dokumentaciji o usklađenosti, a ispad samog pristupnika incident je dobavljača – nije na vama da ga riješite.
Primjerice, 17. i 19. veljače 2026. OpenRouter je imao ispade u trajanju od 38, odnosno 35 minuta, nakon što je zakazala ovisnost za predmemoriranje. Neki su korisnici dobivali pogreške „User not found“ i trošili vrijeme na otklanjanje problema s potpuno valjanim API ključevima. Kvar je bio u infrastrukturi pristupnika.
No treba odati priznanje OpenRouteru: objavio je detaljnu analizu incidenta i dodao zaštitne mjere kako kvar predmemorije ne bi preopteretio njegovu bazu podataka. Upravljani pristupnik poput OpenRoutera može pojednostaviti pristup, ali, kako ističe u/QuanTradin na r/LLMDevs, objedinjavanje računa ne smanjuje automatski potrošnju.
Proširite API pristupnik koji već imate
Ako se ispred vaših usluga već nalazi Kong, Apigee ili Azure API Management, svaki od njih ima mogućnosti specifične za AI: Kong AI Gateway, pravila AI pristupnika platforme Apigee i AI pristupnik usluge Azure API Management. Možete se nadovezati na postojeću autentifikaciju, mrežna pravila i operativne postupke te dodati kontrole za modele putem dodataka ili pravila.
U velikoj tvrtki to može biti put najmanjeg organizacijskog otpora. AI značajke ovdje su mlađe od onih u samostalnim pristupnicima. Obavezno testirajte ograničavanje učestalosti zahtjeva na temelju tokena i strujanje kroz cijeli skup dodataka ili pravila koje namjeravate koristiti.
Stoga svakako ugradite glavni ventil – svemogući pristupnik. Ipak, inženjer iz uvoda ima pravo. Pristup tvrtke modelima ne bi smio ovisiti o tome tko slučajno u ladici drži pravi ključ.
Pristupnik to rješava stavljanjem tih ključeva pod središnju kontrolu, zbog čega je ostavljanje otvorene ladice još rizičnije. Morate znati čija je to ladica.
Česta pitanja o LLM pristupnicima
Je li LLM pristupnik besplatan?
Ako mislite na kategoriju u cjelini, neki LLM pristupnici imaju besplatne verzije.
LLM pristupnici kreću se od besplatnog softvera otvorenog koda do plaćenih paketa koji počinju od približno 50 USD mjesečno, uz prilagođene cijene za implementacije u velikim poduzećima. Neki umjesto toga naplaćuju postotak; primjerice, paket Standard tvrtke OpenRouter dodaje 5,5 % na kupnju kredita.
Koji je LLM pristupnik najbolji?
Za koji ste posao spremni preuzeti odgovornost?
- Ako ga želite pokretati na vlastitoj infrastrukturi i sami upravljati konfiguracijom, pogledajte Bifrost ili Helicone.
- Upravljano rješenje kao što su OpenRouter ili Vercel AI Gateway odgovara timovima koji žele da uslugu umjesto njih održava netko drugi.
- Ako već upotrebljavate Kong ili Azure API Management, najprije provjerite njihove AI mogućnosti.
Uži izbor testirajte vlastitim zahtjevima i provjerite i što se događa kada pružatelj usluga zakaže.
Ima li AWS LLM pristupnik?
Da. Amazon Bedrock AgentCore Gateway podržava pozive modela putem onoga što AWS naziva „ciljevima zaključivanja“ (engl. inference targets). Oni aplikacijama omogućuju da putem jedne krajnje točke pristupe pružateljima kao što su Amazon Bedrock, OpenAI i Anthropic, dok pristupnik upravlja vjerodajnicama pružatelja i usmjeravanjem.