Amazon SageMaker Inference получил поддержку NVIDIA Multi-Instance GPU (MIG): один физический ускоритель делится на аппаратно изолированные партиции, и в каждой может работать своя модель. Схему деления задаёт поле AcceleratorPartitionLayouts в конфигурации эндпоинта, а выбор партиции под конкретную модель - поле AcceleratorPartitionType в inference component.
Практический смысл простой. Раньше минимальной единицей GPU был целый ускоритель, теперь можно взять его долю. Для эндпоинта с несколькими небольшими моделями это меняет и плотность размещения, и счёт за железо. Выгода не гарантирована: при коротких промптах и низкой конкурентности целый A100-40GB остаётся дешевле партиции mig-3g.40gb на H100, о чём AWS пишет прямо в разборе новой функции.
Работает это не везде. Нужны эндпоинты на inference components, инстансы семейств P4d, P5, G7 или G7e, а число партиций ограничено семью на GPU и зависит от ускорителя. Дальше - как устроен механизм, как считать профиль партиции и где MIG проигрывает альтернативам.
Зачем делить GPU: проблема, которую решает MIG
Без разбиения минимальная единица GPU, которую можно запросить под модель, - целый ускоритель. На ml.p4d.24xlarge стоят восемь A100, значит эндпоинт вмещает восемь моделей: и когда каждой нужно 40 ГБ, и когда хватает 14 ГБ. Разница в памяти уходит в никуда.
Картина знакомая: три-четыре небольшие модели, каждая на отдельном крупном ускорителе, загрузка заметно ниже возможной. Второй эффект касается выбора железа. Нужна доля нового ускорителя - приходится брать целый, пусть и предыдущего поколения.
MIG меняет единицу измерения. Один GPU режется на партиции, каждая получает фиксированную долю вычислительных блоков и выделенный блок памяти, изоляция держится на уровне аппаратуры. NVIDIA ограничивает число инстансов семью на GPU, точное количество и размеры зависят от модели ускорителя.
Изоляция в железе - ключевая деталь. Тяжёлый запрос к одной модели не отбирает вычисления у соседней по партиции, а в сценарии с несколькими тенантами это важнее пиковой утилизации.
Что такое NVIDIA MIG и как он работает в Amazon SageMaker
MIG - механизм NVIDIA. SageMaker добавил к нему управление через API: разбиение настраивается на уровне эндпоинта и компонентов, без ручной работы с драйверами и device plugin.
Условие одно, но жёсткое: разбиение доступно только на эндпоинтах, которые используют inference components. Это конструкция для развёртывания нескольких моделей на одном эндпоинте с настройкой вычислений под каждую модель. На single-model и serverless-эндпоинтах, а также на гетерогенных пулах инстансов партиций не будет.
Партиция как ресурс inference component
Inference component уже умеет запрашивать CPU и память. Партиция стала ещё одним ресурсом в том же запросе: компонент просит её там же, где просит остальное. Планирование размещения моделей остаётся в привычном механизме, отдельный оркестратор не нужен.
Если inference components уже работают в продакшене, схема развёртывания не ломается. Стоит освежить смежные настройки: как компоненты распределяются по зонам доступности и что даёт SPREAD-стратегия размещения. Плотная упаковка моделей на одном инстансе повышает цену ошибки в планировании.
Настройка: AcceleratorPartitionLayouts и AcceleratorPartitionType
Полей два, оба опциональные, и работают они на разных уровнях. Первое описывает, как нарезано железо. Второе определяет, что из этой нарезки достаётся модели.
Layout на эндпоинте: схема деления GPU
AcceleratorPartitionLayouts в конфигурации эндпоинта задаёт схему деления каждого GPU. Фактически это описание того, какие партиции существуют на инстансе. От layout зависит, какие профили вообще доступны моделям: если в схеме нет крупной партиции, привязать к ней модель не получится.
Partition type в компоненте: что получает модель
AcceleratorPartitionType в inference component определяет, какую именно партицию получает конкретная модель. Для H100 это может быть mig-3g.40gb. Модель запрашивает партицию как ресурс, и сумма запросов всех компонентов не должна выходить за то, что описано в layout.
Точный синтаксис запросов AWS в публикации не приводит: там объясняется назначение полей и логика связки, а не готовый JSON. Перед написанием конфигурации сверяйтесь с документацией API, чтобы не угадывать имена вложенных параметров.
Как выбрать профиль партиции под модель
Ошибка номер один - считать только веса. Партиция, в которую модель влезла по параметрам, может не выдержать реальную нагрузку из-за KV-кэша и служебных буферов.
Веса, KV-кэш и накладные расходы
Бюджет памяти складывается из трёх частей. Веса фиксированы и зависят от числа параметров и формата хранения. KV-кэш растёт с длиной контекста и числом одновременных последовательностей: при длинных промптах и высокой конкурентности его объём может сравняться с весами или превысить их. Накладные расходы - рантайм, служебные буферы, фрагментация.
Порядок расчёта: веса, затем KV-кэш под целевые длины контекста и число параллельных запросов, затем запас на накладные расходы. Итог сравнивается с памятью партиции, а не с памятью всего GPU. Если бюджет VRAM считается впервые, пригодится разбор того, как уложить крупную MoE-модель в память одной карты: там показана логика распределения памяти между весами и кэшем.
Ориентир из замеров AWS: партиция mig-3g.40gb на H100 обслуживает Llama-3.1-8B-Instruct. Цифра полезна как точка отсчёта. 8B-модель класса Llama помещается в партицию на 40 ГБ, а сколько останется под KV-кэш, зависит от длины контекста и батча.
Сколько партиций имеет смысл
Максимум - семь партиций на GPU, и это верхняя граница, а не цель. Чем больше партиций, тем больше моделей помещается на инстансе и тем меньше памяти и вычислений достаётся каждой. Выбор идёт между плотностью размещения и производительностью отдельной модели.
Раскладка из семи мелких партиций оправдана для парка лёгких моделей с умеренным контекстом. Для модели с длинным контекстом или высоким трафиком лучше взять одну крупную партицию, даже если часть инстанса достанется соседям. Доступные профили и их число зависят от ускорителя, проверять по документации конкретного семейства инстансов.
Когда MIG выигрывает, а когда целый GPU дешевле
Публичное сравнение на момент выхода функции одно: тест AWS на Llama-3.1-8B-Instruct, партиция mig-3g.40gb на H100 против целого A100-40GB. Партиция дала более высокую пропускную способность и меньшую задержку. При коротких промптах и низкой конкурентности целый A100 оставался дешевле.
Читать это надо как два разных сценария, а не как общий вывод «MIG быстрее». Исход определяют профиль нагрузки и число моделей на эндпоинте.
Сценарии, где MIG окупается
- Несколько моделей на одном эндпоинте: портфель fine-tuned вариантов, отдельные модели под тенантов, разные задачи вроде чата и извлечения сущностей.
- Высокая конкурентность и длинные промпты: там, где целый ускоритель предыдущего поколения проигрывает по пропускной способности.
- Нужна изоляция: тяжёлый запрос к одной модели не должен бить по задержке соседней.
- Нужна доля нового ускорителя: партиция H100 вместо целого A100.
Сценарии, где MIG проигрывает
- Короткие промпты и низкая конкурентность: целый A100-40GB дешевле.
- Одна модель на эндпоинт: делить нечего, выгода от партиций не появляется.
Отдельно про метрики. Фраза «пропускная способность выросла» имеет смысл только с указанием профиля нагрузки: длин промптов и ответов, числа одновременных запросов, SLA по задержке. Как читать заявления об эффективности GPU и какие цифры за ними стоят, разобрано в материале про «100% эффективности GPU».
Ограничения и совместимость
Список короткий, и каждый пункт способен заблокировать планы:
- Только эндпоинты на inference components.
- Single-model эндпоинты, serverless-эндпоинты и гетерогенные пулы инстансов разбивать нельзя.
- Семейства инстансов: P4d, P5, G7, G7e.
- Число и размеры партиций зависят от ускорителя, максимум семь на GPU.
Если инфраструктура построена на serverless или на single-model эндпоинтах, MIG не подключить без смены схемы развёртывания. Это стоит посчитать заранее: переезд на inference components сам по себе меняет управление копиями моделей и их масштабированием.
Альтернативы MIG: multi-model endpoints, батчинг, Kubernetes
Разбиение GPU - не единственный способ поднять утилизацию. AWS в публикации перечисляет три альтернативы, и у каждой своя цена.
Меньше крупных эндпоинтов с более интенсивным батчингом. Утилизация растёт, но только если модели взаимозаменяемы. Для портфеля fine-tuned вариантов или моделей по тенантам приём не работает: разнородные модели в один батч не собрать.
Multi-model endpoints. Модели загружаются и выгружаются с общего GPU по требованию. Подходит для редкого bursty-трафика. Минусы: изоляции нет, тяжёлый запрос к одной модели влияет на другие, а незагруженная модель платит штраф за загрузку при первом обращении.
Self-managed Kubernetes с MIG. Разбиение там работает, но вместе с ним приходят версии драйверов, конфигурация партиций, device plugin, планирование и согласованность по всему парку. В SageMaker эту операционную часть берёт на себя сервис.
Полностью бесплатной альтернативы нет: либо теряете изоляцию, либо забираете инфраструктуру к себе.
Чек-лист перед миграцией на MIG
- Проверить, что эндпоинт построен на inference components. Если нет, оценить стоимость перехода.
- Сверить семейство инстанса: P4d, P5, G7 или G7e. Остальные варианты отпадают.
- Посчитать память: веса, KV-кэш под целевые длины контекста и конкурентность, запас на накладные расходы.
- Выбрать число и размеры партиций и описать их в layout эндпоинта.
- Привязать каждую модель к партиции через partition type в inference component.
- Прогнать нагрузочный тест на реалистичной конкурентности и длине промптов, а не на одном запросе.
- Сравнить стоимость с целым GPU на своём профиле нагрузки: цифры AWS получены на Llama-3.1-8B-Instruct и на другие модели автоматически не переносятся.
Последний пункт решает исход чаще остальных. MIG экономит, когда ускоритель делится между моделями с реальной нагрузкой, и проигрывает, когда партиция простаивает рядом с занятой соседкой. Полное описание функции и замеры AWS стоит прочитать до того, как менять layout в продакшене.