Singularityで分散深層学習
- 1. Singulairtyで分散深層学習 産業技術総合研究所 ⼈⼯知能研究センター ⼈⼯知能クラウド研究チーム 佐藤 仁 第⼀回 Singularity勉強会 2018年1⽉10⽇ 1
- 2. Singularityとの出会い 2 早朝着 深夜便発 某社 某社 某社 2016年12⽉のある⽇，ベイエリアにて
- 3. ⼈⼯知能技術の発展には アルゴリズム×ビッグデータ×計算基盤 の⼀体的な進展が不可⽋ 3 ビッグデータ アルゴリズム 計算基盤 深層学習, 機械学習, etc. クラウド, スパコン, etc. 研究開発・実証・橋渡しを⾒据えたAIプラットフォームの構築・展開
- 4. 4 NEDOプロ(NAIROBI) ⼈⼯知能研究開発・実証 のための研究テストベッド H28.6運⽤開始 産総研AIクラウド(AAIC) 産総研と連携機関による ⼈⼯知能実証のための 共⽤プラットフォーム H29.6運⽤開始 AI橋渡しクラウド(ABCI) ⾼密度・省エネ構成 運⽤技術・ノウハウ うまくいった成果を ⼤規模実証 複数の産学官による オープンイノベーション プラットフォーム 最初からIDCへの技術移 転を⾒越した設計・運⽤ H30.3納⼊（予定） IDCなどに 商⽤展開 AIRCの計算基盤ロードマップ グリーンITプロ 実サービス化 NVIDIA Tesla M40 x 32 NVIDIA Tesla P100 x 400 w/ IB NVIDIA Tesla V100 たくさん w/ IB
- 5. 5 産総研AIクラウド（通称AAIC）とは？ • 400x NVIDIA Tesla P100s and Infiniband EDR accelerate various AI workloads including ML (Machine Learning) and DL (Deep Learning). • Advanced data analytics leveraged by 4PiB shared Big Data Storage and Apache Spark w/ its ecosystem. AI Computation System Large Capacity Storage System Computation Nodes (w/GPU) x50 • Intel Xeon E5 v4 x2 • NVIDIA Tesla P100 (NVLink) x8 • 256GiB Memory, 480GB SSD Computation Nodes (w/o GPU) x68 • Intel Xeon E5 v4 x2 • 256GiB Memory, 480GB SSD Mgmt & Service Nodes x16 Interactive Nodes x2 400 Pascal GPUs 30TB Memory 56TB SSD DDN SFA14K • File server (w/10GbEx2, IB EDRx4) x4 • 8TB 7.2Krpm NL-SAS HDD x730 • GRIDScaler (GPFS) Computation Network Mellanox CS7520 Director Switch • EDR (100Gbps) x216 Bi-direction 200Gbps Full bi-section bandwidth Service and Management Network IB EDR (100Gbps) IB EDR (100Gbps) GbE or 10GbE GbE or 10GbE Firewall • FortiGate 3815D x2 • FortiAnalyzer 1000E x2 UTM Firewall 40-100Gbps class 10GbE SINET5 Internet Connection 10-100GbE >4PiB effective RW100GB/s 既存のGPUスパコン に類似した構成
- 6. GPU計算ノードの構成 • NVIDIA TESLA P100 x 8 • Intel Xeon E5-2630 v4 x 2 ソケット – ソケットあたり10コア – Hyper Threading (HT) で動作 – ノードあたり40コアにみえる • 256GiBのメモリ • 480GBのSSD • EDR Infiniband – 計算ノード – GPFSストレージへ接続 6 Machine (256GB total) NUMANode P#0 (128GB) Package P#0 L3 (25MB) L2 (256KB) L1d (32KB) L1i (32KB) Core P#0 PU P#0 PU P#20 L2 (256KB) L1d (32KB) L1i (32KB) Core P#1 PU P#1 PU P#21 L2 (256KB) L1d (32KB) L1i (32KB) Core P#2 PU P#2 PU P#22 L2 (256KB) L1d (32KB) L1i (32KB) Core P#3 PU P#3 PU P#23 L2 (256KB) L1d (32KB) L1i (32KB) Core P#4 PU P#4 PU P#24 L2 (256KB) L1d (32KB) L1i (32KB) Core P#8 PU P#5 PU P#25 L2 (256KB) L1d (32KB) L1i (32KB) Core P#9 PU P#6 PU P#26 L2 (256KB) L1d (32KB) L1i (32KB) Core P#10 PU P#7 PU P#27 L2 (256KB) L1d (32KB) L1i (32KB) Core P#11 PU P#8 PU P#28 L2 (256KB) L1d (32KB) L1i (32KB) Core P#12 PU P#9 PU P#29 PCI 10de:15f9 card1 renderD128 PCI 10de:15f9 card2 renderD129 PCI 10de:15f9 card3 renderD130 PCI 10de:15f9 card4 renderD131 PCI 8086:8d62 sda PCI 1a03:2000 card0 controlD64 PCI 8086:8d02 NUMANode P#1 (128GB) Package P#1 L3 (25MB) L2 (256KB) L1d (32KB) L1i (32KB) Core P#0 PU P#10 PU P#30 L2 (256KB) L1d (32KB) L1i (32KB) Core P#1 PU P#11 PU P#31 L2 (256KB) L1d (32KB) L1i (32KB) Core P#2 PU P#12 PU P#32 L2 (256KB) L1d (32KB) L1i (32KB) Core P#3 PU P#13 PU P#33 L2 (256KB) L1d (32KB) L1i (32KB) Core P#4 PU P#14 PU P#34 L2 (256KB) L1d (32KB) L1i (32KB) Core P#8 PU P#15 PU P#35 L2 (256KB) L1d (32KB) L1i (32KB) Core P#9 PU P#16 PU P#36 L2 (256KB) L1d (32KB) L1i (32KB) Core P#10 PU P#17 PU P#37 L2 (256KB) L1d (32KB) L1i (32KB) Core P#11 PU P#18 PU P#38 L2 (256KB) L1d (32KB) L1i (32KB) Core P#12 PU P#19 PU P#39 PCI 8086:1528 enp129s0f0 PCI 8086:1528 enp129s0f1 PCI 10de:15f9 card5 renderD132 PCI 10de:15f9 card6 renderD133 PCI 10de:15f9 card7 renderD134 PCI 10de:15f9 card8 renderD135 PCI 15b3:1013 ib0 mlx5_0 Indexes: physical Date: Tue May 30 11:32:43 2017 MEM CPU Cores GPUs Infiniband HBA SSD
- 7. 現状のAIクラウドの利⽤法（≒ スパコンの利⽤法） • ジョブスケジューラの存在 – スクリプトファイルの作成 – ジョブの投⼊ • ユーザ権限でのプログラム実⾏ – システムに予めインストールされた ソフトウェアの利⽤ • GPUランタイム・ライブラリCUDA, CuDNN, NCCL • 並列分散処理ソフトウェア（MPI） • 共有ストレージの利⽤ – 複数ユーザで共有された並列ファイルシステム 7 /home (GPFS) Job Job Job Job NQS Submit Scheduling script file $ qsub <option> script_filename inter-connect SSH ( )
- 8. AIアプリケーションの事例 • lang2program – https://github.com/kelvinguu/ lang2program – ACL 2017 paper内で⽤いられた実装 – Dockerfileの提供 • Tensorflow, PostgresQL, Python pip Packages, etc. • 依存関係のあるソフトウェアの インストールが⼤量に発⽣ 8 HPC環境（スパコン）で動くか？ • Dockerの⾮サポート （セキュリティ上ホストのrootを与えることができない） • マニュアルにインストールすれば可能だが煩雑
- 9. HPCコンテナのいろいろ (SCやISCなどHPCコンテナのBoFが年々増えている） 9 • 今⽇のテーマ なので後述 • NERSCで開発(Cori) • CSCSで拡張(Piz Diant) • Singulairtyと同様の技術 • ImageGatewayの存在 • Crayのサポート • Slurm連携 • LANLで開発 • Singularityと同様の 技術？ • SC17 Paper • ソースコードが少ない
- 10. Singularity (ソフトウェアの名称です） • Singularity – ⽶国LBNLで開発中のHPC向けLinuxコンテナ • http://singularity.lbl.gov/ • https://github.com/singularityware/singularity • 修正BSDライセンス – ユーザ権限でプログラムを実⾏、ストレージへアクセス • rootで動作するデーモンが不要 => 資源管理をスケジューラに委ねる • setuidでroot権限を与えたコマンドを実⾏ （マウント、名前空間の作成、コンテナ内へのホストのPathのʼ作成など） – Dockerイメージが利⽤可能 • DockerHubと連携 – HPC系のソフトウェアスタックが利⽤可能 • CUDA, MPI, Infiniband, etc. 10
- 11. Singularityの利⽤イメージ sudo singularity build –sandbox tmpdir/ Singularity sudo singularity build –writable container.img Singularity sudo singularity build container.img Singularity sudo singularity build container.img docker://ubuntu sudo singularity build container.img shub://ubuntu Sandboxディレクトリの⽣成 コンテナイメージファイルの⽣成 sudo singularity shell –writable container.img パッケージソフトウェアを インストール(yum, apt等) Recipeファイルの利⽤ DockerHubの利⽤ (Dockerコンテナイメージ) SingularityHubの利⽤（Singularityコンテナイメージ） container.img コンテナイメージ ファイルを転送 インタラクティブにコンテナイメージを作成 既存のコンテナイメージを利⽤して作成 予め定めた⼿順によりコンテナイメージを作成 singularity run container.img singularity exec container.img … singularity shell container.img シェルを実⾏(shell) コマンドを与えて実⾏ (exec) 予め定義された動作を 実⾏(run) ユーザ環境 共有計算機環境 11
- 12. Singularityのインストール • $ ./configure –-prefix=/path/to/install • $ make • # make install 共⽤計算機環境的にはインストールが容易でリーズナブル → ただし，root権限でのインストールが必要 12
- 13. Singularityでできること • GPU, Infiniband, XXXが利⽤できるか？ – ホスト側のデバイス関連ドライバ・ライブラリをコンテナ側 へみせる（nvidia-docker⽅式？） • MPIが利⽤できるか？ – ホストのMPIをコンテナ側へみせる（コンテナなメリットが薄い） – コンテナ内にMPIをインストールし、コンテナの外からキックする （ホスト側と同じMPIを使⽤し, Buildも同じにする必要） • mpirun –np N singularity exec container.img mpi_program • mpi4pyが利⽤できるか？ – コンテナ内にMPIをインストール – コンテナ内のMPIに対してmpi4pyをインストール – コンテナ外からキック 13
- 14. 分散深層学習フレームワーク向けコンテナイメージの構築 • ホスト側 – GPUやIninibandを活⽤するために デバイス関連ドライバ・ライブラリを コンテナ側へマウント • GPUやIninibandの利⽤ • nvidia-docker⽅式 • コンテナ側 – ユーザランドライブラリの インストール • CUDA, CuDNN, NCCL2, ibverbs, MPI – 分散深層学習フレームワークの インストール • 最適化されたビルド 14 Base Drivers, Libraries on Host CUDA Drivers Infiniband Drivers Filesystem Libraries (GPFS, Lustre) Userland Libraries on Container CUDA CuDNN NCCL2 MPI (mpi4py) Mount ibverbs Distributed Deep Learning Frameworks Caffe2 ChainerMNDistributed TensorflowMXNet
- 15. Singularityの利⽤イメージ (最も簡単バージョン） • 事前にDockerHubにアップロードされたDockerイメージ を利⽤ • $ singularity build container.img ¥ docker://nvidia/cuda:8.0-cudnn6-devel • $ singulairty exec --nv container.img nvidia-smi 15 GPUを有効にするには--nvををつける！
- 16. --nvオプションで起きること(v2.4) • libexec/cli/action_argparser.shを参照 – NVIDIAのホストのライブラリのリストを取得 (SINGULAIRTY_NVLIBLIST) – SINGULARITY_CONTAINLIBSに上記リストを追加 – コンテナ起動時 • SINGULARITY_CONTAINLIBSに記述されたリストが /.singularity/libs以下にマウントされる • LD_LIBRARY_PATHに/.singularity/libsが追加される 16 • 原理的には同様のことをすればInfinibandでもOPAでもできる • SingularityのGPU利⽤⽅法はOn Goingで進⾏中
- 17. /etc/singularity/init • Singularityの起動時に呼ばれる（スクリプト） – exec, shell, run • 起動時に実⾏したいコマンドを記載 – SINGULARITY_CONTAINLIBSに必要なライブラリの リストを代⼊ – export SINGULARITY_CONTAINLIBS 17
- 18. Singularityの利⽤イメージ (MPI) • $ mpirun –np N singularity exec container.img ¥ mpi_program • ただし、 – コンテナ内: container.imgのイメージ作成時に MPIをインストールする必要がある – コンテナ外: コンテナ内のMPIとバージョンやconfigureを ⼀致させる必要（な場合がある） • ABIの互換性のサポートがすすめば緩和されるはず • OpenMPI v3.0では--singularityオプションあり， MVAPICHでもサポートの意向 18
- 20. あとは適当に分散深層学習のイメージをつくればよい • 例えば、ChainerMNだと – $ pip install mpi4py – $ pip install --no-cache-dir cython matplotlib Pillow – $ pip install --no-cache-dir chainer chainermn • ノウハウ的にはDockerfileで作成しておいたほうが汎⽤？ – Singularityが安定していないことがある – GPUのサポート 20
- 21. Singularityを⽤いた分散深層学習フレームワークの実⾏ • 実験環境 – AAIC 8 nodes (64 GPUs) – フレームワーク: CHainerMN v1.0.0 • Chainer 2.1.0, Cupy 1.0.3, mpi4py 2.0.0, Python 3.6.1 – コンテナ • Singularity v2.3.1 • Ubuntu 16.04, gcc-5.4.0, glibc-2.23 – ベアメタル • CentOS 7.3, gcc-4.8.5, glibc-2.17, • 実験設定 – データセット: Imagenet-1K – モデル: ResNet-50 – 訓練: • バッチサイズ: GPU毎に32, 32 x 64 • 学習率: 30 epoch毎に0.1倍 • 最適化: Momentum SGD (momentum=0.9) • Weight Decay: 0.0001 • 訓練エポック数: 100 21 ベアメタル実⾏とほぼ遜⾊のない性能を確認 Better
- 24. 通信性能(OSU Micro Benchmarks v5.3.2) AllReduce (Ave. Latency, 2nodes, 8gpus/node) AllReduce(h2h) AllReduce(d2d) 24 Better
- 26. ストレージI/O性能(FIO v2.19) IOPS (qdepth=1, 16) READ WRITE 26 Better
- 27. 議論 • Singularity – ベアメタルと⽐較してほぼ遜⾊のない性能を確認 • 演算性能だけでなく、メモリバンド幅、ストレージI/O, ネットワーク性能（要確認）も • メモリのフットプリントは未確認 – OSの違いを超えられる（CentOS vs. Ubuntu) • 特に、glibcのバージョンの違いも容易に超えられる （glibcが互換性を担保するような実装になっている） – 導⼊しやすさ • configure, make, make installで可能。共有ストレージへも可能。 – あとはエンジニアリングイシュー • ソフトウェアの安定性の向上 • セキュリティイシューを潰す 27
- 28. 議論 (contʼd) • Singularityの⽋点 – コンテナ内常駐デーモン不可? – Debug系(gdb)不可？ – 資源管理は(cgroupsではなく)スケジューラまかせ → v2.4からinstanceコマンドが導⼊されたので何か変わった かも 28
- 29. 議論 (contʼd) • ユーザが任意のコンテナを動かして問題が起きるか？ – 特に問題がないと判断している（問題を定義したい） – 基本的には実⾏するユーザの責任 （現状でも任意のソフトウェアをユーザが動かしているので ほぼ同じ問題） • 特殊なコンテナが必要？制限はある？ – 基本的には不要。ARMでもOPAでも(Linuxであれば)動く。 – ただし、計算環境に最適化するためには再コンパイルなどした⽅が良い。 • ISVアプリのライセンス – コンテナに含めるのは難しい（気がする） – ユーザ権限でホストの環境をコンテナ側にreadマウントすることはできる – ホストにISVアプリをインストール、コンテナ側にマウント？ 29
- 30. まとめ • lang2program – https://github.com/kelvinguu/ lang2program – ACL 2017 paper内で⽤いられた実装 – Dockerfileの提供 • Tensorflow, PostgresQL, Python pip Packages, etc. • 依存関係のあるソフトウェアの インストールが⼤量に発⽣ 30 どうやったらSingularityで動かせるでしょうか？ → ⾃分で動かせたらだいたいOK
- 31. • 所内向けにはSingularityなどの レクチャなどもやってます！ – Jupyter Notebookベース 31