pandazx's blog

データ分析など雑多な技術ブログ

TFUG ハード部:Jetson Nano, Edge TPU & TF Lite micro 特集のメモ

以下の勉強会に参加。

tfug-tokyo.connpass.com

以下、メモ

Getting Started with Jetson Nano

NVIDIA 橘 幸彦さん

Jetson Nanoを使い始める際に参照してもらいたいサイトを紹介しながら、 簡単に楽しくJetson Nanoを使い始めてもらうためのTipsをシェアします。

Jetson Nano

  • 5-10W, 0.5 TFLOPS(FP16)
  • GTC 2019で発表
  • ラズパイに仕様を寄せており、ラズパイフレンドリーになっている
    • ラズパイのエコシステムに入って、一緒に皆さんに使っていただきたい
  • メジャーなDLフレームワークはTensorRTで最適化して実行可能

Jetson AGX XAVIER

  • 10-30W, 10 TFLOPS

Jetson Nanoと類似製品に対する各種ディープラーニングでのベンチマーク

全般

  • ラズパイのようにmicroSDにイメージを入れて起動可能。
  • リソース使用状況はtegrastatsでモニタリング可能

JetBot

  • カメラを用いたデータ収集および学習
  • 衝突回避やObject Following, Road FollowingといったAI機能が実装されている

Jetson Nano Mouse(仮称)

  • ラズパイマウスの後継
  • Robot OS(ROS)を入れて動かすネズミのマウスを模擬したデバイス
  • Full HD x 8チャネルに録画された動画を流して、同時にObject Detectionを30fpsで実行可能
    • 実際の推論はFull HDそのままではなく、小さくリサイズしている
    • 今回のデモではResNet10の推論を実行している。モデルは8つではなく、これ1つのみ
    • XAVIER は 30チャネル同時に可能で、Object Detectionに加えてClassificationが可能

スライド

https://www.slideshare.net/NVIDIAJapan/getting-started-with-jetson-nano?ref=https://tfug-tokyo.connpass.com/event/133310/presentation/

Jetson Nano x TensorFlowで始めるモバイルAI画像認識

からあげさん

ユーザー目線でのJetson Nanoの紹介と、 Jetson NanoでTensorFlowを使って画像認識する方法を話します。

全般

  • 簡単にインストールできるスクリプトを作ってGitHubで公開している。
  • Jetson NanoはCUDAインストール済みなので、ハマらなくていい
  • GoogleのObject Detection APIを利用するためのToolsを作って公開している
  • SSD Lite Mobilenet v2をラズパイにデプロイしたところ、なぜか45分かかったが、 Jetson Nanoは50倍高速に起動できた
  • 同モデルをJetson Nanoで使った場合に、TensorRTの使用前後で2倍の高速化できた
  • 骨格検出がラズパイでは遅く実用的でなかったが、Jetson Nanoならスムーズに実行できた

スライド

https://www.slideshare.net/karaage0703/jetson-nano-x-tensorflowai-149186926?ref=https://tfug-tokyo.connpass.com/event/133310/presentation/

AI Robot Car 最前線

株式会社GClue/FaBo 佐々木 陽さん

Donkey Car, JetBot, AWS DeepRacerなどのAI Robot Carの最新動向と、 Deep Learningの使われ方や、ハードウェアの構成や開発方法など解説します。

自動運転プラットフォーム

Robot Car

DeepTesla

  • NVIDIAの自動運転に関する論文

シリコンバレーではDonkeyCarが流行っているらしい

  • DIY Robotcarsという自動運転ラジコンのコミュニティがある
  • 駐車場にロボットカー用コースを作って走らせられる
  • DoenkeyCarの教師データは人間がリモコンで操作して作れる
  • 今までは推論性能がラスパイでは遅いので、人間の操作より遅かったが、 Jetson Nanoが出たことで、近い内に人間より速くなるだろう

★ここで急用が入り、泣く泣く退席。以下の発表聞きたかった。。。

Edge TPU と GCP / AutoML を組み合わせるといい話

Google Cloud 吉川 隼人さん

エッジ側のアクセラレータである Edge TPU と、クラウドGCP は TensorFlow のエコシステムにとてもマッチしています。 ここでは Edge TPU の概要と、GCP(特に AutoML) を組み合わせることでどんなことができるのか紹介します。

(TF Lite for Microの話)Google proppyさん

LTタイム(各5分)

Google Edge TPUでTensorFlow Liteを使った時に何をやっているのかを妄想してみる

@Vengineerさん

スライド

https://www.slideshare.net/ssuser479fa3/google-edge-tputensorflow-lite?ref=https://tfug-tokyo.connpass.com/event/133310/presentation/

Jetson Nano + Coral USBでつくるセルフレジシステム

田原 大輔さん

スライド

https://www.slideshare.net/DaisukeTahara/jetson-nanocoral-usb-accelerator?ref=https://tfug-tokyo.connpass.com/event/133310/presentation/

パネルティスカッション

スピーカーの皆さん、太田さん、TxRacingさん

USENIX OpML'19 登壇・参加報告会のメモ

USENIX OpML'19 登壇・参加報告会(Hadoopソースコードリーディング 第26回)

USENIX OpML全体紹介

  • 参加者:210名
  • 日付:2019.5.20
  • 場所:サンタクララ
  • 採択率は約5割。投稿62件
  • Practiceの傾向が強かった
  • 参加者もシステム系の人の方が多かった印象

USENIX OpML発表資料

登壇内容紹介:Low-latency Job Scheduling with Preemption for the Development of Deep Learning

薮内 秀仁 /東京大学大学院

発表資料はUSENIXのページで公開されている

  • 本論文はPFNでインターンしていた時の研究内容
  • 効率的なリソースマネジメントがDL開発では重要
  • 最適なパラメータ探索のためにジョブを多数実行する。Try & Error(TE)
  • それ以外ではパラメータ決定後に大規模データで評価するBest-Effortなジョブ(BE)
  • TEとBEなジョブの混在環境において、スケジューリングするアルゴリズムを提案
    • TE jobの時間をLow-latencyにするために、BE jobはサスペンドされ得ることを許容した
  • System Model
    • k8sのようなシステムを想定
    • サスペンドにはDL frameworkの多くがサポートしているチェックポイントを利用
  • Grace Period
    • サスペンドする前の停止前処理が実行される期間のこと
  • Fitting Grace Period Preemption(FitGpp)
  • Minimizing Re-scheduling Intervals
    • サスペンドするのは少ないリソースを要求するBEが望ましい
    • 大きいとリソースを停止、またすぐに実行するというオーバーヘッドが大きくなってしまうから
    • (BE jobの要求リソースは大きい傾向があるものなのでは?)
    • サスペンドするBE jobは小さすぎてもダメで、次に実行されるTEのリソースに不足が発生しないような BE jobをサスペンドする必要がある
  • Avoiding Starvation
  • Evalution
    • PFNで実際に実行されていたジョブの傾向を見て、それをシミュレーションした環境で評価

登壇内容紹介:A Distributed Machine Learning for Giant Hogweed Eradication

梅森 直人 /NTTデータ

発表資料はUSENIXのページで公開されている

分散学習の話。

Giant Hogwed Eradication Project

  • デンマークでのプロジェクト
    • Hogweedという毒性のある植物を手作業で切り出している
  • デンマーク国土:3217 km平方メートル。農耕地は62%。これをターゲットとした
  • 課題:データ量:200TB
    • ドローンが撮影した4K動画
  • 課題:Preparation of Supervised Data
    • 空撮動画から判別するのが困難
    • Hogweedに詳しくない人でもラベリングできるツールを開発
  • 課題:Coordinate Calculation at Pinpoint
    • 空撮動画の撮影範囲が20m程度あるので、正確な位置座標がわからない
  • 考察
    • データ量が200TBなので、マシンは自然と複数台構成の分散構成となる
      • 単一ノードとは性質が異なる
    • 運用はどうする
  • Data Pipelines
  • Distributed-ML Code
    • シーケンス図を書いて、コンポーネント間のやりとりが複雑になることがわかった
    • これを出発点として、やりとりが減るようにパイプラインの設計を改良した

OpML 聴講内容紹介:参加者による注目すべきセッションの紹介

Relevance Debugging and Explainable xxx

  • Linkedinのシステムで、ユーザの関連情報提供サービスのデバッグ
  • 関連情報を提供するアーキテクチャは階層化されており、複雑。デバッグ難しい
  • デバッグの難しさ
    • 複雑なインフラ
    • 再現性。その時の本番データでないと再現できないことが多い
    • 時間がかかる
  • デバッグのための仕掛け
    • コンポーネントで発生したログをKafkaに集約し、後からトレースできるようにする
    • ログの可視化機能
      • 各リクエストの成否の表示
      • 時間のかかっている箇所の表示
      • など
    • 比較
      • モデルやクエリを変えた時の結果の違いを比較表示
    • Replay
      • あるユーザの操作で表示される画面を再現
  • MPP: Model Performance Predictor
    • 機械学習をプロダクションで運用する際に、モデルの良し悪しを知りたい
    • しかし、プロダクションでは正解データがない
    • パフォーマンス値自体を推定しよう
    • 推定時と同じ特徴量を入力として、出力は推定が正解、不正解になるという2値判定を行う

MLOp Lifecycle xxx

Deep Learning Inference xxx

Tensorflow Extended(TFX)

  • ML-metadata
    • Data driven。ある処理の出力(artifact)があったら、次の処理が動く
  • TFXではTask drivenでもサポートする

Katib: A Distributed General AutoML Platform on Kubernetes

  • kubeflowのコンポーネントとして実装
  • AutoML Workflows
    • Hyperparameter Tuning
    • Neural Architecture Search
  • 類似品に対する強み:k8s native
  • k8sとして実行するので、一部が死んでも系全体は活き続ける

気になるPythonライブラリ 2019.6.2

videoflow
Python framework that facilitates the quick development of complex video analysis applications and other series-processing based applications in a multiprocessing environment

 

GitHub - videoflow/videoflow: Python framework that facilitates the quick development of complex video analysis applications and other series-processing based applications in a multiprocessing environment.

 

AKIBA.AWS #13 ガチ編〜監視(モニタリング)のメモ

AKIBA.AWS #13 ガチ編〜監視(モニタリング) - https://classmethod.connpass.com/event/130740/

AWSと監視SaaSの動向から探る監視(モニタリング)の「現在」

資料:https://dev.classmethod.jp/cloud/aws/201905-akiba-aws-13-monitoring-s01/

ペットと家畜モデル

  • ペットは丁寧に色々なメトリクスを収集
  • 家畜は10ノードの全体のパフォーマンスに注目し、ノードごとの細かなメトリクスはあまり気にしない

Design for failuer: 1つ2つサーバが落ちてもサービス継続可能な設計

昔はマシン再起動に時間がかかったので、プロセスだけを再起動していたが、 今は再起動にかかる時間が少ない。コンテナなら破棄して再作成するだけ。

Apdex(アプリケーション性能指標)

  • アプリケーションの応答時間やサービスの応答時間を基に ユーザー満足度を測定するための業界標準の指標
  • 簡潔なサービス品質保証契約 (SLA:Service Level Agreement) ソリューション

IoT Botの監視(re:Invent 2018 DEV311)

  • 各デバイスはステータスをDynamoDBにUPし、UPが途絶えたら、そのデバイスは死んだと判断

資料紹介:運用自動化、不都合な真実(波多野)

監視 SaaS(網羅的で汎用的)

  • Datadog, Mackerel, Stackdriver

Stackdriver

New Relic

sumoLogic

Pingdom

  • 外形監視特化
  • 複数拠点からの死活監視

これまでの監視を振り返って、最近の監視で変わったことを考える

監視環境はいつでも構成変更できるようにすべき

Grafanaが可視化レイヤーを担うことで、内部のコンポーネントを変更可能になった。

  • (これにより、アップグレードの単位が小さくなり、特に可視化レイヤーのアップグレードしやすくなったと思われる)

最近のトレンド

  • 収集データがJSON/YAMLで構造化データとなり、プログラムで処理しやすくなった

Googleトレンド検索によると、Zabbixの一強

  • (これは監視SaaSは検索しなくても使えるからと思われる。Zabbixはノウハウを検索しないと使いこなせない)

最近の監視(モニタリング)は非技術者も見るようになってきている。

  • (これはビジネスのKPIをダッシュボード化しているためと思われる)

「監視」でつくる「安全な自動デプロイ環境」

資料:https://www.slideshare.net/ssusere269e9/cicd-148257692

デプロイにはリスクがつきものなので監視が必要。

自動デプロイ失敗時は必ずアラートを通知すること

  • CircleCIにはSlack通知機能がある
  • CodePipelineでは、Lambdaなどを使って作る必要がある

デプロイするモジュールなどは事前にビルドしておきデプロイする時にしない方がエラー発生のリスクを減らせる。

Blue/Green deploymentによるデプロイリスク低減

  • Blueを本番とした場合、Greenにデプロイしてリリースは切り替えるだけにする

REDメソッド

  • Rate, Error, Durationに着目したアラート通知条件の設定
  • レート(Rate) - 秒あたりのリクエスト数
  • エラー(Errors) - リクエストの失敗数
  • 時間(Duration) - リクエストの処理にかかる時間

勉強会で説明はなかったが、USEメソッドというのもある

  • すべてのリソースについて、使用率(Utilization)、飽和状態(Saturation)、エラー(Errors)を確認する
  • リソース(Resources):すべての物理サーバーの機能コンポーネント(CPU、ディスク、バスなど)
  • 使用率(Utilization):リソースが処理中でbusyだった時間の平均
  • 飽和状態(Saturation):リソースにサービスできない余分な作業がある度合い。(処理できてないものは大抵キューに入れられいる)
  • エラー(Errors):エラーイベントの数
  • 参考: http://febc-yamamoto.hatenablog.jp/entry/2019/02/17/152014

REDメソッドとUSEメソッドは両方一緒に使うべきらしい

複数ノードで構成されるクラスタをローリングアップグレードする際にあるノードがデプロイが失敗しても、通常の監視では気づきにくいので、デプロイの失敗は明示的にアラート通知すべき。

いまふたたびの CloudWatch Dashboards へ

2018年からCloudWatch Dashboardsのアップデートが多く発表された

  • AWSのすべてのリソースがAutomatic Dashboardsで見れるようになった
  • Metric Math により複数の CloudWatch メトリクスをクエリし、数式を使用して、これらのメトリクスに基づく新しい時系列を作成できるようになった
  • 検索条件式が使えるようになった

Four of the Observability

  • Monitoring
  • Alerting/Visualization
  • Distributed systems tracing infrastructure
  • Log aggregation/analytics

Observabilityとは

  • 複雑化するシステムの動作を追跡、把握できること

CloudWatchではグラフに注釈を追加でき、グラフ上に表示可能

  • 未来の注釈も事前に追加可能
  • (分析する時に便利そう)

その他

AWS Systems Manager

DMM x ZOZOを支える基盤技術のメモ

DMM x ZOZOを支える基盤技術 https://dmm.connpass.com/event/129128/

参加者数:200

DMMを支えるプラットフォーム基盤の裏側

ユーザーの回遊・リテンションを最大化するサイクルとは? 石垣 雅人, DMM.com, @i35_267

資料:https://speakerdeck.com/i35_267/dmmwozhi-erupuratutohuomuji-pan-falseli-ce

複数サービスを支えるアカウント管理、決済といった共通機能を基盤として提供。

ユーザに複数サービスを回遊してもらいたい。

送客のリコメンド技術で数%向上しただけでも、売り上げに大きく貢献できる。

ZOZOSUITEによる計測システムの裏側と今後の展開について

指原 卓也, ZOZOテクノロジー

初代ZOZOSUITE計測システムの構成

問題1:Lambdaのコールドスタート問題

  • 安定的なリクエストがあればLambdaコンテナが再利用されるが、 まったくリクエストがない時間が続いてからリクエストがあると コンテナ作成から処理が行われるので時間がかかってしまう

問題2:GDPR

  • EUのデータを扱うために、アイルランドリージョンに移行した
    • (日本からのレイテンシがより高くなるのでは?)
    • (グローバルで1つのシステムにする理由がいまいちわからなかった)

問題3:商品サイズ管理の組合せが柔軟がゆえに膨大になる

  • 商品の仕様変更もあるので、スキーマレスのDynamoDBで管理

レコメンド/検索の大規模展開に関する課題と解決策

藤井 亮太, DMM.com, @r_megane

レコメンドの種類は167種類

ABテスト用ダッシュボードを作成。

  • 1本/月だったのが、5本/2週間に高速化

課題

  • Solrのver 4を8にアップグレード
  • しかし、多くのサービスにSolrが利用されているため、無停止アップグレードが困難
  • 検索ライブラリからSearchAPI→Solrにして検索リクエストをSearchAPIに集約
  • 巨大なプログラムファイルがあり、リファクタリングが困難。。。
  • ログベーステストを実施
    • ユーザからのリクエスト時に実行されるメソッド、引数、変数などをログに出力し、 それをHadoopでテストケースを自動生成 (類似テストを絞り込む実用的に使えるテストケースが出来るの?)
    • これにより、仕様不明でもテストケースを作成できる
    • 2人で4か月でリファクタリングを完了
    • (無停止アップグレードをどうやったかの説明がなかった。残念)

ZOZOTOWN HTTPS化におけるSREチームのアプローチ

横田 工, ZOZOテクノロジー

Forward Secrecy(ECDHE)

  • クライアントとサーバ間で使い捨ての共通鍵を利用してセキュリティ向上

SSL Labs

  • 自社サイトのSSL状況を評価してくれるサイト
  • B判定だった
  • 対策
    • RSA -> ECDHEに変更
    • 不要なciphersなどを精査

過去のシステム構成

  • LBがHTTPSの複合処理を担当
  • FW兼LBの役割が多く、アクセス増の場合に負荷が懸念されていた
  • 使っている機器でECDHEに変更するとカタログスペックよりも、大幅に低い性能が出てしまう問題があった

変更後のシステム構成

  • WAFがHTTPSの複合処理を担当
  • 複合後にL7のFWを通している
  • SSL Labsの判定がA判定になった

アクセス数、WAFの検知率など実際の運用負荷に近い状態を 1/Nの規模で再現して負荷テストを実施

DMMの不正対策システムと運用サイクル

寺西 一平, DMM.com

本日の不正の対象

  • アカウント乗っ取り、
  • 不正種別の割合として、アカウントの乗っ取りが70%
  • 対策することで、乗っ取りを50%以上防止できた

対策の施行1

  • 過去の購入時と、その時のIPアドレス、ブラウザ情報に変化があったら 不正と判断したが、正当判定率が2%と全然ダメだった
  • なぜ?
    • ネットカフェからのアクセス
    • 様々なWi-Fiスポットからのアクセス
    • VPN利用
    • ブラウザのプラベートブラウズ
    • 上記は不正ユーザばかりで、正規ユーザを見れていなかった

対策の施行2

  • 確実に本人の購入である操作を検出
  • 不正ユーザの特徴を含む購買の検出
    • 日本語のページに台湾からロシア語でアクセス
  • 正当安定率13%まで改善

しかし、対策を行うと不正ユーザも対策を行うので、いたちごっこになる

  • 不正ユーザ検出パターンを追加する体制を整え、毎週追加/削除を実施
  • 昨年11月から360パターンが追加された

伝えたいこと

  • 不正被害の継続的モニタリング
  • 不正の分類をすべき。乗っ取り、クレカ不正利用など
  • 横連携が大事
    • 守りが一番薄いところが狙われるので、システム、サービス全体で連携することが必要
    • 1社では難しいことがあるので、会社横断で連携したい

ZOZOTOWN Azure SQL Database 節約術

鶴見 純一, 杉山 弘二, ZOZOテクノロジー

宣伝:コーデ相談をリリース

  • Amazon Alexaを使ってコーディネートをAIに相談できる

オンプレでDBをセールの時だけスケールアップさせるのがツライ

  • 参照系DBをAzureに移行。しかし、費用が高い。。。

コスト低減の施策

  • SQL Database オートスケール
    • アクセス負荷が時間帯によって変わるので、それに応じてインスタンスタイプを変更
    • これをAzure Automationで自動化
    • ただし、スケール変更に30分以上かかる
    • スケール変更時に10秒程度の切断がある
    • スケールダウン時に必要なデータがメモリに乗らなくなる可能性がある
  • SQL Database Read scale-out
    • いわゆる、DBのマスタスレーブ構成
    • Secondary Read Replicaのメトリクス取得が困難で、工夫が必要

上記課題に対してカスタムメトリクスを収集できるようにして、Datadogを利用

k8sのCronJobで定期ジョブスケジューラでメトリクス収集を実行

  • メリット
    • 実行用コンテナが毎回、作成・破棄されるので、実行環境にゴミがたまらない
    • 環境設定の変更が容易なため、1種類のジョブを複数の環境に対して実行しやすい
    • Nodeの空きスペースを考慮して実行してくれるため、リソース不足になりにくい

Datadog

  • アラートをSlackに通知
  • 高アラートはPagerDutyでオンコール

メトリクス収集を行っているk8sシステムの監視はDatadogで行っている

  • Datadogにはk8s integrationがある

上記の施策の結果、当初から70%のコスト削減を実現

気になるPythonライブラリ 2019.5.17

Python weeklyからの抜粋

 

Interesting Projects, Tools and Libraries

 

openpilot
openpilot is an open source driving agent. Currently, it performs the functions of Adaptive Cruise Control (ACC) and Lane Keeping Assist System (LKAS) for selected Honda, Toyota, Acura, Lexus, Chevrolet, Hyundai, Kia. It's about on par with Tesla Autopilot and GM Super Cruise, and better than all other manufacturers.

 

GitHub - commaai/openpilot: open source driving agent

 

pysot

SenseTime Research platform for single object tracking research, implementing algorithms like SiamRPN and SiamMask.

 

GitHub - STVIR/pysot: SenseTime Research platform for single object tracking, implementing algorithms like SiamRPN and SiamMask.

 

stumpy

stumpy is a powerful and scalable Python library that can be used for a variety of time series data mining tasks

 

GitHub - TDAmeritrade/stumpy: STUMPY is a powerful and scalable Python library that can be used for a variety of time series data mining tasks

 

creme

Online machine learning in Python

 

GitHub - creme-ml/creme: Online machine learning in Python

 

koalas

Pandas API on Apache Spark

 

GitHub - databricks/koalas: Koalas: pandas API on Apache Spark

 

conveiro

Visualization of filters in convolutional neural networks.

 

GitHub - Showmax/conveiro: Visualization of filters in convolutional neural networks

 

 

 

 

SysML2019論文読み会のメモ

SysML2019論文読み会に参加してきた。

mlxse.connpass.com

気になった発表は以下から論文を参照できる

以下、メモ

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
    • メルカリからは約6名参加, FPN, NEC, Indeed, etc.
  • スポンサー: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プロファイルを使ってコンパイルする
  • 評価がいい加減な機械学習が多いという苦言
    • 冗長なモデルにlossy compressionを行って、精度劣化があったが、コスト低減ができたという論文が多い
    • lossy compressionとは、例えば、FP32->FP8にするといったもの
    • 基本的に処理時間と精度はトレードオフで、 このトレードオフのパレート境界を上に押し広げる研究でないと意味がない

基調講演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, P3)
      • 通信内容の圧縮(3LC)
      • 通信頻度の削減(AdaComm)
      • 通信アルゴリズムの改良(BlueConnect)
    • 計算の効率化
  • TicTac
    • ResNet, Inceptionなど分岐が多い場合に通信順序を効率化する手法
  • P3
    • 層ごとのパラメータ数が異なる場合に効率化する手法
  • AdaComm
    • 分散SGDは分散して学習して、都度、コミュニケーションして協調していく
    • Periodic Averaging SGD(PASGD)はコミュニケーション回数をτ回に1回にする
      • 学習はバラツキが大きいので、τ回にすることでバラつきが抑えられる(らしい)
      • 処理は速くなるが、収束性が分散SGDよりも悪化し、得られるモデル精度が劣化する問題がある
      • これを改善するために、最初のτは大きく、徐々に小さくする手法もある ※他の分散学習でも学習率はこのように変化させることが多い
  • 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で重み平均値を計算するが、その際のルールを提案
  • 1つの方法として平均ではなく、中央値を取る方法もある。 他にMULTI-KRUM, BULYANという手法があり、それに対する考察を行い、 ビザンチン障害に対する耐性を数学的に証明
  • MULTI-KRUMはいくつかの障害があっても収束することを証明
  • BULYANはいくつかの障害があっても、障害がない場合と同じ値になることを証明
  • 故障したり、乗っ取られた場合の値というのは全体的な平均の値から 一定以上離れているかどうかを基準としている
  • Tensorflow上に実装して、故障やパケットロスを起こさせて評価して 提案手法の有効性を示した

Towards Federated Learning at Scale: System Design

  • 論文著者はBonawitz et al., Google
  • Federated Learning(自分の理解があやしい。。。)
    • クラウドからエッジに学習タスクを配布
    • エッジで得られたデータを元に学習
    • 更新したモデルを暗号化してクラウドにUPして集約
    • これはエッジで得られたデータを外に出せない場合に有効な手法

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倍高速化
  • 単純な方式
    • convとreluを1つにまとめる
    • これにより、メモリアクセス、GPUカーネルの立ち上げ処理が低減される
    • 本方式はルールベースでモデルやハードウェアの違いを考慮できていない
  • Metaflowによる最適化
    • conv 1x1 -> conv 3x3にしてカーネルサイズを拡大
      • ただ、こういったルールは人が決めている。自動化は将来課題
    • 拡大した部分は0で埋める。拡大しても計算結果は変わらない
    • プレゼンの例で示された最適化例はV100では高速化されるが、K80では高速化されないらしい。 つまり、デプロイ先のHWを考慮した最適化が必要
  • ソースコードGithubで公開されている
    • metaflow_sysml19
  • QA

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
    • ハードウェアにより高速化される機械学習のための、多段階型のPythonに埋め込まれたDSL
    • ライブラリというよりはDSL
    • Tensorflowは宣言型プログラミングだったが、これを命令型にしたのがTensorflow Eager