Результаты Управляемая Azure система Lustre хранилище MLPerf версии 3.0

MlPerf Storage — это набор тестов MLCommons для систем хранения, используемых рабочими нагрузками искусственного интеллекта (ИИ). Он создает репрезентативные шаблоны ввода-вывода хранилища и измеряет, может ли путь к хранилищу предоставлять данные или сохранять состояние модели по скорости, требуемой рабочей нагрузкой.

Хранилище MLPerf версии 3.0 включает учебные, контрольные точки, векторную базу данных и рабочие нагрузки кэша "ключ-значение". Отправка Управляемая Azure система Lustre включает результаты для категорий обучения и контрольных точек.

Какие меры тестирования

Хранилище MLPerf использует клиентские узлы для создания операций ввода-вывода для имитированных акселераторов. Он проверяет систему хранения и путь к данным; Он не выполняет тест вычислений GPU, точности модели или комплексного времени обучения.

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

Training

Тест обучения измеряет, может ли хранилище постоянно предоставлять обучающие данные достаточно быстро, чтобы обеспечить активность имитированных акселераторов. Отправка Azure использовала рабочую нагрузку UNET3D с имитацией акселераторов B200.

Отчеты о тесте:

• Число и тип имитированных акселераторов.
• Устойчивая пропускная способность чтения в ГиБ/с.
• Имитация использования акселератора при выполнении теста.

Запуски Azure поддерживают более 90% имитации использования акселератора в течение пяти часов подряд. Это означает, что проверенные конфигурации хранилища поддерживали требуемую скорость данных рабочей нагрузки в течение длительности выполнения.

Создание контрольных точек

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

Отчеты о тесте:

• Пропускная способность записи и восстановления контрольной точки в ГиБ/с.
• Длительность записи и восстановления в секундах.
• Количество экземпляров параллельного данных.
• Масштаб модели, представленный контрольной точкой.

Закрытое деление

Все Управляемая Azure система Lustre результаты были отправлены в закрытое подразделение хранилища MLPerf. В этом разделе код рабочей нагрузки и параметры теста стандартизированы. Отправители могут настраивать и настраивать систему хранения в правилах теста.

область отправки Azure

Все 17 Azure результатов используют Управляемая Azure система Lustre в качестве общей удаленной файловой системы через протокол POSIX.

Единицы пропускной способности

Таблица результатов хранилища MLPerf сообщает пропускную способность в гибибайтах в секунду (ГиБ/с), двоичную единицу. Один ГиБ/с равен 1,073741824 гигабайтам в секунду (ГБ/с), десятичной единицей.

Диаграммы пропускной способности обучения, масштабируемости и контрольных точек используют ГиБ/с, как сообщается в таблице результатов хранилища MLPerf. Граф плотности пропускной способности использует МБ/с на ТиБ. В результирующих таблицах предоставляются как ГиБ/с, так и преобразованное значение ГБ/с.

Результаты обучения

Сравнение между уровнями служб

В конфигурациях с тремя имитируемыми акселераторами измеряемая пропускная способность чтения составила от 17,3 до 17,4 ГиБ/с. При 16 имитированных ускорителях измеряемая пропускная способность чтения составила от 89,0 до 90,6 ГиБ/с на всех пяти уровнях служб Управляемая Azure система Lustre.

Пунктирная строка на каждой панели показывает номинальную пропускную способность для проверенной конфигурации файловой системы. Каждый шаг емкости обеспечивает 2000 МБ/с. Номинальная пропускная способность вычисляется из числа добавок емкости, а затем преобразуется в ГиБ/с для сопоставления измеренных значений в таблице результатов хранилища MLPerf:

Nominal bandwidth (GiB/s) = capacity (TiB) / tier increment (TiB) * 2,000 / 1,073.741824

Каждая конфигурация с тремя акселераторами имеет 10 добавок емкости и 18,6 ГиБ/с номинальной пропускной способности. Каждая конфигурация 16-акселератора имеет 50 добавок емкости и 93,1 ГиБ/с номинальной пропускной способности.

Рис. 1. Измеряемая и номинальная пропускная способность обучения по уровню служб Управляемая Azure система Lustre и подготовленной емкости для акселераторов (a) 3 и (b) 16 имитированных акселераторов.

Эффективность плотности пропускной способности

Управляемая Azure система Lustre имена уровней служб определяют класс производительности, но номинальная пропускная способность и номинальная плотность пропускной способности вычисляются на основе увеличения емкости уровня. Каждый шаг емкости обеспечивает 2000 МБ/с.

Nominal bandwidth (MB/s) = capacity (TiB) / tier increment (TiB) * 2,000

Nominal density (MB/s per TiB) = 2,000 / tier increment (TiB)

Чтобы вычислить плотность пропускной способности, измеренное значение из таблицы результатов хранилища MLPerf преобразуется из ГиБ/с в десятичные МБ/с и делится на емкость файловой системы:

Demonstrated density (MB/s per TiB) = measured bandwidth (GiB/s) * 1,073.741824 / capacity (TiB)

Эффективность демонстрируется плотность, разделенная на вычисляемую номинальную плотность. На пяти проверенных уровнях, продемонстрированная плотность составила от 95,6% до 97,3% номинальной.

Рис. 2. Вычисляемая номинальная и демонстрируемая плотность пропускной способности для конфигураций 16 акселераторов.

Масштабируемость пропускной способности AMLFS

AMLFS 125 был выбран в качестве эталонного уровня для масштабируемости обучения, так как отправка включает результаты в 3, 16, 46 и 70 имитированных акселераторах. Аналогичное поведение масштабирования ожидается на всех уровнях AMLFS, если файловая система имеет размер для обеспечения требуемой номинальной пропускной способности.

Конфигурации AMLFS 125 увеличились с 3 имитированных акселераторов и 17,4 ГиБ/с (18,6 ГБ/с) до 70 имитированных акселераторов и 379,1 ГиБ/с (407,1 ГБ/с). Емкость файловой системы увеличилась с 160 ТиБ на 3 имитированных акселераторах до 40 096 ТиБ в 70 имитированных акселераторах.

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

Рис. 3. Измеряемая пропускная способность обучения AMLFS 125 и идеальное линейное масштабирование от 3 до 70 имитированных акселераторов.

Самые крупные конфигурации обучения использовали 70 имитированных акселераторов. Помимо результата AMLFS 125, конфигурация AMLFS 20 измеряется 378,0 ГиБ/с.

Полные результаты обучения

Результаты контрольной точки

Результаты контрольной точки охватывают четыре масштаба модели Llama 3. Все четыре конфигурации использовали AMLFS 125 с подготовленными емкостями с 160 ТиБ до 4096 ТиБ. Самый большой результат, представляющий модель 1250B, измеряется 642,2 ГиБ/с (689,6 ГБ/с) для операций записи контрольных точек и 489,6 ГиБ/с (525,7 ГБ/с) для операций восстановления.

Рис. 4. Пропускная способность записи и восстановления контрольных точек для чтения по масштабу модели, уровню AMLFS и подготовленной емкости.

Использование данных в качестве ссылки на размер

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

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

Определение требования к рабочей нагрузке

Определите, ограничена ли рабочая нагрузка в первую очередь постоянными обучаемыми чтениями, записью контрольных точек или восстановлением.

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

Рассмотрим пример.

Required checkpoint bandwidth (GiB/s) = checkpoint size (GiB) / target duration (seconds)

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

Учетная запись поведения ввода-вывода приложения

Реальные рабочие нагрузки искусственного интеллекта могут создавать различные шаблоны ввода-вывода из теста, даже если акселераторы и масштабы моделей похожи. Необходимо учесть следующие моменты.

• Является ли контрольная точка синхронной или асинхронной.
• Как платформа обучения предварительно получает данные, буферы, кэши и перемешивает данные.
• Используется ли локальное хранилище NVMe или другое хранилище с нуля для контрольных точек, кэшей или промежуточных обучающих данных.
• Выполняется ли предварительная обработка данных перед заданием или преобразованием во время обучения.
• Размер модели и контрольной точки.
• Размер входного файла, формат файла, размер образца и количество записей, хранящихся в каждом файле.
• Баланс больших последовательных операций ввода-вывода, небольших случайных операций ввода-вывода и метаданных файловой системы.
• Количество параллельных заданий, совместное использование файловой системы.

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

Перевод начальной оценки пропускной способности в емкость AMLFS

Если у вас есть начальный целевой объект пропускной способности общего хранилища, его можно перевести в оценочную емкость AMLFS. Каждый шаг емкости AMLFS обеспечивает 2000 МБ/с номинальной пропускной способности.

Target bandwidth (MB/s) = target bandwidth (GiB/s) * 1,073.741824

Estimated increments = ceiling(target bandwidth (MB/s) / 2,000)

Estimated performance-driven capacity (TiB) = estimated increments * tier increment (TiB)

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

В качестве арифметического примера конфигурации обучения 16 акселераторов используют 50 добавок емкости:

50 increments * 2,000 MB/s = 100,000 MB/s = 93.1 GiB/s nominal bandwidth

Соответствующие проверенные емкости : 4800 TiB для AMLFS 20, 2400 TiB для AMLFS 40, 800 TiB для AMLFS 125, 400 TiB для AMLFS 250 и 200 ТиБ для AMLFS 500. Эти значения показывают, как номинальная пропускная способность сопоставляется с емкостью; Они не рекомендуются для каждой 16-акселераторной рабочей нагрузки.

Учетная запись клиентов и сетей

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

• Используйте размеры виртуальных машин с достаточной пропускной способностью сети и ускорением сети.
• Поместите клиенты в ту же зону доступности, что и файловая система Управляемая Azure система Lustre, когда регион поддерживает зоны доступности.
• Сохраняйте прямую маршрутизацию сети между клиентами и файловой системой.
• Планирование макетов файлов и каталогов для размеров файлов рабочей нагрузки и шаблона доступа.

Дополнительные сведения см. в разделе "Оптимизация Управляемая Azure система Lustre производительности" и "Оптимизация макетов файлов и каталогов".

Проверка с помощью приложения

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

Связанные материалы

• Оптимизация производительности Управляемая Azure система Lustre
• Многоуровневые контрольные точки для обучения ИИ
• Репозиторий GitHub хранилища MLPerf