第168回HPC研究会で口頭発表してきた
2019年3月14日
すでに先週のことなのだが、3月5日から3月7日の間に開催された第168回HPC研究会という研究会にて口頭発表をしてきた。
何気に初めての学外での研究発表ということになった。査読なしの口頭発表、しかも研究会なので、プロの研究者から見たら大したことのない場なのかも知れない。実際、何回も発表してる「常連」のような雰囲気の人も多く、聞いてる方もずいぶんリラックスしているように見えた。しかし、入学以来、学外での研究発表が初めての自分にとっては十分緊張するに値する機会であった。
今回発表したネタは深層ニューラルネットワークにおける訓練高速化のための自動最適化というもので、内容的にはChainerで実装したModelで実際にforward/backwardを実行して、処理時間とか訓練処理中のGPUの利用状況をプロファイルして、1 epochの訓練をできるだけ高速化するミニバッチサイズを見つける最適化スクリプトをChainerのExtensionとして実装したよ、という話。
今回の発表のために実装したコードは取り急ぎGithubに上げてある。まだドキュメントを一切書いてないのだがこちらについてもちゃんとドキュメントを書いて別のブログ（seri::diary）の方で紹介したい。
これを使うと、例えばChainer付属のCifar100+VGG16のサンプルスクリプトだと、「V100が刺さってるマシンだとミニバッチサイズ196ぐらいが1 epoch当たりのforward/backwardの処理時間がいい感じに早くなるミニバッチサイズだよ」ってことを自動で判定してくれるやつである。モデルの精度は全く見ておらず、単にGPUを使い切る当たりを狙ってミニバッチサイズを調整する、という感じである。得られた最適値をそのまま使うというより、GPUを使い切るにはこれぐらいのミニバッチサイズになるということが分かるので、そこから精度に影響しない範囲でサイズを調整するとか、精度改善のために学習率を調整するとかバッチ正則化層を入れるなどの、マニュアルチューニングを入れた上で使用することを想定している。
ちなみに今回はCifar100 + VGG16で試した限りではミニバッチサイズ196でも32や54と比べてさほど汎化性能に影響はなかった。たまたまであるが。
この研究のモチベーションとしては、なぜかミニバッチサイズってどの論文でもモデルに関係なく32とか64を使っていて、それが本当に最適なのかが気になったのと、そういうミニバッチサイズで1 GPUをちゃんと使い切れるかどうかというのが気になったというの２つの理由がある。
この研究の結論としては、V100なんかが刺さってるマシンだとCifar100 + VGG16みたいなトイデータだとバッチサイズは32や64からは明らかに大きくできる余地があった。一方でImageNet-1k（224x224にcropしたもの）だとデータのロードやpngからndarrayへの変換処理などの処理時間と思われる、GPUを使わない時間帯が多く存在し、GPUが「遊んでいる」時間帯が1 iterationごとに1秒ほど存在しており、ミニバッチサイズを増加させてもなかなか性能改善につながらないということがわかった。ChainerのImageNet-1k + ResNetのサンプルだと、この問題を回避するために非同期でデータをロードするMultiProcessIteratorを使用している。
じゃあMultiProcessIterator使えばいいじゃん、でこの話は正直言って終わりなのだが、逆に言えばMultiProcessIteratorのような機構がない場合は、画像サイズが32x32から高々224x224になるだけで随分とGPUの利用が阻害されるという問題が簡単に起きるということを示している。これは一般的に知られているんだかいないんだか分からないが、安易に訓練データのサイズを上げることの影響は予想以上に大きいということを示唆しているという点でそれなりに意味のある発見。。なのではないだろうかと勝手に思っているのだが、どうなのだろう。周りに深層学習ガチ勢がいないのでちょっと分からない。ガチ勢が集まる場所で聞いてみたい。
とりあえず今回の研究発表はこんな感じであり、会場からはいくつか質問もいただいて、最低限伝えたいところは伝わったようなのでホッとしている。このOptimizerのコードはそのうち公開する予定である。高々数百行で作れるExtensionなので、自分の書いた原稿を読めば誰でも作れそうなモンであるが、一応ちゃんと動くものができたのでそれはそれで意味があるのではないだろうか。
