gtc_japan_2017.md

Gtc JAPAN 2017

Volta Architecture Deep Drive

• Volta はPascal に続くNVのGPU アーキテクチャであり、コア名としてはGV100。

  • 車載向けがXavier
  • GPUコンピューティング向けボードがTesla V100

• GV100 のスペック

  • 5120個のCUDA
  • FP32時で15TFLOPS
  • DL向けFP16では120TFLOPS

• Tesla V100

  • HBM2 memory

  • MPS

  • SIMT Model の拡張

  • TensorCore 125

  • DLとHPC両方に最適化対応している

  • DL、トレーニングはP100比で2.4倍、インファレンスが3.7倍

    • HPCは1.5倍

  • HPC米国SUMMIT,FP16で計算すれば3エクサ

    • HPC もAIを多用してきている

  • トランジスタ数21B

  • 640TensorCore

  • 5120CUDACore

  • HBM 900GB/s DRAMの実効バンド幅の95%まで来た

  • TensorCoreを使うことでトレーニング125TOPS（P100 10TOPS)

  • これら総合して、演算ボトルネックでもバンド幅ボトルネックでも 大きく性能が向上する

  • NVLINK

    • 4→６へ増加
    • トータルで300GB/s

  • Volta(GV100) SM

    • FP32 64

    • FP64 32

    • INT32 64

    • TensorCore 8

    • 命令セットの一新、実際には見えない

    • 生産性の向上、直感的にプログラムを書いても性能が上がる

    • スケジューラは２倍？で命令発行をシンプルに→消費電力低減

    • TensorCore によるテンソル計算の加速 * 混合制度行列計算ユニット * ４＊４の積和演算を１サイクルで実施 * 入力はFP１６*２ → FP32で加算 →FP32 を繰り返し

        * 出力はFP16
        * 16*16の行列演算をWarpレベルで強調事項
        * ３２スレッドが動いている中で同期をとって、Tensorコアで演算
        ３２スレッドを再開
        
        * ３２スレッドのレジスタを使って演算ができる
          * fragment
            * これによりレジスタ
        * DLをターゲットにしている。
            * cuBLAS、cuDNN等で使える
        * cuBLAS
          * Pascal でのFP32 と比較するとVolta TensorCoreは９倍
          * Volta でのFP32 と比較するとVolta TensorCoreは６倍
          * 計算精度
            * FP32を正解とした場合、TensorCoreは誤差範囲が1%程度、FP16は10%
      
        * cuDNN
          * CNNの性能的にはPascalでは4-5倍高速化
      

    • SIMT Independent thread scheduling

      • Pascalまでは３２個のスレッドがWarp（３２スレッド）でPCやStackを共有
        • これは悪いことではない。これにより効率化。
        • ただし、分岐がある場合、片方のパスが終了してからもう一方を実行
          • そのためパス間の動機が取れない。
        • つまり、LockFreeのアルごリズムでは
      • Voltaでは３２スレッドそれぞれがStackとPCを持つ
        • これにより分岐したバス間で同期が可能
      • まとめるとGPUでタスク並列のプログラムがかなり（LockFree不要）書きやすくなった

  • L1キャッシュ

    • Pで共有メモリとL1キャッシュを分けたが、これをVoltaで統合（もとに戻した）
      • ４倍のバンド幅、５倍の容量のL1キャッシュ
      • 共有メモリの使用は難しいため、使わずにL1キャッシュでプログラミングできるようにする
        • Pではチューニング済みに対して７０％近い性能だったが、Vだと90%近く出る

  • L2キャッシュ

    • 4MB→6MBになった
      • ATOMICSのアクセス性能が２倍に

  • スケジューラ

    • SMごとのWarpスケジューラを２→４

      • １個のスケジューラにディスパッチャが２個

      • 各ディスパッチャーが１６CUDAコア担当

      • GV100 では、、

        • FP32の命令とINTの命令を同時発行
        • アドレス演算でINTを使い、FP32で演算

      • ああ、この話難しい

  • SMの外の話

    • Unified Memory
      • ユーザーがCPUとGPUのどちらにデータが有るかを意識しないように
      • ページの同期をするのでただし性能は落ちる。
      • VOLTAではアクセスカウンタを導入し最適化
      • Kernel4.14からはmallocでUnifiedMemoryを確保できる
      • C++のテンプレート内ではmallocを書き換えられないので効果的

  • GPU上のマルチプロセススケジューリング

    • 時分割スケジューリング
      • Pでは使い切れない、利用率が低い
    • マルチ・プロセスサービル
      • PではMPSが導入されている
      • GPUを分割使用
      • メモリ保護が×
      • Vではハードウェアメモリ保護
      • インファレンスで大きな効果、レスポンスタイムが必要なので
        • ある程度コアを埋められる

CUDA 9

• VOLTAに対応

  • 前回セッションの内容参照
  • スケジューリング変更により同期関数を多数導入
    • スレッド同期
    • アクティブスレッドの取得
    • スレッド感の同期
  • 分岐後の３２スレッド同期はPまでは暗黙でOKだったが、Vでは危険
  • これまでの暗黙OKが崩れている

• ライブラリの高速化

  • cuBLAS(DL向け）
    • GEMMS性能改善（CUDA8-＞CUDA9)
      • FP32で1.8倍、ハード（P→V）は1.5倍
    • 18種類のアルゴリズムから選択可能、Tensorコアも3種類から
  • NPP(画像処理）
    • IPPとくらべて100倍
  • cuFFT（信号処理）
    • CUDA8と比較し最大で2倍高速化
  • cuSolver
    • ヤコビ法ベースの固有値ソルバー
    • 行列サイズ256まではIntelよりは速い
  • CUTLASS
    • CUDAの様々な階層から呼べる行列積C++テンプレート、DLアプリに向いている
      • デバイスレベル、ブロックレベル、ワープレベル、スレッドレベル
    • cuBLAS と遜色のないレベルの性能をC++ CUDAで実現できている

• COOPERATIVE GROUPS

  • Keplarから使用可能
  • 協調動作するスレッドグループの定義分割同期を容易にする
  • スレッドブロック内でのスレッドグループ動的生成
  • SM間の同期（シングルGPUない）
  • GPU間での同期
  • 非常に高い抽象度を用いてライブラリの再利用を促進
  • Coalesced Group
    • 同時に同じパスを実行しているスレッドのグループを取得できる
    • このグループに対してShaffle等を発行できる
  • Grid Group、MultiGrid Group
    • 省略

• 開発ツールの改善

  • VisualProfiler
  • NVPROF
  • GPU LIBRARY ADVISOR
  • CUDA MEMCHECK
    • Raceチェック
  • NVVP:Unified Memoryプロファイリング
  • NVVP:NVLINKトポロジー
    • コンパイラツール

AWS

• AWSでは次のようなMLサービスを追加した

  • SageMaker
    • Setupless
    • TensorFlow
    • 秒単位課金
  • AWS DeepLens
    • Cameraでのトレーニングを行う
    • TensorFlow Caffe等が利用可能 *Aamazon Rekognition VIdeo
    • 物体検出
    • 人間追跡
    • 物体の裏に隠れてもトレースできる
  • Amazon Transcribe、Translate
    • 音声認識、リアルタイム翻訳byDL 12言語ペア
  • Amazon Comprehend 自然言語処理
    • 感情、登場人、キーフレーズ、トピックモデリング by DL

• 歴史

  • LeNET
  • AlexNet
  • And more....
  • コンピューテーションパワーが必要

• EC2 P3 Instance

  • TRIも利用
  • １PFLOPS
  • V100 GPU
  • NVLiNKが利用可能

• DeppLearning AMI

  • TensorFlow
  • ｍｘｎｅｔ
  • Caffe2

• Mapillary

  • ユーザー投稿画像のマッピング
  • AWSを利用している

• Gluon

  • MXNet、CNTK対応
  • 高性能
  • 柔軟なNN作成
  • MSとの共同開発
  • 動的グラフ生成

• ONNX:OpenNeaural network exchange

  • can choose the framework that best fits their needs
  • MXNet の性能が高い
  • MXNet でのデモ
  • m4nb-instance.notebook.us-west-2.sagemaker.aws

• AMazon ML LAb

Chainer

• 2015年6月に公開。世のDL研究の加速のため

• コンセプト

  • 高い自由度と直感的な記述
  • 十分に高速に実行できる
  • 容易にデバッグできる

• 最初は4人現在は数十人が関わっている

• theano：Lua

• Caffe：CNNは良い、他は×

• TensorFlowは2015年夏

• DL研究者がすること（◎がFWがサポートするところ）

  • ネットワークを考案（畳み込みNNとか、それをどう組み合わせるのか）
  • ◎コンピュータが読める形に落とし込む（プログラム、設定ファイルなど）
  • データを用意
  • ◎最適化もんだとして解く

• DL研究開発のボトルネック

  • データ・セットを作ること
  • いかにかんたんに実験が行えること（これをFWが支えている）

• DL FWのやるべきこと（◎がCHainerの強み）

  • ◎複雑なモデルをかんたんに記述するにはどうすればよいか
  • ◎定義の間違いを防ぐにはどうすればよいか
  • ◎デバッグを行えること
  • 自動微分（誤差逆伝搬）と最適化ルーチンを提供
  • 高速化・省メモリの実現

• 計算グラフの作成戦略

  • define-and-run ネットワークの定義を書くステップと計算実行の2ステップを分ける
    • 大体みんなこれTensorFlowも
  • define-by-run 計算実行のコード自体がネットワーク定義を兼ねる
    • Chainer,PyTorchなど

#define-and-run

teigi

x = Variable('x') y = Variable('x') w = PrintNode(w) # For Debug z = x + 2 * y

keisan

for xi, yi in data: eval(z, (xi,yi))

#define-by-run for xi, yi in data: x=Variable(xi) y=Variable(yi) print(w) # for debug z=x+2*y

• define-by-runによって生産性向上

• スタック Chainer CuPy ←使っている

• CuPyはNumPy互換の行列計算ライブラリ

  • NumPyの命令をGPUで実行できる
  • バグまで忠実に再現
  • 新しいライブラリの習得が不要

• 最近のFWの潮流はdefine-by-runを取り込む方向

  • PytorchはChainer をforkしてバックエンドをtorchに
  • TensorFlow はEager-modeでdefine-by-run
  • Gluon はMXNETを使ったdefine-by-run

• 深層学習自体のトレンド

  • データの大規模化のための分散学習
    • ChainerMN
      • ChainerはPythonだが、実行速度は速い。TensorFlowとかよりも。最速はMXNent
      • CUDA/cuDNN が典型的な実装をカバーしてきたため、速度はそこで担保
        • 他FWとの差が出にくくなっている
      • そこで分散実行
      • 複数GPUはNVLINK、 InfiniBandを使ったノード間接続上でMPI（まじか）
      • スケーラビリティはChainerMNは128GPUまでスケール
        • 学習速度も大幅に向上、精度も大幅向上
      • GPU,ノード間通信はC++でチューニング
      • P100*1024 を購入（MN-1）TOP500ランクイン
        • HPCのチューニング領域に入ってきている
      • Azure上でINFINIBAND環境あり！128GPUで同様の結果を得た
      • 今後は分散学習のコモディティ化が進む（Hadoopのように）
  • 複雑な手法をサポートする高レベルライブラリ
    • 深層学習の課題は、組合せの領域に（画像＋言語、画像＋強化学習など）
    • DLはベクトルデータなので、組み合わせを行いやすい
    • 例えば言葉を理解してピッキングするロボット、数年前までは専門家が必要
    • より複雑な内容がFWに求められる
      • ChainerRL ：強化学習（AlphaGO、試行錯誤でデータを作り出しながら）
      • ChainerCV ：画像認識（物体検知、セグメンテーション、画像分類）
      • ChainerUI ：学習結果の可視化、管理
    • 実験管理・デバッグのしやすさまで意識が必要
  • ユースケースに合わせた多様な実行環境
    • 音声認識：各社のエンジンにすでに搭載されている
    • 画像認識：実用化段階、一部サービス裏では使用中
    • 自然言語処理：機械翻訳（Googleは裏はAIのみ）、一部は実用化
    • ハードル
      • 利用シーンの違い、運用コストの違い、消費電力の違い
    • ONNX（OpenNeauralNetworkExchange）
      • 標準形式の策定
      • Caffe2、MXNet、PyTorch、CHainer、CognitiveToolkit
      • Chainerで学習した結果を他の環境（組み込みなど）で実行可能！
        • NNVM/TVM ：Android,RasPi,JS
        • TensorRT ：Jetson
    • ChainerのCPU対応
      • 学習はGPUを使っても推論でCPUを使えるように。

SONY

• NeuralNetworkLibraries/Console

  • 2回の作り変えを経たDLライブラリ
  • Library ：コアライブラリ
  • Console ：GUIソフト

• カバーするワークフロー

  • ネットワークの設計
  • 学習と評価
  • 製品搭載

• NeuralNetworkLibraries

  • Pythonでの開発が可能
  • コーディング可能な開発者
  • じっくりと研究・開発を行っている人

• NeuralNetworkConsole

  • 統合開発環境
  • ビジュアライゼーション

• 活用シーン

  • ソニー不動産の価格推定エンジン
  • Xperiaのジェスチャー認識

• NeuralNetworkLibrariesの特徴

  • C++ Core上にPythonAPIを載せている
  • おなじレイヤーにC++APIも存在、こちらは製品開発で役立つ
  • インストール
    • $ pip install nnabla
    • $ cmake <nnabla_root>&&make
  • サンプル（画像）
    • LeNetであれば6行で記述可能
  • 動的NN（学習中にNNが変化する、RecursiveNN,DropPath）と静的NNに両対応
  • GPUをかんたんに使える
    • $ pip install nnable-ext-cuda
    • コードの変更はなし
  • 高速実行・分散実行
    • MPIを使用している。
  • Libraries はPythonIFが使える
  • まずは触ってほしい。 * http://github.com/sony/nnable-examples
  • SONYの製品群としてはNNのコンパクト化が重要。論文ベースの手法がサンプルで示されている。

• NeuralNetwork Consoleの特徴

  • 製品レベルのNNを開発するための統合開発環境
  • マウス操作でNNを構築できる。
  • 結果の分析の可視化、構造の自動探索ま！！

NV TesorCore

• TensorCore 混合精度演算 P V FP16／Tensorコア 20TOPS -> 125TOPS

• 半精度浮動小数点数

  • IEEE754に準拠のため、指数が5bitしかない
  • FP32と比べ表現域が狭い

• したがって、混合精度TensorCoreを使ったトレーニングは FP16のみのトレーニングよりFP32の結果に近づけるのか

  • 対策：ウェイトのUpdateにはFP16とFP32を併用する
    • FP16だと表現域の狭さから更新値が表現できない可能性が高い
  • 処理時間は遅くならない？ →もともとUpdateの時間はほんの一部
  • 収束するもの：GoogleNet, Inception v1 RESNET50などでFP32とほぼ同様の結果が得られる。
  • 収束しないもの：AlexNet、CaffeNet、Multibox SSD(VGG_D),FasterR-CNN(VGG-D)
    • 原因：BackPropにてFP16表現域を外れる値が多い
    • 対策：ロスの値をスケールアップしてからBackPropする

TSUBAME3.0 ACBI

• KEI のSPARC64 と比較してTSUBAMEのPASCALは40倍速い

• TOP500のような指標も重要だが、アプリケーション性能をどれだけ出せるかが重要

• HPC界の関心事はAIを同効率よく扱うか、BigDataをどのように扱うか

• BigDataも疎行列計算、AIも行列計算で目指すアーキは雑に言えば同じである

• ハイパーパラメータサーチや並列性検証など、並列実行で探すべき課題は多い

• ただし複数GPUの連携を目指すとネットワークボトルネックが出て来る

• TSUBAME3では432Tbpssのインターコネクトを出した

  • NVLINK、PCIeスイッチなどなど

• 常にデータを流し続けることが重要

• データセンターの作り方PUEが1.3？

• 温水と冷水による冷却

• ABCI オープンかつパブリックなプラットフォーム

• 半精度はEFLOPS

• 建造中で東大柏キャンパス

• すべての設計情報をオープンソース化

• ディープラーニングを使ったソフトプロセスを大規模支援したい

• 来年の春には導入、夏には一般にリリース

• HW：4352個のGV100

佐藤さん

• 産総研ではAIプラットフォームの構築を課題として捉えている
• HPCでも演算処理からAI処理に移行しつつある
• AIIC産総研AIクラウド
• 現在の利用方法はトラディショナルなスパコン
  • いきなりRootがもらえるクラウドとは異なる
  • 最近の論文はGithubで論文を再現するプログラムを合わせて発表する
  • その時はDockerファイルも一緒に公開されるが、Dockerの利用は基本的にはスパコンではNG
• ImageNetでの学習は小さいファイルへのアクセスが多く、スパコンにありがちな共有ファイルシステムでは苦しい
• スパコンとクラウドの特徴を併せ持ったAIクラウドを推し進めていきたい
• Dockerに対応するため、Singularity というソフトを利用している
• ChainerMNのAIIC 8node でベンチマーク、結果ベアメタルと遜色なし

ゼンリン

• 自動運転向けHDマップに注力(米国、日本)

• HDマップ

  • センチメートル級の地図
  • レーンネットワーク
  • 地物3D情報
  • 信号がどのレーンに紐付いているか

• 自動運転ロジックではローカライズを持ちてHDマップ中の自社位置特定が必要

• GPSの情報では不足するので看板等の情報を使って補正

• デモ、NVIDIAと連携か。少なくとも破線でのマッチングはやっていない

• HDマップ生成

  • LIDARカメラ、活用
  • データは１日で1TB／車両
  • 日本全国自専道30Kを２０１８年末迄に

• 一般道課題

  • １２２万KM
  • 信号２０万
  • 標識９８０万
  • 道路形状が複雑
  • 歩行者、他車両との切り分けが必要

• これらのマエショリを行うためにDLを活用

  • 車両オンラインでDL処理、PXを利用

• NVのDriveNetを活用

  • 認識率95.58%
  • V4.1.6では65%、これは米国データのみ
  • V4.1.8では95.58%、日本のデータを加えたため
  • 看板形状や情報が異なる
  • ただやはり補助標識がきつい90%程度
  • DriveNetは逆光等ふくめロバスト性が上がって来ている

• さらなる認識率とロバストを上げるため、複数AI使う

• 処理能力を上げるためDrivePX2を活用

  • 60km/h走行で1m間隔の画像を6並列処理できることがわかっている

HONDA

• 高精度地図の有無によって自動運転のアプローチは異なる
  • HONDAのアプローチはオーナーカー向け（高精度地図なし）
• HDマップアリはLV4、HDマップなしの場合、LV2or3の極力高いレベルを実現したい
• 事故なし、高齢者補助、車は完全プライベート空間になる
• 自動運転時代のHONDAらしさとは？
  • 圧倒的な信頼感
  • 乗り心地、フィーリング
• 2020年高速道路
  • LV2とLV3のモードあり
  • ドラモにあり
  • カメラ、ライダー、レーダー
  • 渋滞時LV3
  • 高速走行時LV2
  • 分岐は運転支援
  • おそらく、ルールベース
• 一般道システム
  • 商店街通過のような難しいシーンもやりたい
  • シーン理解のために
    • セグメンテーション
    • 歩行者の動きの予測
    • これらをAIを活用
    • 白線なし、停止線なし、くさむら
    • 商店街での軌道作成
    • テストコースデモ、GPSなし、白線なしで動いている
  • 人間の認識結果、顔の向き、動きまでを認識し、可視化（バウンディングボックスだけではない）
    • 子供の飛び出し
    • スマホ歩き
  • パスプランニング
    • DNNとモデルベース制御をハイブリットに
    • DeepNeauralでも出る作成、強化学習
      • 鈴鹿サーキットでの教科学習した結果を他のコースに持っていっても走れる
  • HONDAはまずカメラベースで限界まで挑戦する、人間ができていること
    • そこまでやってからLidar等を重ねていく
  • プロのドライバーのような操舵、ブレーキ・アクセル
  • DrivePX2で開発、先行開発でのメリットは大きい
  • アルゴはNV製ではなくHONDA製を利用