Розгортання 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 і спостережуваність;
• строки кожного етапу й залежності між ними — що йде паралельно, а що блокує наступний крок;
• точки контролю з вимірюваним критерієм приймання: частка коректних відповідей на відкладеному наборі, час відгуку, поведінка при відмові;
• схему розгортання: які керовані сервіси задіяні, як розділені середовища й обмежені права;
• порядок передачі: конфігурації, документація, навчання вашої команди й план відкату на попередню версію.

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