Дефіцит GPU у вашій власній інфраструктурі: чому ШІ-навантаження стоять у черзі, тоді як потужності простоюють
Використання GPU показує обчислювальну активність, а не те, чи справді доступна ємність. GPU може повідомляти про низьке використання, залишаючись повністю виділеним під одне робоче навантаження. У цій публікації пояснюється, чому робочі навантаження стають у чергу поруч із GPU, які виглядають простоюючими, як на це впливають виділення ресурсів, пам’ять, розміщення та вузькі місця застосунків, а також чим відрізняються методи спільного використання GPU за своїми компромісами.
Коротко:
Робочі навантаження ШІ можуть чекати на GPU, навіть коли моніторинг показує відсутність обчислювальної активності. GPU з низькою обчислювальною активністю не обов’язково має доступну ємність для іншого робочого навантаження, оскільки правила виділення ресурсів, вимоги до пам’яті, апаратна сумісність, ізоляція та обмеження розміщення визначають, що саме може бути запущено. У публікації слід пояснити, як відрізнити реальний дефіцит апаратних ресурсів від вузького місця, пов’язаного з виділенням ресурсів, розміщенням або застосунком. Використайте показник середнього використання GPU на рівні 5% із звіту Cast AI за 2026 рік як дослідницьку відправну точку, але не створюйте враження, ніби робочі навантаження в черзі та простоюючі GPU спостерігалися одночасно в тих самих вимірюваних середовищах, або ніби 95% ємності GPU можна негайно повернути в користування.
Ключові висновки
- Метрики використання GPU вимірюють обчислювальну активність, а не стан виділення ресурсів. GPU, який повідомляє про 5% обчислювального використання, усе ще може бути повністю виділеним із нульовою ємністю для нових робочих навантажень.
- Kubernetes за замовчуванням призначає подам цілі GPU. Одне робоче навантаження, що утримує пристрій, блокує всі інші, незалежно від того, наскільки активно воно фактично використовує GPU.
- Робочі навантаження можуть ставати в чергу поруч із GPU, які виглядають простоюючими, щонайменше з чотирьох різних причин. Лише одну з них можна усунути за допомогою спільного використання GPU.
- Часове розподілення, MIG і MPS мають різні компроміси щодо ізоляції пам’яті, апаратних вимог, спостережуваності та підтримки хмарними провайдерами. Жоден метод не підходить для всіх робочих навантажень.
- Важлива послідовність діагностики: спочатку перевірте стан виділення ресурсів, потім зайнятість пам’яті, далі обмеження розміщення і лише після цього — вузькі місця застосунку. Саме в такому порядку.
- Cast AI підтримує всі три методи спільного використання з автоматичним bin-packing і без змін у маніфестах робочих навантажень.
Що показує використання GPU і чого воно не показує
Термін «використання GPU» охоплює щонайменше чотири різні вимірювання, і змішування цих понять — найшвидший шлях до неправильної діагностики. Більшість інформаційних панелей показують обчислювальне використання: відсоток потокових мультипроцесорів (SM), активних у певному часовому вікні. Це число показує, наскільки завантажений кремній під час роботи. Воно нічого не говорить про те, чи доступний пристрій для нового робочого навантаження.
Модель, завантажена у VRAM, безперервно займає цю пам’ять. Сервіс інференсу може обробляти один запит на хвилину, підтримуючи обчислювальну активність на рівні 5%, але пристрій виділений, пам’ять зайнята, і Kubernetes не запланує на ньому нічого іншого. З точки зору планувальника цей GPU недоступний. На інформаційній панелі моніторингу він виглядає майже простоюючим.
У таблиці нижче розділено чотири метрики, які зазвичай об’єднують під назвою «використання GPU», і пояснено, що кожна з них показує, а чого не показує.
| Метрика | Що вона вимірює | Чого вона НЕ показує |
| Обчислювальна активність (%SM) | Частка потокових мультипроцесорів, активних протягом вікна вимірювання | Чи виділений GPU; чи доступна VRAM для іншого робочого навантаження |
| Зайнятість пам’яті (VRAM) | Обсяг пам’яті GPU, спожитий завантаженими моделями та тензорами | Обчислювальну активність; чи можуть робочі навантаження в черзі поміститися в доступну пам’ять |
| Час очікування в черзі (планування подів) | Скільки часу поди в стані очікування чекають, перш ніж пристрій GPU стане доступним | Чи спричинена затримка виділенням ресурсів, пам’яттю, розміщенням або вузьким місцем застосунку |
| Пропускна здатність / затримка | Кількість запитів, оброблених за секунду; час до першого токена або повний час відповіді | Використання ресурсів GPU або ефективність їхнього виділення |
Звіт Cast AI про оптимізацію Kubernetes за 2026 рік, у якому проаналізовано десятки тисяч продуктивних кластерів із січня 2025 року до квітня 2026 року, зафіксував середнє обчислювальне використання GPU на рівні 5% до застосування будь-якої оптимізації. У супровідній публікації у блозі звіту зазначено, що один кластер із набору даних підтримував використання GPU на рівні 49% на 136 H200; цей розрив описано як такий, що майже повністю пояснюється методикою, а не апаратним забезпеченням. Середнє значення 5% відображає реальну загальнофлотську тенденцію надмірного резервування та недостатнього використання. Воно не означає, що 95% ємності вільні для прийому нових робочих навантажень. Перш ніж робити такий висновок, кожен кластер і кожен GPU у ньому потребують окремої діагностики.
Чотири причини, через які робочі навантаження можуть ставати в чергу поруч із вільною ємністю GPU
Планувальник Kubernetes сприймає GPU як доступний або недоступний. Він визначає це на основі кількості ресурсу nvidia.com/gpu на кожному вузлі, а не на основі відсотка активного кремнію. Чотири різні умови можуть спричинити чергу, навіть коли обчислювальна активність виглядає низькою.
Робоче навантаження утримує весь пристрій
Плагін пристроїв NVIDIA для Kubernetes за замовчуванням виділяє GPU виключно. Коли под запитує nvidia.com/gpu: 1, він отримує одноосібне володіння одним фізичним пристроєм на весь час свого життєвого циклу. Жоден інший под не може використовувати цей пристрій, незалежно від того, скільки обчислювальних ресурсів або пам’яті фактично споживає робоче навантаження, що його займає.
Це найпоширеніша причина ситуації, коли черга утворюється поруч із GPU, що виглядають простоюючими, у кластерах інференсу. Набір моделей, кожна з яких утримує виділений GPU, але обробляє нерегулярні або нечасті запити, залишає всі пристрої виділеними. Нове робоче навантаження бачить на вузлі nvidia.com/gpu: 0 доступних і чекає, хоча сукупна обчислювальна активність на вузлі може бути нижчою за 10%.
Плагін пристроїв зосереджений на виділенні ресурсів, а не на поверненні простоюючих ресурсів у пул. Cluster Autoscaler Kubernetes може підготувати нові вузли, але не повертає невикористану ємність на наявних. Проблема знаходиться на рівні планування, і її вирішення потребує зміни способу представлення пристроїв планувальнику. Саме це роблять механізми спільного використання GPU.
Пам’ять зайнята, а не просто недостатньо використовується
Низьке обчислювальне використання не означає, що пам’ять доступна. Два сценарії ілюструють цей діапазон. Модель із 70 мільярдами параметрів, завантажена у FP16, споживає приблизно 140 ГБ VRAM (лише базові ваги; за довжини контексту 4K кеш KV додає 15–20% понад базові ваги, тоді як за довжини контексту 128K вимоги до кешу KV можуть повністю перевищувати обсяг базових ваг). Для завантаження такої моделі потрібно щонайменше два GPU A100 80GB. Модель 13B у FP16 займає приблизно 26 ГБ і поміщається на одному A100 80GB, але все одно постійно утримує цю VRAM. Обчислювальне використання може становити 8%, оскільки більшість запитів обробляється швидко, але пристрій не може прийняти інше робоче навантаження.
Перш ніж налаштовувати спільне використання, перевірте, чи можна застосувати квантування. Квантизована в INT4 модель 7B займає приблизно 4 ГБ проти приблизно 14 ГБ у FP16, що змінює розрахунок спільного розміщення для конфігурацій із часовим розподіленням і MIG. INT8 приблизно вдвічі зменшує вимоги порівняно з FP16, часто забезпечуючи прийнятний компроміс щодо якості для робочих навантажень інференсу.
Це особливо важливо для команд, які розглядають часове розподілення як рішення. Часове розподілення мультиплексує доступ до обчислень, але не розділяє пам’ять. Усі репліки спільно використовують один адресний простір VRAM. Якщо два робочі навантаження разом перевищують обсяг пам’яті пристрою, вони не зможуть безпечно співіснувати. Діагностика обмеження пам’яті перед вибором методу спільного використання допомагає уникнути невдалого розгортання та потенційної нестабільності робочих навантажень.
Перевірте зайнятість пам’яті за допомогою nvidia-smi, перш ніж припускати, що певний підхід до спільного використання допоможе. Якщо стовпчик вільної пам’яті на відповідних пристроях близький до нуля, обмеженням є ємність VRAM, а не планування обчислень. MIG забезпечує апаратно ізольовані розділи пам’яті, які можуть усунути певні варіанти цієї проблеми, але потребує сумісного обладнання та змінює спосіб планування робочих навантажень.
Правила розміщення виключають обладнання, яке інакше можна було б використати
Робоче навантаження може не заплануватися не через повністю виділені GPU, а тому, що планувальник не може знайти вузол, який одночасно відповідає всім обмеженням розміщення. Правила спорідненості вузлів, що вимагають певної моделі або покоління GPU, обмеження розподілення топології, які вимагають мінімальної кількості вузлів, і taints без відповідних tolerations можуть перешкодити плануванню, навіть коли необроблені лічильники пристроїв виглядають достатніми.
Запит nvidia.com/gpu: 1 із селектором вузла, що вимагає A100, не буде розміщено на вузлі лише з H100, навіть якщо ці H100 простоюють і здатні виконати завдання. Так само робоче навантаження, яке запитує більше часових реплік, ніж може надати будь-який окремий вузол, без розподілення між вузлами може повністю не заплануватися, попри наявність сукупної ємності у флоті.
Діагностична команда тут — kubectl describe pod <pending-pod>. Перевірте розділ Events на наявність таких причин, як MatchNodeSelector, InsufficientResource або TaintToleration. Проблеми розміщення часто виглядають як дефіцит ємності та усуваються налаштуванням планування, а не придбанням нового обладнання.
Запущене робоче навантаження очікує на щось інше
Не кожне низьке показання обчислювального використання свідчить про проблему з виділенням ресурсів. GPU простоює під час попередньої обробки на CPU, завантаження даних, передавання через PCIe та мережевих обмінів. Сервер інференсу LLM, який очікує повільної токенізації або отримання кешу KV із віддаленого сховища, показуватиме низьку активність %SM, але GPU не доступний для інференсу запитів іншого робочого навантаження. Він заблокований на іншому рівні.
Цю категорію найважче діагностувати лише за метриками GPU. Стабільно низьке обчислювальне використання активного запланованого робочого навантаження зазвичай вказує на вузьке місце поза GPU. Збільшення кількості GPU не допоможе. Рішення передбачають збільшення ресурсів CPU, коригування налаштувань пакетування, скорочення затримки сховища або перебудову конвеєра даних.
Використовуйте nvidia-smi dmon або метрики DCGM, щоб спостерігати за обчислювальним використанням у часі. Робоче навантаження, яке циклічно переходить від 0% до високого обчислювального використання короткими імпульсами, імовірно, обмежене CPU у періоди 0%. Якщо робоче навантаження постійно демонструє низьке обчислювальне використання, активно отримуючи запити, імовірно, воно очікує на введення-виведення або мережу. Обидва сценарії відрізняються від дефіциту виділення ресурсів і потребують інших способів усунення.
Приклад виділення GPU у Kubernetes
Наведений нижче сценарій є гіпотетичним і створений для ілюстрації проблеми виділення ресурсів. Він не відображає виміряну продуктивність конкретного кластера.
Розглянемо вузол із чотирма GPU, кожен із яких виключно виділений одному сервісу інференсу. Кожен сервіс обробляє нерегулярні запити студентів: пікова обчислювальна активність у періоди навантаження становить 15%, а в непікові години — менше 3%. П’ятий сервіс інференсу розгортається та переходить у стан Pending. Планувальник виявляє, що на вузлі доступно nvidia.com/gpu: 0, і ставить под у чергу.
| Конфігурація | GPU на вузлі | Запущені сервіси | Пікова обчислювальна активність | Стан п’ятого сервісу |
| Поточна: виділення окремих GPU | 4 | 4 (по одному на GPU) | ~15% на пристрій | Pending: пристрої недоступні |
| Потенційна: часове розподілення (по 4 репліки кожного) | 4 | До 16 (по чотири на GPU) | Залежить від перекриття запитів | Може бути запланований за умови відповідності VRAM |
Перехід до часового розподілення не гарантує конкретного підвищення пропускної здатності. Він змінює доступність пристроїв з точки зору планувальника. Тепер кожен GPU оголошує чотири слоти замість одного. П’ятий сервіс може бути запланований. Чи покращиться, чи погіршиться загальна затримка, залежить від того, наскільки часто запити сервісів перекриваються, скільки VRAM займає кожна модель і чи демонструє якась модель імпульсну активність SM, що створює конкуренцію в пікові періоди.
Єдиний спосіб дізнатися відповідь для конкретної суміші робочих навантажень — протестувати її. У наступних діагностичних кроках описано, як це зробити, не переходячи одразу до конфігурації, яка може погіршити затримку в продуктивному середовищі.
Порівняння виділених GPU, часового розподілення, MIG і MPS
Для робочих навантажень GPU у Kubernetes існує чотири моделі виділення ресурсів. Кожна вирішує окремий варіант проблеми спільного використання, і кожна має обмеження, які визначають її придатність для конкретного робочого навантаження. Жоден підхід не є універсально правильним.
| Підхід | Модель виділення | Ізоляція пам’яті | Апаратні вимоги | Придатність для робочих навантажень | Ключовий компроміс |
| Виділення окремого GPU | Один под, один GPU, виключний доступ | Повна ізоляція | Будь-який GPU NVIDIA | Великі моделі; багат GPU-навчання; критичний до затримки інференс, якому потрібна повна пропускна здатність пристрою | Максимальна ізоляція; відсутність спільного використання; втрата ємності для переривчастих або низьковикористовуваних робочих навантажень |
| Часове розподілення | Часове мультиплексування; N реплік спільно використовують один фізичний GPU | Відсутня: усі репліки спільно використовують повний адресний простір VRAM | Будь-який GPU NVIDIA; працює на V100, T4 і старіших поколіннях | Малі моделі; переривчастий інференс; пакетні завдання зі змінним попитом | Немає ізоляції пам’яті або відмов; DCGM-Exporter не може пов’язати метрики з контейнерами; ризик конкуренції за VRAM під час одночасного навантаження |
| MIG (Multi-Instance GPU) | Апаратне розділення на до 7 ізольованих екземплярів на фізичний GPU | Апаратно ізольовані шляхи пам’яті: окремі банки кешу L2, контролери пам’яті та шини DRAM для кожного екземпляра | Лише архітектура Ampere та новіші: A100, A30, H100, H200, Blackwell (B200, GB200). Недоступний на T4, V100 або A10. | Багатокористувацький інференс; робочі навантаження, яким потрібні гарантії QoS; обслуговування моделей різного розміру | Фіксовані профілі, які не можна динамічно змінювати; NVLink між екземплярами не підтримується; потрібні ввімкнення режиму MIG і скидання GPU |
| MPS (Multi-Process Service) | Одночасне виконання процесів CUDA; кілька процесів спільно використовують SM | У базовій конфігурації ізоляція пам’яті відсутня. MPS із розділенням SM (доступне від CUDA 11.0) додає налаштовувані розділи SM і пам’яті для кожного простору імен; Volta та новіші додають ізоляцію на рівні процесів. Фізична пам’ять залишається спільною в усіх конфігураціях. | Будь-який GPU NVIDIA із підтримкою CUDA. Cast AI MPS наразі доступний у GCP GKE; підтримка AWS і Asure запланована. | Спільно розміщені робочі навантаження, які можуть спільно використовувати виконання; пакетний інференс із нижчим рівнем ізоляції | Одночасне виконання, а не часове чергування; менші накладні витрати на перемикання контекстів; для жорстких бюджетів пам’яті на робоче навантаження слід оцінити MIG |
Часове розподілення працює на будь-якому GPU NVIDIA, зокрема на старіших поколіннях T4 і V100, які не підтримують MIG. У документації NVIDIA GPU Operator щодо часового розподілення прямо зазначено, що між репліками немає ізоляції пам’яті або відмов. Робоче навантаження, яке вичерпує VRAM або аварійно завершує контекст CUDA, може вплинути на всі робочі навантаження, заплановані на тому самому пристрої. Це обмеження робить часове розподілення придатним лише для робочих навантажень, сумарний обсяг пам’яті яких комфортно поміщається у VRAM пристрою.
MIG забезпечує найсильнішу гарантію ізоляції серед трьох методів спільного використання. Кожен розділ має фізично окремі шляхи через систему пам’яті, зокрема порти внутрішньочипового перехресного комутатора, банки кешу L2, контролери пам’яті та адресні шини DRAM. Вичерпання кешу одним екземпляром не може вплинути на затримку іншого. Посібник користувача NVIDIA MIG описує до семи екземплярів на фізичний GPU з фіксованими профілями, які визначають розподіл обчислень і пам’яті для кожного розділу. Ці профілі не можна динамічно змінювати під час роботи, тому рішення про розділення приймається під час конфігурації.
Одне обмеження має особливе значення для розподілених робочих процесів навчання: NVLink не підтримується між екземплярами MIG. Команди, які запускають багат GPU-завдання навчання та покладаються на високошвидкісний обмін даними між GPU, не повинні розглядати MIG як готовий до використання варіант спільного доступу для таких робочих навантажень.
MPS відрізняється від обох цих методів. Якщо часове розподілення перемикається між контекстами CUDA з часом, MPS дає змогу кільком процесам CUDA одночасно виконуватися на тих самих потокових мультипроцесорах. Документація NVIDIA MPS описує цю архітектуру як легковагове середовище виконання: керівний демон, серверний процес і клієнтську бібліотеку, вбудовану в libcuda.so. MPS із розділенням SM (доступне від CUDA 11.0) додає налаштовувані розділи SM і пам’яті для кожного простору імен, забезпечуючи більше ізоляції, ніж базове часове розподілення, без потреби в обладнанні, сумісному з MIG. Архітектура Volta та новіші додають ізоляцію відмов на рівні процесів; фізична пам’ять залишається спільною в усіх конфігураціях MPS.
Cast AI підтримує поєднання MIG і часового розподілення. Один A100, розділений на сім екземплярів MIG, кожен із чотирма репліками часового розподілення, представляє планувальнику Kubernetes 28 логічних слотів GPU з одного фізичного пристрою. Це конфігурація високої щільності, яка потребує ретельного профілювання робочих навантажень перед розгортанням, але цей розрахунок ілюструє, чому вибір методу спільного використання не менш важливий, ніж придбання обладнання.
Діагностуйте вузьке місце, перш ніж замовляти більше GPU
Наведена нижче послідовність проходить через чотири категорії вузьких місць — від найменш до найбільш складної. Зупиніться, щойно знайдете активне обмеження. Наступні кроки лише створять зайвий шум.
Крок 1: Перевірте стан виділення ресурсів на всіх вузлах. Виконайте:
kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.’nvidia\.com/gpu’
Якщо всі вузли показують 0 доступних GPU, а робочі навантаження стоять у черзі, ви маєте дефіцит виділення ресурсів. Відповідним класом рішень є спільне використання GPU. Якщо деякі вузли показують доступні слоти GPU, але робочі навантаження все одно стоять у черзі, перейдіть до кроку 3 і перевірте обмеження розміщення.
Крок 2: Перевірте зайнятість пам’яті на виділених пристроях. Виконайте nvidia-smi на вузлах, де обчислювальна активність низька, але пристрої повністю виділені. Порівняйте стовпчик використаної пам’яті із загальним обсягом пам’яті для кожного пристрою. Низький %SM у поєднанні з майже нульовою вільною пам’яттю означає, що обмеженням є VRAM, а не обчислення. Часове розподілення тут не допоможе. Відповідним шляхом є розділення пам’яті за допомогою MIG або MPS із розділенням SM — з урахуванням сумісності обладнання та провайдера.
Крок 3: Перевірте події подів у стані очікування на наявність проблем із розміщенням. Виконайте:
kubectl describe pod <pending-pod-name>
У розділі Events знайдіть причини невдалого планування: MatchNodeSelector, InsufficientResource або TaintToleration. Якщо правила розміщення не дають робочому навантаженню потрапити на доступні GPU, виправлення полягає в налаштуванні планування. Придбання обладнання проблему не вирішить.
Крок 4: Спостерігайте за обчислювальною активністю запущених робочих навантажень у часі. Використовуйте nvidia-smi dmon -s u або метрики DCGM, щоб зібрати часовий ряд протягом репрезентативного періоду обробки запитів. Якщо %SM короткими імпульсами циклічно змінюється від 0 до високих значень, імовірно, у періоди 0% робоче навантаження обмежене CPU. Якщо %SM залишається стабільно низьким, поки робоче навантаження активно отримує запити, підозрюйте завантаження даних, передавання через PCIe або затримку кешу KV. Обидва сценарії відрізняються від дефіциту виділення ресурсів.
Крок 5: Перевірте сумісність обладнання та провайдера з передбачуваним методом спільного використання. Часове розподілення працює на будь-якому GPU NVIDIA. MIG потребує архітектури Ampere або новішої. Cast AI MPS працює на GCP GKE; див. таблицю порівняння вище щодо статусу дорожньої карти. Вибір методу спільного використання, який не підтримується обладнанням або хмарним провайдером, призведе до помилки конфігурації ще до запуску робочого навантаження, тому цю перевірку слід виконати до будь-яких змін конфігурації.
Перед завершенням налаштування часового розподілення варто врахувати одне обмеження спостережуваності: DCGM-Exporter не може пов’язати метрики GPU з окремими контейнерами, коли ввімкнено часове розподілення. Видимість використання GPU окремими робочими навантаженнями зникає, якщо немає окремого шляху інструментування. Передбачте цю прогалину в моніторингу до переведення конфігурації у продуктивне середовище, а не після цього.
Коли DCGM не може пов’язати метрики з контейнерами в умовах часового розподілення, використовуйте вбудовану телеметрію сервера інференсу. vLLM надає дані про використання пам’яті GPU для кожного запиту та глибину черги через кінцеву точку /metrics. TGI надає подібні метрики.
Як протестувати спільне використання GPU без погіршення якості сервісу
Ризик увімкнення спільного використання GPU у продуктивному кластері цілком конкретний. Часове розподілення без ізоляції пам’яті може спричинити стрибки затримки, коли спільно заплановані робочі навантаження одночасно надсилають імпульсні запити. Підхід «спочатку тестування, потім зобов’язання» зменшує цей ризик до керованого рівня.
Почніть з одного вузла. Увімкніть часове розподілення на одному вузлі в просторі імен, що не є продуктивним, за допомогою ConfigMap, застосованої до NVIDIA GPU Operator. Встановіть кількість реплік відповідно до кількості робочих навантажень, які ви плануєте спільно розміщувати, почавши з двох і поступово збільшуючи їх. Запускайте кожне робоче навантаження з реалістичною частотою запитів, перш ніж додавати наступне.
Вимірюйте затримку на 95-му та 99-му процентилях протягом усього нарощування, а не лише середнє значення. Конкуренція за ресурси при часовому розподіленні спочатку проявляється у хвостовій затримці. Якщо p99 залишається в межах вашої цілі рівня обслуговування під час додавання робочих навантажень, конфігурація придатна для цієї суміші. Якщо показник погіршується понад допустимий рівень до досягнення цільової кількості реплік, часове розподілення не є правильним методом для цих конкретних робочих навантажень за таких частот запитів.
Для робочих навантажень із жорсткими бюджетами затримки перед переходом до часового розподілення оцініть MIG. Апаратно ізольовані шляхи пам’яті MIG усувають взаємні перешкоди між робочими навантаженнями, яким часове розподілення запобігти не може. На A100 профіль MIG 3g.20gb забезпечує 3/7 обчислювальних ресурсів і приблизно 20 ГБ ізольованої VRAM, із детермінованою пропускною здатністю незалежно від того, що працює в сусідніх розділах. Компромісом є сумісність обладнання: MIG потребує Ampere або новішої архітектури. Якщо ваші робочі навантаження працюють у GCP GKE, MPS є ще одним варіантом для оцінювання сценаріїв одночасного інференсу (доступність та характеристики ізоляції див. у таблиці порівняння).
Перед запуском будь-якого тесту спільного розміщення слід врахувати один фактор: vLLM за замовчуванням виділяє 90% VRAM пристрою під час ініціалізації контексту CUDA, незалежно від навантаження запитами. TGI виділяє пам’ять на основі параметра –max-batch-prefill-tokens, який може зайняти значну частину VRAM ще до обробки будь-якого запиту інференсу. Неактивний екземпляр vLLM утримує ці 90%, навіть коли не обробляє жодного запиту. vLLM надає прапорець –gpu-memory-utilisation, який обмежує це виділення; значення за замовчуванням — 0.9. У конфігураціях часового розподілення, де кілька серверів інференсу спільно використовують пристрій, установіть для кожного співрозміщеного пода нижче значення цього прапорця, щоб залишити запас для сусідів. Без такого коригування два сервери інференсу, які виглядають простоюючими, можуть наситити VRAM ще до надходження першого запиту інференсу.
Під час тестування враховуйте прогалину в моніторингу DCGM. За ввімкненого часового розподілення метрики GPU для окремих контейнерів недоступні через DCGM-Exporter. Використовуйте під час оцінювання метрики рівня застосунку: затримку запитів, токени за секунду та глибину черги. Перед перенесенням конфігурації в продуктивне середовище сплануйте роботу з цим обмеженням моніторингу. Якщо під час тестування часове розподілення спричиняє події OOM, поверніть кількість реплік GPU до 1 у ConfigMap (що вимкне часове розподілення) і перезапустіть відповідні поди, перш ніж коригувати бюджети VRAM робочих навантажень.
Перед увімкненням будь-якої конфігурації спільного використання переконайтеся, що VRAM достатньо. Складіть вимоги до VRAM усіх робочих навантажень, які плануєте спільно розмістити на одному пристрої. Якщо загальний обсяг перевищує пам’ять пристрою, конфігурація спричинить помилки нестачі пам’яті під навантаженням, а не плавне погіршення. MIG вирішує цю проблему, призначаючи фіксований обсяг пам’яті кожному розділу. Часове розподілення — ні.
Ручне виконання таких тестів є практичним для одного-двох кластерів. У міру зростання флотів GPU та сама логіка координації потребує автоматизації.
Роль спільного використання GPU та автоматизації розміщення
Конфігурація спільного використання, налаштована під сьогоднішню суміш робочих навантажень, погіршується одразу після випуску нових моделей. Частоти запитів змінюються. Команди додають робочі навантаження, не торкаючись ConfigMap, створеного шість місяців тому. Ручна конфігурація може одного разу усунути проблему виділення ресурсів, але не здатна підтримувати флот у актуальному стані.
Спільне використання GPU від Cast AI усуває описану вище проблему виключного виділення ресурсів на рівні автоматизації. Конфігурація спільного використання зберігається в шаблонах вузлів, а не в маніфестах робочих навантажень, тому наявні поди переходять на спільні пристрої без змін у маніфестах. Часове розподілення масштабується від 1 до 48 реплік на GPU на будь-якому GPU NVIDIA: той самий сценарій із наведеного прикладу (чотири сервіси інференсу, що утримують чотири виділені пристрої з 10% обчислювальної активності) вирішується збільшенням кількості реплік без переписування жодної специфікації Deployment.
Саме тут важливе bin-packing — у ситуації, описаній у розділі «Правила розміщення виключають обладнання, яке інакше можна було б використати». Автоматизація розміщення Cast AI вибирає конфігурацію спільного використання та розподіляє робочі навантаження між спільними й розділеними GPU, не вимагаючи селекторів вузлів або правил спорідненості в маніфестах застосунків. Призначення пристроїв відбувається через Dynamic Resource Allocation (DRA, стабільний у Kubernetes 1.32; у попередніх версіях потрібно ввімкнути функціональний перемикач). DRA замінює механізм Extended Resources для виділення пристроїв, надаючи планувальнику Kubernetes контроль на рівні окремих подів над конкретними екземплярами GPU, а не непрозорими цілими лічильниками. Зміни попиту автоматично запускають коригування розміщення, а не створення заявки на повторне налаштування ConfigMap.
Якщо визначальним обмеженням є VRAM, вибір методу безпосередньо впливає на результат. Часове розподілення на будь-якому GPU NVIDIA обробляє робочі навантаження, сумарні вимоги до пам’яті яких поміщаються у VRAM пристрою. Підтримка MIG поширюється на GPU A100, A30, H100, H200 і покоління Blackwell для робочих навантажень, яким потрібні апаратно ізольовані бюджети пам’яті та детермінована пропускна здатність кожного розділу. MPS, що забезпечує одночасне виконання CUDA з налаштовуваним розділенням SM, доступний у GCP GKE (щодо дорожньої карти для інших хмарних провайдерів див. таблицю порівняння).
Один A100, розділений на сім екземплярів MIG із чотирма репліками часового розподілення кожного, представляє планувальнику Kubernetes 28 логічних слотів GPU. Це верхня межа, а не початкова конфігурація. Пропускна здатність одного слота зменшується за високої щільності, тому перед використанням цієї конфігурації для чутливого до затримки інференсу протестуйте її під репрезентативним навантаженням. Рівень автоматизації підтримує перевірену конфігурацію стабільною під час розгортання нових моделей, замість того щоб дозволити їй деградувати до повторної появи черги.
ALLEN Digital: зниження витрат на 71% завдяки спільному використанню семи моделей
Виділені екземпляри GPU для переривчастих робочих навантажень стають проблемою оплати ще до того, як перетворюються на проблему ємності. Практичний приклад ALLEN Digital показує, як це виглядає у продуктивному масштабі.
На SageMaker працювали сім ML-моделей: три моделі з відкритим кодом (BGE-M3, LlamaGuard, Multilingual E5 Large) і чотири власні. Кожна безперервно утримувала власний виділений екземпляр GPU. Навантаження складали нерегулярні запити студентів; оплата за екземпляри нараховувалася цілодобово незалежно від використання. SageMaker не пропонував способу об’єднати ці моделі на спільній ємності, тому команда оцінювала альтернативи.
В EKS продукт оптимізації інференсу Cast AI, Kimchi Inference, керував часовим розподіленням GPU, bin-packing вузлів і співвідношенням екземплярів On-Demand/Spot 50/50. Разом ці зміни скоротили витрати ALLEN Digital на 71% порівняно із SageMaker, при цьому затримка збереглася. Із загального скорочення на 71% часове розподілення забезпечило приблизно 20 процентних пунктів. Об’єднання моделей на спільних екземплярах GPU дало ще 30–40 процентних пунктів. Перехід на Spot і оптимізація розмірів CPU/пам’яті забезпечили решту.
На початку BGE-M3 зіткнулася з проблемами сумісності з часовим розподіленням. Команда Cast AI усунула їх за два дні. Після виправлення затримка виявилася нижчою за попередній базовий показник SageMaker. Картик Бхат, інженер DevOps 2 в ALLEN Digital, сформулював це прямо: «Якщо ваші моделі недостатньо використовуються або ви прагнете підвищити використання та повністю задіяти ємність GPU, одночасно зменшуючи витрати, я вважаю Kimchi Inference чудовим рішенням».
Ці 71% — це показник переходу із SageMaker на EKS. Він відображає спільну дію спільного використання, переходу на Spot і оптимізації розмірів, а не один окремий важіль. Структурна закономірність, яка переноситься між середовищами, полягає в тому, що виділення окремих ресурсів для переривчастого інференсу створює неефективність, яку можна усунути спільним використанням GPU, якщо це дозволяє профіль пам’яті робочого навантаження.
Висновок
Робочі навантаження в черзі поруч із GPU, які виглядають простоюючими, майже ніколи не свідчать про дефіцит обладнання. Вони відображають проблему конфігурації на рівні планування, виділення ресурсів, пам’яті або застосунку. Послідовність діагностики в цій публікації містить команди, які допоможуть визначити, який саме варіант має місце. Спільне використання GPU усуває проблему виділення ресурсів; обмеження VRAM потребують розділення пам’яті через MIG або MPS із розділенням SM. Проблеми розміщення усуваються налаштуванням планування, а не додатковим обладнанням. Вузьке місце на рівні застосунку потребує ресурсів CPU, коригування пакетування або роботи над
Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.