Skip to content

Instantly share code, notes, and snippets.

@zonomasa

zonomasa/gtc_japan_2017.md

Created December 13, 2017 12:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save zonomasa/29c5c8fd0e3bc6ad66c55701e5a2f3c3 to your computer and use it in GitHub Desktop.
Save zonomasa/29c5c8fd0e3bc6ad66c55701e5a2f3c3 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
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製を利用
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment