Розгортання LLM у Yandex Cloud з GPU та vLLM

Розгортання LLM: де інфраструктура ламається під навантаженням

На тестовому стенді все виглядає рівно: одиночні запити йдуть у модель і повертаються за частки секунди, затримка відповіді передбачувана, черга порожня.

Щойно надходить реальний потік звернень — десятки одночасних діалогів, різна довжина промптів, довгі історії листування — картина змінюється: частина запитів стоїть у черзі, частина відвалюється за таймаутом.

Вузьке місце майже завжди одне й те саме — пам'ять прискорювача. Ваги моделі займають фіксовану її частину, а залишок ділиться між кешем контексту активних сесій і буферами під обчислення.

Коли одночасних сесій стає більше, ніж вміщується, сервер витісняє чужі контексти й перераховує їх заново — час відповіді зростає ступенями, а не лінійно.

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

Нарощування кількості копій допомагає не завжди: якщо стеля задана конфігурацією виводу, нові копії чекають ті самі ресурси й подовжують чергу.

Тому ми починаємо не з абстрактних тестів, а з профілю навантаження на вивід моделей у вашому сценарії: довжина промптів, кількість одночасних сесій, частка довгих відповідей. Далі розбираємо, як це закривається.

Що дає виділений контур виводу моделей у робочому середовищі

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

Сусідні завдання перестають впливати на час відгуку, і затримка стає передбачуваною величиною, а не випадковою. Нижче — ознаки, за якими такий контур перевіряють до виводу в робоче середовище.

• Передбачувана затримка. Час відгуку тримається у вузькому коридорі й не зростає в рази на піку: запити не конкурують за прискорювач, а довжина черги обмежена зверху.
• Частка невдалих відповідей. Перевищення часу очікування та обриви з'єднань рахуються окремою метрикою, а довгий контекст не призводить до відмови через пам'ять.
• Простій сервісу. Оновлення моделі йде по вузлах по черзі, тому сервіс не зупиняється повністю на жодному кроці.
• Стійкість до відмов. Вузол виведено з ротації — трафік перерозподіляється, а ваги піднімаються з локального диска, без повторного завантаження зі сховища.
• Час відновлення. Вимірюється окремо: замінений вузол повертається в обслуговування передбачувано, без ручного складання середовища.
• Клас відмов. Зникає ціла група — деградація під навантаженням, різні версії моделі на вузлах, «плаваюча» довжина відповіді.
• Спостережуваність. Видно завантаження прискорювачів і глибину черги, у кожної відповіді є ідентифікатор запиту та версія моделі.

Профіль навантаження фіксуємо заздалегідь: частка довгих запитів, довжина контексту, пікові значення за добу. На виділених прискорювачах Yandex Cloud контур збирається як окрема група вузлів, тому результати тестового прогону переносяться в робоче середовище без перезбирання. Кожен пункт списку — це метрика, за якою видно результат, а не обіцянка.

Розгортання LLM у закритому контурі: варіанти розміщення

Вибір розміщення впирається не в розмір моделі, а в профіль навантаження. Діалоговий асистент чекає відповідь за частки секунди, нічний перерахунок масиву документів йде годинами, а тонке налаштування під домен взагалі не про обслуговування запитів.

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

Локальний контур знімає питання периметра: запити, логи та ваги не покидають вашу інфраструктуру, прискорювачі віддані лише вашому навантаженню, параметри виводу та квантування підбираються під завдання.

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

На практиці режими не конкурують, а комбінуються: інтерактив тримає модель з безперервною пакетною обробкою запитів — ми ставимо vLLM, він підмішує нові запити в поточний крок виводу й не дає прискорювачу простоювати, — архіви йдуть у нічний пакет, навчання йде в окремому контурі.

Гібридна схема дає передбачувану затримку на діалозі та повне завантаження карт на пакеті, а дані визначають, яка частина контуру залишається в закритому периметрі.

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

Роботи йдуть послідовно: спочатку вимірюємо реальне навантаження, потім проєктуємо контур, запускаємо вивід і після перевірок передаємо систему вашій команді. Порядок прибирає головний ризик — контур під передбачувані, а не під фактичні запити.

1. Аудит навантаження. Збираємо профіль запитів: довжину контексту, середній і піковий темп звернень, частку довгих генерацій, допустимий час до першого токена. Джерело — логи вашого сервісу або замірювальний прогін, а не оцінка «на око».
2. Схема контуру. Визначаємо кількість і тип прискорювачів, розміщення сервісу виводу на vLLM, балансування, черги, зберігання ваг і мережеві межі. Контур залишається закритим, назовні виходять лише точки доступу застосунку.
3. Налаштування виводу. Підбираємо модель під завдання, розмір пакета, паралелізм, квантування та ліміт контексту, вмикаємо прогрів і перевикористання спільного префікса. Мета — підняти пропускну здатність без зростання затримок.
4. Перевірка під навантаженням. Прогоняємо контур за профілем з першого кроку: ступінчасте зростання, довгі сесії, відмова однієї ноди. Фіксуємо затримки, пропускну здатність і поведінку при перевантаженні.
5. Передача в експлуатацію. Віддаємо конфігурацію контуру як код, дашборди, правила оповіщень, регламент оновлення моделі та порядок відкату на попередню версію.
6. Навчання команди. Розбираємо з вашими інженерами діагностику типових збоїв і ручне перемикання версій, щоб далі ви змінювали модель і параметри самі.

Далі — за домовленістю: ведемо контур на супроводі або залишаємо його вашій команді з повною документацією.

Документація, схеми та регламенти на виході

Проєкт вважається зданим не в момент, коли модель відповідає на запити, а коли ваша команда здатна підняти, оновити й відкотити її без нас.

Тому розгортання LLM ми закриваємо пакетом артефактів: конфігурації, схеми та регламенти залишаються у вашому репозиторії разом із системою, а не в листуванні.

• Схема взаємодії компонентів — які сервіси спілкуються між собою, де проходять межі довіри, які вузли з прискорювачами обслуговують вивід моделі та що станеться при відмові кожного з них.
• Конфігурації розгортання — маніфести, змінні середовища та параметри паралелізму сервера виводу з коментарями: які значення критичні для затримки, які змінюються без перезбирання.
• Ролі доступу та політики — сервісні облікові записи, області видимості ключів, розділення прав на читання логів, викат нової версії та доступ до панелі моніторингу.
• Інструкції для команди — запуск і зупинка сервісів, читання логів, діагностика типових відмов: нестача пам'яті на прискорювачі, таймаути на довгих запитах, недоступність зовнішнього сховища.
• Регламент оновлення моделі — порядок викату нової збірки ваг: підготовка середовища, тіньовий прогін на живому трафіку, порівняння якості за фіксованим набором питань, умови та час відкату.
• Порядок резервного копіювання — що саме копіюється, як часто, де зберігається і скільки займає відновлення працездатності.
• Карта моніторингу — метрики та пороги, при яких надходить оповіщення, з прив'язкою до дії, очікуваної від чергового.

Кейс: вивід моделей для служби підтримки — що змінилося

Кейс впровадження: служба підтримки з потоком у десятки тисяч звернень на добу виводила відповіді моделі через зовнішній сервіс.

Медіана відгуку трималася близько 4 секунд, але p95 сягав за 12, а в години пік запити ставали в чергу — оператор чекав відповіді довше, ніж формулював питання.

Частка помилкових відповідей трималася близько 10%, і частину їх списували на якість моделі, хоча в логах це були таймаути та обриви з'єднання.

Вивід перенесли на виділений кластер з прискорювачами в Yandex Cloud, обслуговування — через vLLM. Інференс винесли в окремий контур із групуванням запитів у пакети та кешем частих підказок, а оновлення ваг моделі перестало вимагати перезбирання сервісу.

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

Метрики до та після

• Медіана відгуку: з 4 до 1,2 секунди.
• p95: з 12 до 3,2 секунди.
• Частка помилкових відповідей: з 10% до 3,5%.
• Пік трафіку до 2,5 раза вище звичайного: проходить без черги та відмов.

Поведінка на піках змінилася найсильніше. Раніше стрибок трафіку означав ручне підняття потужностей, і частина запитів все одно падала; тепер вузли підключаються за десятки секунд, і черга розсмоктується раніше, ніж її помічає оператор.

Додали резервний маршрут: при деградації вузла запит іде на сусідній, відповідь віддається штатно, а інцидент видно в моніторингу.

Чим відрізняється хмарний вивід моделей від локального контуру?

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

У хмарі модель живе на орендованому GPU-пулі, наприклад у Yandex Cloud, а масштабування, драйвери та заміна вузлів, що відмовили, — на боці провайдера. Запуск займає години: розгортаємо контейнер з інференс-сервером, підключаємо сховище ваг, обмежуємо мережевий доступ.

Дані при цьому покидають периметр — ізоляція тримається на приватній мережі, шифруванні та політиці доступу до сховища, але фізично вони на чужому залізі.

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

Натомість ви тримаєте парк прискорювачів, оновлюєте драйвери та рантайм, чергуєте при відмові вузла й самі забезпечуєте пропускну здатність під пік.

На практиці частіше виграє гібрид: чутливі дані обробляються локально, решта сценаріїв ідуть у хмару. Вибір роблять за одним питанням — де фізично лежать дані й хто готовий нести за них відповідальність.

Технічні сумніви перед стартом робіт

Інженерні заперечення перед стартом рідко звучать як «чи взагалі запрацює» — скоріше як «що буде після запуску». Як перенести вже працюючу модель, куди йдуть дані, що станеться при відмові вузла й хто відповідає за систему через півроку. Нижче — п'ять питань, які найчастіше виринають на технічній прийманні.

Дані не вийдуть за межі контуру?

Модель і сховище ембеддингів живуть у приватній мережі, назовні дивиться лише шлюз API. Логи пишуться з маскуванням, ключі — через секрет-сховище з ротацією. Якщо політика вимагає, контур збирається взагалі без зовнішнього трафіку.

Що буде при відмові GPU-вузла?

Реплік мінімум дві, та що впала, виводиться з ротації, стан сесій зберігається поза вузлом — запити переїжджають без втрати контексту. Черга на вході гасить сплеск, поки піднімається заміна.

Як виходить оновлення моделі?

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

Що з підтримкою після передачі?

Віддаємо конфігурації, схеми, доступи та регламенти щодо типових збоїв, навчаємо вашу команду. Далі — супровід з обумовленим часом реакції або консультації на запит.

Що обговорити на першій зустрічі щодо вашого контуру

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

Готове технічне завдання не вимагається: достатньо відповідей на кілька питань, які ви й так тримаєте в голові.

• Які сценарії закриваємо: чат із внутрішньої бази знань, розбір документів, асистент для підтримки, генерація відповідей за регламентами.
• Профіль навантаження: звернень на годину в піку, середня та максимальна довжина запиту й відповіді, чи потрібна потокова видача.
• Вимоги до контуру: публічний сервіс чи внутрішня мережа, де лежать чутливі дані й чи можна їх виносити.
• Доступи: хмарний акаунт, роль із правами на мережу та обчислення, хто з боку замовника підтверджує зміни.
• Дані та матеріали: корпус документів для перевірки якості, приклади типових запитів, поточні прототипи й тести на моделях.
• Критерії приймання: цільова точність відповідей, допустимий час відповіді, частка відмов, готовність до відкату на попередню версію.

Цього достатньо, щоб підібрати конфігурацію GPU-вузлів під пікове навантаження із запасом, визначити схему оновлення моделей без зупинки сервісу та розкласти терміни розгортання LLM за етапами.

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