ネイティブなマルチモーダル操作 vs 外部UDF：Daftは画像デコード、埋め込み推論、動画フレーム抽出を最適化された内部式として実装しています。一方、Ray DataはPillowやNumPy、Hugging Faceなどのライブラリを呼び出すPython UDFを書く必要があります。これらのライブラリはそれぞれ独自のデータフォーマットを持ち、不必要なデータ移動とシリアライズオーバーヘッドを生み出します。
ストリーミングメモリモデル vs マテリアライズ：DaftはクラウドストレージからCPUを経由してGPUメモリへと非同期にデータをストリーミングし、出力へと戻します。パーティションは完全に中間バッファにマテリアライズされません。Ray Dataの操作融合はメモリスパイクを引き起こし、手動でブロックサイズを最適化しないと、シリアライズのペナルティが発生します。
Daftがマルチモーダルワークロード向けにデータパイプラインを再構築：完全なアーキテクチャとパフォーマンス分析
マルチモーダルAIアプリケーションの爆発的な普及は、従来のデータ処理インフラの重要なギャップを露呈しています。SparkやRay Dataが画像デコード、音声書き起こし、動画フレーム抽出に取り組むと、その硬直したアーキテクチャは崩壊します。メモリは予測不能に膨張し、GPUサイクルはI/Oのボトルネック中にアイドリングし、クラスターは巨大な非効率性を蓄積します。Daftは、分散データシステムが異種の計算要求をどのように扱うべきかについて、根本的な再考を示しています。
マルチモーダルデータ処理が他と異なる理由
従来のデータパイプラインエンジンは、SQLの集約やテーブル結合向けに構築されていました。マルチモーダルワークロードは、まったく異なる次元で動作します。
メモリ膨張：JPEGファイルは解凍後に20倍に膨れ上がります。2時間の動画は何千もの個別フレームにデコードされ、それぞれがメガバイトを消費します。データパイプラインはこれらの爆発を予測し、動的に管理しなければなりません。
断片化した計算要求：処理チェーンは、同時にCPU、GPU、ネットワークの飽和を要求します。単一のワークロードには、ダウンロード、デコード、リサンプリング、特徴抽出、正規化、推論、分類などが含まれ、これらは異なるハードウェアコンポーネントに異なるフェーズで負荷をかけます。
スケールの要求：最近の実運用ワークロードは驚くべき規模に達しています。Common Voice 17には113,800の音声ファイル、Common Crawlには10,000のPDF、ImageNetは803,580の画像、Hollywood2には1,000の動画があります。これらすべてにシームレスにスケールできるデータパイプラインインフラが必要です。
Daftのストリーミングアーキテクチャ：ボトルネックを打破
Daftは、データの流れを根本的に再構築します。そのSwordfishストリーミング実行エンジンは、データを静的なバッチではなく、常に動き続けるものとして扱います。
連続フローモデル：100,000画像を含むパーティションの場合、最初の1,000枚はすぐにGPU推論に入り、次のバッチはダウンロードやデコードを行います。中間のマテリアライズポイントは一切なく、パイプラインのブロックはありません。システムはすべての処理段階で常に動き続けます。
インテリジェントなバックプレッシャー：GPU推論が制約となる場合、上流の操作は自動的にスロットルします。この境界付きメモリアプローチは、競合システムが抱えるメモリの暴走を防ぎます。
適応的パーティショニング：url_downloadやimage_decodeのようなメモリ集約型操作は、リアルタイムでバッチサイズを自動調整します。システムは粒度の細かい並列性を犠牲にして、予測可能なメモリオーバーヘッドと持続的なスループットを実現します。
Flotillaによる分散コーディネーション：各クラスターのノードはSwordfishワーカーを1つずつ実行し、水平スケーリングを可能にします。大容量のローカルまたはクラスタ全体のペタバイト規模の処理でも、同じ効率原則が適用されます。
Daftのデータパイプラインは、マルチモーダル操作に特化したネイティブ機能も備えています。画像のエンコード/デコード/クロッピング/リサイズのプリミティブ、テキストと画像の埋め込み層、LLM統合、トークナイゼーション、コサイン類似度演算、URL処理、動画からフレームへの変換などが、外部のPython関数ではなく、ファーストクラスの式として存在します。
Ray Dataのアプローチ：汎用性のトレードオフ
Ray Dataは、Rayの分散Pythonフレームワークの上に構築され、低レベルの抽象化を公開します。ユーザーは、PyArrowバッチやpandas DataFrameに適用するmap_batches関数を通じて操作を構成します。
連続操作内では、Ray Dataはそれらを単一のタスクに融合しますが、これはマルチモーダルワークロードには逆効果です。ブロックサイズを慎重に手動調整しないと、メモリ消費が予測不能に急増します。中間結果はRayのオブジェクトストアにラップしてマテリアライズできますが、これにはシリアライズのオーバーヘッドとメモリコピーが伴います。Rayのオブジェクトストアは利用可能なシステムメモリの30%しか使用できないため、積極的なディスクスピルが避けられません。
この柔軟性は、予測性と効率性の犠牲の上に成り立っています。
パフォーマンスの現実：数字で見る差
同じインフラ上でのベンチマーク（(8 AWS g6.xlargeインスタンス、各にNVIDIA L4 GPU、4 vCPU、16 GBメモリ、100 GB EBS)）は、次のような顕著な差を示しています。
Daftは音声パイプラインを4.6〜29倍高速で実行し、ドキュメント処理も4.2〜7.6倍の加速を示します。画像分類は5.4〜10.3倍の改善をもたらし、動画ワークロードでは最も劇的な差が見られます。Daftは11分46秒で完了しますが、Sparkは3時間36分かかり、18.4倍の差となっています。
なぜこのパフォーマンスの差が生まれるのか？
ネイティブなマルチモーダル操作 vs 外部UDF：Daftは画像デコード、埋め込み推論、動画フレーム抽出を最適化された内部式として実装しています。一方、Ray DataはPillowやNumPy、Hugging Faceなどのライブラリを呼び出すPython UDFを書く必要があります。これらのライブラリはそれぞれ独自のデータフォーマットを持ち、不必要なデータ移動とシリアライズオーバーヘッドを生み出します。
ストリーミングメモリモデル vs マテリアライズ：DaftはクラウドストレージからCPUを経由してGPUメモリへと非同期にデータをストリーミングし、出力へと戻します。パーティションは完全に中間バッファにマテリアライズされません。Ray Dataの操作融合はメモリスパイクを引き起こし、手動でブロックサイズを最適化しないと、シリアライズのペナルティが発生します。
リソース飽和戦略：Daftはすべての処理を単一のSwordfishワーカー内で行い、リソース管理を統一します。ダウンロード、CPU前処理、GPU推論、結果のアップロードが同じ実行コンテキストを流れ、CPU、GPU、ネットワークを常に飽和させます。Ray DataはデフォルトでI/O負荷の高い操作に専用のCPUコアを予約し、計算用コアは未使用のままです。最適なリソース配分には、手動のCPUの分割調整が必要です。
どのシステムをどのシナリオで選ぶべきか？
Daftが優れる場面：
Ray Dataが価値を持つ場面：
実運用での検証
Essential AIのスケールテスト：Tim Romanskiのチームは、Daftを用いてCommon CrawlのWebドキュメント236億件（(24兆トークン)）を分類し、VMあたり32,000リクエスト/秒にスケールさせました。彼の評価：「Daftを限界まで追い込み、実戦投入に耐えられることを確認しました。Sparkでこれを再現するにはJVM設定やクラスパス管理、トラブルシューティングが必要で、Daftの方がはるかに短時間で完了し、ローカルからクラスターへのスケールも最小限のアーキテクチャ変更で済みました。」
CloudKitchensのインフラ再構築：このチームは、MLプラットフォームを「DREAMスタック」（(Daft、Ray、Poetry、Argo、Metaflow)）に再構築。評価中にRay Dataの制限点を特定し、「DataFrame/ETLのカバレッジ不足とパフォーマンスの最適化不足」を指摘。DaftをRayの計算層の補完として採用し、「DaftはRay Dataのギャップを埋め、包括的なDataFrame APIを提供し、Sparkより高速な実行と少ないリソース消費を実現した」と述べています。
ByteDanceの大規模検証：1.28百万のImageNetサンプルで画像分類を評価した結果、DaftはRay Dataより約20%高速であることを確認。技術的な分析では、「優れた実行性能とリソース効率」、「大規模画像データセットのシームレスなストリーミング処理」を強調しています。
今後の展望
データパイプラインの世界は、構造的な変革を迎えつつあります。マルチモーダルワークロードは、従来の分析に適していたアーキテクチャの決定が、異種計算圧力の下では失敗することを露呈しています。Daftの設計思想—連続ストリーミング、ネイティブなマルチモーダル操作、適応的リソース管理、統一されたクラスター実行—は、単なる漸進的な最適化ではなく、カテゴリーのリセットを意味します。画像、音声、ドキュメント、動画を大規模に処理する組織は、これらの原則に基づく再アーキテクチャ化によって、信頼性を犠牲にせずに2〜7倍のパフォーマンス向上を実現しています。