ChainerとTensorRTの間をつなぐchainer-trtの公開

Daichi Suzuo
エンジニア

2018-12-13 17:00:28

この度、Chainerで開発したモデルをNVIDIAの推論エンジンTensorRTに変換しNVIDIA GPU上で高速に推論するための実験的ツールchainer-trtをOSSで公開しました。この記事ではその概要、開発の背景と位置づけを簡単に紹介したいと思います。

https://github.com/pfnet-research/chainer-trt.git

はじめまして。PFNエンジニアの鈴尾(すずお)です。いつも同じアバターを使っているので、社内や社外でお魚さんと呼んでいただけることもあります。

深層学習技術の急速な発展に伴って、いよいよエッジへの推論器のデプロイという形での実用化が進んできました。学習時の速度がモデル開発の効率に直結するように、推論時の速度は製品に載せるハードウェアのコストに直結するため、高速に推論できることは極めて重要です。ここで推論とは、ニューラルネット(NN)の順伝搬処理のみを実行し解釈可能な出力(例えば、物体検出の結果など)を得るプロセスを指します。Chainerは一般に非常に高速な深層学習フレームワークとして知られ、また学習に用いたコードをほとんどそのまま推論に用いることができます。しかしながら、特定の種類のデバイス上で、入力の大きさやアーキテクチャおよびパラメータが固定されたNNの順伝搬処理のみに注目した場合、最適化の余地はまだまだあります。

NVIDIAのTensorRTはこのような需要に対応するため開発された推論エンジンの一つです。
Deploying Deep Neural Networks with NVIDIA TensorRT
How to Speed Up Deep Learning Inference Using TensorRT | NVIDIA Developer Blog

TensorRTは完全に静的なNNと固定のデバイス(GPU)を前提とし、あらかじめ深さ方向ないしは幅方向に隣接する層を可能な限り統合するなどの計算グラフレベルの最適化、指定されたGPU上で最も実性能の良いCUDAカーネルを計測に基づいて自動選択するなどの実装レベルの最適化、計算グラフ中の破棄可能なメモリ領域を同定し再使用するなどのメモリレベルの最適化、および16bit浮動小数点数や8bit整数を用いた低精度計算へのpost-training変換などを施します。これをビルド段階と呼びます。

推論時は、このビルド段階で構築した実行計画に基づいて処理を行うだけであるため、NVIDIA GPU上で極めて高速に順伝搬処理を行うことができます。

これまでChainerで開発・学習したモデルをTensorRT推論器に変換する仕組みはONNXを介する方法しかありませんでした。この場合少々複雑なTensorRTのC++ APIを理解し、CPUおよびGPU上の生ポインタを責任持って管理するなどの作業が生じるため、これらを可能な限り吸収しかつChainerからTensorRT化をスムーズに行うことができないかを検証するべく、実験的ツールchainer-trtを開発しました。

一言でまとめるとchainer-trtは、TensorRTのC++ APIを用いてTensorRTにNNの構造とパラメータを教え最適化を走らせることによってChainerのモデルをTensorRT推論器に変換し、またそれを実行する、といった作業を行うための薄いラッパーです。

chainer-trtの仕組み

chainer-trtを使う上では、大きく3段階の作業が必要です。

1段階目は、PythonによってChainerの流儀で書かれた順伝搬コードをもとに、計算グラフをchainer-trt独自の中間形式に書き出すプロセスです。chainer-trtでは、これをModelRetrieverと呼ぶPythonパートが担当します。

計算グラフの全ての情報を得るのは、ちょうどChainerの機能の一つであるComputationalGraphと同じ仕組みで行われています。すなわち、順伝搬後に得られる出力Variable(chainer.VariableNode)から計算グラフを終端(入力側)まで順にたどっていく方法です。多くの場合、順伝搬のコードそのものに対するchainer-trt対応のための特別な変更は必要ありません。

中間形式の実体は1つのディレクトリであり、これは計算グラフの構造を表すmodel.jsonと各層の重みを表す*.weightsファイルを含みます。

下記のスニペットは、ImageNet学習済みのResNet50モデルを中間形式に書き出す処理です。見ての通り、通常の推論コードに少しchainer-trtの要素を外付けしているだけです。

import numpy as np
import chainer
import chainer_trt

# NNを用意
net = chainer.links.ResNet50Layers()

# ダミー入力を作成
x = chainer.Variable(np.random.random((1, 3, 224, 224)).astype(np.float32))

# ModelRetrieverを作成し、入力に名前をつける(任意)
retriever = chainer_trt.ModelRetriever("resnet50")
retriever.register_inputs(x, name="input")

# ダミー入力を用いて順伝搬を実行
with chainer.using_config('train', False):
    with chainer_trt.RetainHook():    # おまじない
        y = net(x)['prob']

# 計算グラフを取得し、全ての情報を保存する
retriever(y, name="prob")
retriever.save()

2段階目は、先程書き出した中間形式の情報を読み込みTensorRTのC++ APIを用いて推論器のビルドを走らせるプロセスで、chainer-trtのC++パートがこれを行います。推論を実行させたい対象デバイスの上でchainer-trtのビルド実行関数を呼ぶと、まもなくそのデバイス専用の推論器(実体は1つのファイル)ができあがります。

#include <chainer_trt/chainer_trt.hpp>
...

// ModelRetrieverの出力ディレクトリを指定し、推論エンジンを構築・保存する
auto m = chainer_trt::model::build_fp32("resnet50");
m->serialize("resnet50/fp32.trt");

上記のスニペットはユーザの書いたC++からこのビルド処理を行う例ですが、TensorRTの機能であるINT8量子化を行わない場合については標準でコンパイルされる小さなツールを下記のように呼ぶだけでも全く等価な推論器が構築できます。
(INT8量子化を伴う場合は、キャリブレーションと呼ばれるプロセスをNNごとに行う必要があるため、専用のビルドツールをユーザが実装する必要があります。)

% tensorrt_builder -i resnet50 -o resnet50/fp32.trt

3段階目は、その推論器を用いて推論を実行するプロセスで、chainer-trtのC++パートがこれを行います。ユーザはまず入力データと出力先バッファをCPU上ないしGPU上に用意し、それぞれがNNのどの入力・出力に対応するか(1つのNNは複数の入力や出力を持つことができ、これを名前で識別できます)などの情報とともにchainer-trtの推論実行関数を呼び出します。すると推論処理が走り、出力結果が返ってきます。

厳密にはビルドされた推論器のファイルはchainer-trtに依存するものではなく、chainer-trtを経由せず直接TensorRTのC++ APIを呼んで利用することができます。しかしながらchainer-trtは典型的なユースケースに関してメモリ管理や入出力の指定方法などを簡易化しCUDAの煩雑なコーディングをある程度隠蔽しているため、chainer-trtでビルドした推論器はchainer-trtで実行するのが便利でしょう。

#include <chainer_trt/chainer_trt.hpp>
...

// 構築した実行エンジンを読み込み、ランタイムを作成
auto m = chainer_trt::model::deserialize("renet50/fp32.trt");
chainer_trt::infer rt(m);

// CPU上の入力・出力バッファを用意し、入力バッファに入力データを読み込んでおく
std::vector<float> x(...);
std::vector<float> y(...);
load_input(x, ...);

rt.infer_from_cpu(1, {{"input"s, x.data}}, {{"prob"s, y.data}});

// 出力がyに入っている

同梱されているImageNetおよびYOLOv2のサンプルを用いた場合の1バッチ推論の平均実効時間、すなわち画像を入力して結果が得られるまでの推論レイテンシを測定してみました。

モデル Chainer FP32 (ms/img) TensorRT FP32 (ms/img) TensorRT INT8 (ms/img)
VGG16 4.713 2.259 1.384
GoogLeNet 13.809 0.974 0.624
ResNet50 19.062 2.145 0.851
YOLO v2 20.749 (12月14日訂正) 6.151 4.579

環境: GeForce GTX 1080Ti, i7 7700K, CUDA 10, TensorRT 5.0, Ubuntu 18.04, Chainer 5.1.0, ChainerCV 0.11.0

GoogLeNetなどの細かな層が多数積み重なったようなNNでは演算量に対して計算グラフ構築のオーバヘッドが相対的に多くなるため、特にTensorRTの活用による高速化の恩恵を受けやすい傾向があります。ただしChainerベースの推論であっても、バッチ数を大きくし複数のCUDAストリームで推論を並列実行するなどの工夫によってスループットはかなりTensorRTベースの推論に近づけることができます。推論のレイテンシが特に重要な場合は、TensorRTで推論器を構成することがきわめて有効です。

コードに同梱しているREADMEドキュメントでは、導入方法(現在のところ、手動でのコンパイル作業が必要です)、より詳細な動作原理、並列化・バッチ化による高スループット化の方法、INT8量子化の使い方、numpy/cupy arrayから直接推論を走らせることのできるPythonインタフェースの使い方など詳細を解説しています。

社内での活用

社内ではいくつかのプロジェクトでchainer-trtを活用して推論を高速化しています。

最も典型的な活用例としては、実製品となる組み込み機器上での画像認識器の開発が挙げられます。計算能力上の制約が多い現場では、TensorRTの活用による高速化が必要不可欠でした。

面白いところでは、探索問題における評価関数を近似するNNを学習しこれをTensorRTで高速化することで全体の処理時間を大幅に短縮するという活用例がありました。別の例としては、強化学習のような問題設定において正確だが計算時間かかる物理シミュレータを同様にNNで近似後TensorRTで高速化することで学習全体を高速化するという例もあります。

Menohとの関係

次に、Menohとの関係についても述べておきたいと思います。

PFNでは、ONNXベースの推論ライブラリMenoh(R)を今年6月にリリースし、現在も活発に開発しています。MenohはONNXとして書き出したNNをもとに推論を行うライブラリで、主に以下のような極めて優れた特長を持っています。

  • Python/C++に限らない豊富な言語バインディング
  • ONNXを用いることで、Chainerのみに必ずしも依存しない汎用性
  • プラガブルなバックエンド

特にバックエンドとして、もともとMenohはIntel製CPU上で深層学習のための演算を高速に実行するためのライブラリMKL-DNNを用いていましたが、現在TensorRTバックエンドを選択できるようにするべく開発を進めています。

これに対してchainer-trtは、

  • ChainerのモデルをTensorRTに迅速に変換することのみを目的とする
  • ONNXに依存しない

といった思想で設計されています。

2点目は特に重要で、ONNXに依存する選択をしている限りは現在のONNXで表現できないオペレータを含むようなNNは原理的に扱えないという困難があります(※1)。TensorRTの場合はプラグインという仕組みにより、TensorRTさえも標準サポートしていないような任意のオペレータをユーザが自らCUDA実装しNN内で使うことができますが、ONNXを中間形式とした場合この自由度がONNXの表現能力によって制約されてしまいます。chainer-trtはONNX非依存の独自中間形式をとるという選択をすることで、実装さえすれば提案されたばかりのオペレータなどを迅速に利用可能にできるような作りにしました(※2)。
※1: ONNXに任意の拡張を施せるようにする構想はいくつか検討されているそうですが、当面の間は使えるオペレータの種類に制約がある状態は続くと考えられます。
※2: もちろんこのように実装されたプラグインオペレータに関してはTensorRTによる自動的かつ高度な最適化の対象とはなりませんが、そのようなオペレータの存在のみによってNNのTensorRT化自体を諦める必要がなくなります。

これらのことから、ごく一般的なオペレータのみで構成されるほとんどのNNは、Menohによって十分にその超高速推論の恩恵に与れることと思います。ONNXで表現できないオペレータを使いたい、またそのオペレータの独自実装を自ら行うことができる方にはchainer-trtが役に立つでしょう。

歴史的には、実はchainer-trtはONNXが昨秋発表される前より社内で開発しています。したがってONNX非依存という選択をしたというよりは、そうするより他になかった当初の設計のまま今に至っていると言う方が正確な表現です。技術的には、Menohとchainer-trtは全く異なるコードベースから始まっており、情報交換をしつつ独立に開発が進んでいます。

Menohは今後も汎用的な推論ライブラリとして最新の高度な需要に追従するため大規模に開発が継続されていく見込みです。chainer-trtはChainerとTensorRTの間をとりもつ実験的プロジェクトとして、TensorRT本体の各種新機能への追従やカスタムオペレータの拡張などを中心に、またインタフェースやドキュメント改善なども含めた開発をしていく見込みです。

ぜひ実機での推論に課題を抱えている皆様のお役に立てればと考えております。また、皆様からのフィードバックをお待ちしています。

ハイパーパラメータ自動最適化ツール「Optuna」公開

秋葉 拓哉
リサーチャー

2018-12-03 13:45:42

ハイパーパラメータ自動最適化フレームワーク「Optuna」のベータ版を OSS として公開しました。この記事では、Optuna の開発に至った動機や特徴を紹介します。

 

 

ハイパーパラメータとは?

ハイパーパラメータとは、機械学習アルゴリズムの挙動を制御するパラメータのことです。特に深層学習では勾配法によって最適化できない・しないパラメータに相当します。例えば、学習率やバッチサイズ、学習イテレーション数といったようなものがハイパーパラメータとなります。また、ニューラルネットワークの層数やチャンネル数といったようなものもハイパーパラメータです。更に、そのような数値だけでなく、学習に Momentum SGD を用いるかそれとも Adam を用いるか、といったような選択もハイパーパラメータと言えます。

ハイパーパラメータの調整は機械学習アルゴリズムが力を発揮するためにほぼ不可欠と言えます。特に、深層学習はハイパーパラメータの数が多い傾向がある上に、その調整が性能を大きく左右すると言われています。深層学習を用いる多くの研究者・エンジニアは、ハイパーパラメータの調整を手動で行っており、ハイパーパラメータの調整にかなりの時間が費やされてしまっています。

Optuna とは?

Optuna はハイパーパラメータの最適化を自動化するためのソフトウェアフレームワークです。ハイパーパラメータの値に関する試行錯誤を自動的に行いながら、優れた性能を発揮するハイパーパラメータの値を自動的に発見します。現在は Python で利用できます。

Optuna は次の試行で試すべきハイパーパラメータの値を決めるために、完了している試行の履歴を用いています。そこまでで完了している試行の履歴に基づき、有望そうな領域を推定し、その領域の値を実際に試すということを繰り返します。そして、新たに得られた結果に基づき、更に有望そうな領域を推定します。具体的には、Tree-structured Parzen Estimator というベイズ最適化アルゴリズムの一種を用いています。

Chainer との関係は?

Optuna は Chainer を含む様々な機械学習ソフトウェアと一緒に使うことができます。

Chainer は深層学習フレームワークであり、Optuna はハイパーパラメータの自動最適化フレームワークです。例えば、Chainer を用いたニューラルネットの学習に関するハイパーパラメータを最適化する場合、Chainer を用いるユーザーコードの一部に Optuna からハイパーパラメータを受け取るコードを書くことになります。それを Optuna に渡すことによって、Optuna が自動的に何度もそのユーザーコードを呼び出し、異なるハイパーパラメータによりニューラルネットの学習が何度も行われ、優れたハイパーパラメータが自動的に発見されます。

社内では Chainer と共に用いられているユースケースがほとんどですが、Optuna と Chainer は密結合しているわけではなく、Chainer の以外の機械学習ソフトウェアとも一緒に使うことができます。サンプルとして、Chainer の他に scikit-learn, XGBoost, LightGBM を用いたものを用意しています。また、実際には機械学習に限らず、高速化など、ハイパーパラメータを受け取って評価値を返すようなインターフェースを用意できる幅広いユースケースで利用可能です。

なぜ Optuna を開発したのか?

ハイパーパラメータの自動最適化フレームワークとして、Hyperopt, Spearmint, SMAC といった有名なソフトウェアが既に存在しています。そんな中でなぜ Optuna を開発したのでしょうか?

複数の理由やきっかけがありますが、一言で言うと、我々の要求を満たすフレームワークが存在せず、そして既存のものよりも優れたものを作るアイディアがあったからです。また、実際には、機能面だけではなく品質面でも、既存のフレームワークにはレガシーなものが多く、不安定であったり環境によって動作しなかったり修正が必要だったりという状況でした。

Optuna の特徴

Define-by-Run スタイルの API

Optuna は Define-by-Run スタイルの API を提供しており、既存のフレームワークと比較し、対象のユーザーコードが複雑であっても高いモジュール性を保ったまま最適化を行うことを可能とし、またこれまでのフレームワークでは表現出来なかったような複雑な空間の中でハイパーパラメータを最適化することもできます。

深層学習フレームワークには Define-and-Run と Define-by-Run という 2 つのパラダイムが存在します。黎明期は Caffe など Define-and-Run のフレームワークが中心でしたが、PFN の開発した Chainer は Define-by-Run のパラダイムを提唱し先駆けとなり、その後 PyTorch が公開され、TensorFlow も 2.0 では eager mode がデフォルトになるなど、今では Define-by-Run のパラダイムは非常に高く評価されており、標準的にすらなろうとする勢いです。

Define-by-Run のパラダイムの有用性は、深層学習フレームワークの世界に限られたものなのでしょうか?我々は、ハイパーパラメータ自動最適化フレームワークの世界でも同様の考え方を適用できることに気づきました。この考え方の下では、全ての既存のハイパーパラメータ自動最適化フレームワークは Define-and-Run に分類されます。そして Optuna は Define-by-Run の考え方に基づき、既存のフレームワークと大きく異なるスタイルの API をユーザに提供しています。これにより、ユーザプログラムに高いモジュール性を持たせたり複雑なハイパーパラメータ空間を表現したりといったことが可能になりました。

学習曲線を用いた試行の枝刈り

深層学習や勾配ブースティングなど、反復アルゴリズムが学習に用いられる場合、学習曲線から、最終的な結果がどのぐらいうまくいきそうかを大まかに予測することができます。この予測を用いて、良い結果を残すことが見込まれない試行は、最後まで行うことなく早期に終了させてしまうことができます。これが、Optuna のもつ枝刈りの機能になります。

Hyperopt, Spearmint, SMAC 等のレガシーなフレームワークはこの機能を持ちません。学習曲線を用いた枝刈りは、近年の研究で、非常に効果的であることが分かっています。下図はある深層学習タスクでの例です。最適化エンジン自体は Optuna も Hyperopt も TPE を用いており同一であるものの、枝刈りの機能の貢献により、Optuna の方が最適化が効率的になっています。

並列分散最適化

深層学習は計算量が大きく一度の学習に時間がかかるため、実用的なユースケースでのハイパーパラメータの自動最適化のためには、性能が高く安定した並列分散処理を簡単に使えることが必要不可欠です。Optuna は複数ワーカーを用いて複数の試行を同時に行う非同期分散最適化をサポートします。下図のように、並列化を用いることで最適化は更に加速します。下図はワーカー数を 1, 2, 4, 8 と変化させた場合の例ですが、並列化により最適化がさらに高速化されていることが確認できます。

また、Chainer の分散並列化拡張である ChainerMN との連携を容易にする機能も用意されており、最適化対象の学習自体が分散処理を用いるような場合にも Optuna を簡単に使うことができます。これらの組み合わせにより、分散処理が含まれた目的関数を並列に分散実行するようなこともできます。

ダッシュボードによる可視化(実装中)

最適化の過程を見たり、実験結果から有用な知見を得たりするために、ダッシュボードを用意しています。1 コマンドで HTTP サーバが立ち上がり、そこにブラウザで接続することで見ることができます。また、最適化過程を pandas の dataframe 等で export する機能もあり、それらを用いてユーザがシステマチックに解析を行うこともできます。

終わりに

Optuna は既に複数の社内プロジェクトで活用されています。例えば、今夏準優勝を果たした Open Images Challenge 2018 でも用いられました。今後も活発に開発は続けられ、完成度の向上と先進的な機能の試作・実装の両方を精力的に進めていきます。現段階でも他のフレームワークと比較し Optuna を利用する理由は十分存在すると我々は考えています。お試し頂きお気づきの点があれば忌憚のないフィードバックを頂ければ幸いです。

先日開催された第 21 回情報論的学習理論ワークショップ (IBIS’18) では、弊社でのインターンシップにおける成果であるハイパーパラメータ自動最適化に関する研究を 2 件発表しました。これらは Optuna を実際に利用している中で出てきた問題意識に基づいており、成果はいち早く Optuna に組み込むことを目指して取り組んでいます。こういった技術により Optuna を更に優れたものとしていければと考えています。

我々の目標は、深層学習関連の研究開発をできるだけ加速することです。ハイパーパラメータの自動最適化はそのための重要なステップとして取り組んでいますが、他にも既にニューラルアーキテクチャー探索や特徴量の自動抽出といった技術に関しても取り組みを開始しています。PFN では、こういった領域や活動に興味を持ち一緒に取り組んでくれるメンバーをフルタイム・インターンで募集しています

HCIグループの発足、UISTおよびISS 2018での論文発表・デモ実施のお知らせ

Fabrice Matulic

2018-10-15 08:56:12

新たにHCI グループが発足しました

PFNでは最先端のAI技術を駆使して「インテリジェントな」次世代システムとサービスの実現を目指しています。しかし、システムの本質的な部分の開発や運用を担うのは依然として人間であるため、人間とマシンの対話を考える事は非常に重要です。ヒューマンコンピュータインタラクション(HCI)のアプローチは、人間とマシンの隔たりを埋め、機械学習においても人間の介入を要する複雑なプロセスの改善に大きく貢献します。この度PFNでは、「humans-in-the-loop(人間参加型)」の考えを採り入れながら、ユーザー中心のAI設計を推し進めるべく、新たにHCI専門のグループを立ち上げました。

HCIチームが探求する研究は大まかに以下の3分野です。

  • 機械学習のためのHCI: 機械学習には複雑で面倒なプロセスがあり、人間の関与が必要な部分がありますが、HCIの手法を利用する事でこれらの作業を容易にします(例えば、データ収集、ラベル付け、前処理、オーグメンテーション、ニューラルネットワークエンジニアリング、デプロイメントやマネージメントなど)
  • HCIのための機械学習: 深層学習を使って既存のインタラクション手法を強化したり、新たなインタラクション手法を実現します(例えば、高度なジェスチャー認識、行動認識、マルチモーダル入力、センサーフュージョン、身体的インタラクション、AIと人間のコラボレーション、インタラクティブなコンテンツを作成する生成モデルなど)
  • ヒューマンロボットインタラクション(HRI): 未来の賢いロボットとユーザーが、効果的かつ直感的に、さらには楽しくコミュニケーションやインタラクションできる事を目指します。

また、HCIグループの外部コンサルタントとして、HCIとHRI分野で豊富な経験をお持ちである東京大学の五十嵐健夫教授からアドバイスをいただく事になりました。五十嵐教授は、研究科学技術振興機構(JST)の戦略的創造研究推進事業(CREST)として、「機械学習のためのHCI」の研究にも取り組まれています。まさに私たちが注力する研究分野であり、今後の長期的な共同研究から実りある成果が生まれる事を大いに期待しています。

今年のUIST ISSで論文発表とデモを行います

HCIグループはまだ正式に立ち上げて間もないグループですが、すでに本格的な研究活動に着手し、直近の研究成果を二本の論文にまとめています。これらは今週開催されるUISTと来月開催のISSで個別に発表する予定です。

一つ目はウォータールー大学でDrini Cami氏とDan Vogel教授との共同研究ですが、タブレット画面に文字を書く際のスタイラスペンの握り方を変える事で様々な機能を呼び出すシステムです。本手法では機械学習を活用し、タッチ入力の生データにもとづいて、ユーザーの手が画面に触れた際の握り方を検知します。これにより、面倒で扱いにくいUIウィジットに頼らず、文字を書いている方の手でペンのモードを素早く変える事が可能です。詳しくは以下の動画をご覧ください。

UISTでは論文発表に加えてDrini Cami 氏が本手法のデモを行います。

二つ目の研究は、昨年12月のコミックマーケットに出展したPaintsChainerに用いたプロジェクションマッピングシステム(論文ではColourAIzeと呼んでいます)で、紙に描いた線画に自動で色を付けます。コミケに行けなかった方のために具体的に説明すると、PaintsChainerが自動的に判断した着色イメージを、線画に重ねるように投影して着色します。その結果、アナログとデジタルが融合した興味深い作品が出来上がります。Web版PaintsChainerと同様に、ヒントとなる色を指定してお好みの自動着色に仕上げる機能もサポートしており、任意の箇所をペンでなぞるだけで本機能が使用可能です。

最初にご紹介したペンの異なる持ち方の研究と同様、11月に東京で開催されるISSでは論文発表とデモの両方を行います。ご自身の線画やマンガにAIが自動着色する楽しい体験をしてみたい方は、カンファレンス期間中にぜひ私たちのデモにお越しください!

最後に、私たちは優秀なHCIリサーチャーを募集しています。前述の研究分野で貢献できる方は、弊社ウェブサイトの採用ページで募集要項をご確認いただき、ぜひご応募ください!お待ちしております。

[BoF] How to choose programming language for product/in-house software development

kashihara
エンジニア

2018-08-24 15:35:26

Preferred Networksでエンジニアをしている柏原です。PFN Dayでは “How to choose programming language for product/in-house software development” という題でBoFのセッションを開きました。PFN Dayとはトビアスのブログエントリ「[PFN Day] BoF session: How to Improve Sharing of Software Components and Best Practices」にもあるように、社内向けの技術カンファレンスです。

ソフトウェア開発において、プログラミング言語は開発環境をはじめとして、開発チームやサポート体制などに大きな影響を与えます。 PFNの中でもたくさんのプログラミング言語が使われていると思います。 今回は社内で何が使われているかという現状については言及せず、社外にリリースする製品/社内製品を開発することを想定して、どうやってプログラミング言語を選択するか、どのような要素がプログラミング言語の選択に影響を与えるのか議論したいと考えました。

まず、参加メンバーのバックグラウンドを共有するため、どういったソフトウェア開発・プログラミング言語の経験があるか自己紹介をしました。 その後、過去にどのような点を重視してプログラミング言語を選んだのか、プログラミング言語を選ぶときの重要な点についての項目を議論の中であげていきました。

結論としては必要としているものを正しく選ぶ、ということになりますが、以下の優先順位がプログラミング言語の決定に大きく依存しているということになりました。

  • Priority 1: Real world restrictions (E.g. frameworks, platforms)
  • Priority 2: Real world needs (E.g. stability, production readiness, concurrency, distributed computed)
  • Priority 3: Real world benefits (E.g. productivity factors)

1番目のrestrictionsでは、実行環境(OS、モバイル端末、組込)や、目的を実現するためのフレームワークが優先されます。 近年ではたくさんのプログラミング言語が増えてきたとはいえ、その言語が利用できるかは環境に大きく依存します。

2番目は、ソフトウェアで求められている機能・非機能要件を満たすことが、当然ながらソフトウェアの開発で求められます。 プログラミング言語やランタイム環境は、適材適所であるべきといえるでしょう。 ソフトウェアの安定性が求められるのはもちろんのこと、近年ではCPUのマルチコア環境を活かすことも必要とされてきています。 プログラミング言語の機能や特性によって、ソフトウェアの要求を実現できるというのはとても心強いです。

3番前は、プログラマーがプログラミングするにあたって、あると嬉しい部分です。 例えば、テキストエディタやIDEによる、プログラミング言語を書くことをサポートする機能(プラグイン)があげられます。

BoFを開催する前は極端な意見に偏るかもしれないと少し不安でしたが、最終的には現実的な結論に落ち着いたと思います。 その他、興味深いトピックとして、ソフトウェアの正しさを検証するものとして、モデル検査やHDLのSystemVerilog(言語)といったものも話題にあがりました。 80分と長いような短い時間の議論でしたが、興味深い会話ができたと思います。BoFのメモがもし公開されたら、そちらも是非ご覧ください。

2018年 PFN夏季インターンシップのコーディング課題公開

楠本充
エンジニア

2018-07-18 11:32:38

PFN 2018夏季インターンシップの選考で用いたコーディング課題を github 上で公開しました。

https://github.com/pfnet/intern-coding-tasks

PFN の楠本です。PFN では毎年8,9月前後に2ヶ月間の長期インターンシップを行っています。コーディング課題はその選考で応募者のプログラミング能力や問題解決能力を見るために出題させて頂いているものです。PFN のインターンシップでは機械学習をはじめとする幅広い分野で応募を行っているため、今年は「機械学習・数理」「バックエンド」「フロントエンド」「プロセッサ/コンパイラ」「Chainer」の5種類のコーディング課題を用意し、応募者の希望するテーマに応じてこのうちのいずれかを解いていただく形にしていました。

今年は去年を大きく上回る数の応募を国内外双方からいただくことができました。それに伴い、インターン生の受け入れ人数も去年よりもさらに拡充する形になりました。

今年の問題は以下のような構成になっています。

  • 機械学習・数理課題: ニューラルネットワークの敵対的入力(Adversarial Example)のアルゴリズムを実装し、性能を報告するためのレポートを記す課題。
  • バックエンド課題: 与えられたログファイルを分析するツールを作る課題。
  • フロントエンド課題: セミナー発表のような動画に対して、発表内容のアノテーションを行うウェブサービスのプロトタイプを作る課題。
  • プロセッサ/コンパイラ課題: 行列積コードの最適化と、行列積回路の設計を行う課題。
  • Chainer 課題: モデルの学習を行うコードを Chainer で実装する課題。

コーディング課題では毎年、出題者が趣向を凝らした問題を作成しています。これらの課題が、興味のある分野を実践的に学ぶための練習問題になれば幸いです。

私は今年の機械学習・数理課題の出題に携わりました。少し余談になりますが、課題を作る際に意識していたことについて書きたいと思います。他の課題ではまた話が違ってくるかもしれませんが、共通しているところもありそうです。

  • 前提知識があまり無くても解けるようにする: PFN では幅広い分野の方々を募集しています。そのため、機械学習そのものの経験や知識が無くても課題を一通り解けるように問題を設定したり、問題文を記述するようにしています。また、特定の知識を持っている人が有利になりすぎるということがあまりないようにも配慮しているつもりです。
  • 実際の研究に近いような設定にする: 深層学習のような分野の研究では「何か良いテーマを見つけて手法を考える → 実装する → 出てきた結果をまとめ、考察を与える」という過程を繰り返しますが、このうち「実装して考察する」という流れを短期間で一通り辿れるような設定にしています。大学の授業の課題のような感じに近いかもしれません。
  • できるだけ興味深いテーマを問う: 機械学習・深層学習の分野では日々研究が進んで面白い結果が次々に出ているので、それに少しでも触れられるような課題を設定しているつもりです。今回の課題である Fast Gradient Signed Method という手法は、シンプルな手法でありながらランダムよりも遥かに強い攻撃手法であるという点で興味深いものだったと思います。
  • 時間が掛かりすぎないようにする: 学業に支障が出ると良くないので、実力が十分あれば1~2日程度で終わるような分量にすることを目標にしています。

提出されたコードは様々な観点から評価するようにしています。単に実装されたコードが正しいのかどうかだけではなく、コードが読みやすいものになっているか、単体テストなどの検証のためのコードが適切に書かれているか、他人がコードの追試をしやすいようになっているか、といった要素も考慮するようにしています。
実験ではコードを書いて動かしたら終わりではなく、手法がどの程度うまくいったのかを評価し、なぜそのような結果になったのかを考察するのが重要になります。特に、複数人で一つの課題に取り組む際にはそれら(評価・考察)を他のチームメンバーに共有することも大事になるでしょう。レポートでは結果の評価と考察ができているかを評価するようにしています。

これらの課題を見て PFN に興味を持っていただけた方は、ぜひ来年のインターンシップへ応募することを検討していただければ幸いです。また、PFN ではフルタイムの採用も通年で行っておりますので、こちらもご検討をよろしくお願いします。

分散深層学習を支える技術:AllReduceアルゴリズム

kfukuda

2018-07-10 11:49:43

本記事は、2017年インターンシップを経て現在はアルバイトとして勤務されている上野さんによる寄稿です

数式が正しく表示されない場合は、こちらのリンクから再読込をお試しください。


みなさんはじめまして。Preferred Networksの2017夏季インターンに参加し、現在アルバイトをしている上野裕一郎です。普段は東京工業大学でHigh-Performance Computingに関する研究を行っており、分散・並列計算に興味があります。

今回は、分散深層学習を行う際に使用されるAllReduceという通信パターンについて調査・実装・評価を行いましたので、それについてご説明いたします。

分散深層学習とは

現在、ディープニューラルネットワークを用いた学習には長い時間がかかることが知られています。そして、様々な種類のモデルや、大量のデータを組み合わせて学習を試すためには、学習にかかる時間を短縮する必要があります。そのために、多数のプロセスに分散して計算を行うことで、学習にかかる時間を短縮することを目的とするのが分散深層学習です。分散深層学習の詳細については、Preferred ResearchのChainerMN 公開に関する記事[1] をご参照ください。

弊社では、深層学習の研究開発や関連技術の迅速な実用化のために、スーパーコンピュータ MN-1 を運用しています。これは、民間企業のプライベートな計算環境としては国内最大級で、NVIDIA(R)製 Tesla(R) P100 GPUを1,024基、Mellanox(R) InfiniBand FDRを搭載しています。これを用いて、ImageNetの画像分類データセットを利用したResNet-50の学習を15分で完了することができました[2]。

しかし、このような多数のGPUを用いて効率的に計算を行うのは多くの困難が伴います。そのうちの1つとして、データ並列型分散深層学習において、GPU同士の通信にかかる時間がボトルネックとなっていることが挙げられます。

分散深層学習では、どのような通信が発生し、なぜ時間がかかるのか、もう少し詳しくご説明します。

分散深層学習におけるAllReduceの重要性

データ並列型分散深層学習では、異なるデータでモデルのパラメータでの損失関数の勾配を求めたあと、プロセス間で勾配の平均を求め、求めた平均を得られた勾配とみなして、モデルに適用を行います。この勾配の平均を求める操作として、多対多の通信を行う集団通信アルゴリズム:AllReduceが用いられています。

このとき、最もよく用いられているのが、NVIDIA社が提供しているNCCL[3] (NVIDIA Collective Communications Library)です。NCCLは、並列・高性能計算の分野の標準であるMPIと比較して、圧倒的に高速な通信を実現しています。前述のImageNet15分実験においても、NCCLが実現する高速通信は、記録の達成には不可欠なものでした。現在、ChainerMNでデータ並列型分散深層学習を実行するにあたっては、NCCLは必須のライブラリとなっています。

さて、NCCLの高い性能の秘密はどこにあるのか、社内でも多くのリサーチャーやエンジニアが興味を持ちました。今回は、実験的にAllReduce通信プログラムを作成し、最適化することによって、NCCLの性能にどこまで迫れるかを試してみました。

AllReduceのアルゴリズム

では、分散深層学習のスループットに大きな影響を与えるAllReduceについて詳しく見ていきます。
AllReduceとは、すべてのプロセスが持っている配列データを集約(Reduce)したうえで、すべてのプロセスがその結果を等しく取得する操作です。まず、総プロセス数を \(P\), そして、それぞれのプロセスには\(1\)から\(P\)までの番号\(p\)がついているとします。そして、各プロセス\(p\)が長さ\(N\)の配列\(A_{p}\)を持っているとしましょう。さらに、プロセスpが持つi番目のデータを \(A_{p,i}\) とします。このとき、最終的に得られる配列を \(B\)とすると、

$$ B_{i}~~=~~A_{1,i}~~Op~~A_{2,i}~~Op~~…~~Op~~A_{P,i} $$

となります。ここで、\(Op\) は2項演算子で、SUM(合計)、MAX/MIN(最大値/最小値)などがよく用いられます。つまり、ここでいう集約(Reduce)とは、配列の要素 \(A_{p,i}\) を、\(p=1,…,P\)までの全プロセスにわたって \(Op\)を用いて畳み込み計算することになります。分散深層学習においては損失関数の勾配の平均が必要であるため、勾配の要素ごとにSUMを用いて合計を計算します。以降では、集約操作に用いる演算はSUMだと仮定します。図1に、\(P=4\), \(N=4\)のAllReduceを実行する模式図を示しています。

図1. AllReduceの模式図

このようなAllReduce処理を実装する方法として、複数の方法が考えられます。

例えば、最も単純な方法として、代表となるプロセスを1つ決め、そこに全ての配列を集め、そのプロセスが全てのReductionを行い、計算結果を全プロセスに配布する、というアルゴリズムを考えることができます。しかし、このアルゴリズムは、プロセス数が増えると代表プロセスの通信量、Reduceの計算量、メモリ使用量がそれに比例して増え、処理量に不均衡があります。

このようにプロセス間の処理量に不均衡が存在しないよう、うまく通信や計算を全てのプロセスに分散させたアルゴリズムが提案されています。代表的なものとして以下のものが挙げられます。

  • Ring-AllReduce
  • Rabenseifnerのアルゴリズム[4]

本稿では、Ring-AllReduceアルゴリズムについて紹介します。NCCLも、Ring-AllReduceを用いて実装されています[5]。

Ring-AllReduce

まず、総プロセス数を\(P\), そして、それぞれのプロセスには\(1\)から\(P\)までの番号がついているとします。そして、各プロセスが図2のようにリングを構成するとしましょう。

図2. リングの構成例

ここで、プロセスpに着目して処理の流れを見ていきます。

まず、プロセスpは、自分の配列をP個に分割し、この分割された配列のp個目をチャンク[p]と表記するとします。そして、プロセスpは、チャンク[p]を次のプロセスp+1に送信します。この時、同時にプロセスp-1はチャンク[p-1]の送信を行っているので、プロセスpはこれを受信することができます(図3)。

図3. 各プロセスpがチャンク[p]を送信する

そして、プロセスpは、受信したチャンクに自分のチャンク[p-1]を足し込み(Reduceし)、計算結果を次のプロセスに転送します(図4)。

図4. 各プロセスがReduce後のチャンク[p-1]を送信する

これをP-1ステップ繰り返すことで、それぞれのプロセスが、Reduce済みのチャンクを1つ手に入れることができます(図5)。

図5. P-1ステップの繰り返しが終了し、Reduce済みのチャンクを1つ手に入れる

言い換えれば、各々のプロセスが、リングの上をまわるチャンクに、自分のチャンクを少しずつ足しこんでいきます。そして、チャンクがリングに沿って全プロセスを1度ずつ訪問した時点で、そのチャンクは、全てのプロセスのチャンクの集約の結果になっています。つまり、最終的には、それぞれのプロセスが、チャンクごとの集約の結果を1つ保持していることになります。

そして、それぞれのプロセスが持つ集約済みチャンクを、さらにリング上で一周回すことで、全てのプロセスが集約済みチャンクを全て取得でき、AllReduceが完了したことになります。

では、このアルゴリズムの通信量を、先程挙げた単純なアルゴリズムと比較してみましょう。

単純なアルゴリズムの場合、代表プロセスが受信するデータの量は、代表プロセスでない全てのプロセスからデータを受信する必要があるので、\((P-1) * N\)となります。その後、代表プロセスでない全てのプロセスにデータを送信する必要があります。これは、Pに対して代表プロセスの受信量が比例しています。

対して、Ring-AllReduceにおける1プロセスあたりの送信(受信)したデータの量は、以下のように求めることができます。最初に、P個に分割した配列をReduceしながらP-1回送信しました。そして、全プロセスにそのReduce済みチャンクを配布するために、P-1回送信しました。よって、1プロセスあたりの送信量はこの合計である \(2(P-1)/P * N\)となり、1プロセスあたりの送信量はPに関して定数であることが分かりました。

よって、2つのアルゴリズムを比べると、Ring-AllReduceは代表プロセスに集中していた送信・受信量を各プロセスにうまく分散させたアルゴリズムになっていることが分かります。このような特徴から、多くのAllReduceの実装でRing-AllReduceアルゴリズムが用いられています。

実装と最適化

Ring-AllReduceのアルゴリズムそのものは、GPU対GPUの通信を行う送受信関数を用いれば、簡単に実装することができます。Baidu社によるbaidu-allreduce[6]は、MPIのライブラリ上で実装済みの MPI_Send, MPI_Recv関数を用いてこれを実現しています。

今回は、MPIではなく、InfiniBandを直接扱うことができるInfiniBand Verbsを用いて実装し、より進んだ最適化を試みました。まず、InfiniBand、GPU、CPUのそれぞれのハードウェアリソースのアイドル時間を可能な限り削減して性能を引き出すために、アルゴリズムの処理をRegistration, Send, Reduction, Receive, Deregistrationなどのステージに分割し、パイプライン化を行っています。ここで、Registration, Deregistrationは、メモリ領域をDMAを用いて転送する際に必要な前処理、後処理を表しています。これらは、MPIを用いて実装すると、 分割してパイプラインに組み込むことができません。
さらに、配列を分割したものであるチャンクを、パイプラインの粒度をより細かくするために更に分割しました。また、メモリ確保は低速であることが知られているので、メモリプールを導入してコストを隠蔽しています。

性能評価

本稿で実装したプロトタイプ(PFN-Proto)の性能を、他の既存実装(詳細は付録に記載)と比較しました。比較対象を、スーパーコンピュータで広く用いられている通信ライブラリであるOpen MPI[7]、Baidu社によるbaidu-allreduce[6]、NVIDIA社によるNCCL[3]です。

なお、今回の我々のプロトタイプ実装は、ノード間通信に焦点を当てて開発しており、ノード内でのGPU間のDMA通信や共有メモリを使った通信最適化は実装されていません。実験では、1ノードに1プロセスを実行する条件でのみ測定しています。また、Open MPIについては、最新シリーズであるバージョン3.xではGPU Directに関係するバグがあり、弊社内ではまだ導入していないため、2.1.3を測定対象としています。

総プロセス数を8として、1ノードに1プロセスを起動することとし、256MBの配列のAllReduceをそれぞれ10回ずつ実行して測定を行いました。実験環境は、MN-1を用いています。実験環境の詳細は付録「実験環境」をご参照ください。図6に性能評価の結果を示します。

図6. AllReduceの実行時間の評価

この棒グラフは実行時間を示しており、低いほうが良い結果を示します。各棒は、それぞれのライブラリの10回の実行時間の中央値、エラーバーは実行時間の95%信頼区間を表しています。各実装の名前の意味、バージョンなどは、付録「比較対象ソフトウェア」をご参照ください。

まず、実行時間の中央値について見てみましょう。一番右側に示されているPFN-Protoが、最も高い性能を示しています。これは、ompi, ompi-cuda, Baidu, NCCLと比較して、それぞれ約82%, 286%, 28%, 1.6% 高速となっています。なお、グラフ上には示されていませんが、10回試行中の最速は、baidu-allreduceで0.097 [s] となりました。

次に、実行時間の分布について見てみましょう。中央値を基準にした実行時間の最大値と最小値は、PFN-Protoが +/-3%、NCCLが+/- 6%以内に収まっています。一方、baidu-allreduceは最大値が中央値の7.5倍という大きな数字となりました。これは、初回実行時に大幅に時間がかかるためです。なお、初回の試行を除いた最大値も中央値の+9.6%となっており、依然としてNCCLおよびPFN-Protoよりもばらつきが大きいことがわかります。

MPI、およびMPIをベースにした実装でこのように性能にばらつきが出る原因としては、MPIが内部で行っているメモリ領域の扱い方に関連していると推測しています。MPIは、InfiniBandによる送受信に必要となるメモリ領域の確保とRegistrationなどを抽象化したインターフェイスを提供しています。これにより、Ring-AllReduceの実装から、それらの発生タイミングを精密に制御することができないため、性能にばらつきが出ると考えられます。

関連研究

今回は、分散深層学習の中のAllReduce操作の高速化についてご説明しました。それ以外にも、分散深層学習の通信部分を高速化する方法として様々なものが考えられています。例えば、

  • 勾配の送受信を1イテレーション遅延させて、Forward, Backwardと通信をオーバーラップする方法(例:ChainerMNにおけるDouble Buffering[8])
  • データの浮動小数点精度を下げることによって通信量を削減する方法(例:ChainerMNにおけるFP16通信[8])
  • 勾配の値の重要度によって送受信するデータを間引いて通信量を削減する方法[9]

などがあります。特に、InfiniBandを持たないような環境(例えばAWS)では、このようなテクニックを用いることで学習を高速化することができます。

まとめ

本記事では、分散深層学習を支える技術である、AllReduceという通信パターン、特にRing-AllReduceという通信アルゴリズムについて説明しました。

そして、このアルゴリズムを実装し、今回の実験環境・実験条件では、NCCLと同等の性能まで最適化することができました。そのためには、InfiniBand Verbsを使用し、徹底的なパイプライン化を行うことが必要であったことが分かりました。これにより、高いハードウェアの性能と並行性を十分に活用することができました。これからも、より高速で、高い信頼性を持つ通信にはどのようなアルゴリズムやチューニングが最適か、調査・開発を進めていきたいと考えています。

ただし、今回の実装は、社内のクラスタを使用して開発・最適化しており、社内のクラスタのみに最適化された実装になっている可能性があります。それに対してNCCLは、幅広い環境で安定して利用できる高速な集団通信ライブラリであり、依然として、NVIDIA製GPUを用いて分散深層学習を行うためには、NCCLを使用するべきであると考えています。

謝辞

最後に、インターンの頃からメンターの方々やチームの方々には手厚いサポートをしていただきながら、大量の計算資源のもとでプロジェクトを進めることができており、非常に貴重な経験をさせていただいています。本当にありがとうございます。


おまけ:メンターより

上野さんのインターンシップメンターを務めています、PFN 大規模分散計算チームの福田(@keisukefukuda) です。今回は、NCCLの高い通信性能はどのように実現されているのだろうか?という疑問からスタートした実験的なプロジェクトでしたが、上野さんの高い技術力によってNCCLに近い性能を出すことに成功しました。

PFNでは、機械学習/深層学習そのものの研究だけでなく、ソフトウェアからハードウェアまで、広い分野で研究開発を進めています。

HPC・高性能計算に興味を持っている学生の皆さんは、ぜひ来年のPFNインターンシップへの応募をご検討ください(このブログ記事の公開時点では、残念ながら2018年の夏季インターンの募集は終わってしまいました)。

また、もちろん中途・新卒の人材募集も通年で行っています。興味のある方はぜひご検討ください!PFNの人材募集のページはこちら https://www.preferred-networks.jp/ja/jobs です。

参考文献

[1] 分散深層学習パッケージ ChainerMN 公開
[2] Akiba, et al., “Extremely Large Minibatch SGD: Training ResNet-50 on ImageNet in 15 Minutes”
[3] NVIDIA Collective Communications Library
[4] Rabenseifner, “Optimization of Collective Reduction Operations”, ICCS 2004
[5] Jeaugey, “Optimized Inter-GPU Collective Operations with NCCL”, GTC 2017
[6] baidu-allreduce
[7] Open MPI
[8] ChainerMNのクラウド環境向け新機能とAWSにおける性能評価
[9] Tsuzuku, et al., “Variance-based Gradient Compression for Efficient Distributed Deep Learning”, In Proceedings of ICLR 2018 (Workshop Track)

付録

比較対象ソフトウェア

Implementation Version Note
MPI (ompi) Open MPI 2.1.3 CPUメモリからCPUメモリへの転送
(他の実装はすべてGPUメモリからGPUメモリへの転送)
CUDA-aware MPI Open MPI 2.1.3
baidu-allreduce (baidu) A customized version of baidu-allreduce, based on commit ID 73c7b7f https://github.com/keisukefukuda/baidu-allreduce
NCCL 2.2.13

実験環境

  • Intel(R) Xeon(R) CPU E5-2667 x 2
  • Mellanox(R) ConnectX(R)-3 InfiniBand FDR (56Gbps) x 2
  • NVIDIA(R) Tesla(R) P100 GPU (with NVIDIA Driver Version 375.20)

Emergence of Locomotion Behaviors in Rich Environment の追試

Manabu Nishiura

2018-06-29 10:48:38

1.内容紹介

はじめまして。PFNでSummer Internship 2017に続き、アルバイトをしている東京大学の西浦です。現在は駒場2キャンパスの先端研で神経科学・循環器系の数理モデルの研究をしています。

さて、2017年の春頃、DeepMindから”Emergence of Locomotion Behaviours in Rich Environments”[1]という論文が公開され、その動画が話題になりました。しかし、この論文では公開されている情報が限られており(深層学習分野でよくあることなのですが)、実験環境の設定、ネットワークの構成や学習に必要なパラメータで不明なものが多く、論文の結果を再現するためには不明な部分を推定するために多くの組み合わせを試す必要がありました。そのため、このような実験の再現は深層学習の実践的な知識と学習のための大規模なリソースが必要とされ、個人で行うのはなかなか難しいと思います。今回はその論文をChainer FamilyのひとつであるChainerRLを利用して再実装し追試を行い、その結果として様々な知見が得られましたのでご報告させていただきます。

Emergence of Locomotion Behaviors in Rich Environmentsの元動画

2.元論文の概要

強化学習のパラダイムは、原理的には単純な報酬のみから複雑な振る舞いを学習することができるようになっています。しかし実際は、意図した振る舞いを学習させるためには、報酬関数を慎重にチューニングすることが一般的です。この論文では、報酬はなるべく直感的な構成で固定してしまい、学習に使う環境(タスク)を様々な種類用意して、エピソードごとにランダムにその環境を変更するというアプローチが採用されています。これにより、様々な環境に対してロバストで、複雑な行動を獲得させようということをモチベーションに実験が行われています。

アルゴリズムとしては、方策勾配法(Policy Gradient)をベースにして、現在の方策に近い方策へと徐々に更新していくProximal Policy Optimization(PPO)[3]を用いています。PPOは論文公開当時では一番性能の良い強化学習のアルゴリズムだったのでそれが採用されていて、論文には同じく性能のよいTrust Reigion Policy Optimization(TRPO)[4]との比較もされています。

3.アルゴリズム、実験手法の解説

前提知識

まず強化学習のフレームワークについて説明します。強化学習では環境とエージェントというのがあり、エージェントが環境に対して行動をし、環境はそれを受けてエージェントに対して観測と報酬を返すという枠組みになっています。エージェントは、報酬に基づいて行動を決定するためのルール「方策(Policy)」を学習していきます。この論文では、ロボットなど連続値の行動を扱いやすい方策勾配法を採用しています。方策勾配法ではActor-Criticモデルという、エージェントをActor(行動器)とCritic(評価器)でモデル化し、例えばそれぞれをニューラルネットワークで表現します。また、エージェントがActor-Criticモデルだと、例えば、Actorのネットワークを決定しているパラメータが方策に該当します。Criticは、現在の方策の元である状態がどれだけの価値を持つかを表す価値関数(ある状態以降の報酬の期待値に割引率をかけたものが一般的)でモデル化されます。

 

実験環境としては、物理エンジンのMuJoCo [2]と強化学習のフレームワークであるOpenAI Gym [5]を用いています。代表的なものとしては、Planar walker(またはWalker2d)と呼ばれる二次元平面内でエージェントに二足歩行を行わせるモデルが挙げられます。Planar walkerの場合、それぞれのエージェントは各関節を曲げるトルクにより行動を表現することになります。また、エージェントが環境から受けとる観測は、大きく内部状態と外部状態に分けられ、各関節の角度、角速度、位置、接触、トルクセンサ情報などを内部情報、地形の高さ情報を外部情報として受け取っています。報酬はPlanar walkerの場合だと以下のように設計されており、基本的には前に進むと報酬がもらえ、それに加えて姿勢のペナルティー(負の報酬)などが含まれています[1]。

Planar walker [4]

今回追試したアプローチでは、方策を決定するネットワークは内部状態と外部状態を別々に処理して最後に合わせて処理して、行動の次元個分、平均と分散の組を指定した正規分布を確率的方策としてを出力する構成になっています。

アルゴリズム

ここで、追試で使ったTRPOとPPOの二つのアルゴリズムについて解説します。まず、ベースになっている方策勾配法は、目的関数(原則としては現在の方策による期待値を用いる)を方策のパラメータに関して微分し、得られた勾配方向にパラメータを更新する方法です。目的関数を計算するために、現在の方策で行動して、その系列データを貯めること(一般化方策反復)を行います。しかし、方策の更新には慎重になる必要があり、一度方策が劣化してしまうと、それから後に得られるサンプル系列も悪化してしまい、持ち直すのが難しくなるという問題があります。

そこでTRPOは、方策の更新に制限をかけながら更新していきます。具体的には、KLダイバージェンスを使って信頼領域(trust region)を定義して、その信頼領域を超えないように、制約条件つきの最適化問題を解くことにより方策のパラメータを更新します。これにより方策の分布として大きな変化を抑制することができて、方策の大きな劣化を防ぐことができます。TRPOが二回微分を計算するので、計算量が多いことを踏まえ、PPOはTRPOの制約条件を目的関数に含めて非厳密化することで、TRPOより単純で軽い計算量でそれなりの性能を発揮するアルゴリズムになっています。

具体的には、方策を \(T * N\) time steps走らせて(Nはスレッドの数)集めた \(s_t\) ,\(a_t\), \(r_t\) を用いて \(A_t\)(アドバンテージ)を計算し、\(L^{CLIP} \)を前の方策と新しい方策の比率を \(\pm \epsilon\) 内にクリップして勾配方向にパラメータを更新していきます。方策のネットワークと価値関数のネットワークでパラメータを共有する(最後の出力層のみそれぞれのパラメータを使う)なら、方策と価値関数のネットワークを独立に更新できないので、目的関数に価値関数の誤差項を加え、探索の幅を増やしたければ、エントロピーボーナスを加えることもあります。(最終的な目的関数は \(L^{CLIP+VF+S} \))ここで登場するアドバンテージとは、収益(報酬の期待値)からベースラインを引いたもので、勾配の推定値の分散を減らすためのテクニックです。それぞれの計算式を以下に示します[3]。

元論文ではPPOをさらに分散版にしたものを使っています。追試としては、PPOで方策ネットワークと状態価値関数にLSTMを含んだものと、TRPOを用いましたが、1スレッドの場合では、TRPOの方がかなり性能がよかったです。したがって、以下の結果は全てChainerRLのTRPOで学習させた結果となります。

実験手法

追試としては2通りの環境で訓練しました。一つ目は元論文の動画に近い3種類のタスクがある環境で、もう一つは地形の凸凹の状態がランダムに変わるものです。

元論文に近い環境では、Planar Walkerを①箱を飛び越えるタスク、②穴を飛び越えるタスク、③浮いている板を避けるタスクの3種類の環境で順番に訓練した後、3種類の環境(タスク)がランダムにエピソードごとに切り替わる環境で訓練します。

地形の凸凹の状態がランダムに変わる環境では、エピソードごとにすべての地形が変わる中で訓練します。

4.結果

学習し始めのエピソードごとにランダムに地形が変わる中で試行錯誤している様子

学習後歩いている動画

こちらでは、学習初期段階からランダムに地形を変更していたためか、とにかく脚を高く上げて、どんな障害物でも越えられるような動きになってしまったようです。

動画に示した歩行行動を獲得するまでの学習曲線を上に示します。10,000ステップごとに10エピソード走らせて評価を行なっており、青のrewardは10エピソードの平均累積報酬で、上下の灰色の線は10エピソード内での最小値最大値になっています。200万ステップほどで収束していることが分かります。

 

元論文に近い環境で学習後歩いている様子

障害物によって頭を下げたり、ジャンプする高さが変わったり、動きが変わっていることが見て取れます。一つ目と二つ目の動画ではPlanar walkerの関節の減速比のパラメータが違っていて、このような微妙な差でも獲得される動きに違いが出てしまいます。

 動画に示した歩行行動を獲得するまでの学習曲線を上に示します。歩く動作は120万ステップほど、穴を飛び越える動作は800万ステップほど、浮いている板を避ける動作は400万ステップほどで学習が収束していることが分かります。

タスクによって報酬の平均がそこまで変動していないものもあり、歩く動作を獲得した状態から箱を飛び越える動作の獲得にはそれほど学習が必要ではないが、箱を飛び越える動作を獲得した状態から穴を飛び越える動作を獲得するのと、箱を飛び越える動作を獲得した状態から浮いている板を避ける動作を獲得するためにはかなり学習が必要であることが分かります。

元論文では適切に実験設定が考えられていて、カリキュラムラーニングになっていたために、タスクに応じて行動をうまく切り替えられるようになっていましたが、ただ単に地形やタスクをランダムに変えるだけでは、どんな環境にも対応するような方策を獲得してしまうようです。

5.考察

問題点の一つに、初期条件を注意深く設定しないと意図した学習結果になりづらいという問題があります。今回の場合も初期の状態変数の分散や、地面とMuJoCoのモデル(Planar walkerなど)との高さ方向の相対的な位置は学習の様子をみながら調整することが必要でした。具体的に注意した点としては以下のような点が挙げられます。

  • ある程度初期状態に分散がないと、分散の範囲で実現できる行動になってしまう。(逆に分散が大きすぎても学習がうまく進まないことがある)
  • 環境をリセットした時に何ステップ分フレームをスキップしてから指令を出し始めるか、によって獲得されるモーションが変わってくる。(例えばMuJoCo環境内で、完全に地に足が着いてから指令値を出すようにした、など)
  • 歩行を獲得させる場合、学習の過程で最初に獲得されるのはその場に立っているという方策なので、初期位置の周辺はなるべく平らな方がよさそう。

その他にも、下記の記事[6]に現状の深層強化学習の課題はよくまとまっているので、ぜひ読んでいただきたいです。(方策を更新していくために特定のアルゴリズムを採用しても、報酬関数、方策を表現するネットワークのパラメータなどは自分で任意に決定する必要があり、設定する報酬によって獲得される方策がかなり変わってしまうという問題など。)

 

失敗例の動画

けんけんを獲得している動画(初期化した時の相対的な高さの問題で、片足を前に出す方策を獲得できなかった例、初期状態の分散はうまくいった例と同じ)

6.PFNインターンの感想

ある仮説を検証するのに、「ある実験系でやってみて上手く行かなければもっと単純化した系でやってみる。」という、研究の基礎的なプロセスの体験ができたのはとてもよかったです。また、ロボティクス関係の様々な研究を知ることができ、そこで研究している人たちとの繋がりができたのは一番大きな収穫だったかもしれません。最後に、情報交換の重要性も強く意識することができました。有名なライブラリやパッケージの使い方(インストールで苦戦するものなど)や、こういう手法を試したけどいまいちだった、ハイパーパラメータの情報など、公開されていなけど実験をしていく中では欠かせない情報などを共有できる環境が、とてもありがたいなと感じました。

元論文の情報が結構少なく、なかなか学習が進まず進捗が出ずに精神的に辛い時期もありましたが、様々な方に積極的に相談するようになってからは比較的スムーズに乗り切ることができたように思います。最後になりましたが、ご指導いただいてるメンターの皆様をはじめ、社員の方々に感謝を表して報告を終わらせていただきたいと思います。

参考文献

[1] “Emergence of Locomotion Behaviours in Rich Environment” https://arxiv.org/abs/1707.02286v2

[2] MuJoCo advanced physics simulation http://mujoco.org/

[3] “Proximal Policy Optimization Algorithms” https://arxiv.org/abs/1707.06347

[4] “Trust Reigion Policy Optimization” https://arxiv.org/abs/1502.05477v5

[5] OpenAI Gym https://gym.openai.com/docs/

[6] “Deep Reinforcement Learning Doesn’t Work Yet” https://www.alexirpan.com/2018/02/14/rl-hard.html

 

DNN推論用ライブラリ「Menoh」リリースについて

Shintarou Okada
エンジニア

2018-06-21 11:41:46

Python以外も使いたくないですか?  特にDeepLearning界隈で.

Menoh開発者の岡田です.この記事ではMenohの紹介と開発に至った動機について説明します.

Menohのレポジトリ: https://github.com/pfnet-research/menoh

Menoh(メノウ)は学習済みのDNNモデルをONNX形式から読み込んで動作させる推論専用のライブラリです.実装はC++で書きましたが,C言語のインターフェースを持たせて,他の言語用からもその機能を呼び出しやすくしてあります.リリース時点でC++版ラッパーとC#版ラッパー,Haskell版ラッパーがあり,Ruby版ラッパーとNodeJS版ラッパー,Java(JVM)版ラッパーが開発中です.バックエンドにはIntelの開発しているMKL-DNNを採用し,GPUが無くてもIntel CPUが使える環境で高速にモデルの推論が可能になっています.Menohを使えばChainerで学習したモデルをPython以外の言語で実装したアプリケーションに瞬時にデプロイすることが可能です.

ところでなぜDeepLearning界隈で覇権を握ったのがPythonであって,Rubyじゃなかったんでしょう? Rは? Perlは? C++は? プログラミング言語は数多くありますが,どの言語も今のPythonのように広くDL用学習フレームワークを記述するために利用される可能性はありました(もちろん言語ごとに用途の向き不向きがあって,可能性の大小はあったにせよ).我々の宇宙ではPythonが覇権を握りましたが,どこか別の宇宙ではLispが覇権を握ることもきっとあったでしょう.とは言え,我々は我々の宇宙に生きるしかなく,今日そのディープなんとかを実装するには甘美な()や{}やbeginendから離れて空虚なインデントでブロックを記述する必要があります.このことについて,なんと悲しいことかと手放しに言い切れれば良かったんですが,皆さんご存知の通り,Pythonは良い言語です.

そう,Pythonは良い言語です.豊富なライブラリ,特にNumpyが使えること,動的型付けであること,GC機能が搭載されていること――どれもがDNNを実装したり学習させたりするコードを試行錯誤しながら書くという作業をやりやすくしてくれます.もちろんChainerはPythonで記述されており,改造・拡張しやすいDNN学習フレームワークとなっています.ChainerはそのDefine-by-Runという魔法によってすばらしく使いやすい.このDefine-by-Runをもっと別の言語で実装することも出来たと思いますが,コードはより複雑に,その作業はもっと苦痛の伴うものになっていたでしょう.明らかにChainerの使い勝手の良さの一端はPythonという言語そのものが担っています.

我々にとって,DNNについて研究する作業というのは地獄ではありません.Pythonの使い勝手の良さに裏打ちされたChainerがあるからです.手軽にDNNモデルを記述して学習を回せる.素晴らしいことです.地獄なのは学習したDNNモデルをデプロイする作業です.

地獄というのは言いすぎかもしれません.Pythonがデプロイ先の環境で使えるならChainerをそのまま使えばよく,首尾貫徹して苦痛はどこにも(少なくともデプロイ作業には)ありません.でもPythonが使えない環境はどうでしょうか.研究室の外に出ると,セキュリティや計算資源的な問題などでPythonが使えない環境や,分野によっては別の言語が覇権を握っていてPythonではそこにある資産を利用できない状況というのは山ほどあります(例えば,Web界隈では今でもRubyに根強い人気があります).現在でもDLフレームワークの中には設計がデプロイまで意識されたものや,Pythonを使わずにCやC++などでDNNを記述できるものもありますが,大掛かりだったり,あまりに実装が剥き身すぎて使いづらかったりします.現状はDNNの学習については広く知見が行き渡っているのと比べて,まだまだDNNのデプロイについては発展途上であると言えます.

ただ学習したモデルを自分のアプリケーションに組み込みたいだけなのにそれがなかなか難しい.

以上が私がMenohの開発を始めた動機です.

MenohはPFNが社内で定められた20%ルールの下でのプロジェクトの成果です.20%ルールとは「PFNメンバーは公式にアサインされたタスクとは別に20%の時間を各自の好きなタスクやプロジェクトに充てても良い」というもので,Menohプロジェクト以外にも様々な個人やチームのプロジェクトや勉強会が進行しています.

MenohはChainer Advent Calendar 2017で開発した「Instant」というライブラリが元になっています.20%の時間を使って,Instantの機能を拡充していく中で,設計の助言をしてくれたり,他の言語のラッパーを書いてくれたりするメンバーが現れて,そうした自発的に協力してくれたメンバー達のお陰でInstantはMenohに名前を変えて実験的なプロダクトとしてpfn-researchにてリリースするに至りました.これからも20%の時間を使って開発は継続していく予定なので,ぜひ利用してもらって,バグや要望等あればどんどんIssueに投げていただければと思います.

Preferred Networks における研究活動

秋葉 拓哉
リサーチャー

2018-06-08 14:36:39

こんにちは、新しく執行役員兼 Chief Research Strategist に就任した秋葉です。就任の挨拶を兼ねて、PFN における研究活動に関する考えを共有したいと思います。

PFN における研究とは何か?

何が研究であり何が研究でないかという境界を引くのは非常に難しく、またそれを積極的に行う意味もありません。研究とは「研ぎ澄まし究めること」を語義とし、一般に、物事について深く調査・考察を行い事実を解明したり発明を行ったりすることを指します。

PFN では挑戦的であり不確実性の高いプロジェクトが大部分を占めており、ほぼ全てのプロジェクトが少なからず研究的側面を伴います。深層学習関連のコア技術の研究開発は勿論、その応用に関してもデータやタスクに応じた適切な手法の選択や非自明な工夫がなければ上手くいかないことが殆どです。また、ロボティクス、コンピュータビジョン、自然言語処理等のような多分野の技術を組み合わせることにより新たに出てくる課題もあります。それに加えて、クラスタの設計やそのリソース管理、及びディープラーニングフレームワークに関しても、深層学習特有の要求を満たし、便利かつ高性能にするために、多くのことを考え試行錯誤をしています。

そのような中でも、特に研究的側面を強く持つプロジェクトには、以下のようなものがあります。

  • 論文となるような学術的研究
  • デモンストレーションの制作と展示
  • コンペティションへの参加
  • 社会での未解決問題の解決

このような分野でも、既に素晴らしい成果が出ています。論文に関しては、ICML, CVPR, ACL, CHI など、幅広い分野のトップ会議に論文が継続的に採択されるようになりました。また、数が増えているだけでなく、ICRA’18 にて論文が Best Paper Award on Human-Robot Interaction を受賞したり、ICLR’18 にて論文が Oral に選ばれたりと、世界的に極めて高い注目を集める論文を出すことに成功しています。デモンストレーションとしては、CEATEC 2016 や ICRA 2017 等で制作したものを展示しました。コンペティションとしても、Amazon Picking Challenge 2016 や IPAB 創薬コンテスト等で優れた成果を残しています。

PFN はなぜ研究をするのか?

PFN のような企業で、今すぐ直接お金に結びつかないような研究をする意味はあるのでしょうか?例えば、論文を書こうと思えば貴重な業務の時間をごっそりと使ってしまうことになるし、それを出版すれば社外の人たちに技術を教えてしまうことになります。こう考えると、学術的研究や論文執筆は、会社にとってマイナスの活動のようにすら見えます。

実際には、PFN においてそのような研究活動は極めて重要視されており、今後もなお重点的に強化を行っていく予定です。コンピュータや AI 分野のビジネスでは、しばしば「Winner takes all」といったことが言われます。このような領域では、ビジネスに国境がなく、中途半端では生き残ることはできません。世界でトップクラスの技術を持ちリードを保ち続ける必要があります。従って、我々は、研究活動を通じ技術力を中心とした競争力を持ち続けることがビジネス上で極めて重要だと考えています。また、現実的には、優れた特許ポートフォリオを構築するといったことも重要です。

また、「よそから出てくる論文の実用化に注力する方が効率的ではないのか?」という疑問もよく聞きます。しかし、論文が出てきて我々の目に止まるタイミングでは、世界のトップは必ずもっと進んでしまっています。そして、論文を読んで得られる情報はかなり限られており、試行錯誤したり著者に問い合わせながら再現に成功したり、他のデータセットへの適用を通じて論文に書かれていない手法のネガティブな性質について把握したりするのには、さらにかなりの時間がかかります。パーソナルコンピュータの父として知られるアラン・ケイの「未来を予測する最善の方法は、それを発明することだ」という言葉は、実際にいくつかの分野で世界をリードしたりトップに迫ったりといった成果を出すことができている我々にとって、大きな実感があります。

更に、単に社内で研究を行うことだけでなく、成果をコミュニティに発表し還元することも重要視しています。一つには国内外でのプレゼンスを得るという目的もあります。それに加えて、我々の発表した技術に基づいた研究や我々の発表に触発された研究が社外でも行われることにより、トータルで考えて我々に必要な技術の発展が加速されると考えています。そのため、OSS としてソフトウェアを公開したり、研究に使ったコードやデータなども積極的に公開しています。また、アカデミックなコミュニティへ貢献するため、学会や論文誌の査読も業務で行えるようにしています。

どのような研究を推進していくのか?

深層学習を中心として、コンピュータビジョン、自然言語処理、音声認識、ロボティクス、コンパイラ、分散処理、専用ハードウェア、バイオインフォマティクス、ケモインフォマティクスといった、幅広い分野での研究を行っており、これを以下のような理念に基づき強化していきます。

正しくクレイジーに

全ての研究は現在だけでなく未来を見据えて行われるべきです。研究の価値も、今の常識だけで判断するべきではありません。「そんな計算が重い方法は実用的じゃないよ」といったことや「今はそんな処理したい人いないよ」といったことは、必ずしもネガティブではありません。例えば、我々は昨年、1024 台の GPU を用いた分散処理により画像認識モデルを高速に学習するというプロジェクトを成功させ、世界的に大きな注目を集めました。達成した速度が常識外れだっただけでなく、1024 台の GPU を一度に使うと言った実験の規模自体も常識外れでした。1024 台の GPU を使って日常的な学習を行うといったことは現実的ではないかもしれません。それでは、このような研究の価値は無いのでしょうか?

計算機は未だに速くなり続けています。特に、深層学習に関しては、専用チップの開発も盛んです。OpenAI の調査によれば、深層学習の大規模なトレーニングで使われる計算力は、3.5 ヶ月で倍という急速なペースで上がっています。今は馬鹿げた計算力に見えるそのような設定も、数年のうちに当たり前のように使える状況が来る可能性は高いでしょう。未来を見据え、そのような状況では何が起こるのかといったことを知り、そこでの課題を解決したり新たにできることを模索したりといったことに早く乗り出すことは、非常に重要だと考えています。1024 台の GPU を用いた上述の実験はその第一歩であり、プライベートスーパーコンピュータと並列分散計算チームを持つ強みを活かしながら、大規模な実験を促進し、このような規模での実験を当たり前のように感じられるぐらいの環境を作りたいと考えています。

世界とグラウンディングする

全ての研究は何らかの意味で世界の最先端を目指すべきです。技術力は、世界的にリードを持つことにより大きな価値に繋がります。社内だけでなく、積極的に外を向き、論文が世界的に高く評価されたり、世界的なコンペティションで高い順位を取ったり、注目を集め講演に呼ばれたり、といったことを目指すべきだと考えています。実際には、全ての研究プロジェクトで世界をリードするようなことは難しいかもしれません。しかし、世界トップをしっかり意識し目指すことで、自分たちの相対的な位置を知ることができます。

また、世界的なコミュニティに食い込むことも非常に重要です。社外の世界トップを走る人たちと知り合いになり、無視できない存在だと認識してもらうことで、有益な情報の交換ができます。そのためにも、外部発表を推奨しており、貢献をしたメンバーの顔がしっかり外に出るようにしています。

積極的に展開する

全ての研究は小さく閉じこもることなく積極的な展開を目指すべきです。例えば、研究を論文にすることは非常に重要なマイルストーンですが、それは完成ではありませんし、それだけを目標にするべきではありません。深層学習では共通の技術が異なる応用分野を跨がり力を発揮することがあります。PFN には幅広い分野に取り組む人がいるという利点を活かし、研究のスコープを狭く捉えず、人を巻き込み、幅広い展開を目指してほしいです。また、新たなソフトウェアを開発したり社内のソフトウェアにフィードバックしたりして人が利用できる形にすることも可能であれば検討するべきです。社内での実務に成果を還元できれば素晴らしいでしょう。トップ会議への論文採択数は重要視していますが、一方で、論文の本数や論文が採択された会議のランクのみから研究開発活動を評価することはしないつもりです。

もちろん、全てを自分でやる必要はありません。世界のトップレベルに食い込んでいくためには、自分の能力的な強みとモチベーションを存分に発揮することが必要です。従って、自分が持っていない能力は積極的に人に頼ることも検討するべきです。これは技術領域のみでなく、研究のまとめ方に関してもです。せっかく面白い研究開発をやっていても、論文執筆の経験を持たないためどうやって論文にしていいか分からなかったり、誤解が原因で学会投稿で過小評価され採択に繋がらないこともあります。論文の執筆方法や徹底したサーベイ、正しい比較実験の仕方などについて、基礎研究で活躍してきた研究のベテランが社内に多く存在することを活かしていけるようにしたいと考えています。

PFN で研究開発をする魅力は?

リサーチャー・エンジニアとして PFN における研究開発に携わる良さとは何でしょう?

最も魅力的な点の 1 つは、PFN の対象とする深層学習を中心とした技術領域の特徴として、個人及び組織的な卓越した技術力が、本当に必要とされており、非常に重要であるということです。個人としても組織としても技術力の差が成果に反映されやすいという意味で、高い技術力を持つことが高い価値に直接的につながります。個人として高い技術力を持つこと、そしてチームとしてさらなる力を発揮することが非常に高く評価されます。これは、技術力に自信を持つ人や、技術力の向上にモチベーションを持つ人に、とても良いことであると感じます。

取り組み方が非常にフレキシブルな点も魅力だと考えています。100% の時間をピュアな基礎研究に費やすメンバーも今では複数人いてチームも構成しており、増強していく予定です。一方で、実務的な課題にも触れながら研究活動を行っているメンバーも多数います。また、アカデミアとの共同研究も積極的に行われていますし、社会人博士としてパートタイムで大学院に通い専門性を磨くメンバーもいます。

研究開発活動を促進するための社内制度にも気を使っています。会社がメンバーを信頼して大きな裁量を与え、足りない社内制度や資産があればフレキシブルに対応するなど、新しいチャレンジを積極的に支援しています。例えば、20% ルールにより、全てのメンバーは 20% までの時間を自分の裁量で使うことができます。これにより、誰でも思いついたアイディアをすぐに試すことができます。強いモチベーションやユニークなアイディアを持つ取り組みがボトムアップに出てくることを期待しています。

PFN が取り組む深層学習を中心とした技術領域では、アルゴリズムからソフトウェアフレームワーク、研究支援ミドルウェア、そしてハードウェアまで、その全てが重要になってきます。深層学習、強化学習、コンピュータビジョン、自然言語処理、バイオインフォマティクス、高性能計算、分散システム、ネットワーク、ロボティクス、シミュレーション、データ解析、最適化、異常検知といったような幅広い専門を持つ人が社内の近い位置にいて、気軽に情報交換ができる点もとても魅力的だと思います。分からない事柄について教えてもらったり、実務上出てくる問題を交換したり、一緒に研究に取り組んだりすることができます。

終わりに

最後に、少し個人的な抱負を書かせてください。今回、執行役員兼 Chief Research Strategist という身に余る大役を頂戴しました。能力面でもそれ以外でも心から尊敬できるメンバー達が素晴らしいチームとなり活躍しているこの会社で、私なんかにこのような大役が務まるのかという不安もあり、引き受けていいものか迷いました。

私は前職ではアカデミアでの研究者でしたが、企業での研究にも学生時代から興味を持ち、海外の企業研究所でのインターンにも複数回参加していました。その中で一度、インターン期間中にレイオフが起こり、自分のメンターも含めてその研究所に所属していた全研究者が解雇になるという様子を目の当たりにしたことがあります。企業での研究を意義あるものに保つ難しさを実感しました。

そのような経験を踏まえて考えても、私は PFN は企業として研究活動をするべきだと思います。それを健全な状態に保ち価値に繋げるのは決して簡単なことではないと思いますが、そのような部分にもし私の色々な場所での経験や考えを活かして貢献できるのであれば、それは非常に刺激的かつ意義のあることだと感じ、新たなポジションで頑張ってみることにしました。

また、研究とエンジニアリング、深層学習と分散計算など、複数面の得意分野を融合させることのできる自分の強みや、勝ちにこだわり戦略を練り遂行できる自分の強みを、今後はより広範囲で活かしていければと考えています。

PFN では、このような研究開発活動に興味を持ち一緒に取り組んでくれるメンバーをリサーチャー・エンジニアとして募集しています

オープンソースの深層学習フレームワーク Chainer アマゾン ウェブ サービスが公式にサポート

Shingo Omura

2018-06-01 12:02:14

深層学習フレームワークの Chainer は、アマゾン ウェブ サービス(AWS) の協力により、多数の AWS アプリケーションで利用できるようになりました。Chainerは、ニューラルネットワークを簡単に扱える Pythonのフレームワークですが、AWSと組み合わせる事で、マルチ GPU やマルチサーバーにおける Chainer の並外れたスケーリング能力を最大限活用できます。Chainer の非常に優れたスケーリング能力については、ImageNet-1K を利用した ResNet50 の学習を、それまで最速とされた Facebook の記録より4倍速い15分で完了した事により実証済みです。

Chainer のマルチ GPU とマルチサーバーのスケーリングにより、必要時に必要量の計算資源を提供するというクラウドの利点を有効活用できます。Chainer の比類なき並列計算能力と AWS のオンデマンド型クラウド資源を併用すれば、費用を最小限に抑えながら、ハードウェアの制約がある環境下と比べて、非常に短時間で複雑な深層学習モデルの学習が可能になります。

Chainer は、AWS 深層学習 AMI(AMI)ですでに利用可能となっていますが、Chainerが最新の CloudFormation スクリプトをリリースした事により、一度に複数のChainer AMIを容易にデプロイできるようになりました。また、ChainerはAWS上で32 GPUまでのスケーリング効率95%を達成する事を確認済みで、これはニューラルネットワークの学習を最大30倍高速化できる事を意味します。

データの前処理やハイパーパラメータの調整、ならびにニューラルネットワークのデプロイといった作業の簡素化を目的として、Chainer は Amazon SageMaker でもサポートされるようになりました。Amazon SageMaker は、開発者やデータサイエンティストが、機械学習モデルをあらゆる規模で、迅速かつ簡単に構築、トレーニング、デプロイできるようにする完全マネージド型プラットフォームです。SageMaker で Chainer を使用すれば、SageMaker が持つデプロイ上の利点に加え、並列化により速度が向上します。

上記に加えて、Chainer は AWS Greengrass でもサポートされるようになりました。AWS Greengrass は、接続されたデバイスでローカルのコンピューティング、メッセージング、データキャッシュ、同期、ML 推論機能を安全な方法で実行できるようにするソフトウェアです。Amazon SageMaker と組み合わせる事で、SageMaker でのモデル学習時や、AWS Greengrass でIoTデバイスへ直接デプロイする際に、Chainer の利便性とスピードを活用できます。

Chainer チームは AWS による今回のリリースを大変うれしく思うと同時に、進化し続ける深層学習技術のさらなる発展に貢献する事を目指します。