Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
DEIM Forum 2019 D3-3
機械学習向けのコンピュータシステムの構築に向けた
AIワークロード実行時の特徴に関する検討
高山沙也加† 白石 崇†† 鈴木 成人†† 山本 昌生†† 渡辺 幸洋††
小口 正人†
† お茶の水女子大学 〒 112–8610 東京都文京区大塚 2-1-1
†† 富士通研究所 〒 211–8588 神奈川県川崎市中原区上小田中 4-1-1
E-mail: †{sayaka-t,oguchi}@ogl.is.ocha.ac.jp,
††{shiraishi-ten,shigeto.suzuki,masao.yamamoto,watanabe.y}@fujitsu.com
あらまし AIを用いたアプリケーション利用の増加に伴って,CPUと比べて処理性能が高く電力消費の激しいGPU
の利用が進み ICTシステムの全体電力が増加傾向にある.そのため,システム性能の維持が可能な範囲での ICT電
力の削減が望まれるが,よりワークロードに特化したサーバ設計・サーバ制御技術の確立が課題となる.そこで,AI
ワークロード毎にサーバ性能の自動チューニングを行う機械学習向けのコンピュータシステムの構築を考えたい.本
研究ではコンピュータシステムの構築に向けて,機械学習系アプリケーションのパフォーマンス測定のためのベンチ
マークであるMLPerfを用いて AIワークロードの比較及び特徴分析を行う.
キーワード 特徴分析,MLPerf,Zabbix,機械学習,AIワークロード
A Study on Characteristics of AI Workload Execution for Constructing
Computer System Suitable for Machine Learning
Sayaka TAKAYAMA†, Takashi SHIRAISHI††, Shgeto SUZUKI††, Masao YAMAMOTO††,
Yukihiro WATANABE††, and Masato OGUCHI†
† Ochanomizu University,
2–1–1 Otsuka, Bunkyou-ku, Tokyo 112–8610 Japan
†† Fujitsu Laboratories,
4–1–1 Odanaka, Nakahara-ku, Kawasaki-shi, Kawasaki 221–8588, Japan
E-mail: †{sayaka-t,oguchi}@ogl.is.ocha.ac.jp,
††{shiraishi-ten,shigeto.suzuki,masao.yamamoto,watanabe.y}@fujitsu.com
1. は じ め に
AIを用いたアプリケーション利用の増加に伴って,CPUと
比べて処理性能が高く電力消費の激しい GPU の利用が進み
ICTシステムの全体電力が増加傾向にある.特に近年では,プ
ロセッサの高負荷による大量の電力消費がもたらす環境面への
影響が懸念されている [1].そのため,システム性能を落とさな
い範囲で ICT 電力を削減していく事が望まれ,システム電力
削減とアプリ性能の向上のバランスを取り,システムを効率良
く稼働させる事がますます重要になる.ワークロードという計
算機に対する負荷または負荷アプリケーションを使った実行時
性能やリソース情報から効率的にハードウェアを設計・制御す
る手法は既に用いられている [2].この制御にあたって CPU時
間やデータベースの変更数,応答時間などの情報を踏まえた上
でリソースの配分などを検討しなければならない.しかし,AI
ワークロードを走行させるハードウェアリソースの有効活用・
運用の制御手法は未だ確立されてない.そこで,ワークロード
毎にサーバ性能の自動チューニングを行う機械学習向けのコン
ピュータシステムの構築を考えたい.
本研究ではコンピュータシステムの構築に向けて,AI ワー
クロードに特化したコンピュータシステムの最適リソース設計
を目的として,機械学習系アプリケーションのパフォーマンス
測定のためのベンチマークであるMLPerf [3]を用いた AIワー
クロードの比較及び特徴分析を行う.
2. 背 景
Facebook社では保有するデータの大部分を機械学習パイプ
ラインに流しており,GPU と CPU の両方を活用するトレー
ニングと CPUを活用するリアルタイム推論でシステムを使い
分けている.また,リアルタイム推論では入力データが大き
いことから必要リソースも異なってくるなど,文献 [4]では機
械学習に基づく AIワークロード挙動の特徴分析の重要性が問
われている.Facebook製品の機械学習を活用するタスクを簡
素化することを目的とした FBLearner というツールキットが
開発されており,機械学習の特徴に合わせて異なるリソース設
計の CPU サーバ,GPU サーバで処理している.FBLearner
は FBLearner Feature Store,FBLearner Flow,FBLearner
Predictorという機械学習パイプラインのさまざまな部分に焦
点を当てた 3つのツールから構成されており,内部ジョブスケ
ジューラを利用して,GPU と CPU の共有プール上にリソー
スを割り当て,ジョブをスケジュールする. Facebookの機械学
習の訓練の殆どは,この FBLearner プラットフォームを介し
て実行されている.
ボトルネックを分析し,リソースを配分を行う自動ワーク
ロード管理機能や受信する接続を均等に分散する機能を備えた
CPU やサーバは既に開発されている.CPU コアやクラスタ
単位で負荷に応じて電圧と動作周波数を切り替える Dynamic
Voltage and Frequncy Scalingを実行する Intelの CPUアー
キテクチャ”Haswell” [5],CPUアーキテクチャや多くの GPU
を積んで AI ワークロードに特化させた NVIDIA のサーバプ
ラットフォーム”HGX-2” [6]等が例として挙げられる.HGX-2
は通常の IAサーバと異なり 1サーバで最大 16個のGPUを利
用できる GPUネックジョブ向けの専用サーバである.
3. 実 験
本研究では,AI の代表種であるアプリケーションの実行時
のハードウェア情報の分析を目的としてMLPerfを利用して各
ベンチマークの性能評価,比較を行う. 性能評価には MLPerf
に実装されている 9つのベンチマークを利用する.情報取得に
は Zabbix [7]を用いる.Zabbixは Zabbix社が開発したネット
ワーク管理ソフトウェアで,デフォルト設定の他にテンプレー
トを用いることによって監視対象を追加することができる. 本
研究では IPMI,Perf,nvidia-smi,そして Intel CPUが備える
性能監視機構である PMU(Performance monitoring unit)[8]
で取得できる情報を分析対象とする.各ベンチマーク毎の特徴
分析のためにこれらのコマンドによって CPU や GPU,メモ
リ,I/Oといった情報をベンチマーク実行時に取得する.情報
取得は 1分間隔で行う.各ベンチマークの測定条件を表 1に示
す.また,RNN translatorのみ学習精度を 15に変更した.今
回は CPUやGPU,メモリの利用量に注目して特徴分析を行っ
た.実験環境は表 2に示す.
以下に本研究で利用するソフトウェアの概要を記す.
表 1: 各ベンチマークの測定条件
ベンチマーク epoch 数 SEED ジョブ時間
(step, iteration)
IC 53200 1 3:01:13
(step)
SSD 11 1 3:09:12
OD 25000 3 2:23:26
(iteration)
RM 6 1 1:09:34
SA 100 1 1:22:50
RT 1 1 2:48:18
TL 17200 1 2:59:55
(step)
SR 1 1 10:53:32
RI 4 1 5:46:00
表 2: 実験環境
OS ubuntsu 16.04
サーバ FUJITSU Primergy RX2540 M4
CPU Intel Xeon Skylake 2 ソケット 20 コア
2.4GHz Gold 6148 150W
GPU NVIDIA Tesla V100 16GB
Storage M2.SSD 290GB read 0.87GB/s write 1.75GB/s
Memory 192GB DDR4 2666MHz
Python 3.50
CUDA 9.2
3. 1 MLPerf
MLPerf は Google,Intel,Baidu,NVIDIA および数十の
企業が支援する AIベンチマークである.AI専用プロセッサの
多様化に対応し,機械学習分野において異なるアーキテクチャ
間でシステムパフォーマンスを測定できるベンチマークセット
の構築を目的として開発された.
図 1: MLPerf 概要
カテゴリとしては図 1にあるように,画像分類の image clas-
sification,物体認識の single stage detector,object detection,
自然言語処理の recommendation,sentiment analysis,翻訳の
rnn translator,translation,音声認識の speech recognition,
強化学習の reinforcement(図表では IC,SSD,OD,RM,SA,
RT,TL,SR,RIと略記する)といった 9つのベンチマークが
およそ 6つの分野に分けられ,TensorFlow,Pytorch,Caffe2,
Paddleなどのフレームワークが用いられている.本研究ではこ
れらのベンチマークを AIアプリケーションの代表種とし,動
作中のサーバ情報を取得,分析を行う.
3. 2 Zabbix
Zabbixは Zabbix社が開発しているネットワーク管理ソフト
ウェアで,様々なネットワークサービス,サーバ,ネットワー
クハードウェアのステータスを監視・追跡できる. データ格納に
は,本研究では PostgreSQLを用いる.Zabbixは複数の独立
したモジュールで構成されている.サーバ,エージェント,及
びプロキシは C言語で書かれており,フロントエンドは PHP
と JavaScript で実装されている.本研究では図 2 にあるよう
な環境を構築し,情報取得を行う.ベンチマーク実行サーバで
情報取得すると負荷が掛かってしまうため,Zabbix エージェ
ントと情報取得を行う Zabbixサーバを分けている.
図 2: Zabbix 情報取得環境
4. 解 析 結 果
4. 1 取得データの解析
取得した時系列データがサーバ設計にどのように利用できる
かの考察を行う. 本項では例として image classificationのデー
タを取り上げる.
IPMIでは,電力や温度といったインフラ情報の取得ができ
る.図 3は CPU温度の時系列データである.図 4は CPUと
GPU の消費電力の時系列データである.Perf では,OS が取
得できる CPU利用率,メモリ利用量が取得でき,nvidia-smi
では GPUに関連する情報の取得が可能である.これらの情報
はデバイスリソースの静的な最適設計に活用することができる.
図 5は CPUと GPUの利用率の時系列データである.図 6は
CPUと GPUのメモリ利用率の時系列データである.PMUで
は CPUのイベント情報から,命令数,キャッシュミス率から
メモリアクセス数が取得できる.これらの情報は動的な周波数
設計に活用できる.図 8のメモリ intensive指標の時系列デー
タは,次式で求めた値を利用した.
intensive =(local + remote)
inst× 100
ここで,localはMEM LOAD L3 MISS RETIRED.LOCAL
DRAM(all)で得られる L3キャッシュをミスして local DRAM
にいった回数,remoteはMEM LOAD L3 MISS RETIRED
.REMOTE DRAM(all) で得られる L3 キャッシュをミスして
remote DRAMにいった回数,そして instは INST RETIRE
図 3: image classification 温度
図 4: image classification CPU/GPU 消費電力
図 5: image classification CPU/GPU 利用率
D.ANY(all)で得られる命令数である.
これらのグラフの考察を行う.まず温度と CPU電力,メモ
リ intensive指標だがベンチマーク走行開始付近を除きほぼ大
きな変動は見られなかった.しかしキャッシュミスの割合が変
動し各ソケットのメモリ intensiveが増減すると温度と電力も
ほぼ同じタイミング増減しており,ソケット毎の値の変動に法
則性が見られた.CPUと GPUのメモリ利用率は,GPUメモ
リ利用率が開始すぐに 100%近くなっていることと,CPU メ
モリ利用率が実行開始後 70秒頃まで一次関数的に増加してい
たのが 80%に達してからは変化がなくなっていることが特徴と
して挙げられる.このベンチマークの学習用の入力データセッ
トの総サイズは,約 140GB であるのに対し,GPU メモリは
図 6: image classification CPU/GPU メモリ利用率
図 7: image classification Disk I/O アクセス量
図 8: image classification メモリ intensive 指標
16GBと小さいために GPUメモリが 100%近く使われている
ことが分かる.CPU メモリも利用率こそ GPU と比べて低い
が 8割程度利用されており,必要なデータをディスクではなく
転送速度の速いメモリに格納している事が分かる.次に CPU
とGPUの利用率についてだが,GPUの利用率がほぼ 100%に
近いのに対して CPU利用率は 10%を常に下回っている.
よって,image classificationは CPU性能はさほど必要とさ
れず GPU性能を重視しており,また,メモリ容量も重要であ
ると考えられる.
4. 2 メモリ利用量
図 9の縦軸はメモリ利用量の最大値を表している.GPUメ
モリ利用量と比べ,殆どのアプリケーションでは CPUメモリ
図 9: メモリ利用量
利用量が大きくなっている.これはアプリケーションが要求す
るデータサイズに対して GPUメモリ容量が不足しているため
である.容量不足の問題が解決できれば,より効率良くアプリ
ケーションを利用できる.また,画像分類系アプリケーション
や翻訳系アプリケーションはどちらも GPU利用率の高いワー
クロードだが,CPUメモリ利用量に大きな差がある.前者は
データ量が大きい画像データを用いており,後者は比較的デー
タ量の小さいテキストデータを用いているためであると考えら
れる.
4. 3 サーバ比較
世代の異なるサーバでMLPerfを走行させた際の結果との比
較を行う.まず,これまでの実験環境におけるディスクアクセ
ス速度を測定する.表 3は各ベンチマーク実行時のディスクア
クセス速度の最大値である.実験で用いた FUJITSU Primergy
RX2540 M4の最大ディスクアクセス速度は readが 0.87GB/s,
writeが 1.75GB/sである.ベンチマーク実行時のディスクア
,表 3: ディスクアクセス速度
ベンチマーク read(MB/s) write(MB/s)
IC 73.92 111.32
SSD 6.75 10.96
OD 4.66 1.25
RM 2.67 29.26
SA 9.82 0.01
RT 29.50 0.06
TL 26.14 93.90
SR 7.10 8.05
RI 22.13 0.75
クセス速度の最大値がサーバのディスク性能に対して余裕があ
り,また,ディスクアクセスの発生する時間はジョブ時間と比
べて著しく短いため,ディスク性能差によるベンチマークへの
影響は小さいと考えられる.
サーバを変更した際に生じるベンチマーク実行に要する
ジョブ時間の変化に関する考察を行う.その際,表 2 にある
スペックのサーバと表 4 にあるスペックのサーバを用いる.
表 4: 比較用サーバ実験環境
OS CentOS Linux release 7.5.1804 (Core)
サーバ FUJITSU Primergy CX400 M1
CPU Intel Xeon Haswell 2 ソケット 14 コア
2.6GHz E5-2697 145W
GPU NVIDIA Tesla P100 16GB
Storage HDD 270GB read 0.21GB/s write 1.07GB/s
Memory 256GB DDR4 2133MHz
Python 3.50
CUDA 9.2
image classification,single stage detector,object detection,
recommendation,sentiment analysis,rnn translator,trans-
lation,reinforcementのベンチマークで比較を行った.
表 5は表 2のサーバと表 4のサーバでMLPerfを実行した際
に要したジョブ時間の比較結果である.
表 5: ジョブ時間の比較 - サーバ
ベンチマーク Haswell Skylake 比率
IC 4:36:10 4:33:04 0.99
SSD 3:56:42 3:12:18 0.81
OD 2:59:34 2:57:51 0.99
RM 1:12:00 1:09:07 0.96
SA 2:00:12 1:48:14 0.90
RT 4:06:41 4:05:28 1.00
TL 4:37:47 4:29:21 0.97
SR - 15:07:34 -
RI 6:28:00 6:08:37 0.95
CPUの性能を測る意図で 1命令の実行に要するクロック数
を表す CPI の情報取得も行ったが,サーバ変更に伴う法則性
のある大きな変化は見られなかった.
図 10,図 11,図 12,図 13,図 14,図 15,図 16,図 17は
それぞれのサーバで各ベンチマークを実行した際のスレッド毎
のクロック周波数の時系列データである.
sentiment analysisでは特定のスレッドのみクロック周波数
が高い値になっており,これは,周波数が落ちると一部のスレッ
ドのみを使うようになる仕様のためと考えられる.Skylakeと
Haswellの結果を比べるとクロック周波数は時系列に沿ってあ
る程度似た変化が起きているが,最大値や細部に違いがあるこ
とが確認できる.
これらの結果から,CPUを変更することによるクロック周
波数の変化がアプリケーション性能の変化に関係していると考
えられる.
4. 4 GPU/CPU平均利用率
各ベンチマーク実行時のGPU/CPU比率を図 18に示す.ま
た,表 6は CPUと GPUの平均利用率を表している.
図 18の縦軸は 1ソケット当たりの GPU利用率の平均値を
CPU利用率の平均値で割ったものを表している.ここでは,本
研究で利用したサーバは 2 ソケットなので CPU1 ソケット当
たりの利用率に換算している.GPU/CPU比率は CPU1つ当
図 10: image classificationのクロック周波数上: Skylake下:Haswell
図 11: single stage detectorのクロック周波数上: Skylake下:Haswell
たりの GPU の必要数の概算に用いる.表 6 を見るとアプリ
ケーション全体としては GPUネックの傾向にあり,翻訳系ア
プリケーションでは特に GPUの必要量が大きいことが確認で
きる.それに対して,recommendationや reinforcementのよ
うに CPU性能も重要になると考えられるアプリケーションも
見られる.また,系統の異なるアプリケーションではプロセッ
サの利用率に大きく違いがある.
メモリ利用量の結果も踏まえると,容量不足の問題が解決で
きればより効率良いアプリケーションの利用が可能になると推
測できる.
図 12: object detection のクロック周波数 上: Skylake 下:Haswell
図 13: recommendation のクロック周波数 上: Skylake 下:Haswell
4. 5 GPU比較
世代の異なるサーバでMLPerfを走行させた際の結果との比
較を行う.実験に用いた GPUの V100と P100のスペックを
表 7に示す.
表 8は GPUを V100から P100に変更し,それぞれで各ベ
ンチマークを実行した際のジョブ時間の比較結果である.表 6
の GPU平均利用率と比べると,GPU平均利用率が高いベン
チマークほど GPUを変更した際のジョブ時間の変化が大きく
なっている.
これらの結果から GPU 利用率が高いジョブは GPU 性能
によるジョブ性能向上効果が高く,CPU 性能によるジョブ性
図 14: sentiment analysisのクロック周波数 上: Skylake 下:Haswell
図 15: rnn translator のクロック周波数 上: Skylake 下:Haswell
能の差は小さいと推測できるため,AI の種類によって最適な
GPU/CPUリソース設計ができる.
5. まとめと今後の予定
AI ワークロードに特化したコンピュータシステムの最適リ
ソース設計を目的として,MLPerfを用いた AIワークロード
の比較及び特徴分析を行った.
サーバを変更して実験したところ,ディスクアクセス速度や
CPIには大きな変化は見られなかったがクロック周波数には大
きな変化が見られた.この結果から,CPUを変更することに
よるクロック周波数の変化がアプリケーション性能の変化に関
図 16: traslation のクロック周波数 上: Skylake 下:Haswell
図 17: reinforcement のクロック周波数 上: Skylake 下:Haswell
係していると考えた.
GPUを用いた AIアプリケーション群でも GPUの必要量に
大きく差があるが全体的には GPUネックの傾向があり,GPU
利用率が高いジョブは GPU性能によるジョブ性能向上効果が
高く,CPU性能によるジョブ性能の差は小さいと推測した.
また,メモリ利用量はアプリケーションの分野によって大き
く異なっており,メモリも重要であることが分かった.
今後はデータ量や正解データから GPU,メモリ量を自動で
選択できるコンピュータシステムの提案を試みたい.
図 18: GPU/CPU 比率
表 6: CPU/GPU 平均利用率
ベンチマーク CPU 利用率 (%) GPU 利用率 (%)
IC 5.1 95.4
SSD 9.9 59.8
OD 4.9 74.5
RM 6.7 44.3
SA 1.4 82.0
RT 1.5 95.5
TL 1.5 83.9
SR 3.2 65.1
RI 11.4 62.7
表 7: GPU スペック
GPU コア数 MHz FP16 FP32 FP64 メモリ帯域 発表年
P100 3584 1300 18.636 9.318 4.659 720 2016/4
V100 5120 1455 119.19 14.90 7.45 900 2017/5
表 8: ジョブ時間の比較 - GPU
ベンチマーク P100 V100 比率
IC 4:33:04 3:01:13 1.51
SSD 3:12:18 3:09:12 1.02
OD 2:57:51 2:23:26 1.24
RM 1:09:07 1:09:34 0.99
SA 1:48:14 1:22:50 1.31
RT 4:05:28 2:48:18 1.46
TL 4:29:21 2:59:55 1.50
SR 15:07:34 10:53:32 1.39
RI 6:08:37 5:46:00 1.07
謝 辞
本研究の一部はお茶の水女子大学と富士通研究所との共同研
究契約に基づくものである.また,本研究にご協力頂いた富士
通コンピュータテクノロジーズの鈴木孝規氏に深謝する.
文 献[1] Camilo Mora, Randi L Rollins, Katie Taladay, Michael B
Kantar, Mason K Chock, Mio Shimada, and Erik C
Franklin. Bitcoin emissions alone could push global warm-
ing above 2◦c, 2018.
[2] Zhenhua Liu, Yuan Chen, Cullen Bash, Adam Wierman,
Daniel Gmach, Zhikui Wang, Manish Marwah, and Chris
Hyser. Renewable and cooling aware workload management
for sustainable data centers, 2012.
[3] MLPerf v0.5. https://mlperf.org/. Accessed: 2018-12.
[4] Kim Hazelwood, Sarah Bird, David Brooks, Soumith Chin-
tala, Utku Diril, Dmytro Dzhulgakov, Mohamed Fawzy, Bill
Jia, Yangqing Jia, Aditya Kalro, et al. Applied machine
learning at facebook: A datacenter infrastructure perspec-
tive, 2018.
[5] Haswell. https://ark.intel.com/ja/products/codename/42174/Haswell.
Accessed: 2018-12.
[6] HGX-2. https://www.nvidia.com/en-us/data-center/hgx/.
Accessed: 2018-12.
[7] Zabbix. http://www.zabbix.com/. Accessed: 2018-12.
[8] Intel Corporation. Pmu. Intel 64 and IA-32 Archi-
tectures Software Developer’s Manual Volume 3B :Or-
der Number 253669-067US, p.19-3 - p.19-24, p.19-46
- p.19-58. https://software.intel.com/en-us/articles/intel-
sdm. Accessed:2018-12.