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 «Пользователь не найден» и привели к мерам по устранению проблем, включая внедрение автоматических выключателей и замену ошибок 401 на 503 в случаях, когда проблемы инфраструктуры мешают проверке авторизации.

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

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

Что касается стоимости, в руководстве говорится, что цены на шлюзы для больших языковых моделей варьируются от бесплатного программного обеспечения с открытым исходным кодом до платных тарифов стоимостью от примерно 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 с открытым исходным кодом, который подключается к поддерживаемым агентам через локальные хуки и может проверять запланированные действия, например команды оболочки или запись файлов, до их выполнения. Блокировка таких действий является необязательной и по умолчанию отключена.