カテゴリー

エンジニアリング

ニューラルネットの新しい正規化手法 Group Normalization の高速な実装と学習実験

今年 1 月に ALBERT に入社した清水です。深層学習プログラマとして自社プロダクト開発をしております。このブログを書くのは始めてなのですが、今日はちょっとプログラミング寄りの記事を。残暑厳しい折ですが、実装の詳細にまで立ち入りつつアツく Yuxin Wu および Kaiming He の考案した手法 Group NormalizationECCV 2018 採択済)について語ります。Kaiming He 氏は ResNet を筆頭に優れた convolutional neural networks (CNN) の設計で知られていることもあり、みなさんも注目している手法ではないでしょうか?

Chainer v5.0.0b4 を用いて、Chainer に入っている実装と弊社の独自実装での速度比較、また Batch Normalization との速度・精度比較を行いました。その上で、速度差が生じる原因の調査や CUDA を使った高速化の工夫について詳しく記します。ソースコードは MIT ライセンスで GitHub に公開していますので、ぜひご覧ください。

Group Normalization って?

Group Normalization の発想はシンプルです。早速ですが、Group Normalization を端的に表す図(論文 Figure 2 より引用)を見てみましょう。

Batch Normalization, Layer Normalization, Instance Normalization, Group Normalization の図示

(N, C, HW) の 3 次元からなる多次元配列が出てきましたが、これは CNN の中間層の出力だと考えると想像しやすいかと思います。バッチサイズ N, チャンネル数 C, 画像の縦幅 H, 画像の横幅 W です。

図に示された Batch Normalization, Layer Normalization, Instance Normalization およびこの記事の本題 Group Normalization の 4 つの手法は、いずれも青色で示された領域ごとに算出される平均・分散によって入力を正規化 (normalize) します。Batch Normalization が各チャンネルごとに平均・分散を求めることは有名ですね。精度・収束性を劇的に向上させる Batch Normalization は今や CNN のデファクトスタンダードですが、しかし

  • 画像の解像度が大きくてメモリが不足するなどの理由でバッチサイズが小さくなる場合に、平均・分散の推定が不安定になり学習ができなくなる
  • 複数 GPU にまたがって平均・分散を推定することで実質的なバッチサイズを増やすことは可能だが、高価なハードウェアが必要になる上に実装や最適化が複雑
  • ビデオの隣接フレームといった相関がある画像をミニバッチとして入力する場合も平均・分散の推定が不安定になる
  • 学習時に平均・分散の移動平均を覚えておいて推論時に用いるといった処理が煩雑
  • Finetune 時に移動平均をどう扱うべきかよくわからない

といった難点も併せ持っており、いつでも使えるわけではありません。このためミニバッチに依存しない正規化手法が待ち望まれていました。

そのような手法として、全チャンネルにまたがって平均・分散を取る Layer Normalization と、各チャンネル独立に画像の縦横方向についてのみ平均・分散を取る Instance Normalization が考案されました。とはいえ十分にバッチサイズが確保されている条件下での精度は Batch Normalization に比べてかなり劣っており、主流とはなっていません。

そこで登場したのが Group Normalization です。チャンネルを G 個にグルーピングして Layer Normalization と Instance Normalization の中間的な処理を行うことで、画像分類などのタスクで Batch Normalization に匹敵する精度を実現しました。グループ数 G を 32 にした場合がベストだったと論文に述べられていますが、それほど G の値に対して敏感ではないようです。Group Normalization の論文では、Instance Normalization には複数のチャンネルの組み合わせによって表現される特徴を歪めてしまう問題があると考察されています。その対極になるのが Layer Normalization ですが、こちらは大域的すぎて、特に重要ではないチャンネルが画像全体にわたって高い値を示した場合に他の全てのチャンネルが抑制されてしまいます。中間的な Group Normalization は良いとこ取りをできるというわけです。

なんだか素晴らしそうですね。Chainer では v5.0.0b3 から Group Normalization がサポートされているのでお手軽に使えます。しかし、本当に Batch Normalization をドロップインで置き換えて精度低下は起きないのでしょうか? Batch Normalization と同等の速度で動作するのでしょうか? この疑問を検証します。

結論から言えば、Batch Normalization を単に Group Normalization に置き換えるだけでは精度がかなり落ちてしまいました。なので Group Normalization を使う場合は精度の確認やパラメータチューニングをきちんとやるべきでしょう。また、Chainer v5.0.0b3 に追加された Group Normalization の実装はあまり効率的ではなく、CNN 全体の実行速度を大きく下げてしまうことがわかりました。この原因や、より効率のいい実装方法についても詳述します。

続きを読む ニューラルネットの新しい正規化手法 Group Normalization の高速な実装と学習実験

Azure Batch AI Trainingを利用したツイートデータ分類モデルの分散学習

はじめまして、システムソリューション部の松本です。

今回は、ディープラーニングの分散学習を可能にするサービス「Azure Batch AI Training」を用いて、Twitterの投稿に対する分類モデルを分散学習させてみようと思います。

アウトライン

  1.  Azure Batch AI Trainingとは
  2.  Azure Batch AI Training APIを使用してディープラーニング分散処理を行う流れ(Python&Tensorflowを使用した例)
  3. Tensorflowによるリツイート数でのツイートCNN2値分類
  4. 結果
  5. まとめ
  6. Appendix:独自Dockerコンテナssh設定

続きを読む Azure Batch AI Trainingを利用したツイートデータ分類モデルの分散学習

AzureのデータサイエンスVMを用いたニューラルネットワーク機械翻訳

初めまして。
システムソリューション部の長田と申します。

昨今では「AI」や「Deep Learning」などのキーワードとともに、データ分析が注目されています。 データ分析を行うためのツールは数多く存在し、それらをインストールするには意外と手間がかかります。 特にDeep LearningのアルゴリズムをGPUで計算する際に使われるcuda周りのインストールはノウハウがないと面倒です。

本記事では、データ分析で用いる主要なツールがプレインストールされているAzureのデータサイエンス仮想マシン(DSVM)を使ってDeep Learningを行ってみた感想について書いていきます。

続きを読む AzureのデータサイエンスVMを用いたニューラルネットワーク機械翻訳

AWS Data Pipeline の 稀によくあるQ&A

システムソリューション部の佐藤奏です。

業務でAWS Data Pipelineを結構ヘビーに使ったので、調べにくいところやハマりどころをQ&A形式でご紹介します。

サービスの概要について少しだけコメントします。その後はひたすら細かい話になります。なお、以下はもっぱらリソースとしてEC2を使う場合の記述です(EC2の他に、EMRクラスタを起動することもできますが、筆者は使ったことがありません)。

続きを読む AWS Data Pipeline の 稀によくあるQ&A

Apache Spark を使ったシステム構築のための Tips

システムソリューション部の佐藤奏です。

並列分散処理フレームワークApache Sparkがホットな昨今。サンプルコードや活用事例もいろいろと公開されていますが、では実際にSparkを利用してシステムを構築しようとするとき、どのような考慮が必要なのでしょうか。

今回は「SparkとAWS EMRを使ったシステム構築」を念頭に、開発の初期段階――技術選定や開発スケジュール検討、外部設計、プロトタイプ作成・評価――において有用な情報や開発の進め方のポイントをいろいろとご紹介してみようと思います。結構、地味な話が多いですがお付き合いください。

本記事執筆時点でのSparkの最新バージョン1.6.1をベースとした記述です。

続きを読む Apache Spark を使ったシステム構築のための Tips

GAE Managed VM & Custom Runtimeについて

このエントリーはGoogle Cloud Platform Advent Calendar 2015の14日目です。

10月に入社しましてブログには初めて投稿します石井です。休日はJavaScriptやGoで趣味の開発を行っていたり、家に知人を集めてボードゲーム会をしてたりします。

さて、ALBERTはAWSメインの開発を行っているのですが、GCP (Google Cloud Platform) も最近盛り上がって来ている!という事で、新しい案件をGCPで構築してみることにしました。その際にGAE (Google AppEngine) 周りの調査を色々と行ったので、今回は特にManaged VMとCustom Runtimeについて紹介できればと思います。

GAE Managed VM, Custom Runtimeは簡単に言うと、GAEが裏で管理していたコンテナを触れることができるようになったり、自分で定義したDockerのコンテナをGAE上で動かすことがでるようになるものです。

続きを読む GAE Managed VM & Custom Runtimeについて

Redis Cluster の構築と利用(Redis 3.0.0)

みなさまこんにちは。池内です。

Redis 3.0.0 から正式な機能として盛り込まれたRedis Clusterの構築と基本的な動作について紹介します。

※ 期せずして本日 LINEさんの事例 LINEの100億超/日メッセージを支えるRedis・HBaseのスケールアウト・アップ戦略(A-5) #linedevday – Togetterまとめ が話題になっていますが、合計48TBものメモリサイズで運用しているようです。凄いですね。

Redis Cluster とは

  • 疑似的なマルチマスタ構成
  • 複数ノードでデータをシャーディングできる
  • スレーブ構成を採用すれば耐障害性の向上も可能

概ね上記のような内容です。マルチマスタを「疑似的」としているのは、実際にデータが各ノードに伝播しているわけではないからです。Redis Clusterは、あるレコードをどのノードに保存するかを把握しておき、ノード間でリダイレクトすることによって、どのノードから接続しても指定するデータにたどり着けるというアーキテクチャを採用しています。この記事では便宜上マルチマスタと表記します。

続きを読む Redis Cluster の構築と利用(Redis 3.0.0)