ハードウェア中級 #8 GPU とアクセラレータ — AI 時代の 5 つ目のリソース

読了 6分

このシリーズは一貫して 4 つのリソース (CPU・メモリ・ストレージ・ネットワーク) で世界を見てきました。ところが AI ワークロードがサーバールームに入ってきたことで、5 つ目のリソースが標準装備になりました。GPU です。今回は GPU を運用者の目で見ていきます。内部アーキテクチャの深いところではなく、GPU サーバーを回すときに出会う指標とボトルネック、そして分けて使う問題です。

GPU は何が違うのか — 広く浅い働き手 #

基礎 #2 の CPU は、複雑な仕事を速く処理する少数のコアでした。GPU は逆の設計です。単純な計算しかしないコアを数千個以上敷き詰め、同じ演算を巨大なデータに同時に 適用します。行列の掛け算がまさにそういう仕事で、ディープラーニングの学習と推論は本質的に巨大な行列積の繰り返しなので、GPU が AI の標準装備になったのです。

運用の観点で重要な帰結が 1 つあります。GPU は単独では働けません。データを準備して GPU メモリへ送り、結果を回収する仕事は CPU とメモリ、ストレージの担当です。つまり GPU サーバーのボトルネックが GPU ではない場合があります。GPU 使用率が低い学習サーバーの犯人が、遅いデータロード (ストレージ) や前処理 (CPU) だったというのはよくある話です。4 つのリソースの診断法が、GPU サーバーでもそのまま前提になります。

VRAM — 新しいメモリの壁 #

GPU には自前のメモリである VRAM が付いていて、高性能 GPU は HBM (High Bandwidth Memory、GPU パッケージに積層して帯域幅を最大化したメモリ) を使います。普通の RAM との違いは、容量と帯域幅のトレードオフです。数百 GB〜TB 級まで増やせるシステム RAM と違い、VRAM は数十 GB の水準にとどまる代わりに数 TB/s の帯域幅を出します。数千個のコアを飢えさせないためには、その帯域幅が必要だからです。

この構造が AI 運用の第一の制約を作ります。モデルと作業データが VRAM に収まるか です。モデルが VRAM より大きければ、複数の GPU に分けるか、精度を下げて (量子化) 小さくする必要があります。LLM 推論ではモデルの重みに加えて、同時リクエストのコンテキスト (KV キャッシュ) も VRAM を食うので、同時ユーザー数が VRAM 容量の関数になります。CPU の世界で「メモリ不足 → スワップ」だった問題が、GPU の世界では「VRAM 不足 → 即 OOM エラー」という、より容赦のない形で現れます。

nvidia-smi — GPU の点検表 #

GPU 運用の基本ツールは nvidia-smi です。第1回 の使用率・飽和・エラーの枠組みをそのまま当てはめて読みます。

nvidia-smi (要約)
+-------------------------------+----------------------+
| GPU  Name        Persistence-M | GPU-Util  Memory-Usage |
|  0   H100 80GB   On            |   92%     71GiB/80GiB  |
| Temp  76C   Pwr  610W / 700W   |                        |
+-------------------------------+----------------------+
  • GPU-Util (使用率) — 注意して読むべき指標です。「その瞬間カーネルが動いていたか」を表すだけなので、数千個のコアの一部しか働いていなくても 100% になり得ます。使用率が高いからといって有効に使えているわけではなく、逆に 低ければ確実に問題 (供給のボトルネック) です。
  • Memory-Usage (VRAM) — 上で見た第一の制約のゲージです。上限の近くなら、次のリクエスト 1 つが OOM になり得ます。
  • Temp / Pwr第2回 のスロットリングは GPU にもまったく同じようにあります。温度や電力の上限に達するとクロックが削られます。高密度 GPU サーバーでは冷却は性能項目です。
  • エラー — ECC エラーカウントと XID ログ (ドライバが残す GPU エラーコード) がハードウェア異常のシグナルです。

GPU を分けて使う — パススルー・vGPU・MIG #

GPU は高価で、すべてのワークロードが GPU 1 枚を使い切るわけではありません。そこで 基礎 #7 の仮想化の問いが GPU でも繰り返されます。1 枚を誰に、どう渡すかです。

方式何をするか向く場面
パススルー (passthrough)GPU 1 枚を仮想マシン 1 台にまるごと直結性能損失は最小。分け合いなし
vGPUソフトウェアで時分割して複数の VM に配分VDI、グラフィックス、軽い共有
MIGGPU をハードウェアレベルで独立したパーティションに分割推論サービスの分離されたマルチテナンシー

MIG (Multi-Instance GPU) が運用的に面白いところです。演算ユニットと VRAM、キャッシュまで物理的に切り分けるので、パーティション同士には 第2回 で見たうるさい隣人問題が構造的に存在しません。大きな GPU 1 枚を小さな推論 GPU 7 枚のように売るクラウド商品は、この技術の上に成り立っています。逆に、学習のように GPU 全体を使い切る仕事は、パススルー (クラウドなら GPU 専用インスタンス) が基本です。

複数枚になると、接続がもう 1 つのリソースになります。GPU 間を PCIe よりはるかに広くつなぐ専用インターコネクト (NVLink など) と、サーバー間をつなぐ高速ネットワーク (RDMA) が分散学習の性能を左右します。第4回 の NUMA も戻ってきます。GPU がどのソケットに付いているかで、CPU〜GPU 間のデータ移動コストが変わるからです。

よく出会う落とし穴 #

  • GPU-Util 100% をフル稼働と読む — カーネルが動いていたという意味にすぎません。スループット (秒あたりトークン数、ステップ時間) と一緒に読み、精密な活用度はプロファイリングツールの領域です。
  • GPU だけ買って供給路を見ない — データロード、前処理、ネットワークが GPU を飢えさせれば、高価な GPU が遊びます。GPU 使用率が低ければ、視線を 4 つのリソースに戻します。
  • VRAM を平均で計画する — VRAM は超過の結果が即 OOM なので、平均ではなく最大 (同時リクエストのピーク) で見積もる必要があります。

まとめ #

今回つかんだ絵です。

  • GPU は単純なコア数千個で同じ演算を同時に処理する装置で、供給 (CPU・ストレージ・ネットワーク) が追いついて初めて働きます。
  • VRAM が AI 運用の第一の制約です。モデルと同時リクエストのピークが容量計画の基準です。
  • nvidia-smi も使用率・飽和・エラーの枠組みで読みつつ、GPU-Util の意味を正確に押さえます。温度と電力はスロットリングの予告です。
  • 分けて使う方法はパススルー・vGPU・MIG のスペクトラムで、分離レベルと用途が選択基準です。

次回 — 実践診断ウォークスルー #

部品はすべてそろいました。最終回の「ハードウェア中級 #9 実践:遅くなったサーバーを診断する — シリーズのまとめ」では、シリーズ全体を 1 つの事件に当てはめます。「サービスが遅い」という報告から出発して 4 つのリソースを絞り込みながら原因を探し、処方を検証する、運用現場の診断プロセスを最初から最後まで追っていきます。

X