従来のデータエンジン（Spark、Ray）は、画像、動画、音声といったマルチモーダルデータを処理する際に問題が生じ始めています。どこに問題があるのでしょうか？メモリの爆発、GPUの利用率が低い、単一のマシンでは全く持ちこたえられない。## マルチモーダルデータはなぜこんなに難しいのか圧縮されたJPEG画像は、デコードされると20倍に膨張します。1つのビデオファイルから数千のフレームが生成され、各フレームは数メガバイトです。同時にCPUとGPUが協力して働かなければなりません——この混合計算負荷は従来のエンジンを完全に混乱させます。## Daft vs Ray Data: パフォーマンスのギャップはどのくらい大きいか同じGPUクラスタ（8台のg6.xlarge + NVIDIA L4）で実際のワークロードを実行した結果は明白です：- **音声トランスクリプト** (113,000ファイル) :D 後方 6 分 22 秒 vs レイ データ 29 分 20 秒 (**4.6 倍差**)- **ドキュメント埋め込み** (10,000 PDF) :D 後方 1 分 54 秒 vs 光線データ 14 分 32 秒 (**7.6 倍差**) - **画像分類** (800,000枚) (800,000枚) :D 後方 4 分 23 秒 vs 光線データ 23 分 30 秒 (**5.4 倍差**)- **ビデオ検出** (1000 ビデオ) :D AFT 11 分 46 秒 vs スパーク 3 時間 36 分 (**18.4x 差**)## なぜこれほどの差があるのか**1. ネイティブ最適化 vs 自分でコードを書く**Daftは、画像デコード、テキスト埋め込み、LLM呼び出しなどのネイティブ操作を内蔵しており、高度に最適化されています。Ray Dataは、PillowやHuggingFaceなどのライブラリを使用して自分でPython関数を書く必要があります—各ライブラリには独自のデータ形式があり、相互変換はパフォーマンスのブラックホールになります。**2. ストリーミング処理 vs メモリ蓄積**Daftはストリーミング実行エンジン（Swordfish）を使用してデータを絶えず流動させます：1000枚目の画像がGPU推論中で、1001枚目から2000枚目の画像はまだダウンロードおよびデコード中です。全体のパーティションは決してメモリに完全にロードされることはありません。Ray Dataは操作を1つのタスクに統合する傾向があり、メモリの急増を引き起こす可能性があります。クラスを使用して回避することはできますが、その場合は中間結果がオブジェクトストレージに物化され、シリアライズのオーバーヘッドが増加します。また、Rayのオブジェクトストレージはデフォルトでマシンメモリの30%しかないため、オーバーフローのリスクが高いです。**3. リソース調整**DaftはCPU、GPU、ネットワークを同時にフル稼働させます。Ray DataはデフォルトでI/O操作のために1つのCPUコアを確保しており、CPUの処理作業が詰まることがあります。最適化するには手動での調整が必要です。## 実戦ケースはどう言うか**Essential AIチーム**：Daftを使用してCommon Crawlの236億のウェブドキュメント（24兆トークン）を処理し、1秒あたり3.2万リクエスト/VMに拡張しました。彼らの評価は——"Sparkを使うと、JVMのインストールやパラメータ調整だけでも大変です。Daftはローカルから始めるのがずっと早く、複数のマシンにスケールするのもスムーズです。"**CloudKitchens**：思い切って全MLインフラを"DREAM Stack"（Daft + Ray + Poetry + Argo + Metaflow）に変更しました。なぜなら、彼らはRay Dataの性能と機能が不十分であることに気づき、Daftがそのギャップを埋めたからです。**バイトダンスのエンジニア**：130万枚のImageNet画像で分類タスクを実行したところ、DaftはRay Dataより20%速く、さらにリソースを節約できました。## いつDaftを使い、いつRayを使うべきか**Daftを選択**：マルチモーダルデータ処理、複雑なETL、信頼性とパフォーマンスを重視、DataFrame/SQLスタイルが好き**レイ データの選択**: レイ トレイン/レイ サーブを緊密に統合するには、きめ細かな CPU/GPU 構成が必要です。---**重要な数字**：Daftはマルチモーダル処理で2-7倍速く、Sparkよりも4-18倍速く、かつ安定して信頼性があります。もしあなたのワークロードが大規模メディア処理に関わるのであれば、これはオプションではなく必須です。
マルチモーダルAIデータ処理のパフォーマンス競争：なぜDaftがデータパイプラインを再定義しているのか
従来のデータエンジン（Spark、Ray）は、画像、動画、音声といったマルチモーダルデータを処理する際に問題が生じ始めています。どこに問題があるのでしょうか？メモリの爆発、GPUの利用率が低い、単一のマシンでは全く持ちこたえられない。
マルチモーダルデータはなぜこんなに難しいのか
圧縮されたJPEG画像は、デコードされると20倍に膨張します。1つのビデオファイルから数千のフレームが生成され、各フレームは数メガバイトです。同時にCPUとGPUが協力して働かなければなりません——この混合計算負荷は従来のエンジンを完全に混乱させます。
Daft vs Ray Data: パフォーマンスのギャップはどのくらい大きいか
同じGPUクラスタ（8台のg6.xlarge + NVIDIA L4）で実際のワークロードを実行した結果は明白です：
なぜこれほどの差があるのか
1. ネイティブ最適化 vs 自分でコードを書く
Daftは、画像デコード、テキスト埋め込み、LLM呼び出しなどのネイティブ操作を内蔵しており、高度に最適化されています。Ray Dataは、PillowやHuggingFaceなどのライブラリを使用して自分でPython関数を書く必要があります—各ライブラリには独自のデータ形式があり、相互変換はパフォーマンスのブラックホールになります。
2. ストリーミング処理 vs メモリ蓄積
Daftはストリーミング実行エンジン（Swordfish）を使用してデータを絶えず流動させます：1000枚目の画像がGPU推論中で、1001枚目から2000枚目の画像はまだダウンロードおよびデコード中です。全体のパーティションは決してメモリに完全にロードされることはありません。
Ray Dataは操作を1つのタスクに統合する傾向があり、メモリの急増を引き起こす可能性があります。クラスを使用して回避することはできますが、その場合は中間結果がオブジェクトストレージに物化され、シリアライズのオーバーヘッドが増加します。また、Rayのオブジェクトストレージはデフォルトでマシンメモリの30%しかないため、オーバーフローのリスクが高いです。
3. リソース調整
DaftはCPU、GPU、ネットワークを同時にフル稼働させます。Ray DataはデフォルトでI/O操作のために1つのCPUコアを確保しており、CPUの処理作業が詰まることがあります。最適化するには手動での調整が必要です。
実戦ケースはどう言うか
Essential AIチーム：Daftを使用してCommon Crawlの236億のウェブドキュメント（24兆トークン）を処理し、1秒あたり3.2万リクエスト/VMに拡張しました。彼らの評価は——“Sparkを使うと、JVMのインストールやパラメータ調整だけでも大変です。Daftはローカルから始めるのがずっと早く、複数のマシンにスケールするのもスムーズです。”
CloudKitchens：思い切って全MLインフラを"DREAM Stack"（Daft + Ray + Poetry + Argo + Metaflow）に変更しました。なぜなら、彼らはRay Dataの性能と機能が不十分であることに気づき、Daftがそのギャップを埋めたからです。
バイトダンスのエンジニア：130万枚のImageNet画像で分類タスクを実行したところ、DaftはRay Dataより20%速く、さらにリソースを節約できました。
いつDaftを使い、いつRayを使うべきか
Daftを選択：マルチモーダルデータ処理、複雑なETL、信頼性とパフォーマンスを重視、DataFrame/SQLスタイルが好き
レイ データの選択: レイ トレイン/レイ サーブを緊密に統合するには、きめ細かな CPU/GPU 構成が必要です。
重要な数字：Daftはマルチモーダル処理で2-7倍速く、Sparkよりも4-18倍速く、かつ安定して信頼性があります。もしあなたのワークロードが大規模メディア処理に関わるのであれば、これはオプションではなく必須です。