Как работает LLM-шлюз? Практическое руководство для инженерных команд

LLM-шлюз располагается между вашими приложениями и поставщиками моделей, подключенными через него, и позволяет в одном месте управлять учетными данными и отслеживать использование.

«Сейчас это полный бардак», — написал на Reddit в r/LLMDevs один инженер в сентябре 2026 года.

«У каждого свой набор ключей для Claude, OpenAI, AWS Bedrock и всех остальных поставщиков инференса, которыми мы пользуемся».

В материале BigGo о llm-proxy-tk, легковесном шлюзе на FastAPI, такая схема сравнивается с превращением LLM в «корпоративный водопровод», где шлюз играет роль главного вентиля здания.

Но прежде чем так сильно доверять этой сантехнике, давайте разберемся, что именно вы устанавливаете.

Что такое LLM-шлюз?

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

У каждого поставщика LLM свой API: своя структура запросов, своя аутентификация и свой способ возвращать ошибки. У каждого также свои ограничения частоты запросов и сценарии сбоев. Если перед ними нет общего слоя, каждое приложение, обращающееся к поставщику, делает все само — и каждое немного по-своему.

Аналогия с водопроводом работает лишь до определенного предела, но здесь она вполне уместна: поставщики подключаются один раз — к шлюзу. После этого каждое приложение получает собственное подключение со счетчиком, так что вы видите, кто что использует, и можете перекрыть любую отдельную линию, не трогая остальные.

LLM-, ИИ-, MCP- и API-шлюзы: в чем разница?

Как работает LLM-шлюз?

Проследим путь одного запроса от вашего приложения к модели и обратно.

1. Запрос поступает на шлюз: ваше приложение отправляет на эндпоинт шлюза обычный на вид запрос к чату, часто в формате, совместимом с OpenAI. С точки зрения приложения, это адрес, по которому оно обращается к модели.
2. Шлюз проверяет, кто обращается и что ему разрешено: прежде чем переслать запрос, он проверяет подлинность учетных данных. Часто это виртуальный ключ, выданный команде или продукту. Если вы подключили защитные механизмы для входящих данных, промпты также можно сканировать на наличие конфиденциальных данных или попыток переопределить инструкции модели.
3. Шлюз проверяет, нет ли у него уже готового ответа: если включено кэширование, на подходящий совпадающий запрос шлюз может вернуть сохраненный ответ без повторного обращения к поставщику. Некоторые шлюзы также предлагают семантическое кэширование, при котором ищутся не идентичные, а достаточно похожие запросы. Это может подойти для трафика вроде ответов на часто задаваемые вопросы.
4. Шлюз выбирает, куда направить запрос: в запросе может быть указана конкретная модель или псевдоним. Шлюз находит соответствующий маршрут в вашей конфигурации. Можно также настроить резервный маршрут: если поставщик A не отвечает вовремя, шлюз может попробовать поставщика B.
5. Шлюз готовит вызов и возвращает ответ: шлюз преобразует ваш запрос в формат выбранного поставщика и аутентифицирует исходящий вызов. Как только ответ получен, он преобразуется в формат, который нужен вашему приложению.
6. Шлюз фиксирует, что произошло: если включено логирование, шлюз записывает сведения о том, кто сделал вызов и какая модель его обработала, а также количество токенов, задержку и стоимость. Именно такого журнала не хватало инженеру с Reddit, о котором шла речь во вступлении.

4 вещи, которые нужно знать, прежде чем запускать шлюз в продакшен

Все, что описано в предыдущем разделе, возможно потому, что шлюз видит каждый проходящий через него запрос. В этом и состоит главное преимущество. Но это же описание поверхности атаки и зависимости от вендора, которые нужно учитывать при планировании.

Теперь шлюз — самый ценный узел вашего ИИ-стека

Шлюз централизует доступ. А значит, множество учетных данных оказывается в зоне досягаемости одного сервиса. Команда безопасности Microsoft перечисляет, что может хранить или получать развертывание LiteLLM: API-ключи поставщиков, собственный мастер-ключ, записи виртуальных ключей, строки подключения к базам данных, настройки маршрутизации и политики тенантов.

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

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

Обе уязвимости исправлены в версии 1.83.9. Приложение, которое использует шлюз, не должно иметь возможности менять его настройки.

Вашим защитным механизмам нужна политика на случай сбоя

В обзоре Pillar Security от 4 октября 2026 года описаны интеграции сторонних защитных механизмов в основных шлюзах, включая LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management и Apigee. (Pillar продает защитные механизмы, так что учитывайте это, читая ее рекомендации.)

Хук — это точка на пути запроса (обычно перед отправкой промпта модели или после получения ответа), в которой шлюз может передать содержимое внешнему сканеру для вынесения вердикта. Блокирующая проверка ждет этого вердикта, прежде чем пропустить трафик дальше. В документации Portkey они называются before_request_hooks и after_request_hooks; TrueFoundry использует четыре хука, добавляя проверки до и после вызовов инструментов MCP.

Теперь стоит проверить две вещи:

• Что произойдет, если откажет сам сканер? Заблокировав запрос, вы остановите непроверенный трафик, но можете прервать работу приложения. Если пропустить его, приложение продолжит работу без этой проверки. Журнал сбоев потом покажет, что проверка не выполнялась, — это полезно, но не то же самое, что выполнить ее.
• Можно ли заменить сканер? Если другой поставщик не поддерживается, возможно, придется обновить приложение или подключаться через другой прокси.

MCP-хуки TrueFoundry расширяют охват шлюза с запросов к моделям на вызовы инструментов. Но шлюз может проверять только тот трафик, который через него проходит. Агент для программирования, выполняющий команду на компьютере разработчика, может оказаться вне его поля зрения.

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

Нужно знать, где заканчивается контроль шлюза

Forkast News выделяет три линии развития, которые приходят к шлюзам с разных сторон:

• Шлюзы, ориентированные на LLM: LiteLLM и Portkey начинали с вызовов моделей — преобразования запросов между поставщиками, маршрутизации и учета токенов. Сейчас они добавляют механизмы контроля вызовов инструментов.
• Платформы управления API: Kong, Apigee от Google и Azure API Management начинали с аутентификации, разрешений и управления трафиком, а затем добавили поддержку моделей и правил, специфичных для ИИ.
• Инфраструктура, изначально созданная для агентов: например, agentgateway строился вокруг взаимодействия агентов с моделями, инструментами и другими агентами, в том числе через MCP и A2A.

Чтобы сделать выбор, ответьте на вопрос, что именно вы маршрутизируете:

• Только вызовы моделей? Хорошей отправной точкой станет шлюз, ориентированный прежде всего на LLM.
• Вызовы моделей в компании, где уже полно правил для API? Начните с той платформы, которая у вас уже есть.
• Агенты вызывают инструменты, которые вызывают модели? Убедитесь, что эти подключения тоже охвачены.

Вы создаете общую точку отказа

Допустим, ваш чат-бот поддержки использует OpenAI, а инструмент для исследований — Anthropic, и оба подключаются через один и тот же шлюз. Если этот шлюз перестанет работать, оба инструмента потеряют доступ к своим моделям, даже если OpenAI и Anthropic работают в штатном режиме.

Такое действительно случалось. Во время сбоя 12 июня 2025 года доля ошибок в AI Gateway от Cloudflare достигала 97%. Шлюз хранил настройки в сервисе Cloudflare Workers KV, и этот сервис давал сбой.

Если вы управляете шлюзом сами, держите запущенной еще одну копию, которая сможет взять на себя работу при отказе. Если ваш шлюз размещает кто-то другой, спросите, как обеспечивается его работа во время сбоев и что происходит с вашими запросами во время восстановления.

Ключевые функции, на которые стоит обратить внимание в LLM-шлюзах

Вы собираетесь дать шлюзу доступ к учетным данным всех пользователей, поэтому вправе многого требовать от него взамен.

• Единый API для нескольких поставщиков: ваш код использует один формат, часто совместимый с OpenAI, а шлюз выполняет преобразование. Поставщики LLM идут навстречу. Например, Agent API от Perplexity поддерживает интерфейс Responses API от OpenAI, поэтому команды могут повторно использовать существующие клиентские библиотеки OpenAI.
• Виртуальные ключи с привязанными правилами: каждая команда или продукт получает собственный ключ с правилами, определяющими разрешенные модели, лимиты запросов и расходы.
• Маршрутизация и резервное переключение: шлюз направляет запросы к моделям в соответствии с вашими настройками, в которых приоритет может отдаваться стоимости, скорости или конкретному поставщику. Если вызов завершается ошибкой, шлюз может попробовать другой вариант. Agent API от Perplexity позволяет указать до пяти моделей, в том числе от разных поставщиков, в предпочтительном порядке.
• Кэширование: сохраненный ответ может избавить от повторного обращения к поставщику. Некоторые шлюзы находят только идентичные запросы, другие умеют сопоставлять и запросы, близкие по смыслу. Проверьте, можно ли разделять кэшированные ответы по пользователям или командам и можно ли отключать кэширование для персонализированных ответов или ответов, зависящих от времени.
• Потоковая передача и единообразные ошибки: ответы поступают по мере генерации, а ошибки поставщиков преобразуются в формат, который может обработать ваше приложение. Проверьте, что происходит, когда вы добавляете защитные механизмы ИИ.
• Логирование и распределение затрат: шлюз записывает, кто сделал вызов, какая модель его обработала, сколько токенов было использовано, сколько времени это заняло и какова ориентировочная стоимость. Проверьте, попадают ли в журналы промпты и ответы и как долго журналы хранятся.
• Хуки для защитных механизмов: это точки на пути запроса, в которых шлюз может отправить содержимое внешнему сканеру для вынесения вердикта. Обычно они расположены перед запросом к модели или после ее ответа. Проверьте, останавливаются ли запросы или продолжают выполняться при отказе сканера и можно ли подключить другой сканер.
• Административный интерфейс, доступ к которому можно ограничить: шлюз управляет доступом к учетным данным поставщиков и правилам, которыми пользуются все. Убедитесь, что доступ администраторов можно ограничить отдельно от трафика приложений и что пользователи с правами только на чтение не могут менять настройки. Главному вентилю нужен замок.

С помощью каких инструментов можно построить LLM-шлюз?

Списки функций у решений на рынке во многом пересекаются. В одном треде на Reddit о внутреннем доступе к моделям автор спросил: какой шлюз не потребует выделенного инженера?

На наш взгляд, это правильный вопрос, и на него есть четыре ответа — в зависимости от того, какую часть работы вы готовы взять на себя.

Написать самостоятельно

Минимальный шлюз выполняет небольшой набор задач: принимает запросы, проверяет ключ вызывающей стороны, добавляет учетные данные поставщика, пересылает вызов и записывает результат в журнал. Но поддержка разных форматов поставщиков добавляет работы. Как и поддержание работоспособности всей системы.

Если вы уже используете Envoy, его фильтр внешней обработки позволяет подключить сервис, который анализирует и изменяет запросы и ответы. Но этот сервис все равно придется создать и поддерживать самостоятельно.

В треде r/LLMDevs о том, снижает ли шлюз затраты, u/QuanTradin рассказал, что запись в журнал количества токенов и флага попадания в кэш при каждом вызове помогла им найти две задачи, в которых за идентичные промпты платили полную цену.

«...исправление этого принесло больше пользы, чем принес бы любой слой маршрутизации».

Это лишь опыт одного пользователя, но с него стоит начать. Выясните, за что вы платите, прежде чем выстраивать сложные схемы маршрутизации.

Развернуть шлюз с открытым исходным кодом у себя

LiteLLM — частый выбор в этом случае: он совместим с OpenAI, поддерживает широкий спектр поставщиков и имеет большое сообщество. Bifrost — альтернатива, созданная для минимальных накладных расходов на каждый запрос. На Helicone стоит обратить внимание, если наблюдаемость — главный пункт в вашем списке требований.

Как и у любого продукта, у LiteLLM есть ограничения, существенные для некоторых команд. В треде r/aiagents об альтернативах собственной разработке u/Own_Bar_920 написал, что LiteLLM хорошо справлялся с маршрутизацией, но им не хватило версионирования промптов между командами и непрерывных оценок при смене моделей, из-за чего пришлось перейти на отдельный инструмент.

Эти задачи выходят за рамки базовой маршрутизации в шлюзе, и в этом весь смысл: если основная потребность — маршрутизация, LiteLLM с ней справился.

Вы получаете готовый набор функций (часть из них зависит от редакции) и держите шлюз внутри своей сети. Но на вас ложится и установка исправлений — чем это оборачивается, наглядно показали упомянутые выше уязвимости, раскрытые Check Point, — и доступность шлюза, о которой шла речь в разделе про единую точку отказа.

Но заложите в бюджет человека, который будет за это отвечать. В одном треде r/LLMDevs о шлюзах для внутреннего доступа одной из проблем называли обслуживание. u/Informal-Writer9685 искал решение, которое «не требует выделенного инженера для поддержки», и спрашивал, является ли нестабильность LiteLLM при обновлениях, о которой сообщают пользователи, реальной проблемой в их масштабах или касается только продакшена.

Использовать управляемый шлюз

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter и размещенный шлюз Portkey берут эксплуатацию сервиса на себя. Чтобы совместимое приложение отправило первый запрос, может потребоваться немногим больше, чем изменить URL и получить API-ключ.

Компромисс здесь в том, что каждый промпт теперь проходит через третью сторону, прежде чем попасть к поставщику. Это еще один обработчик данных, которого нужно учесть в документации по соответствию требованиям, а сбой самого шлюза — это инцидент вендора, и исправлять его не вам.

Например, 17 и 19 февраля 2026 года у OpenRouter произошли сбои продолжительностью 38 и 35 минут соответственно после отказа зависимости, отвечающей за кэширование. Некоторые клиенты получали ошибки «User not found» и тратили время на отладку совершенно корректных API-ключей. Неисправность была в инфраструктуре шлюза.

Но надо отдать OpenRouter должное: компания опубликовала подробный разбор инцидента и добавила защиту, чтобы сбой кэша не перегружал ее базу данных. Управляемый шлюз вроде OpenRouter может упростить доступ, но, как отмечает u/QuanTradin на r/LLMDevs, объединение счетов само по себе не снижает расходы.

Расширить уже имеющийся API-шлюз

Если ваши сервисы уже работают за Kong, Apigee или Azure API Management, у каждого из них есть возможности для ИИ: Kong AI Gateway, политики ИИ-шлюза в Apigee и ИИ-шлюз в Azure API Management. Вы можете опираться на уже настроенную аутентификацию, сетевые правила и операционные процедуры, добавляя механизмы контроля моделей с помощью плагинов или политик.

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

Так что непременно установите главный вентиль — всемогущий шлюз. Впрочем, инженер из введения в чем-то прав: доступ компании к моделям не должен зависеть от того, у кого в ящике стола случайно лежит нужный ключ.

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

Часто задаваемые вопросы об LLM-шлюзах

Бесплатен ли LLM-шлюз?

Если речь о категории в целом, то у некоторых LLM-шлюзов есть бесплатные версии.

LLM-шлюзы бывают самыми разными: от бесплатного ПО с открытым исходным кодом до платных тарифов примерно от 50 долларов в месяц и индивидуальных цен для корпоративных развертываний. А некоторые взимают процент: например, тариф Standard в OpenRouter добавляет 5,5 % к стоимости покупки кредитов.

Какой LLM-шлюз лучший?

Какую работу вы готовы взять на себя?

• Присмотритесь к Bifrost или Helicone, если хотите разместить шлюз на собственной инфраструктуре и самостоятельно управлять конфигурацией.
• Управляемые решения, такие как OpenRouter или Vercel AI Gateway, подойдут командам, которые хотят переложить эксплуатацию сервиса на кого-то другого.
• Если вы уже используете Kong или Azure API Management, сначала изучите их возможности для работы с ИИ.

Протестируйте отобранные варианты на собственных запросах, в том числе проверьте, что происходит при сбое провайдера.

Есть ли у AWS LLM-шлюз?

Да. Amazon Bedrock AgentCore Gateway поддерживает вызовы моделей через механизм, который в AWS называют «целями инференса» (inference targets). Они позволяют приложениям через единую конечную точку обращаться к провайдерам, включая Amazon Bedrock, OpenAI и Anthropic, а шлюз при этом берет на себя учетные данные провайдеров и маршрутизацию.