Модуль 3.8: AI/ML у хмарній нативній інфраструктурі

Складність: [MEDIUM] - Концептуальна обізнаність

Час на виконання: 25-30 хвилин

Передумови: Модуль 3.1 (Хмарні нативні принципи), Модуль 3.3 (Хмарні нативні патерни)

Що ви зможете робити

Після завершення цього модуля ви зможете:

Пояснити чому Kubernetes є домінуючою платформою для навантажень AI/ML
Визначити ключові інструменти екосистеми ML на Kubernetes: Kubeflow, KServe та планування GPU
Порівняти вимоги до навантажень навчання та виведення та їхні шаблони ресурсів Kubernetes
Оцінити як планування та керування ресурсами Kubernetes підтримують навантаження GPU та TPU

Чому цей модуль важливий

Навантаження штучного інтелекту та машинного навчання швидко стають найбільшими споживачами хмарної інфраструктури. Kubernetes перетворюється на “операційну систему для AI” — не тому, що він був для цього спроектований, а тому, що його розширюваність, планування та управління ресурсами роблять його природною платформою. KCNA очікує, що ви розумієте, як AI/ML перетинається з cloud native.

Kubernetes як платформа AI/ML

┌─────────────────────────────────────────────────────────────┐
│              ЧОМУ K8S ДЛЯ AI/ML?                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Kubernetes надає те, що потрібно AI/ML навантаженням:      │
│                                                             │
│  1. ПЛАНУВАННЯ GPU                                         │
│     ─────────────────────────────────────────────────────   │
│     K8s планує GPU як CPU/памʼять — запитайте їх,          │
│     планувальник розмістить ваш Pod на вузлі, що їх має    │
│                                                             │
│  2. ПЛАГІНИ ПРИСТРОЇВ                                      │
│     ─────────────────────────────────────────────────────   │
│     Розширюють K8s для управління спеціалізованим          │
│     обладнанням:                                           │
│     • NVIDIA GPUs (nvidia.com/gpu)                         │
│     • AMD GPUs, Intel FPGAs, Google TPUs                   │
│     • Будь-який прискорювач через device plugin framework  │
│                                                             │
│  3. ПАКЕТНА ОБРОБКА                                        │
│     ─────────────────────────────────────────────────────   │
│     Jobs та CronJobs обробляють тренувальні запуски, що    │
│     завершуються (на відміну від вебсерверів, що працюють  │
│     постійно)                                              │
│                                                             │
│  4. АВТОМАСШТАБУВАННЯ                                      │
│     ─────────────────────────────────────────────────────   │
│     Масштабуйте endpointʼи інференсу вгору/вниз            │
│     на основі трафіку. Масштабуйте до нуля коли немає     │
│     запитів                                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ресурси GPU у Kubernetes

GPU розглядаються як розширені ресурси. Pod запитує їх так само, як CPU або памʼять:

resources:
  limits:
    nvidia.com/gpu: 1   # Запит одного NVIDIA GPU

Ключові концепції на рівні KCNA:

Концепція	Що це означає
Device Plugin	DaemonSet, що оголошує обладнання (GPU) для kubelet
nvidia.com/gpu	Назва ресурсу для NVIDIA GPU у K8s
GPU time-slicing	Спільне використання одного фізичного GPU кількома Podʼами (без повної ізоляції)
MIG (Multi-Instance GPU)	Апаратне розділення GPU на NVIDIA A100/H100
Цілий GPU	Один Pod отримує ексклюзивний доступ до одного GPU (найпростіша модель)

Ключовий висновок: GPU є нестискувані ресурси. На відміну від CPU (який можна обмежити), якщо Pod потребує GPU і жоден не доступний, він залишається у стані Pending поки один не звільниться.

Патерни навантажень AI/ML

┌─────────────────────────────────────────────────────────────┐
│              ТИПИ НАВАНТАЖЕНЬ AI/ML                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ТРЕНУВАННЯ                                                │
│  ─────────────────────────────────────────────────────────  │
│  • Працює годинами/днями/тижнями                           │
│  • Потребує багато GPU (розподілених між вузлами)           │
│  • Пакетне навантаження — працює потім завершується         │
│  • Gang scheduling: усі воркери запускаються разом або     │
│    жоден                                                   │
│                                                             │
│  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐                          │
│  │GPU 0│ │GPU 1│ │GPU 2│ │GPU 3│  ← Розподілене           │
│  │Node1│ │Node1│ │Node2│ │Node2│    тренування             │
│  └─────┘ └─────┘ └─────┘ └─────┘    між вузлами           │
│                                                             │
│  ІНФЕРЕНС (ОБСЛУГОВУВАННЯ)                                 │
│  ─────────────────────────────────────────────────────────  │
│  • Працює постійно, обслуговує передбачення                │
│  • Чутливий до затримок (користувачі чекають)              │
│  • Потребує автомасштабування на основі обсягу запитів     │
│  • Часто 1 GPU на репліку достатньо                        │
│                                                             │
│  Запит → [Model Server] → Передбачення                     │
│          [Model Server] → (автомасштабовані репліки)        │
│          [Model Server]                                     │
│                                                             │
│  ДОТРЕНУВАННЯ (FINE-TUNING)                                │
│  ─────────────────────────────────────────────────────────  │
│  • Взяти попередньо натреновану модель, адаптувати         │
│    до ваших даних                                          │
│  • Коротше за повне тренування, менше GPU                  │
│  • Дедалі популярніше з LLM (LoRA, QLoRA)                 │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Порівняння тренування та інференсу

Аспект	Тренування	Інференс
Тривалість	Години — тижні	Постійний
Кількість GPU	Багато (розподілено)	Менше на репліку
Патерн	Пакетний Job	Довготривалий Deployment
Масштабування	Фіксоване під час запуску	Автомасштабування з трафіком
Пріоритет	Пропускна здатність	Затримка
Обробка збоїв	Чекпоінтинг + перезапуск	Load balancer перенаправляє

Інференс LLM на Kubernetes

Запуск великих мовних моделей на власному кластері Kubernetes — тренд, що зростає. Ось чому організації це роблять:

┌─────────────────────────────────────────────────────────────┐
│              ЧОМУ САМОСТІЙНИЙ ХОСТИНГ LLM?                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ПРИВАТНІСТЬ    Дані не покидають вашу інфраструктуру      │
│  ВАРТІСТЬ       Без оплати за токен у масштабі             │
│  ЗАТРИМКА       Розміщення моделі поруч із застосунком     │
│  ВІДПОВІДНІСТЬ  Виконання вимог щодо резиденції даних      │
│  КОНТРОЛЬ       Вибір моделі, версії та конфігурації       │
│                                                             │
│  Компроміс: Ви управляєте GPU, масштабуванням та          │
│  оновленнями моделі                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ключові інструменти (рівень обізнаності)

Вам не потрібно знати, як встановлювати або налаштовувати ці інструменти для KCNA. Знайте що вони роблять та коли б ви їх використали.

Інструмент	Що він робить	Статус CNCF
Kubeflow	Повна платформа ML на K8s: пайплайни, ноутбуки, тренування, обслуговування	CNCF Incubating
KServe	Стандартизоване обслуговування інференсу на K8s — з автомасштабуванням, canary розгортаннями	Частина екосистеми Kubeflow
Ray	Фреймворк розподілених обчислень — популярний для тренування та обслуговування у масштабі	Не CNCF (Anyscale)
vLLM	Високопропускний рушій інференсу LLM — оптимізований для обслуговування великих мовних моделей	Відкритий код (UC Berkeley)
NVIDIA GPU Operator	Автоматизує налаштування драйверів GPU та device plugin на вузлах K8s	Відкритий код NVIDIA
Volcano	Система пакетного планування для K8s — gang scheduling, справедливе розділення черги для AI/ML завдань	CNCF Incubating

┌─────────────────────────────────────────────────────────────┐
│              ML ПАЙПЛАЙН НА KUBERNETES                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Підготовка → Тренування → Оцінка → Обслугов. → Моніторинг│
│  даних          │            │         │           │       │
│  [Spark/    [Kubeflow    [Автомат.  [KServe   [Prometheus │
│   Argo]     Training]    тести]    /vLLM]    + власні]    │
│                                                             │
│  Все працює як Podʼи на Kubernetes                        │
│  Все управляється через K8s API                           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

GPU коштують більше, ніж решта кластера разом — Один вузол NVIDIA H100 GPU може коштувати $30,000+, що робить планування та використання GPU найдорожчою проблемою управління ресурсами в Kubernetes. Витрата 10% часу GPU набагато дорожча за витрату 10% CPU.
Gang scheduling не існує в стандартному Kubernetes — Стандартний kube-scheduler розміщує Podʼи по одному. Розподілене тренування потребує, щоб усі воркери запускались разом (gang scheduling), що вимагає доповнень як Volcano або Coscheduling. Без цього можна отримати deadlock, де половина воркерів запуститься і вічно чекатиме іншу половину.
vLLM може обслуговувати моделі у 24 рази швидше за наївні підходи — Використовуючи PagedAttention (управління памʼяттю GPU як ОС управляє віртуальною памʼяттю), vLLM суттєво покращує пропускну здатність для обслуговування LLM. Тому він став типовим рушієм обслуговування для багатьох розгортань LLM на K8s.

Поширені помилки

Помилка	Чому це шкодить	Правильне розуміння
Думати що K8s нативно підтримує GPU	GPU потребують встановлення device plugins	NVIDIA device plugin (DaemonSet) повинен бути розгорнутий для надання GPU у K8s
Використовувати Deployments для тренування	Тренування завершується — Deployments перезапускаються назавжди	Використовуйте Jobs або спеціалізовані оператори тренування (PyTorchJob, TFJob)
Один GPU на кластер = достатньо	Тренування LLM потребує багато GPU паралельно	Великі моделі потребують розподіленого тренування на десятках або сотнях GPU
Ігнорувати памʼять GPU (VRAM)	Моделі що не вміщуються в VRAM падають	Модель з 70B параметрів потребує ~140GB VRAM — більше, ніж один GPU має
Ставитись до інференсу як до пакетного завдання	Користувачі очікують низьку затримку	Використовуйте Deployments з автомасштабуванням, не Jobs, для endpointʼів інференсу

Тест

1. Який основний механізм Kubernetes використовує для управління ресурсами GPU?

A) Вбудований планувальник GPU B) Плагіни пристроїв, що оголошують GPU для kubelet C) Спеціальний простір імен GPU D) Автоматичне виявлення GPU середовищем виконання контейнерів

Відповідь

B) Плагіни пристроїв, що оголошують GPU для kubelet. Фреймворк device plugin дозволяє постачальникам (як NVIDIA) реєструвати апаратні ресурси в kubelet, який потім повідомляє про них планувальнику. GPU не вбудовані в ядро K8s.

2. Що таке gang scheduling у контексті навантажень AI/ML?

A) Планування Podʼів на якомога більше вузлів B) Запуск усіх воркерів розподіленого завдання разом або жодного C) Призначення кількох GPU одному Pod D) Планування запитів інференсу пакетами

Відповідь

B) Запуск усіх воркерів розподіленого завдання разом або жодного. Розподілене тренування вимагає комунікації всіх воркерів. Якщо лише половина запуститься, вони витрачають ресурси GPU очікуючи. Gang scheduling забезпечує запуск усієї групи разом.

3. Який інструмент є CNCF Incubating проєктом для наскрізних ML пайплайнів на Kubernetes?

A) vLLM B) Ray C) Kubeflow D) TensorFlow

Відповідь

C) Kubeflow. Kubeflow є CNCF Incubating проєктом, що надає ML пайплайни, оператори тренування, ноутбуки та можливості обслуговування на Kubernetes. vLLM та Ray не є проєктами CNCF; TensorFlow — це фреймворк ML, а не платформа K8s.

4. Чому організації запускають інференс LLM на власних кластерах Kubernetes замість використання хмарних API?

A) Це завжди дешевше за хмарні API B) Приватність, затримка, відповідність та контроль витрат у масштабі C) Хмарні API не підтримують великі моделі D) Kubernetes необхідний для запуску LLM

Відповідь

B) Приватність, затримка, відповідність та контроль витрат у масштабі. Самостійний хостинг зберігає дані у вашій інфраструктурі, зменшує вартість за токен при великих обсягах та відповідає вимогам резиденції даних. Це не завжди дешевше (особливо при малих обсягах), і хмарні API підтримують великі моделі.

5. Який тип ресурсу Kubernetes найбільш підходить для завдання тренування моделі, що працює 8 годин і потім завершується?

A) Deployment B) DaemonSet C) Job D) StatefulSet

Відповідь

C) Job. Тренування — це пакетне навантаження, що працює до завершення. Jobs призначені для цього — вони відстежують завершення та не перезапускають Podʼи після успіху. Deployments тримають Podʼи запущеними нескінченно, що витрачає ресурси після завершення тренування.

6. Що таке GPU time-slicing?

A) Розділення памʼяті GPU на ізольовані апаратні розділи B) Спільне використання одного GPU кількома Podʼами шляхом почергового доступу в часі C) Запуск GPU навантажень лише у непікові години D) Планування GPU між різними часовими зонами

Відповідь

B) Спільне використання одного GPU кількома Podʼами шляхом почергового доступу в часі. Time-slicing дозволяє кільком Podʼам ділити один GPU, чергуючись, покращуючи використання для легковагових навантажень. Він не забезпечує ізоляцію памʼяті — для цього потрібен апаратний MIG (Multi-Instance GPU).

Підсумок

Kubernetes стає стандартною платформою для AI/ML завдяки плануванню, розширюваності (device plugins) та автомасштабуванню
Ресурси GPU управляються через device plugins (наприклад, nvidia.com/gpu) — вони не вбудовані в ядро K8s
Тренування = пакетне, розподілене, багато GPU, потрібен gang scheduling
Інференс = постійний, чутливий до затримок, автомасштабований, менше GPU на репліку
Дотренування = адаптація попередньо натренованих моделей, менш ресурсоємне за повне тренування
Ключова екосистема: Kubeflow (CNCF, повна платформа), KServe (обслуговування), vLLM (інференс LLM), Ray (розподілені обчислення), Volcano (пакетне планування)
Самостійний інференс LLM обумовлений приватністю, вартістю, затримкою та відповідністю

Наступний модуль

Модуль 3.9: WebAssembly та Cloud Native - Технологія, що може доповнити (або іноді замінити) контейнери.