Perplexity пояснює принципи роботи шлюзів LLM і ризики під час експлуатації

Perplexity опублікувала практичний посібник зі шлюзів LLM 27 жовтня 2026 року. У ньому для інженерних команд описано, як проміжний рівень маршрутизує виклики моделей, автентифікує їх, кешує та реєструє, а також перелічено ризики для безпеки й надійності, пов’язані зі зберіганням облікових даних постачальників в одному сервісі.

Визначення та класифікація шлюзів

У посібнику шлюз LLM визначено як зворотний проксі для викликів моделей: застосунки надсилають запити шлюзу, а не безпосередньо таким постачальникам, як OpenAI, Anthropic чи Google, а шлюз пересилає ці запити, застосовуючи правила оператора. Цю категорію представлено як розв’язання проблеми розпорошення облікових даних. Посібник починається з допису у вересні 2026 року на Reddit у спільноті r/LLMDevs, де інженер описав робоче середовище, у якому кожен мав власні ключі для Claude, OpenAI, AWS Bedrock та інших постачальників інференсу.

У порівняльній таблиці посібника розрізнено чотири типи шлюзів. Шлюз API розташовується перед внутрішніми сервісами й визначає, чи автентифіковано клієнта та чи не перевищив він встановленого ліміту запитів. Шлюз LLM розташовується перед постачальниками моделей і визначає, якій моделі надійде запит, хто за нього заплатить і чи повернеться відповідь. Шлюз MCP визначає, чи може агент викликати певний інструмент із заданими аргументами. Терміном «шлюз ШІ» у посібнику позначено продукти постачальників, які поєднують певні функції цих типів шлюзів.

Шість етапів обробки запиту

У посібнику принцип роботи пояснено на прикладі одного запиту, який проходить шлях від застосунку до моделі й назад. Спочатку застосунок надсилає запит на чат, часто у форматі, сумісному з OpenAI, до кінцевої точки шлюзу. Шлюз перевіряє облікові дані — часто це віртуальний ключ, виданий команді або продукту — і, якщо налаштовано вхідні захисні механізми, може перевірити запити на наявність конфіденційних даних або спроб перевизначити інструкції моделі. Якщо кешування ввімкнено, на відповідний запит, що збігається з попереднім, можна відповісти збереженою відповіддю; деякі шлюзи також пропонують семантичне кешування, яке зіставляє запити, визнані подібними, а не ідентичними. Потім шлюз знаходить у своїй конфігурації відповідний маршрут і може переключитися на резервного постачальника, якщо перший не відповідає вчасно. Шлюз перетворює запит у формат вибраного постачальника, автентифікує вихідний виклик і перетворює відповідь у формат, потрібний застосунку. Якщо ведеться журналювання, шлюз фіксує, хто зробив виклик, яка модель його обробила, кількість токенів, затримку та вартість.

Ризики для безпеки та надійності

Головне застереження в посібнику: шлюз концентрує облікові дані. Команда Microsoft із безпеки перелічила дані, які може зберігати або отримувати розгортання LiteLLM: ключі API постачальників, головний ключ LiteLLM, записи віртуальних ключів, рядки підключення до баз даних, конфігурацію маршрутизації та дані про політики клієнтів. У дописі від 26 серпня 2026 року Microsoft описала зафіксований випадок компрометації шлюзу LiteLLM, під час якого зловмисники викрали облікові дані із середовища виконання шлюзу.

13 жовтня 2026 року Check Point Research повідомила про дві вразливості високого ризику в LiteLLM: CVE-2026-35029 — уразливість контролю доступу, яка давала автентифікованим користувачам, зокрема з правами лише на читання, змогу отримувати доступ до адміністративних функцій і захопити контроль над шлюзом; і CVE-2026-59823 — уразливість підроблення запитів на стороні сервера, яка давала користувачам змогу перенаправляти запити шлюзу на контрольований зловмисником сервер і перехоплювати ключі API постачальників ШІ. Обидві вразливості виправлено у версії LiteLLM 1.83.9. За даними Check Point, LiteLLM завантажують 97 мільйонів разів на місяць, а кількість зірок на GitHub перевищує 59 000. Компанія повідомила, що скоординоване розкриття інформації LiteLLM розпочалося в жовтні 2025 року.

У посібнику також рекомендують командам визначити політику на випадок відмови захисних механізмів. У ньому хуки описано як точки в процесі обробки запиту, у яких шлюз передає вміст зовнішньому сканеру для оцінювання. Зазначається, що в документації Portkey згадано before_request_hooks і after_request_hooks, а TrueFoundry використовує чотири хуки, додаючи перевірки до та після викликів інструментів MCP.

Щодо надійності, у посібнику наведено задокументовані перебої в роботі. У власному звіті Cloudflare про перебій 12 червня 2025 року зазначено, що частка помилок AI Gateway сягнула 97% запитів, оскільки AI Gateway використовує Workers KV для клієнтських і внутрішніх конфігурацій; загалом перебій тривав 2 години 28 хвилин. У звіті про інциденти OpenRouter щодо перебоїв 17 і 19 лютого 2026 року зазначено, що через збій залежності стороннього кешування інциденти тривали 38 і 35 хвилин, спричинили помилки 401 «Користувача не знайдено» та призвели до впровадження низки заходів, зокрема автоматичних вимикачів і повернення помилок 503 замість 401, коли проблеми з інфраструктурою перешкоджають перевірці авторизації.

Варіанти розгортання, ціни та особливості постачальників

У посібнику описано чотири способи розгортання. Команди можуть самостійно створити мінімальний шлюз — приймати запити, перевіряти ключ відправника, додавати облікові дані постачальника, пересилати виклик і записувати результат у журнал — або розмістити шлюз із відкритим кодом на власній інфраструктурі; серед таких варіантів названо LiteLLM, Bifrost і Helicone. Серед керованих шлюзів згадано Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter і розміщений шлюз Portkey. Четвертий варіант — розширити шлюз API, який компанія вже використовує; як приклади наведено Kong AI Gateway, політики шлюзу ШІ в Apigee та шлюз ШІ в Azure API Management.

Щодо вартості, у посібнику зазначено, що ціни на шлюзи для великих мовних моделей (LLM) варіюються від безкоштовного програмного забезпечення з відкритим кодом до платних тарифів, які починаються приблизно від 50 доларів на місяць, а для підприємств передбачають індивідуальне ціноутворення. Деякі шлюзи натомість стягують відсоток: як зазначено в посібнику, тариф Standard від OpenRouter додає 5,5% до суми придбання кредитів.

Наприкінці посібник містить відповіді щодо окремих постачальників. У ньому зазначено, що Amazon Bedrock AgentCore Gateway підтримує виклики моделей через те, що AWS називає «цілями інференсу», даючи змогу застосункам звертатися до таких постачальників, як Amazon Bedrock, OpenAI та Anthropic, через одну кінцеву точку. Також у посібнику йдеться, що власний Agent API від Perplexity підтримує інтерфейс Responses API від OpenAI, тож команди можуть повторно використовувати наявні клієнтські бібліотеки OpenAI, а сам Agent API дає змогу користувачам перелічувати до п’яти моделей, зокрема від різних постачальників, у бажаному порядку. У посібнику також згадується Numbat — проєкт Perplexity з відкритим вихідним кодом, який під’єднується до підтримуваних агентів через локальні хуки та може перевіряти заплановані дії, як-от команди оболонки чи записування файлів, перш ніж їх буде виконано; блокування таких дій є необов’язковим і за замовчуванням вимкнене.