Мониторинг загрузки GPU-кластера — какие показатели снимают и зачем

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

Ниже — какие показатели снимают с узла и с кластера, как они связаны между собой, какие картины встречаются чаще всего и что из этого следует для конфигурации. Подбор и поставка ускорителей — в разделах GPU NVIDIA и GPU MetaX.

Что снимается с ускорителя

• Загрузка вычислительных блоков. Доля времени, когда на ускорителе выполнялась хотя бы одна операция. Показатель грубый: он не различает полную загрузку и единственное мелкое ядро.
• Занятая и доступная видеопамять. Пиковое и среднее значение. Именно память чаще всего ограничивает размер модели и величину пакета данных.
• Пропускная способность памяти. Доля от паспортной. Высокая загрузка блоков при низкой пропускной способности означает, что расчёт упирается в вычисления; обратная картина — что в доступ к памяти.
• Потребляемая мощность. Косвенный, но честный показатель реальной работы: ускоритель, простаивающий в ожидании данных, потребляет заметно меньше предельного значения.
• Температура и режим ограничения. Частота снижается при перегреве или при достижении предела по мощности. Если ограничение включается регулярно, проблема в стойке, а не в задаче.
• Ошибки памяти. Счётчики исправленных и неисправленных ошибок. Рост числа исправленных — ранний признак деградации модуля.
• Загрузка межсоединения. Трафик по шине между ускорителями и по шине к процессору.

Что снимается с узла и с кластера

Типовые картины и что за ними стоит

1. Загрузка блоков высокая, потребление низкое. Ускоритель формально занят, но выполняет мелкие операции. Как правило, помогает увеличение размера пакета данных или объединение операций.
2. Загрузка ускорителя проседает периодически. Провалы совпадают с чтением очередной порции данных. Узкое место — хранилище или предобработка на процессоре, а не ускоритель.
3. Память занята почти полностью, блоки загружены слабо. Модель помещается, но пакет данных пришлось уменьшить. Решение — либо ускоритель с большим объёмом памяти, либо разбиение модели между картами.
4. Частота снижается под нагрузкой. Срабатывает ограничение по температуре или по мощности. Разбирается на уровне стойки: расход воздуха, температура на входе, распределение нагрузки.
5. При росте числа узлов время расчёта сокращается непропорционально. Потери уходят в обмен между узлами. Проверяются полоса и задержка сети, схема разбиения задачи.
6. Часть карт простаивает, очередь не пуста. Задачи не помещаются в свободные карты по памяти либо планировщик резервирует узел целиком.

Что делать с полученными данными

• Считать загрузку за период, а не мгновенно. Решение о закупке принимается по картине за недели, потому что пики и простои чередуются.
• Разделять нехватку мощности и неэффективное использование. Очередь при средней загрузке карт ниже половины — повод разбирать распределение задач, а не докупать узлы.
• Проверять запас стойки до расширения. Добавление узлов упирается в питание и отвод тепла раньше, чем в место. Что считать — разобрано в материалах раздела GPU и AI.
• Следить за счётчиками ошибок памяти. Плановая замена модуля дешевле, чем сбой длительного расчёта.
• Хранить историю. Без архива показателей невозможно показать, что нагрузка выросла, и обосновать расширение.

Что учитывается при разделении ресурсов

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

Частые вопросы

Достаточно ли одной загрузки в процентах? Нет. Этот показатель не различает полную и частичную занятость и не показывает, упирается ли расчёт в память или в вычисления. Его смотрят вместе с потреблением и пропускной способностью памяти.

Какая загрузка считается нормальной? Устойчивый уровень зависит от характера задач. Для обучения ориентируются на высокую и ровную загрузку с короткими провалами; для инференса картина принципиально другая — важнее время отклика и запас на пиковый поток.

Что мониторить в первую очередь, если ресурсов на внедрение мало? Занятую память, потребление, факты срабатывания ограничения частоты и время ожидания в очереди. Этих четырёх показателей хватает, чтобы понять, куда упирается кластер.

Нужно ли мониторить единичный сервер? Да. Показатели одного узла на пилоте — основа для расчёта конфигурации перед закупкой кластера.

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

Что мы делаем

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

Пришлите показатели текущего парка и описание задач на sale@tkasiatorg.ru — посчитаем, чего не хватает, и подберём конфигурацию под расширение.