ハードウェア中級 #8 GPU とアクセラレータ — AI 時代の 5 つ目のリソース
このシリーズは一貫して 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回 の使用率・飽和・エラーの枠組みをそのまま当てはめて読みます。
+-------------------------------+----------------------+
| 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、グラフィックス、軽い共有 |
| MIG | GPU をハードウェアレベルで独立したパーティションに分割 | 推論サービスの分離されたマルチテナンシー |
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 つのリソースを絞り込みながら原因を探し、処方を検証する、運用現場の診断プロセスを最初から最後まで追っていきます。