113 測定値

データローダーの概要: 数値結果

に The Serialization Publication7m2024/06/04

長すぎる; 読むには

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

著者:

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

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

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

リンク一覧

4. 数値結果

最初の一連の実験では、ワーカー数（2を参照）とバッチサイズを変更したときのすべてのライブラリのパフォーマンスを評価しました。これらの実験は、Intel(R) Core(TM) i9-10900K、2 x NVIDIA GeForce RTX 3090、および10TBのストレージ（6GB / s）を備えたHDD [5]という仕様のローカルサーバーで実行されました。

0、1、2 人のワーカーのあらゆる組み合わせについて、デフォルト (単一 GPU)、分散 (2 つの GPU)、フィルタリング (単一 GPU) の 3 つのモードを評価しました。CIFAR10 と RANDOM の場合、バッチサイズは 16、64、128 のいずれかでした。CoCo の場合、1、2、4 という小さい値を使用しました。これらの実験ではすべて、カットオフ 10 とモデルを実行するバリアント (フォワードパスとバックワードパス) を使用しました。

4.1 バッチサイズとワーカーの関数としての速度

実験を調べているときに最初に気づくのは、ライブラリ間の差異は問題と使用されるデータセットによって異なるということです。図 4 は、単一の GPU 上の CIFAR10 のそのような比較の 1 つを示しています。一方、図 5 は、同じく単一の GPU 上の CoCo の同じ結果を示しています。

これは、後者では、前方パスと後方パスの計算にかかる時間が全体の実行時間の大部分を占めることを考えると予想通りであるが、画像の場合はそうではない。

分類。また、全体的な速度の違いにも気づくでしょう。1 秒あたり 4000 サンプルから 20 サンプルに減少しました。

次に、バッチサイズを増やすと、ほとんどの場合、処理速度が上がることを指摘します。ただし、ワーカー数の場合はそうではありません。図 6 を見ると、FFCV のパフォーマンスはワーカー数が増えるにつれて低下しますが、Deep Lake はワーカー数が 2 ではなく 1 で安定していることがわかります。1 つの説明として、ライブラリには、必要に応じてスレッドとプロセスをどのようにスパンするかを決定する独自の内部アルゴリズムがあるということです。上記の点は、これらのライブラリのユーザーにとって重要です。1 つのライブラリでの経験が、別のライブラリにうまく適用できない可能性があるためです。

4.2 DDP使用時の速度向上

データローダーの望ましい機能は、GPU の数に応じて線形にスケーリングできることです。これは常に可能であるとは限らず、各ライブラリの内部読み込みメカニズムに依存します。1 つまたは 2 つの GPU を使用した場合の速度向上を比較することで、これらのライブラリのパフォーマンスを調べます。図 7 は、RANDOM データセットの結果を示しています。各バーは、すべてのバッチサイズ、ワーカー数、および繰り返しで達成された最大速度を表します。ある意味で、これはライブラリによって達成可能な最大速度を反映しています。ライブラリが約 40% 高速化していることがわかります。これは、平均して線形増加の半分未満です。特に驚くべき 2 つのケースがあります。一方では、Torchdata は 2 つの GPU を使用すると 1 つの GPU よりもパフォーマンスが低下します。他方では、FFCV は理論上可能な速度向上よりも高い速度向上を達成しました。ここで影響している可能性のあるアーティファクトはいくつかありますが、おそらく、実行できた繰り返し回数が限られていること (リソースが限られているため) が原因です。また、これは

Torchdata の設定ミスを示します。マルチ GPU 環境での実験の実行に関するドキュメントは、ほとんどのライブラリでは限られています。

4.3 フォワードパスとバックワードパスの有無の比較

アルゴリズム1の発表時に議論したように、速度計算にフォワードパスとバックワードパスを組み込むかどうかを決定する必要がありました。どちらにも議論があります。一方では、フォワードパスとバックワードパスを含めると、アルゴリズムの実際のトレーニング時間をよりよく反映します。同時に、一部のライブラリは、フォワードパス中に通常実行されるステップを事前に最適化する可能性があるため、

そこで止まると、実際よりも時間がかかっているように見えます。

一方、フォワードパスとバックワードパスにかかる時間が、データのロードのみにかかる時間よりもはるかに大きい場合、その時間を計算に含めると、ライブラリ間の違いが必然的に隠れてしまいます。

動作の変化が顕著であるかどうかを理解するために、RANDOM データセットを使用して、計算に 2 つのモデル操作を含めた場合と含めなかった場合の平均速度の違いを比較しました。結果は図 8 に示されています。ほとんどのライブラリでは、モデルを除外すると速度がわずかに向上していることがわかります (パフォーマンスが半分に低下する FFCV を除く)。最も重要なのは、ライブラリ間の相対的なパフォーマンスがほぼ同じであることです。

4.4 データのフィルタリング時の速度のトレードオフ

フィルタリング実験では、CIFAR10 と RANDOM 用に、それぞれ dog と truck、0 と 13 の 2 つのクラスを選択しました。CoCO には、pizza、couch、cat の 3 つのクラスを選択しました。

ほとんどのライブラリには、データセット全体の反復処理を回避する適切なフィルタリングメカニズムがないことがわかりました。たとえば、PyTorch フィルタリングの実装では、必要な画像のインデックスを使用してカスタムサンプラーを構築する必要があります。

これは小さなデータセットでは非常に高速ですが、大きなデータセットでは実現不可能になります。PyTorchを使用してCoCoをフィルタリングするのは非常に高価でした。一般的に、フィルタリングした場合とそうでない場合のパフォーマンスは非常に似ていました[6]。図と同様に

7、図 9 では、フィルタリングの結果として速度が低下していることがわかります。Torchdata と Webdataset では速度低下が顕著でしたが、CoCo Dataset では結果が逆転しました。

4.5 ネットワーク経由でストリーミングしながらのトレーニング

理想的には、データセットストレージを機械学習トレーニングプロセスから切り離し、2 つの場所に関係なく、データを保存しているデータベースを選択した ML フレームワークに接続するだけです。これには、トレーニングデータをネットワーク経由で送信することが必要になり、速度が大幅に低下します。クラウドで GPU アクセラレーションハードウェアをレンタルするには高額な費用がかかるため、利便性に見合う価値がないと思われるかもしれません。しかし、そうではないでしょうか。

この論文で検討したライブラリの中には、インターネット経由でアクセス可能なデータセットを指定できるものがあります。Webdataset、Hub、Deep Lakeは特にこの点に優れています[7]。そこで疑問になるのが、使いやすさと実行時間の間のトレードオフはどの程度大きいのか、ということです。

この疑問に対する洞察を提供するために、次の実験を設定しました。データの出所を変えながら、Hub、Deep Lake、Webdataset の 3 つのライブラリの RANDOM データセットの 2 つの完全なエポックを実行しました。検討した場所は 3 つあります。実験のハードドライブを実行しているマシンのローカルコピー、S3 バケットのコピー (マシンに最も近いリージョン)、同じローカルネットワーク内の同様のマシンで実行されている MinIO (S3 のオープンソース版で、ローカルにホストできます) に保存されているコピーです (両方のマシンは WiFi 経由で接続されています)。実験のコンピューターには、Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz、16 GB の RAM、NVIDIA GeForce RTX

2070 Rev、および 256 GB のストレージを備えた Samsung SSD 850 ハードドライブ。レイテンシに関しては、実験を実行しているワークステーションから MinIO サーバー (同じ部屋にあり、同じローカル WiFi 内にある) までのラウンドトリップ時間は 59.2 ± 58.5 ミリ秒 (最小 8.8 ミリ秒) かかり、AWS サーバーの S3 バケットまでのラウンドトリップ時間は 17.3 ± 1.3 ミリ秒 (最小 14.8 ミリ秒) でした。

図 10 は、9 つの実験の合計実行時間を示しており、白いパーセンテージはローカルの場合と比較した速度低下 (実行時間の増加) を示しています。Hub と Webdataset では AWS に移行すると大幅な速度向上が見られますが、Deep Lake は 13% の増加にとどまり、ほぼ同じ速度を維持できたことがわかります。この結果から、もう 1 つの役立つ洞察が得られます。図 10 に示すように、MinIO 設定では AWS 設定のほぼ 2 倍の速度低下が見られます。この出力は、主に上記の平均ラウンドトリップ時間の違いによって説明できますが、ローカルネットワーク (社内ネットワークなど[8]) は、複雑な構成と制限のため、データセットをホストする最も効率的な方法ではない可能性があることを強調しています。さらに、この結果は、ネットワーク経由でデータセットを提供するストレージがリモートトレーニングを可能にする上で重要な役割を果たしていることを示しており、データセットを提供するためのベストプラクティスに関する疑問を引き起こす可能性があります。つまり、S3 のデータは、単一の MinIO インスタンスにアクセスしている間、負荷分散を使用して異なるサーバーから並列で提供されます。

追加のすべての実験のグラフは付録 A にあります。