155 測定値

データローダーの概要: 実験的なセットアップ

に The Serialization Publication6m2024/06/04

長すぎる; 読むには

この論文では、研究者はデータローダーを ML トレーニング改善の鍵として強調し、ライブラリの機能性、使いやすさ、パフォーマンスを比較しています。

著者:

（１）イアソン・オフェイディス、イェール大学電気工学部およびイェールネットワーク科学研究所、ニューヘブン {同等の貢献}

（２）ディエゴ・キエダンスキ、イェール大学電気工学部およびイェールネットワーク科学研究所、ニューヘブン {同等の貢献}

（3）Leandros TassiulasLevon Ghukasyan、Activeloop、米国カリフォルニア州マウンテンビュー、電気工学部およびイェール大学ネットワーク科学研究所、ニューヘブン。

リンク一覧

3. 実験のセットアップ

いくつかのライブラリとデータセットを選択し、その機能とパフォーマンスを比較しました。できるだけ分かりやすくするよう努力しましたが、データ読み込みの分野は常に進化しており、新しいライブラリとリリースが毎日追加されています。この点で、次のリストは、必ずしも全体的に最高であると主張したり見つけたりすることなく、データローダーの現在の機能の概要を示すことを期待しています (これは、執筆時から公開時までに変わる可能性があります)。実験のすべてのソースコードを一般に公開し、結果が完全に再現可能であることを期待しています。

実験を行うために、PyTorch (Paszke et al., 2019)、Torchdata (TorchData、2021)、Hub (Team、2022a)、FFCV (Leclerc et al., 2022)、Webdatasets (Webdataset、2013)、Squirrel (Team、2022b)、Deep Lake (Hambardzumyan et al., 2022) の 7 つのライブラリを選択しました。興味深いことに、すべてのライブラリが同じ機能をサポートしているわけではありません。たとえば、S3 バケットにホストされているデータセットを使用して FFCV を実行し、リモート実験を行うことはできませんでした。セクション 1 で述べたように、すべての実験は PyTorch で実行しています。他の一般的な機械学習フレームワークで実験を再現することも検討しましたが、2 番目の候補は Tensorflow だったため、このアイデアは採用しませんでした。ただし、Google は Tensorflow から JAX に移行しているという噂があります。図 1 は、過去 12 か月間のさまざまな ML フレームワークの人気を示しています。

3.1 データセット

データセットに関しては、当初は2つの異なる学習タスクをサポートするために2つの古典的なデータセットを選択しました。画像分類にはCIFAR-10 (Krizhevsky et al., 2009)、物体検出にはCoCo (Lin et al., 2014)です。いくつかの実験を行っているときに、次のような奇妙な動作（ライブラリが予想よりも良いパフォーマンスを発揮する）が見られました。

CIFAR-10はメモリに収まりきらない[2]。このため、ランダムに生成された256×256ピクセルのカラー画像と20のランダムクラスで構成されるRANDOMという3番目のデータセットを構築しました。この3番目のデータセットには、トレーニング用に45000枚、検証用に5000枚、テスト用に500枚の画像が含まれており、CIFAR-10よりもかなり大きいです。

ベンチマークを比較できるように、すべてのライブラリに同じ変換を使用しました。唯一の例外は、さまざまな変換を独自に実装している FFCV です。画像分類の場合、変換スタックは、ランダム水平反転、正規化、切り取り、テンソルへの変換で構成されます。

物体検出については、Albumentations (Buslaev et al., 2020) の変換実装に主に頼りました。スタックは次のようになります: ランダムサイズの切り抜き、ランダム水平反転、正規化、テンソルへの変換。これらの変換は、画像と境界ボックスの両方に適用されます。

3.2 実験のバリエーション

可能な場合は、データセットをローカルで、S3 と同等のバケットにホストしました。これにより、ネットワーク上のデータストリームからのトレーニングによって生じる速度低下を評価することができました。トレーニング設定の詳細については、セクション 4 で説明します。

最も集中的なトレーニングジョブでは複数の GPU を使用する必要があるため、可能な限り、複数の GPU ユニットがある環境でも同じ実験を実行しました。実験を実行した時点では、すべてのライブラリが PyTorch Lightning を完全にサポートしていたわけではないため、PyTorch の Distributed Data Parallel (DDP) (Li et al.、2020) ライブラリを使用してマルチ GPU を実装することにしました。

一部の機械学習プロジェクトでは、大規模なデータセットのサブセットのみにアクセスする必要があるかもしれません。そのような場合、データセット全体を反復処理することなく必要なデータポイントをすばやくフィルター処理する機能があれば、トレーニングの合計時間を大幅に短縮できます。一部のライブラリでは、クラス (画像分類タスク用) などの特定の機能に基づいてフィルター処理できます。ライブラリが提供するフィルター処理方法 (提供されている場合) を使用する場合とまったくフィルター処理しない場合の速度の向上 (または低下) を調査しました。ライブラリがフィルター処理方法を提供していない場合は、データセット全体をスキャンし、指定された条件に一致する要素のみを保持するという単純な方法で実装しました。高速フィルター処理は、すべてのサンプルを反復処理しないようにするためにインデックスのような追加の構造を維持する必要があるため、実装が必ずしも簡単ではありません。

最後に、表 1 では、この論文で検討したさまざまな実験やデータセットとさまざまなライブラリの互換性を示します。

3.3 メトリクス

実験を構築する際の私たちの主な優先事項は、さまざまなライブラリをすべて適切な方法で比較できる客観的な指標を見つけることでした。

理想的な指標は、トレーニングジョブの合計実行時間です。これは、待機して料金を支払わなければならないものだからです。残念ながら、そうすると実行できる実験の数が大幅に制限されます。慎重に検討した結果、数値実験によって裏付けられた結果である、1 秒あたりの処理データポイント (画像) の数を選択しました。この指標には 2 つのバリエーションがあります。1 つは ML モデルを使用してトレーニングし、バックプロパゲーションを実行するもので、もう 1 つは ML モデルを使用せず、サンプルを反復処理して GPU にコピーするものです。2 つの指標の違いは、アルゴリズム 1 のトレーニングループの疑似コードからわかります。ここで、m は速度変数を表します。また、合計実行時間 [3] とデータローダーの初期化にかかった時間も収集しました。後者は、一部のライブラリがトレーニング中に速度を上げるために事前に高価な計算を実行する可能性があるという事実に動機付けられました。また、速度を計算するためのウォームアップも実行しました。これについては、サブセクション 3.5 で詳しく説明します。

3.4 速度と走行時間の相関関係

3.5 走行時間を詳しく見る

各ライブラリの内部メカニズムの理解を深めるために、1 回の実行で各バッチの実行とデータローダーの初期化にかかった時間を調べることにしました。図 3 は、パラメータの 1 つの組み合わせ [4] について、アルゴリズム 1 で説明した手順で各ライブラリにかかった時間を示しています。これらの実験はすべて、10 バッチ後にカットオフされました。

興味深いことに、最初のバッチは他のバッチよりもかなり長い時間がかかります。これは次のように説明できます。ほとんどのデータローダーはこの時点でデータの遅延読み込みに依存しているため、将来の呼び出しではプリフェッチ、メモリ内に既に存在するデータ、並列化 (GPU が計算でビジー状態になっている間に処理を実行する) のメリットが得られます。

バンド1から9のサイズは、各ライブラリのスケーリングの程度を示す最良の指標となります。

大規模なデータセットは、その幅に比例して増加します。ほとんどのライブラリの幅は均一で、Deep Lake が最も短い (最速) ことがわかります。一方、不均一な幅を示す唯一のライブラリは FFCV で、バンド 1 から 3 は非常に細いため、画像では見えません。

ラップアップ期間は、FFCV と Deep Lake を除くすべてのライブラリでほぼ同じ時間がかかります。FFCV と Deep Lake ではラップアップにかなり長い時間がかかります。ラップアップにかかる時間は主にモデルによって異なり、必ずしも各ライブラリのスケーリングの程度を示すものではありません。

この数値に基づいて、速度を計算するときにウォームアップを実行することにしました。これは、すべての速度計算で最初のバッチにかかる時間を無視することを意味します。