Инфраструктура и управление для ML

Под всеми пайплайнами и сервисами лежит инфраструктура, а над ними — правила управления и контроля.

Инфраструктура для ML — облачные/кластерные ресурсы (CPU/GPU, хранилища, k8s) под обучение и сервинг; governance — правила доступа, аудита и воспроизводимости моделей и данных.

Почему ML-инфраструктура особенная

ML нагружает инфраструктуру нетипично: обучение требует мощных, но временных ресурсов (GPU на часы), а сервинг — стабильных и масштабируемых. Хранилища велики (датасеты, артефакты). Поэтому ML почти всегда живёт в облаке и/или Kubernetes, где ресурсы выделяются эластично и оплачиваются по факту.

Kubernetes как фундамент

K8s даёт единый слой: контейнеры для обучения и сервинга, автоскейлинг (HPA из урока о масштабировании), управление GPU, изоляцию, перезапуск упавших подов. Поверх него ложатся Kubeflow (пайплайны), KServe/Seldon (сервинг). Если вы знаете k8s из соответствующего курса — это та же платформа, на которую MLOps опирается как на ОС для ML.

+-----------------------------------------------+
|              Kubernetes (кластер)             |
|  +-----------+  +-----------+  +-----------+   |
|  | обучение  |  |  сервинг  |  | пайплайны |   |
|  | (GPU-под) |  | (реплики) |  | (Kubeflow)|   |
|  +-----------+  +-----------+  +-----------+   |
+-----------------------------------------------+
        облако: вычисления + хранилища + сеть

GPU и эластичность

GPU дороги, поэтому их выделяют под задачу и освобождают. Облако позволяет брать spot/preemptible-инстансы для обучения (дёшево, но могут отобрать) и держать стабильные ноды под сервинг. Запросы ресурсов описывают декларативно — сколько CPU/память/GPU нужно поду.

Infrastructure as Code

Инфраструктуру описывают кодом (Terraform, манифесты k8s), а не кликами в консоли. Это даёт воспроизводимость окружения (часть lineage), ревью изменений и быстрый разворот «с нуля». Без IaC «как настроен прод» живёт в чьей-то голове.

resources:
  requests:
    cpu: "2"
    memory: "4Gi"
    nvidia.com/gpu: "1"
  limits:
    nvidia.com/gpu: "1"

Governance: управление и контроль

Когда моделей много и они принимают важные решения, нужны правила:

• Доступ. Кто может обучать, регистрировать, выкатывать модель (роли, RBAC).
• Аудит. Кто и когда повысил версию в Production — журнал переходов в реестре.
• Воспроизводимость и lineage. Для любой прод-модели восстановим путь до данных и кода.
• Соответствие. Приватность данных (152-ФЗ, GDPR), документирование моделей (model cards), право на объяснение.

152-ФЗ и расположение данных

Для российских пользователей персональные данные должны храниться и обрабатываться на серверах в РФ. Это прямое требование к инфраструктуре MLOps: обучение и хранение персональных данных размещают в российском облаке/ЦОД, а логи инференса с PII маскируют. Governance — это не бюрократия, а защита от штрафов и инцидентов.

Как работает под капотом

Облачный провайдер даёт API на ресурсы; Kubernetes абстрагирует их в поды, сервисы и тома. Контроллеры k8s держат заявленное состояние (нужно 3 реплики — поддерживает 3), а планировщик распределяет поды по нодам с учётом запросов на GPU/память. Governance реализуется как слой политик: RBAC ограничивает действия, реестр ведёт аудит переходов, IaC и трекинг обеспечивают lineage. Вместе это превращает «кучу скриптов на GPU» в управляемую платформу.

Частые ошибки

• Настраивать прод руками (без IaC). Невоспроизводимо и не ревьюится.
• Держать GPU занятым простаивая. Не освобождать ускорители после обучения — прямые потери денег.
• Отсутствие RBAC. Любой может выкатить модель в прод — путь к инцидентам.
• Игнорировать локализацию данных. Нарушение 152-ФЗ/GDPR грозит штрафами.

Итог

• ML живёт в облаке и Kubernetes: эластичные GPU под обучение, масштабируемые реплики под сервинг.
• Инфраструктуру описывают кодом (IaC) ради воспроизводимости, ревью и быстрого разворота.
• Governance (доступ, аудит, lineage, локализация данных) превращает набор скриптов в управляемую, соответствующую закону платформу.