Meta✴ полностью перестроила своё хранилище для ИИ, чтобы предотвратить простой ускорителей. Как сообщает SDxCentral, система, лежащая в основе её операций с ИИ, позволила кратно сократить время, необходимое исследователям для перемещения обучающих данных ИИ между регионами. Согласно опубликованным аналитическим выкладкам, скорость работы имеющихся СХД не поспевала за растущими вычислительными мощностями GPU, которые примерно утраивались каждые два года.
Стремясь устранить этот разрыв и обеспечить поддержку кластеров хранения данных, охватывающих все продукты Meta✴, включая Meta✴ AI, Reality Labs, платформы социальных сетей и потребности потенциальных облачных клиентов, специалисты компании перестроили слой хранения BLOB-объектов (Binary Large Object), работающий поверх её глобальной многопользовательской СХД Tectonic, обслуживающей экзабайты данных.
Загрузка данных на два GPU (Источник изображений: Meta✴)
Компания отметила, что хотя устаревшая архитектура BLOB-хранилищ Meta✴ вполне подходила для веб-приложений, таких как Facebook✴ и Instagram✴, для обучения ИИ она оказалась неэффективной. У неё было слишком много слоёв сервисов, и она должна была выполнять множественные запросы к метаданным на нескольких уровнях, прежде чем определить путь к файлу и его фактическое местоположение в хранилище, что увеличивало задержку и отражалось на производительности.
Прежний алгоритм обработки запросов для API getObject
Перестройка СХД была основана на трёх ключевых изменениях. Во-первых, разрозненная система метаданных была объединена в единую схему, поддерживаемую ZippyDB, что позволило сделать практически мгновенным поиск путей. Во-вторых, были убраны прослойки, не позволявшие передавать байты напрямую с серверов хранения (fat client), что повысило энергоэффективность и снизило задержку. В-третьих, был осуществлён переход от глобальной модели развёртывания к региональной, в рамках которой хранилище данных размещается рядом с GPU, которые в нём действительно нуждаются. Всё это позволило свести к нулю накладные расходы при работе с Tectonic, уложиться в бюджет по энергопотреблению и упростить архитектуру хранения. Более того, Meta✴ задействовала свободную память GPU для распределённого кеша «горячих» данных.
Новый алгоритм обработки запросов для API getObject
Команда воспользовалась опытом разработки Owl — системой дистрибуции больших объектов, которая сочетает децентрализованную P2P-плоскость данных с централизованной плоскостью управления. Специалисты интегрировали логику однорангового обмена из Owl SDK на уровне клиента, что снизило частоту запросов GPU к хранилищу. Также был добавлен отдельный кеш метаданных, который возвращает адреса часто запрашиваемых файлов за 1–2 мс. Это позволило справляться с пиками обращений, например, когда GPU одновременно запрашивают одни и те же «горячие» веса модели, а также улучшить задержку, поскольку данные берутся из памяти, а не с диска.
Эволюция архитектуры загрузки данных
В финальной версии стека хранилища BLOB-объектов были приняты меры к устранению узких мест, таких как пики исходящего трафика, которые в конечном итоге приводили к перегрузке и таймаутам, а также к остановке работы GPU. В частности, было добавлено ПО для динамического управления параллельным доступом на поведения приложений. При высокой нагрузке система автоматически уменьшает количество доступных приложению запросов.
Также в Meta✴ решили проблему доставки данных исследователям. Поскольку вычислительные мощности были разбросаны по регионам, сотрудникам регулярно приходилось часами ждать, пока наборы данных будут скопированы и отправлены в конкретный регион мира, где будет выполняться их задача обучения. Для этого была создана многоуровневая система кеширования. RAM и SSD на GPU-хостах выступают в качестве самого быстрого слоя, которые получают данные от региональных флеш-хранилищ BLOB-объектов, куда, в свою очередь, данные попадают из глобальных озёр данных на базе HDD.
Для ускорения используется механизм предвыборки, который заранее загружает данные, которые исследователь собирается использовать. Эта схема уже позволила значительно сократить время загрузки во всех рабочих нагрузках Meta✴. В среднем время загрузки сократилось со 150 мин. до всего 10 мин. (сокращение на 93 %). Meta✴ зафиксировала максимальное сокращение времени загрузки с 89 ч. до всего 182 мин.
Источник: servernews.ru