Разделение видеокарты окупается не всегда

Делить одну видеокарту имеет смысл, когда отдельные задачи оставляют ускоритель без работы, а их совместный пик укладывается в память и допустимую задержку. Цена карты сама по себе ничего не доказывает: экономия появляется только после замеров одновременной нагрузки, лицензий и времени эксплуатации.

Я видел немало проектов, где команда радовалась высокой средней загрузке после включения общего доступа, а через неделю отключала его из-за скачков p99, ошибок нехватки памяти и невозможности понять, какой контейнер испортил соседям ночь. Хорошая схема разделения задает границы заранее. Плохая лишь позволяет запустить больше процессов на одном устройстве.

Сначала найдите неиспользуемую емкость

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

Среднее значение GPU Utilization не показывает свободную емкость целиком. Оно не отвечает, хватает ли видеопамяти, упирается ли задача в пропускную способность памяти, занят ли кодировщик, и насколько длинны очереди запросов. Смотрите временной ряд с тем же интервалом, в котором живет сервис: для API важны секунды и хвостовая задержка, для пакетной обработки могут быть важнее минуты и время завершения партии.

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

Есть простой порог здравого смысла. Совместный режим должен давать больше полезной работы на одну карту за расчетный период, не нарушая целевое время ответа и срок выполнения партии. Рост загрузки с 30 до 85 процентов не считается успехом, если p99 вырос за пределы соглашения с пользователями или ночное задание перестало заканчиваться к утру.

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

Механизмы разделения решают разные задачи

Потоки CUDA, MPS, временное разделение, vGPU и MIG нельзя считать разными настройками одной функции. Они дают разные границы памяти, планирования, отказов и администрирования.

Самый простой вариант работает внутри одного приложения: процесс запускает операции в нескольких CUDA streams, а фреймворк собирает запросы в пакеты. Это часто лучший путь для одного владельца кода. Приложение видит общую память и само управляет параллелизмом, поэтому не платит за виртуальные машины и отдельные гостевые драйверы. Но поток CUDA не изолирует ошибку, память или пропускную способность от другого потока.

NVIDIA Multi-Process Service, или MPS, позволяет нескольким CUDA-процессам совместно подавать работу через сервер MPS. Руководство NVIDIA объясняет две практические выгоды: ядра и копирование из разных процессов могут перекрываться, а общий набор ресурсов планирования уменьшает переключение контекстов. Это полезно для доверенных пакетных задач, MPI-процессов и небольших сервисов одного подразделения. MPS поддерживается в Linux и QNX, а учет в инструментах наблюдения часто относится к серверу MPS, поэтому разбор потребления по клиентам становится сложнее. Это средство совместной работы, а не граница безопасности между арендаторами.

Time slicing дает процессам, контейнерам или виртуальным GPU доступ по очереди. NVIDIA vGPU планирует временные кванты: пока одна виртуальная машина выполняется, остальные ждут. Короткий квант улучшает отзывчивость, но учащает переключения; длинный помогает пропускной способности, но увеличивает ожидание. В Kubernetes настройка replicas у NVIDIA device plugin рекламирует несколько логических ресурсов поверх одной карты. Документация GPU Operator прямо предупреждает, что такие реплики не получают изоляцию памяти и отказов, а запрос двух реплик не гарантирует двойную долю вычислений.

MIG делит поддерживаемую карту пространственно. Экземпляр получает выделенные вычислительные ресурсы и изолированные пути через L2-кэш, контроллеры памяти и адресные шины DRAM. Разные экземпляры могут работать параллельно с более предсказуемой задержкой. MIG-backed vGPU передает такой экземпляр виртуальной машине; некоторые новые сочетания оборудования и гипервизора допускают еще и временное разделение внутри экземпляра. Эта дополнительная плотность полезна не всегда: внутри одного среза снова появляются соседи и очередь.

Еще одно различие часто теряется в обсуждении: квота, изоляция и гарантия производительности не равны друг другу. Фиксированный объем framebuffer ограничивает память виртуальной машины, но не обязательно закрепляет за ней постоянную долю всех движков. Логическая реплика помогает планировщику выдать доступ, но сама по себе не ограничивает процесс внутри контейнера. Аппаратный срез дает более сильную границу ресурсов, однако общими остаются физическая карта, хост и часть программного стека. В проектной документации называйте конкретное свойство, которое требуется задаче, вместо общего слова «разделение».

Потери возникают не только при переключении контекста

Накладные расходы самого механизма часто меньше ущерба от конкуренции за общий ресурс. Две задачи могут почти без потерь делить карту, если одна редко запускает короткие ядра, а другая в это время не заполняет устройство. Те же задачи столкнутся, когда обе одновременно начнут читать большие тензоры из памяти или копировать данные через PCIe.

Проверяйте четыре вида конкуренции. Вычислительные блоки определяют, сколько ядер реально выполняется параллельно. Пропускная способность видеопамяти ограничивает модели и аналитические операции, которые много читают при сравнительно малом числе вычислений. PCIe и NUMA влияют на подачу данных, особенно если CPU-процессы и карта находятся на разных сокетах. Отдельные движки декодирования и кодирования могут стать узким местом в медиаконвейере, даже когда показатель GPU Utilization выглядит скромно.

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

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

Считайте полезную пропускную способность, а не штраф каждой задачи по отдельности. Если два сервиса на отдельных картах выполняют 100 и 40 запросов в секунду, а вместе на одной выполняют 92 и 36 при приемлемой задержке, общий результат 128 против 140. Карта освободилась ценой примерно девяти процентов совокупной работы. Это может быть выгодно. Если первый сервис сохраняет 100, а второй падает до 10 из-за нехватки памяти или очереди, высокая загрузка оборудования маскирует плохое решение.

Видеопамять задает жесткую границу

Задачи делят не «проценты GPU», а конкретную емкость памяти, и здесь средние значения особенно опасны. Модель занимает веса, кэш, временные буферы и рабочее пространство библиотек. После первого запроса объем может вырасти из-за прогрева, подбора алгоритма или расширения KV-кэша. Замер сразу после запуска почти всегда слишком оптимистичен.

При time slicing процессы обычно видят одну физическую память без гарантированной квоты. Планировщик может раздать логические реплики, но он не превращает 48 ГБ в четыре независимых пула по 12 ГБ. Один контейнер способен занять свободное пространство, после чего сосед получит out of memory. Ограничение памяти контейнера на стороне CPU эту проблему не решает.

vGPU обычно назначает виртуальной машине профиль с фиксированным framebuffer. MIG тоже дает экземпляру объем памяти, заданный профилем. Это защищает емкость соседа, но требует заранее подобрать размеры. Если модель требует 22 ГБ после прогрева, два среза по 20 ГБ не помогут, даже если на всей карте памяти достаточно. Иногда один крупный и один малый профиль полезнее симметричной нарезки.

Для расчета берите максимум устойчивого прогона и добавляйте резерв на рост пакета, новую версию модели и служебные расходы. Размер резерва нельзя взять из универсальной таблицы. Получите его экспериментом: прогоните типичный пик, затем увеличьте пакет или параллелизм до планового предела. Отдельно проверьте, что происходит при нехватке памяти. Управляемая ошибка одного задания приемлема; сбой общего процесса, зависший GPU или массовый перезапуск подов уже меняет класс риска.

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

Поддержка зависит от карты и всего программного стека

Надпись «GPU поддерживает виртуализацию» недостаточна для закупки. Проверять нужно точную модель, форм-фактор, версию драйвера, гостевую ОС, гипервизор, лицензионную редакцию и нужный профиль.

В актуальном руководстве NVIDIA список MIG начинается с архитектуры Ampere, но не включает каждую карту этого поколения. Среди широко применяемых ускорителей там указаны A100 и A30, затем H100, H200 и поддерживаемые серверные модели Blackwell. Число экземпляров различается: для A100 и ряда крупных ускорителей руководство указывает до семи, для A30 до четырех, а для отдельных рабочих моделей Blackwell меньше. Название архитектуры не заменяет таблицу совместимости конкретного выпуска драйвера.

Потребительская карта, на которой одновременно запускаются два процесса CUDA, еще не стала MIG-картой или корпоративной vGPU. Она может поддерживать параллельные контексты, но не иметь аппаратных срезов, поддерживаемых vGPU-профилей и нужных условий лицензирования. Попытка построить гарантированный многопользовательский сервис на таком основании часто заканчивается самодельным диспетчером и длинным списком исключений.

У NVIDIA vGPU есть матрица поддерживаемых GPU, гипервизоров, гостевых ОС и профилей, а программное обеспечение лицензируется. Условия отличаются для виртуальных рабочих станций, вычислительных профилей и способов развертывания. Стоимость лицензий, сервера лицензирования и сопровождения должна попасть в расчет до сравнения с ценой второй карты.

У AMD механизм SR-IOV создает Virtual Functions, которые гипервизор назначает виртуальным машинам, но поддержка также привязана к серверным ускорителям, драйверу GPU Virtualization и проверенным сочетаниям ОС и гипервизора. Документация ROCm отдельно перечисляет поддерживаемые конфигурации. Нельзя переносить вывод с одной серии Instinct на любую карту AMD.

Перед заказом запросите у поставщика подтвержденную матрицу именно для вашей спецификации и сохраните ее вместе с версией проекта. Затем проверьте ее по руководствам производителя. Формулировка «поддерживает GPU sharing» без профиля, версии и режима не дает эксплуатационной гарантии.

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

Экономию дают четыре типа нагрузки

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

Первый сценарий, несколько небольших моделей инференса с неровным потоком запросов. Они редко достигают пика одновременно, а объединение запросов в пакеты оставляет промежутки для соседей. Для доверенных сервисов одного владельца может хватить процессов или MPS. Для разных команд и требований к задержке разумнее отдельные MIG-профили или vGPU.

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

Третий сценарий, виртуальные рабочие места с графикой или инженерными приложениями. vGPU позволяет дать каждой виртуальной машине профиль framebuffer и управлять доступом через гипервизор. Экономика зависит от лицензий, требуемой частоты кадров, дисплеев и сертификации приложений. Офисный трехмерный просмотр и тяжелый интерактивный рендер нельзя считать одним классом пользователя.

Четвертый сценарий, дополняющие конвейеры. Декодирование видео, предварительная обработка, инференс и постобработка нагружают разные части системы в разные моменты. Совместное размещение сокращает простой, если вы измерили движки декодирования, память, PCIe и CPU, а не только вычислительные блоки.

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

Некоторые нагрузки лучше оставить на целой карте

Не делите ускоритель, если одна задача уже стабильно насыщает вычисления или память и ее срок выполнения имеет цену. Обучение крупной модели, научный расчет с плотным обменом и большой пакетный рендер часто получают от соседа только вариацию времени. Планировщик не создает дополнительную емкость.

Задания с жестким p99 тоже плохие соседи для time slicing. Даже небольшая фоновая работа может попасть в неудачный момент. MIG помогает закрепить ресурсы, но маленький профиль должен выдерживать пик сервиса самостоятельно. Если это требует почти всей карты, разделять больше нечего.

Недоверенные арендаторы требуют более сильной границы, чем MPS или обычные контейнеры с временным доступом. Документация NVIDIA GPU Operator прямо противопоставляет time slicing аппаратной изоляции памяти и отказов в MIG. Для разных юридических лиц, чувствительных данных или строгого разделения обязанностей используйте поддерживаемую виртуализацию и аппаратные границы, а затем отдельно проверяйте модель угроз. Слово «контейнер» не доказывает изоляцию GPU.

Не смешивайте производственный сервис с экспериментом, который может скомпилировать неожиданное ядро, занять всю память или вызвать сброс устройства. Отдельный MIG-экземпляр уменьшает взаимное влияние, но не устраняет общие компоненты сервера, питание, драйвер и окно обслуживания. Критичные службы должны переживать потерю всей физической карты.

Популярная рекомендация «включить восемь реплик, потому что средняя загрузка низкая» неверна. Число реплик в Kubernetes сообщает планировщику, сколько потребителей можно допустить, но не резервирует каждому восьмую часть вычислений или памяти. Начинайте с числа одновременно безопасных профилей, найденного нагрузочным тестом, а не с желаемой плотности.

Пилот должен воспроизводить конфликт

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

Сначала снимите базовую линию для каждой задачи на целой карте. Зафиксируйте пропускную способность, p95 и p99, полное время партии, максимальную видеопамять, потребление энергии и ошибки. Затем повторите тот же набор совместно, не меняя версии моделей и размер входных данных. Иначе вы сравните разные эксперименты.

Для быстрой диагностики на NVIDIA полезен реальный поток nvidia-smi dmon. Руководство утилиты указывает, что группа u показывает загрузку SM, памяти, encoder, decoder, JPEG и OFA, а группа m выводит framebuffer и BAR1:

nvidia-smi dmon -i 0 -s pucvm -d 1

Ожидайте строку на каждый интервал с идентификатором GPU и столбцами питания, температуры, загрузки, частот и памяти. Это не трассировщик ядер и не распределяет вину идеально, но быстро показывает, что совпало по времени. Для постоянного наблюдения DCGM Exporter публикует, среди прочего, DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_FB_USED, DCGM_FI_PROF_DRAM_ACTIVE, счетчики PCIe и XID-ошибки. Руководство DCGM предупреждает, что доступность полей зависит от GPU, драйвера и режима MIG.

Если проверяете time slicing в Kubernetes, сделайте общий ресурс видимым в имени. Такой фрагмент основан на формате NVIDIA device plugin и не создает изоляцию памяти:

version: v1
sharing:
  timeSlicing:
    renameByDefault: true
    failRequestsGreaterThanOne: true
    resources:
      - name: nvidia.com/gpu
        replicas: 2

renameByDefault помогает отличать общий ресурс, а failRequestsGreaterThanOne блокирует ложное ожидание, что запрос нескольких реплик даст пропорционально больше мощности. После применения проверьте labels, Capacity и Allocatable узла, затем запустите конфликтующие профили.

Тест отказа обязателен. Доведите один участник до контролируемой ошибки памяти, завершите его процесс, перезапустите контейнер и проверьте соседей. Запишите, что видит мониторинг и сколько занимает восстановление. Если команда не может связать деградацию с владельцем и быстро освободить устройство, высокая плотность превратится в ночные ручные разборы.

Решение принимает экономика эксплуатации

Сравнивайте не цену одной карты с ценой двух, а годовую стоимость двух рабочих вариантов. Для общего ускорителя сложите карту и сервер, лицензии vGPU при их наличии, работу по интеграции, мониторинг, резерв на отказ, окна перенарезки и время дежурной команды. Для раздельного варианта учтите дополнительные карты, слоты, питание, охлаждение, сеть и простой каждой карты.

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

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

Назначьте владельца емкости. Он должен утверждать новые классы задач, хранить результаты базовых замеров и решать, кого ограничивать при конфликте. Без этого каждая команда оптимизирует собственное время, а общий узел постепенно получает больше обещаний, чем может выполнить. Полезна простая ведомость на один профиль: владелец, модель и версия, максимум памяти, приоритет, разрешенные часы, цель p99 или срок партии, поведение при вытеснении и контакт дежурного.

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

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

При проектировании AI- и дата-центровой инфраструктуры GSE может сопоставить серверную платформу, ускорители NVIDIA или AMD и схему сопровождения с измеренными профилями нагрузки. Сам выбор режима все равно должен опираться на пилот заказчика: аппаратная совместимость не доказывает экономию.

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