Почему инструменты трассировки LLM теперь создают шлюзы для ИИ

В 2026 году LangSmith, Langfuse, Opik и Braintrust добавили шлюз между приложениями и провайдерами моделей. Главная причина — контроль: инструмент трассировки может лишь записать вызов модели, а шлюз способен его остановить.

Два инструмента для разных задач

Последние два года многие команды использовали в приложениях на основе больших языковых моделей (LLM) два отдельных инструмента. Между приложением и провайдерами моделей находился шлюз. Он хранил ключи API провайдеров, преобразовывал запросы между API разных провайдеров и повторял неудачные вызовы. LiteLLM — прокси-сервер с открытым исходным кодом — стал распространенным решением для этой задачи. Рядом с приложением работал инструмент трассировки, например LangSmith или Langfuse: он записывал каждый вызов модели, вызов инструмента и этап извлечения данных, чтобы инженеры могли видеть, что сделал агент.

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

Четыре запуска за шесть месяцев

В мае 2026 года LangChain объявила о закрытом бета-тестировании шлюза LLM LangSmith, а 30 июля открыла публичное бета-тестирование. Позднее шлюз также стал частью развертываний LangSmith в облаке заказчика. Braintrust отказалась от поддержки своего прежнего ИИ-прокси и предложила пользователям новый шлюз, который пока доступен в предварительной версии и будет бесплатным до общего запуска. Comet выпустила шлюз LLM Opik в виде бета-версии конечной точки, принимающей запросы в формате OpenAI. 4 ноября Langfuse открыла свой шлюз для ИИ в рамках публичного бета-тестирования — как в Langfuse Cloud, так и для самостоятельного развертывания. Шлюз распространяется по лицензии MIT и написан на Rust.

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

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

Почему для контроля бюджета нужен шлюз в цепочке обработки запросов

Инструмент трассировки записывает вызов модели уже после того, как провайдер ответил и токены были оплачены. Этого достаточно, чтобы построить график расходов, но такой инструмент не может остановить траты. Чтобы контролировать бюджет команды, блокировать модель или удалять секрет из запроса, нужно проверять его до того, как он попадет к провайдеру. Это может сделать только компонент, через который проходит запрос.

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

Одна точка входа для записи каждого вызова

Вторая причина — полнота охвата. SDK записывает только те участки кода, для которых кто-то настроил инструментирование. Именно за пределами этих участков сбои агентов часто остаются незамеченными. Скрипт на ноутбуке, блокнот или агент для написания кода, использующий скопированный ключ API, не оставляет следов. Шлюз, в котором хранятся ключи провайдеров, видит каждый вызов, поскольку другого пути к провайдеру нет.

Langfuse строит свой шлюз на этом принципе. Согласно документации по шлюзу, каждый ключ шлюза принадлежит пользователю или служебной учетной записи и может содержать метаданные, например название команды или центра затрат. Учетные данные провайдера хранятся только в шлюзе, а администраторы утверждают, к каким моделям может обращаться каждый набор учетных данных. LangSmith публикует инструкции по настройке маршрутизации Claude Code, Codex и Gemini CLI через свой шлюз. Эти агенты обращаются к моделям с компьютера разработчика, вне системы трассировки какого-либо приложения.

Что шлюз добавляет к инструменту трассировки

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

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

Есть и коммерческий аспект, о котором сами поставщики не говорят. Тот, кто управляет шлюзом, владеет ключами доступа к провайдерам и отчетом о расходах, на который ориентируются финансовые команды и команды платформы. Поэтому заменить шлюз сложнее, чем инструмент просмотра трассировок. LangSmith и Langfuse уже по-разному используют это положение: LangSmith продает Gateway Credits, позволяющие клиентам обращаться к размещенным моделям, например Kimi, без собственного ключа провайдера, а в FAQ Langfuse говорится, что компания не перепродает токены.

Чего пока не умеют бета-версии шлюзов

Эти шлюзы появились недавно, и поставщики сами описывают их недостатки. Сейчас шлюз Langfuse поддерживает только OpenAI и Anthropic; Amazon Bedrock, Google Vertex AI и Google AI Studio указаны в планах развития. Резервное переключение между провайдерами и жесткие лимиты расходов для команд, пользователей или ключей запланированы, но пока не реализованы. Сейчас шлюз предлагает панель расходов и оповещения. В документации не описаны ограничения частоты запросов и кэширование ответов.

Шлюз Langfuse не преобразует форматы API, поэтому клиент OpenAI может обращаться только к моделям OpenAI. Самостоятельно размещаемая версия обращается только к официальным URL провайдеров, поэтому пока исключены Azure OpenAI, Bedrock и внутренний прокси. Comet описывает шлюз Opik как предназначенный для разработки и тестирования. Braintrust не объявляла цены на свой шлюз.

Шлюз LangSmith уже умеет больше, чем остальные. В документации в числе доступных сейчас функций указаны резервное переключение, лимиты расходов, ограничения частоты запросов и политики обработки данных; кроме того, он поддерживает форматы OpenAI Chat Completions, OpenAI Responses и Anthropic Messages. В мае резервное переключение и ограничения частоты запросов значились в планах, то есть их добавили во время бета-тестирования. Весь продукт по-прежнему имеет статус бета-версии.

Нагрузочное тестирование выявляет другой тип недостатков. В сравнительном тестировании шлюза Langfuse, LiteLLM и AcruxCore, развернутых на собственных серверах, выяснилось, что шлюз Langfuse добавлял к каждому вызову меньшую задержку, чем LiteLLM. Однако при настройках Docker по умолчанию он завершил с ошибкой 739 из 1 000 одновременных потоков, поскольку процесс использовал установленный Docker по умолчанию лимит в 1 024 открытых файла. Проблему устранила одна строка в файле Compose Langfuse.

По сравнению с этими бета-версиями LiteLLM, уже много лет работающий как отдельный шлюз, поддерживает более 100 провайдеров и уже включает виртуальные ключи, отслеживание расходов, защитные механизмы, балансировку нагрузки и панель администратора. LiteLLM также переносит обработку запросов с Python на Rust. Его шлюз ИИ на Rust находится в бета-версии, а команда LiteLLM ожидает, что запросы /v1/messages в стиле Anthropic будут полностью обрабатываться на Rust к 1 декабря, а задержка сократится примерно в 20 раз. Некоторые платформы с открытым исходным кодом, например MLflow и AcruxCore, уже объединяют шлюз и трассировку в одном продукте.

Почему их стоит оставить отдельными

Объединение шлюза с инструментом трассировки сопряжено с издержками, и главная из них — тесная связанность компонентов. При отдельном шлюзе команда меняет поставщика инструмента трассировки, просто заменив функцию обратного вызова для журналирования. Если инструмент трассировки одновременно служит шлюзом, приходится менять также базовый URL, ключи и идентификаторы моделей во всех сервисах. Например, Langfuse записывает идентификаторы моделей в формате credential:model.

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

Поставщики решений для безопасности стремятся занять то же место в цепочке обработки запросов. В мае 2026 года Palo Alto Networks завершила приобретение Portkey, отдельного шлюза, и сделала его шлюзом ИИ платформы Prisma AIRS. Команда по безопасности может предпочесть самостоятельно управлять шлюзом, а не размещать его внутри инструмента наблюдаемости. Шлюзы также стали мишенью для злоумышленников, что показал взлом цепочки поставок LiteLLM в марте.

Как командам сделать выбор

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

Затем следует проверить поддержку провайдеров. Команде нужно перечислить всех провайдеров и форматы API, которые используются в рабочей среде, включая Azure OpenAI и Bedrock, и сравнить этот список с тем, что каждый шлюз поддерживает сейчас, а не с планами развития.

У команд, уже использующих LiteLLM, мало причин переходить на другой продукт, пока бета-версия шлюза не предложит функции, которых им не хватает. Главное преимущество шлюза, встроенного в инструмент трассировки, — возможность видеть вызов шлюза внутри трассировки агента; ради этого переход должен быть оправдан. Команды, начинающие с нуля, могут оставить шлюз отдельным уровнем, даже если оба продукта предоставляет один поставщик. Если хранить базовый URL и ключи в одном модуле конфигурации, то при последующем переходе достаточно будет изменить конфигурацию, а не код.

Большинство этих шлюзов имеют статус бета-версии или предварительной версии, поэтому список их недостатков быстро сократится. Открытый вопрос — кто будет отвечать за цепочку обработки запросов в типичной компании: команда наблюдаемости, команда платформы, управляющая отдельным шлюзом, или команда безопасности. В этом году LangSmith и Langfuse создали собственные шлюзы, а Palo Alto Networks приобрела такой продукт, однако во многих инфраструктурах запросы по-прежнему проходят через LiteLLM.