Дефицит GPU внутри собственной инфраструктуры: почему ИИ-нагрузки стоят в очереди, пока мощности простаивают

Утилизация GPU показывает вычислительную активность, но не то, доступна ли фактически вычислительная ёмкость. GPU может сообщать о низкой утилизации, оставаясь полностью выделенным под одну рабочую нагрузку. В этой статье объясняется, почему рабочие нагрузки становятся в очередь рядом с визуально простаивающими GPU, как на это влияют выделение ресурсов, память, размещение и узкие места приложений, а также чем отличаются методы совместного использования GPU и их компромиссы.

Краткое содержание:

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

Основные выводы

• Метрики утилизации GPU измеряют вычислительную активность, а не состояние выделения ресурсов. GPU, сообщающий о 5% вычислительной утилизации, всё ещё может быть полностью выделен и иметь нулевую доступную ёмкость для новых рабочих нагрузок.
• Kubernetes по умолчанию назначает подам целые GPU. Рабочая нагрузка, занявшая устройство, блокирует всех остальных независимо от того, какую долю GPU она фактически использует.
• У рабочих нагрузок, находящихся в очереди рядом с визуально простаивающими GPU, есть как минимум четыре разные первопричины. Только одна из них устраняется совместным использованием GPU.
• Time-slicing, MIG и MPS по-разному балансируют между изоляцией памяти, требованиями к оборудованию, наблюдаемостью и поддержкой облачных провайдеров. Ни один метод не подходит для всех рабочих нагрузок.
• Важна последовательность диагностики: сначала проверьте состояние выделения ресурсов, затем занятость памяти, потом ограничения размещения и после этого узкие места приложения. Именно в таком порядке.
• Cast AI поддерживает все три метода совместного использования с автоматической упаковкой рабочих нагрузок и без необходимости менять манифесты рабочих нагрузок.

Что показывает утилизация 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 Device Plugin выделяет GPU исключительно. Когда под запрашивает nvidia.com/gpu: 1, он получает единоличное владение одним физическим устройством на весь срок своего жизненного цикла. Ни один другой под не может использовать это устройство независимо от того, сколько вычислительных ресурсов или памяти фактически потребляет занявшая его рабочая нагрузка.

Это наиболее распространённая причина ситуации, когда очередь формируется рядом с простаивающими GPU в кластерах инференса. Набор моделей, каждая из которых удерживает выделенный GPU, но обслуживает нерегулярные или редкие запросы, оставляет все устройства выделенными. Входящая рабочая нагрузка обнаруживает на узле nvidia.com/gpu: 0 доступных GPU и ждёт, хотя совокупная вычислительная активность на узле может быть ниже 10%.

Device Plugin занимается выделением ресурсов, а не их возвратом. Cluster Autoscaler Kubernetes может подготовить новые узлы, но не вернёт простаивающую ёмкость на уже существующих. Проблема находится на уровне планирования, и для её решения нужно изменить способ представления устройств планировщику. Именно этим занимаются механизмы совместного использования GPU.

Память занята, а не просто недоиспользуется

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

Перед настройкой совместного использования проверьте, применима ли квантизация. Квантизированная в INT4 модель на 7 млрд параметров занимает примерно 4 ГБ вместо примерно 14 ГБ в FP16, что меняет расчёты совместного размещения для конфигураций с time-slicing и MIG. INT8 сокращает требования примерно вдвое по сравнению с FP16, часто обеспечивая приемлемый компромисс по качеству для рабочих нагрузок инференса.

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

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

Правила размещения исключают пригодное в остальных отношениях оборудование

Рабочая нагрузка может не планироваться не потому, что GPU полностью выделены, а потому, что планировщик не может найти узел, одновременно удовлетворяющий всем ограничениям размещения. Правила affinity узлов, указывающие модель или поколение GPU, ограничения распределения топологии, требующие минимального количества узлов, и taints без соответствующих tolerations могут препятствовать планированию даже при достаточном количестве устройств.

Запрос nvidia.com/gpu: 1 с node selector, требующим A100, не будет размещён на узле только с H100, даже если эти H100 простаивают и подходят для работы. Аналогично, рабочая нагрузка, запрашивающая больше time-sliced реплик, чем предоставляет любой отдельный узел, без распределения по узлам может полностью не запуститься, несмотря на наличие совокупной ёмкости во всём парке.

Диагностическая команда здесь — 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 на узле	Работающие сервисы	Пиковая вычислительная активность	Состояние пятого сервиса
Текущая: выделение отдельных GPU	4	4 (по одному на GPU)	~15% на устройство	Pending: устройства недоступны
Возможная: time-slicing (по 4 реплики)	4	До 16 (по четыре на GPU)	Зависит от перекрытия запросов	Можно запланировать при условии достаточного объёма VRAM

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

Единственный способ узнать ответ для конкретного сочетания рабочих нагрузок — протестировать его. В следующих диагностических шагах описано, как сделать это, не принимая конфигурацию, которая может ухудшить задержку в рабочей среде.

Сравнение выделенных GPU, time-slicing, MIG и MPS

В Kubernetes существует четыре модели выделения ресурсов для рабочих нагрузок GPU. Каждая решает отдельный вариант проблемы совместного использования и имеет ограничения, определяющие её пригодность для конкретной рабочей нагрузки. Универсально правильного подхода не существует.

Подход	Модель выделения	Изоляция памяти	Требования к оборудованию	Подходящие рабочие нагрузки	Ключевой компромисс
Выделение отдельного GPU	Один под, один GPU, эксклюзивный доступ	Полная изоляция	Любой GPU NVIDIA	Большие модели; обучение на нескольких GPU; критичный к задержке инференс, которому нужна полная пропускная способность устройства	Максимальная изоляция; отсутствие совместного использования; потери ёмкости для нерегулярных рабочих нагрузок или нагрузок с низкой утилизацией
Time-slicing	Временное мультиплексирование; 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

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

MIG обеспечивает наиболее сильную гарантию изоляции среди трёх методов совместного использования. Каждый раздел имеет физически отдельные пути через систему памяти, включая порты внутрикристальной перекрёстной коммутации, банки кеша L2, контроллеры памяти и адресные шины DRAM. Обращение к кешу одного экземпляра не может повлиять на задержку другого. В руководстве пользователя NVIDIA MIG описано до семи экземпляров на физическом GPU с фиксированными профилями, определяющими распределение вычислительных ресурсов и памяти для каждого раздела. Эти профили нельзя динамически изменять во время выполнения, поэтому решение о разделении принимается на этапе настройки.

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

MPS отличается от обоих этих методов. Если time-slicing переключается между контекстами CUDA во времени, MPS позволяет нескольким процессам CUDA одновременно выполняться на одних и тех же потоковых мультипроцессорах. В документации NVIDIA по MPS архитектура описывается как облегчённая среда выполнения: управляющий демон, серверный процесс и клиентская библиотека, встроенная в libcuda.so. MPS с разделением SM (доступно начиная с CUDA 11.0) добавляет настраиваемые разделы SM и памяти для каждого пространства имён, обеспечивая администраторам более высокий уровень изоляции, чем базовый time-slicing, без необходимости оборудования, совместимого с MIG. Архитектуры Volta и новее добавляют изоляцию сбоев на уровне процессов; физическая память остаётся общей во всех конфигурациях MPS.

Cast AI поддерживает сочетание MIG и time-slicing. Один A100, разделённый на семь экземпляров MIG, каждый из которых настроен на четыре time-sliced реплики, предоставляет планировщику 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, а не с вычислениями. Time-slicing здесь не поможет. Подходящим решением будет разделение памяти с помощью MIG или MPS с разделением SM — при условии совместимости оборудования и провайдера.

Шаг 3: Изучите события ожидающего пода на наличие ошибок размещения. Выполните:

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. Оба сценария отличаются от нехватки выделенных ресурсов.

Шаг 5: Проверьте совместимость оборудования и провайдера с выбранным методом совместного использования. Time-slicing работает на любом GPU NVIDIA. 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 ГБ изолированной 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, где несколько серверов инференса используют одно устройство, установите для этого флага меньшее значение в каждом совместно размещённом поде, чтобы оставить запас для соседей. Без этой настройки два визуально простаивающих сервера инференса могут заполнить VRAM ещё до поступления единственного запроса.

Во время тестирования учитывайте пробел в мониторинге DCGM. При включённом time-slicing метрики GPU на уровне контейнеров недоступны через DCGM-Exporter. Используйте метрики уровня приложения: задержку запросов, количество токенов в секунду и глубину очереди. Учтите ограничение мониторинга до перевода конфигурации в рабочую среду. Если во время тестирования time-slicing вызывает события OOM, верните количество реплик GPU к 1 в ConfigMap (это отключит time-slicing) и перезапустите затронутые поды, прежде чем корректировать бюджеты VRAM рабочих нагрузок.

Перед включением любой конфигурации совместного использования подтвердите, что VRAM достаточно. Сложите требования к VRAM всех рабочих нагрузок, которые планируется совместно запускать на одном устройстве. Если общая сумма превышает объём памяти устройства, при нагрузке конфигурация приведёт к ошибкам нехватки памяти, а не к плавному снижению производительности. MIG решает эту проблему, назначая фиксированный объём памяти каждому разделу. Time-slicing — нет.

Ручное проведение таких тестов практично для одного-двух кластеров. По мере роста GPU-парка та же логика координации выигрывает от автоматизации.

Где применяются совместное использование GPU и автоматизация размещения

Конфигурация совместного использования, настроенная под сегодняшний набор рабочих нагрузок, начинает деградировать сразу после выхода новых моделей. Частота запросов меняется. Команды добавляют рабочие нагрузки, не меняя ConfigMap, созданный полгода назад. Ручная настройка может один раз решить проблему выделения ресурсов, но не способна поддерживать работу большого парка.

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

Именно там, где правила размещения исключают пригодное оборудование, важна упаковка рабочих нагрузок. Автоматизация размещения Cast AI выбирает конфигурацию совместного использования и распределяет рабочие нагрузки между общими и разделёнными GPU без необходимости добавлять node selectors или правила affinity в манифесты приложений. Назначение устройств выполняется через Dynamic Resource Allocation (DRA, стабильный механизм в Kubernetes 1.32; в более ранних версиях требуется включение feature gate). DRA заменяет механизм Extended Resources для выделения устройств, предоставляя планировщику Kubernetes управление конкретными экземплярами GPU на уровне подов вместо непрозрачных целочисленных значений. Изменения спроса автоматически запускают корректировки размещения, а не требуют заявки на перенастройку ConfigMap.

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

Один A100, разделённый на семь экземпляров MIG с четырьмя time-sliced репликами в каждом, предоставляет планировщику Kubernetes 28 логических слотов GPU. Это верхняя граница, а не начальная конфигурация. При высокой плотности пропускная способность каждого слота снижается, поэтому перед применением этой конфигурации для чувствительного к задержке инференса протестируйте её под репрезентативной нагрузкой. Уровень автоматизации поддерживает проверенную конфигурацию стабильной при развёртывании новых моделей, вместо того чтобы позволять ей постепенно ухудшаться до возвращения очереди.

ALLEN Digital: снижение затрат на 71% благодаря совместному использованию семи моделей

Выделенные экземпляры GPU для нерегулярных рабочих нагрузок становятся проблемой биллинга ещё до того, как превращаются в проблему ёмкости. Практический пример ALLEN Digital показывает, как это выглядит в производственном масштабе.

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

В EKS продукт оптимизации инференса Cast AI Kimchi Inference управлял time-slicing GPU, упаковкой рабочих нагрузок на узлы и распределением экземпляров 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, почти никогда не свидетельствуют о нехватке оборудования. Обычно это проблема конфигурации на уровне планирования, выделения ресурсов, памяти или приложения. Описанная в статье последовательность диагностики даёт команды, необходимые для определения конкретной причины. Совместное использование GPU решает проблему выделения ресурсов; ограничения VRAM требуют разделения памяти с помощью MIG или MPS с разделением SM. Ошибки размещения устраняются настройкой планирования, а не дополнительным оборудованием. Узкое