# ECS переходит от назначения целого GPU к совместному планированию

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

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-10-27
Первоисточник новости: https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-ecs-gpu-sharing-nvidia-mps/
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-ecs-gpu-granularity-mps/

Совместное использование GPU в Amazon ECS меняет единицу выделения с целого устройства на объявленный бюджет задачи. Эксплуатационная возможность — более мелкое размещение совместимой работы. Польза зависит от фактической потребности в памяти и вычислениях, а не от предположения, что каждой задаче безопасно назначить меньшую долю без изменения её полезного поведения и режима исполнения.

## Ранний сервис назначал целые GPU

[Объявление GPU для ECS 4 февраля 2019 года](https://aws.amazon.com/about-aws/whats-new/2019/02/gpu-support-for-amazon-ecs-now-available/) установило назначение GPU контейнерным задачам. Это историческая основа октябрьского изменения: задачу связывали с устройством как объектом выделения. Новый подход становится понятным при сравнении именно этой единицы, а не общего обещания улучшить использование вычислительного парка.

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

## Managed Instances добавил цикл хоста

[Объявление Managed Instances 30 сентября 2025 года](https://aws.amazon.com/blogs/aws/announcing-amazon-ecs-managed-instances-for-containerized-applications/) представило управляемый вычислительный путь. Оно дало контекст хостов до распределения общих GPU между задачами. Этот уровень относится к тому, как окружающая инфраструктура появляется и сопровождается, а не непосредственно к объёму ресурсов отдельной модели внутри работающего устройства.

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

## Октябрь ввёл другую границу ресурса

[Релиз 27 октября 2026 года](https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-ecs-gpu-sharing-nvidia-mps/) описывает MPS NVIDIA для ECS на EC2 и Managed Instances с памятью GPU задачи и необязательным вычислительным выделением. Он также касается управления общим сервисом. Новость определяет более точный способ выражения потребности контейнерной работы относительно доступного устройства и окружающего управления.

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

## Описываем задачу перед уплотнением

Иллюстративная запись выделения сохраняет различия:

| Свойство задачи | Вопрос до совместного размещения |
| --- | --- |
| Размещение модели | Какое состояние остаётся в памяти устройства? |
| Переменная работа | Как спрос меняется со смесью запросов? |
| Вычислительная потребность | Какая рабочая точка требуется задаче? |
| Зависимость общего сервиса | Что происходит при изменении сервиса или хоста? |

Это не скрытое правило допуска AWS. Запись определяет подтверждения для превращения мелкого бюджета в полезное размещение. Небольшой средний объём недостаточен, если требуемое пиковое поведение находится вне объявленной области. Такое различие помогает обосновать выбранную долю ресурса, сохраняя связь планирования с тем, какую работу задача должна успешно завершать.

## Оцениваем размещение завершённой работой

Хроника проходит от назначения устройства через управляемые хосты к бюджетам общих задач. Возможность — гибкость размещения при приёмке приложения в выбранной области и соседстве. [Механизмы общего GPU](/ru/journal/gpu-mig-vs-time-slicing/) рассматривают разные границы, а [пропускная способность и задержка](/ru/journal/throughput-latency-tradeoff/) — рабочие компромиссы. Октябрьский этап меняет гранулярность планирования, не обещая универсального ускорения или удешевления каждой нагрузки.