多くのAIチームの監視ダッシュボードでは、GPU利用率が常に30%以下、あるいはそれ以下に留まっているにもかかわらず、学習タスクはリソースの空きを待ち続けている。これは不可解な現象ではなく、広く蔓延する「測定の幻想」だ。GPU利用率が測定しているのは「計算活動」であり、「容量が本当に利用可能かどうか」ではない。あるタスクがGPU全体を独占したまま、非常に低い利用率を報告することは十分にありうる。
編集注：本稿が論じるのは「GPUが買えない」という問題ではなく、「買ったGPUを使い切れない」という問題である。後者はより見えにくく、より費用がかかる——スケールアウトではオーケストレーション層の問題は解決できないからだ。
利用率は欺く指標である
nvidia-smiやDCGMが報告するGPU利用率は、本質的にはサンプリングウィンドウ内で「少なくとも一つのカーネルが動いていた」時間の割合にすぎない。SMアレイがどれだけ埋まっているか、メモリ帯域幅がどれだけ消費されているか、Tensor Coreが空転していないかは報告されない。データロード待ち、ホスト側の前処理待ち、Pythonインタープリタによるブロック、あるいはコレクティブ通信によるブロックが発生しているタスクは、利用率がほぼゼロに近くなる一方で、デバイス全体をしっかり占有し続ける。
ここで全く異なる二つの概念が生まれる。利用率と割り当て率だ。スケジューラの視点ではこのGPUは100%割り当て済みだが、監視パネルからは「サボっている」ように見える。この大きなギャップこそが「自社データセンターでのGPU不足」の正体だ——GPUの枚数が足りないのではなく、遊んでいる容量を再びスケジューリング可能な容量に変換できていないのだ。
見えない四つのボトルネック
第一に、割り当てと占有。多くのスケジューラはGPU全体を最小割り当て単位としており、タスクは一度GPUを取得すると長期間保持し続ける——途中でI/O待ち、チェックポイント待ち、上下流パイプライン待ちが大量に発生しても同様だ。アイドルは解放を意味しない。これがキュー形成の第一の原因だ。
第二に、VRAMと断片化。HBM容量は演算能力より先に上限に達することが多い。大規模モデル推論のKVキャッシュ、学習時の活性化値、オプティマイザの状態は大量のVRAMを消費し、「演算能力は余っているのにVRAMが逼迫する」というミスマッチを招く。さらに、繰り返しの確保・解放によるVRAM断片化は、本来収容できるはずのタスクを弾いてしまう。
第三に、配置とトポロジー。同一ノード内8枚、同一NVLinkドメインを必要とするタスクは、異なるマシンに散在する8枚の空きGPUでは満たせない。ラック単位・ノード単位のトポロジー、NVLinkとNVSwitchの構成、PCIe帯域幅の差異は、物理的に存在する容量をスケジューラが組み合わせられない形に分断する。クロスノードの断片化は、クラスター規模でのキュー積滞の最も一般的な隠れた要因だ。
第四に、アプリケーション層のボトルネック。データローダーが遅い、トークナイズがCPUを占有している、バッチサイズが小さすぎる、推論リクエストが逐次処理されている、コールドスタートとモデルロードの時間がかかる、チェックポイント書き込みが学習をブロックする——これらはいずれもGPUの問題ではないが、すべて「GPUのアイドル」という形で現れる。典型的な例として、リクエストを1件ずつ推論処理する場合、GPUはほぼ全時間をCPUの入力準備待ちに費やすことになる。
GPU共有：各アプローチのトレードオフ
タイムスライシング（Time-slicing）は最も実装が簡単で、複数プロセスが同一デバイスを交互に使用する。代償はコンテキストスイッチのオーバーヘッド、VRAMの分離がないこと、そして「うるさい隣人」が他のタスクを大幅に遅延させる可能性だ。遅延に敏感な本番推論よりも、開発・デバッグやインタラクティブ用途に適している。
MPS（Multi-Process Service）は複数プロセスが同一CUDAコンテキストを共有し、スイッチのオーバーヘッドを削減して並行スループットを向上させる。ただし分離性が弱く、あるプロセスの異常が同じGPU上の他タスクに波及する可能性がある。
MIG（Multi-Instance GPU）はハードウェアレベルのパーティショニングを提供し、A100/H100を独立したVRAMと障害分離を持つ複数インスタンスに分割できる。安全性は最も高いが、分割粒度が固定でありフレキシビリティに欠け、対応するモデルも限られる。推論や中小規模タスクには適しているが、全帯域幅を必要とする大規模学習には対応できない。
仮想化とコンテナ化スライシング（vGPU/クォータスケジューリング）はソフトウェアによるマルチテナントとクォータ管理を実現し、デプロイの柔軟性は高いが、パフォーマンスオーバーヘッド、ドライバの互換性、運用の複雑さを慎重に評価する必要がある。
これらのアプローチに絶対的な優劣はなく、ワークロードの特性との適合度だけがある。学習タスクは帯域幅とトポロジーを重視し、推論サービスは分離性と弾力性を重視し、開発環境は密度とコストを重視する。
「もう何枚かGPUを買えばいい」が常に正解でない理由
本当のボトルネックはチップ数にあるのではなく、オーケストレーション層にある。
非効率なタスクが1枚のGPUを12時間占有しているなら、スケールアウトは浪費を複製するだけだ。より効果的な道筋はまず指標を変えることだ。単一の「利用率」指標の代わりに、SM占有率、VRAMの使用状況、キュー待機時間、実効スループット（goodput）を用いる。次に、時間軸とトポロジー軸で「利用可能な容量のビュー」を構築し、スケジューラが本当の空きを把握できるようにする。
同時に、クォータと優先度キュー、ギャングスケジューリング、チェックポイントとプリエンプティブスケジューリングを導入し、低優先度タスクを安全に中断してGPU全体を明け渡せるようにする。推論側では、バッチ処理、継続的バッチ処理（continuous batching）、KVキャッシュの再利用によって「CPU待ち」の時間を埋める。業界ではすでに多くの事例が示されており、GPU1枚も追加せずにスケジューリングと共有戦略の最適化だけで、クラスターの実効スループットを数十パーセント向上させることができる。
チームへの実践チェックリスト
第一に、利用率と割り当て率を区別し、両方を同時に監視対象とする。第二に、「トポロジーの不整合により失敗した」スケジューリングリクエストの割合を集計する。第三に、ワークロードごとにSLOを定義し、それに基づいて共有方式を選択する。第四に、長時間にわたり低効率でGPUを占有するタスクに対してアラートと回収ポリシーを設定する。第五に、コールドスタート、データロード、チェックポイントなどGPU非依存の工程を一級の最適化対象として扱う。
GPUの不足には二種類ある。一つは買えない場合、もう一つは買ったのに使いこなせない場合だ。前者は予算で解決し、後者はエンジニアリング能力で解決する。そして算力コストが高騰する今、後者の投資対効果はしばしばより高い。
本稿はAI Newsを翻訳・編集したものである。
© 2026 Winzheng.com 赢政天下 | 转载请注明来源并附原文链接