2016-09-02 4 views
1

ディープ学習とそのフレームワークで比較的新しいです。現在、私はCaffeフレームワークを試していて、Vgg16_places_365を微調整しようとしています。Finetuning Caffeディープラーニングチェックに失敗しました:error == cudaメモリ不足になりました

私はAmazone EC2インスタンスg2.8xlargeを4つのGPU(それぞれ4GBのRAMを搭載)で使用しています。私が(単一GPUを使用して)私のモデルを訓練しようとすると、しかし、私はこのエラーを得た:私はいくつかの研究をした後

Check failed: error == cudaSuccess (2 vs. 0) out of memory

、私は、メモリの問題のうち、これを解決する方法の一つは、であることがわかりました私のtrain.prototxtのバッチサイズを減らす

Caffe | Check failed: error == cudaSuccess (2 vs. 0) out of memory

最初に、バッチサイズを50に設定し、それを10まで繰り返しました(batch_size = 10のときに機能したため)。 モデルは訓練されており、かなり長い時間がかかりそうです。しかし、このドメインの新人として、私はsolver.prototxtで指定したラーニング・レート、ステップ・サイズ、最大反復さえも、このバッチ・サイズと別のパラメータとの関係について興味があります。

バッチのサイズがモデルの品質にどの程度影響しますか(精度など)。どのように他のパラメータを使用して品質を活用できるか。また、バッチサイズを小さくするか、マシンをスケールアップする代わりに、この問題を解決する別の方法がありますか?

答えて

1

バッチサイズ、学習率、最大反復回数などのパラメータ間の関係に関する最初の質問に答えるには、数学的背景について読むことをお勧めします。開始するには、このstats.stackexchange質問:How large should the batch size be for stochastic gradient descent?が適しています。答えはバッチサイズと学習率(あなたの質問から私は学習率=ステップサイズと仮定します)との関係を簡単に議論し、さらに読むための参考文献を提供します。

最後の質問に答えるには、データセットで微調整しているモデル(つまりVGG16)が固定されている(固定サイズの入力データと固定サイズのモデル)場合は、大きなバッチサイズのメモリ不足の問題を回避できます。ただし、入力サイズやモデルサイズを縮小したい場合は、より大きなバッチサイズを使用することができます。どのように(そして何を)正確に微調整しているかによって、学習したレイヤーを破棄したり、完全に接続されたレイヤーの数/サイズを減らしたりすることで、モデルサイズを縮小することができます。

残りの質問、つまりバッチサイズが品質/精度にどの程度影響するか、他のパラメータが品質/精度にどのような影響を与えるかは、解決しようとしている具体的な問題を知らなければ答えにくいです。例えば、達成された精度のバッチサイズは、データセットのノイズ、データセットの次元、データセットのサイズ、学習率(= stepsize)やモーメンタムパラメータなどのさまざまな要因に依存する場合があります。このような質問の場合は、textbook by Goodfellow et al.をおすすめします。第11章では、これらの超パラメータを選択する際の一般的なガイドライン(バッチサイズ、学習率など)を提供する場合があります。

+0

素晴らしい回答と参考に感謝します。したがって、私が正しく理解できれば、一般的に、バッチサイズは、ウェイトを更新する前に見ているサンプルの数を決定します。言い換えれば、バッチサイズが小さいほど、トレーニング信号のノイズが大きくなります。もしそうならば、バッチサイズを減らすと、学習率を上げるべきですか? – bohr

+0

また、前述の2つの選択肢について言えば、入力サイズを小さくするかモデルサイズを小さくすることです** - 私はこれについて少し心配しています。私が知る限り、いくつかのモデルの入力サイズは固定されており、ユニークなので、それを変更するとエラーになります。一方、私はvggやgooglenetのような既存のモデルを使用しているので、(計算の速度とモデルの品質の点で)どれくらい重要なのでしょうか、レイヤのいくつかを破棄したり、完全に接続された層? – bohr

+0

はい、バッチサイズの理解は正しいです。しかし、バッチサイズを小さくすることは必ずしも学習率を上げることを意味するものではなく、その逆もあります。 2番目の質問:入力サイズを減らすことは、データセットが固定(たとえば画像サイズ)されていても、完全に接続されたレイヤーを再調整してサイズを変更した場合、VGGモデルでエラーが発生しないようにする完全に接続されたレイヤーのみが元の入力サイズに制限されます)。例えば、畳み込みレイヤーを維持しながら、完全に接続されたレイヤーのサイズを減らすことによって、モデルサイズを縮小することが可能です。 –

1

問題を解決する別の方法は、マシン上のすべてのGPUを使用することです。 GPUに4x4=16GBのRAMがある場合は、それで十分でしょう。あなたのpythonを使用している場合は

build/tools/caffe train --solver=solver.prototxt --gpu=0,1,2,3 

:あなたはコマンドモードでカフェを実行している場合(デフォルトの0,1,2,3としてインデックス4つのGPUを持っていると仮定すると)以下のように、ちょうど--gpu引数を追加複数のGPUで動作するインタフェースは、まだサポートされていません。

バッチサイズに関する質問に答えようとする一般的なヒントを指摘しておきます: - バッチサイズが小さいほど、あなたの学習はより確率的になります。>トレーニングデータのオーバーフィットの確率が低くなります。収束しない確率が高い。 - caffeの各繰り返しは、1バッチのデータをフェッチし、順方向に実行し、バックプロパゲーションで終了します。 - トレーニングデータが50,000で、バッチサイズが10であるとします。 1000回の反復で、データの10分の1がネットワークに供給されました。同じシナリオのシナリオでは、バッチサイズが50で1000回の反復であれば、すべてのトレーニングデータがネットワークに表示されます。これは1エポックと呼ばれます。バッチサイズと最大反復は、ネットワークが一定のエポック数の訓練を受けるように設計する必要があります。 - caffeのstepsizeは、ソルバーが学習率にガンマ値を乗算する前に実行する反復の回数です(トレーニングアプローチを「ステップ」として設定した場合)。

+0

あなたの答えに感謝します。複数のgpusを使用することは良い選択ですが、まだいくつかの考慮のために1つのGPUしか使用できないように、すべてのパラメータを最適化する方法を見つけようとします。また、あなたの説明に感謝します。簡単で有益な情報です。しかし、私はあなたの経験に基づいて、バッチサイズや学習率などのハイパーパラメータを指定する際の経験則はありますか? – bohr

+0

学習率に関して、文献では多くの経験則があります:たとえば、VGGの論文(https://arxiv.org/pdf/1409.1556.pdf)(3.1節)、またはCaffeのドキュメント(http: //caffe.berkeleyvision.org/tutorial/solver.html(「学習率と運動量を設定するためのルール」節)、Alex Krizhevskyの論文でもよく知られているルールである:https://papers.nips.cc /paper/4824-imagenet-classification-with-deep-convolutional-neural-networks.pdf(セクション5)。論文は通常、使用されたバッチサイズと学習率の削減スキームも報告します。 –

+0

素晴らしい!すべての情報源を読むためにいつかかかります。しかし、私はすべてのgpus( 'caffe train --solver = solver.prototxt --gpu = 0,1,2,3')を使ってトレーニングを実行しようとしていますが、googlenetモデルでは(train.prototxtではバッチサイズ:50)。しかし、私は同じ問題がメモリ不足になっています。 @DavidStutz – bohr

関連する問題