Шаблоны проектирования систем машинного обучения

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

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

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

Одна машина + один графический процессор

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

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

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

Одна машина + несколько графических процессоров

К 2012 году более крупные наборы данных, такие как крупные архитектуры моделей и эмпирические результаты оправдали усилия, необходимые для настройки инфраструктуры с несколькими графическими процессорами . Следовательно, мы стали свидетелями появления таких фреймворков, как TensorFlow и PyTorch, а также выделенных аппаратных платформ с несколькими графическими процессорами, которые могли обрабатывать распределенное обучение с минимальным кодом.

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

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

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

Эти форматы не только не были разработаны с учетом хранилищ облачных объектов, но они также не были оптимизированы для шаблонов доступа к данным, уникальных для обучения модели или типов чтения (доступ к многомерным данным в виде блоков или фрагментов без чтения всего файла).

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

Хранилище объектов + несколько графических процессоров

В 2018 году мы начали видеть более распределенное обучение с облачными хранилищами объектов с такими библиотеками, как s3fs и AIStore , а также такими сервисами, как AWS SageMaker’s Pipe Mode. Мы также стали свидетелями появления форматов хранения данных на основе HDF с учетом облачных хранилищ, таких как Zarr . Возможно, самое интересное, мы заметили, что ряд отраслевых команд машинного обучения разрабатывают собственные решения для потоковой передачи данных из S3 в модели на виртуальные машины.

Несмотря на то, что проблема скорости передачи оставалась, этот шаблон проектирования считается наиболее осуществимым методом работы с наборами данных petascale.

Несмотря на то, что текущих методов сегментирования томов EBS или передачи данных по конвейеру непосредственно в модели, наряду с умными обходными путями, такими как WebDataset  достаточно, фундаментальная проблема несоответствия пропускной способности остается: хранилища облачных объектов могут выдавать ~ 30 МБ/с на запрос, в то время как чтение графических процессоров может достигать 140 ГБ/с, что означает, что дорогих ускорителей недостаточно.

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

• Размер набора данных: наборы данных часто превышают емкость дискового локального хранилища, что требует распределенных систем хранения и эффективного доступа к сети.
• Количество файлов: наборы данных часто состоят из миллиардов файлов с одинаковыми шаблонами произвольного доступа, что часто перегружает как локальные, так и сетевые файловые системы. Чтение набора данных, содержащего большое количество небольших файлов, занимает много времени.
• Скорость передачи данных: при обучении на больших наборах данных часто используется много графических процессоров, что требует совокупной пропускной способности ввода-вывода для набора данных в несколько гигабайт/с; это может быть выполнено только с помощью систем ввода-вывода с массовым параллелизмом.
• Перемешивание и увеличение: повторное чтение набора данных файлов в перемешанном порядке неэффективно, если набор данных слишком велик для кэширования в памяти.
• Масштабируемость: пользователи часто хотят разрабатывать и тестировать небольшие наборы данных, а затем быстро масштабировать их до больших.

Вывод

В текущем режиме наборов данных petascale исследователи должны иметь возможность обучать произвольно большие модели на произвольно больших наборах данных в облаке. Точно так же, как распределенное обучение отделяет архитектуру моделей от вычислительных ресурсов, облачное хранилище объектов может сделать обучение ML независимым от размеров набора данных.