تحدي أداء معالجة بيانات الذكاء الاصطناعي متعدد الوسائط: لماذا يعيد Daft تعريف أنابيب البيانات

تبدأ محركات البيانات التقليدية (Spark، Ray) في فقدان القدرة على التعامل مع البيانات متعددة الأنماط مثل الصور والفيديو والصوت. أين تكمن المشكلة؟ انفجار الذاكرة، انخفاض نسبة استخدام GPU، وعدم قدرة الأجهزة الفردية على التحمل.

لماذا تعتبر البيانات متعددة الأبعاد صعبة الفهم

صورة JPEG مضغوطة، بمجرد فك تشفيرها ستتضخم 20 مرة. يمكن لملف الفيديو أن يولد آلاف الإطارات، كل إطار منها عدة ميغابايت. وفي الوقت نفسه، يجب أن يعمل كل من وحدة المعالجة المركزية ووحدة معالجة الرسومات معًا - هذا الحمل الحسابي المختلط جعل المحركات التقليدية في حيرة من أمرها.

دا프트 مقابل راي داتا: ما مدى الفجوة في الأداء

على مجموعة GPU المماثلة (8 g6.xlarge + NVIDIA L4) تعمل تحت ضغط عمل حقيقي، كانت النتائج واضحة جدًا:

• نسخ الصوت (113,000 ملف): Daft 6 دقائق و22 ثانية مقابل Ray Data 29 دقيقة و20 ثانية (فارق 4.6 مرات)
• تضمين الوثائق (10,000 PDF): دافت 1:54 مقابل راي داتا 14:32 (فرق 7.6 مرة)
• تصنيف الصور (800,000 صورة): Daft 4 دقيقة 23 ثانية مقابل Ray Data 23 دقيقة 30 ثانية (فارق 5.4 أضعاف)
• كشف الفيديو (1000 فيديو): Daft 11 دقيقة و46 ثانية مقابل Spark 3 ساعات و36 دقيقة (فرق 18.4 مرة)

لماذا الفجوة كبيرة جدا

1. تحسين أصلي مقابل كتابة الكود الخاص بك

تمتلك Daft عمليات أصلية مثل فك تشفير الصور، تضمين النصوص، واستدعاء LLM، وقد تم تحسينها بشكل كبير. يعتمد Ray Data على كتابة دوال Python بنفسك باستخدام مكتبات مثل Pillow وHuggingFace - كل مكتبة لها تنسيق بيانات خاص بها، مما يجعل التحويل المتكرر بينها هو ثقب أسود في الأداء.

2. المعالجة المتدفقة مقابل تراكم الذاكرة

تتيح محرك التنفيذ المتدفق (Swordfish) لـ Daft تدفق البيانات بلا توقف: الصورة رقم 1000 قيد الاستدلال على وحدة معالجة الرسوميات، والصور من 1001 إلى 2000 لا تزال قيد التحميل وفك الترميز. لا يتم تحميل القسم بأكمله بالكامل في الذاكرة أبداً.

تميل Ray Data إلى دمج العمليات في مهمة واحدة، مما يؤدي بسهولة إلى زيادة هائلة في الذاكرة. يمكنك استخدام الفئات لتجنب ذلك، ولكن هذا سيؤدي إلى تخزين النتائج الوسيطة في تخزين الكائنات، مما يزيد من تكلفة التسلسل. بالإضافة إلى ذلك، فإن التخزين الافتراضي للكائنات في Ray يستخدم فقط 30% من ذاكرة الآلة، مما يزيد من مخاطر الانفجار.

3. تنسيق الموارد

دافت يجعل وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسوميات (GPU) والشبكة تعمل بكامل طاقتها في نفس الوقت. يحتفظ Ray Data بشكل افتراضي بنواة واحدة من وحدة المعالجة المركزية لعمليات الإدخال/الإخراج، مما يؤدي بسهولة إلى توقف معالجة العمل على وحدة المعالجة المركزية، ويحتاج إلى ضبط يدوي للمعلمات من أجل تحسين الأداء.

كيف نقول حالة دراسية

فريق Essential AI: معالجة 236 مليار وثيقة ويب من Common Crawl باستخدام Daft (240 تريليون توكن)، وتوسيعها إلى 32,000 طلب/ثانية/آلة افتراضية، تقييمهم هو - "إذا استخدمنا Spark، فإن تثبيت JVM وضبط المعلمات سيكون مجهدًا. Daft يعمل بسرعة أكبر بكثير من المحلي، والتوسع إلى عدة آلات أيضًا سلس. "

CloudKitchens: قرروا تحويل البنية التحتية ML بالكامل إلى “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow)، لأنهم اكتشفوا أن أداء Ray Data وميزاته ليست كافية، وقد أكمل Daft هذه الفجوة.

مهندس ByteDance: لقد تم تنفيذ مهمة التصنيف على 1.3 مليون صورة من ImageNet، Daft أسرع بنسبة 20% من Ray Data، كما أنه أكثر كفاءة في استهلاك الموارد.

متى نستخدم Daft ومتى نستخدم Ray

اختيار Daft: معالجة البيانات متعددة الأنماط، ETL المعقد، يهتم بالموثوقية والأداء، يفضل أسلوب DataFrame/SQL

اختيار Ray Data: إذا كنت ترغب في تكامل وثيق مع Ray Train/Ray Serve وتحتاج إلى تكوين دقيق لوحدات المعالجة المركزية/وحدات معالجة الرسومات.

الأرقام الرئيسية: Daft أسرع من 2-7 مرات في المعالجة متعددة الوسائط، وأسرع من Spark من 4-18 مرة، وهو مستقر وموثوق. إذا كانت عبء عملك تتضمن معالجة الوسائط على نطاق واسع، فهذه ليست خيارًا، بل خيار إلزامي.