Valuable insights
1.Развертывание больших моделей требует значительных ресурсов.: Модели с миллиардами параметров, такие как GPT или Stable Diffusion, потребляют много ресурсов, например, до 40 ГБ видеопамяти, что усложняет классическое бэкенд-развертывание.
2.Классический MVP на Python не обеспечивает надёжности.: Начальные решения на Flask/FastAPI демонстрируют долгий перезапуск подов (30 минут) и неспособность выдерживать даже минимальную нагрузку, требуя немедленной смены стека.
3.Nvidia Triton Inference Server — оптимальный выбор для продакшена.: Triton предоставляет необходимую надёжность, гибкость, встроенную генерацию API (HTTP/gRPC) и инструменты для метрик, несмотря на необходимость переписывания существующего ML-кода.
4.Оптимизация Docker-образов критична для скорости деплоя.: Сокращение размера образа и кэширование слоёв Docker значительно уменьшают время скачивания и запуска подов, что критично при масштабировании на дорогом оборудовании.
5.Асинхронная архитектура необходима из-за долгого инференса.: Поскольку генерация может занимать десятки секунд, синхронный подход приводит к таймаутам; требуется task-based архитектура с очередями для управления задачами.
6.Равномерная балансировка нагрузки GPU обязательна для утилизации.: Стандартная балансировка Kubernetes неэффективна; необходимо внедрение клиентской или серверной балансировки для равномерного распределения запросов по дорогим вычислительным узлам.
7.Экономика генерации сильно зависит от объёма трафика.: Удельная стоимость одной генерации может достигать десятков рублей, но этот показатель снижается по мере увеличения общего количества обрабатываемых запросов.
8.Модерация контента предотвращает генерацию нежелательных результатов.: Требуется многоуровневая модерация: LLM используется для проверки промптов, а постпроцессинг проверяет готовые изображения на соответствие запрещённым тематикам.
Введение и Проблематика Больших Моделей
Докладчик руководит разработкой платформы синтеза контента в банке, занимаясь генерацией изображений на основе текста. Основная задача — рассмотреть, как с точки зрения бэкенда осуществляется вывод в продакшн крупногабаритных моделей, которые требуют значительных вычислительных ресурсов для обучения и выполнения инференса.
Потребление ресурсов большими моделями
Под большими моделями подразумеваются модели, содержащие более миллиарда параметров, такие как GPT или Stable Diffusion. Их запуск и инференс требуют колоссального количества ресурсов. Например, Docker-образ может весить 14 ГБ, а для запуска модели необходимо около 40 ГБ видеопамяти, что является серьёзным вызовом для классических бэкенд-решений.
Первые Шаги и Боль от MVP
Первоначальное развёртывание на Kubernetes с использованием стандартных подходов показало критические недостатки. Приложение, развёрнутое в лоб, не могло обслуживать даже одного пользователя, а перезапуск подов для обновления версии занимал до 30 минут из-за необходимости скачивания больших образов (более 30 ГБ) из S3 хранилища при каждом старте.
Весь бэкэнд, который делался до этого, не был похож на то, что требуется для работы с такими моделями.
Дорога к продакшн-платформе
Для перехода от неработоспособного MVP к полноценной платформе с внятными SLO, релизами и экономикой был разработан дорожный план. Этот план нацелен на устранение проблем с надёжностью и производительностью, которые не решались классическими бэкенд-инструментами, и на обеспечение продоспособности системы.
Выбор Технологического Стека и Переход на Triton
На начальном этапе рассматривались два пути: использование обычного Python-сервера (Flask или FastAPI) или применение специализированного inference-движка для LLM. Было решено начать с Python, поскольку это быстрее и проще для оборачивания существующего кода ML-инженеров в API с помощью декораторов. Однако это решение оказалось ненадёжным для продакшена.
Переход к Production Ready решению
В итоге система была переписана на Production Ready Nvidia Triton Inference Server. Преимуществами стали его надёжность и гибкость. Основной сложностью этого перехода стала необходимость переноса и переформатирования всего кода, написанного на Python, чтобы он соответствовал требованиям Triton для запуска инференса.
Оптимизация Развертывания и Проблемы с Драйверами
После выбора сервера необходимо определить целевое аппаратное обеспечение, поскольку не все образы совместимы с доступным железом. Далее следует выбор базового образа (например, Triton 22.10) и критически важный шаг по минимизации его размера. Необходимо удалить весь лишний мусор и библиотеки, которые случайно попали в сборку.
Максимальное сокращение размера образа
Уменьшение размера образа напрямую влияет на скорость деплоя. Изначально сборка занимала 40 минут, а Kubernetes тратил 10 минут на скачивание образа. Применяя стандартные процедуры и кэширование слоёв Docker, удалось сократить сборку до 10 минут, а скачивание — до 5 минут, что является необходимым буфером для Kubernetes.
Мы пришли к фейлу, когда у нас было сначала две высотных (GPU-ноды), потом их стало шесть. И сначала у нас успевало выкатываться на двух нодах, на шести не успевало.
Ещё одной важной проблемой стала несовместимость версий драйверов. Обновление до более свежего образа Triton (с 22.10 до 24.10) оказалось возможным на продакшене, но провалилось в тестовом кластере из-за разницы в версиях драйверов. Это вынудило временно использовать разные версии в разных окружениях.
Экономика Ресурсов и Долгое Время Инференса
При проектировании платформ, требующих больших моделей, необходимо учитывать высокую стоимость аппаратного обеспечения. В отличие от классического бэкенда, где подходит любая нода с CPU и RAM, здесь количество доступных видеокарт ограничено. Кроме того, внутренние системы биллинга могут усложнять получение доступа к этим дорогим ресурсам.
Влияние длительного инференса
Длительность инференса (изначально 30 секунд на одну картинку) приводит к тому, что система мгновенно упирается в ресурсы, даже при наличии всего двух пользователей. При шести узлах с GPU пропускная способность остаётся крайне низкой, так как ресурсы не могут быть использованы эффективно из-за долгого ожидания завершения задачи.
Расчет удельной стоимости показывает, что генерация одной картинки может стоить до десятков рублей. Существует парадокс: чем больше генерируется изображений, тем ниже становится удельная стоимость, что подчёркивает важность максимизации утилизации дорогостоящего оборудования.
Революция Архитектуры: Асинхронность и Балансировка
Учитывая высокую стоимость и длительность инференса, синхронная архитектура, где API напрямую дёргает inference-сервер, оказалась непригодной, поскольку при нагрузке в два пользователя система отваливалась из-за таймаутов. Это потребовало полного пересмотра архитектуры в сторону асинхронности.
Построение асинхронной Task-Based Архитектуры
Переход к асинхронности ввёл понятие задачи (Task-based архитектура) с чёткими статусами: принята, в прогрессе, завершена (успех или фейл). Это требует наличия очередей, желательно с приоритетами, чтобы разделять запросы от пользователей, которым нужна быстрая генерация, от фоновых задач, которые могут ждать дольше.
- Быстрая и медленная очереди задач с приоритетами.
- S3 или реляционная база данных для хранения данных.
- Два типа консьюмеров (обработчиков), потребляющих задачи из разных очередей.
- Мульти-inference сервер.
Выжимаем максимум из железа: Балансировка
Для максимальной утилизации дорогих GPU необходимо равномерное распределение нагрузки. Стандартная балансировка Kubernetes случайна и не гарантирует равномерности. Изначально применялась клиентская DNS-балансировка, когда приложение само получало список IP-адресов GPU-нод и циклически отправляло запросы по кругу.
У нас есть умный балансировщик. Теперь только он знает, сколько у нас видеокарт, а приложение не знает.
Мониторинг, Тестирование и Качество Продукта
После построения архитектуры критически важным становится мониторинг рантайма. Необходимо отслеживать корректность инициализации при новых раскатках, анализировать логи процессов и ошибки на каждом шаге инференса, чтобы выявлять узкие места и определять наиболее стабильные ноды.
- Корректность инициализации сервиса.
- Отслеживание ошибок между этапами сложного инференса.
- Анализ нагрузки на каждый шаг для последующего горизонтального масштабирования.
- Измерение общей скорости генерации.
Нагрузочное тестирование и Качество
Проводится нагрузочное тестирование, эмулирующее поведение клиента (например, 10 000 запросов) для измерения общей пропускной способности платформы. Также измеряется стоимость в нетрадиционных единицах: одна картинка обходится примерно в 1 килокалорию.
Оценка качества генеративного контента сложна. Используется метрика Task Success, показывающая, насколько часто сгенерированная картинка реально решала задачу пользователя (была скачана или принята). Общая удовлетворённость (CSAT) измеряется опросами. Часть трафика (например, 130 000 картинок в месяц) размечается вручную на внутренней платформе Клекс для проверки таких деталей, как количество пальцев.
Итоги, Экономика и Модерация Контента
Оценка качества выявила нетривиальные проблемы. В одном из случаев модель, обученная хорошо генерировать людей (endpoint Jgerut в Stable Diffusion), на любой шум генерировала детализированную человеческую анатомию, что привело к нежелательному токсичному контенту. Это подчеркнуло острую необходимость в модерации.
Модерация Промптов и Результатов
Модерация должна проводиться как на этапе промпта (препроцессинг), так и на этапе готовой картинки (постпроцессинг). Это необходимо, поскольку слова могут быть токсичными только после перевода на английский. Для модерации промптов используется LLM, выступающая в роли системного модератора. Изображения проверяются на соответствие списку запрещённых тематик с использованием пороговых значений.
Подводя итог, успешная платформа синтеза контента требует последовательного выполнения шагов: выбор стека, подготовка и оптимизация артефактов развёртывания, расчёт экономики, проектирование асинхронной архитектуры, внедрение логирования и метрик, и, наконец, измерение продуктовых метрик качества и востребованности.
Questions
Common questions and answers from the video to help you understand the content better.
Как обеспечить равномерную загрузку дорогих GPU при инференсе больших моделей в Kubernetes?
Для обеспечения равномерной загрузки необходимо отказаться от стандартной случайной балансировки Kubernetes и внедрить умный балансировщик, который знает о наличии и состоянии всех видеокарт и распределяет запросы по принципу раунд-робина.
Почему синхронная архитектура не подходит для сервисов генерации изображений с долгим временем ответа?
Синхронная архитектура не подходит, потому что долгое время инференса (например, 30 секунд на картинку) приводит к таймаутам API, не позволяя системе выдерживать даже минимальную нагрузку от нескольких пользователей.
Какие метрики используются для оценки качества работы платформы генеративного контента, помимо стандартных CSAT?
Ключевой метрикой является Task Success, которая измеряет, насколько часто сгенерированный контент был реально принят и использован пользователем. Также применяется фоновая ручная разметка для проверки деталей, например, анатомической корректности.
Как решается проблема несовместимости драйверов GPU между тестовым и продуктивным кластерами при обновлении моделей?
Несовместимость драйверов может блокировать обновление образов моделей между окружениями. В таких случаях приходится временно использовать разные версии образов в тестовом и продакшн-кластерах, пока не будет достигнута унификация драйверного окружения.
Какую роль играет LLM в процессе модерации промптов перед запуском генерации контента?
LLM используется как модератор промптов. Ей передаётся системный промпт, имитирующий роль модератора, чтобы оценить потенциальную токсичность входного запроса до того, как он будет обработан диффузионной моделью.
Какова удельная стоимость генерации одной картинки на дорогостоящем оборудовании, и как она меняется с ростом трафика?
Удельная стоимость может достигать десятков рублей за одну картинку. Однако, согласно парадоксу экономики, чем больше генерируется изображений, тем ниже становится удельная стоимость, так как постоянные затраты на инфраструктуру распределяются на больший объём вывода.
Useful links
These links were generated based on the content of the video to help you deepen your knowledge about the topics discussed.