Компания 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✴ удалось решить проблему доставки данных исследователям. Поскольку вычислительные ресурсы были распределены по разным регионам, сотрудникам часто приходилось ждать по несколько часов, пока наборы данных скопируют и отправят в конкретный регион мира, где будет выполняться их задача по обучению. Для этого была разработана многоуровневая система кеширования. Оперативная память и SSD на GPU-хостах служат самым быстрым уровнем, получая данные из региональных флеш-хранилищ BLOB-объектов, куда, в свою очередь, информация поступает из глобальных озёр данных на базе HDD.
Для ускорения применяется механизм предвыборки, который заранее загружает данные, которые исследователь планирует использовать. Эта схема уже позволила существенно сократить время загрузки во всех рабочих нагрузках Meta✴. В среднем время загрузки уменьшилось со 150 минут до всего 10 минут (снижение на 93 %). Meta✴ зафиксировала максимальное сокращение времени загрузки с 89 часов до всего 182 минут.
Источник:
