Les moteurs de données traditionnels (Spark, Ray) commencent à avoir des problèmes lorsqu'ils traitent des données multimodales telles que les images, les vidéos et l'audio. Où est le problème ? Explosion de la mémoire, faible utilisation du GPU, une seule machine ne peut tout simplement pas supporter.
Pourquoi les données multimodales sont-elles si difficiles à traiter
Une image JPEG compressée, une fois décodée, se dilate 20 fois. Un fichier vidéo peut générer des milliers d'images, chacune pesant plusieurs mégaoctets. De plus, le CPU et le GPU doivent travailler ensemble - cette charge de calcul hybride laisse complètement perplexes les moteurs traditionnels.
Daft vs Ray Data : Quelle est la différence de performance ?
Sur un cluster GPU identique (8 g6.xlarge + NVIDIA L4) exécutant une charge de travail réelle, les résultats sont très clairs :
Transcription audio (113 000 fichiers) : Daft 6 minutes 22 secondes contre Ray Data 29 minutes 20 secondes (écart de 4,6 fois)
Intégration de documents (10 000 PDF) : Daft 1 min 54 sec vs Ray Data 14 min 32 sec (écart de 7,6 fois)
Classification d'images (800 000 images) : Daft 4 min 23 s vs Ray Data 23 min 30 s (écart de 5,4 fois)
Détection vidéo (1000 vidéos) : Daft 11 minutes 46 secondes contre Spark 3 heures 36 minutes (écart de 18,4 fois)
Pourquoi l'écart est-il si grand
1. Optimisation native vs écrire son propre code
Daft intègre des opérations natives telles que le décodage d'image, l'insertion de texte et l'appel de LLM, le tout hautement optimisé. Ray Data nécessite que vous écriviez des fonctions Python vous-même en utilisant des bibliothèques comme Pillow et HuggingFace - chaque bibliothèque a son propre format de données, et les conversions répétées deviennent un gouffre de performance.
2. Traitement en flux vs Accumulation en mémoire
Daft utilise le moteur d'exécution en continu (Swordfish) pour faire circuler les données : la 1000e image est en cours d'inférence sur le GPU, tandis que les images 1001 à 2000 sont encore en cours de téléchargement et de décodage. L'ensemble de la partition ne sera jamais complètement chargé en mémoire.
Ray Data a tendance à fusionner les opérations en une seule tâche, ce qui peut entraîner une augmentation excessive de la mémoire. Vous pouvez utiliser des classes pour contourner ce problème, mais cela matérialiserait les résultats intermédiaires dans le stockage d'objets, augmentant ainsi les coûts de sérialisation. De plus, le stockage d'objets de Ray n'utilise par défaut que 30 % de la mémoire de la machine, ce qui présente un risque élevé de saturation.
3. Coordination des ressources
Daft permet de faire fonctionner le CPU, le GPU et le réseau à pleine capacité en même temps. Ray Data réserve par défaut un cœur CPU pour les opérations d'I/O, ce qui peut bloquer le travail de traitement du CPU, nécessitant un ajustement manuel pour optimiser.
Comment dire un cas pratique
Équipe Essential AI : Traitement de 236 milliards de documents web de Common Crawl avec Daft (24 billions de tokens), étendu à 32 000 requêtes/seconde/VM, leur évaluation est - “Si on utilise Spark, rien que l'installation de la JVM et le réglage des paramètres, ça demande beaucoup d'efforts. Daft fonctionne beaucoup plus vite en local et s'étend facilement à plusieurs machines.”
CloudKitchens : Ils ont décidé de transformer toute l'infrastructure ML en “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow), car ils ont constaté que les performances et les fonctionnalités de Ray Data n'étaient pas suffisantes, Daft a comblé cette lacune.
Ingénieur ByteDance : Exécutant des tâches de classification sur 1,3 million d'images ImageNet, Daft est 20% plus rapide que Ray Data et utilise encore moins de ressources.
Quand utiliser Daft et quand utiliser Ray
Choisir Daft : traitement de données multimodales, ETL complexe, soucieux de la fiabilité et des performances, aime le style DataFrame/SQL
Sélectionner Ray Data : Intégration étroite souhaitée avec Ray Train/Ray Serve, nécessitant une configuration CPU/GPU granulée.
Chiffres clés : Daft est 2 à 7 fois plus rapide dans le traitement multimodal, 4 à 18 fois plus rapide que Spark, et il est stable et fiable. Si votre charge de travail implique un traitement média à grande échelle, ce n'est pas une option, c'est une nécessité.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
La compétition de performance dans le traitement des données multimodales par l'IA : pourquoi Daft redéfinit le pipeline de données.
Les moteurs de données traditionnels (Spark, Ray) commencent à avoir des problèmes lorsqu'ils traitent des données multimodales telles que les images, les vidéos et l'audio. Où est le problème ? Explosion de la mémoire, faible utilisation du GPU, une seule machine ne peut tout simplement pas supporter.
Pourquoi les données multimodales sont-elles si difficiles à traiter
Une image JPEG compressée, une fois décodée, se dilate 20 fois. Un fichier vidéo peut générer des milliers d'images, chacune pesant plusieurs mégaoctets. De plus, le CPU et le GPU doivent travailler ensemble - cette charge de calcul hybride laisse complètement perplexes les moteurs traditionnels.
Daft vs Ray Data : Quelle est la différence de performance ?
Sur un cluster GPU identique (8 g6.xlarge + NVIDIA L4) exécutant une charge de travail réelle, les résultats sont très clairs :
Pourquoi l'écart est-il si grand
1. Optimisation native vs écrire son propre code
Daft intègre des opérations natives telles que le décodage d'image, l'insertion de texte et l'appel de LLM, le tout hautement optimisé. Ray Data nécessite que vous écriviez des fonctions Python vous-même en utilisant des bibliothèques comme Pillow et HuggingFace - chaque bibliothèque a son propre format de données, et les conversions répétées deviennent un gouffre de performance.
2. Traitement en flux vs Accumulation en mémoire
Daft utilise le moteur d'exécution en continu (Swordfish) pour faire circuler les données : la 1000e image est en cours d'inférence sur le GPU, tandis que les images 1001 à 2000 sont encore en cours de téléchargement et de décodage. L'ensemble de la partition ne sera jamais complètement chargé en mémoire.
Ray Data a tendance à fusionner les opérations en une seule tâche, ce qui peut entraîner une augmentation excessive de la mémoire. Vous pouvez utiliser des classes pour contourner ce problème, mais cela matérialiserait les résultats intermédiaires dans le stockage d'objets, augmentant ainsi les coûts de sérialisation. De plus, le stockage d'objets de Ray n'utilise par défaut que 30 % de la mémoire de la machine, ce qui présente un risque élevé de saturation.
3. Coordination des ressources
Daft permet de faire fonctionner le CPU, le GPU et le réseau à pleine capacité en même temps. Ray Data réserve par défaut un cœur CPU pour les opérations d'I/O, ce qui peut bloquer le travail de traitement du CPU, nécessitant un ajustement manuel pour optimiser.
Comment dire un cas pratique
Équipe Essential AI : Traitement de 236 milliards de documents web de Common Crawl avec Daft (24 billions de tokens), étendu à 32 000 requêtes/seconde/VM, leur évaluation est - “Si on utilise Spark, rien que l'installation de la JVM et le réglage des paramètres, ça demande beaucoup d'efforts. Daft fonctionne beaucoup plus vite en local et s'étend facilement à plusieurs machines.”
CloudKitchens : Ils ont décidé de transformer toute l'infrastructure ML en “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow), car ils ont constaté que les performances et les fonctionnalités de Ray Data n'étaient pas suffisantes, Daft a comblé cette lacune.
Ingénieur ByteDance : Exécutant des tâches de classification sur 1,3 million d'images ImageNet, Daft est 20% plus rapide que Ray Data et utilise encore moins de ressources.
Quand utiliser Daft et quand utiliser Ray
Choisir Daft : traitement de données multimodales, ETL complexe, soucieux de la fiabilité et des performances, aime le style DataFrame/SQL
Sélectionner Ray Data : Intégration étroite souhaitée avec Ray Train/Ray Serve, nécessitant une configuration CPU/GPU granulée.
Chiffres clés : Daft est 2 à 7 fois plus rapide dans le traitement multimodal, 4 à 18 fois plus rapide que Spark, et il est stable et fiable. Si votre charge de travail implique un traitement média à grande échelle, ce n'est pas une option, c'est une nécessité.