MIG и разделение GPU для инференса: лимиты и емкость

Задача: одна GPU, несколько сервисов и предсказуемый отклик

Одна мощная GPU часто простаивает, если на ней работает только один сервис инференса. Командам хочется разместить на той же карте еще 2-3 модели: чат-бот, классификатор документов, распознавание изображений. Это дешевле и проще в эксплуатации, особенно когда GPU в дефиците или закупка идет по длинному циклу.

Проблема начинается там, где совместное использование не управляется. Один сервис получает всплеск трафика, забивает очередь на GPU, и у остальных растет время ответа. Снаружи это выглядит как "вчера было 200 мс, сегодня 2 секунды", хотя код не менялся. Еще хуже, когда тяжелая модель периодически занимает почти всю память и валит соседей ошибками out of memory.

Для инференса "емкость" - это не абстрактные TFLOPS, а понятные показатели, которые видит пользователь и мониторинг: сколько запросов в секунду вы держите при заданном SLA, какие задержки p95/p99, как ведет себя очередь под пиком и есть ли ошибки или таймауты.

Предсказуемый отклик означает простую вещь: при росте нагрузки сначала растет очередь (и метрики это показывают), а не происходит хаотичный скачок latency из-за конкуренции за ресурсы. Разделение GPU (например, через MIG) как раз про то, чтобы дать каждому сервису понятную долю вычислений и памяти и снизить взаимное влияние.

При этом MIG подходит не всегда. Он доступен не на каждой GPU и требует поддержки со стороны драйверов и платформы. Даже при MIG остается общий контур (питание, охлаждение и часть узлов), который влияет на стабильность. Есть и сценарии, где жесткие разделы мешают: если один сервис должен иногда забирать всю карту под редкие большие батчи, разрезка ухудшит его максимальную производительность. Поэтому сначала формулируют SLA (например, p95 < 300 мс) и профиль нагрузки, и только потом решают, делить карту или выделять отдельную GPU.

Что такое MIG и чем он отличается от других способов разделения

MIG (Multi-Instance GPU) - режим, в котором одна физическая GPU делится на несколько аппаратно изолированных разделов. Для инференса это удобно, когда на одной карте живут разные сервисы и важно, чтобы они не мешали друг другу.

Каждый MIG-раздел получает выделенную часть памяти и выделенную долю вычислительных ресурсов. Изоляция идет на уровне железа: один сервис не может внезапно "съесть" всю память или забить вычисления так, что остальные резко замедлятся.

MIG часто путают с более простыми подходами:

• Несколько процессов на одной GPU - быстро, но без гарантий. Конкуренция за память, кэш и вычисления легко дает скачки latency.
• MPS (Multi-Process Service) помогает лучше загрузить GPU и снизить накладные расходы, но изоляция слабее. Это скорее совместное использование, чем жесткие границы.
• MIG дает более стабильное поведение, потому что делит ресурсы аппаратно.

MIG особенно полезен, когда на одной карте живут несколько API с разными SLA. Например, чат-боту нужен быстрый отклик 200-400 мс, а пакетной классификации документов терпимо 2-3 секунды. Без изоляции "пакетный" сервис в пике может вытеснить "быстрый" и испортить пользовательский опыт.

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

Проверяем, подходит ли железо и окружение

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

Какие GPU поддерживают MIG и почему это важно

MIG есть у части серверных ускорителей NVIDIA, в первую очередь у A100, H100 и A30 (и некоторых близких модификаций). Смысл поддержки ровно в этом: одна физическая GPU делится на изолированные экземпляры с выделенными ресурсами. Для инференса это дает более предсказуемое время ответа, потому что соседний сервис не может внезапно забрать всю память или вычисления.

Что еще должно совпасть в окружении

Даже с правильной GPU MIG может не заработать из-за софта. Проверьте драйвер NVIDIA нужной версии, совместимость с вашей ОС и наличие утилит управления (минимум nvidia-smi). В контейнерной среде дополнительно важны NVIDIA Container Toolkit и корректный runtime, иначе разделы MIG могут не быть видны в контейнерах.

MIG чаще всего используют в стойковых серверах и кластерах (в том числе в Kubernetes), где на одной GPU живут несколько моделей или несколько команд. Например, на сервере уровня GSE S200 можно закрепить отдельный MIG-инстанс под чат-бота, другой под OCR, третий под ранжирование, и у каждого будут свои границы.

Перед стартом полезно сделать короткую инвентаризацию:

• модель GPU и наличие поддержки MIG
• объем памяти GPU и текущая загрузка
• версии драйвера, CUDA (если нужна), ОС
• где запускаете инференс: bare metal, виртуализация или Kubernetes
• какие модели и их требования: размер весов, тип точности, ожидаемый QPS и SLA по latency

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

Планирование начинается с ответа на вопрос, что именно вы хотите изолировать. Чаще всего "единица" разделения - это сервис (одна точка входа и один SLA). Но иногда логичнее делить по моделям (тяжелая LLM отдельно, легкая классификация отдельно) или по клиентам, если важно, чтобы один заказчик не влиял на задержку другого.

Практичный прием - разделить трафик на "быстрый" и "фоновый". Быстрый получает гарантированный кусок GPU, минимальную очередь и строгие лимиты на batch. Фоновый живет в отдельном разделе (или на меньшем профиле) и может копить очередь, если ресурсы заняты.

Дальше прикиньте нагрузку от модели: размер весов и активаций, максимальный batch size, точность (FP16/INT8) и частоту пиков. Память часто становится ограничителем раньше вычислений. Если модель едва помещается, маленький MIG-раздел приведет к OOM или заставит снижать batch, а это ударит по пропускной способности.

Короткая проверочная схема:

• для каждого сервиса зафиксировать SLA по latency и целевой RPS
• оценить память: модель плюс запас на batch и рост очереди
• решить, что важнее: стабильный p95/p99 или максимальная общая утилизация
• выбрать профили MIG так, чтобы "быстрый" сервис не конкурировал с фоновым
• оставить резерв под пики, прогрев и обновления модели

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

Пошагово: включаем MIG и создаем разделы

Перед стартом убедитесь, что GPU поддерживает MIG (например, A100, A30, H100), и установлены драйвер NVIDIA и утилиты управления. Самый быстрый способ проверить состояние - убедиться, что система видит GPU и нет ошибок.

nvidia-smi
nvidia-smi -q | grep -i mig -n

1) Включаем MIG и проверяем, что режим активен

Включение MIG делается на уровне GPU и обычно требует сброса (reset) или перезапуска узла, чтобы режим применился чисто.

# включить MIG режим
sudo nvidia-smi -i 0 -mig 1

# проверить
nvidia-smi -i 0 -q | sed -n '/MIG Mode/,+3p'

Если видите, что MIG Mode: Enabled, можно переходить к созданию инстансов.

2) Создаем GPU-инстансы (профили) и убеждаемся, что они появились

Сначала посмотрите, какие профили доступны для вашей модели. Затем создайте нужные срезы под сервисы (например, один побольше для тяжелой модели и два поменьше для легких).

# список доступных профилей
nvidia-smi mig -lgip

# создать GPU instances по выбранным профилям (пример)
sudo nvidia-smi mig -cgi 19,14,14 -C

# посмотреть, что получилось
nvidia-smi mig -lgi
nvidia-smi mig -lci

Проверьте, что появились MIG устройства (UUID). Это то, к чему вы будете привязывать конкретный сервис.

3) Закрепляем сервис за конкретным MIG-инстансом

На уровне запуска самый простой способ - передать нужный MIG UUID через переменную окружения.

# пример: закрепить процесс только за одним MIG устройством
export CUDA_VISIBLE_DEVICES=MIG-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
./your_inference_service

4) Делаем так, чтобы настройки переживали перезапуск

Разметка MIG часто сбрасывается после перезагрузки. Практичный подход - хранить команды создания в systemd unit или скрипте и запускать при старте узла. В Kubernetes это обычно делает NVIDIA GPU Operator, если включена стратегия MIG. Даже тогда полезно документировать выбранные профили и проверять их после обновлений драйвера.

Лимиты и изоляция: что ограничивать и где

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

Что действительно важно ограничить

Для инференса чаще всего "падает" не по вычислениям, а по памяти и по конкуренции запросов. Поэтому сначала думайте про VRAM, а затем про параллелизм и очереди.

Обычно критично контролировать:

• память GPU (VRAM): сколько сервис может занять и что будет при пике
• конкуренцию запросов: сколько одновременных запросов допускаете, чтобы не раздувать latency
• настройки инференс-сервера: число worker-ов/instance-ов модели, batch, таймауты
• защиту от "шумных соседей": сервис, который принимает слишком много запросов или слишком тяжелые

Где задавать ограничения

На уровне MIG вы фиксируете кусок GPU: сервис видит не всю карту, а свой раздел. Это хорошо защищает по VRAM и сильно снижает риск взаимных помех. Дальше важна прикладная дисциплина: даже в выделенном разделе можно устроить очереди, если разрешить слишком много параллельных запросов.

Рабочая схема выглядит так:

• GPU (MIG): закрепить профиль раздела под сервис и не менять его без теста
• оркестратор: запросить конкретное MIG-устройство и поставить лимиты CPU и RAM, чтобы препроцессинг не стал узким местом
• инференс-сервер: ограничить concurrency, задать таймауты и max batch, включить backpressure

Пример из жизни: сервис с "мелкой" моделью внезапно получает в 5 раз больше запросов. Он не должен выжать соседний сервис с жестким SLA по отклику. MIG удержит границы по GPU, а лимит параллелизма и очередь на входе не дадут latency улететь в секунды. Такие настройки удобно проверять на стенде, например на серверных платформах уровня GSE S200 Series, где можно повторить профиль нагрузки, близкий к продовому.

Метрики: что измерять, чтобы понимать емкость

Когда вы делите GPU между сервисами, важно отвечать на простой вопрос: сколько запросов вы реально держите при нужной задержке. Для этого мало смотреть на график "GPU занята". Нужны метрики по GPU, очередям и самому сервису.

Базовый набор метрик

Собирайте минимум следующее и смотрите в динамике:

• GPU utilization и загрузку SM
• использование памяти GPU и частоту OOM
• длину очереди запросов и время ожидания в очереди
• latency p50, p95, p99 и отдельно время инференса (без очереди)
• ошибки: таймауты, 5xx, отмены запросов, ретраи

"GPU загружена" не всегда значит "сервис перегружен". GPU может быть занята фоновыми задачами, неудачной батчинг-логикой или ожиданием данных. И наоборот: сервис может задыхаться при невысокой загрузке GPU, если упирается в CPU препроцессинг, сеть или блокировки.

Очередь читается так: если входной поток стабильный, а бэклог растет, значит пропускной способности не хватает. Если очередь почти нулевая, но p95/p99 скачут, часто виноват джиттер: прогрев модели, конкуренция потоков, нестабильный ввод-вывод.

Несколько быстрых признаков для диагностики:

• GPU utilization низкая, а latency растет: ищите узкое место в CPU, сети или диске
• память GPU на пределе: проверьте размер модели, batch size и фрагментацию
• очередь растет, а время инференса стабильно: не хватает выделенной доли MIG или слишком строгие лимиты
• таймауты при нормальной GPU: проверьте балансировщик, лимиты соединений, размер пулов

В инфраструктуре, где используются серверы и интеграционные проекты уровня GSE.kz, удобно сразу разделять метрики по инстансам MIG, по подам и по сервисам. Тогда емкость видна не по ощущениям, а по цифрам: где копится очередь и что именно ломает SLA.

Как измерить емкость через очереди запросов и время ответа

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

Упрощенная модель такая: если среднее время обработки одного запроса - T, то один воркер не может стабильно держать больше чем примерно 1/T запросов в секунду. В реальности добавляются накладные расходы (батчинг, копирование, конкуренция за память), поэтому точку срыва нужно измерять.

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

• увеличивайте RPS по шагам (например, +10-20% за шаг) и держите 5-15 минут
• на каждом шаге фиксируйте p50/p95/p99 latency, throughput (фактический RPS), длину очереди и процент ошибок/таймаутов
• отделяйте warm-up период (первые минуты) от стабильной части интервала
• повторите тест в "плохом" сценарии: более тяжелые запросы или максимальный размер батча

Графики обычно читаются так: throughput растет почти линейно до определенного плато, а затем перестает расти, хотя вы добавляете нагрузку. В этот момент latency начинает подниматься (особенно p95/p99), а очередь перестает возвращаться к нулю между всплесками. Это и есть практическая граница емкости для выбранной конфигурации (MIG-слайс, число воркеров, размер батча, модель).

В итоговый документ лучше писать не "максимум RPS", а формулировку, которую можно использовать в SLA и планировании: "сервис A держит N RPS при p95 < X мс (и p99 < Y мс), без ошибок, очередь не растет". Так проще сравнивать разные профили MIG и понимать, сколько сервисов реально уживется на одной GPU без сюрпризов.

Пример: делим одну GPU между тремя сервисами с разными SLA

Представим один сервер с одной GPU (например, в стойке на базе GSE S200), и три инференс-сервиса делят ее одновременно: чат-бот, классификация и OCR. У них разные требования по задержке: чат-боту важен быстрый ответ пользователю, классификации важнее стабильная пропускная способность, а OCR часто идет пачками и терпит чуть большую задержку.

Типичная логика разрезки такая: самый чувствительный к latency сервис получает отдельный, не слишком маленький раздел (чтобы не жить в постоянной очереди), а пакетные нагрузки получают более мелкие или средние разделы.

Пример схемы для GPU с поддержкой MIG:

• чат-бот: средний MIG-профиль, чтобы держать низкий p95 даже при всплесках
• классификация: небольшой профиль с возможностью масштабирования по репликам
• OCR: небольшой или средний профиль, если часто бывают большие изображения или длинные документы

Лимиты стоит ставить не только за счет выделенного раздела, но и на уровне сервиса: ограничьте максимальную параллельность (concurrency) и размер batch. Иначе один сервис будет копить очередь внутри себя, и вы увидите рост задержки, хотя GPU еще не на 100% загружена.

В первые дни полезно держать перед глазами несколько метрик, которые быстро показывают реальную емкость:

• p50/p95/p99 latency по каждому сервису
• длина очереди запросов (в приложении или на входе в сервис)
• доля ошибок и таймаутов
• загрузка GPU и память по каждому MIG-инстансу
• время ожидания в очереди отдельно от времени выполнения

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

Частые ошибки и ловушки

Самые неприятные проблемы обычно не в самих командах разметки, а в ожиданиях: кажется, что каждый сервис получит ровно "свою" производительность. На практике многое решают память, характер запросов и то, как вы измеряете задержки.

Ошибка 1: нарезали слишком мелко

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

Признак простой: модель загружается, но при реальном трафике начинаются частые OOM, падение batch size и резкие скачки времени ответа.

Ошибка 2: смешали разные SLA в одном разделе

Когда в одном разделе живут запросы "срочно, p99 должен быть низким" и "можно подождать", вы почти гарантированно получите дерганый p99. Длинные запросы забивают очередь, и быстрые начинают ждать.

Пример: сервис A отвечает на короткие запросы с жестким SLA, сервис B делает редкие, но тяжелые. Если они делят один раздел, несколько запросов B подряд ухудшат p99 у A, даже если среднее выглядит нормально.

Ошибка 3: смотрят только среднее latency

Среднее время ответа часто "успокаивает", но пользователи чувствуют хвосты. Для инференса важнее p95/p99 и время в очереди. Если p99 растет, значит вы близки к перегрузке или уже в ней, даже если среднее держится.

Ошибка 4: узкое место не в GPU

Иногда MIG настроен корректно, но тормозит CPU-препроцессинг, постпроцессинг, сеть или диск (например, подкачка, логирование, загрузка больших входов). Тогда вы будете резать GPU дальше и дальше, а результата нет.

Быстрая проверка: GPU недозагружен, а очередь растет. Или наоборот: GPU загружен, но основная задержка сидит до отправки на GPU.

Ошибка 5: нет защиты от пиков

Даже с MIG сервис может "сыпаться", если нет ограничений на входящий поток: очередь раздувается, растет время ожидания, копятся таймауты, и начинается лавина повторных запросов.

Помогают базовые меры:

• лимит на максимальную длину очереди (или время ожидания)
• backpressure: отказ или деградация при перегрузке
• отдельные очереди для разных классов запросов
• понятные таймауты на клиенте и на сервере
• прогрев и предсказуемый batch (если он используется)

MIG дает изоляцию по GPU-ресурсам, но предсказуемость появляется только когда трафик разделен по SLA, а вы смотрите не только на среднее, но и на хвосты и очередь.

Короткий чеклист перед запуском в прод

Перед тем как включать MIG в бою, пройдитесь по базовым вопросам. Это занимает час-два, но обычно экономит дни разборов после релиза.

Что должно быть ясно до первого прод-трафика

Нужны не формулировки "модель отвечает быстро", а конкретные числа, которые можно измерить и защитить:

• список сервисов и их SLA: p95/p99 по времени ответа, допустимый процент ошибок, таймауты клиента
• оценка памяти: вес модели плюс пики на активациях, кэше и батчах; стартовые batch size и concurrency
• набор метрик и алертов: очередь, время ожидания в очереди, end-to-end latency, ошибки, загрузка GPU/CPU, память GPU
• результаты нагрузочного теста по ступенькам: при каком QPS/конкурентности растет очередь, где p99 уходит за SLA, где начинаются OOM или троттлинг
• план реакции на перегрузку: что делаете первым действием (ограничение concurrency, снижение batch, деградация качества, перенос части трафика, переразрезка MIG, добавление еще одной GPU)

Быстрая проверка на реалистичность

Проверьте сценарий: один сервис внезапно получает в 3 раза больше запросов. Он не должен "съесть" весь ускоритель и утопить соседей. Это значит, что лимиты по конкуренции и таймауты включены, а очередь и p99 видны на дашборде.

Если эти пункты закрыты, запуск в прод становится контролируемым экспериментом: вы заранее знаете, где упретесь в емкость, и что менять, когда это случится.

Следующие шаги: пилот, стандарты и поддержка инфраструктуры

Самый безопасный старт - пилот на одном узле. Возьмите 1-2 самых важных сервиса, включите MIG, задайте фиксированные профили и прогоните нагрузку, похожую на реальную. Цель пилота не в максимальных цифрах, а в предсказуемости: какой throughput вы получаете при заданном latency и где начинает расти очередь.

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

• профиль MIG (и на каком типе GPU проверено)
• сервис/модель и версия, размер batch и ключевые параметры
• допустимая нагрузка: RPS или токены/с, при каких ограничениях
• SLA: p95/p99 latency и максимальная длина очереди
• запас: при каком росте трафика нужен пересмотр разрезки

Пример: вы проверили, что сервис A держит p95 120 мс до 10 RPS, но после 12 RPS очередь растет и p99 уходит за 300 мс. Это понятное правило для алерта и планирования: не спорить о "медленно/быстро", а смотреть на очередь и хвосты latency.

Когда пора отказаться от совместного проживания на одной GPU? Обычно это видно по одному из признаков: хвостовые задержки зависят от соседей, нагрузка стала слишком рваной (частые пики), или стоимость деградации выше, чем стоимость отдельной GPU или узла. Если профили MIG приходится часто менять ради отдельных релизов, это тоже сигнал: проще выделить сервису отдельный ресурс или добавить еще один узел, чем постоянно перекраивать разрезку.

Если нужна помощь с переходом от пилота к промышленной схеме, GSE.kz может закрыть инфраструктурную часть: подобрать и поставить серверы (в том числе линейку S200 Series), собрать стек инференса, настроить мониторинг и обеспечить поддержку 24/7 через сервисную сеть по Казахстану. Это удобно, когда важно быстро закрепить стандарт и не держать всю экспертизу в одной команде.