分析基盤トーク#01 Preferred Networks 谷脇大輔「PFNの研究基盤」

1. 2018/07/23 分析基盤トーク #1
谷脇 大輔 @dtaniwaki
PFNの研究基盤
1

2. 自己紹介
2
@dtaniwaki
谷脇 大輔 / Daisuke Taniwaki
業務
社内で運用している機械学習向けクラスターやツールの開発・運用
経歴
2008~2012 台湾トレンドマイクロでWebクローラの開発
2012~2014 ニューヨークで食べログのアメリカ版の立ち上げ
2014~2017 Kaizen PlatformにてWeb Page Optimization Platformの開発
2017~現在 Preferred Networks
言語
日本語、英語、中国語
Ruby, JavaScript, C++ → Python, Scala

3. 本日の流れ
- Preferred Networksについて
- Chainer/ChainerMNについて
- 自社クラスターMN1について
- 研究基盤について
- 今後の課題
- Q & A
3

4. Preferred Networks 会社概要
• 略してPFN
• ミッション
• 設立 2014年3月
• 所在地: 東京都千代田区大手町(日本), バークレー(米国)
• 事業内容: IoT x (Distributed) Machine Learning
– 交通システム
– 産業用ロボット
– バイオヘルスケア
4
IoT時代に向けた新しいコンピュータを創造する
あらゆるモノに知能をもたせ分散知能を実現する

5. • PFNが開発しているPython 製の深層学習向けフレームワーク
• 深層学習に必要な計算 (微分および誤差逆伝播) を自動で行う
• numpy互換のCUDA行列計算ライブラリ CuPy を利用可能
• Define-By-Run という概念の Pioneer
Define-and-Run Define-by-Run
5
Chainerについて

6. ChainerMNについて
- 分散深層学習に必要な機能を実装したChainerの追加パッケージ
- 特徴
- 高速 NVIDIA NCCL, CUDA-Aware MPI等の最新技術の活用により高い性能を実現
- 柔軟 Chainerの柔軟性を損なわず、動的なネットワークでも分散学習可能
- 簡単 既存のコードを少し変更すれば利用可能
6
高速通信のできるInfiniBandで最大の効果

7. ChainerMNの性能
- ノード数に比例してほぼ線形に高速化
- ChainerMN による分散深層学習の性能について
7

8. 8
自社クラスター
MN1について

9. MN1とは
- Mizuki Nana 1
- PFNがNTT Communications / NTT PC Communications
と開発したGPUクラスター
9

10. MN1構成
10
Total: 1024 GPUs (NVIDIA Tesla P100)
8 GPUs x 16 Servers
x 2 Infiniband Switches
56Gbps (FDR)
credits:
gpu by Misha Petrishchev from the Noun Project
Network Switch by Creaticca Creative Agency from the Noun Project

11. MN1の性能評価
- LINPACK Benchmark (2017/11)
- Preferred Networksのプライベート・スーパーコンピュータが Top 500リス
トのIndustry領域で国内
１位に認定
- Training ResNet-50 on ImageNet in 15 min (2017/11)
- 深層学習の学習速度において世界最速を実現
11

12. 12
研究基盤について

13. PFNならではの要件
- 計算資源がオンプレ
- ユーザ・プロジェクトごとに実験環境が多様
- 利用者のリテラシーが多様
- 医者、数学者、物理学者などなど
- リソースを占有して利用したい
- パフォーマンスが急に変わると原因の特定が困難
- 再実行性(Repeatability)の担保が重要
- ChainerMN利用にマルチノード間連携が必要
- Hadoop/SparkのようなBig Data Processingが難しい
- データセットを毎回シャッフルするため
13

14. 14
第１世代

15. 第１世代
15
スプレッドシート運用

16. 導入理由
- 導入コストほぼゼロ
16Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

17. 問題点
- 短時間の利用の管理が難しい
- ユーザ数、ノード数が増えると管理が大変
- 実際の利用状況との整合性が取れない
- サーバのアップデートをすると利用者全員に影響
17Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

18. 18
第２世代

19. 第２世代
19
Mesosベースの内製ジョブスケジューラ
Scheduler
datasets
results
Job queue
Execute command job
Build environment job
Retz
datasets
/results

20. 内製ジョブスケジューラの特徴
- 実行環境自動生成
- 再実行性(reproducibility)の担保
- データセット管理
- 実験管理（コマンド・ソースコード）
- 実行環境（Docker Image）管理
- データセット、結果の共有
- マルチノードジョブの実行
20

21. Mesos導入理由
- Containerizerにより環境の隔離ができる
- GPUをサポート
- フレームワークの自由度が高い
21

22. 問題点
- 内製ジョブスケジューラ
- 想定された使い方しかできない
- インタラクティブな利用（デバッグ等）ができない
- スケジューラ障害時にクラスターが一切使えなくなる
- Mesos
- フレームワークなしでは使えない
- Webに情報が少ない
- デファクトな良いジョブスケジューラがない
- 認証・認可はDC/OS Enterpriseが必要
22Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

23. 23
第３世代（現在）

24. 第３世代（現在）
24
Kubernetesの導入
Scheduler shell job

25. Kubernetes導入理由
- ジョブスケジューリングやマルチノードジョブ連携に必要なコ
ンポーネントが揃っている
- RBACやPSPなど権限管理が充実
- Namespaceにより提供するサービスを論理的に分離しつつ
リソースは共有できる
- ネット上に情報が多い
- CRDやSchedulerなど拡張性が高い
25Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

26. PFNならではの工夫
- InifiniBandのHost Deviceをコンテナに見せる
- https://github.com/everpeace/k8s-host-device-plugin
- ユーザ毎、プロジェクト毎にNamespaceを分離
- UIDマッピングによりNFSマウントしたデータをLinuxのユー
ザグループでアクセス
- 長時間のジョブはプリエンプション対象にする
- グランドチャレンジ時にはジョブ一斉退避
26Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

27. Kubeflowの可能性
- PFNでは扱うケースが多様で、前処理や後処理は統一的な仕組みを強制する
のが難しい
- Kubeflowが連携する個々のツールは選択的に利用
- Pachyderm, Kaniko, Katib, Argoなど
- Chainer Operatorを開発中
27
ここ以外は統一
できなそう
Kubeflow Composability

28. 今後の課題
- 効率的なスケジューリング
- ギャングスケジューリング
- ビンパッキング
- 効率的なプリエンプション
- ネットワーク、Busトポロジーの考慮
- GPU V100 512基追加でヘテロジーニアス環境
- 最新のNVIDIA Tesla V100 32GB GPUを採用した プライベート・スーパー
コンピュータ「MN-1b」を7月に稼働
- 巨大なデータセットの管理
28Icons made by Roundicons from www.flaticon.com is licensed by CC 3.0 BY

29. 29
We’re hiring!!
効率的な研究者向けクラスター管理システムを
一緒に構築してくれる仲間を募集中です！

30. 30
Appendix

31. 31
Define-and-RunとDefine-by-Run
f g x f g
① 計算グラフ構築 ② データフィード
x yf
x = chainer.Variable(...)
y = f(x)
z = g(x)
zg
① データフィード= 計算グラフ構築
Define-and-Run
Define-by-Run

32. Define-by-Runの利点
32
# 構築
x = Variable(‘x’)
y = Variable(‘y’)
z = x + 2 * y
# 評価
for xi, yi in data:
eval(z, (xi, yi))
# 構築と評価が同時
for xi, yi in data:
x = Variable(xi)
y = Variable(yi)
z = x + 2 * y
データを見てから違う処理をする、
といったことがやりやすい
Define-and-RunDefine-by-Run
事前にネッ
トワークを構
築してしまう
のでデータ
に依存して
構造を変え
るのが難し
い

33. Define-by-Runの利点
33
Recurrent Net Recursive Net
• Define-and-Runでは、データごとに挙動の変わるノードを定義したり、あり得る計算グラフを事前
に全部作っておく、など複雑もしくは制約の多い方法を取らざるをえない
• Define-by-Runでは、RecurrentならPythonのforループを、Recursiveは再帰呼出しを使って、非
常に直感的かつシンプルに記述できる

34. 34
Chainer の追加パッケージ
ChainerMN: 分散深層学習用追加パッケージ
高いスケーラビリティ（128GPUで100倍の高速化）
ChainerRL: 深層強化学習ライブラリ
DQN, DDPG, A3C, ACER, NSQ, PCL, etc. OpenAI Gym サポート
ChainerCV: 画像認識アルゴリズム・データセットラッパーを提供
Faster R-CNN, Single Shot Multibox Detector (SSD), SegNet, etc.
MN
RL
CV
分散学習
強化学習
画像認識