Multimodal AI veri işleme performans karşılaştırması: Neden Daft veri borusunu yeniden tanımlıyor

Geleneksel veri motorları (Spark, Ray), çok modlu verileri (görüntü, video, ses) işlerken sorunlar yaşamaya başladı. Sorun nerede? Bellek patlaması, GPU kullanım oranı düşük, tek bir makine bunu destekleyemiyor.

Neden çok modlu veriler bu kadar zor?

Sıkıştırılmış bir JPEG görüntüsü, bir kez kodu çözülünce 20 katına çıkar. Bir video dosyası binlerce kare üretebilir, her kare birkaç megabayt büyüklüğünde. Aynı zamanda CPU ve GPU'nun birlikte çalışması gerekiyor - bu karışık hesaplama yükü geleneksel motorları tamamen şaşkına çevirdi.

Daft ve Ray Data: Performans farkı ne kadar büyük

Aynı GPU kümesinde (8 adet g6.xlarge + NVIDIA L4) gerçek iş yükleri çalıştırıldığında, sonuçlar oldukça net:

• Ses Transkripti (113,000 dosya): Daft 6 dakika 22 saniye vs Ray Data 29 dakika 20 saniye (4.6 kat fark)
• Doküman Gömmesi (10,000 PDF): Daft 1 dakika 54 saniye vs Ray Data 14 dakika 32 saniye (7.6 kat fark)
• Görüntü Sınıflandırma (800.000 resim): Daft 4 dakika 23 saniye vs Ray Data 23 dakika 30 saniye (5.4 kat fark)
• Video Kontrolü (1000 video): Daft 11 dakika 46 saniye vs Spark 3 saat 36 dakika (18.4 kat fark)

Neden bu kadar büyük bir fark var

1. Yerel Optimizasyon vs Kendi Kodunu Yazma

Daft, yerleşik görüntü kod çözme, metin gömme, LLM çağrıları gibi yerel işlemlerle yüksek düzeyde optimize edilmiştir. Ray Data, Pillow, HuggingFace gibi kütüphaneleri kullanarak kendiniz Python fonksiyonları yazmalısınız - her kütüphanenin kendi veri formatı vardır, dönüşüm yapmak performans kaynağıdır.

2. Akış İşleme vs Bellek Birikimi

Daft, akış yürütme motoru (Swordfish) ile verilerin sürekli hareket etmesini sağlar: 1000. resim GPU üzerinde çıkarım yaparken, 1001'den 2000'e kadar olan resimler hala indirilip kod çözülüyor. Tüm bölüm asla tamamen belleğe yüklenmeyecek.

Ray Data, işlemleri tek bir görevde birleştirme eğilimindedir, bu da bellek patlamasına neden olabilir. Bunu aşmak için sınıfları kullanabilirsiniz, ancak bu, ara sonuçların nesne depolamasına fiziksel hale gelmesine neden olur ve seri hale getirme maliyetini artırır. Ayrıca, Ray'in nesne depolaması varsayılan olarak yalnızca makinelerin belleğinin %30'unu kullanır, bu da patlama riski taşır.

3. Kaynak Koordinasyonu

Daft, CPU, GPU ve ağı aynı anda tam kapasite çalıştırır. Ray Data, I/O işlemleri için varsayılan olarak bir CPU çekirdeğini ayırır, bu da CPU'nun işleme görevlerinin kilitlenmesine neden olabilir ve optimizasyon için manuel ayarlama gerektirir.

Uygulamalı Örnekler Nasıl Söylenir

Essential AI Ekibi: Daft ile Common Crawl'daki 23.6 milyar web belgesini (240 trilyon token) işleyerek saniyede 32.000 istek/VM'ye genişlediler, değerlendirmeleri şudur - “Eğer Spark kullanırsak, sadece JVM'yi kurmak ve parametreleri ayarlamak bile büyük bir çaba gerektiriyor. Daft yerel olarak çok daha hızlı çalışıyor, çoklu makinelerde de ölçeklenmesi çok kolay.”

CloudKitchens: Tüm ML altyapısını “DREAM Stack” (Daft + Ray + Poetry + Argo + Metaflow) olarak değiştirmeye karar verdiler, çünkü Ray Data'nın performansı ve işlevselliği yetersizdi, Daft bu açığı kapattı.

ByteDance Mühendisi: 1.3 milyon ImageNet görüntüsü üzerinde sınıflandırma görevini çalıştırdığımızda, Daft, Ray Data'dan %20 daha hızlı ve daha az kaynak kullanıyor.

Daft ne zaman kullanılır, Ray ne zaman kullanılır

Daft'ı Seçin: Çok modlu veri işleme, karmaşık ETL, güvenilirlik ve performansa önem verme, DataFrame/SQL tarzını sevme

Ray Veri Seç: Ray Train/Ray Serve'in sıkı entegrasyonu için ayrıntılı CPU/GPU yapılandırması gerekmektedir.

Anahtar Sayılar: Daft, çok modlu işleme konusunda %200-700 daha hızlıdır, Spark'tan %400-1800 daha hızlıdır ve aynı zamanda kararlı ve güvenilirdir. Eğer iş yükünüz büyük ölçekli medya işleme ile ilgiliyse, bu bir seçenek değil, zorunluluktur.