Развёртывание 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-узла?

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

Как выходит обновление модели?

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