Comment Daft réinvente le pipeline de données pour les charges de travail multimodales : une architecture complète et une analyse des performances

L’explosion des applications d’IA multimodale a mis en évidence des lacunes critiques dans l’infrastructure traditionnelle de traitement des données. Lorsque Spark et Ray Data s’attaquent au décodage d’images, à la transcription audio et à l’extraction de frames vidéo, leurs architectures rigides s’effondrent. La mémoire gonfle de façon imprévisible, les cycles GPU restent inactifs lors des goulets d’étranglement I/O, et les clusters accumulent d’énormes inefficacités. Daft représente une refonte fondamentale de la manière dont les systèmes de données distribués devraient gérer des demandes de calcul hétérogènes.

Qu’est-ce qui différencie le traitement multimodal des données ?

Les moteurs de pipelines de données traditionnels ont été conçus pour des agrégations SQL et des jointures de tables. Les charges de travail multimodales opèrent dans une dimension complètement différente :

Inflation de la mémoire : un fichier JPEG peut gonfler 20x une fois décompressé. Une seule vidéo de 2 heures se décode en des milliers de frames individuelles, chacune consommant des mégaoctets. Le pipeline de données doit anticiper ces explosions et les gérer dynamiquement.

Exigences de calcul fragmentées : les chaînes de traitement nécessitent une saturation simultanée du CPU, du GPU et du réseau. Une seule charge de travail inclut le téléchargement, le décodage, le rééchantillonnage, l’extraction de caractéristiques, la normalisation, l’inférence et la classification — des opérations qui sollicitent différents composants matériels à différentes phases.

Exigences d’échelle : les charges de travail en production récentes ont atteint des proportions stupéfiantes : Common Voice 17 contient 113 800 fichiers audio ; Common Crawl détient 10 000 PDFs ; ImageNet couvre 803 580 images ; Hollywood2 comprend 1 000 vidéos. L’infrastructure du pipeline de données doit évoluer de manière transparente sur tous ces volumes.

Architecture de streaming de Daft : briser le goulot d’étranglement

Daft restructure fondamentalement la façon dont les données circulent dans un système distribué. Son moteur d’exécution en streaming Swordfish traite les données comme étant en mouvement perpétuel plutôt que comme des lots statiques en mémoire.

Modèle de flux continu : pour une partition contenant 100 000 images, les 1 000 premières sont immédiatement envoyées en inférence GPU tandis que le batch suivant est téléchargé ou décodé. Aucun point de matérialisation intermédiaire ne bloque jamais le pipeline. Le système maintient un mouvement constant à toutes les étapes de traitement.

Rétropression intelligente : lorsque l’inférence GPU devient le facteur limitant, les opérations en amont sont automatiquement régulées. Cette approche à mémoire limitée évite la consommation incontrôlée de mémoire qui handicape les systèmes concurrents.

Partitionnement adaptatif : les opérations gourmandes en mémoire comme url_download et image_decode ajustent automatiquement leur taille de batch en temps réel. Le système sacrifie le parallélisme granulaire pour une surcharge mémoire prévisible et un débit soutenu.

Coordination distribuée via Flotilla : chaque nœud du cluster exécute un worker Swordfish, permettant au modèle en streaming de s’étendre horizontalement sans compromis architectural. Les mêmes principes d’efficacité s’appliquent que ce soit pour traiter des téraoctets localement ou des pétaoctets à travers un cluster.

L’infrastructure du pipeline de données de Daft offre également des capacités natives spécifiquement pour les opérations multimodales : primitives d’encodage/décodage/coupage/redimensionnement d’images, couches d’intégration de texte et d’image, intégrations LLM, tokenisation, opérations de similarité cosinus, gestion d’URL, et conversions vidéo en frames, le tout en tant qu’expressions de première classe plutôt que comme des fonctions Python externes.

Approche de Ray Data : compromis en termes de généralité

Ray Data s’appuie sur le framework Python distribué Ray, exposant des abstractions de bas niveau. Les utilisateurs composent des opérations via des fonctions map_batches appliquées à des batches PyArrow ou des DataFrames pandas.

Dans les opérations séquentielles, Ray Data les fusionne en une seule tâche — une optimisation qui se retourne contre les charges de travail multimodales. Sans réglage manuel précis des tailles de blocs, la consommation mémoire peut exploser de façon imprévisible. Les utilisateurs peuvent matérialiser des intermédiaires dans le magasin d’objets de Ray en encapsulant la logique dans des classes, mais cela entraîne des coûts de sérialisation et des copies mémoire. Étant donné que le magasin d’objets de Ray n’utilise par défaut que 30 % de la mémoire système disponible, le déversement agressif sur disque devient inévitable.

La flexibilité du pipeline de données a un coût en termes de prévisibilité et d’efficacité.

La réalité des performances : les chiffres

Tests de référence sur une infrastructure identique (8 instances AWS g6.xlarge, chacune avec des GPU NVIDIA L4, 4 vCPU, 16 Go de RAM, 100 Go EBS) révèlent des différences marquantes :

Daft exécute les pipelines audio 4,6 à 29x plus vite que les alternatives. Le traitement de documents bénéficie d’une accélération de 4,2 à 7,6x. La classification d’images montre des améliorations de 5,4 à 10,3x. Les charges vidéo présentent l’écart le plus spectaculaire : Daft termine en 11m 46s alors que Spark nécessite 3h 36m — un décalage de 18,4x.

Pourquoi cet écart de performance ?

Opérations multimodales natives vs UDF externes : Daft implémente le décodage d’images, l’inférence d’embeddings et l’extraction de frames vidéo comme des expressions internes optimisées. Ray Data oblige les utilisateurs à écrire des UDF Python invoquant Pillow, NumPy, Hugging Face, et autres bibliothèques. Chaque bibliothèque maintient son propre format de données, créant des mouvements de données et des coûts de sérialisation inutiles.

Modèle de mémoire en streaming vs matérialisation : Daft diffuse les données de manière asynchrone depuis le stockage cloud via le CPU vers la mémoire GPU, puis retourne vers la sortie. Aucune partition ne se matérialise entièrement dans un buffer intermédiaire. La fusion des opérations de Ray Data provoque des pics de mémoire à moins que les utilisateurs n’optimisent manuellement la taille des blocs, et les solutions de contournement introduisent leurs propres pénalités de sérialisation.

Stratégie de saturation des ressources : Daft pipeline tout le traitement dans un seul worker Swordfish avec une gestion unifiée des ressources. Les téléchargements, le pré-traitement CPU, l’inférence GPU et l’upload des résultats s’écoulent dans le même contexte d’exécution, maintenant CPU, GPU et réseau constamment saturés. Ray Data réserve par défaut des cœurs CPU dédiés aux opérations I/O intensives, laissant des cœurs sous-utilisés pour le calcul. Obtenir une distribution optimale des ressources nécessite un réglage manuel fractionné du CPU.

Quel système pour quel scénario ?

Daft excelle lorsque :

• Traitement de jeux de données multimodaux (images, vidéo, audio, documents, embeddings)
• Priorité à la fiabilité et à des performances prévisibles sans surcharge de réglage
• Construction de transformations complexes de pipelines de données avec jointures, filtres et agrégations
• Équipes habituées aux sémantiques DataFrame/SQL

Ray Data reste précieux lorsque :

• Une intégration profonde à l’écosystème Ray est essentielle (Ray Train pour la formation distribuée, Ray Serve pour le déploiement de modèles)
• Un contrôle granulaire de l’allocation CPU/GPU par opération justifie la complexité supplémentaire

Validation en production

Test d’échelle d’Essential AI : L’équipe de Tim Romanski a taxonomisé 23,6 milliards de documents web issus de Common Crawl (24 trillions de tokens) en utilisant Daft, atteignant 32 000 requêtes par seconde par VM. Son évaluation : « Nous avons poussé Daft à ses limites et il est éprouvé en conditions réelles. Si nous devions reproduire cela avec Spark, il faudrait configurer la JVM, gérer le classpath, et faire beaucoup de dépannage juste pour lancer. Le temps d’exécution avec Daft était nettement plus court, et la montée en charge du développement local aux clusters a nécessité peu de modifications architecturales. »

Reconstruction de l’infrastructure de CloudKitchens : Cette équipe a restructuré toute leur plateforme ML autour du « stack DREAM » (Daft, Ray, poetry, Argo, Metaflow). Leur équipe infrastructure a identifié des limitations spécifiques de Ray Data lors de l’évaluation : couverture incomplète de DataFrame/ETL et performance sous-optimale. Ils ont choisi Daft pour compléter la couche de calcul de Ray, en notant notamment « Daft comble les lacunes de Ray Data en fournissant des API DataFrame complètes » et « offre une exécution plus rapide que Spark tout en consommant moins de ressources dans nos tests. »

Validation à grande échelle par ByteDance : Lors de l’évaluation de la classification d’images sur 1,28 million d’échantillons ImageNet, les ingénieurs de ByteDance ont constaté que Daft maintenait un débit environ 20 % supérieur à Ray Data. Leur analyse technique soulignait « une excellente performance d’exécution et une efficacité des ressources » ainsi que « un traitement en streaming fluide de jeux de données d’images à grande échelle. »

Perspectives

Le paysage des pipelines de données subit une transformation structurelle. Les charges de travail multimodales mettent en lumière des choix architecturaux qui ont fonctionné pour l’analyse traditionnelle mais échouent sous la pression de calcul hétérogène. La philosophie de conception de Daft — streaming continu, opérations multimodales natives, gestion adaptative des ressources et exécution unifiée du cluster — ne représente pas une simple optimisation incrémentale mais une réinitialisation de catégorie. Les organisations traitant à grande échelle des images, audio, documents et vidéos découvrent que la réarchitecture autour de ces principes permet d’obtenir des gains de 2 à 7 fois en performance sans sacrifier la fiabilité ni nécessiter une expertise approfondie en infrastructure.