Дата публикации
ai_products

Как запускать диффузионные модели на GPU в Azure Kubernetes Service без боли в проде

Что нового

Microsoft описывает полноценный референс-подход к запуску диффузионных моделей (Stable Diffusion и похожие пайплайны) в продакшене на Azure Kubernetes Service (AKS).

Ключевые новшества не в самой генерации изображений, а в платформе вокруг неё:

  1. Чёткое разделение контуров нагрузки:

    • Лёгкий API-слой на CPU-нодах.
    • Отдельный слой диспетчеризации задач (внутри Kubernetes или через Azure Service Bus + KEDA).
    • Изолированный пул GPU-нод только под инференс.
    • Отдельный системный пул под ingress, CSI-драйверы и прочие аддоны.

  2. Два варианта очередей и масштабирования:

    • Kubernetes-native: очереди и контроллеры внутри кластера + стандартный autoscaling AKS.
    • Azure Service Bus + KEDA: внешняя очередь, масштабирование воркеров прямо от глубины очереди.

  3. Продуманная работа с артефактами моделей:

    • Кеш Hugging Face на постоянном хранилище, примонтированном к GPU-подам через PV/PVC.
    • Два варианта кеша: node-local (максимально близко к GPU) или Azure Storage (общий кеш между нодами для ускорения старта задач).

  4. GPU-изоляция и классы мощности:

    • Отдельный GPU-пул с NVIDIA device plugin DaemonSet.
    • Поддержка Multi-Instance GPU (MIG): можно делить один физический GPU на несколько логических.
    • Разделение на классы: задачи, требующие целый GPU, и задачи, которым достаточно «доли» GPU.

  5. Безопасность как часть архитектуры, а не «после релиза»:

    • Edge: DNS + Application Gateway с WAF, при необходимости Azure Front Door для глобального входа.
    • TLS-сертификаты в Azure Key Vault, подтягиваются в кластер через Secrets Store CSI Driver.
    • Microsoft Entra ID (бывший Azure AD) для токенов и Microsoft Entra Workload ID вместо долгоживущих секретов.
    • Доступ к Azure Blob, Key Vault, Service Bus через приватные endpoints и managed identity.

  6. Полноценная наблюдаемость не только за кодом, но и за железом:

    • Логи и трейсинг приложений через OpenTelemetry + Application Insights.
    • Метрики очередей, автоскейлинга AKS/KEDA, сервисов — через Azure Monitor.
    • Метрики GPU через NVIDIA DCGM exporter → Azure Managed Prometheus → Azure Managed Grafana.

  7. Простой, но взрослый CI/CD:

    • PR-валидация, тесты, сканирование секретов.
    • Неперезаписываемые теги контейнеров по SHA-коммита.
    • GitHub Actions + OIDC + Azure Workload Identity Federation.
    • ACR как единый источник образов.
    • Промо окружений с ручным апрувом для продакшена и автоматическими health-check и smoke-тестами.

  8. Альтернативы для тех, кому не нужен свой оркестратор:

    • KAITO — лёгкий вариант для быстрой работы с поддерживаемыми пресетами моделей.
    • AI toolchain operator add-on — более управляемый вариант для LLM и мультимодальных моделей с AKS-native-операционкой.

Цифр по производительности в материале нет, акцент на архитектурных решениях: как не утонуть в очередях, GPU-контеншене и проблемах с безопасностью.

Как это работает

Базовый архитектурный паттерн

AKS здесь — не просто кластер, а «пульт управления» GPU-платформой. Схема работы выглядит так:

  1. Входящий трафик и edge:

    • DNS указывает на Application Gateway с WAF.
    • Для глобального трафика можно добавить Azure Front Door.
    • Здесь же происходит TLS-терминация и первичная фильтрация запросов.

  2. API-слой на CPU-пуле:

    • Лёгкие сервисы на CPU-нодах принимают запросы от клиентов.
    • Проверяют аутентификацию (Microsoft Entra ID токены) и базовые права.
    • Превращают запросы в задания на генерацию и отправляют их в диспетчеризацию.

  3. Диспетчеризация задач — два сценария:

    Kubernetes-native:

    • API создаёт или помечает Kubernetes-объекты работы (Job, CRD и т.п.).
    • Контроллеры/очереди внутри кластера управляют допуском задач на GPU.
    • Масштабирование — через стандартный autoscaler AKS (кластерный + по нагрузке).

    Azure Service Bus + KEDA:

    • API отправляет сообщение в Azure Service Bus.
    • Воркеры/шедулеры читают очередь и создают GPU-задачи.
    • KEDA следит за глубиной очереди и масштабирует воркеры прямо по этому сигналу.

  4. GPU-пул и выполнение инференса:

    • Отдельный пул нод с GPU, помеченный лейблами и taints.
    • На ноды развёрнут NVIDIA device plugin DaemonSet — он «рассказывает» kube-scheduler, какие GPU и MIG-слайсы доступны.
    • Поды с диффузионными задачами запрашивают нужный объём GPU-ресурсов (целый GPU или долю).

  5. Хранилище моделей и результатов:

    • GPU-поды монтируют постоянное хранилище с кешем моделей Hugging Face через PV/PVC.
    • Варианты:
      • Node-local: кеш лежит прямо на ноде, минимальные задержки, но кеш не разделяется между нодами.
      • Azure Storage (Blob/другие CSI-драйверы): общий кеш для всего пула, полезен, когда скачивание моделей долгое.
    • Результаты генерации пишутся в blob-хранилище и доступны через стабильный статус API.

  6. Системный пул:

    • Отдельный пул нод для «обвязки»: Application Gateway Ingress Controller (AGIC), Secret Store CSI Driver, Blob CSI Driver, KEDA и другие аддоны.
    • Это разгружает CPU- и GPU-пулы от инфраструктурных задач.

  7. Безопасность и сеть:

    • Сертификаты для публичных доменов живут в Azure Key Vault.
    • В кластер попадают через Secrets Store CSI Driver, без перезапаковки образов.
    • Доступ к ACR, Key Vault, Blob Storage, Service Bus — через Private Endpoints и приватный DNS внутри VNet.
    • Доступ разработчиков к кластеру — через Azure Bastion, а не прямой выход в интернет.

  8. Наблюдаемость:

    • Приложения логируют запросы, job ID, задержки, ошибки. Логи и трейсинг уходят в Application Insights через OpenTelemetry.
    • Azure Monitor собирает метрики очередей (внутренних или Service Bus), активность autoscaler’а AKS или KEDA.
    • NVIDIA DCGM exporter собирает низкоуровневые метрики GPU (загрузка, память, температура), их забирает Azure Managed Prometheus, а визуализирует Azure Managed Grafana.

Логика «по полосам нагрузки»

Microsoft предлагает не сваливать всё в один пул, а разделять по «полосам» (lane):

  • Полоса приёма (admission) — CPU-ноды:

    • Аутентификация, валидация, приём запросов.
    • Никакого GPU, только быстрый API.

  • Полоса планирования (scheduling):

    • Kubernetes-native очередь + autoscaler или Service Bus + KEDA.
    • Здесь живёт логика «когда и сколько задач отправлять на GPU».

  • Полоса исполнения (execution) — GPU-пул:

    • Краткоживущие диффузионные job’ы.
    • Долго живущие воркеры, которые постоянно читают очередь и запускают инференс.

Для GPU-полосы можно ввести классы мощности: отдельные ресурсы для задач, которым нужен целый GPU, и для задач, которые нормально живут в MIG-слайсе. Это снижает риск, что один класс нагрузок забьёт всё железо.

Что это значит для вас

Когда это имеет смысл

Если вы:

  • строите собственную платформу генерации изображений/видео/мультимодальных артефактов на диффузионных моделях;
  • ожидаете скачкообразную нагрузку (маркетинговые кампании, пользовательские пики, ночные батчи);
  • хотите жёстко контролировать стоимость GPU и не переплачивать за простаивающее железо;
  • обязаны соблюдать требования по безопасности и приватности (корпоративный контур, комплаенс),

то такой паттерн на AKS даёт понятный путь:

  • Разнести API, очередь и GPU, чтобы каждая часть масштабировалась по своему сигналу.
  • Хранить модели в кеше и не тратить минуты на скачивание при каждом запуске job’а.
  • Видеть, где именно затык: в коде, в очереди, в автоскейлере или в перегретом GPU.

Для каких задач

Подходит:

  • Генерация изображений/видео по запросу пользователей (B2C и B2B-сервисы).
  • Внутренние пайплайны для дизайнеров и маркетинга, где диффузионные модели — часть большого процесса.
  • Пакетная генерация контента по спискам запросов.
  • Сервисы, которые комбинируют несколько моделей и требуют кастомной оркестрации задач (например, препроцессинг, инференс, постпроцессинг).

С осторожностью:

  • Если вам нужна только «быстрая песочница» для экспериментов, без прод-обязательств, AKS + вся эта обвязка может быть избыточна. В этом случае проще взять KAITO или AI toolchain operator add-on с готовыми пресетами.
  • Если у вас нет команды, которая понимает Kubernetes, observability и безопасность, такой стек может превратиться в чёрный ящик.

Не лучший вариант:

  • Для очень маленьких проектов, где один GPU-VM справляется с нагрузкой и нет требований по высокому SLA.
  • Если вы не можете использовать Azure (регуляторика, политика компании) — архитектуру можно перенести на другие облака концептуально, но конкретные сервисы (AKS, Service Bus, KEDA-аддон, Azure Monitor) придётся заменять.

Важный момент для России

AKS, Azure Service Bus, Azure Monitor, Application Gateway, Front Door, Key Vault, Blob Storage и остальная инфраструктура — это сервисы Microsoft Azure. Для прямого использования из России могут потребоваться юридические и сетевые обходные пути, включая VPN и зарубежные аккаунты. Это нужно учитывать при планировании.

Место на рынке

Microsoft не сравнивает эту архитектуру напрямую с конкурентами по цифрам скорости или стоимости, но по сути это ответ на типичные боли при запуске GPU-инференса в проде:

  • По уровню контроля:

    • AKS + описанный паттерн дают полный контроль над очередями, автоскейлингом, классами GPU, безопасностью и observability.
    • KAITO и AI toolchain operator add-on — более управляемые варианты внутри самого AKS, но с меньшей кастомизацией оркестрации.

  • По уровню абстракции:

    • Это не «модель как сервис», а платформа, где вы сами решаете, какие диффузионные пайплайны запускать, как шардировать GPU, как строить очереди.
    • Подходит компаниям, которые не хотят полностью зависеть от готовых API вроде GPT-4o или Claude 3.5 для генерации, а строят свой стек.

  • По масштабированию:

    • KEDA + Service Bus дают явный сигнал для масштабирования по глубине очереди. Это удобно, когда нагрузки сильно «рваные».
    • Kubernetes-native вариант проще по зависимостям и подойдёт, если профиль нагрузки уже понятен и нет требований к внешней очереди.

Прямых цифр «быстрее/дешевле, чем X» авторы не приводят. Смысл подхода — не в выигрыше в миллисекундах, а в том, чтобы платформа с GPU не разваливалась под реальной нагрузкой и оставалась управляемой.

Как запустить (концептуально)

Полных кусков кода в материале нет, но по шагам картина такая:

  1. Собрать кластер AKS с несколькими пулами:

    • System pool: аддоны (AGIC, CSI-драйверы, KEDA и т.д.).
    • CPU pool: API-сервисы и контрол-плейн приложений.
    • GPU pool: ноды с NVIDIA GPU, включённый NVIDIA device plugin DaemonSet, при необходимости MIG.

  2. Настроить ingress и edge:

    • Application Gateway + WAF.
    • (Опционально) Azure Front Door для глобального входа и failover.
    • Прописать DNS.

  3. Подключить Key Vault и секреты:

    • Развернуть Secrets Store CSI Driver.
    • Хранить TLS-сертификаты и другие секреты в Key Vault.
    • Использовать Microsoft Entra Workload ID для доступа подов к Key Vault и Blob Storage.

  4. Организовать кеш моделей:

    • Развернуть CSI-драйверы для Azure Storage.
    • Создать PV/PVC для кеша Hugging Face.
    • Настроить GPU-поды так, чтобы они монтировали этот кеш и не тянули модели каждый раз с нуля.

  5. Выбрать и реализовать диспетчеризацию:

    • Вариант 1: Kubernetes-native
      • Определить CRD/Job-объекты для задач.
      • Написать контроллер, который следит за очередью и запускает job’ы.
      • Включить autoscaler AKS.
    • Вариант 2: Service Bus + KEDA
      • Создать очередь в Azure Service Bus.
      • API-сервис пишет туда задачи.
      • Воркеры читают очередь, запускают job’ы на GPU.
      • Установить KEDA add-on и настроить скейлинг по глубине очереди.

  6. Настроить наблюдаемость:

    • Логи и трейсинг приложений → Application Insights (через OpenTelemetry).
    • Метрики очередей, автоскейлинга → Azure Monitor.
    • NVIDIA DCGM exporter → Azure Managed Prometheus → Azure Managed Grafana.

  7. Собрать CI/CD:

    • GitHub Actions с OIDC и Azure Workload Identity Federation.
    • Образы в ACR с тегами по SHA-коммита.
    • Разделение окружений (dev/stage/prod), промо по апруву.
    • Автоматические health-check и smoke-тесты после деплоя.

Дополнительно: когда лучше взять KAITO или AI toolchain operator

Если ваша главная цель — не строить свою оркестрацию диффузионных job’ов, а просто сервить поддерживаемые модели, Microsoft предлагает два варианта внутри AKS:

  • KAITO:

    • Лёгкий путь к быстрому запуску поддерживаемых пресетов моделей.
    • Подходит для экспериментов и пилотов.

  • AI toolchain operator add-on:

    • Более управляемый вариант для LLM и мультимодальных моделей.
    • Дает AKS-native-фичи по операционке без необходимости собирать всё вручную.

Оба варианта плохо подходят, если вам нужны:

  • кастомные диффузионные пайплайны;
  • тяжёлые артефактные воркфлоу с большим количеством файлов и зависимостей;
  • сложная логика диспетчеризации задач и очередей под конкретный продукт.

Главное

Запуск диффузионных моделей в продакшене — это не задача «как поднять Stable Diffusion на одной GPU-машине». Это задача платформенной инженерии с GPU в центре.

Если вы используете AKS как управляющий контур для изоляции, наблюдаемости, идентичности и повторяемых релизов, вы получаете платформу, которая выдерживает реальные нагрузки, а не только демо на конференции. Модели, рантаймы, очереди и даже edge-сервисы могут меняться, но фундамент — разделение API, очереди и GPU, внешние секреты, приватная сеть и наблюдаемость по коду и железу — остаётся тем, на чём можно долго строить.

Читайте также

#stable-diffusion#kubernetes#azure#генерация-изображений#диффузионные-модели
🔗 Источник: https://techcommunity.microsoft.com/t5/azure-architecture-blog/running-diffusion-models-at-scale-on-aks/ba-p/4513687
← Все новости