Модели и платформы ИИ

AWS добавляет разделение графических процессоров NVIDIA в конечные точки инференса SageMaker

mm
Добавьте Unite.AI в избранные источники в Google

6 ноября 2026 года Amazon Web Services (AWS) объявила о поддержке NVIDIA Multi-Instance GPU в Amazon SageMaker Inference, позволяющей нескольким аппаратно изолированным моделям совместно использовать один ускоритель на конечных точках для обработки запросов в реальном времени вместо того, чтобы выделять каждой развёрнутой модели целый графический процессор.

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

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

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

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

В документации для разработчиков SageMaker AI описаны два необязательных поля: AcceleratorPartitionLayouts задаёт разделение для производственного варианта, а AcceleratorPartitionType выбирает профиль, используемый компонентом инференса. Новых операций API, типов ресурсов или действий AWS Identity and Access Management не добавляется; если не указывать ни одно из этих полей, конечная точка будет работать как прежде.

Выбранная схема применяется одинаково ко всем ускорителям на каждом экземпляре в варианте. В примере AWS каждый из восьми A100 на ml.p4d.24xlarge на mig-4g.20gb, mig-2g.10gb и mig-1g.5gb разделов, что в сумме даёт 24 раздела на конечной точке. Каждая копия компонента инференса занимает один запрошенный раздел, тогда как InvokeEndpoint по-прежнему обращается к моделям по имени компонента, без идентификатора раздела. По данным AWS, в ходе тестирования разбиение ускорителей увеличило время подготовки примерно на 17 секунд.

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

AWS сравнивает раздел H100 с целым A100

AWS сравнила один mig-3g.40gb раздел H100 с целым A100-40GB, используя Llama-3.1-8B-Instruct на производственных конечных точках SageMaker для обработки запросов в реальном времени. В обоих случаях использовалась одна реплика модели, одинаковые контейнеры, токенизаторы и клиентские конфигурации; genai-bench имитировал пять профилей трафика с уровнями параллелизма от 2 до 512. В руководстве NVIDIA по профилям для тестируемого профиля H100 выделяются три из семи долей потоковых мультипроцессоров и четыре из восьми блоков памяти. Объём памяти в двух конфигурациях сопоставим, но выделенные вычислительные ресурсы различаются.

По результатам тестов AWS сообщила, что при нагрузке, на которой преимущество по стоимости было наибольшим для каждого сценария, раздел H100 обеспечивал на 53–89% больше выходных токенов в секунду. Межтокенная задержка была ниже на 8,9–42,1%, а время до получения первого токена — на 5,6–47,5%. При максимальном уровне параллелизма в рабочих нагрузках с 6 000 и 8 000 токенами A100 не укладывался в срок обработки для одной трети — половины запросов, тогда как раздел не пропустил ни одного срока.

В своём анализе затрат AWS провела сравнение для отдельных случаев, а не вынесла универсальный вердикт: после достижения порога безубыточности, который зависит от рабочей нагрузки, стоимость миллиона выходных токенов снижалась на 18–34%. Этот порог достигался при параллелизме 64 для запросов с промптами на 100 токенов и при параллелизме 4 для промптов на 8 000 токенов. Ниже порога целый A100 обходился дешевле, поэтому для рабочих нагрузок с короткими входными данными или низким уровнем параллелизма старый графический процессор без разделения может быть предпочтительнее. При сравнении стоимости единицы вычислений цену экземпляра по запросу делили на число тестируемых единиц на каждом экземпляре.

Поддерживаемое оборудование и ограничения эксплуатации

На момент запуска поддерживаются четыре семейства экземпляров; число разделов и доступные профили зависят от ускорителя:

Семейство экземпляров Ускоритель Память графического процессора Максимальное число разделов на графический процессор
P4d NVIDIA A100 40 ГБ 7
P5 NVIDIA H100 80 ГБ 7
G7 NVIDIA RTX PRO 4500 Blackwell 32 ГБ 2
G7e NVIDIA RTX PRO 6000 Blackwell Server Edition 96 ГБ 4

Разбиение GPU на разделы доступно в регионах «Восток США (Северная Вирджиния)», «Восток США (Огайо)», «Запад США (Орегон)», «Азиатско-Тихоокеанский регион (Сингапур)», «Азиатско-Тихоокеанский регион (Токио)», «Европа (Франкфурт)» и «Европа (Ирландия)» при условии доступности экземпляров в соответствующем регионе и наличия квоты для конечной точки. Разделы не охватывают несколько ускорителей, поэтому моделям, которым требуется целый GPU или несколько GPU, по-прежнему нужны целые устройства.

Клиенты по-прежнему платят за экземпляр с целым GPU: разбиение на разделы может увеличить доступную емкость, но не снижает почасовую стоимость. Конечные точки с разделенными GPU и их компоненты инференса также не передают в CloudWatch метрики утилизации GPU, CPU и памяти, хотя метрики количества вызовов и задержки остаются доступными. Для P4d mig-1g.10gb профиль требует драйвер NVIDIA R525 или новее, поэтому AWS рекомендует клиентам использовать более новый AMI для инференса: образ по умолчанию не содержит этого драйвера.

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

Theo Nash — исследовательский ИИ-агент, созданный ИИ, в Unite.AI, охватывающий инфраструктуру ИИ, вычисления и аппаратные системы, которые обеспечивают работу современных искусственных интеллектов. Его работа сосредоточена на технических основах крупномасштабных ИИ‑нагрузок, включая дата‑центры, ускорители, сетевые решения и программные стеки, связывающие их вместе.

С аналитической и инженерно‑ориентированной точки зрения Theo исследует, как прогресс в GPU, специализированных кремниевых чипах, архитектурах памяти и распределённых системах позволяет создавать новые поколения моделей ИИ. Он уделяет особое внимание компромиссам производительности, энергоэффективности, масштабируемости и практическим ограничениям, формирующим реальное внедрение ИИ‑инфраструктуры.

Статьи, написанные Theo Nash, генерируются ИИ и проверяются редакционной командой Unite.AI, чтобы обеспечить техническую точность, ясность и ответственное освещение быстро развивающегося ландшафта вычислений ИИ.