Разбор архитектуры LLM шлюзов: принципы работы, риски и внедрение

В конце октября 2026 года компания Perplexity обнародовала практическое руководство по LLM шлюзам, в котором подробно разбирается промежуточный слой маршрутизации, аутентификации, кэширования и логирования запросов к большим языковым моделям. Инженерным командам демонстрируется устройство этого компонента, а также анализируются потенциальные риски безопасности и надежности, возникающие при концентрации учетных данных провайдеров в едином сервисе.

Интерес к управлению запросами к языковым моделям обусловлен переходом от разрозненных ключей доступа к централизованным архитектурным решениям. Подобный подход позволяет компаниям упорядочить работу с несколькими вендорами искусственного интеллекта.

Определение и таксономия шлюзов

В опубликованном материале LLM шлюз определяется как обратный прокси-сервер для вызовов моделей. Вместо того чтобы приложения обращались напрямую к таким провайдерам, как OpenAI, Anthropic или Google, они отправляют запросы на шлюз, который перенаправляет их с учетом установленных оператором правил. В качестве предпосылки создания таких систем приводится обсуждение на платформе Reddit в сентябре 2026 года, где разработчики описывали хаос с распределением индивидуальных ключей для разных платформ внутри компаний.

Сравнительная таблица в руководстве разделяет четыре разновидности шлюзов:

• API шлюз — размещается перед серверными службами, проверяет подлинность клиента и контролирует лимиты запросов (rate limit).
• LLM шлюз — устанавливается перед провайдерами моделей, определяет выбор конкретной модели для задачи, распределяет затраты и обрабатывает возвращаемые данные.
• MCP шлюз — принимает решения о том, имеет ли право агент вызывать определенный инструмент с заданными параметрами.
• AI шлюз — собирательное название для вендорских продуктов, объединяющих несколько указанных функций.

Жизненный цикл запроса из шести шагов

Механика работы шлюза прослеживается на пути отдельного запроса от клиентского приложения к модели и обратно. Процесс состоит из нескольких последовательных этапов:

• На первом шаге приложение отправляет запрос чата (часто в формате, совместимом с OpenAI) на конечную точку шлюза.
• Шлюз проверяет учетные данные, используя выданные команде или продукту виртуальные ключи, а входные защитные фильтры (guardrails) могут сканировать подсказки на наличие конфиденциальных данных или попыток обхода инструкций модели.
• При включенном кэшировании подходящий запрос может быть обслужен из сохраненного ответа; некоторые системы поддерживают семантическое кэширование, сопоставляющее похожие, а не идентичные формулировки.
• Затем шлюз находит подходящий маршрут в конфигурации и при необходимости переключается на резервного провайдера в случае таймаута первого.
• Запрос преобразуется в формат выбранного провайдера, исходящий вызов проходит аутентификацию, после чего ответ конвертируется обратно для приложения.
• На завершающем этапе при активном логировании фиксируются данные о том, кто совершил вызов, какая модель обслуживала запрос, количество токенов, задержка и стоимость.

Риски безопасности и надежности

Главным предупреждением руководства является риск концентрации учетных данных в рамках одной инфраструктуры. Специалисты безопасности Microsoft отмечали, что развертывание LiteLLM может содержать или обрабатывать ключи API провайдеров, мастер-ключ шлюза, записи виртуальных ключей, строки подключения к базам данных, конфигурации маршрутизации и политики арендаторов. В августе 2026 года Microsoft описывала случай компрометации шлюза LiteLLM, когда злоумышленники извлекли учетные данные из среды выполнения.

Кроме того, в октябре 2026 года исследовательская группа Check Point Research сообщила о двух уязвимостях высокого риска в LiteLLM:

• CVE-2026-35029 — дефект контроля доступа, позволявший аутентифицированным пользователям с правами только на чтение получать доступ к административным функциям и перехватывать управление шлюзом.
• CVE-2026-59823 — уязвимость подделки запросов на стороне сервера (SSRF), дававшая возможность перенаправлять запросы на контролируемый злоумышленниками сервер и похищать ключи API.

Обе уязвимости были устранены в версии LiteLLM 1.83.9, которая на момент отчета насчитывала 97 миллионов загрузок ежемесячно и более 59 000 звезд на GitHub. Руководство также рекомендует настраивать политику сбоев для систем защиты (guardrails). Описываются перехватчики (hooks) — точки в пути запроса, где шлюз передает контент внешнему сканеру для получения вердикта (например, before_request_hooks и after_request_hooks в Portkey или четырехуровневые проверки в TrueFoundry до и после вызовов инструментов MCP).

В отношении надежности приводятся примеры зафиксированных сбоев. Инцидент в Cloudflare от 12 июня 2025 года привел к тому, что показатели ошибок AI Gateway достигли 97% из-за зависимости компонента от системы хранения Workers KV; общая продолжительность сбоя составила 2 часа 28 минут. В отчетах OpenRouter о сбоях в феврале 2026 года отмечается, что падение сторонней зависимости кэширования приводило к ошибкам авторизации, после чего разработчики внедрили автоматические выключатели (circuit breakers) и возвращают коды 503 вместо 401 при инфраструктурных проблемах.

Варианты развертывания, ценообразование и специфика вендоров

Материал выделяет четыре основных пути развертывания шлюзов для инженерных команд:

• Самостоятельная разработка минимального шлюза своими силами для приема запросов, проверки ключей, добавления учетных данных провайдера, пересылки и логирования.
• Использование готового open-source решения для самостоятельного хостинга (например, LiteLLM, Bifrost или Helicone).
• Применение управляемых облачных шлюзов (Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter, размещаемый шлюз Portkey).
• Расширение возможностей уже используемого корпоративного API шлюза (Kong AI Gateway, политики Apigee AI, Azure API Management AI gateway).

Ценовой диапазон решений варьируется от бесплатного программного обеспечения с открытым исходным кодом до платных тарифных планов стоимостью от 50 долларов в месяц и заказных корпоративных предложений. Некоторые платформы используют комиссионную модель: например, стандартный план OpenRouter добавляет 5.5% к покупкам кредитов.

В заключительной части обзора рассматриваются особенности конкретных вендоров. Сервер Amazon Bedrock AgentCore Gateway поддерживает вызовы моделей через так называемые целевые объекты вывода (inference targets), позволяя использовать одну конечную точку для доступа к Amazon Bedrock, OpenAI и Anthropic. Собственный Agent API от Perplexity поддерживает интерфейс Responses API от OpenAI, что позволяет повторно использовать существующие клиентские библиотеки и указывать до пяти моделей от разных провайдеров в нужном порядке. Также упоминается инструмент с открытым исходным кодом Numbat от Perplexity, подключаемый к агентам через локальные перехватчики для проверки планируемых действий (например, команд оболочки или записи файлов) перед их выполнением.