задний план
Массивные и высококачественные наборы данных являются одним из краеугольных камней хорошей модели ИИ. Как хранить эти наборы данных и управлять ими, а также повышать эффективность ввода-вывода во время обучения модели всегда вызывали особую озабоченность у инженеров платформы ИИ и ученых-алгоритмистов. Будь то обучение на одной машине или распределенное обучение, производительность ввода-вывода существенно повлияет на эффективность всего конвейера и даже на качество конечной модели.
Мы также постепенно наблюдаем, как контейнеризация становится тенденцией обучения ИИ.Использование преимуществ быстрого и эластичного масштабирования контейнеров в сочетании с пулом ресурсов общедоступного облака может максимизировать использование ресурсов и значительно сократить расходы для предприятий. Поэтому были созданы компоненты с открытым исходным кодом, такие как Kubeflow и Volcano, чтобы помочь пользователям управлять задачами ИИ в Kubernetes. Kubernetes добавила Scheduling Framework начиная с версии 1.15, и сообщество оптимизировало множество задач для сценариев обучения ИИ на основе этой новой структуры планирования. Упомянутая выше проблема управления обучающими данными по-прежнему существует в Kubernetes и даже усиливает этот спрос, поскольку вычисления больше не выполняются на нескольких стационарных машинах, а данные должны разумно следовать «потоку» вычислений (или наоборот).
Наконец, будь то ежедневные эксперименты ученых-алгоритмистов или формальное обучение моделей, интерфейс POSIX по-прежнему пользуется большим спросом.Хотя основные фреймворки или библиотеки алгоритмов в основном поддерживают интерфейс хранения объектов, POSIX по-прежнему остается «первым гражданином». . Некоторые расширенные функции операционных систем (такие как кэш страниц) также доступны только с интерфейсами POSIX.
Общая архитектура платформы ИИ
Выше приведена общая схема архитектуры платформы ИИ. В настоящее время наиболее используемыми системами хранения являются объектное хранилище и HDFS.Причин, по которым здесь используется HDFS, много.Например, платформа развернута в машинном зале без объектного хранилища, а предобработка обучающих наборов данных осуществляется в больших данных. Платформа. Вычислительные ресурсы смешаны с экземплярами ЦП и экземплярами ГП. Отличие от платформ больших данных заключается в том, что ресурсы платформ ИИ по своей природе неоднородны, поэтому разумное и эффективное использование этих разнородных ресурсов всегда было отраслевой проблемой. Планировщик был представлен ранее, Kubernetes в настоящее время является основным компонентом, а сочетание различных операторов заданий, Volcano и плагинов планирования может максимально увеличить возможности Kubernetes. Конвейер - очень важная часть. Задачи ИИ состоят не только из обучения модели, но и из предварительной обработки данных, разработки функций, проверки модели, оценки модели, онлайн-модели и других ссылок. Поэтому управление конвейером также очень важно. Наконец, фреймворки глубокого обучения, с которыми больше всего сталкиваются ученые-алгоритмы. Эти фреймворки в настоящее время имеют свои собственные группы пользователей. Многие оптимизации моделей основаны на определенном фреймворке (например, XLA TensorFlow), но есть и независимые от фреймворка (такие как TVM). [4]).
В этой статье основное внимание уделяется нижнему уровню хранения: как оптимизировать эффективность ввода-вывода уровня хранения, сохраняя при этом компоненты верхнего уровня неизменными. Эта часть включает, помимо прочего, кэширование данных, предварительное чтение, одновременное чтение, оптимизацию планирования и другие стратегии.JuiceFS — это расширенный компонент такого уровня хранения, который может значительно повысить эффективность ввода-вывода, что будет подробно описано ниже.
Введение в JuiceFS
JuiceFS — это высокопроизводительная распределенная файловая система с открытым исходным кодом, разработанная для облачных сред. Она полностью совместима с интерфейсами POSIX, HDFS и S3. Она подходит для таких сценариев, как большие данные, обучение моделей ИИ, общее хранилище Kubernetes и массивное управление архивом данных.
Когда данные считываются через клиент JuiceFS, данные будут интеллектуально кэшироваться в пути локального кэша (который может быть в памяти или на диске), настроенном приложением, а метаданные также будут кэшироваться в локальной памяти клиентского узла. Для сценариев обучения модели ИИ последующие вычисления после первой эпохи могут напрямую получать обучающие данные из кэша, что значительно повышает эффективность обучения.
JuiceFS также имеет возможность опережающего и одновременного чтения данных, чтобы обеспечить эффективность генерации каждого мини-пакета и подготовить данные заранее.
Кроме того, JuiceFS также предоставляет стандартный драйвер Kubernetes CSI, и приложения могут одновременно монтировать файловую систему JuiceFS как общий постоянный том (PV) в несколько контейнеров.
Благодаря поддержке вышеперечисленных функций ученые-алгоритмы могут легко управлять обучающими данными, так же как и доступом к локальному хранилищу, без модификации фреймворка для специальной адаптации, и в определенной степени может быть гарантирована эффективность обучения.
Тестовая программа
Чтобы проверить эффект обучения модели после использования JuiceFS, мы выбираем общую модель ResNet50 и набор данных ImageNet, в задаче обучения используется сценарий, предоставленный проектом DLPerf[5], и соответствующая среда глубокого обучения — PyTorch. Учебный узел настроен на 8 видеокарт NVIDIA A100.
В качестве сравнения мы берем объектное хранилище в общедоступном облаке в качестве базового уровня (доступ к которому осуществляется через S3FS), и сравниваем его с проектом с открытым исходным кодом Alluxio, и тестируем 1 машину с 1 картой, 1 машину с 4 картами, и 1 машина с картами 8. Эффективность обучения (т.е. количество образцов, обрабатываемых в секунду) в соответствии с конфигурацией.
Будь то JuiceFS или Alluxio, набор обучающих данных предварительно нагревается в памяти, и набор данных занимает около 160 ГБ. JuiceFS предоставляет подкоманду warmup [6], чтобы легко разогреть кеш набора данных, просто укажите каталог или список файлов, которые необходимо разогреть.
Метод тестирования заключается в выполнении нескольких раундов обучения для каждой конфигурации и запуске только одной эпохи в каждом раунде.Статистические результаты каждого раунда суммируются, а общая эффективность обучения рассчитывается после исключения некоторых возможных аномальных данных.
Описание параметров конфигурации JuiceFS
Режим ввода-вывода сценария обучения модели ИИ представляет собой типичный режим только для чтения, то есть к набору данных выполняются только запросы на чтение, и данные не будут изменены. Следовательно, чтобы максимизировать эффективность ввода-вывода, некоторые параметры конфигурации (например, конфигурация, связанная с кешем) могут быть соответствующим образом скорректированы.Ниже подробно описаны несколько важных параметров конфигурации JuiceFS.
кэш метаданных
Есть три типа метаданных, которые могут кэшироваться в ядре: атрибуты, записи файлов и direntry, которые могут управлять временем кэширования с помощью следующих трех опций:
--attr-cache value 属性缓存过期时间；单位为秒 (默认: 1)
--entry-cache value 文件项缓存过期时间；单位为秒 (默认: 1)
--dir-entry-cache value 目录项缓存过期时间；单位为秒 (默认: 1)
Метаданные по умолчанию кэшируются в ядре только на 1 секунду, и время кэширования может быть соответственно увеличено в зависимости от времени обучения, например, на 2 часа (7200 секунд).
При открытии файла (например, запрос open()) для обеспечения согласованности [7] JuiceFS будет запрашивать механизм метаданных по умолчанию для получения последних метаданных. Поскольку все наборы данных доступны только для чтения, можно соответствующим образом настроить стратегию обработки и установить интервал проверки обновления файла.Если время не достигает установленного значения, нет необходимости обращаться к механизму метаданных. , что может значительно повысить скорость открытия файлов. Соответствующие параметры конфигурации:
--open-cache value 打开的文件的缓存过期时间（0 代表关闭这个特性）；单位为秒 (默认: 0)
кеш данных
Для файла, который был прочитан, ядро автоматически кэширует его содержимое.При открытии файла в следующий раз, если файл не был обновлен (то есть mtime не был обновлен), его можно прочитать прямо из кеш страниц в ядре.лучшая производительность. Следовательно, по завершении первой эпохи, если памяти вычислительного узла достаточно, большая часть наборов данных могла быть закэширована в кэше страниц, так что в последующие эпохи не нужно будет считывать данные через JuiceFS, а производительность может снизиться. быть значительно улучшена. Эта функция включена по умолчанию в JuiceFS версии 0.15.2 и выше, и настройка не требуется.
Помимо кэширования данных в ядре, JuiceFS также поддерживает кэширование данных в локальной файловой системе, которая может быть любой локальной файловой системой на жестком диске, SSD или в памяти. Локальный кеш можно настроить с помощью следующих параметров:
--cache-dir value 本地缓存目录路径；使用冒号隔离多个路径 (默认: "$HOME/.juicefs/cache" 或 "/var/jfsCache")
--cache-size value 缓存对象的总大小；单位为 MiB (默认: 1024)
--free-space-ratio value 最小剩余空间比例 (默认: 0.1)
--cache-partial-only 仅缓存随机小块读 (默认: false)
Например, есть два способа кэширования данных в памяти.--cache-dirУстановить какmemory, другой - установить его на/dev/shm. Разница между двумя методами заключается в том, что первый очистит кэшированные данные после перемонтирования файловой системы JuiceFS, а второй сохранит их, и между ними нет большой разницы в производительности. Далее следует кэшировать данные в/dev/shm/jfscacheИ пример, который ограничивает использование до 300 ГБ памяти:
--cache-dir /dev/shm/jfscache --cache-size 307200
JuiceFS также поддерживает кэширование данных по нескольким путям. По умолчанию кэшированные данные записываются в режиме опроса. Несколько путей разделяются двоеточиями, например:
--cache-dir /data1:/data2:/data3
Описание параметров конфигурации Alluxio
Все компоненты Alluxio (такие как master, worker, FUSE) развернуты на одном узле, и используется версия 2.5.0-2. Конкретная конфигурация выглядит следующим образом:
| элемент конфигурации | установить значение |
|---|---|
| alluxio.master.journal.type | UFS |
| alluxio.user.block.size.bytes.default | 32MB |
| alluxio.user.local.reader.chunk.size.bytes | 32MB |
| alluxio.user.metadata.cache.enabled | true |
| alluxio.user.metadata.cache.expiration.time | 2day |
| alluxio.user.streaming.reader.chunk.size.bytes | 32MB |
| alluxio.worker.network.reader.buffer.size | 128MB |
Кроме того, параметры монтирования, указанные при запуске Alluxio FUSE:kernel_cache,ro,max_read=131072,attr_timeout=7200,entry_timeout=7200,nonempty.
Результаты теста
Результаты теста содержат два сценария: один с использованием кэша страниц ядра, а другой без него. Как упоминалось выше, метод тестирования заключается в выполнении нескольких раундов обучения для каждой конфигурации.После первого раунда последующие тесты могут напрямую считывать данные из кэша страниц. Поэтому мы разработали второй сценарий для проверки эффективности обучения без кэширования страниц (например, первый этап обучения модели), который может более реалистично отражать фактическую производительность базовой системы хранения.
В первом сценарии JuiceFS может эффективно использовать кеш страниц ядра без дополнительной настройки, но ни хранилище объектов, ни конфигурация Alluxio по умолчанию не поддерживают эту функцию и должны быть установлены отдельно.
Следует отметить, что в процессе тестирования объектного хранилища мы попытались включить функцию локального кэширования S3FS, надеясь добиться эффекта кэширования, аналогичного JuiceFS и Alluxio. Однако в реальном тесте обнаружилось, что даже при полном прогреве кеша и сколько бы ни использовалось видеокарт, одну эпоху нельзя запустить за один день, и даже медленнее, чем когда нет кеш. Поэтому «хранилище объектов» в следующих результатах теста не включает данные после включения локального кэша.
На следующем рисунке показаны результаты тестирования двух сценариев («без ПК» означает отсутствие кеша страниц):
Благодаря кэшированию метаданных и кэшированию данных вы можете видеть, что независимо от того, в каком сценарии он находится,По сравнению с объектным хранилищем, JuiceFS может добиться повышения производительности в среднем более чем в 4 раза, а разрыв в производительности может составлять не более 7 раз.. В то же время, поскольку метод доступа к хранилищу объектов не использует эффективно кэш страниц ядра, разрыв в производительности между двумя сценариями невелик. Кроме того, в полном сквозном обучающем тесте модели из-за слишком низкой эффективности обучения хранилища объектов требуется слишком много времени для достижения заданной точности модели, которая в основном недоступна в производственной среде.
По сравнению с Alluxio первый сценарий с кэшем страниц мало чем отличается от JuiceFS. Во втором сценарии, где нет кеша страниц и есть только кеш памяти, JuiceFS повышает производительность в среднем примерно на 20%, особенно в конфигурации 1 машина и 8 карт разрыв еще больше увеличивается, достигая разницы в производительности примерно на 43%. . Производительность Alluxio в конфигурации с 1 машиной и 8 картами не улучшается по сравнению с производительностью 1 машины с 4 картами, поэтому он не может в полной мере использовать вычислительную мощность нескольких карт.
Ресурсы графического процессора являются относительно дорогим ресурсом, поэтому разница в эффективности ввода-вывода также может косвенно отражаться на стоимости вычислительных ресурсов: чем эффективнее используются вычислительные ресурсы, тем ниже совокупная стоимость владения.
Резюме и перспективы
В этой статье описывается, как в полной мере использовать функции JuiceFS при обучении моделей ИИ для ускорения обучения.По сравнению с чтением наборов данных непосредственно из хранилища объектов, JuiceFS может повысить производительность до 7 раз. Он также может поддерживать определенный коэффициент линейного ускорения в сценарии обучения с несколькими картами, закладывая основу для распределенного обучения.
будущееJuiceFSТакже будут рассмотрены дополнительные направления в сценариях ИИ, такие как дальнейшее повышение эффективности ввода-вывода, массивное хранилище небольших файлов, сходство данных и вычислений, сочетание с оператором заданий, сочетание со структурой планирования Kubernetes или планировщиком сообщества и т. д. Приглашаем всех принять активное участие в сообществе JuiceFS с открытым исходным кодом и совместно создать краеугольный камень хранилища для облачных сценариев искусственного интеллекта.