Jak funguje LLM brána? Praktický průvodce pro inženýrské týmy

Brána LLM stojí mezi vašimi aplikacemi a poskytovateli modelů, které přes ni připojujete, a dává vám jedno místo pro správu přihlašovacích údajů a sledování využití.

„Momentálně je to totální bordel,“ napsal na Redditu v r/LLMDevs v září 2026 jeden inženýr.

„Každý má vlastní sadu klíčů pro Claude, OpenAI, AWS Bedrock a všechny ostatní poskytovatele inference, které používáme.“

Článek BigGo o llm-proxy-tk, odlehčené bráně postavené na FastAPI, přirovnává toto uspořádání k proměně LLM ve „firemní vodu z kohoutku“, přičemž brána slouží jako hlavní uzávěr budovy.

Než ale tomuto potrubí svěříte tolik důvěry, podívejme se, co vlastně instalujete.

Co je brána LLM?

Brána LLM je reverzní proxy pro volání modelů. Vaše aplikace posílají požadavky na ni, nikoli přímo na OpenAI, Anthropic, Google nebo jiné poskytovatele LLM, které používáte. Brána tyto požadavky přeposílá a cestou na ně uplatňuje vaše pravidla.

Každý poskytovatel LLM má vlastní API: s vlastní strukturou požadavků, vlastním ověřováním a vlastním způsobem vracení chyb. Každý má také samostatné limity četnosti požadavků a vlastní způsoby selhání. Pokud před nimi není žádná sdílená vrstva, každá aplikace, která poskytovatele volá, si všechno dělá sama – a pokaždé trochu jinak.

Přirovnání k vodě z kohoutku má své meze, ale tohle vystihuje přesně – poskytovatelé se do potrubí napojí jen jednou, a to v bráně. Od té chvíle má každá aplikace vlastní přípojku s měřením, takže vidíte, kdo co spotřebovává, a můžete uzavřít kteroukoli jednotlivou přípojku, aniž byste sahali na ostatní.

Brány LLM, AI, MCP a API: jaký je mezi nimi rozdíl?

Jak brána LLM funguje?

Sledujte jeden požadavek z vaší aplikace k modelu a zpět.

1. Požadavek dorazí do brány: Vaše aplikace odešle na koncový bod brány zdánlivě běžný chatový požadavek, často ve formátu kompatibilním s OpenAI. Z pohledu aplikace jde o adresu, kterou volá, aby se dostala k modelu.
2. Brána ověří, kdo se ptá a co smí dělat: Před přeposláním požadavku ověří přihlašovací údaje. Často jde o virtuální klíč vydaný týmu nebo produktu. Pokud máte zapojené vstupní ochranné mechanismy, mohou se prompty prověřovat také na citlivá data nebo na pokusy přepsat instrukce modelu.
3. Brána zkontroluje, zda už odpověď nemá: Pokud je zapnuté ukládání do mezipaměti, lze na způsobilý shodný požadavek odpovědět uloženou odpovědí bez dalšího volání poskytovatele. Některé brány nabízejí i sémantické ukládání do mezipaměti, které hledá požadavky vyhodnocené jako dostatečně podobné, nikoli totožné. To se může hodit pro provoz typu častých dotazů (FAQ).
4. Brána zvolí, kam požadavek půjde: Požadavek může uvádět konkrétní model nebo alias. Brána vyhledá odpovídající trasu ve vaší konfiguraci. Můžete nastavit i záložní trasu. Pokud u poskytovatele A vyprší časový limit, brána může zkusit poskytovatele B.
5. Brána připraví volání a vrátí odpověď: Brána převede váš požadavek do formátu zvoleného poskytovatele a opatří odchozí volání ověřovacími údaji. Jakmile obdrží odpověď, převede ji do formátu, který vaše aplikace vyžaduje.
6. Brána zaznamená, co se stalo: Když je zapnuté protokolování, brána zaznamenává podrobnosti včetně toho, kdo volání provedl, který model ho obsloužil, počtu tokenů, latence a nákladů. Právě takový protokol inženýrovi z Redditu, o kterém jsme psali v úvodu, chyběl.

4 věci, které potřebujete vědět, než bránu nasadíte do produkce

Všechno popsané v předchozí části je možné proto, že brána vidí každý požadavek, který přes ni prochází. To je hlavní argument. Zároveň je to ale popis útočné plochy a závislosti na dodavateli, se kterými musíte počítat.

Brána je teď nejcennějším článkem vaší infrastruktury pro AI

Brána centralizuje přístup. A proto také soustřeďuje spoustu přihlašovacích údajů na dosah jediné služby. Bezpečnostní tým Microsoftu uvádí, co může nasazení LiteLLM uchovávat nebo načítat: klíče API poskytovatelů, vlastní hlavní klíč, záznamy virtuálních klíčů, připojovací řetězce databází, nastavení směrování a zásady tenantů.

V říjnu 2026 zveřejnila společnost Check Point Research dvě vysoce rizikové zranitelnosti v LiteLLM:

• CVE-2026-35029 umožňovala ověřeným uživatelům, včetně těch s oprávněním jen pro čtení, dostat se k administrativním funkcím a převzít kontrolu nad instancí.
• CVE-2026-59823 umožňovala uživatelům přesměrovat požadavky na server pod jejich kontrolou a zachytit klíče poskytovatelů.

Obě byly opraveny ve verzi 1.83.9. Aplikace, která bránu používá, by neměla mít možnost měnit její nastavení.

Vaše ochranné mechanismy potřebují zásadu pro případ selhání

Přehled společnosti Pillar Security ze 4. října 2026 dokumentuje integrace ochranných mechanismů třetích stran napříč hlavními bránami, včetně LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management a Apigee. (Pillar ochranné mechanismy prodává, takže to mějte při čtení jeho doporučení na paměti.)

Hook je bod na cestě požadavku, obvykle před odesláním promptu modelu nebo po návratu odpovědi, ve kterém může brána předat obsah externímu skeneru k posouzení. Blokující kontrola na toto posouzení čeká, než provoz pustí dál. Dokumentace Portkey je nazývá before_request_hooks a after_request_hooks; TrueFoundry používá čtyři a přidává kontroly před voláním nástrojů MCP a po něm.

Teď je potřeba ověřit dvě věci:

• Co se stane, když selže samotný skener? Když požadavek zablokujete, zastavíte nezkontrolovaný provoz, ale můžete přerušit chod aplikace. Když ho propustíte, aplikace může pokračovat bez této kontroly. Protokol selhání vám dodatečně ukáže, že kontrola chyběla, což je užitečné, ale není to totéž, jako kdyby proběhla.
• Lze skener vyměnit? Pokud jiný poskytovatel není podporován, možná budete muset upravit aplikaci nebo se připojit přes další proxy.

Hooky MCP od TrueFoundry rozšiřují dosah brány z požadavků na modely i na volání nástrojů. Brána ale dokáže kontrolovat jen provoz, který přes ni prochází. Programovací agent, který spouští příkaz na počítači vývojáře, může být mimo její dohled.

Open-source nástroj Numbat od Perplexity pracuje právě na této straně. Numbat se připojuje k podporovaným agentům přes lokální hooky a dokáže kontrolovat plánované akce, jako jsou příkazy shellu nebo zápisy do souborů, ještě před jejich spuštěním. Funkce blokování je volitelná a ve výchozím nastavení vypnutá. Brána vidí provoz modelů, který je směrován přes ni. Numbat přidává přehled o tom, co agent s odpovědí udělá.

Musíte vědět, kde končí kontrola brány

Forkast News rozlišuje tři vývojové linie, které se k bráně blíží z různých směrů:

• Brány zaměřené na LLM: LiteLLM a Portkey začínaly u volání modelů – překladu mezi poskytovateli, směrování požadavků a sledování tokenů. Nyní přidávají mechanismy řízení volání nástrojů.
• Platformy pro správu API: Kong, Apigee od Googlu a Azure API Management začínaly u ověřování, oprávnění a řízení provozu a poté přidaly podporu modelů a pravidla specifická pro AI.
• Infrastruktura navržená pro agenty: Například agentgateway vznikl kolem komunikace agentů s modely, nástroji a dalšími agenty, mimo jiné přes MCP a A2A.

Rozhodující otázkou je, co směrujete:

• Jen volání modelů? Dobrým výchozím bodem je brána primárně určená pro LLM.
• Volání modelů ve firmě, která už je plná pravidel pro API? Začněte s platformou, kterou už máte.
• Agenti volající nástroje, které volají modely? Ověřte, že jsou pokrytá i tato spojení.

Zavádíte sdílený bod selhání

Řekněme, že váš chatbot zákaznické podpory používá OpenAI a váš výzkumný nástroj Anthropic – a oba se připojují přes stejnou bránu. Pokud ale tato brána přestane fungovat, oba nástroje ztratí přístup ke svým modelům, i když OpenAI i Anthropic běží normálně.

Opravdu se to stalo. Chybovost AI Gateway od Cloudflaru vystoupala až na 97 % během výpadku 12. června 2025. Brána závisela na úložné službě Cloudflare Workers KV, ze které načítala nastavení, a tato služba selhávala.

Pokud bránu provozujete sami, udržujte spuštěnou další kopii, která může převzít provoz, když jedna selže. Pokud vaši bránu hostuje někdo jiný, zeptejte se, jak zajišťuje její chod při selháních a co se během obnovy děje s vašimi požadavky.

Klíčové funkce, na které se u bran LLM zaměřit

Bráně svěříte přístup k přihlašovacím údajům všech, takže byste měli být nároční na to, co vám nabídne na oplátku.

• Jedno API před více poskytovateli: Váš kód používá jeden formát, často kompatibilní s OpenAI, a brána překládá. Poskytovatelé LLM jí vycházejí vstříc. Například Agent API od Perplexity podporuje rozhraní Responses API od OpenAI, takže týmy mohou znovu použít stávající klientské knihovny OpenAI.
• Virtuální klíče s připojenými pravidly: Každý tým nebo produkt dostane vlastní klíč s pravidly, která určují povolené modely, limity požadavků a výdaje.
• Směrování a záložní řešení: Brána posílá požadavky modelům podle vašeho nastavení, které může upřednostňovat náklady, rychlost nebo konkrétního poskytovatele. Když volání selže, může zkusit jiný model. Agent API od Perplexity umožňuje uvést až pět modelů, včetně modelů od různých poskytovatelů, v pořadí podle vašich preferencí.
• Ukládání do mezipaměti: Uložená odpověď vám může ušetřit další volání poskytovatele. Některé brány hledají shodu jen u totožných požadavků, jiné ji dokážou najít i u požadavků s podobným významem. Ověřte, zda lze odpovědi v mezipaměti oddělit podle uživatele nebo týmu a zda můžete ukládání do mezipaměti vypnout u personalizovaných nebo časově citlivých odpovědí.
• Streamování a konzistentní chyby: Odpovědi přicházejí průběžně, jak se generují, a chyby poskytovatelů se překládají do formátu, se kterým si vaše aplikace poradí. Ověřte, co se stane, když přidáte ochranné mechanismy AI.
• Protokolování a přiřazení nákladů: Brána zaznamenává, kdo volání provedl, který model ho obsloužil, kolik tokenů spotřebovalo, jak dlouho trvalo a jaké jsou jeho odhadované náklady. Ověřte, zda protokoly obsahují prompty a odpovědi a jak dlouho se uchovávají.
• Hooky pro ochranné mechanismy: Jde o body na cestě požadavku, ve kterých může brána odeslat obsah externímu skeneru k posouzení. Obvykle se nacházejí před požadavkem na model nebo po jeho odpovědi. Ověřte, zda se požadavky při selhání skeneru zastaví, nebo pokračují, a zda můžete připojit jiný skener.
• Administrátorské rozhraní, které lze uzamknout: Brána spravuje přístup k přihlašovacím údajům poskytovatelů a k pravidlům, která používají všichni. Ověřte, že můžete omezit administrátorský přístup odděleně od provozu aplikací a že uživatelé s oprávněním jen pro čtení nemohou měnit nastavení. Hlavní uzávěr potřebuje zámek.

Jaké nástroje můžete použít k vytvoření vlastní brány LLM?

Seznamy funkcí se na trhu překrývají. V jednom vlákně na Redditu o interním přístupu k modelům se autor zeptal: Která brána nebude vyžadovat vyhrazeného inženýra?

Podle nás je to ta správná otázka a má čtyři odpovědi podle toho, jakou část práce jste ochotni převzít.

Napište si ji sami

Minimální brána zvládá krátký seznam úkolů – přijímá požadavky, kontroluje klíč volajícího, přidává přihlašovací údaje poskytovatele, přeposílá volání a protokoluje výsledek. Podpora různých formátů poskytovatelů ale přidává práci. A stejně tak udržování celého systému v chodu.

Pokud už provozujete Envoy, jeho filtr pro externí zpracování vám umožní připojit službu, která kontroluje a upravuje požadavky a odpovědi. Tuto službu ale stále musíte vytvořit a provozovat.

Ve vlákně na r/LLMDevs o tom, zda brána snižuje náklady, uživatel u/QuanTradin uvedl, že protokolování tokenů a příznaku zásahu mezipaměti u každého volání mu pomohlo najít dvě úlohy, které platily plnou cenu za totožné prompty.

„...oprava toho měla větší cenu, než by kdy měla jakákoli směrovací vrstva.“

Jde o zkušenost jednoho uživatele, ale je to dobrý výchozí bod. Než začnete vymýšlet propracované způsoby směrování, zjistěte, za co vlastně platíte.

Hostujte open-source bránu sami

LiteLLM je tu častou volbou: je kompatibilní s OpenAI, podporuje širokou škálu poskytovatelů a má velkou komunitu. Alternativou je Bifrost, navržený s ohledem na nízkou režii na každý požadavek. Helicone stojí za pozornost, pokud je pozorovatelnost na prvním místě vašeho seznamu požadovaných funkcí.

LiteLLM má jako každý produkt pro některé týmy své limity. Ve vlákně na r/aiagents o alternativách k vlastnímu vývoji uživatel u/Own_Bar_920 uvedl, že LiteLLM zvládalo směrování dobře, ale nestačilo mu u verzování promptů napříč týmy a průběžných evaluací při výměně modelů, což ho přimělo přejít na samostatný nástroj.

To jsou požadavky nad rámec základního směrování v bráně, a o to právě jde – pokud je hlavní potřebou směrování, LiteLLM se v jeho případě osvědčilo.

Získáte hotovou sadu funkcí (některé z nich závisejí na edici) a bránu udržíte uvnitř své sítě. Zároveň ale odpovídáte za záplatování, jehož význam konkrétně ukázala dříve zmíněná zjištění Check Pointu, a za dostupnost brány, kterou ilustrovala část o jediném bodu selhání.

Počítejte ale v rozpočtu s někým, kdo za ni bude zodpovídat. Jednou z obav ve vlákně na r/LLMDevs o branách pro interní přístup byla údržba. Uživatel u/Informal-Writer9685 chtěl něco, co „nevyžaduje vyhrazeného inženýra na údržbu“, a ptal se, zda je hlášená nestabilita LiteLLM při upgradech v jejich měřítku skutečný problém, nebo jen záležitost produkčního provozu.

Použijte spravovanou bránu

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter a hostovaná brána Portkey provozují službu za vás. U kompatibilní aplikace může k odeslání prvního požadavku stačit jen změna URL a klíč API.

Nevýhodou je, že každý prompt teď před dosažením poskytovatele prochází přes třetí stranu. To znamená dalšího zpracovatele dat ve vaší dokumentaci k dodržování předpisů a výpadek samotné brány je incidentem dodavatele – jeho oprava není ve vašich rukou.

Například 17. a 19. února 2026 měl OpenRouter výpadky trvající 38, resp. 35 minut, a to poté, co selhala závislost pro ukládání do mezipaměti. Někteří zákazníci dostávali chyby „User not found“ a trávili čas laděním naprosto platných klíčů API. Chyba byla v infrastruktuře brány.

OpenRouteru je ale třeba přičíst k dobru, že zveřejnil podrobnou analýzu incidentu a přidal ochranu, která zabrání tomu, aby selhání mezipaměti zahltilo jeho databázi. Spravovaná brána, jako je OpenRouter, může zjednodušit přístup, ale jak upozorňuje u/QuanTradin na r/LLMDevs, sloučení faktur samo o sobě výdaje nesníží.

Rozšiřte bránu API, kterou už máte

Pokud už před vašimi službami stojí Kong, Apigee nebo Azure API Management, každá z těchto platforem nabízí funkce specifické pro AI: Kong AI Gateway, zásady brány AI v Apigee a bránu AI v Azure API Management. Můžete stavět na ověřování, síťových pravidlech a provozních postupech, které už máte, a mechanismy řízení modelů přidat pomocí pluginů nebo zásad.

Ve velké firmě to může být cesta nejmenšího organizačního odporu. Funkce AI jsou tu ale mladší než u samostatných bran. Nezapomeňte otestovat omezování četnosti podle tokenů a streamování napříč celou sadou pluginů nebo zásad, které plánujete použít.

Hlavní ventil – všemocnou bránu – tedy rozhodně nainstalujte. Inženýr z úvodu má ale v jednom pravdu: přístup firmy k modelům by neměl záviset na tom, kdo má zrovna v šuplíku ten správný klíč.

Brána to řeší tak, že tyto klíče převede pod centrální správu – a o to víc je pak v sázce, když šuplík zůstane otevřený. Musíte vědět, čí ten šuplík je.

Časté dotazy k LLM bránám

Je LLM brána zdarma?

Pokud máte na mysli kategorii jako celek, některé LLM brány nabízejí bezplatné verze.

Nabídka LLM bran sahá od bezplatného open-source softwaru až po placené tarify začínající zhruba na 50 USD měsíčně, přičemž pro podniková nasazení platí individuální ceny. Některé si místo toho účtují procentní poplatek; například tarif Standard služby OpenRouter připočítává k nákupu kreditů 5,5 %.

Která LLM brána je nejlepší?

Kolik práce jste ochotni vzít na sebe?

• Pokud chcete bránu hostovat sami a mít konfiguraci pod kontrolou, podívejte se na Bifrost nebo Helicone.
• Spravovaná varianta, jako je OpenRouter nebo Vercel AI Gateway, se hodí pro týmy, které chtějí, aby službu provozoval někdo jiný.
• Pokud už používáte Kong nebo Azure API Management, nejprve si ověřte, jaké funkce pro AI nabízejí.

Vybrané kandidáty otestujte na vlastních požadavcích, včetně toho, co se stane, když některý poskytovatel selže.

Má AWS vlastní LLM bránu?

Ano. Amazon Bedrock AgentCore Gateway podporuje volání modelů prostřednictvím toho, co AWS nazývá „inference targets“. Díky nim mohou aplikace přes jediný koncový bod přistupovat k poskytovatelům, mezi něž patří Amazon Bedrock, OpenAI a Anthropic, přičemž brána spravuje přihlašovací údaje poskytovatelů a stará se o směrování.