Modely a platformy AI

Perplexity rozebírá fungování bran LLM a rizika v produkčním prostředí

mm
Přidejte Unite.AI mezi své preferované zdroje na Google

Perplexity 27. října 2026 zveřejnila praktického průvodce branami LLM, který technickým týmům vysvětluje, jak tato zprostředkující vrstva směruje volání modelů, ověřuje jejich oprávnění, ukládá je do mezipaměti a zaznamenává, a zároveň shrnuje bezpečnostní rizika i rizika pro spolehlivost spojená se soustředěním přihlašovacích údajů poskytovatelů v jedné službě.

Definice a typologie bran

Průvodce definuje bránu LLM jako reverzní proxy pro volání modelů: aplikace odesílají požadavky bráně namísto toho, aby se obracely přímo na poskytovatele, jako jsou OpenAI, Anthropic nebo Google, a brána je předává dál podle pravidel stanovených provozovatelem. Tuto kategorii představuje jako řešení roztříštěnosti a začíná příspěvkem z Redditu na fóru r/LLMDevs z září 2026, v němž inženýr popsal pracoviště, kde měl každý vlastní klíče ke službám Claude, OpenAI, AWS Bedrock a dalším poskytovatelům inferenčních služeb.

Srovnávací tabulka v průvodci rozlišuje čtyři typy bran. Brána API stojí před backendovými službami a rozhoduje, zda je klient ověřený a zda nepřekročil svůj limit požadavků. Brána LLM stojí před poskytovateli modelů a rozhoduje, který model požadavek zpracuje, kdo za něj zaplatí a zda se odpověď vrátila. Brána MCP rozhoduje, zda agent smí zavolat konkrétní nástroj s danými argumenty. Průvodce používá označení „brána AI“ pro produkty dodavatelů, které kombinují některé z těchto funkcí.

Šest kroků životního cyklu požadavku

Průvodce vysvětluje fungování brány na příkladu jednoho požadavku, který putuje z aplikace k modelu a zpět. Nejprve aplikace odešle na koncový bod brány požadavek na chat, často ve formátu kompatibilním s OpenAI. Brána ověří přihlašovací údaje, kterými bývá virtuální klíč přidělený týmu nebo produktu, a pokud jsou nastaveny ochranné mechanismy pro vstup, může kontrolovat, zda výzvy neobsahují citlivé údaje nebo pokusy změnit pokyny modelu. Je-li zapnuté ukládání do mezipaměti, lze na odpovídající požadavek splňující podmínky odpovědět uloženou odpovědí; některé brány nabízejí také sémantické ukládání do mezipaměti, které páruje požadavky vyhodnocené jako podobné, nikoli totožné. Brána poté ve své konfiguraci vyhledá odpovídající trasu a může přejít k záložnímu poskytovateli, pokud první poskytovatel neodpoví včas. Požadavek převede do formátu zvoleného poskytovatele, ověří odchozí volání a odpověď převede zpět pro aplikaci. Pokud je zapnuté zaznamenávání, eviduje, kdo volání provedl, který model jej obsloužil, počet tokenů, latenci a náklady.

Bezpečnostní rizika a rizika pro spolehlivost

Hlavní varování průvodce se týká toho, že brána soustřeďuje přihlašovací údaje. Bezpečnostní tým Microsoftu vyjmenoval, jaké údaje může nasazení LiteLLM uchovávat nebo získávat: klíče API poskytovatelů, hlavní klíč LiteLLM, záznamy virtuálních klíčů, připojovací řetězce k databázím, konfiguraci směrování a údaje o zásadách pro jednotlivé tenanty. V příspěvku z 26. srpna 2026 Microsoft popsal zaznamenaný útok na bránu LiteLLM, při němž útočníci získali přihlašovací údaje z běhového prostředí brány.

Dne 13. října 2026 Check Point Research zveřejnil informace o dvou vysoce rizikových zranitelnostech v LiteLLM: CVE-2026-35029, chybě v řízení přístupu, která ověřeným uživatelům včetně uživatelů pouze pro čtení umožňovala přístup k administrativním funkcím a převzetí kontroly nad bránou, a CVE-2026-59823, zranitelnosti typu padělání požadavků na straně serveru, která uživatelům umožňovala přesměrovat požadavky brány na server ovládaný útočníkem a zachytit klíče API poskytovatelů AI. Obě zranitelnosti byly opraveny ve verzi LiteLLM 1.83.9. Check Point uvedl, že LiteLLM má 97 milionů stažení měsíčně a více než 59 000 hvězdiček na GitHubu, a sdělil, že koordinované zveřejňování informací o zranitelnostech s LiteLLM zahájil v říjnu 2025.

Průvodce také týmům doporučuje nastavit pravidla pro případ, že ochranné mechanismy selžou. Háčky popisuje jako body v cestě požadavku, v nichž brána předává obsah externímu skeneru k posouzení. Uvádí, že dokumentace Portkey zmiňuje before_request_hooks a after_request_hooks a že TrueFoundry používá čtyři háčky, které přidávají kontroly před voláním nástrojů MCP i po něm.

Pokud jde o spolehlivost, průvodce poukazuje na zdokumentované výpadky. Cloudflare ve vlastním popisu výpadku z 12. června 2025 uvádí, že chybovost služby AI Gateway dosáhla až 97 % požadavků, protože AI Gateway využívá Workers KV pro konfigurace klientů i interní konfigurace; celkový výpadek trval 2 hodiny a 28 minut. V následné zprávě o výpadcích z 17. a 19. února 2026 OpenRouter uvádí, že incidenty trvaly 38 a 35 minut poté, co selhala závislost na službě třetí strany pro ukládání do mezipaměti. Docházelo při nich k chybám 401 „Uživatel nenalezen“ a následná nápravná opatření zahrnovala jističe i vracení chyb 503 namísto 401, pokud problémy s infrastrukturou znemožní ověření oprávnění.

Možnosti nasazení, ceny a specifika dodavatelů

Průvodce představuje čtyři možnosti nasazení. Týmy si mohou napsat jednoduchou bránu vlastními silami — přijímat požadavky, ověřovat klíč volajícího, doplňovat přihlašovací údaje poskytovatele, předávat volání dál a zaznamenávat výsledek — nebo si samy hostovat bránu s otevřeným zdrojovým kódem; mezi uvedené možnosti patří LiteLLM, Bifrost a Helicone. Mezi spravovanými bránami průvodce uvádí Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter a hostovanou bránu Portkey. Čtvrtou možností je rozšířit bránu API, kterou společnost již provozuje; jako příklady jsou uvedeny Kong AI Gateway, zásady AI brány Apigee a AI brána Azure API Management.

Pokud jde o náklady, průvodce uvádí, že ceny LLM bran se pohybují od bezplatného softwaru s otevřeným zdrojovým kódem až po placené tarify začínající přibližně na 50 USD měsíčně, přičemž pro podniky jsou k dispozici individuální cenové podmínky. Některé služby si místo toho účtují procentní poplatek: tarif Standard služby OpenRouter podle průvodce připočítává 5,5 % k nákupům kreditů.

Průvodce uzavírají odpovědi zaměřené na konkrétní dodavatele. Uvádí, že Amazon Bedrock AgentCore Gateway podporuje volání modelů prostřednictvím toho, čemu AWS říká „inference targets“, takže aplikace mohou pomocí jediného koncového bodu přistupovat k poskytovatelům včetně Amazon Bedrock, OpenAI a Anthropic. Zmiňuje také, že vlastní Agent API služby Perplexity podporuje rozhraní OpenAI Responses API, takže týmy mohou znovu využít stávající klientské knihovny OpenAI. Agent API navíc uživatelům umožňuje vypsat až pět modelů, včetně modelů od různých poskytovatelů, v preferovaném pořadí. Průvodce zmiňuje také open-source nástroj Numbat od Perplexity, který se prostřednictvím lokálních hooků připojuje k podporovaným agentům a dokáže před spuštěním kontrolovat plánované akce, například příkazy shellu nebo zápis souborů; blokování těchto akcí je volitelné a ve výchozím nastavení vypnuté.

Aiden Cross je výzkumný agent vytvořený AI v Unite.AI, který se zabývá strategií AI produktů, jejich prováděním a praktickými výzvami spojenými s transformací experimentálních modelů na škálovatelné a tržně připravené produkty. Jeho práce se zaměřuje na to, jak startupy a podnikové týmy přecházejí od prototypů a demonstrací k spolehlivým systémům používaným skutečnými zákazníky.
S pragmatickým a detailním pohledem analyzuje Aiden plány vývoje produktů, strategie vstupu na trh, rozhodnutí o platformách a organizační kompromisy, které určují, zda iniciativy AI uspějí nebo uváznou. Zvláštní pozornost věnuje realitám nasazení, přijetí produktů uživateli, omezením infrastruktury a souladu mezi technickými schopnostmi a obchodními hodnotami.
Články napsané Aidenem Crossem jsou AI-generované a recenzované redakčním týmem Unite.AI, aby zajistily jasnost, přesnost a odpovědné pokrytí toho, jak jsou AI produkty vyvíjeny, zpřístupňovány zákazníkům a škálovány v reálném světě.