Perplexity опублікувала пояснення про принципи роботи та обмеження шлюзів ШІ

Perplexity опублікувала 20 жовтня 2026 року посібник про те, як шлюзи ШІ маршрутизують трафік між застосунками та великими мовними моделями, вимірюють його обсяг і керують ним, а також коли організації потрібен такий шлюз. Допис під назвою «Що таке шлюз ШІ? Посібник із маршрутизації, контролю витрат і керування трафіком запитів до великих мовних моделей та агентів» став найновішою публікацією в блозі компанії.

Визначення та обробка запитів

У посібнику шлюз ШІ визначено як центральний проксі-рівень між застосунками організації або її агентами ШІ, з одного боку, та великими мовними моделями й інструментами, до яких вони звертаються, — з іншого. На цьому рівні зосереджено маршрутизацію, контроль витрат, забезпечення безпеки та моніторинг використання. Оскільки кожен постачальник (у посібнику названо OpenAI, Anthropic, Google, моделі з відкритим кодом і кінцеві точки, що розміщуються самостійно) має власний SDK, ключі API та формат запитів, шлюз приймає запити в єдиному стандартному форматі й перетворює їх для постачальника, до якого надсилається запит. Моделі додають, замінюють або виводять з експлуатації через конфігурацію шлюзу, а не через код застосунку.

Згідно з посібником, кожен запит, спрямований на базову URL-адресу шлюзу, проходить ті самі чотири етапи: шлюз автентифікує та авторизує того, хто надсилає запит, за ключем і роллю; застосовує правила, зокрема обмеження на кількість токенів, бюджети та запобіжні механізми, серед яких — маскування персональних даних; маршрутизує запит до моделі або постачальника з огляду на вартість, затримку чи доступність, у разі збою переключає його на резервний варіант і перетворює запит у формат цільового постачальника; а також реєструє модель, кількість токенів, затримку й результат для відстеження витрат і налагодження.

Можливості та зазначені обмеження

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

Щодо обмежень, у посібнику зазначено, що шлюз збільшує затримку, однак для трафіку запитів до великих мовних моделей ця затримка, за словами авторів, відносно невелика. У ньому наведено результати незалежного тестування, проведеного в червні 2026 року командою Broadcom VMware Cloud Foundation: за налаштувань, оптимізованих для продуктивності, Envoy AI Gateway додавав близько 2 мілісекунд на запит за одночасної роботи до 224 користувачів, коли використовувалися маршрутизація та обмеження частоти запитів, але не перевірка вмісту. У тому самому тестуванні, як зазначено в посібнику, запобіжні механізми та семантичне кешування могли додавати від десятків до сотень мілісекунд. У посібнику також сказано, що шлюзи не вирішують, що запитувати в моделі, не запам’ятовують розмови, не виконують покрокову логіку агента й не оцінюють якість відповідей. Також автори застерігають, що маршрутизація з урахуванням вартості може знизити якість, якщо дешевша модель дає гіршу відповідь.

Типи шлюзів і трафік агентів

У посібнику шлюзи ШІ порівнюють із традиційними шлюзами API за кількома параметрами: облік токенів замість обмежень за кількістю запитів, семантичне кешування замість кешування з точним збігом, перевірка запитів на наявність конфіденційних даних і прихованих інструкцій замість автентифікації за ключем, а також маршрутизація до моделей за вартістю, затримкою чи можливостями замість маршрутизації до внутрішніх служб. У посібнику також розмежовано два вужчі поняття: шлюз великих мовних моделей обробляє сам виклик моделі, тоді як шлюз MCP визначає, до яких інструментів і джерел даних агент може отримати доступ через протокол Model Context Protocol. У посібнику зазначено, що LiteLLM, Portkey, Azure API Management і Envoy AI Gateway тепер підтримують керування MCP, тож ці терміни описують рівні контролю, які частково перетинаються.

Агенти, які, за описом у посібнику, працюють циклічно, послідовно звертаючись до моделей і використовуючи інструменти, доки не виконають завдання, перебувають під контролем шлюзу: він відстежує весь трафік, ініційований агентом, авторизує доступ агента до інструментів і джерел даних та реєструє всі виклики моделей і інструментів у журналі аудиту.

Наведені дані про впровадження та рекомендації щодо розгортання

Щоб оцінити попит, у посібнику наведено дані з досліджень третіх сторін. Індекс готовності до ШІ Cisco за 2025 рік засвідчив, що 83% із 8 039 опитаних керівників вищої ланки в організаціях із понад 500 працівниками планують розробляти або впроваджувати агентів ШІ. За прогнозом Gartner, до кінця 2026 року агенти для виконання конкретних завдань використовуватимуться у 40% корпоративних застосунків — порівняно з менш ніж 5% у 2025 році. Щодо витрат, у посібнику наведено дані опитування DoiT/Sapio за 2026 рік: 79% керівників фінансових підрозділів, які взяли в ньому участь, повідомили, що протягом минулого року перевищили бюджет на ШІ. Згідно з опитуванням Dataiku та Harris Poll за 2026 рік, 93% керівників ІТ-підрозділів великих компаній зазначили, що різні моделі краще працюють для різних сценаріїв використання; 81% великих компаній очікують, що використовуватимуть двох або більше постачальників моделей, а 55% принаймні один раз змінювали постачальника великих мовних моделей.

Згідно з незалежним моніторингом, на який посилається посібник, у травні 2026 року доступність провідних постачальників LLM становила приблизно 99,85–99,9% — це, за перерахунком у посібнику, близько 9–13 годин простою на рік. В опитуванні Cockroach Labs 2026 року, у якому взяли участь 1 125 керівників вищої ланки у сфері інфраструктури, дві третини респондентів оцінили, що година простою ШІ коштувала б їхній організації понад 100 000 доларів. Посібник також посилається на рейтинг OWASP за 2025 рік, у якому ін’єкцію промптів названо головним ризиком безпеки LLM, і на висновок Zscaler ThreatLabz: обсяг корпоративних даних, що надсилаються до застосунків ШІ, за рік зріс на 93%, а лише ChatGPT спричинив 410 мільйонів порушень правил запобігання витоку даних.

У посібнику наведено ознаки того, що організації потрібен шлюз: ключі постачальників жорстко прописані в кількох кодових базах; фінансовий відділ не може визначити, до яких моделей належать рахунки; виникають помилки через обмеження частоти запитів або простої, пов’язані із залежністю від одного постачальника; промпти із чутливими даними не перевіряються; команди створюють конкуруючі інтеграції з постачальниками; використовуються інтеграції з інструментами MCP; немає загального огляду безпеки й відповідності вимогам. У посібнику зазначено, що шлюз не потрібен для одного прототипу, невеликого побічного проєкту або запитів до однієї кінцевої точки моделі за мінімальних вимог до безпеки. Серед варіантів для самостійного розгортання названо LiteLLM, Portkey і Apache APISIX — у приватній хмарі, Kubernetes або локальній інфраструктурі. До керованих варіантів належать Cloudflare AI Gateway, Azure API Management і Amazon Bedrock AgentCore Gateway. Посібник пропонує оцінювати варіанти з огляду на контроль над даними й конфіденційність, операційне навантаження, зокрема використання сховищ стану, таких як PostgreSQL, Redis або etcd, швидкість розгортання та інтеграції. У розділі поширених запитань зазначено, що терміни «шлюз генеративного ШІ» та «шлюз ШІ» є взаємозамінними, а єдиного найкращого шлюзу ШІ з відкритим вихідним кодом не існує.