NVIDIA A100 MIGをLinux Deviceとして管理する

Kota Tsuyuzaki
nttlabs
Published in
Oct 26, 2020

こんにちは. NTT研究所の露崎です. NVIDIAの最新GPU, A100とそれを搭載したDGX A100が発表されてから早半年, 先日のGTC秋のセッションやブログでも触ってみた, 性能を測ってみたといった紹介記事が出てきましたね. NTT研究所でもNTT PCコミュニケーションズ社InnovationLABの環境をお借りして検証を実施しており, その中でA100の目玉機能であるMIG(Multi-Instance GPU)の検証も実施しました.

本ブログではSlurm Workload Manager のようなLinuxのリソースを直接管理するようなスケジューラからこのMIGを制御し, Dockerを使わなくてもMIGデバイス上でプログラムを実行する仕組みやその設定方法について紹介します.

MIG (Multi-Instance GPU)

MIGはA100で初めて実装された機能で一つのA100 GPUをいくつかのインスタンスという単位に分割して利用することができる機能です. 今までのV100 GPUとの性能比較や分割した際の性能, 設定のポイントなどはNTT PCコミュニケーションズ社のBlogにまとまっていますのでぜひ活用の参考にしていただければと思います.

さて, それではこのブログでは何を書くかと言いますとA100 GPUの管理設定方法に関して, もう少し詳しく掘っていこうと思います. 具体的にはタイトルにある通りMIGをLinuxのデバイスとして管理する方法について紹介します.

CSP Multi-Instance GPU(MIG) from NVIDIA white paper

MIGは nvidia-smi でInstanceの分割を行うと以下のようなInstance毎のUUIDが発行され, NVIDIA_VISIBLE_DEVICESCUDA_VISIBLE_DEVICES でこのUUIDを指定することで特定のMIG InstanceをGPU向けのプログラムから利用することができます.

MIG’s UUID

この値はdocker containerやCUDAプログラムの引数には直接利用できますがデフォルトではUUIDと実際のデバイスとの対応はCUDAやcontainer toolkitといったNVIDIAのライブラリで管理されています. このためLinuxの /dev 配下には /dev/nvidia0 のような分割前のGPUが見えており, Linux上から管理することができないため, 例えばHigh Performance Computingのクラスタでよく利用されているSlurm Workload Manager のようなLinuxのリソースを直接管理ようなスケジューラからコントロールすることが難しいという課題があります.

DEVFS based Configuration

これを解決する方法としてA100の DEVFSモードとその設定について紹介します. DEVFSモードは名前のとおり, MIGのインスタンスに対応するデバイスを /dev配下に作成し, Linuxから管理することができるようにする機能で, nvidiaのカーネルモジュールオプションとして有効化することができます. DEVFSの有効化は $modprobe nvidia nv_cap_enable_devfs=1 で設定可能です.この際に他のprocessや他のカーネルモジュールがnvidiaモジュールを参照していると設定ができないので注意が必要です. 以下はDGX A100で有効化されていたモジュールを解決しつつDEVFSモードを有効化した際に利用したスクリプトです.

Enabling DEVFS mode shell script

DEVFSモードを有効化したら次に

$nvidia-modprobe \
-f /proc/driver/nvidia/capabilities/mig/config \
-f /proc/driver/nvidia/capabilities/mig/monitor

を実行し, migconfigとmigmonitorを有効化します. これらが有効化されると /proc/driver/nvidia-caps/mig-minors というファイルが作成され, 準備完了となります.

この状態で nvidia-smi 経由でインスタンスを作成すると対応したMIGインスタンスが /dev/nvidia-caps 配下に作られ, 対応デバイスに /dev 経由でアクセスできるようになります. 前述した/proc/driver/nvidia-caps/mig-minorsはこのインスタンス作成時のデバイス番号とMIGの対応マップになっていて, 例えば以下の出力のように gpu2/gi0/access 273mig-minorsに書かれていた場合, GPU-index2 ( /dev/nvidia2 )のGPU インスタンス 0を作成した時に, 対応する番号(273)のデバイスが /dev/nvidia-caps/nvidia-cap273 という形で作成されるという挙動になっています.

mig-minors example

/proc/driver/nvidia-caps/mig-minors が作成された時点で想定されるGPUインスタンスの組み合わせに対応する番号は確認できるので事前のMIGの分割設計をもとにこのマッピングを使って管理対象のMIGデバイスの設定を検討すると良いでしょう.

参考までにSlurm Workload ManagerでのMIGを用いたGPUの設定を紹介すると以下のようになります.

Slurm’s gres.conf example

この例ではGPU 0, 1, 4, 5, 6, 7はMIGを用いないA100を a100としてそのまま利用しGPU 2, 3に設定したMIGのインスタンスを a100-mig として設定しています. MIGのデバイスはこれまでの解説のとおり /dev/nvidia-caps と既存のデバイスより一階層深いディレクトリ構成にはなりますが, この設定で a100-migを指定して実行すると

この様な形で従来のGPUと同じ様にSlurm Workload Manager上から指定のMIGインスタンスを利用可能なことが確認できています.

設定上の注意点

今回は nvidia driver 450.51.06を用いて検証しました. 現時点で最新である450.51.06では紹介したDEVFSモードはデフォルトで無効になっていますが将来的にはデフォルト有効になる予定とドキュメントには書かれています.

また, DEVFSモードを有効にした状態でdocker containerを利用する場合はlibnvidia-driverのv1.3.0以上を使うようにしてください. v1.3.0でlibnvidia-containerとDEVFSモードの組み合わせを使用した場合にdocker container側からMIGのインスタンスを利用できない不具合への修正が含まれています.

まとめ

今回はNVIDIAの最新GPUであるA100の設定方法としてLinuxのデバイスとして扱う方法を検証した結果を紹介しました. この方法を使えばデバイスベースで管理する様々なシステムへの応用、連携をすることができますのでA100導入の参考にして頂ければと思います.

おわりに

本検証はNTT PCコミュニケーションズ InnovationLabのご協力のもと実施することができました. 深く感謝いたします.

また, 私たちNTTは、オープンソースコミュニティで共に活動する仲間を募集しています. ぜひ弊社 ソフトウェアイノベーションセンタ紹介ページ及び, 採用情報ページをご覧ください.

参考文献

NVIDIA A100 Tensor Core GPU Architecture: https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/nvidia-ampere-architecture-whitepaper.pdf

MIG User Guide: https://docs.nvidia.com/datacenter/tesla/mig-user-guide/index.html

--

--

Kota Tsuyuzaki
nttlabs
Writer for

Research Engineer at Nippon Telegraph and Telephone Corporation (NTT). OpenStack Swift core team member, OpenStack Storlets Project Team Lead.