Як Daft переосмислює конвеєр даних для мультимодальних навантажень: повна архітектура та аналіз продуктивності

Вибух мультимодальних застосунків штучного інтелекту виявив критичні прогалини в традиційній інфраструктурі обробки даних. Коли Spark і Ray Data займаються декодуванням зображень, транскрипцією аудіо та витяганням кадрів відео, їхні жорсткі архітектури руйнуються. Пам’ять несподівано роздувається, цикли GPU залишаються без діла під час I/O-узких місць, а кластери накопичують величезні неефективності. Daft уявляє собою фундаментальне переосмислення того, як розподілені системи обробки даних мають справлятися з гетерогенними обчислювальними вимогами.

Чим відрізняється мультимодальна обробка даних?

Традиційні рушії обробки даних були створені для SQL-агрегацій і з’єднань таблиць. Мультимодальні навантаження працюють у зовсім іншому вимірі:

Інфляція пам’яті: JPEG-файл роздувається у 20 разів після розпакування. Одне двогодинне відео декодується у тисячі окремих кадрів, кожен з яких займає мегабайти. Інфраструктура обробки даних має передбачати ці вибухи та динамічно їх керувати.

Фрагментовані обчислювальні вимоги: Оброблювальні ланцюги вимагають одночасної насиченості CPU, GPU і мережі. Одне навантаження включає завантаження, декодування, ресемплінг, витягування ознак, нормалізацію, інференс і класифікацію — операції, що навантажують різні апаратні компоненти на різних етапах.

Масштабні вимоги: Останні виробничі навантаження досягли вражаючих масштабів: Common Voice 17 містить 113 800 аудіофайлів; Common Crawl — 10 000 PDF-файлів; ImageNet — 803 580 зображень; Hollywood2 — 1 000 відео. Інфраструктура обробки даних має масштабуватися безперешкодно.

Архітектура потокової обробки Daft: подолання вузьких місць

Daft кардинально переосмислює, як дані рухаються через розподілену систему. Його рушій потокової обробки Swordfish розглядає дані як постійно рухомі, а не статичні пакети, що сидять у пам’яті.

Модель безперервного потоку: Для розділу з 100 000 зображень перші 1 000 одразу переходять у GPU-інференс, тоді як наступна партія завантажується або декодується. Жодна проміжна матеріалізація не блокує конвеєр. Система підтримує постійний рух на всіх етапах обробки.

Інтелектуальний зворотний тиск: Коли GPU-інференс стає обмежуючим фактором, вхідні операції автоматично зменшують швидкість. Такий підхід з обмеженою пам’яттю запобігає неконтрольованому зростанню споживання пам’яті, що характерно для конкурентних систем.

Адаптивне розбиття: Операції з високим споживанням пам’яті, такі як url_download і image_decode, автоматично регулюють розмір пакетів у реальному часі. Система жертвує дрібною паралельністю заради передбачуваних накладних витрат пам’яті та стабільної пропускної здатності.

Розподілена координація через Flotilla: Кожен вузол кластера запускає одного робітника Swordfish, що дозволяє масштабувати потокову модель горизонтально без архітектурних компромісів. Ті ж принципи ефективності застосовуються як при обробці терабайтів локально, так і петабайтів у масштабі кластера.

Крім того, Daft пропонує вбудовані можливості спеціально для мультимодальних операцій: примітиви кодування/декодування/обрізки/зміни розміру зображень, шари вбудовки тексту і зображень, інтеграція з LLM, токенізація, операції косинусної подібності, обробка URL та перетворення відео у кадри — все як перша класу вирази, а не зовнішні функції Python.

Підхід Ray Data: компроміси у загальності

Ray Data базується на розподіленій Python-екосистемі Ray, пропонуючи низькорівневі абстракції. Користувачі складають операції через map_batches, застосовані до пакетів PyArrow або DataFrame pandas.

У послідовних операціях Ray Data зливає їх у один завдання — оптимізація, що погіршує ситуацію при мультимодальних навантаженнях. Без ретельної ручної настройки розмірів блоків споживання пам’яті несподівано зростає. Можна матеріалізувати проміжні результати у об’єктному сховищі Ray, обгорнувши логіку у класи, але це додає накладні витрати на серіалізацію і копіювання пам’яті. Оскільки за замовчуванням Ray об’єктне сховище використовує лише 30% доступної системної пам’яті, агресивне вивантаження на диск стає неминучим.

Гнучкість обробки даних у Ray Data — це компроміс із передбачуваністю та ефективністю.

Реальна продуктивність: цифри

Бенчмарки на ідентичній інфраструктурі (8 екземплярів AWS g6.xlarge, кожен з NVIDIA L4 GPU, 4 vCPU, 16 ГБ пам’яті, 100 ГБ EBS) показують різкі відмінності:

Навантаження Daft Ray Data Spark
Транскрипція аудіо (113 800 файлів) 6х 22 хв 29х 20 хв (4.6x повільніше) 25х 46 хв (4.0x повільніше)
Вбудовлення документів (10 000 PDF) 1х 54 хв 14х 32 хв (7.6x повільніше) 8х 4 хв (4.2x повільніше)
Класифікація зображень (803 580 зображень) 4х 23 хв 23х 30 хв (5.4x повільніше) 45х 7 хв (10.3x повільніше)
Об’єктне детектування у відео (1 000 відео) 11х 46 хв 25х 54 хв (2.2x повільніше) 3х 36 хв (18.4x повільніше)

Daft виконує аудіопайплайни у 4.6–29 разів швидше за альтернативи. Обробка документів — у 4.2–7.6 разів швидше. Класифікація зображень — у 5.4–10.3 разів. Відео-навантаження демонструють найбільший розрив: Daft завершує за 11х 46 хв, тоді як Spark — за 3х 36 хв, що становить різницю у 18.4 рази.

Чому така різниця у продуктивності?

Внутрішні мультимодальні операції проти зовнішніх UDF: Daft реалізує декодування зображень, вбудовування ознак і витяг кадрів відео як оптимізовані внутрішні вирази. Ray Data змушує користувачів писати Python UDF, що викликають Pillow, NumPy, Hugging Face та інші бібліотеки. Кожна бібліотека зберігає власний формат даних, створюючи зайві переміщення і накладні витрати на серіалізацію.

Модель потокової пам’яті проти матеріалізації: Daft асинхронно потоково передає дані з хмарного сховища через CPU до GPU і назад у вихідний потік. Жоден розділ не матеріалізується повністю у проміжному буфері. Злиття операцій у Ray Data спричиняє сплески пам’яті, якщо користувачі не оптимізують розмір блоків вручну, а обхідні шляхи додають накладні витрати серіалізації.

Стратегія насичення ресурсів: Daft виконує весь оброблювальний процес у одному робітнику Swordfish із єдиним управлінням ресурсами. Завантаження, попередня обробка CPU, GPU-інференс і завантаження результатів проходять через один контекст виконання, підтримуючи постійне насичення CPU, GPU і мережі. Ray Data резервує окремі ядра CPU для I/O-інтенсивних операцій за замовчуванням, залишаючи ядра недоиспользованими для обчислень. Досягнення оптимального розподілу ресурсів вимагає ручного налаштування частки CPU.

Яка система підходить для яких сценаріїв?

Daft ідеально підходить, коли:

  • Обробляє мультимодальні набори даних (зображення, відео, аудіо, документи, вбудовки)
  • Потрібна надійність і передбачувана продуктивність без накладних витрат на налаштування
  • Створює складні трансформації даних із з’єднаннями, фільтрами і агрегаціями
  • Команди, звиклі до DataFrame/SQL-семантики

Ray Data залишається цінним, коли:

  • Необхідна глибока інтеграція з екосистемою Ray (Ray Train для розподіленого тренування, Ray Serve для сервісу моделей)
  • Детальне керування CPU/GPU для кожної операції виправдовує складність і додаткові зусилля

Валідація у виробництві

Масштабне тестування AI Scale: Тим Романскі та його команда класифікували 23.6 мільярдів веб-документів із Common Crawl (24 трильйонів токенів) за допомогою Daft, досягнувши 32 000 запитів на секунду на VM. Його висновок: «Ми максимально навантажили Daft, і він пройшов випробування. Якби потрібно було повторити це у Spark, довелося б налаштовувати JVM, керувати classpath і довго налагоджувати. Час виконання у Daft був значно коротшим, а масштабування від локальної розробки до кластерів — мінімальним за архітектурою».

Реконструкція інфраструктури CloudKitchens: Ця команда перебудувала всю свою ML-платформу навколо “DREAM stack” (Daft, Ray, poetry, Argo, Metaflow). Їхня інфраструктурна команда виявила обмеження Ray Data під час оцінки: неповне покриття DataFrame/ETL і низька продуктивність. Вони обрали Daft для доповнення обчислювального шару Ray, зокрема зазначаючи: «Daft заповнює прогалини Ray Data, пропонуючи повний API DataFrame» і «забезпечив швидше виконання, ніж Spark, при меншому споживанні ресурсів у наших тестах».

Велике масштабне тестування ByteDance: При оцінці класифікації зображень на 1.28 мільйоні зразків ImageNet інженери ByteDance зафіксували, що Daft підтримує приблизно на 20% вищу пропускну здатність, ніж Ray Data. Вони відзначили: «Відмінна продуктивність і ефективність ресурсів» та «безшовна потокова обробка величезних наборів зображень».

В перспективі

Ландшафт обробки даних зазнає структурних змін. Мультимодальні навантаження виявляють архітектурні рішення, що працювали для традиційної аналітики, але провалюються під гетерогенним обчислювальним навантаженням. Філософія дизайну Daft — безперервний потік, нативні мультимодальні операції, адаптивне управління ресурсами і єдина кластерна обробка — це не просто покращення, а новий рівень категорії. Організації, що обробляють зображення, аудіо, документи і відео у масштабі, відкривають для себе, що переробка архітектури за цими принципами дає 2–7-кратне підвищення продуктивності без втрати надійності або глибоких знань інфраструктури.

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • Прокоментувати
  • Репост
  • Поділіться
Прокоментувати
0/400
Немає коментарів
  • Закріпити