GPUの状態を表示する標準ツールでは、1秒から6分の1秒の計測期間にプログラムが1つでも動けば利用率が100%になる。演算ユニット5個のうち1個しか働いていなくても変わらず、製造元の管理ツールでは同じ仕事の稼働率が20%と出る。
米エヌビディアのGPUがどれだけ使われているかを確かめるとき、最もよく見られる数字は、同社の標準の監視ツール「nvidia-smi」が表示する「GPU利用率」である。同社の文書は、この値を「直前の計測期間のうち、GPU上で1つ以上のプログラムが実行されていた時間の割合」と定め、計測期間は製品により1秒から6分の1秒とする (同社の製品文書、2026年9月15日取得)。ここでいうプログラムは、GPU上で多数のスレッドに分けて同時に動かす計算処理を指し、同社は「カーネル」と呼ぶ。この定義には、GPUの中でどれだけの回路が働いたかを数える項目がない。
X上でGPUの内部構造を解説した投稿は、この違いを出発点にしている。筆者は、起動したプログラムが抱える仕事、GPUの演算ユニットに載っている仕事、いますぐ実行できる仕事の3つを同じものとして捉えていたと振り返り、利用率が100%でもテンソルコアや広帯域メモリーの読み書きが限界に達しているとは限らないと書いた。問いを「なぜ100%にならないのか」から「いま何が計算を遅らせているのか」に変え、42ページの手引きにまとめたという。同じ論点を扱って出回った解説図は、「機械」「指標」「ボトルネック」の3部で構成されている。
エヌビディア自身は利用率とは別に、演算ユニットの稼働率や占有率、テンソルコアの稼働率、メモリー読み書きの割合を測る指標を用意している。メタが大規模言語モデル「Llama 3」の事前学習で「GPU利用率」と題して示した数字も、実際の演算量を理論上の上限と比べた38〜43%だった。計算資源の使われ方を数字で評価するときは、その数字が時間を数えているのか、回路を数えているのか、実際に進んだ計算量を数えているのかを先に確かめる必要がある。
61,440本のスレッドを起動しても、演算ユニットに載ってすぐ実行できるのはその一部にとどまる
エヌビディアのプログラミング解説書 (2026年9月9日更新) は、GPUを多数の演算ユニットの集まりとして説明する。同社は演算ユニットを「ストリーミング・マルチプロセッサー」と呼ぶ。各ユニットは、スレッドごとの変数を置くレジスター、共有メモリーと1次キャッシュに振り分けて使う記憶領域、計算を担う回路を持つ。同書は、これはプログラムを書くための考え方で、実際の回路の配置とは異なる場合があると断っている。深層学習向けの性能解説書 (2023年2月1日更新) によると、同社の「A100」は演算ユニットが108個、チップ上の2次キャッシュが40メガバイトで、80ギガバイトの広帯域メモリー (HBM) と毎秒2,039ギガバイトでデータをやり取りする。
プログラムを起動すると、スレッドは同じ大きさのブロックにまとめられ、ブロックごとに演算ユニットへ割り当てられる。演算ユニットはスレッドを32本ずつの組にして動かし、同社はこの組を「ワープ」と呼ぶ。実行の順番を決める仕組みは、次の命令をすぐ実行できるスレッドを持つ組を選ぶ (同書3.2節)。投稿の例では、240ブロックに256本ずつスレッドを持つプログラムはスレッドが61,440本、32本の組が1,920個になる。240×256=61,440、61,440÷32=1,920で、投稿の数字は計算で確かめられる (記者の計算)。
ただし、1,920組が一度にすべて演算ユニットに載るわけではない。同書は、1つの演算ユニットに同時に載せられるブロックと組の数は、プログラムが使うレジスターと共有メモリーの量、ユニットが持つ量で決まり、載せられる数そのものにも上限があると書く。投稿も、ブロックはレジスター、共有メモリー、スレッド数・組の数・ブロック数の上限が許す範囲で演算ユニットに載ると説明する。載った組もメモリーからのデータ、ほかの計算の結果、スレッド間の同期を待つことがあり、実行の順番を決める仕組みが選べるのは、すぐ実行できる組だけである。起動した数、載った数、すぐ実行できる数は、同じプログラムの中で段階ごとに小さくなる。
性能解説書は、GPUは待ちが生じた命令の遅れを、ほかのスレッドの実行に切り替えて目立たなくすると説明し、GPUを使い切るには回路の数よりずっと多いスレッドが必要になると書く。演算ユニットに載っていながら待っている組があるのは、設計上の前提である。
解説図は演算ユニットの中身を、組の実行順を決める仕組み、レジスター、共有メモリーと1次キャッシュ、汎用の演算回路とテンソルコア、2次キャッシュへの接続として描く。ここまでは同社の解説書の説明と合う。図はさらに、ユニットごとの演算回路として単精度と整数、テンソルコア、読み込みと書き込み、特殊関数、テクスチャーなどを並べる。後述の管理ツールも単精度、半精度、テンソルコアの稼働を別々に測るため一部は重なるが、読み込みと書き込み、特殊関数、テクスチャーの回路はエヌビディアの公開文書で確認できなかった (未確認)。
図は32本の組を「足並みをそろえて実行する」単位とし、処理が枝分かれすると順番に実行されると説明する。同書によると、これはエヌビディアが世代ごとに付ける番号が7.0より前のGPUの動き方で、7.0以降のGPUはスレッドごとに実行の状態を持ち、組の途中でも処理を分けたり戻したりできる。組の中のスレッドが常に足並みをそろえる前提で書いたプログラムは、正しく動かないことがあるとも注意している。
GPU利用率はプログラムが1つ動けば100%になり、同じ仕事が演算ユニットの稼働率では20%になる
標準ツールの利用率が数えているのは時間である。計測期間の中でプログラムが1つでも実行されていれば、その時間は「利用」に数える。同じ文書はメモリーの利用率も、GPUのメモリーが読み書きされていた時間の割合と定めており、どれだけのデータが動いたかは数えていない。
エヌビディアのデータセンター向け管理ツール「DCGM」は、これとは別に、GPU全体の稼働率 (識別番号1001)、演算ユニットの稼働率 (1002)、演算ユニットの占有率 (1003)、テンソルコアの稼働率 (1004)、メモリー読み書きの割合 (1005) を測る (同ツールの解説、2026年6月17日更新)。演算ユニットの稼働率は、少なくとも1組がユニット上で動いていた時間の割合を、全ユニットで平均した値である。同ツールの解説は、演算ユニットがN個のGPUで、N個のブロックを使うプログラムが計測期間中ずっと動けば稼働率は100%、使うブロックが5分の1なら20%、N個のブロックで計測期間の5分の1だけ動いた場合も20%になると例を示す。
2つ目の例を標準ツールの定義に当てはめると、計測期間中ずっとプログラムが動いているので利用率は100%になる。演算ユニットが5個のGPUで1ブロック分のプログラムが動き続けると、標準ツールの利用率は100%、管理ツールの稼働率は20%で、同じ仕事の評価に5倍の開きが出る (記者の計算)。3つ目の例では、どちらも20%になる。利用率の数字だけでは、働いている回路の数が違うこの2つの仕事を見分けられない。
演算ユニットの稼働率も、それだけで効率を示すわけではない。管理ツールの解説は、メモリーからのデータを待っている組も「稼働」に数えるとし、稼働率が0.8以上であることは効率よく使うための必要条件だが十分条件ではなく、0.5未満なら効率の悪い使い方の可能性が高いと書く。
解説図はGPU利用率を「すべての演算ユニットでGPUが有用な仕事をしている時間の割合」と説明するが、この定義は標準ツールの文書と合わない。標準ツールはプログラムが実行されていれば時間を数え、何個の演算ユニットが働いたかも、仕事が有用かどうかも見ていない。「すべての演算ユニットで」に近いのは、管理ツールが測る演算ユニットの稼働率のほうである。図がボトルネックの部で書く「GPU利用率が100%でもすべての回路が限界に達しているとは限らない」という注意は定義から導けるが、「利用率はチップ全体と時間の平均である」という説明のうち、チップ全体の平均にあたるのは演算ユニットの稼働率で、標準ツールの利用率にはあてはまらない。
占有率の高さが効率につながるのは、メモリーの読み書きが速さを決める処理に限られる
投稿は占有率を、演算ユニットに載っている組の数を設計上の最大値と比べた数字と説明する。管理ツールの定義も、1つの演算ユニットが同時に扱える組の最大数に対する、載っている組の数の割合で、値は1ブロックのスレッド数、1スレッドが使うレジスター、1ブロックが使う共有メモリーで決まる。解説図は分子を「動いている組の数」と書いて50%の例を示すが、管理ツールは「動いている」(稼働率) と「載っている」(占有率) を別の指標に分けている。待っている組も「載っている」には数えるため、図の書き方では2つの指標が混ざる。
管理ツールの解説は、メモリーとのデータのやり取りが速さを決める処理では占有率が高いほど効率がよいが、計算そのものが速さを決める処理では占有率と効率は必ずしも結びつかないと書く。載っている組が多ければ、データを待つ間にほかの組へ切り替える余地が増えるためとみられる (記者の見立て)。解説図の「占有率100%でも最高の性能は保証されない」はこの説明と合う。一方、「計算が速さを決める処理では組を減らした方が速いことがある」という記述について、管理ツールの解説は「結びつかない」までしか書いておらず、速くなるかどうかは確認できなかった (未確認)。
テンソルコアの稼働率とメモリー読み書きの割合は、時間ではなく、命令を出す周期の回数で数える。テンソルコアの稼働率100%は、計測期間中ずっと1周期おきに行列計算の命令を出している状態にあたり、メモリー読み書きの割合は実際には約80%が上限だという。管理ツールはこれらをすべて同時には測れないため、一部を抜き出して交互に測っており、短い間隔で集計すると0と表示されることがある。値が0でも、仕事が止まっているとは限らない。
モデルが広帯域メモリーに収まっても、速さは読み書きの回数で決まる
投稿は、レジスター、共有メモリー、1次キャッシュ、2次キャッシュ、広帯域メモリーを、速さの順に並んだメモリーの階層というだけでなく、使える範囲や容量、管理の方法、読み書きの仕方がそれぞれ異なるものとして扱う。モデルが広帯域メモリーに収まっても、それで分かるのは収まることだけで、何バイトのデータが動くか、読み出しをまとめられるか、どれだけ使い回せるか、メモリーが速さを決めているかはほとんど分からないという。
性能解説書は、処理の速さの上限はメモリーとのデータのやり取りの速さ、計算の速さ、待ち時間の3つのいずれかで決まるとし、読み書きする1バイトあたりの計算回数で、計算とメモリーのどちらが速さを決めているかを判定する。同書が「V100」を半精度で使う例では、出力4,096・入力1,024の全結合層は一度に512件を処理すれば1バイトあたり315回で計算が速さを決めるが、1件ずつなら1回でメモリーが速さを決める。3×3の最大値プーリングは2.25回、負の値を0にする活性化関数は0.25回、レイヤー正規化は10回未満で、いずれもメモリーが速さを決める。同じ層でも、一度にまとめて処理するデータの量で、速さを決める要因が入れ替わる。
投稿はこの問題に取り組んだ例として、アテンションの計算方法「フラッシュアテンション」を挙げる。アテンションは、トランスフォーマーと呼ぶAIモデルの中で、語どうしの関係の強さを計算する部分を指す。2022年に米スタンフォード大学などの研究者が発表した論文によると、A100の広帯域メモリーは40〜80ギガバイトで読み書きの速さは毎秒1.5〜2.0テラバイト、チップ上の高速なメモリー (SRAM) は108個の演算ユニットそれぞれに192キロバイトで、読み書きの速さは毎秒19テラバイト程度 (推定) である。同論文は、近似に頼らず正確にアテンションを計算しながら、行列を小分けにして広帯域メモリーとSRAMの間の読み書きを減らし、広帯域メモリーへのアクセスを従来の計算方法の最大9分の1にした。
その結果、GPT-2のアテンションの計算は最大7.6倍速くなり、BERTの大型版 (入力512トークン) の学習は性能比較の業界指標MLPerf 1.1の最高記録より15%速く、GPT-2 (入力約1,000トークン) の学習は3倍速くなった。計算の中身は変えず、データの動かし方だけを変えた成果で、投稿の「計算は同じまま、実行の順番を組み替えた」という説明と一致する。GPUのメモリーの階層と、文章を1語ずつ生成する処理がメモリーの速さで頭打ちになる仕組みは、GPUのメモリーの制約を公開仕様から計算した記事で扱った。
テンソルコアが速めるのは行列の掛け算で、BERTの実行時間の39.0%はそれ以外の計算が占める
性能解説書によると、テンソルコアは「ボルタ」世代で導入された行列計算の専用回路で、4×4のような小さな行列の掛け算と足し算をまとめて速める。半精度の2つのデータを要素ごとに足す計算は、テンソルコアではなく汎用の演算回路で実行する。行列計算の性能解説書 (2023年2月1日更新) は、同社の行列計算ライブラリーの11.0版以降ではテンソルコアを常に使えるが、半精度では行列の縦横の大きさが8の倍数 (A100では64の倍数) のとき最も効率がよいと書く。
投稿は、テンソルコアはAIの計算に大きく効くが、モデル全体を動かすわけではなく、合計や最大値を求める集計、データの位置を指定して取り出す処理、要素ごとの計算、スレッド間の同期、メモリー上のデータの移動、プログラムの起動はほかの回路が担うと書く。解説図も、テンソルコアを使わない計算として、要素ごとの計算、数値を確率に置き換えるソフトマックス、レイヤー正規化、アテンションの一部、小さな行列を挙げる。このうち要素ごとの計算はエヌビディアの文書と一致し、レイヤー正規化は同社の表でメモリーが速さを決める計算に分類されている。ソフトマックスについての同社の説明は見つからなかった (未確認)。
行列の掛け算以外にどれだけの時間が使われるかは、トランスフォーマーの学習にかかる時間を測った論文で確かめられる。スイス連邦工科大学チューリッヒ校の研究者が2021年の国際会議で発表した論文によると、BERTの学習では行列の掛け算などが計算回数の99.80%を占めるのに、実行時間では61.0%にとどまる。正規化は計算回数の0.17%で実行時間の25.5%、要素ごとの計算は0.03%で13.5%を占める。行列の掛け算以外が実行時間に占める割合は、25.5%+13.5%で39.0%になる (記者の計算)。論文は、学習の1ステップにかかる時間の3分の1超 (37%) が、メモリーの読み書きが速さを決める計算に使われているとしている。
テンソルコアで行列の掛け算をいくら速くしても、実行時間の4割近くを占める正規化と要素ごとの計算は速くならない。テンソルコアの稼働率が高いことと、学習全体が速く進むことが一致しないのはこのためである。
メタはLlama 3の学習で「GPU利用率」を実際の演算量の比率で示し、値は38〜43%だった
解説図は処理量を、一定の時間に終えた有用な仕事の量とし、実際の処理はメモリー、処理の流れの制御、データの移動のために理論上の最大値に届かないと描く。理論上の最大値は、性能解説書の計算では、演算ユニットの数、クロックの速さ、1クロックあたりの計算回数を掛け合わせて求める。A100は演算ユニット108個とクロック1.41ギガヘルツから、半精度で毎秒31.2京回の浮動小数点演算が上限になる。
メタは2024年7月に公開したLlama 3の論文で、パラメーター数4,050億のモデルの事前学習の実績を示した。GPU 8,192個の構成では1個あたり毎秒43京回の計算を行い、理論上の最大演算量に対する実際の比率は43%だった。GPU 16,384個 (入力8,192トークン) では毎秒40京回で41%、GPU 16,384個 (入力131,072トークン) では毎秒38京回で38%である。43京回を43%で割ると、この比率の前提になったGPU1個あたりの上限は毎秒100京回になる (記者の計算)。
同論文はこの38〜43%を「GPU利用率」と題して示し、41%に下がったのは、全体で一度に学習させるデータ量を保つために、並列に学習させる1グループあたりのデータ量を減らしたためと説明している。1万個を超えるGPUを並べて設定を詰めた学習でも、実際に進んだ計算量は理論上の上限の半分に届かない。この間の標準ツールの利用率は論文に書かれていない (未取得)。
AIデータセンターの計算資源を評価するとき、「GPUの利用率」や「稼働率」として示される数字が、時間の割合なのか、働いた演算ユニットの割合なのか、実際に進んだ計算量の割合なのかで、同じ設備の評価は大きく変わる。標準ツールの100%は、テンソルコアの稼働率とも、メモリー読み書きの割合とも、理論上の上限に対する演算量の比率とも別の量である (記者の見立て)。
GPUが忙しく見えるかどうかは、計測期間の中でプログラムが1つでも動いたかで決まり、計算がどれだけ進むかは、演算ユニットに載ってすぐ実行できる組の数、メモリーとの読み書き、行列の掛け算以外の計算の重さで決まる。利用率100%の画面が示すのは仕事が途切れていないことだけで、いま何が計算を遅らせているかは、演算ユニットの稼働率、占有率、メモリー読み書きの割合、実際の演算量の比率を並べて初めて見えてくる。
投資家向けの個別銘柄レポートと技術デューデリジェンスのご相談はこちら。データ・調査のご相談
💬 この記事へのコメント 0
まだコメントはありません
最初のコメントを投稿してみましょう!⚠️ エラーが発生しました