ПРОДУКТЫ И ГАДЖЕТЫ

AWS добавила в CloudWatch контроль GPU и AI-ускорителей в EKS

AWS представила CloudWatch Accelerated Compute Insights для контроля GPU, Trainium и Inferentia в кластерах Amazon EKS.

✍️ Редакция iTech News | 12.11.2026 | ⏱ 3 мин | Источник: The New Stack
📡

Один обучающий кластер может работать днями и обходиться в миллионы долларов, но владелец платформы нередко не может быстро ответить, какой именно команде достался конкретный GPU. AWS представила Accelerated Compute Insights в Amazon CloudWatch — инструмент, который должен связать мониторинг GPU в EKS с данными Kubernetes и оценкой затрат. Для российских команд, использующих EKS или строящих похожие внутренние платформы, это ещё один сигнал: ускорители пора учитывать не только по счёту облака, но и по конкретной нагрузке.

Новый режим CloudWatch собирает в одном представлении телеметрию ускорителей, контекст Kubernetes и сведения о стоимости. Как сообщает The New Stack, он рассчитан на NVIDIA GPU, а также фирменные AWS-ускорители Trainium и Inferentia, работающие в Amazon EKS. Заявленная цель довольно приземлённая: увидеть, кто занял устройство, насколько оно загружено, нет ли сбоя и сколько обходится простаивающая или неэффективно используемая мощность.

Это не замена биллингу AWS и не очередной дашборд с красивой диаграммой загрузки кластера. Разница — в привязке метрик к сущностям Kubernetes: подам, пространствам имён и командам. В общем пуле ускорителей именно этой связки обычно не хватает. Финансовый отчёт показывает расход по аккаунту, инженер видит ноду, а руководитель команды обучения уверен, что «всё занято кем-то другим». В результате расследование простоя GPU превращается в ручной квест по логам, планировщику и таблицам с владельцами проектов.

Ускорители плохо переносят такую организационную неопределённость. CPU можно пережить с запасом: лишнее ядро в виртуальной машине неприятно, но редко способно испортить квартальный бюджет. GPU и специализированные чипы дороже, их часто делят между несколькими командами, а дефицит ресурса быстро становится конфликтом между разработкой, ML-инженерами и финансами. Мониторинг GPU в EKS на уровне рабочей нагрузки помогает отделить реальный дефицит от привычного «кластер занят».

Особенно важен сценарий с частичным использованием устройства. В Kubernetes один физический GPU может быть разделён между нагрузками, в том числе через MIG — механизм NVIDIA для изоляции экземпляров GPU. Если на уровне облачной виртуальной машины виден только сам ускоритель, платформа рискует принять неверное решение: перезапустить всю ноду из-за одной проблемной задачи или купить ещё ресурсов, хотя часть имеющихся разделов простаивает. Device-level-наблюдаемость должна показать, где именно находится сбой или незанятая ёмкость.

Для ML-команд полезны и более неприятные вопросы, которые наконец можно задать данным. Действительно ли обучение эффективно использует выделенные ускорители? Не удерживает ли эксперимент GPU после завершения? Не работает ли inference-эндпоинт с запасом, который не соответствует трафику? Ответы не гарантируют мгновенной экономии: иногда простаивающий ресурс нужен для пиков или экспериментов. Но без измерения такие решения выглядят как инженерная интуиция с очень дорогим ценником.

Платформенным командам инструмент также меняет разговор с внутренними заказчиками. Вместо запроса «нам срочно нужны ещё восемь GPU» можно обсуждать конкретные поды, длительность использования и фактическую загрузку. Для chargeback или showback это критично: распределять расходы по командам разумнее по рабочим нагрузкам, а не по самому громкому пользователю общего кластера. При этом метрики не снимают главной задачи — определить правила квот, приоритетов и отключения забытых задач. Они лишь дают основу, на которой эти правила можно защищать без гадания.

В российском контексте решение AWS прежде всего интересно как архитектурный ориентир, а не как универсальный рецепт: не каждая компания использует EKS, а набор доступных ускорителей и облачных сервисов различается. Принцип остаётся тем же для любого Kubernetes-кластера: связывать телеметрию устройства с владельцем, задачей и стоимостью. Иначе расходы на AI-инфраструктуру будут расти быстрее, чем способность объяснить их бизнесу.

Следующий спор вокруг AI-кластеров будет не о том, где взять ещё ускорителей, а о том, кто доказал необходимость уже выделенных. Чем больше GPU становятся общей инфраструктурой, тем ценнее оказывается наблюдаемость на уровне пода, а не на уровне очередного счёта. Подробности анонса опубликованы в материале The New Stack.

Поделиться: Telegram X LinkedIn