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.