LangSmith BYOC (Bring Your Own Cloud) теперь доступен на AWS в статусе GA, а на Azure и Google Cloud в бете. LangChain разворачивает и обслуживает платформу внутри виртуальной сети клиента, а трейсы, промпты, датасеты, эксперименты, деплои агентов и секреты рабочих пространств остаются в аккаунте и регионе клиента. Масштабирование, обновления схемы и runtime-зависимости при этом берёт на себя вендор. В анонсе это описано как способ уложиться в требования комплаенса без содержания платформенной команды на патчинг stateful-сервисов.
Формула короткая. Данные у вас, эксплуатация у LangChain. Режим закрывает разрыв между SaaS, где всё лежит в чужом облаке, и self-hosted, где всё в вашем, включая круглосуточную возню с обновлениями.
У LangSmith три режима развёртывания: LangSmith Cloud, self-hosted и BYOC. Дальше разбор, какие данные попадают в управляемую часть, что известно по каждому облаку, как проходит миграция и где границы применимости.
Что такое LangSmith BYOC и зачем он нужен
BYOC значит, что LangChain провижинит и оперирует LangSmith внутри вашей виртуальной сети: разворачивает сервисы, обновляет их, масштабирует, следит за совместимостью зависимостей. Облачный аккаунт, сеть, регион и сами данные остаются вашими. Для организаций с требованиями по резидентности данных и аудиту это снимает главный аргумент против SaaS.
Чем BYOC отличается от self-hosted и LangSmith Cloud
Разница между тремя режимами сводится к двум вопросам: где физически лежат чувствительные данные и кто отвечает за эксплуатацию.
| Критерий | LangSmith Cloud | Self-hosted | BYOC |
|---|---|---|---|
| Где лежат трейсы, промпты и секреты | В инфраструктуре LangChain | В инфраструктуре клиента | В аккаунте, VPC и регионе клиента |
| Кто эксплуатирует платформу | LangChain | Клиент | LangChain |
| Патчинг stateful-сервисов | LangChain | Клиент | LangChain |
| Настройка баз данных и миграции схем | LangChain | Клиент | LangChain |
| Масштабирование под нагрузку | LangChain | Клиент | LangChain |
| Скорость появления новых функций | Сразу после релиза в облаке | С выходом очередного релиза self-hosted | Вскоре после релиза в LangSmith Cloud |
Боль, ради которой появился BYOC, в анонсе названа прямо. Команды со строгими комплаенс-границами держали self-hosted LangSmith: данные оставались внутри периметра, но патчинг stateful-сервисов, настройка баз данных и прогон миграций схем требовали выделенных платформенных инженеров. Такая работа не заканчивается после первого запуска: сервисы обновляются, схемы меняются, инциденты случаются.
Как устроена архитектура: control plane и data plane
В режиме BYOC LangSmith делится на две части. Control plane LangChain держит у себя, data plane живёт в вашем облаке. Граница проходит по чувствительности: в управляемой части остаются метаданные и статика интерфейса, в вашем аккаунте - всё, что содержит содержимое работы с агентами.
Провижининг идёт в вашу виртуальную сеть: LangChain разворачивает и обслуживает LangSmith внутри неё, данные data plane остаются в вашем VPC, пока вендор занимается масштабированием, обновлениями схемы и runtime-зависимостями. Об этом прямо сказано в описании модели развёртывания.
Что остаётся в control plane у LangChain
Управляемая часть содержит пять групп данных:
- аутентификация;
- конфигурация организаций и рабочих пространств;
- биллинговые метаданные;
- хешированные API-ключи;
- статические UI-ассеты.
Это служебный слой. Содержимого трейсов, текстов промптов и секретов здесь нет. Отдельно про ключи: в control plane хранятся хеши API-ключей, по которым проверяется подлинность запроса, а не сами ключи в открытом виде. Секреты рабочих пространств лежат в data plane, то есть в вашем аккаунте.
Что хранится в data plane в аккаунте клиента
Data plane принадлежит клиенту и содержит всё чувствительное:
- трейсы;
- промпты;
- датасеты;
- эксперименты;
- деплои агентов;
- секреты рабочих пространств.
Каждый data plane привязан к конкретному аккаунту и региону. Для комплаенса это главное: содержимое трейсов, тексты промптов и секреты не покидают ваш периметр, а регион выбирается под требования по резидентности данных.
Поддержка облаков: AWS в GA, Azure и Google Cloud в бете
Статусы на момент анонса: AWS - GA, Azure и Google Cloud - Beta. Версия для AWS стартовала в августе, и, по данным LangChain, с тех пор многие команды выбрали BYOC для запуска LangSmith в своём облаке. GA в терминах вендоров значит общую доступность: возможность считается готовой к рабочей нагрузке. Бета такого статуса не даёт.
Что именно стоит за бетой на Azure и Google Cloud, в анонсе не раскрыто: нет ни сроков выхода в GA, ни цен, ни отдельного списка ограничений по функциям. Планировать production на этих облаках стоит с оглядкой на статус.
Azure: AKS, Istio, KEDA и Azure Monitor
По Azure технические детали известны лучше всего. Data plane разворачивается так:
- выделенная виртуальная сеть, внутри которой живёт вся нагрузка;
- приватный API-эндпоинт AKS: управляющий слой кластера недоступен из публичной сети;
- Istio через Helm отвечает за ingress-маршрутизацию входящего трафика к нужным сервисам;
- KEDA через Helm масштабирует сервисы по событиям, а не только по загрузке CPU;
- системная телеметрия уходит в Azure Monitor, то есть в вашу подписку.
Логика набора читается: приватная сеть и приватный API-эндпоинт убирают публичную поверхность, Istio даёт единую точку маршрутизации трафика между сервисами, KEDA позволяет не держать ресурсы под пиковую нагрузку постоянно. По AWS и Google Cloud на таком уровне детализации в анонсе ничего нет.
На всех трёх облаках data plane дополнительно запускает эндпоинты Managed Deep Agents.
Несколько data plane в одной организации: регионы, окружения, подразделения
Одна организация в LangSmith может держать несколько data plane. Каждый живёт в своём аккаунте и регионе, и каждый содержит свои рабочие пространства. Изоляция получается на уровне облачных аккаунтов, а не на уровне настроек доступа внутри одного развёртывания.
Рабочие схемы разделения:
- по окружению: production и staging в разных аккаунтах AWS, чтобы нагрузка тестов и эксперименты не пересекались с рабочими трейсами;
- по региону: data plane в регионе, который требует законодательство или внутренняя политика;
- по бизнес-подразделению: команда, стандартизировавшаяся на Azure, получает собственный data plane на Azure, остальные остаются на AWS.
Отдельные организации для этого не нужны. Держите в голове обратную сторону: аутентификация и конфигурация организации живут в control plane, то есть общие для всех ваших data plane.
Что BYOC снимает с команды: обновления, масштабирование, новые функции
LangChain перечисляет три выгоды, которые отмечают клиенты BYOC на AWS: непрерывные обновления, быстрый доступ к новым функциям LangSmith и автоматическое масштабирование. Это формулировки вендора и отзывы клиентов, а не измеренные метрики, поэтому читать их стоит как заявленные свойства режима.
Обновления без окон обслуживания и Helm-апгрейдов
В self-hosted обновление компонентов исполнения означает плановые работы: согласовать окно, обновить Helm-релизы, проверить stateful-сервисы и миграции. В BYOC обновления идут непрерывно, без окон обслуживания и без ручных Helm-апгрейдов на стороне клиента. Патчинг stateful-сервисов, настройка баз данных и миграции схем переходят к LangChain. Формулировка источника говорит именно об отсутствии окон обслуживания; гарантию нулевого простоя она не заменяет.
Скорость появления новых функций LangSmith
В self-hosted новая возможность доезжает до вас с очередным релизом self-hosted. В BYOC новые функции появляются в data plane вскоре после релиза в LangSmith Cloud. Для команд, которые строят наблюдаемость и оценку агентов, это заметно: инструменты отладки агентов меняются быстро. Насколько быстро, видно по релизам последних месяцев, включая Red Teaming в LangSmith Engine v2 и LangSmith Custom Apps для собственных интерфейсов поверх данных платформы.
Третья заявленная выгода - автоматическое масштабирование сервисов под нагрузку: LangChain берёт на себя масштабирование, обновления схемы и runtime-зависимости. Часть ответственности остаётся на клиенте: облачный аккаунт, сеть, доступы и всё, что вокруг VPC. Конкретный список зон ответственности в анонсе не детализирован, его стоит зафиксировать с LangChain до запуска production.
Миграция с self-hosted: что переносит открытый инструмент, а что LangChain
Переход разбит на два потока. Открытый инструмент миграции переносит объекты платформы: пользователей, роли, датасеты, эксперименты, промпты, очереди аннотаций, правила автоматизации, дашборды и ресурсы Fleet. Трейсы, запуски и фидбэк переносятся отдельно, внутренними инструментами LangChain, и пока это работает только на AWS. Анонс разделяет эти два потока явно.
Ограничение стоит проговорить прямо. Если вы на self-hosted, у вас накоплена большая история трейсов и вам нужен Azure или Google Cloud, автоматического пути переноса истории пока нет: детали и сроки придётся уточнять у LangChain. Для команд, у которых трейсы служат сырьём для оценки качества и сборки датасетов, это узкое место, а не техническая мелочь.
Практическая сторона: Terraform, LLM Gateway и Managed Deep Agents
Точка входа для инфраструктурной команды - Terraform-модули BYOC, опубликованные в открытом репозитории. Развёртывание описывается кодом и проходит через ваши обычные ревью и пайплайны. Название репозитория и полный список переменных в анонсе не приводятся, искать стоит в открытых репозиториях LangChain.
Внутри data plane работает LLM Gateway. Он поддерживает 11 провайдеров моделей и любые OpenAI- или Anthropic-совместимые эндпоинты. Для команд, у которых трафик к моделям идёт через собственный шлюз или приватный деплой, это ключевая деталь: запросы можно направлять в свои модели, не выводя их за периметр. Конкретный список 11 провайдеров в анонсе не раскрыт.
Дополнительно на всех трёх облаках data plane запускает эндпоинты Managed Deep Agents. Что это даёт на практике, разбирали в материале про Managed Deep Agents 0.8.
Кому подходит BYOC, а кому нет
Критерии простые и проверяемые.
BYOC подходит, если:
- есть требование держать трейсы, промпты и секреты в своём облаке и выбранном регионе;
- не хочется держать платформенных инженеров на патчинг stateful-сервисов, базы и миграции схем;
- нужны свежие функции LangSmith без ожидания релизов self-hosted;
- есть несколько окружений или подразделений, которые надо развести по отдельным аккаунтам.
BYOC не подходит или требует паузы, если:
- вы на self-hosted с большой историей трейсов и планируете Azure или Google Cloud: перенос трейсов пока доступен только на AWS;
- production-нагрузку нельзя ставить на бета-статус, а ваше облако - Azure или Google Cloud;
- нужен полный контроль над каждым компонентом и своим графиком обновлений, тогда остаётся self-hosted.
Чек-лист вопросов до старта:
- В каком облаке и регионе должен жить data plane?
- Сколько исторических трейсов и запусков нужно перенести и на каком облаке?
- Кто отвечает за сеть, доступы и облачный аккаунт на вашей стороне?
- Нужны ли Managed Deep Agents и собственные LLM-эндпоинты через LLM Gateway?
- Какие функции LangSmith критичны и как быстро они нужны?
Вывод короткий. Если данные обязаны остаться в вашем аккаунте, а платформенную рутину вы хотите отдать вендору, BYOC на AWS - рабочий вариант уже сейчас. Для Azure и Google Cloud считайте бета-статус и доступность переноса истории трейсов отдельными рисками, а не деталями оформления.