Недостигът на GPU във вашата собствена инфраструктура: защо AI натоварванията чакат, докато капацитетът стои неизползван

Използването на GPU показва изчислителната активност, но не и дали капацитетът действително е наличен. Един GPU може да отчита ниско използване, като същевременно остава изцяло разпределен към едно работно натоварване. Тази публикация обяснява защо работните натоварвания се нареждат на опашка до привидно неизползвани GPU, как разпределението, паметта, разполагането и тесните места в приложенията допринасят за това и как се различават методите за споделяне на GPU по отношение на компромисите.

Резюме:

AI работните натоварвания могат да чакат за GPU, дори когато мониторингът показва неизползвана изчислителна мощност. GPU с ниска изчислителна активност не представлява непременно наличен капацитет за друго работно натоварване, тъй като правилата за разпределение, изискванията към паметта, хардуерната съвместимост, изолацията и ограниченията при разполагане определят какво действително може да се изпълни. Публикацията трябва да обясни как да се разграничи реалният недостиг на хардуер от тесните места, свързани с разпределението, разполагането или приложението. Използвайте констатацията за средно използване на GPU от 5% в доклада на Cast AI за 2026 г. като изследователска отправна точка, но не внушавайте, че чакащи работни натоварвания и неизползвани GPU са се наблюдавали едновременно в едни и същи измерени среди или че 95% от капацитета на GPU може незабавно да бъде освободен.

Основни изводи

Метриките за използване на GPU измерват изчислителната активност, а не състоянието на разпределение. GPU, отчитащ 5% изчислително използване, все пак може да е изцяло разпределен, с нулев наличен капацитет за нови работни натоварвания.
Kubernetes по подразбиране разпределя цели GPU устройства към pod-ове. Едно работно натоварване, което държи устройство, блокира всички останали, независимо колко от GPU използва в действителност.
Чакащите работни натоварвания до привидно неизползвани GPU имат поне четири различни първопричини. Само една от тях се решава чрез споделяне на GPU.
Time-slicing, MIG и MPS предлагат различни компромиси по отношение на изолацията на паметта, хардуерните изисквания, наблюдаемостта и поддръжката от облачните доставчици. Нито един метод не е подходящ за всяко работно натоварване.
Последователността на диагностиката е важна: първо проверете състоянието на разпределението, след това заетостта на паметта, после ограниченията при разполагане и накрая тесните места в приложението. Именно в този ред.
Cast AI поддържа и трите метода за споделяне с автоматично bin-packing и без необходимост от промени в манифестите на работните натоварвания.

Какво ви показва използването на GPU и какво пропуска

Използването на GPU е израз, който обхваща поне четири различни измервания, а смесването им е най-бързият път към неправилна диагноза. Това, което повечето табла за управление показват, е изчислителното използване: процентът от streaming multiprocessor-ите (SM), които са активни в даден времеви интервал. Това число показва колко зает е силицият, когато работи. То не ви казва нищо за това дали устройството е налично за ново работно натоварване.

Модел, зареден във VRAM, заема тази памет непрекъснато. Услугата за инференс може да отговаря на една заявка в минута, поддържайки изчислителната активност на 5%, но устройството е разпределено, паметта е заета и Kubernetes няма да планира нищо друго върху него. От гледна точка на планировчика този GPU е недостъпен. От гледна точка на таблото за мониторинг изглежда почти неизползван.

Таблицата по-долу разделя четири метрики, които обикновено се обобщават под „използване на GPU“, и изяснява какво всяка от тях показва и какво не показва.

Метрика	Какво измерва	Какво НЕ показва
Изчислителна активност (%SM)	Делът на активните streaming multiprocessor-и през времевия интервал на извадката	Дали GPU е разпределен; дали VRAM е налична за друго работно натоварване
Заетост на паметта (VRAM)	Колко GPU памет се използва от заредените модели и тензори	Изчислителната активност; дали чакащите работни натоварвания биха се побрали в оставащата памет
Време на изчакване в опашката (планиране на pod)	Колко дълго чакащите pod-ове изчакват, преди GPU устройство да стане налично	Дали забавянето е причинено от разпределение, памет, разполагане или тясно място в приложението
Пропускателна способност / латентност	Обслужени заявки в секунда; време до първия токен или време за отговор от край до край	Използването на GPU ресурса или ефективността на разпределението

Докладът на Cast AI за оптимизацията на Kubernetes през 2026 г., който анализира десетки хиляди производствени клъстери от януари 2025 г. до април 2026 г., отчита средно изчислително използване на GPU от 5%, преди да бъде приложена каквато и да е оптимизация. Придружаващата публикация към доклада отбелязва, че един клъстер в набора от данни е поддържал 49% използване на GPU при 136 H200, като разликата е описана като почти изцяло резултат от техниката, а не от хардуера. Тази средна стойност от 5% отразява реален модел на свръхосигуряване и недостатъчно използване в целия парк. Тя не означава, че 95% от капацитета е свободен за приемане на нови работни натоварвания. Всеки клъстер и всеки GPU в него изискват собствен диагностичен анализ, преди да може да се направи такъв извод.

Четири причини, поради които работните натоварвания могат да се наредят на опашка до неизползван GPU капацитет

Планировчикът на Kubernetes вижда GPU като наличен или неналичен. Той определя това въз основа на броя ресурси nvidia.com/gpu на всеки възел, а не според процента от силиция, който е активен. Четири различни условия могат да доведат до опашка, дори когато изчислителната активност изглежда ниска.

Работно натоварване заема цялото устройство

Приставката NVIDIA Kubernetes Device Plugin по подразбиране разпределя GPU изключително. Когато един pod заяви nvidia.com/gpu: 1, той получава изключителна собственост върху едно физическо устройство за целия си жизнен цикъл. Никой друг pod не може да използва това устройство, независимо колко изчислителни ресурси или памет действително заема работното натоварване.

Това е най-честата причина за модела „опашка до неизползван GPU“ в клъстерите за инференс. Набор от модели, всеки от които държи специално предназначен GPU, но обслужва периодични или редки заявки, поддържа всички устройства разпределени. Входящо работно натоварване открива nvidia.com/gpu: 0 налични на възела и изчаква, въпреки че съвкупната изчислителна активност на възела може да е под 10%.

Приставката за устройства се фокусира върху разпределението, а не върху освобождаването на ресурси. Cluster autoscaler на Kubernetes може да осигури нови възли, но няма да възстанови неизползвания капацитет на съществуващите. Проблемът е на ниво планиране, а решението изисква промяна в начина, по който устройствата се представят пред планировчика. Именно това правят механизмите за споделяне на GPU.

Паметта е заета, а не просто недостатъчно използвана

Ниското изчислително използване не означава, че паметта е налична. Два сценария илюстрират диапазона. Модел със 70 милиарда параметъра, зареден във FP16, използва приблизително 140 GB VRAM (само базовите тегла; при дължина на контекста 4K KV cache добавя 15–20% над базовите тегла, докато при дължина на контекста 128K изискванията за KV cache могат изцяло да надхвърлят базовите тегла). За зареждането на този модел са необходими поне два A100 80GB GPU. Модел с 13 милиарда параметъра във FP16 заема приблизително 26 GB и се побира на един A100 80GB, но въпреки това продължава да заема тази VRAM. Изчислителното използване може да отчита 8%, тъй като повечето заявки приключват бързо, но устройството не може да приеме друго работно натоварване.

Преди да конфигурирате споделяне, проверете дали е приложима квантизация. Квантизиран модел INT4 със 7 милиарда параметъра заема приблизително 4 GB спрямо приблизително 14 GB при FP16, което променя изчисленията за съвместно разполагане при конфигурации с time-slicing и MIG. INT8 намалява изискванията приблизително наполовина спрямо FP16, често с приемливи компромиси в качеството при работни натоварвания за инференс.

Това е особено важно за екипи, които обмислят time-slicing като решение. Time-slicing мултиплексира достъпа до изчислителните ресурси, но не разделя паметта. Всички реплики споделят едно и също адресно пространство на VRAM. Ако две работни натоварвания заедно надхвърлят паметта на устройството, те няма да съществуват безопасно едновременно. Диагностицирането на ограничението на паметта преди избора на метод за споделяне предотвратява неуспешно внедряване и потенциална нестабилност на работните натоварвания.

Проверете заетостта на паметта с nvidia-smi, преди да приемете, че даден подход за споделяне ще помогне. Ако колоната за свободната памет е близо до нула на съответните устройства, ограничението е капацитетът на VRAM, а не планирането на изчисленията. MIG осигурява хардуерно изолирани дялове памет, които могат да решат определени варианти на този проблем, но изисква съвместим хардуер и променя начина, по който се планират работните натоварвания.

Правилата за разполагане изключват иначе използваем хардуер

Работно натоварване може да не успее да се планира не защото GPU са изцяло разпределени, а защото планировчикът не може да намери възел, който едновременно да отговаря на всички ограничения за разполагане. Правила за affinity на възлите, посочващи модел или поколение GPU, ограничения за разпределение по топология, изискващи минимален брой възли, и taint-ове без съответстващи toleration-и могат да попречат на планирането, дори когато необработените бройки устройства изглеждат достатъчни.

Заявка за nvidia.com/gpu: 1 със селектор на възел, изискващ A100, няма да бъде разположена на възел, който разполага само с H100, дори ако тези H100 са неизползвани и съвместими. По същия начин работно натоварване, заявяващо повече реплики с time-slicing, отколкото предоставя един възел, без разпределяне между възли, може да се провали изцяло, въпреки че паркът разполага със съвкупен капацитет.

Диагностичната команда тук е kubectl describe pod <pending-pod>. Проверете секцията Events за причини като MatchNodeSelector, InsufficientResource или TaintToleration. Неуспешното разполагане често изглежда като недостиг на капацитет и се решава чрез конфигурацията на планирането, а не чрез закупуване на хардуер.

Изпълняваното работно натоварване изчаква нещо друго

Не всяко ниско показание за изчислително използване сигнализира проблем с разпределението. Изчислителните ресурси на GPU остават неизползвани по време на предварителната обработка от CPU, зареждането на данни, трансферите през PCIe и мрежовите обиколки. Сървър за LLM инференс, който изчаква бавна токенизация или извличане на KV cache от отдалечено хранилище, ще показва ниска активност на %SM, но GPU не е наличен за заявките за инференс на друго работно натоварване. То е блокирано на друг слой.

Тази категория е най-трудната за диагностициране само от метриките на GPU. Продължителното ниско изчислително използване при активно, планирано работно натоварване обикновено сочи към тясно място извън GPU. Увеличаването на броя GPU няма да помогне. Решенията включват увеличаване на CPU ресурсите, корекции в конфигурацията за пакетиране, подобряване на латентността на хранилището или преработване на конвейера за данни.

Използвайте nvidia-smi dmon или метрики от DCGM, за да наблюдавате изчислителното използване във времето. Работно натоварване, което се редува между 0% и високо изчислително използване на кратки интервали, вероятно е ограничено от CPU през периодите с 0%. Работно натоварване, което остава постоянно на ниско изчислително използване, докато активно получава заявки, изчаква I/O или мрежата. И двата модела се различават от недостига на разпределение и изискват различни решения.

Практически пример за разпределение на GPU в Kubernetes

Сценарият по-долу е хипотетичен и е създаден, за да илюстрира проблема с разпределението. Той не представлява измерена производителност от конкретен клъстер.

Представете си възел с четири GPU, всеки от които е разпределен изключително към една услуга за инференс. Всяка услуга обработва периодични заявки от ученици, с пикова изчислителна активност от 15% в натоварени периоди и под 3% извън тях. Пета услуга за инференс се внедрява и преминава в състояние Pending. Планировчикът открива nvidia.com/gpu: 0 налични на възела и поставя pod-а на опашка.

Конфигурация	GPU на възела	Работещи услуги	Пикова изчислителна активност	Състояние на петата услуга
Текуща: специално разпределение	4	4 (по една на GPU)	~15% на устройство	Pending: няма налични устройства
Потенциална: time-slicing (по 4 реплики)	4	До 16 (по четири на GPU)	Зависи от припокриването на заявките	Може да бъде планирана, при условие че се побира във VRAM

Преминаването към time-slicing не гарантира конкретно подобрение на пропускателната способност. То променя наличността на устройствата от гледна точка на планировчика. Всеки GPU вече обявява четири слота вместо един. Петата услуга може да бъде планирана. Дали общата латентност ще се подобри или влоши зависи от това колко често заявките на услугите се припокриват, колко VRAM заема всеки модел и дали някой модел не показва периодична SM активност, която създава конкуренция по време на пиковите интервали.

Единственият начин да разберете отговора за конкретна комбинация от работни натоварвания е да я тествате. Следващите диагностични стъпки описват как да направите това, без да се ангажирате с конфигурация, която може да навреди на производствената латентност.

Сравнение на специално предназначени GPU, time-slicing, MIG и MPS

Съществуват четири модела за разпределение на GPU работни натоварвания в Kubernetes. Всеки решава различен вариант на проблема със споделянето и всеки има ограничения, които определят дали е подходящ за дадено работно натоварване. Нито един подход не е универсално правилен.

Подход	Модел на разпределение	Изолация на паметта	Хардуерни изисквания	Подходящи работни натоварвания	Основен компромис
Специално разпределение	Един pod, един GPU, изключителен достъп	Пълна изолация	Всеки NVIDIA GPU	Големи модели; обучение на няколко GPU; инференс с критична латентност, изискващ пълната пропускателна способност на устройството	Максимална изолация; липса на споделяне; разхищение на капацитет при периодични или слабо използвани работни натоварвания
Time-slicing	Времево мултиплексиране; N реплики споделят един физически GPU	Няма: всички реплики споделят цялото адресно пространство на VRAM	Всеки NVIDIA GPU; работи с V100, T4 и по-стари поколения	Малки модели; периодичен инференс; пакетни задачи с променливо търсене	Няма изолация на паметта или отказите; DCGM-Exporter не може да свързва метрики с контейнерите; риск от конкуренция за VRAM при едновременно натоварване
MIG (Multi-Instance GPU)	Хардуерно разделяне до 7 изолирани инстанции на физически GPU	Хардуерно изолирани пътища на паметта: отделни L2 cache банки, контролери на паметта и 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 и по-новите добавят изолация на ниво процес. Физическата памет остава споделена във всички конфигурации.	Всеки NVIDIA GPU с поддръжка на CUDA. MPS на Cast AI понастоящем е наличен в GCP GKE; поддръжката за AWS и Asure е в пътната карта.	Съвместно разположени работни натоварвания, които могат да споделят изпълнението; пакетен инференс с по-ниска изолация	Едновременно изпълнение, а не времево преплитане; намалени разходи за превключване на контекста; оценете MIG, когато са необходими строги бюджети за памет на работно натоварване

Time-slicing работи с всеки NVIDIA GPU, включително по-стари поколения като T4 и V100, които не поддържат MIG. Документацията на NVIDIA GPU Operator за time-slicing изрично посочва, че между репликите няма изолация на паметта или отказите. Работно натоварване, което изчерпи VRAM или срине CUDA контекста, може да засегне всички съвместно планирани работни натоварвания на същото устройство. Това ограничение свежда time-slicing до работни натоварвания, чийто комбиниран отпечатък в паметта се побира комфортно във VRAM на устройството.

MIG осигурява най-силната гаранция за изолация от трите метода за споделяне. Всеки дял има физически отделни пътища през системата на паметта, включително портове на on-chip crossbar, L2 cache банки, контролери на паметта и DRAM адресни шини. Трашингът на кеша от една инстанция не може да повлияе на латентността на друга. Ръководството на NVIDIA за MIG описва до седем инстанции на физически GPU, с фиксирани профили, които определят разпределението на изчислителни ресурси и памет за всеки дял. Тези профили не могат динамично да се преоразмеряват по време на изпълнение, така че решението за разделяне се взема при конфигурирането.

Едно ограничение е особено важно за работните процеси с разпределено обучение: NVLink не се поддържа между MIG инстанции. Екипи, изпълняващи задачи за обучение на няколко GPU, които разчитат на високоскоростна комуникация между GPU, не трябва да приемат MIG като директна алтернатива за споделяне при тези работни натоварвания.

MPS се различава и от двата метода. Докато time-slicing превключва между CUDA контексти във времето, MPS позволява на множество CUDA процеси да се изпълняват едновременно върху едни и същи streaming multiprocessor-и. Документацията на NVIDIA за MPS описва архитектурата като лек runtime: контролен демон, сървърен процес и клиентска библиотека, вградена в libcuda.so. MPS с разделяне на SM (налично от CUDA 11.0 нататък) добавя конфигурируеми дялове на SM и памет на пространство от имена, като предоставя повече изолация от базовия time-slicing, без да изисква хардуер, съвместим с MIG. Архитектурата Volta и по-новите добавят изолация на ниво процес; физическата памет остава споделена във всички MPS конфигурации.

Cast AI поддържа комбинирането на MIG и time-slicing. Един A100, разделен на седем MIG инстанции, всяка конфигурирана с четири time-sliced реплики, предоставя 28 логически GPU слота на планировчика на Kubernetes от едно физическо устройство. Това е конфигурация с висока плътност, която изисква внимателно профилиране на работните натоварвания преди внедряване, но изчислението илюстрира защо изборът на метод за споделяне е толкова важен, колкото и закупуването на хардуер.

Диагностицирайте тясното място, преди да поръчате още 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, а не изчислителна мощност. Time-slicing няма да помогне тук. Разделянето на паметта чрез MIG или MPS с разделяне на SM е подходящият път, при условие че хардуерът и доставчикът са съвместими.

Стъпка 3: Проверете събитията на чакащия pod за неуспешно разполагане. Изпълнете:

kubectl describe pod <pending-pod-name>

Потърсете причините за неуспешно планиране в секцията Events: MatchNodeSelector, InsufficientResource или TaintToleration. Ако правилата за разполагане блокират поставянето на работното натоварване върху налични GPU, решението е в конфигурацията на планирането. Закупуването на хардуер няма да го реши.

Стъпка 4: Наблюдавайте изчислителната активност във времето на работещите работни натоварвания. Използвайте nvidia-smi dmon -s u или метрики от DCGM, за да съберете времеви ред за представителен период на заявки. Ако %SM се редува между 0 и високи стойности на кратки интервали, работното натоварване вероятно е ограничено от CPU през периодите с 0%. Ако %SM остава постоянно нисък, докато работното натоварване активно получава заявки, подозирайте зареждане на данни, трансфер през PCIe или латентност на KV cache. И двата модела се различават от недостига на разпределение.

Стъпка 5: Проверете съвместимостта на хардуера и доставчика с планирания метод за споделяне. Time-slicing работи с всеки NVIDIA GPU. MIG изисква архитектура Ampere или по-нова. MPS на Cast AI работи в GCP GKE; вижте таблицата за сравнение по-горе за състоянието в пътната карта. Изборът на метод за споделяне, който хардуерът или облачният доставчик не поддържа, ще доведе до конфигурационна грешка, преди да доведе до работно натоварване, затова тази проверка трябва да се извърши преди всяка промяна в конфигурацията.

Едно ограничение на наблюдаемостта, което трябва да имате предвид, преди да финализирате конфигурация с time-slicing: DCGM-Exporter не може да свързва метрики за GPU с отделни контейнери, когато е активиран time-slicing. Видимостта върху GPU на ниво работно натоварване изчезва, освен ако не разполагате с отделен инструментариум за измерване. Планирайте тази празнина в мониторинга, преди конфигурацията да достигне производствена среда, а не след това.

Когато DCGM не може да свърже метрики с контейнерите при time-slicing, използвайте вградената телеметрия на сървъра за инференс. vLLM предоставя използването на GPU памет на заявка и дълбочината на опашката на крайна точка /metrics. TGI предоставя подобни метрики.

Как да тествате споделянето на GPU, без да жертвате качеството на услугата

Рискът при активиране на споделяне на GPU в производствен клъстер е реален. Time-slicing без изолация на паметта може да причини пикове в латентността, когато съвместно планирани работни натоварвания изпращат едновременно пакетни заявки. Подходът „тествай преди ангажиране“ намалява този риск до управляемо ниво.

Започнете с един възел. Активирайте time-slicing на един възел в непроизводствено пространство от имена, като използвате ConfigMap, приложен към NVIDIA GPU Operator. Задайте броя реплики според броя работни натоварвания, които възнамерявате да разположите съвместно, като започнете от две и постепенно увеличавате. Изпълнявайте всяко работно натоварване с реалистични нива на заявки, преди да добавите следващото.

Измервайте латентността при персентили p95 и p99 по време на увеличаването, а не само средната стойност. Конкуренцията при time-slicing първо се проявява в опашката на разпределението. Ако p99 остане в рамките на целта за ниво на услугата, докато добавяте работни натоварвания, конфигурацията е подходяща за тази комбинация. Ако се влоши над допустимото, преди да достигнете целевия брой реплики, time-slicing не е правилният метод за тези конкретни работни натоварвания при тези нива на заявки.

За работни натоварвания със строги бюджети за латентност оценете MIG, преди да се ангажирате с time-slicing. Хардуерно изолираните пътища на паметта на MIG премахват взаимодействието между работните натоварвания, което time-slicing не може да предотврати. При A100 MIG профил 3g.20gb предоставя 3/7 от изчислителната мощност и приблизително 20 GB изолирана VRAM, с детерминистична пропускателна способност независимо от това какво се изпълнява в съседните дялове. Компромисът е хардуерната съвместимост: MIG изисква Ampere или по-нова архитектура. Ако работните ви натоварвания работят в GCP GKE, MPS е друга възможност, която си струва да оцените за сценарии с едновременен инференс (вижте таблицата за сравнение относно наличността и изолацията).

Преди да изпълните тест за съвместно разполагане, отчетете един фактор: vLLM предварително заделя 90% от VRAM на устройството при инициализация на CUDA контекста по подразбиране, независимо от натоварването със заявки. TGI предварително заделя памет според настройката –max-batch-prefill-tokens, която може да заеме значителна част от VRAM, преди да бъде обслужена каквато и да е заявка за инференс. Неактивна vLLM инстанция държи тези 90%, дори когато не обслужва нито една заявка. vLLM предоставя флаг –gpu-memory-utilisation, който ограничава това заделяне; стойността по подразбиране е 0.9. При конфигурации с time-slicing, в които няколко сървъра за инференс споделят устройство, задайте по-ниска стойност на този флаг за всеки съвместно разположен pod, за да оставите резерв за останалите. Без тази корекция два привидно неактивни сървъра за инференс могат да наситят VRAM, преди да пристигне дори една заявка.

Имайте предвид празнината в мониторинга на DCGM по време на тестването. Метрики за GPU на ниво контейнер не са налични чрез DCGM-Exporter при активиран time-slicing. Използвайте метрики на ниво приложение по време на оценяването: латентност на заявките, токени в секунда и дълбочина на опашката. Планирайте това ограничение в мониторинга, преди да преместите конфигурацията в производство. Ако time-slicing причини OOM събития по време на тестването, върнете броя на GPU репликите на 1 в ConfigMap (което деактивира time-slicing) и рестартирайте засегнатите pod-ове, преди да коригирате бюджетите за VRAM на работните натоварвания.

Потвърдете, че VRAM е достатъчна, преди да активирате каквато и да е конфигурация за споделяне. Съберете изискванията за VRAM на всички работни натоварвания, които планирате да разположите съвместно на едно устройство. Ако общата стойност надхвърля паметта на устройството, конфигурацията ще доведе до грешки от типа out-of-memory при натоварване, а не до плавно влошаване. MIG решава това, като задава фиксирана памет за всеки дял. Time-slicing не го прави.

Ръчното изпълнение на тези тестове е практично за един или два клъстера. С разрастването на парковете от GPU същата логика за координация печели от автоматизацията.

Къде се вписват споделянето на GPU и автоматизацията на разполагането

Конфигурация за споделяне, настроена за днешната комбинация от работни натоварвания, се влошава веднага щом бъдат пуснати нови модели. Нивата на заявките се променят. Екипите добавят работни натоварвания, без да докосват ConfigMap-а от преди шест месеца. Ръчната конфигурация може да реши проблема с разпределението веднъж, но не може да поддържа целия парк.

Споделянето на GPU на Cast AI решава описания по-горе проблем с изключителното разпределение на ниво автоматизация. Конфигурацията за споделяне се намира в шаблоните на възлите, а не в манифестите на работните натоварвания, така че съществуващите pod-ове преминават към споделени устройства без промени в манифестите. Time-slicing се мащабира от 1 до 48 реплики на GPU при всеки NVIDIA GPU: същият сценарий от практическия пример (четири услуги за инференс, заемащи четири специално разпределени устройства при 10% изчислително използване) се решава чрез увеличаване на броя реплики, без да се променя нито една спецификация на Deployment.

Ограничението при разполагане, описано в „Правилата за разполагане изключват иначе използваем хардуер“, е мястото, където bin-packing има значение. Автоматизацията на разполагането на Cast AI избира конфигурацията за споделяне и разпределя работните натоварвания между споделени и разделени GPU, без да изисква селектори на възли или правила за affinity в манифестите на приложенията. Задаването на устройства се извършва чрез Dynamic Resource Allocation (DRA, стабилен в Kubernetes 1.32; по-ранните версии изискват активиране на feature gate). DRA заменя механизма Extended Resources за разпределяне на устройства и предоставя на планировчика на Kubernetes контрол на ниво pod върху конкретни GPU инстанции, вместо непрозрачни цели числа. Промените в търсенето задействат автоматични корекции в разполагането, вместо да изискват заявка за повторна настройка на ConfigMap.

Когато VRAM е обвързващото ограничение, изборът на метод определя резултата. Time-slicing при всеки NVIDIA GPU обработва работни натоварвания, чието комбинирано потребление на памет се побира във VRAM на устройството. Поддръжката на MIG обхваща A100, A30, H100, H200 и GPU от поколението Blackwell за работни натоварвания, които се нуждаят от хардуерно изолирани бюджети за памет и детерминистична пропускателна способност на всеки дял. MPS, предоставящ едновременно изпълнение на CUDA с конфигурируемо разделяне на SM, е наличен в GCP GKE (вижте таблицата за сравнение относно пътната карта за допълнителни облачни доставчици).

Един A100, разделен на седем MIG инстанции с по четири time-sliced реплики на всяка, предоставя 28 логически GPU слота на планировчика на Kubernetes. Това е горна граница, а не начална точка. Пропускателната способност на слот намалява при висока плътност, така че тествайте при представително натоварване, преди да използвате тази конфигурация за инференс с критична латентност. Слоят за автоматизация поддържа валидирана конфигурация стабилна, когато се внедряват нови модели, вместо да позволява тя да се влоши, докато опашката се появи отново.

ALLEN Digital: 71% намаление на разходите чрез споделяне на седем модела

Специално предназначените GPU инстанции за периодични работни натоварвания се превръщат в проблем с фактурирането, преди да станат проблем с капацитета. Казусът на ALLEN Digital показва как изглежда това в производствен мащаб.

Седем ML модела работеха в SageMaker: три с отворен код (BGE-M3, LlamaGuard, Multilingual E5 Large) и четири разработени по поръчка. Всеки от тях постоянно заемаше собствена специално предназначена GPU инстанция. Натоварването се състоеше от периодични заявки на ученици; инстанциите се таксуваха денонощно независимо от това. SageMaker не предлагаше начин тези модели да бъдат консолидирани върху споделен капацитет, затова екипът оцени алтернативи.

В EKS продуктът на Cast AI за оптимизация на инференс, Kimchi Inference, управляваше GPU time-slicing, bin-packing на възлите и съотношение 50/50 между on-demand и Spot инстанции. Заедно тези промени намалиха разходите на ALLEN Digital със 71% спрямо SageMaker, като латентността остана непроменена. От общото намаление от 71% time-slicing допринесе с приблизително 20 процентни пункта. Консолидирането на моделите върху споделени GPU инстанции доведе до още 30–40 процентни пункта. Използването на Spot и оптимизирането на CPU/паметта покриха остатъка.

BGE-M3 се сблъска с проблеми със съвместимостта с time-slicing в началото. Разрешаването им от екипа на Cast AI отне два дни. След корекцията латентността беше по-ниска от предишната базова стойност в SageMaker. Картик Бхат, DevOps инженер 2 в ALLEN Digital, го формулира директно: „Ако моделите ви са недостатъчно използвани или ако се опитвате да постигнете по-високо използване и да оползотворите напълно GPU капацитета, като същевременно намалите разходите, мисля, че Kimchi Inference е чудесно решение.“

Тези 71% са стойност за преминаване от SageMaker към EKS. Тя отразява съвместната работа на споделянето, използването на Spot и оптимизирането на ресурсите, а не един-единствен лост. Общото между различните среди е структурният модел: специалното разпределение при периодичен инференс създава неефективност, която споделянето на GPU може да възстанови, когато профилът на паметта на работното натоварване го позволява.

Заключение

Чакащите работни натоварвания до привидно неизползвани GPU почти никога не са резултат от недостиг на хардуер. Те отразяват проблем в конфигурацията на ниво планиране, разпределение, памет или приложение. Диагностичната последователност в тази публикация предоставя командите, с които да установите кой от тях е приложим. Споделянето на GPU адресира случая с разпределението; ограниченията на VRAM изискват разделяне на паметта чрез MIG или MPS с разделяне на SM. Неуспешното разполагане се решава чрез конфигурация на планирането, а не чрез допълнителен хардуер. Тясното място на ниво приложение изисква CPU ресурси, корекции в пакетирането или работа по конвейера за данни, а не повече GPU. На практика екипите първо се сблъскват с о

Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.