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, JapanE-mail: †{sayaka-t,oguchi}@ogl.is.ocha.ac.jp,††{shiraishi-ten,shigeto.suzuki,masao.yamamoto,watanabe.y}@fujitsu.com

1. は じ め に性能やリソース情報から効率的にハードウェアを設計・制御する手法は既に用いられている [2]．この制御にあたって CPU 時

AI を用いたアプリケーション利用の増加に伴って，CPU と間やデータベースの変更数，応答時間などの情報を踏まえた上比べて処理性能が高く電力消費の激しい GPU の利用が進みでリソースの配分などを検討しなければならない．しかし，AIICT システムの全体電力が増加傾向にある．特に近年では，プワークロードを走行させるハードウェアリソースの有効活用・ロセッサの高負荷による大量の電力消費がもたらす環境面への運用の制御手法は未だ確立されてない．そこで，ワークロード影響が懸念されている [1]．そのため，システム性能を落とさな毎にサーバ性能の自動チューニングを行う機械学習向けのコンい範囲で ICT 電力を削減していく事が望まれ，システム電力ピュータシステムの構築を考えたい．

削減とアプリ性能の向上のバランスを取り，システムを効率良本研究ではコンピュータシステムの構築に向けて，AI ワー

く稼働させる事がますます重要になる．ワークロードという計

クロードに特化したコンピュータシステムの最適リソース設計

算機に対する負荷または負荷アプリケーションを使った実行時を目的として，機械学習系アプリケーションのパフォーマンス

測定のためのベンチマークである MLPerf [3] を用いた AI ワー

表 1: 各ベンチマークの測定条件

クロードの比較及び特徴分析を行う．

2. 背ベンチマーク

景epoch 数

SEED ジョブ時間(step, iteration)
IC53200

Facebook 社では保有するデータの大部分を機械学習パイプ

1

3:01:13(step)ラインに流しており，GPU と CPU の両方を活用するトレー

SSD

11

1

3:09:12

ニングと CPU を活用するリアルタイム推論でシステムを使いOD

25000

32:23:26(iteration)

分けている．また，リアルタイム推論では入力データが大きいことから必要リソースも異なってくるなど，文献 [4] では機
械学習に基づく AI ワークロード挙動の特徴分析の重要性が問われている．Facebook 製品の機械学習を活用するタスクを簡RM

611:09:34

SA100

11:22:50

RT1

12:48:18

TL17200

12:59:55

素化することを目的とした FBLearner というツールキットが(step)開発されており，機械学習の特徴に合わせて異なるリソース設

SR1

110:53:32

計の CPU サーバ，GPU サーバで処理している．FBLearner

RI4

15:46:00

は FBLearner Feature Store，FBLearner Flow，FBLearner
表 2: 実験環境

Predictor という機械学習パイプラインのさまざまな部分に焦点を当てた 3 つのツールから構成されており，内部ジョブスケOSubuntsu 16.04

ジューラを利用して，GPU と CPU の共有プール上にリソーサーバ

FUJITSU Primergy RX2540 M4スを割り当て，ジョブをスケジュールする. Facebook の機械学

CPUIntel Xeon Skylake 2 ソケット 20 コア

習の訓練の殆どは，この FBLearner プラットフォームを介して実行されている．

2.4GHz Gold 6148 150W
GPUNVIDIA Tesla V100 16GB

Storage M2.SSD 290GB read 0.87GB/s write 1.75GB/s

ボトルネックを分析し，リソースを配分を行う自動ワーク

Memory192GB DDR4 2666MHz

ロード管理機能や受信する接続を均等に分散する機能を備えた

Python3.50

CPU やサーバは既に開発されている．CPU コアやクラスタ

CUDA

9.2

単位で負荷に応じて電圧と動作周波数を切り替える Dynamic

Voltage and Frequncy Scaling を実行する Intel の CPU アー

3. 1 MLPerf

キテクチャ”Haswell” [5]，CPU アーキテクチャや多くの GPU

MLPerf は Google，Intel，Baidu，NVIDIA および数十のを積んで AI ワークロードに特化させた NVIDIA のサーバプ企業が支援する AI ベンチマークである．AI 専用プロセッサのラットフォーム”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]図 1: MLPerf 概要で取得できる情報を分析対象とする．各ベンチマーク毎の特徴分析のためにこれらのコマンドによって CPU や GPU，メモカテゴリとしては図 1 にあるように，画像分類の image clas-

リ，I/O といった情報をベンチマーク実行時に取得する．情報sification，物体認識の single stage detector，object detection，取得は 1 分間隔で行う．各ベンチマークの測定条件を表 1 に示

自然言語処理の recommendation，sentiment analysis，翻訳のす．また，RNN translator のみ学習精度を 15 に変更した．今rnn translator，translation，音声認識の speech recognition，

回は CPU や GPU，メモリの利用量に注目して特徴分析を行っ

強化学習の reinforcement（図表では IC，SSD，OD，RM，SA，た．実験環境は表 2 に示す.

RT，TL，SR，RI と略記する）といった 9 つのベンチマークが以下に本研究で利用するソフトウェアの概要を記す．

およそ 6 つの分野に分けられ，TensorFlow，Pytorch，Caﬀe2，Paddle などのフレームワークが用いられている．本研究ではこれらのベンチマークを AI アプリケーションの代表種とし，動作中のサーバ情報を取得，分析を行う．

3. 2 Zabbix
Zabbix は Zabbix 社が開発しているネットワーク管理ソフト
ウェアで，様々なネットワークサービス，サーバ，ネットワークハードウェアのステータスを監視・追跡できる. データ格納には，本研究では PostgreSQL を用いる．Zabbix は複数の独立したモジュールで構成されている．サーバ，エージェント，及びプロキシは C 言語で書かれており，フロントエンドは PHPと JavaScript で実装されている．本研究では図 2 にあるような環境を構築し，情報取得を行う．ベンチマーク実行サーバで

図 3: image classification 温度

情報取得すると負荷が掛かってしまうため，Zabbix エージェントと情報取得を行う Zabbix サーバを分けている．

図 2: Zabbix 情報取得環境

図 4: image classification CPU/GPU 消費電力

4. 解 析 結 果
4. 1 取得データの解析
取得した時系列データがサーバ設計にどのように利用できるかの考察を行う. 本項では例として image classification のデー
タを取り上げる．

IPMI では，電力や温度といったインフラ情報の取得ができる．図 3 は CPU 温度の時系列データである．図 4 は CPU とGPU の消費電力の時系列データである．Perf では，OS が取得できる CPU 利用率，メモリ利用量が取得でき，nvidia-smi
では GPU に関連する情報の取得が可能である．これらの情報はデバイスリソースの静的な最適設計に活用することができる．

図 5: image classification CPU/GPU 利用率

図 5 は CPU と GPU の利用率の時系列データである．図 6 はCPU と GPU のメモリ利用率の時系列データである．PMU でD.ANY(all) で得られる命令数である．

は CPU のイベント情報から，命令数，キャッシュミス率からこれらのグラフの考察を行う．まず温度と CPU 電力，メモメモリアクセス数が取得できる．これらの情報は動的な周波数

リ intensive 指標だがベンチマーク走行開始付近を除きほぼ大設計に活用できる．図 8 のメモリ intensive 指標の時系列デー

きな変動は見られなかった．しかしキャッシュミスの割合が変タは，次式で求めた値を利用した．

動し各ソケットのメモリ intensive が増減すると温度と電力もintensive =(local + remote)
× 100
inst

ほぼ同じタイミング増減しており，ソケット毎の値の変動に法則性が見られた．CPU と GPU のメモリ利用率は，GPU メモ

ここで，local は MEM LOAD L3 MISS RETIRED.LOCAL

リ利用率が開始すぐに 100%近くなっていることと，CPU メ

DRAM(all) で得られる L3 キャッシュをミスして local DRAM

モリ利用率が実行開始後 70 秒頃まで一次関数的に増加していにいった回数，remote は MEM LOAD L3 MISS RETIREDたのが 80%に達してからは変化がなくなっていることが特徴と.REMOTE DRAM(all) で得られる L3 キャッシュをミスしてして挙げられる．このベンチマークの学習用の入力データセッ

remote DRAM にいった回数，そして inst は INST RETIRE

トの総サイズは，約 140GB であるのに対し，GPU メモリは

図 6: image classification CPU/GPU メモリ利用率
図 9: メモリ利用量

利用量が大きくなっている．これはアプリケーションが要求するデータサイズに対して GPU メモリ容量が不足しているためである．容量不足の問題が解決できれば，より効率良くアプリケーションを利用できる．また，画像分類系アプリケーションや翻訳系アプリケーションはどちらも GPU 利用率の高いワークロードだが，CPU メモリ利用量に大きな差がある．前者はデータ量が大きい画像データを用いており，後者は比較的データ量の小さいテキストデータを用いているためであると考えられる．

4. 3 サーバ比較

図 7: image classification Disk I/O アクセス量

世代の異なるサーバで 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

16GB と小さいために GPU メモリが 100%近く使われている

RT

29.50

0.06

ことが分かる．CPU メモリも利用率こそ GPU と比べて低い

TL

26.14

93.90

が 8 割程度利用されており，必要なデータをディスクではなくSR

7.10

8.05

RI

22.130.75

図 8: image classification メモリ intensive 指標転送速度の速いメモリに格納している事が分かる．次に CPUと GPU の利用率についてだが，GPU の利用率がほぼ 100%に近いのに対して CPU 利用率は 10%を常に下回っている．
よって，image classification は CPU 性能はさほど必要とされず GPU 性能を重視しており，また，メモリ容量も重要であると考えられる．

4. 2 メモリ利用量
図 9 の縦軸はメモリ利用量の最大値を表している．GPU メ
モリ利用量と比べ，殆どのアプリケーションでは CPU メモリ

クセス速度の最大値がサーバのディスク性能に対して余裕があり，また，ディスクアクセスの発生する時間はジョブ時間と比べて著しく短いため，ディスク性能差によるベンチマークへの影響は小さいと考えられる．
サーバを変更した際に生じるベンチマーク実行に要するジョブ時間の変化に関する考察を行う．その際，表 2 にあるスペックのサーバと表 4 にあるスペックのサーバを用いる．

表 4: 比較用サーバ実験環境

OS

CentOS Linux release 7.5.1804 (Core)

サーバ

FUJITSU Primergy CX400 M1

CPUIntel Xeon Haswell 2 ソケット 14 コア
2.6GHz E5-2697 145WGPU

NVIDIA Tesla P100 16GB

Storage HDD 270GB read 0.21GB/s write 1.07GB/s
Memory256GB DDR4 2133MHz

Python

3.50

CUDA

9.2

image classification，single stage detector，object detection，
recommendation，sentiment analysis，rnn translator，translation，reinforcement のベンチマークで比較を行った．
表 5 は表 2 のサーバと表 4 のサーバで MLPerf を実行した際に要したジョブ時間の比較結果である．
表 5: ジョブ時間の比較 - サーバ
ベンチマーク

HaswellSkylake

比率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:001:09:07

0.96

SA

2:00:12

1:48:140.90

RT

4:06:41

4:05:28

1.00

TL

4:37:47

4:29:210.97

SR-

15:07:34-RI

6:28:00

6:08:370.95

図 10: image classification のクロック周波数 上: Skylake 下：Haswell

CPU の性能を測る意図で 1 命令の実行に要するクロック数を表す CPI の情報取得も行ったが，サーバ変更に伴う法則性のある大きな変化は見られなかった．
図 10，図 11，図 12，図 13，図 14，図 15，図 16，図 17 はそれぞれのサーバで各ベンチマークを実行した際のスレッド毎のクロック周波数の時系列データである．

sentiment analysis では特定のスレッドのみクロック周波数が高い値になっており，これは，周波数が落ちると一部のスレッドのみを使うようになる仕様のためと考えられる．Skylake とHaswell の結果を比べるとクロック周波数は時系列に沿ってあ図 11: single stage detector のクロック周波数 上: Skylake 下：Haswell

る程度似た変化が起きているが，最大値や細部に違いがあることが確認できる．

たりの GPU の必要数の概算に用いる．表 6 を見るとアプリ

これらの結果から，CPU を変更することによるクロック周

ケーション全体としては GPU ネックの傾向にあり，翻訳系ア波数の変化がアプリケーション性能の変化に関係していると考

プリケーションでは特に GPU の必要量が大きいことが確認でえられる．

きる．それに対して，recommendation や reinforcement のよ4. 4 GPU/CPU 平均利用率

うに CPU 性能も重要になると考えられるアプリケーションも各ベンチマーク実行時の GPU/CPU 比率を図 18 に示す．ま見られる．また，系統の異なるアプリケーションではプロセッ

た，表 6 は CPU と GPU の平均利用率を表している．

サの利用率に大きく違いがある．

図 18 の縦軸は 1 ソケット当たりの GPU 利用率の平均値をメモリ利用量の結果も踏まえると，容量不足の問題が解決でCPU 利用率の平均値で割ったものを表している．ここでは，本きればより効率良いアプリケーションの利用が可能になると推研究で利用したサーバは 2 ソケットなので CPU1 ソケット当測できる．

たりの利用率に換算している．GPU/CPU 比率は CPU1 つ当図 12: object detection のクロック周波数 上: Skylake 下：Haswell

図 14: sentiment analysis のクロック周波数 上: Skylake 下：Haswell

図 13: recommendation のクロック周波数 上: Skylake 下：Haswell

図 15: rnn translator のクロック周波数 上: Skylake 下：Haswell

4. 5 GPU 比較

能の差は小さいと推測できるため，AI の種類によって最適な世代の異なるサーバで MLPerf を走行させた際の結果との比GPU/CPU リソース設計ができる．

較を行う．実験に用いた GPU の V100 と P100 のスペックを
表 7 に示す．
表 8 は GPU を V100 から P100 に変更し，それぞれで各ベ5. まとめと今後の予定
AI ワークロードに特化したコンピュータシステムの最適リンチマークを実行した際のジョブ時間の比較結果である．表 6

ソース設計を目的として，MLPerf を用いた AI ワークロードの GPU 平均利用率と比べると，GPU 平均利用率が高いベンの比較及び特徴分析を行った．

チマークほど GPU を変更した際のジョブ時間の変化が大きくなっている．

サーバを変更して実験したところ，ディスクアクセス速度やCPI には大きな変化は見られなかったがクロック周波数には大

これらの結果から GPU 利用率が高いジョブは GPU 性能きな変化が見られた．この結果から，CPU を変更することにによるジョブ性能向上効果が高く，CPU 性能によるジョブ性よるクロック周波数の変化がアプリケーション性能の変化に関図 18: GPU/CPU 比率
表 6: CPU/GPU 平均利用率
ベンチマーク

図 16: traslation のクロック周波数 上: Skylake 下：HaswellCPU 利用率 (%) GPU 利用率 (%)

IC5.195.4

SSD

9.9

59.8

OD

4.974.5

RM

6.7

44.3

SA

1.482.0

RT

1.5

95.5

TL

1.583.9

SR

3.2

65.1

RI

11.462.7

表 7: GPU スペック

GPU コア数 MHz

FP16

P1003584

1300

18.636 9.318

FP32 FP64 メモリ帯域
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:340.99

図 17: reinforcement のクロック周波数 上: Skylake 下：Haswell

係していると考えた．

GPU を用いた AI アプリケーション群でも GPU の必要量に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

大きく差があるが全体的には GPU ネックの傾向があり，GPU利用率が高いジョブは GPU 性能によるジョブ性能向上効果が謝

辞高く，CPU 性能によるジョブ性能の差は小さいと推測した．
また，メモリ利用量はアプリケーションの分野によって大きく異なっており，メモリも重要であることが分かった．
今後はデータ量や正解データから GPU，メモリ量を自動で本研究の一部はお茶の水女子大学と富士通研究所との共同研究契約に基づくものである．また，本研究にご協力頂いた富士通コンピュータテクノロジーズの鈴木孝規氏に深謝する．

選択できるコンピュータシステムの提案を試みたい．
文

献[1] Camilo Mora, Randi L Rollins, Katie Taladay, Michael B

[2]

[3]
[4]

[5]
[6]
[7]
[8]

Kantar, Mason K Chock, Mio Shimada, and Erik C
Franklin. Bitcoin emissions alone could push global warming above 2◦ c, 2018.
Zhenhua Liu, Yuan Chen, Cullen Bash, Adam Wierman,
Daniel Gmach, Zhikui Wang, Manish Marwah, and ChrisHyser. Renewable and cooling aware workload management
for sustainable data centers, 2012.
MLPerf v0.5. https://mlperf.org/. Accessed: 2018-12.
Kim Hazelwood, Sarah Bird, David Brooks, Soumith Chintala, Utku Diril, Dmytro Dzhulgakov, Mohamed Fawzy, BillJia, Yangqing Jia, Aditya Kalro, et al. Applied machinelearning at facebook: A datacenter infrastructure perspective, 2018.
Haswell. https://ark.intel.com/ja/products/codename/42174/Haswell.
Accessed: 2018-12.
HGX-2. https://www.nvidia.com/en-us/data-center/hgx/.
Accessed: 2018-12.
Zabbix. http://www.zabbix.com/. Accessed: 2018-12.
Intel Corporation.
Pmu. Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3B :Order Number 253669-067US, p.19-3 - p.19-24, p.19-46- p.19-58. https://software.intel.com/en-us/articles/intelsdm. Accessed:2018-12.