ABCIシステムについて
GPUの環境を整えるのに、オンプレorクラウドかを状況に応じて選択する場合、双方メリット、デメリットがある。オンプレの場合は伝聞だと、運用がとても大変らしい。対して大手クラウドサービス(AWS, GCPなどでGPUインスタンス)を用いる場合は、便利だが、変動費とのトレードオフになる。
今回は第3の選択肢として、2018.8に運用開始したABCIシステムを検討の上で使用してみた1ので、概要を述べる。ABCIとは産業技術総合研究所が構築運用しているAI向けクラウド型計算システムであり、上記のクラウドを使う場合に比べて運用費が1/10くらいに(つまり、一桁！)抑えられるのが一番のメリットだ。
もし、中規模~大規模の機械学習の案件が有り、GPU資源が必要な場合は、一度比較検討してみるのも良いだろう。
なお本記事は、一個人として使用した知見であるので、間違った情報を記載しているかもしれない。より正確な情報は下記の公式ドキュメントを見るか、直接問い合わせをしてみてください。
reference
ABCIのHP https://abci.ai/ja/
document https://portal.abci.ai/docs/ja/
singularity docs https://www.sylabs.io/guides/2.6/user-guide/index.html
ABCIを使うにあたってのメリット・デメリット
まず、いきなりコマンドやら使い方のコツの説明をされても困ると思うので、使用に適するかどうかのメリット・デメリットを上げたいと思う。ソフトウェアスタックは https://abci.ai/ja/about_abci/software.html にある。
メリット
- 同性能でコストがAWSのGPUインスタンスと比べて1/10に抑えられる。GPUがTesla V100で高性能 https://abci.ai/ja/about_abci/computing_resource.html
- クラウドなので、運用コスト(人件費含め)がかからない。
- 現状知名度がそれほど高くないため、ほとんど混雑していない。自身は100+ノード規模を借りて実際に運用基盤を構築しているが、ノードが確保できないことはまったくないといって良い。
- 国産のため、問い合わせは比較的スムーズに行える。
デメリット
- すぐに利用できるわけではない。使用手続き等必要です2 https://abci.ai/ja/how_to_use/custom.html
AWSのインスタンスと異なり、非管理者としての使用に限定されるので、CentOSだが、
yumコマンドなどは使用できない。使用コマンドが少々特殊(yumの代わりにmoduleコマンド、Dockerの代わりにHPC向けのコンテナライブラリSingularityなど)。 Dockerは使用できるものの、特にprivate imageは(docker loginが管理者権限を要求されるので、)直接使用できない(コメント欄で一応可能な旨教えていただきました)。(ただし、後述するように回避方法はある) docker-composeとかも使用できないよ。情報が公式ドキュメントくらいしかない。ABCI自体の利用に関しては日本語で書かれたドキュメントがあるが、Singularityについては、ほぼ英語の公式ドキュメントしかありません。
例えば、Webサービス等の運用の一部として用いるのには不向きかもしれない。
ABCIの概要
前章では、そもそも利用に適しているのかのメリット、デメリットを上げた。本章では、所要の強化学習のための基盤構築をするために知っておくべきor知っておくと捗る点をいくつか述べたいと思う。
ABCIシステムでは、インタラクティブノード上にloginして、計算ノードにjob(scriptの内容)を投げることで、機械学習の計算をさせる。
ログインはsshのトンネリングを経由してインタラクティブノードにログインする3：
# ABCI_USER=... ssh -vvv -L 10022:es:22 -l ${ABCI_USER} as.abci.ai # on the other terminal ## -XC: インタラクティブノードへX転送を有効に ssh -XC -p 10022 -l ${ABCI_USER} localhost # enter interactive node..
インタラクティブノードに入った後は、スクリプトを用意する。自分の場合は、ansibleを利用して各種構成ファイルを自動で準備できるようにした：
# Before starting ansible, prepare the ssh-tunneling. ssh -vvv -L 10022:es:22 -l ${ABCI_USER} as.abci.ai # In the other terminal, we initialize and configure the application related scripts within the ABCI system. ansible-playbook -u ${ABCI_USER} -i ./inventory/abci_hosts abci.yml
. ├── abci.yml | ├── inventory | ├── abci_hosts ├── abci.yml ├── roles ├── abci ├── files │ └── ... └── tasks └── main.yml
- inventory/abci_hosts
[tag_Role_abci] 127.0.0.1 [tag_Role_abci:vars] ansible_port = 10022
# abci.yml - hosts: tag_Role_abci user: ${ABCI_USER} gather_facts: yes roles: - abci
その後、計算ノードにjobを投げる。
# ABCI_GROUP=.. qsub -g ${ABCI_GROUP} -l rt_F=1 script.sh
qsubというコマンドはHPC用のJob Schedulerのコマンドであり、後述する。
ABCIでは、全ての計算ノードとインタラクティブノードは大容量ストレージシステムを共有している4。つまり、任意のファイルは全てのノード間で共有されている。
特に、グループ領域5 (/group1/${ABCI_GROUP} or /group2/${ABCI_GROUP})は(ノード間で共有&)ユーザー間でも共有になっているため、出力ファイル等はここに置くようにすると、他のユーザーもこの出力ファイルを参照できるので良い。
Note) インタラクティブノードはあくまでqsubなどのjob schedulerを走らせるためのフロントであって、機械学習プログラムなどを動かすノードでないので、注意すること。See https://portal.abci.ai/docs/ja/01/#15
使い方の流れとしてはこれが基本だが、コアのプログラムはSingualrityというHPC用のコンテナライブラリを用いる。また、ノードの状態を自動で監視するためにJob Scheduler command(qsub, qstat, qrstat)を使用する。使用方法にコツが有るため、次章で述べる。
ABCIのツール群
https://abci.ai/ja/about_abci/software.html にある中で
- Container Engine(Singularity) doc: https://www.sylabs.io/guides/2.6/user-guide/index.html
- Job Scheduler (Univa Grid Engine) man: https://docs.hpc.qmul.ac.uk/using/man/man1/
あたりの使い方をみていく。Hadoop, Sparkは使用する機会がなかったので、割愛。
- module コマンドについては、公式ドキュメントか、ABCI docsにも、 https://portal.abci.ai/docs/ja/05/ に書いてある。基本的にyumの代わりに用いるイメージで、もうちょっと柔軟なことをしたければ、Singularityというコンテナライブラリを利用して、所要の処理をコンテナでラップすれば良い。
Singularity
Singularityとは、HPC向けのコンテナライブラリで、GPU仮想化も--nvオプションを付ければ対応できる(ちょうど、nvidia-dockerの--runtime=nvidiaと対応している)。ここでは、DockerとSingualrityの技術的な差異については述べずに、専ら利用者の立場からの利用のコツについて述べる。
Note) singularityのversionは2019.4現在、2.6.1しか使用できないことに注意：
$ module display singularity ------------------------------------------------------------------- /apps/modules/modulefiles/runtimes/singularity/2.6.1: module-whatis singularity 2.6.1 conflict singularity setenv SSL_CERT_DIR /apps/modules/modulefiles/runtimes/singularity/certs prepend-path PATH /apps/singularity/2.6.1/bin prepend-path LD_LIBRARY_PATH /apps/singularity/2.6.1/lib prepend-path MANPATH /apps/singularity/2.6.1/share/man -------------------------------------------------------------------
使用する際は、module load singularity/2.6.1とするだけでよい。
なので、本記事ではSingularity 2.6について説明する。(3以降も存在するが、2.6との後方互換性はなかったような気がする。) 詳細は、 https://www.sylabs.io/guides/2.6/user-guide/index.html を確認してほしい。
Singularity imageの作成方法
Singularityのimageを作成、使用する方法はざっくり4つある。3番目の方法が最も学習コストが高いが、確実に動作する。4番目の方法は実務上便利で、コアの機械学習プログラムをこの方法を用いてimageとして作成した：
publicなDocker imageであれば、
singularity pull docker://${docker_image_name}:${version}で6。Singularity Recipe(これはDockerfileのSingularity版に当たるImage作成するための構成ファイル)によってimageを作成する
SingularityHub(これは、DockerHubと似たようなやつ)に所要のImageがあるかどうか探してみる
Docker2Singularityを用いて、Docker imageからSingularity Imageに変換することで、Singularity Imageを使用できるようにする
もし、publicなDocker imageを使用する場合は、singularity pullコマンドが使用できる：
$ singularity pull docker://centos:latest WARNING: pull for Docker Hub is not guaranteed to produce the WARNING: same image on repeated pull. Use Singularity Registry WARNING: (shub://) to pull exactly equivalent images. Docker image path: index.docker.io/library/centos:latest Cache folder set to /home/****/.singularity/docker [1/1] |===================================| 100.0% // <skip> Singularity container built: ./centos-latest.simg Cleaning up... Done. Container is at: ./centos-latest.simg
docker imageの種類によっては、singualrity imageと互換性が合わず、使用できない可能性があるので、その場合は2,3を検討する。また、ABCIシステムは非管理者権限での実行となるので、docker loginを使用できず、privateなdocker imageをpullできない(と思われる)。その時は、4を検討する。
2番目は正攻法なのだが、可搬性が乏しい。というのも、もし、Dockerfileを事前に作成してある状況下において、新たにSingularity Recipeという構成ファイルをSingularityという(ABCIでしか使わないであろう)ライブラリを使用するためだけに作成するのは、時間がかかる。さらに良くないことに、DockerfileとこのSingularity Recipeは結構書き方が異なるので、学習コストがやや高いと感じた。
なので、どうしてもSingualrity Recipeを使わなければならない、という時以外は使用を避けたほうが良いかもしれない。自分自身は、後述する方法でMySQLがdocker imageから変換すると、singualrity上で使用できず、(解決方法が調べても情報ないので)仕方なしにMySQLのSingularity Recipeを作成した7
3番目は、一見すると良い解決方法に見えるが、所要のsingularity imageがあるとは限らないのですよね.. この場合は、4番目、それでもだめなら2番目の方法を使うしかない。
4番目のDocker2Singularityを使用する方法は、主に、既存のprivateなdocker imageがある場合、有効な方法である。自分の場合、C++で使用できるようにtensorflowをsourceからbuildしたいがprivate repositoryで閉じた範囲での使用を検討していたため、Dockerfileを作り、image化し、その後、docker2singularityを用いて、singularity imageに変換して、社内のS3に置くようにしていた8。
Note) 4番目については、コメント欄でご指摘が有り、SINGULARITY_DOCKER_USERNAMEやSINGULARITY_DOCKER_PASSWORDをABCIシステムの環境変数として登録しておくとprivate imageでもdocker imageをsingualrity imageとして引っ張ってこれるみたいです。ただ、個人的には環境変数にpasswordを置くことに対するセキュリティ上の懸念と、自分が返信したコメント欄の理由で、Docker2Singularityを用いる方法を推したいと思います。
各種コマンド
singularityの使用方法例としては、 https://portal.abci.ai/docs/ja/09/ にある。ここでは、自身が使用しているコマンドについてまとめる。
# 普通の使い方 # similar to docker pull ## `shub://aaaa/sample`はsingularity hubからimageを登録できるようにしておく singularity pull --name ${APP_NAME} shub://aaaa/sample # あるいは、ABCIではS3が使用できるので、singularity imageをdownloadする(予め、docker2singularity等でsingularity imageを作成しておく) # aws s3 cp s3://${BUCKET_NAME}/app.simg ${APP_SIMG_PATH} # --nv: GPU仮想化 c.f) https://www.sylabs.io/guides/2.6/user-guide/appendix.html#a-gpu-example singularity exec --nv ${APP_SIMG_PATH} /bin/bash -c "..." # backgroundでの起動(mysqlなど) # https://github.com/ISU-HPC/mysql を改良 # docker pull singularity pull --name $(basename ${MYSQL_SERVER_SIMG_PATH}) shub://bbbb/sample # background で initialization ## --bindはdockerのvolumeに対応 singularity instance.start --bind ${MYSQL_DATADIR}:/var/lib/mysql --bind ${MYSQL_SOCKDIR}:/run/mysqld ${MYSQL_SERVER_SIMG_PATH} mysqld # mysql serverをstart(backgroundで) singularity run instance://mysqld
dockerのcommandとは、厳密には1:1に対応しているわけではないが、似たように扱える。ただし、current directoryはSingularityの場合、${HOME}などで共有されている9。(ちょうどdockerの--volumeと同等の機能)
Job Scheduler
続いて、job schedulerのコマンド群について述べる。 ABCIのdocumentとしては、 https://portal.abci.ai/docs/ja/03/ が対応しているので、基本的な操作というよりは、使い勝手を向上させるためのtipsについて述べる。
qsub
qsubは計算ノードにjobを走らせるのに必要なコマンドで、ABCIシステム上で機械学習プログラムを動かすのに必須のコマンドである。man pageはhttps://docs.hpc.qmul.ac.uk/using/man/man1/ にある。
自身は以下のようにaliasで定義している：
alias qsubg="qsub -g ${ABCI_GROUP} -j y -cwd -terse -M ${EMAIL_ADDRESS} -m sa -o ${LOG_PATH} -e ${LOG_PATH}" alias qsub_full="qsubg -l rt_F=1" alias qsub_gpu1="qsubg -l rt_G.small=1" alias qsub_gpu4="qsubg -l rt_G.large=1"
-Mはemail addressを指定するが、slackに通知させるには、emailというapplicationを用いると、一意のemail addressが新規に発行されるので、それを利用すれば良い。
-mは-Mで指定したemail addressにいつ飛ばすかで、以下のように指定できる：
# man qsubより
-m b|e|a|s|n,...
`b' Mail is sent at the beginning of the job.
`e' Mail is sent at the end of the job.
`a' Mail is sent when the job is aborted or
rescheduled.
`s' Mail is sent when the job is suspended.
`n' No mail is sent.
-terseは標準出力にYour job 218747 ("script.sh") has been submittedと表示される代わりに、job_id(218747)のみが出力されるようになる。
これは、-hold_jidと合わせて、直列でjobを走らせる際に用いると便利：
https://gist.github.com/knknkn1162/2bf87553f586e3d93489dda49197df89
他には、-ar ar_id optionが予約ノードを指定する際に必要だ。予約ノードについては、qrstat commandで詳しく述べるが、事前に予約したノードを使用する際のオプション。
qrsh
qrshはqsubとにているが、qsubとは違い、計算ノード上でコマンド操作を試行するために用いるコマンドである。https://portal.abci.ai/docs/ja/03/#34 に詳しく書かれているので、詳細は省くが、自分自身は以下のような補助関数を定めている：
# ~/.bash_profile function launch() { local TYP=$1 if [ -z $1 ]; then echo "default_type is rt_G.small" TYP="rt_G.small=1" fi qrsh -g ${ABCI_GROUP} -l $TYP -pty yes -display DISPLAY -v xterm /bin/bash } function launch_gpu1() { launch "rt_G.small=1" } function launch_gpu4() { launch "rt_G.large=1" } function launch_full() { launch "rt_F=1" }
qstat
qstatは計算ノードの状態を表示させるためのコマンド。qstat -xmlでxml形式に整形してくれるので、計算ノードの状態を定期的に監視させたい場合などはこのxmlをparseすることになる。自身はxmllintを用いて以下のように用いている：
# cache xml result QSTAT_XML=`qstat -xml` FILTER_TAG='s/<[^>]*>//g' FILTER_ATTR='s/^.*"\(.*\)".*$/\1/' COUNT=$(echo $QSTAT_XML | xmllint --xpath "count(//queue_info/job_list)" -) if [ ${COUNT} -eq 0 ]; then return 1 fi # This is an example of the xml-formmated output: When you exec `qsub` command multiple times, the number of job_list element should be more than one. ## $ qstat -xml | xmllint --xpath "//queue_info/job_list" - ## <job_list state="running"> ## <JB_job_number>228168</JB_job_number> ## <JAT_prio>0.28027</JAT_prio> ## <JB_name>bash</JB_name> ## <JB_owner>****</JB_owner> ## <state>r</state> ## <JAT_start_time>******</JAT_start_time> ## <queue_name>gpu@g0002</queue_name> ## <jclass_name/> ## <slots>10</slots> ## </job_list> for idx in `seq 1 $COUNT`; do JOB_XML=$(echo $QSTAT_XML | xmllint --xpath "//queue_info/job_list[$idx]" -) STATE=$(echo $JOB_XML | xmllint --xpath "//@state" - | sed -e ${FILTER_ATTR}) JOB_NUMBER=$(echo $JOB_XML | xmllint --xpath "//JB_job_number" - | sed -e ${FILTER_TAG}) JOB_NAME=$(echo $JOB_XML | xmllint --xpath "//JB_name" - | sed -e ${FILTER_TAG}) if [ ${STATE} = "running" ]; then STATE="r" fi done
_FILTER_TAG_SPACE='s/<[^>]*>/ /g' # 現在実行中のinstance名(gpu@g0999など)の一覧表示 function get_running_instances() { local QSTAT_XML=$(qstat -xml) echo ${QSTAT_XML} | xmllint --xpath "//job_info/queue_info/job_list/queue_name" - | sed -e "${_FILTER_TAG_SPACE}" | xargs -n1 echo }
qrstat
qsub実行時にノードを取得する場合、72時間しか、連続で使用できない。もし、それ以上連続可動させたい場合は、予約ノードを用いる。予約ノードは前日の21:00まで予約でき、翌日の10:00から30日間連続でノードを専有させることができる10。詳細は、https://portal.abci.ai/docs/ja/03/#36 を参照のこと。
予約ノードはqsubで使用する場合、-ar ${AR_ID}のように指定する11。2019.4現在、一度につき、32台まで同時に予約できる。(その際、一つのAR_IDが得られる。)
もし、32台以上使用したい場合は、複数のAR_IDを発行することで対応する。
qrstatは予約ノードについての情報を入手できるコマンドで、こちらも、qrstat -xmlやqrstat -ar ${AR_ID} -xmlでxml形式で得られる。予約ノードについての詳細は、前小節のqsubの部分と、https://portal.abci.ai/docs/ja/03/#362 を参照のこと。以下のように使用している：
_FILTER_TAG='s/<[^>]*>//g' _FILTER_TAG_SPACE='s/<[^>]*>/ /g' _FILTER_ATTR='s/^.*"\(.*\)".*$/\1/' function get_ar_info() { local QRSTAT_XML=`qrstat -xml` local AR_ID_XPATH="//qrstat/ar_summary" local AR_COUNT=$(echo $QRSTAT_XML | xmllint --xpath "count($AR_ID_XPATH/id)" -) for idx in `seq 1 $AR_COUNT`; do local AR_ID=$(echo $QRSTAT_XML | xmllint --xpath "$AR_ID_XPATH[$idx]/id" - | sed -e ${_FILTER_TAG}) local AR_STATE=$(echo $QRSTAT_XML | xmllint --xpath "$AR_ID_XPATH[$idx]/state" - | sed -e ${_FILTER_TAG}) # check "r": running state or "E": error (effective - running with error) state if [ $AR_STATE = "r" ] || [ $AR_STATE = "E" ]; then local SLOTS=$(qrstat -ar ${AR_ID} -xml | xmllint --xpath "count(//qrstat//ar_summary/granted_slots_list/granted_slots)" -) echo "$AR_ID,$SLOTS" fi done return 0 } function get_running_instances() { local QSTAT_XML=$(qstat -xml) echo ${QSTAT_XML} | xmllint --xpath "//job_info/queue_info/job_list/queue_name" - | sed -e "${_FILTER_TAG_SPACE}" | xargs -n1 echo } function get_nonreserved_running_instances() { local AR_LIST=`get_ar_instances` local RUNNING_LIST=`get_running_instances` for ins in $RUNNING_LIST; do [[ "$AR_LIST" =~ $ins ]] || echo $ins done } function get_ar_instances() { for ar_id in `qrstat -xml | xmllint --xpath "//qrstat/ar_summary/id" - | sed -e "${_FILTER_TAG_SPACE}"`; do qrstat -ar $ar_id -xml | xmllint -xpath "//qrstat/ar_summary/granted_slots_list/granted_slots/@queue_instance" - | sed -e 's/queue_instance=//g' | sed -e 's/"//g' | xargs -n1 echo done }
get_nonreserved_running_instancesはqsub時に予約ノードが使用されているかチェックするコマンドで、もし、予約していないノードが使用されている場合、リストアップするようになっている。
Note) 場合によっては、予約ノードのうちいくつか使用できない状態になっていることがある(state: E)ので、注意すること：
$ qrstat ar-id name owner state start at end at duration sr ---------------------------------------------------------------------------------------------------- 1142 test001 root r 04/**/2019 10:00:00 04/**/2019 09:30:00 335:30:00 false 1139 test001 root r 04/**/2019 10:00:00 04/**/2019 09:30:00 335:30:00 false 1141 test001 root r 04/**/2019 10:00:00 04/**/2019 09:30:00 335:30:00 false 1140 test001 root E 04/**/2019 10:00:00 04/**/2019 09:30:00 335:30:00 false $ qrstat -ar 1140 -------------------------------------------------------------------------------- id 1140 # <skip> message reserved queue gpu@g0940 is disabled
128台予約したが、その内1台使えない事になっている。
ほとんど、使用するにあたっての情報が公式document以外になかったので、かなり詳しめに書きました。AWSなどのクラウドサービスに慣れている方にとっては、多少job schedulerなどが独特だと思うので、最初のメリット、デメリット等勘案しながら、利用するのが良いと思います。
補足
計算ノード( 4GPU/ノード)のGPUスペック詳細(2019/5現在)
function launch_full() { qrsh -g ${ABCI_GROUP} -l rt_F=1 -pty yes -display DISPLAY -v xterm /bin/bash }
として、launch_fullとした結果(uuidなどは**としてます)
$ nvidia-smi Tue May 28 16:01:24 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 410.104 Driver Version: 410.104 CUDA Version: 10.0 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla V100-SXM2... On | 00000000:3D:00.0 Off | 0 | | N/A 33C P0 45W / 300W | 0MiB / 16130MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 1 Tesla V100-SXM2... On | 00000000:3E:00.0 Off | 0 | | N/A 31C P0 43W / 300W | 0MiB / 16130MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 2 Tesla V100-SXM2... On | 00000000:B1:00.0 Off | 0 | | N/A 32C P0 43W / 300W | 0MiB / 16130MiB | 0% Default | +-------------------------------+----------------------+----------------------+ | 3 Tesla V100-SXM2... On | 00000000:B2:00.0 Off | 0 | | N/A 34C P0 43W / 300W | 0MiB / 16130MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ bash-4.2$ nvidia-smi --query-gpu=index,name,uuid,serial --format=csv index, name, uuid, serial 0, Tesla V100-SXM2-16GB, GPU-***1 ** 1, Tesla V100-SXM2-16GB, GPU-***2 , ** 2, Tesla V100-SXM2-16GB, GPU-***3, ** 3, Tesla V100-SXM2-16GB, GPU-***4, ** $ nvidia-smi topo --matrix GPU0 GPU1 GPU2 GPU3 mlx5_0 mlx5_1 CPU Affinity GPU0 X NV2 NV2 NV2 NODE SYS 0-19,40-59 GPU1 NV2 X NV2 NV2 NODE SYS 0-19,40-59 GPU2 NV2 NV2 X NV2 SYS NODE 20-39,60-79 GPU3 NV2 NV2 NV2 X SYS NODE 20-39,60-79 mlx5_0 NODE NODE SYS SYS X SYS mlx5_1 SYS SYS NODE NODE SYS X Legend: X = Self SYS = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI) NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU) PXB = Connection traversing multiple PCIe switches (without traversing the PCIe Host Bridge) PIX = Connection traversing a single PCIe switch NV# = Connection traversing a bonded set of # NVLinks $ nvidia-smi -i 0 -q ==============NVSMI LOG============== Timestamp : Tue May 28 16:06:03 2019 Driver Version : 410.104 CUDA Version : 10.0 Attached GPUs : 4 GPU 00000000:3D:00.0 Product Name : Tesla V100-SXM2-16GB Product Brand : Tesla Display Mode : Enabled Display Active : Disabled Persistence Mode : Enabled Accounting Mode : Disabled Accounting Mode Buffer Size : 4000 Driver Model Current : N/A Pending : N/A Serial Number : *** GPU UUID : *** Minor Number : 0 VBIOS Version : 88.00.4F.00.09 MultiGPU Board : No Board ID : 0x3d00 GPU Part Number : *** Inforom Version Image Version : G503.0201.00.03 OEM Object : 1.1 ECC Object : 5.0 Power Management Object : N/A GPU Operation Mode Current : N/A Pending : N/A GPU Virtualization Mode Virtualization mode : None IBMNPU Relaxed Ordering Mode : N/A PCI Bus : 0x3D Device : 0x00 Domain : 0x0000 Device Id : 0x1DB110DE Bus Id : 00000000:3D:00.0 Sub System Id : 0x121210DE GPU Link Info PCIe Generation Max : 3 Current : 3 Link Width Max : 16x Current : 16x Bridge Chip Type : N/A Firmware : N/A Replays since reset : 0 Tx Throughput : 0 KB/s Rx Throughput : 0 KB/s Fan Speed : N/A Performance State : P0 Clocks Throttle Reasons Idle : Active Applications Clocks Setting : Not Active SW Power Cap : Not Active HW Slowdown : Not Active HW Thermal Slowdown : Not Active HW Power Brake Slowdown : Not Active Sync Boost : Not Active SW Thermal Slowdown : Not Active Display Clock Setting : Not Active FB Memory Usage Total : 16130 MiB Used : 0 MiB Free : 16130 MiB BAR1 Memory Usage Total : 16384 MiB Used : 2 MiB Free : 16382 MiB Compute Mode : Default Utilization Gpu : 0 % Memory : 0 % Encoder : 0 % Decoder : 0 % Encoder Stats Active Sessions : 0 Average FPS : 0 Average Latency : 0 FBC Stats Active Sessions : 0 Average FPS : 0 Average Latency : 0 Ecc Mode Current : Enabled Pending : Enabled ECC Errors Volatile Single Bit Device Memory : 0 Register File : 0 L1 Cache : 0 L2 Cache : 0 Texture Memory : N/A Texture Shared : N/A CBU : N/A Total : 0 Double Bit Device Memory : 0 Register File : 0 L1 Cache : 0 L2 Cache : 0 Texture Memory : N/A Texture Shared : N/A CBU : 0 Total : 0 Aggregate Single Bit Device Memory : 0 Register File : 0 L1 Cache : 0 L2 Cache : 0 Texture Memory : N/A Texture Shared : N/A CBU : N/A Total : 0 Double Bit Device Memory : 0 Register File : 0 L1 Cache : 0 L2 Cache : 0 Texture Memory : N/A Texture Shared : N/A CBU : 0 Total : 0 Retired Pages Single Bit ECC : 0 Double Bit ECC : 0 Pending : No Temperature GPU Current Temp : 33 C GPU Shutdown Temp : 90 C GPU Slowdown Temp : 87 C GPU Max Operating Temp : 83 C Memory Current Temp : 31 C Memory Max Operating Temp : 85 C Power Readings Power Management : Supported Power Draw : 45.24 W Power Limit : 300.00 W Default Power Limit : 300.00 W Enforced Power Limit : 300.00 W Min Power Limit : 150.00 W Max Power Limit : 300.00 W Clocks Graphics : 135 MHz SM : 135 MHz Memory : 877 MHz Video : 555 MHz Applications Clocks Graphics : 1312 MHz Memory : 877 MHz Default Applications Clocks Graphics : 1312 MHz Memory : 877 MHz Max Clocks Graphics : 1530 MHz SM : 1530 MHz Memory : 877 MHz Video : 1372 MHz Max Customer Boost Clocks Graphics : 1530 MHz Clock Policy Auto Boost : N/A Auto Boost Default : N/A Processes : None
-
社内で https://www.globis.co.jp/news/release/20190418_globis.html の件で使用中。↩
-
ここは社内のビジネスサイドの方たちに代行していただいたので、詳細は把握してないです↩
-
https://portal.abci.ai/docs/ja/01/#system-use-overview を参照のこと。↩
-
ABCIから与えられるgroup名によってgroup1 or group2 が変わる↩
-
https://www.sylabs.io/guides/2.6/user-guide/build_a_container.html?highlight=docker#downloading-a-existing-container-from-docker-hub↩
-
勿論、一連の流れを手動でやるのめんどくさかったので、自動化した。↩
-
https://www.sylabs.io/guides/2.6/user-guide/bind_paths_and_mounts.html?highlight=bind#system-defined-bind-points↩
-
利用管理者(ABCI利用の代表者)であれば、予約実行や予約取り消しもコマンドで行えるが、自動化するモチベーションがなかったため、利用者ページから指定するようにした。↩
-
arとはadvance reservationの略らしい。↩
