Jan 01, 1970
データローダーの概要: 数値結果
長すぎる; 読むには
この論文では、研究者はデータローダーを 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 にあります。
この論文はCC 4.0ライセンスの下でarxivで公開されています。
[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf
[6] 速度が向上します。PyTorchのサンプラーの構築は事前に行われるため、全体の実行時間に大きな影響を与えます。
[7] Squirrelにはこの機能がありますが、MinIOアドレスを指定できなかったため、比較から除外しました。Torchdataでも同様の問題が発生しました。
[8] この場合、大学のネットワーク
L O A D I N G
. . . comments & more!
. . . comments & more!
