# Почему NUMA-топология стала частью размещения в управляемом Slurm

AWS PCS раскрыл NUMA-топологию и привязку GPU для размещения в Slurm. Локальность стала видимой без обещания универсального ускорения приложений.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-11
Первоисточник новости: https://aws.amazon.com/about-aws/whats-new/2026/09/aws-pcs-gres-hardware-topology-mig/
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-aws-pcs-numa-placement/

AWS PCS сделал топологию узла частью размещения 11 сентября 2026 года. Запрос GPU по-прежнему описывает количество устройств, однако привязка CPU и путь между процессорами и ускорителями показывают, где фактически работает задача. Это разные измерения одного выделения ресурсов, которые нельзя свести к общему числу карт.

## Сначала появился управляемый сервис

[Запуск PCS 28 августа 2024 года](https://aws.amazon.com/about-aws/whats-new/2024/08/aws-parallel-computing-service/) создал управляемую инфраструктуру Slurm. Это уменьшало работу по сопровождению планировщика. Однако управление сервисом не делало вычислительные узлы одинаковыми и не устраняло различие между локальным и удалённым доступом к памяти внутри машины.

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

## Разнообразие оборудования повысило значение топологии

[NVIDIA представила семейство Blackwell RTX PRO 18 марта 2025 года](https://nvidianews.nvidia.com/news/nvidia-blackwell-rtx-pro-workstations-servers-agentic-ai). Анонс семейства оборудования и функция управляемого планирования являются отдельными этапами. Первый не устанавливает, что каждый облачный узел обладает одинаковой схемой CPU или соединениями между устройствами.

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

## Что стало доступно в сентябре

[Обновление PCS](https://aws.amazon.com/about-aws/whats-new/2026/09/aws-pcs-gres-hardware-topology-mig/) добавило поддержку Slurm 26.05, автоматическое определение привязки GPU к ядрам и соединений между GPU. По умолчанию домены NUMA представлены как сокеты. Администратор может переопределить топологию, в том числе использовать домены кэша L3 в качестве сокетов.

Сокет в таком представлении планировщика нельзя автоматически считать обещанием о количестве физических процессорных корпусов. Выбранное представление определяет, как ограничения размещения описывают узел. Его смысл должен оставаться частью записи конфигурации кластера, иначе одинаковое слово будет обозначать разные границы.

## Полезный артефакт выделения ресурсов

Представим пакетную задачу, которая подготавливает входные данные на CPU, а затем передаёт их назначенному GPU. Запись её размещения может содержать следующие поля:

| Поле | На какой вопрос отвечает |
| --- | --- |
| Идентификатор GPU | Какое устройство выделено? |
| Привязка CPU | Какие ядра связаны с ним? |
| Представление NUMA | Что здесь означает сокет? |
| Версия переопределения | Какое решение администратора изменило обнаружение? |

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

## Как изменилась граница решения

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

Материал [NUMA и GPU-серверы](/ru/journal/numa-and-gpu-servers/) раскрывает проблему локальности, а статья [смешанный парк GPU](/ru/journal/mixed-gpu-fleet/) рассматривает неоднородные ресурсы. Вместе они показывают, почему подсчёт ускорителей необходим, но недостаточен для описания размещения.