Развёртывание LLM на Google Cloud Vertex AI

Деплой LLM Vertex AI: что ломается на проде

Деплой LLM Vertex AI обычно проходит гладко на демонстрации: один запрос, тёплый контекст, ручная проверка ответа. Vertex AI закрывает базовый слой — квоты, автомасштабирование, версионирование модели, — но прод начинается там, где запросы идут параллельно и круглосуточно. Именно тут развёртывание модели в облаке обнажает то, что не видно на тестовом прогоне.

Пиковая нагрузка на вывод первым делом бьёт по задержке: очередь запросов копится, время ответа растёт с долей секунды до десятков, часть вызовов падает по таймауту. Это и есть отказ модели под нагрузкой — сервис формально жив, но пользователь ответа не получает. Деградация нелинейна: до определённого порога всё выглядит нормально, а после обваливается лавинообразно, и масштабирование не успевает догнать рост.

Отдельный класс — утечки памяти в долгоживущих процессах вокруг модели: накопление контекста, не освобождённые буферы, растущие кэши. Инстанс держится сутки-двое, потом перезапускается по проверке живости, и на холодном старте задержка снова растёт. На графиках это выглядит как ритмичные провалы, которые списывают на «нестабильность облака».

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

Что даёт управляемое развёртывание модели

Модель описывается декларативно: версия образа, размер инстанса с ускорителем, минимальное и максимальное число копий, лимит на одновременные запросы. Каждое изменение — новая ревизия, к которой привязывается своя доля трафика. Это и есть суть управляемого развёртывания: конфигурация живёт в репозитории, а не в голове инженера, который вручную поднимал сервер.

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

Главный выигрыш — устранение отказов, которые раньше приходили вместе с обновлением. Выкат идёт долями: сначала на новую ревизию уходит часть трафика, мы сверяем время ответа и долю ошибок, и только потом переводим остальное. Если метрики просели, возврат на предыдущую ревизию занимает минуты и не требует пересборки — класс сбоев «обновление уронило рабочий контур» уходит.

Масштабирование вывода — про то, что моделей становится несколько. Ревизии под разные задачи живут на общем входе, у каждой свои квоты и лимиты, нагрузка распределяется балансировщиком. Vertex AI даёт это штатно, поэтому команда тратит время на качество ответов и данные, а не на самодельный слой вокруг запуска модели.

Варианты размещения LLM: сравнение режимов

Выбор режима размещения определяет три вещи: где физически лежат веса модели и данные, кто отвечает за масштабирование под нагрузку и как быстро выкатывается новая версия. На практике сравнивают четыре варианта — от полностью управляемого контура (например, развёртывание на Vertex AI) до изолированного внутри периметра заказчика. Ниже — что каждый даёт и какие ограничения платформы придётся принять.

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

Порядок внедрения: от аудита до передачи

Порядок фиксируем до старта: каждый этап заканчивается артефактом, который можно проверить, иначе приёмка превращается в разговор о впечатлениях. Этапы идут последовательно, и на каждом мы понимаем, что именно нужно от вашей команды.

1. Аудит инфраструктуры. Разбираем, что уже есть: проекты, сети, права, объёмы и качество данных для обучения и дообучения. Отдельно фиксируем требования к нагрузке — сколько одновременных запросов держит сервис и какая задержка ответа приемлема. На выходе — карта ограничений и рисков с приоритетами.
2. Схема размещения. Решаем, что отдаём управляемому сервису, а что поднимаем на своих мощностях: модели с чувствительными данными обычно требуют второго варианта. Схема показывает точки отказа, границы сетей и порядок выпуска новых версий.
3. Настройка окружения. Раздельные среды под разработку и продуктив, сервисные учётные записи с минимально нужными ролями, приватный сетевой доступ без публичных адресов, секреты — в защищённом хранилище. Всё описание хранится кодом, поэтому среда воспроизводится, а не собирается руками.
4. Сборка и подключение модели. Готовим образ с весами и зависимостями, настраиваем автомасштабирование под пики, ограничение параллельных запросов и журналирование без персональных данных. Новую версию сначала выпускаем на малую долю трафика.
5. Приёмочная проверка. Прогоняем профиль реальных запросов: замеряем задержку на длинных входах, смотрим поведение при отказе узла и исчерпании квоты, проверяем откат на предыдущую версию — он должен занимать минуты, а не часы.
6. Передача и обучение команды. Отдаём доступы, схемы, регламент обновлений и разбор типовых инцидентов, обучаем ваших инженеров. Первые недели работы сервиса идём рядом и правим настройки по фактическим метрикам, а не по предположениям.

Что остаётся у вас: конфигурации и регламенты

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

• Конфигурация окружения. Параметры модели, лимиты запросов, размеры экземпляров и переменные окружения — в системе контроля версий, с явным описанием отличий между контурами.
• Схема интеграции. Путь запроса от вашего приложения до модели: аутентификация, очереди, кэш, обработка длинных ответов и повторные попытки при таймаутах.
• Политики доступа. Роли сервисных учётных записей, права на вызов модели и на чтение данных, разделение доступов между тестовой и промышленной средами.
• Документация. Контракты API, форматы запросов и ответов, коды ошибок, поведение при исчерпании квот и при недоступности внешнего источника.
• Регламент обновлений. Как выкладывается новая версия модели, промпта или набора данных: кто подтверждает, какие проверки качества проходят до выката.
• Процедура отката. Куда возвращаемся при деградации: предыдущая версия, точки сохранения, целевое время восстановления и ответственный за решение.
• Наблюдаемость. Набор показателей — доля отказов, задержка ответа, расход токенов на запрос — и пороги, при которых приходит оповещение.

Кейс: убрали деградацию ответов на пиковой нагрузке

Пиковая нагрузка — единственный режим, который по-настоящему важен в продакшене. У сервиса обращений в поддержку генерация на Google Cloud Vertex AI держала форму до определённого потока, а дальше начиналась деградация: ответ растягивался, часть запросов обрывалась по времени ожидания, очередь копилась и разгоняла задержку ещё сильнее. Разбирались не с моделью, а с тем, как она развёрнута.

Что изменили

Разделили пулы ресурсов для лёгких и тяжёлых запросов, вынесли лимит времени ожидания на уровень перед моделью, добавили кэш повторяющихся обращений и прогревочный трафик перед открытием окна нагрузки. Обновление версии перестало быть событием с простоем: новая ревизия поднимается рядом, получает часть трафика, а предыдущая остаётся готовой к возврату.

Главное — поведение перестало зависеть от того, насколько удачно сложился день. При перегрузке сервис отдаёт короткий ответ или честную ошибку вместо зависшего ожидания, а деградация ответов заметна по метрикам до того, как её увидит пользователь. Это и есть разница между «модель работает» и «решение работает».

Чем отличается управляемая платформа от своего контура?

Управляемая платформа берёт на себя слой инфраструктуры: вы выбираете модель из каталога, регион размещения и режим доступа, а масштабирование под нагрузку, обновления и доступность сервиса закрывает провайдер. Развёртывание занимает дни, а не месяцы, и первые запросы уходят в работу почти сразу. Освободившееся время команда тратит на то, что реально влияет на результат — подготовку данных и качество формулировок.

Обратная сторона — границы контроля. Настраивается только то, что выведено в интерфейс платформы: квоты, изоляция сети, журналирование запросов, политика доступа. Сменить движок вывода, переписать планировщик очередей или оставить веса модели в собственном периметре здесь не получится — придётся ждать, пока нужная возможность появится у провайдера.

Свой контур — противоположный набор компромиссов. Веса, версии библиотек, схема дообучения и сетевая изоляция полностью в ваших руках, но туда же переходят планирование ёмкости, очереди, отказоустойчивость и совместимость драйверов. Это не «поставили и работает»: нужна команда, которая ведёт вывод модели в проде и разбирает деградации.

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

Выбор сводится к трём вопросам: насколько чувствительны данные, насколько предсказуема нагрузка и есть ли команда на постоянную поддержку. Часто выигрывает гибрид — проверка сценария на Vertex AI, затем перенос чувствительной части в свой контур; при едином слое доступа приложение не приходится переписывать.

Технические сомнения: отвечаем по пунктам

Сомнения на этапе оценки почти всегда одни и те же: поместится ли развёртывание LLM на Vertex AI в закрытый контур, переживёт ли сервис обновление модели, сколько переписывать в существующем приложении и кто получит доступ к логам запросов. Отвечаем по пунктам — детали фиксируем в проектной документации до старта работ.

Как обновляется модель без простоя?

Новая версия поднимается рядом со старой и проверяется на теневом трафике, пока качество ответов не сойдётся с эталоном. Переключение маршрута выполняется на шлюзе, предыдущая версия остаётся запущенной — откат занимает секунды.

Сколько придётся переписывать в существующем приложении?

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

Кто получит доступ к логам и как он разграничивается?

По ролям через корпоративный каталог: разработчик видит технические метрики, аналитик — обезличенные диалоги, поддержка — только свои обращения. Срок хранения логов ограничен, а каждое обращение к ним фиксируется в журнале аудита.

Обсудим задачу и вернёмся с оценкой и планом

Для старта достаточно описать задачу в свободной форме: какие сценарии закрывает модель, откуда приходят данные, какие требования к доступам и приватности, есть ли жёсткая дата запуска. Если уже есть прототип на Vertex AI или наработки с запросами и ответами — приложите, это сокращает разбор.

По итогам разбора мы возвращаемся с оценкой и планом, где зафиксированы состав работ, сроки этапов и точки контроля — места, где вы видите результат, а не отчёт о процессе.

• перечень вводных, которых не хватает для старта, и кто их даёт: доступы к проекту, наборы данных, эксперт по предметной области;
• состав работ по этапам: подготовка и разметка данных, выбор и настройка модели, контур оценки качества, развёртывание в Vertex AI и наблюдаемость;
• сроки каждого этапа и зависимости между ними — что идёт параллельно, а что блокирует следующий шаг;
• точки контроля с измеримым критерием приёмки: доля корректных ответов на отложенном наборе, время отклика, поведение при отказе;
• схему развёртывания: какие управляемые сервисы задействованы, как разделены среды и ограничены права;
• порядок передачи: конфигурации, документация, обучение вашей команды и план отката на предыдущую версию.

Опишите задачу в том объёме, в котором она у вас есть, — вернёмся с оценкой и планом работ и согласуем старт.