SysML2019論文読み会のメモ
SysML2019論文読み会に参加してきた。
気になった発表は以下から論文を参照できる
以下、メモ
SysML参加報告＆紹介
Speaker: 今井
SysMLとは
- SySMLとは計算機システムと機械学習の学際的な研究を扱う国際会議。
- 採択率16%とトップカンファレンス級の難易度。
SysML2019
- Session
- Parallel & Distributed Learningのセッションは2セッションあった
- 他はSecurity and Privacy, Hardware, Hardware Debugging, Video Analysis, etc
- 参加者515名. 去年の1.8倍
- 産学比は産:学=7:3
- スポンサー：GAFAM, Tesla, databricks, IBM Research AI, QUANTUMBLACK, NetApp
- 講演映像はSysMLで公開されている
基調講演1: Compiling AI for the Edge
- Ofer Dekel, Microsoft Research
- Microsoft Researchが開発しているエッジ向けAIコンパイラ ELL(the Embedded Learning Library)
- デプロイ先のエッジHWプロファイルを使ってコンパイルする
- 評価がいい加減な機械学習が多いという苦言
基調講演2: How Do We Make AI Fair?
- Maya Gupta, Google AI
- AIの公平性の話
- 学習時に公平性を制約として入れて、公平性を満たすように学習すべき。 この際、滑らかな関数を得たい。ギャップがあると、その前後で公平性に欠ける可能性がある
- 例えば、ある指標値が上がっていく時に上がって下がって上がるような曲線がある場合、 途中下がってしまうと不公平になる場合があるため
- 具体例としては金利計算する際に勤務年数を元にすると、 勤務年数が低い方が金利が優遇されてしまうケースが出てくるため
- AIで難しいのは現実に即したモデルとなって欲しいが、現実が公平ではない場合があるということ
おそらく、ギャップを狙ってAIがハックされるといった、AIの脆弱性にも通じるところと思われる。
Hardwareセッション: Serving Recurrent Neural Networks Efficiently with a Spatial Accelerator
Hardwareセッション: Bandana: Using Non-Volatile Memory for Storing Deep Learning Models
- Standord, Facebook
- Facebookではたくさんの特徴量がベクタ表現に変換しているため、巨大なメモリが必要
- DRAMでは足りなくなるので、NVMをメモリとして使って、DRAMをキャッシュとして使う
- 格納アルゴリズムSocial Hash Partitioner(SHP)を提案
- 学習の時に使うテクニック
Speaker: 宮崎崇史, ヤフー株式会社
Parallel & Distributed Learning I, II
- 分散学習の例: AGGREGATHOR, Federated Learning
- アプローチの分類
- TicTac
- ResNet, Inceptionなど分岐が多い場合に通信順序を効率化する手法
- P3
- 層ごとのパラメータ数が異なる場合に効率化する手法
- AdaComm
- P3(Priority-based Parameter Propagation for Distributed DNN Training)
Video Analysis: FixyNN: Efficient Hardware for Mobile Computer Vision via Transfer Learning
- 事前学習しておくと転移学習で必要な学習データ量を削減できる
- FFEのメリットとして、演算内容が固定されるので最適化しやすい
- ただ、固定すると精度が劣化
- 固定する層数に比例してチップ面積が増大
- NVDLA: NVIDIAが公開しているOSSのNNアクセラレータ
- DeepFreeze: 本論文で提案したツール。Githubで公開されている
- NVDLA, DeepFreezeを評価してスループットや電力効率（TOPS/W）を比較
Category: Security and Privacy
AGGREGATHOR: Byzantine Machine Learning via Robust Gradient Aggregation
- Speaker: 丸山宏, PFN Fellow
- 並列トレーニングにおけるビザンチン障害
- 理論的かつ実用的な提案
- マルチノードマルチGPUの分散学習で、いくつかのGPUが故障したり、乗っ取られたケースを想定
- All Reduceで重み平均値を計算するが、その際のルールを提案
- １つの方法として平均ではなく、中央値を取る方法もある。 他にMULTI-KRUM, BULYANという手法があり、それに対する考察を行い、 ビザンチン障害に対する耐性を数学的に証明
- MULTI-KRUMはいくつかの障害があっても収束することを証明
- BULYANはいくつかの障害があっても、障害がない場合と同じ値になることを証明
- 故障したり、乗っ取られた場合の値というのは全体的な平均の値から 一定以上離れているかどうかを基準としている
- Tensorflow上に実装して、故障やパケットロスを起こさせて評価して 提案手法の有効性を示した
Towards Federated Learning at Scale: System Design
- 論文著者はBonawitz et al., Google
- Federated Learning（自分の理解があやしい。。。）
To compress or not to compress: Understanding the Interactions between Adversarial Attacks and Neural Network Compression
メモしなかった
敵対的サンプルについて。
Category: Hardware & Debugging
Full Deep Neural Network Training on a Pruned Weight Budget
- エッジデバイスで学習するためのPruningを適用してメモリ使用量を削減する手法
- 評価では重みの数を5～11分の1に削減し、精度劣化なしという結果が得られた
Continuous Integration of Machine Learning Models with ease.ml/ci: Towards a Rigorous Yet Practical Treatment
- 厳密だが実用的な機械学習システムのためのCI(Continuous Integration)
- 技術課題
- テストセットのサイズ
- テストセットの更新頻度
- リリースの基準
- 貢献
- テストシナリオを整理
- テスト条件を記述するscriptを定義(Travis CIの拡張として定義）
- そのCI Systemを開発
- リリース基準
- モデルの精度が改善していること
- モデルの結果が変わりすぎていないこと
- 他に3つある
- テストセットの更新頻度
- 基本的には開発者が過学習させないようにテストセットは開発者に渡したくないという考えがある
- テストセット更新しない。モデル開発者にはテストセットは渡さない
- テストセットを毎回更新。モデル開発にはテストセットを渡す
- モデルがテストをパスしたらテストセットを更新。モデル開発にはテストセットを渡す
- テストセットのサイズ
- Hoeffdingの不等式の変形によってサンプルサイズを計算
- 最適化などを使用
- コメント
- 運用チームが開発とは独立にテストデータを準備するのは難しいので、 前提が成り立ちにくいのでは
Data Validation for Machine Learning
- 機械学習パイプライン
- TFX(Tensorflow Extended)のライブラリとして提案手法を実装
- 既存研究ではデータの品質に着目されてこなかったが、 運用ではデータの品質監視が重要
- 学習データとテストデータの分布の差を監視
- 両データの分布の距離を計算するが、KL divergence, コサイン距離は 運用チームでは解釈が難しい。チェビシェフの距離を使った解釈が容易な手法を提案
データ品質監視はDebuggingというカテゴリになるんだな。
Category: Efficient Training & Interface
Optimizing DNN Computation with Relaxed Graph Substitutions
- Speaker: 横道春道, NEC研究所
- DNN計算グラフの最適化
- 提案手法
- グラフ全体にサブグラフに分割
- バックトラック法で広い空間で探索
- 最大で1.6倍高速化
- 単純な方式
- Metaflowによる最適化
- ソースコードはGithubで公開されている
- metaflow_sysml19
- QA
- TVMはルールの自動生成ではなく、スケジュールの最適化をしている
- TVM: https://qiita.com/masahi/items/f722db96338d8868f222
Category: Programming Models
TensorFlow Eager: A multi-stage, Python-embedded DSL for machine learning
- Tensorflow EagerはAutoGraphと関連が深い
- AutoGraph: https://www.tensorflow.org/guide/autograph
- Tensorflow Eager
metaflowとMLOps
MLOps関係でkubeflow,airflowなどのツールがあるが、Netflix開発のmetaflowもあるらしい。
- Machine learning infrastructure lessons from Netflix
- Human-Centric Machine Learning Infrastructure @Netflix - YouTube
metaflowでググるとmetaflow-aiやmetaflow incなど似たような名前が出て来るが、Netflixのgithubリポジトリをみる感じでは、まだOSSにはしていないようだ。
以下によるとOSS化の予定ではあるらしい。
UseR!2018に参加し、社内Rパッケージ「liner」の活用事例を紹介しました - LINE ENGINEERING
MLOpsについて
精度を高めたモデルをリリースする際にシステム運用チームの承認や対応が必要だと面倒。すぐにリリースできるAPIがあるといいが、精度以外のパフォーマンス劣化があると問題になる。そのため、パフォーマンスの自動テストがリリースAPIに含まれていると事故防止になってよいのではないか。達成すべきパフォーマンスについて運用チームと事前に合意しておけばよい。
データ可視化のアニメーション
データ可視化でグラフをアニメーション表示する方法はRではgganimateがある。
Rで解析：ggplot2のプロットを簡単アニメーション「gganimate」パッケージ
以下の動画にリッチなアニメーション例がある。
The Grammar of Animation - YouTube
上記よりもリッチさには劣りそうだが、Pythonでは以下の方法がある。
How to Create Animated Graphs in Python – Towards Data Science
デモ用に見た目をカッコよくするにはいいけど、これの実装に時間をかけるほどの実用性はアニメーションにはないかな。
Deep LearningにおけるCPUとGPUの性能比較メモ
興味があったので、いくつか記事を漁ってみた。
benchmark 1
以下はNVIDIA 1080ti, Jetson, Qualcomm, Google Vision kit, Intel Core i7などのHWごとの 処理性能をベンチマーク。
https://towardsdatascience.com/benchmarking-hardware-for-cnn-inference-in-2018-1d58268de12a
パラメータ数が少ないとCPUでもGPUに近いスループットが出る。それでも2倍遅いが。 パラメータ数が多い場合はGPUの方が数倍速い。 MobileNetのようなモバイル向けのDLはパラメータ数が少なく、CPUで実用的な性能が出ている。
benchmark 2
以下はResNetやSqueezeNetのGPUとCPUの比較。 CPUはGPUの100倍の時間がかかっている。
https://qiita.com/yu4u/items/c6e24d862325fac96f61
benchmark 3
以下はMSによるAzure上のベンチマーク結果。
https://azure.microsoft.com/en-us/blog/gpus-vs-cpus-for-deployment-of-deep-learning-models/
環境にかかる費用を同一にしたCPUとGPU環境を用意した場合、 同一コストではGPUの方が数倍、性能が出ることを示している。 3 node GPUと5 node CPUが同一コストらしいので、 今の価格表を見てみると以下の通り。 GPUはNC6 seriesのK80を使うインスタンス。$0.9/hour CPUはD4 v2の8coreインスタンス。$0.458/hour 3 node GPUで$2.7/hour, 5 node CPUで$2.29/hour 今の価格ではCPUは6 nodeにした方がフェアな比較になる。
Visual Studio 2010でCannot find or open the PDB file error
実行中に以下のエラーメッセージが出た場合の対応。
'C:\Windows\System32\ntdll.dll' を読み込みました。Cannot find or open the PDB file
Visual Studioで、ツール→オプション→デバッグ→シンボル→Microsoft シンボル サーバにチェックする。 これで解決。
参考記事
Skype for Business自動起動を停止
Ubuntu16.04でCUDAなどのインストールでログインできなくなった場合の対処
NVIDIAのグラフィックカードをディープラーニング用GPUとして使う場合、 グラフィックカードのドライバ、cuDNN、CUDAをインストールするが、 インストール後に再起動すると画面が正しく表示されず、ログインできなくなる場合がある。
場合があるというか、よくある。
Ubuntuでこの現象が起きた場合に画面が起動中の紫色一色になったままことがある。 この場合、放置、電源長押しのシャットダウン、再起動を何回か繰り返して 20-30分ぐらい経過して、諦めの境地に達した時に 急に画面を正しく認識し、ログイン画面が表示されるようになるので、すぐに諦めてはいけない。 後はディスプレイの画面表示をフルスクリーンにしたり、他のにしたりしてみたり。
以下の方法も有効だと思われる。
