Hogyan működik az LLM-átjáró? Gyakorlati útmutató mérnökcsapatoknak

Az LLM-átjáró az alkalmazásai és a rajta keresztül csatlakoztatott modellszolgáltatók között helyezkedik el, így egyetlen helyen kezelheti a hitelesítő adatokat, és követheti nyomon a használatot.

„Jelenleg az egész egy nagy sz*rakás” – írta 2026 szeptemberében egy mérnök a Reddit r/LLMDevs közösségében.

„Mindenkinek megvan a saját kulcskészlete a Claude-hoz, az OpenAI-hoz, az AWS Bedrockhoz és az összes többi általunk használt inferenciaszolgáltatóhoz.”

A BigGo az llm-proxy-tk-ról szóló cikkében – ez egy könnyű FastAPI-átjáró – azt írja, hogy ez a megoldás „vállalati csapvízzé” teszi az LLM-eket, az átjáró pedig az épület főelzáró szelepe.

Mielőtt azonban ennyire megbízna a vízvezeték-rendszerben, nézzük meg, mit is telepít.

Mi az az LLM-átjáró?

Az LLM-átjáró a modellhívások fordított proxyja. Az alkalmazásai neki küldik a kéréseket ahelyett, hogy közvetlenül az OpenAI-nak, az Anthropicnak, a Google-nek vagy bármely más használt LLM-szolgáltatónak küldenék. Az átjáró továbbítja ezeket a kéréseket, és közben alkalmazza az Ön szabályait.

Minden LLM-szolgáltatónak saját API-ja van, saját kérésformátummal, saját hitelesítéssel és a hibák visszaadásának saját módjával. Mindegyiknek külön sebességkorlátai és hibamódjai is vannak. Ha nincs előttük közös réteg, akkor minden alkalmazás, amely egy szolgáltatót hív, mindent maga old meg – és mindegyik kicsit másképp.

A csapvizes hasonlat csak egy darabig működik, de eddig mindenképp: a szolgáltatókat egyszer kell bekötni, az átjárónál. Ettől kezdve minden alkalmazás saját, mérőórás csatlakozást kap, így látható, ki mit használ, és bármelyik vezeték elzárható anélkül, hogy a többihez hozzá kellene nyúlni.

LLM-, AI-, MCP- és API-átjárók: mi a különbség?

Hogyan működik az LLM-átjáró?

Kövessünk végig egy kérést az alkalmazástól a modellig és vissza.

1. A kérés megérkezik az átjáróhoz: Az alkalmazás egy hétköznapinak tűnő csevegési kérést küld – gyakran OpenAI-kompatibilis formátumban – az átjáró végpontjára. Az alkalmazás szemszögéből ez az a cím, amelyet a modell eléréséhez hív.
2. Az átjáró ellenőrzi, ki kérdez, és mit tehet meg: A kérés továbbítása előtt érvényesíti a hitelesítő adatokat. Ez gyakran egy csapatnak vagy terméknek kiadott virtuális kulcs. Ha bemeneti védőkorlátokat is beállított, a promptokban érzékeny adatokat vagy a modell utasításainak felülírására irányuló kísérleteket is kereshet.
3. Az átjáró ellenőrzi, megvan-e már a válasz: Ha a gyorsítótárazás engedélyezve van, egy arra alkalmas, egyező kérésre mentett válasszal felelhet, újabb szolgáltatói hívás nélkül. Egyes átjárók szemantikus gyorsítótárazást is kínálnak, amely nem azonos, hanem kellően hasonlónak ítélt kéréseket keres. Ez a GYIK-jellegű forgalomhoz illhet.
4. Az átjáró eldönti, hová kerüljön a kérés: A kérés megnevezhet egy konkrét modellt vagy egy álnevet. Az átjáró kikeresi a konfigurációban a hozzá tartozó útvonalat. Tartalék útvonalat is beállíthat. Ha az A szolgáltatónál időtúllépés történik, az átjáró megpróbálkozhat a B szolgáltatóval.
5. Az átjáró előkészíti a hívást, és visszaküldi a választ: Az átjáró a kérést a kiválasztott szolgáltató formátumára alakítja, és hitelesíti a kimenő hívást. Amint megérkezik a válasz, átalakítja az alkalmazás által igényelt formátumra.
6. Az átjáró rögzíti, mi történt: Ha a naplózás engedélyezve van, az átjáró többek között azt rögzíti, ki indította a hívást, melyik modell szolgálta ki, valamint a tokenszámot, a késleltetést és a költséget. Ez az a napló, amely a bevezetőben idézett redditező mérnöknek hiányzott.

4 dolog, amit tudnia kell, mielőtt éles környezetbe helyez egy átjárót

A fenti szakaszban leírtak mind azért lehetségesek, mert az átjáró minden rajta keresztül irányított kérést lát. Ez a fő érv mellette. Ugyanakkor ez egyben annak a támadási felületnek és szállítói függőségnek a leírása is, amellyel számolnia kell.

Az átjáró lett az AI-rendszere legértékesebb eleme

Az átjáró központosítja a hozzáférést. Ezért egyben rengeteg hitelesítő adatot is egyetlen szolgáltatás kezébe ad. A Microsoft biztonsági csapata felsorolja, mit tárolhat vagy kérhet le egy LiteLLM-telepítés: szolgáltatói API-kulcsokat, a saját mesterkulcsát, virtuáliskulcs-rekordokat, adatbázis-kapcsolati karakterláncokat, útválasztási beállításokat és bérlői szabályzatokat.

2026 októberében a Check Point Research két magas kockázatú sebezhetőséget hozott nyilvánosságra a LiteLLM-ben:

• A CVE-2026-35029 lehetővé tette, hogy a hitelesített felhasználók – köztük a csak olvasási jogúak is – elérjék az adminisztratív funkciókat, és átvegyék az irányítást a példány felett.
• A CVE-2026-59823 lehetővé tette, hogy a felhasználók egy általuk irányított kiszolgálóra irányítsák át a kéréseket, és megszerezzék a szolgáltatói kulcsokat.

Mindkettőt az 1.83.9-es verzió javította. Az átjárót használó alkalmazás ne legyen képes módosítani az átjáró beállításait.

A védőkorlátokhoz hibakezelési szabályzat kell

A Pillar Security 2026. október 4-i áttekintése dokumentálja a harmadik féltől származó védőkorlát-integrációkat a főbb átjárókban, köztük a LiteLLM-ben, a Kongban, a TrueFoundryban, a Portkeyben, az Azure API Managementben és az Apigee-ben. (A Pillar maga is árul védőkorlátokat, ezt tartsa szem előtt az ajánlásai olvasásakor.)

A hook a kérés útvonalának egy pontja – jellemzően mielőtt a prompt a modellhez kerül, vagy miután a válasz visszaérkezik –, ahol az átjáró ítéletért átadhatja a tartalmat egy külső szkennernek. A blokkoló ellenőrzés megvárja ezt az ítéletet, mielőtt továbbengedi a forgalmat. A Portkey dokumentációja ezeket before_request_hooks és after_request_hooks néven említi; a TrueFoundry négyet futtat, és az MCP-eszközhívások előtti és utáni ellenőrzésekkel egészíti ki őket.

Két dolgot érdemes ellenőrizni:

• Mi történik, ha maga a szkenner hibásodik meg? Ha blokkolja a kérést, megállítja az ellenőrizetlen forgalmat, de megszakíthatja az alkalmazás működését. Ha átengedi, az alkalmazás az ellenőrzés nélkül folytathatja a működést. A hibanapló utólag megmutatja, hogy az ellenőrzés elmaradt – ez hasznos, de nem ugyanaz, mintha lefutott volna.
• Lecserélhető a szkenner? Ha egy másik szolgáltató nem támogatott, előfordulhat, hogy frissítenie kell az alkalmazását, vagy egy másik proxyn keresztül kell csatlakoznia.

A TrueFoundry MCP-hookjai a modellkérésekről az eszközhívásokra is kiterjesztik az átjáró hatókörét. Az átjáró azonban csak a rajta áthaladó forgalmat tudja megvizsgálni. Egy fejlesztő gépén parancsot futtató kódolási ügynök kívül eshet ezen a látókörön.

A Perplexity nyílt forráskódú Numbat eszköze ezen az oldalon működik. A Numbat helyi hookokon keresztül csatlakozik a támogatott ügynökökhöz, és még a végrehajtás előtt megvizsgálhatja a tervezett műveleteket, például a shellparancsokat vagy a fájlírásokat. A blokkolási funkció opcionális, és alapértelmezés szerint ki van kapcsolva. Az átjáró a rajta keresztül irányított modellforgalmat látja. A Numbat pedig betekintést nyújt abba, mit kezd az ügynök a válasszal.

Tudnia kell, hol ér véget az átjáró hatásköre

A Forkast News azonosít három fejlődési vonalat, amelyek különböző irányokból közelítenek az átjáróhoz:

• LLM-központú átjárók: A LiteLLM és a Portkey a modellhívásokkal indult: a szolgáltatók közötti fordítással, a kérések útválasztásával és a tokenek nyomon követésével. Most már az eszközhívásokhoz is kínálnak vezérlési lehetőségeket.
• API-kezelési platformok: A Kong, a Google-féle Apigee és az Azure API Management a hitelesítéssel, a jogosultságokkal és a forgalomkezeléssel kezdte, majd a modellek és az AI-specifikus szabályok támogatásával bővült.
• Ügynökközpontú infrastruktúra: Az agentgateway például eleve arra épült, hogy ügynökök kommunikáljanak modellekkel, eszközökkel és más ügynökökkel, többek között MCP-n és A2A-n keresztül.

A döntő kérdés az, hogy mit irányít át rajta:

• Csak modellhívásokat? Egy LLM-központú átjáró jó kiindulópont.
• Modellhívásokat egy olyan vállalaton belül, ahol már rengeteg API-szabály van érvényben? Kezdje a meglévő platformjával.
• Ügynököket, amelyek eszközöket hívnak, amelyek pedig modelleket? Ellenőrizze, hogy ezekre a kapcsolatokra is kiterjed-e a lefedettség.

Közös meghibásodási pontot hoz létre

Tegyük fel, hogy az ügyfélszolgálati chatbotja az OpenAI-t, a kutatási eszköze pedig az Anthropicot használja – és mindkettő ugyanazon az átjárón keresztül csatlakozik. Ha ez az átjáró leáll, mindkét eszköz elveszíti a hozzáférést a modelljeihez, még akkor is, ha az OpenAI és az Anthropic rendben működik.

Ez valóban megtörtént már. A Cloudflare AI Gateway hibaaránya 97%-on tetőzött a 2025. június 12-i leállás során. Az átjáró a beállításaihoz a Cloudflare Workers KV tárolószolgáltatására támaszkodott, és ez a szolgáltatás hibásan működött.

Ha saját maga üzemelteti az átjárót, tartson futásban egy másik példányt is, amely átveheti a szerepét, ha az egyik meghibásodik. Ha más üzemelteti az átjáróját, kérdezze meg, hogyan tartják működésben hibák esetén, és mi történik a kéréseivel a helyreállítás alatt.

Az LLM-átjárók legfontosabb funkciói, amelyekre érdemes figyelni

Az átjárónak mindenki hitelesítő adataihoz hozzáférést fog adni, ezért cserébe joggal lehet igényes azzal szemben, amit nyújt.

• Egyetlen API több szolgáltató előtt: A kódja egyetlen formátumot használ – gyakran OpenAI-kompatibiliset –, a fordítást pedig az átjáró végzi. Az LLM-szolgáltatók is tesznek egy lépést ebbe az irányba. A Perplexity Agent API szolgáltatása például támogatja az OpenAI Responses API-felületét, így a csapatok újrahasznosíthatják a meglévő OpenAI-klienskönyvtáraikat.
• Szabályokhoz kötött virtuális kulcsok: Minden csapat vagy termék saját kulcsot kap, amelyhez szabályok határozzák meg az engedélyezett modelleket, a kéréskorlátokat és a költési keretet.
• Útválasztás és tartalék: Az átjáró a beállításai alapján továbbítja a kéréseket a modellekhez; ezek a beállítások előnyben részesíthetik a költséget, a sebességet vagy egy adott szolgáltatót. Ha egy hívás sikertelen, megpróbálkozhat egy másikkal. A Perplexity Agent API-jában akár öt modellt is megadhat – különböző szolgáltatóktól is – a kívánt sorrendben.
• Gyorsítótárazás: Egy mentett válasz megspórolhat egy újabb szolgáltatói hívást. Egyes átjárók az azonos kéréseket párosítják, mások a hasonló jelentésű kéréseket is. Ellenőrizze, hogy a gyorsítótárazott válaszok elkülöníthetők-e felhasználónként vagy csapatonként, és hogy kikapcsolható-e a gyorsítótárazás a személyre szabott vagy időérzékeny válaszoknál.
• Streamelés és egységes hibakezelés: A válaszok generálás közben érkeznek, a szolgáltatói hibák pedig olyan formátumra alakulnak, amelyet az alkalmazása kezelni tud. Ellenőrizze, mi történik, ha AI-védőkorlátokat ad hozzá.
• Naplózás és költségek hozzárendelése: Az átjáró rögzíti, ki indította a hívást, melyik modell szolgálta ki, hány tokent használt, mennyi ideig tartott, és mennyi a becsült költsége. Ellenőrizze, hogy a naplók tartalmazzák-e a promptokat és a válaszokat, és mennyi ideig őrzik meg őket.
• Védőkorlát-hookok: Ezek a kérés útvonalának azon pontjai, ahol az átjáró ítéletért elküldheti a tartalmat egy külső szkennernek. Általában a modellkérés előtt vagy a válasz után helyezkednek el. Ellenőrizze, hogy a kérések leállnak vagy folytatódnak-e, ha a szkenner meghibásodik, és hogy csatlakoztatható-e másik szkenner.
• Lezárható adminisztrációs felület: Az átjáró kezeli a szolgáltatói hitelesítő adatokhoz való hozzáférést és a mindenki által használt szabályokat. Ellenőrizze, hogy az adminisztrátori hozzáférés az alkalmazásforgalomtól külön korlátozható-e, és hogy a csak olvasási jogú felhasználók valóban nem tudják-e módosítani a beállításokat. A főelzáró szelepre lakat kell.

Milyen eszközökkel építheti fel az LLM-átjáróját?

A funkciólisták az egész piacon átfedik egymást. Egy belső modellhozzáférésről szóló Reddit-szálban a szál indítója azt kérdezte: melyik átjáróhoz nem kell külön mérnök?

Véleményünk szerint ez a helyes kérdés, és négy válasz létezik rá attól függően, hogy a munka mekkora részét hajlandó magára vállalni.

Írja meg saját maga

Egy minimális átjáró csak néhány feladatot lát el: fogadja a kéréseket, ellenőrzi a hívó kulcsát, hozzáadja a szolgáltatói hitelesítő adatot, továbbítja a hívást, és naplózza az eredményt. A különböző szolgáltatói formátumok támogatása azonban többletmunkát jelent. Ahogy az egész rendszer működésben tartása is.

Ha már Envoyt futtat, annak külső feldolgozási szűrőjével olyan szolgáltatást csatlakoztathat, amely megvizsgálja és módosítja a kéréseket és a válaszokat. Ezt a szolgáltatást azonban továbbra is Önnek kell megépítenie és üzemeltetnie.

Egy r/LLMDevs-szálban, amely arról szólt, hogy csökkenti-e a költségeket egy átjáró, u/QuanTradin azt írta, hogy a tokenek és egy gyorsítótár-találati jelző naplózása minden hívásnál segített nekik megtalálni két olyan feladatot, amelyek azonos promptokért fizettek teljes árat.

„...ennek a kijavítása többet ért, mint amennyit bármilyen útválasztási réteg ért volna.”

Ez egy egyéni tapasztalat, de jó kiindulópont. Derítse ki, mire költ, mielőtt bonyolult útválasztási megoldásokat építene.

Üzemeltessen saját maga egy nyílt forráskódú átjárót

A LiteLLM gyakori választás: OpenAI-kompatibilis, a szolgáltatók széles körét támogatja, és nagy közösség áll mögötte. A Bifrost egy alternatíva, amelyet úgy terveztek, hogy kérésenként minimális többletterhelést okozzon. Ha a megfigyelhetőség áll a funkciólistája élén, érdemes megnézni a Helicone megoldást.

A LiteLLM-nek, mint minden terméknek, vannak korlátai egyes csapatok számára. Egy r/aiagents-szálban, amely a saját fejlesztés alternatíváiról szólt, u/Own_Bar_920 azt írta, hogy a LiteLLM jól kezelte az útválasztást, de a csapatok közötti promptverzió-kezelésben és a modellcserénél végzett folyamatos kiértékelésekben elmaradt az igényeiktől, ezért egy különálló eszközre váltottak.

Ezek túlmutatnak az átjáró alapszintű útválasztásán, és éppen ez a lényeg: ha az útválasztás a fő igény, a LiteLLM megállta a helyét náluk.

Kész funkciólistát kap – egyes funkciók a kiadástól függenek –, és az átjáró a hálózatán belül marad. A javítások telepítése azonban az Ön felelőssége, ahogy azt a korábban említett Check Point-közzétételek kézzelfoghatóvá tették, és az átjáró rendelkezésre állása is, ahogy azt a közös meghibásodási pontról szóló szakasz megmutatta.

Számoljon azonban azzal, hogy kell valaki, aki felel érte. Egy belső hozzáférésre szolgáló átjárókról szóló r/LLMDevs-szálban az egyik aggály a karbantartás volt. u/Informal-Writer9685 olyan megoldást keresett, amely „nem igényel külön mérnököt a karbantartásához”, és megkérdezte, hogy a LiteLLM frissítéseinek állítólagos instabilitása valódi probléma-e az ő méretükben, vagy csak éles környezetben jelentkező gond.

Használjon felügyelt átjárót

A Cloudflare AI Gateway, a Vercel AI Gateway, az OpenRouter és a Portkey hosztolt átjárója Ön helyett üzemelteti a szolgáltatást. Egy kompatibilis alkalmazásnál az első kérés átjuttatásához alig kell több egy URL-módosításnál és egy API-kulcsnál.

A kompromisszum itt az, hogy minden prompt egy harmadik félen halad át, mielőtt a szolgáltatóhoz érne. Ez eggyel több adatfeldolgozó a megfelelőségi dokumentációjában, az átjáró saját leállása pedig a szállító incidense – nem Önnek kell elhárítania.

Például 2026. február 17-én és 19-én az OpenRouternél 38, illetve 35 percig tartó leállások történtek, miután meghibásodott egy gyorsítótárazási függőség. Egyes ügyfelek „User not found” („A felhasználó nem található”) hibákat kaptak, és időt töltöttek tökéletesen érvényes API-kulcsok hibakeresésével. A hiba az átjáró infrastruktúrájában volt.

Az OpenRouter javára legyen mondva, részletes utólagos elemzést tett közzé, és védelmi intézkedéseket vezetett be, hogy egy gyorsítótár-hiba ne terhelhesse túl az adatbázisát. Egy olyan felügyelt átjáró, mint az OpenRouter, egyszerűsítheti a hozzáférést, de ahogy u/QuanTradin rámutat az r/LLMDevs-en, a számlák összevonása nem csökkenti automatikusan a kiadásokat.

Bővítse a meglévő API-átjáróját

Ha már a Kong, az Apigee vagy az Azure API Management áll a szolgáltatásai előtt, mindegyik kínál AI-specifikus képességeket: a Kong AI Gateway, az Apigee AI-átjáró-szabályzatai és az Azure API Management AI-átjárója. Építhet a már meglévő hitelesítésre, hálózati szabályokra és üzemeltetési eljárásokra, a modellvezérlőket pedig bővítményekkel vagy szabályzatokkal adhatja hozzá.

Egy nagyvállalatnál ez lehet a legkisebb szervezeti ellenállással járó út. Ezek az AI-funkciók újabbak, mint az önálló átjárók megfelelő funkciói. Mindenképp tesztelje a tokenalapú sebességkorlátozást és a streamelést a használni kívánt bővítmények vagy szabályzatok teljes készletén keresztül.

Tehát mindenképp építsd be a főszelepet, vagyis a mindenható átjárót. A bevezetőben említett mérnöknek azonban részben igaza van: egy vállalat modellhozzáférése nem függhet attól, hogy éppen kinek a fiókjában lapul a megfelelő kulcs.

Az átjáró ezt úgy oldja meg, hogy ezeket a kulcsokat központi felügyelet alá vonja – ami viszont jócskán megemeli a tétet, ha nyitva marad a fiók. Tudnod kell, kié az a fiók.

GYIK az LLM-átjárókról

Ingyenes az LLM-átjáró?

Ha magára a kategóriára gondolsz, egyes LLM-átjáróknak van ingyenes verziója.

Az LLM-átjárók kínálata az ingyenes, nyílt forráskódú szoftverektől a nagyjából havi 50 dollártól induló fizetős csomagokig terjed, vállalati telepítésekhez pedig egyedi árazás érhető el. Egyes szolgáltatók ehelyett százalékos díjat számítanak fel: az OpenRouter Standard csomagja például 5,5%-kal növeli a kreditvásárlások összegét.

Melyik a legjobb LLM-átjáró?

Milyen munkát vagy hajlandó magadra vállalni?

• Ha saját magad szeretnéd üzemeltetni a megoldást, és te akarod kézben tartani a konfigurációt, nézd meg a Bifrostot vagy a Helicone-t.
• Az OpenRouterhez vagy a Vercel AI Gateway-hez hasonló felügyelt megoldás azoknak a csapatoknak való, amelyek inkább másra bíznák a szolgáltatás üzemeltetését.
• Ha már a Kongot vagy az Azure API Managementet használod, először azok AI-képességeit nézd meg.

A szűkített listán szereplő megoldásokat a saját kéréseiddel teszteld, és azt is vizsgáld meg, mi történik, ha egy szolgáltató kiesik.

Van az AWS-nek LLM-átjárója?

Igen. Az Amazon Bedrock AgentCore Gateway támogatja a modellhívásokat az AWS által „inference targets” (következtetési célok) néven emlegetett funkción keresztül. Ezekkel az alkalmazások egyetlen végponton át érhetnek el különböző szolgáltatókat, köztük az Amazon Bedrockot, az OpenAI-t és az Anthropicot, a szolgáltatói hitelesítő adatokat és az útválasztást pedig az átjáró kezeli.