Как разделить ресурсы ускорителей MetaX между командами
Способы разделения ресурса ускорителя, ограничения каждого из них, правила распределения квот между командами и требования к инфраструктуре кластера.
Когда ускорители закупаются под несколько команд, возникает задача разделения ресурса. Отдать карту целиком под каждую задачу расточительно: значительная часть времени она простаивает между запусками, а мелкие задачи занимают память в объёме, несопоставимом с объёмом карты. Разделение ускорителей MetaX между командами решается несколькими способами, и выбор зависит от того, что важнее — гарантированная изоляция или максимальная утилизация.
Разберём способы разделения, их ограничения, правила распределения квот и данные, нужные для расчёта конфигурации. Направление описано на странице ускорителей MetaX.
Способы разделения ресурса
| Способ | Как устроено | Изоляция | Где применяется |
|---|---|---|---|
| Карта целиком на задачу | планировщик выделяет ускоритель монопольно | полная | обучение, длительные расчёты |
| Разделение по времени | задачи ставятся в очередь и получают карту по расписанию | полная в пределах окна | исследовательские задачи, ночные прогоны |
| Несколько процессов на карте | память делится между процессами, вычислительные блоки — по мере обращения | по памяти, без гарантии по производительности | инференс небольших моделей, отладка |
| Контейнеры с квотой памяти | планировщик кластера выдаёт долю памяти ускорителя контейнеру | по памяти и по доступу | общая среда разработки для нескольких команд |
| Пулы узлов | узлы закрепляются за подразделениями, задачи направляются метками | полная на уровне узла | команды с разными требованиями к оборудованию |
Что учитывается при разделении памяти
- Память ускорителя делится не только между моделями: часть занимают состояния оптимизатора и промежуточные значения, и при обучении они превышают размер самой модели в несколько раз.
- Разделённая карта не даёт двум задачам суммарно больше памяти, чем есть физически, — превышение квоты завершает процесс ошибкой, а не замедлением.
- Задача с пиковым потреблением памяти планируется по пику, а не по среднему значению.
- При инференсе память занимает кеш промежуточных состояний, который растёт с длиной последовательности и числом одновременных запросов.
- Для отладочных задач хватает небольшой доли карты — такие запуски разумно вынести в отдельный пул, чтобы они не занимали ресурс обучения.
Чего разделение не даёт
- Гарантии производительности. Если две задачи делят вычислительные блоки, каждая получает меньше, чем на свободной карте, и время выполнения становится непредсказуемым.
- Ускорения обучения. Разделение повышает утилизацию оборудования, но не сокращает время отдельной задачи.
- Изоляции от сбоя. Ошибка, приводящая к сбросу ускорителя, затрагивает все процессы на этой карте.
- Экономии на межсоединении. Обучение на нескольких картах требует полосы между ними независимо от того, как они разделены между командами.
- Решения проблемы очередей. Если ресурса не хватает на всех, разделение лишь распределяет дефицит.
Как распределяются квоты между командами
- Ресурс считается не в картах, а в карто-часах за период: так видно и потребление, и простой.
- Каждой команде назначается гарантированная доля и возможность занимать свободный ресурс сверх неё, когда он не востребован.
- Задачи разделяются по приоритетам: обучение по плану выше, чем исследовательский запуск, который можно прервать и повторить.
- Для длительных задач вводится обязательное сохранение контрольных точек — иначе вытеснение низкоприоритетной задачи означает потерю дней расчёта.
- Отчёт по утилизации собирается ежемесячно: он показывает, нужна ли закупка или достаточно перераспределения.
- Отдельный небольшой пул выделяется под отладку — доступ к нему без очереди важнее для скорости работы команд, чем несколько процентов общей утилизации.
Что нужно от инфраструктуры
- Планировщик кластера с поддержкой квот на ускорители и меток узлов.
- Система наблюдения с показателями загрузки вычислительных блоков и занятой памяти по каждой карте.
- Общее хранилище наборов данных с полосой, достаточной для одновременной работы нескольких команд.
- Сеть между узлами, рассчитанная на обучение, а не только на доступ к данным — параметры разбираются в материалах об инфраструктуре кластера.
- Резерв по питанию и охлаждению на случай одновременной загрузки всех узлов: пиковое потребление заметно выше среднего.
- Образы контейнеров с драйверами и библиотеками, единые для всех команд.
Что прислать для расчёта
- Число команд и характер их задач: обучение, дообучение, инференс, отладка.
- Размеры моделей и требуемый объём памяти на задачу.
- Ожидаемое число одновременных задач в пике.
- Используемый планировщик кластера, если он уже развёрнут.
- Доступная мощность и схема охлаждения стоек.
- Планируемый рост числа задач на ближайший год.
Частые вопросы
Сколько задач разумно запускать на одной карте? Для инференса небольших моделей — столько, сколько помещается по памяти с запасом 20 %. Для обучения — одна: конкуренция за вычислительные блоки делает время выполнения непредсказуемым.
Что выгоднее — одна карта большого объёма или две меньшего? Если модель помещается в меньшую карту, две карты дают больше суммарной производительности и гибкости в распределении. Если не помещается, выбора нет: разбиение модели между картами замедляет обучение.
Как понять, что ресурса действительно не хватает? По загрузке вычислительных блоков, а не по числу занятых карт. Карта, занятая задачей с загрузкой 20 %, показывает не дефицит ускорителей, а узкое место в подаче данных.
Нужен ли отдельный пул под инференс? Желателен. Обучение занимает карту надолго, а инференс требует предсказуемой задержки. Смешивание в одном пуле приводит к тому, что сервис отвечает медленнее при каждом крупном запуске.
Обязателен ли планировщик кластера при двух-трёх узлах? При двух узлах можно обойтись графиком и договорённостями, но учёт занятости и очередь всё равно понадобятся. Планировщик окупается, как только число команд превышает количество узлов.
Что мы делаем
Подбираем конфигурацию узлов под число команд и профиль их задач, считаем требуемый объём памяти и число ускорителей по пиковой нагрузке, проверяем мощность и охлаждение стоек под одновременную загрузку и комплектуем поставку сетевой частью и хранилищем. Поставляем оборудование напрямую из Китая.
Пришлите состав команд, размеры моделей и параметры стоек на sale@tkasiatorg.ru — предложим схему разделения ресурса, посчитаем конфигурацию и дадим спецификацию с ценами и сроками поставки.

