コンテンツにスキップ
CloudPick

GPUワークロードの特性とリファレンスアーキテクチャ

文書基準: 2026年9月 | この文書は変化の速い領域であり、四半期ごとのレビュー対象です。

概要

Section titled “概要”

この文書は、モデルやデータがGPU 1枚（またはサーバー1台）の容量を超えるときに必要です。その場合、複数のGPUとサーバーを一つにまとめて仕事を分担させる必要があります。

このときよくある誤解が「もっと速いGPUを、もっとたくさん入れればその分だけ速くなる」というものです。実際はそうではありません。複数のGPUが協力するには互いに計算結果を絶えずやり取りする必要があり、GPU数を増やしてもノード間の通信帯域とストレージのスループットが一緒に増えなければ、GPUの遊休時間だけが増え、性能は線形にスケールしません。（料理人をいくら増やしても、厨房が狭く食材を運ぶ通路が詰まっていればその分速くはならないのと同じです。）

そのためGPUインフラ設計は「どのGPUを使うか」よりもGPUをどう繋ぎ、データをどう流すかが肝心です。この文書ではまずワークロードがどの種類かを分け（学習か推論かなど）、それに合った接続構造をノード内 → ノード間 → ストレージの3段階に分けて4ベンダーを比較します。

クラウドを変えても同じもの、ベンダーごとに違うもの

Section titled “クラウドを変えても同じもの、ベンダーごとに違うもの”

クラウドを移すとき何が付いてきて何を学び直すかを先に整理すると、以降の内容が楽になります。

  • そのまま移るもの（移植性の基準線） — 学習・推論コードは大半がCUDAとNCCLという共通基盤の上で動きます。（CUDA = NVIDIA GPUで計算を回す標準ソフトウェア、NCCL = 複数GPUが計算結果をやり取りできるようにする通信ライブラリ。）この2つの上で書いたコードは、クラウドを変えても大体そのまま移ります。
  • ベンダーごとに違うもの — GPUを物理的に繋ぐ高速通信網、サーバーを近くに配置する方法、丸ごと管理してくれるクラスター製品はベンダーごとに名前も実装も異なり、互いに1対1で置き換えられません。

GPUワークロードの3分類

Section titled “GPUワークロードの3分類”

ワークロードごとにボトルネックとなるリソースが異なるため、インフラ設計の出発点はワークロード特性の把握です。

ワークロード 支配的なボトルネック 通信要求 ストレージ要求 代表的なインフラ特性
事前学習 (Pre-training) 演算 + ノード間通信 非常に高い（全ノードが一緒に通信） 高い（大容量データセットのストリーミング） 多数ノード、高速通信網必須、チェックポイント帯域が重要
ファインチューニング (Fine-tuning) 演算 + メモリ 中程度（数ノード以内が多い） 中程度 小～中規模クラスター、単一ノードで可能な場合が多い
推論 (Inference) メモリ帯域 + 遅延 低い（モデル並列時のみ） 低い（重みロード後は常駐） 遅延・スループットのバランス、オートスケール中心

リファレンスアーキテクチャ — 3層通信モデル

Section titled “リファレンスアーキテクチャ — 3層通信モデル”

GPUクラスターでデータが行き交う道は大きく3種類です。各道は異なる技術で作られ、速度も役割も違います。ベンダーを比較するとき、この3層を混ぜて見ると誤った比較になるため、必ず分けて見ます。

graph TB
    subgraph Node["単一ノード (8×GPU)"]
        G1["GPU"] -->|"NVLink / NVSwitch<br/>(ノード内)"| G2["GPU"]
    end
    Node -->|"高速通信ファブリック<br/>(ノード間RDMA)"| Node2["別のノード"]
    Node -->|"並列ファイルシステム / オブジェクトストレージ<br/>(データ・チェックポイント)"| Storage["ストレージ層"]
  • ノード内（1台のサーバー内） — 1台のサーバー内のGPU同士はNVLink/NVSwitchという超高速の専用線で繋がれます。3層の中で最も速く、ベンダーに関係なくNVIDIAハードウェアの特性で決まります。
  • ノード間（サーバーとサーバーの間） — サーバー同士は高速通信ファブリックで繋ぎます。ここでファブリック（fabric）は「サーバー群を密に織り込む専用の高速ネットワーク」を指し、RDMA（Remote Direct Memory Access）は「CPUを介さずサーバーのメモリ同士で直接データをやり取りする」技術です。この層はベンダーごとに実装が異なり、大規模学習の性能を左右します。
  • ストレージ（データ保管庫） — 学習データを読み込み、途中の保存（チェックポイント）を書き、また読み戻す道です。この道が遅いと、GPUがデータを待って遊んでしまいます。

ノード間高速通信ファブリック — ベンダーマッピング

Section titled “ノード間高速通信ファブリック — ベンダーマッピング”
層 AWS Azure Google Cloud OCI
ノード間ファブリック EFA (Elastic Fabric Adapter) InfiniBand (NDシリーズ) GPUDirect-TCPX / RDMA RDMA Cluster Network
通信ライブラリ NCCL NCCL NCCL NCCL
同一概念か 近似対応 — 名称・実装・性能特性が相違 近似対応 近似対応 近似対応

配置・トポロジ — 物理的近接性とNUMA

Section titled “配置・トポロジ — 物理的近接性とNUMA”

ノード間通信の性能を活かすには、2つが揃う必要があります。1つ目は、GPUサーバー同士がデータセンター内で物理的に近くにあること（遠く散らばっていると往復の時間が長くなります）。2つ目は、1台のサーバー内でGPUとそのGPUが使うネットワークカード（NIC）が同じ区画にくっついていること。ここでNUMA（Non-Uniform Memory Access）は「1台のサーバー内でもCPU・メモリが複数の区画に分かれていて、同じ区画同士は速く、別の区画を経由すると遅くなる構造」を指します。

項目 AWS Azure Google Cloud OCI
近接配置 Placement Group (Cluster) Proximity Placement Group + VMSS Compact Placement Policy Cluster Network（近接プロビジョニング内蔵）
NUMA・GPU-NIC整列 インスタンストポロジ公開、NCCLトポロジ認識 トポロジ公開 gVNIC + トポロジ認識 Bare Metalトポロジ固定
  • 近接配置 — 学習ノードを低遅延で束ねるには、近接配置を明示的に要求する必要があります。配置グループなしで散らばったノードはcollective通信の遅延が大きくなり、学習スループットが低下します。
  • NUMA・GPU-NIC affinity — GPUとそのGPUが使用するNICが異なるNUMAノードにあると、データがCPUソケット間のリンクを経由し、遅延・帯域の損失が発生します。NCCLトポロジ認識とプロセスバインディングで整列します。

マネージドGPUクラスター

Section titled “マネージドGPUクラスター”

ノード・ファブリック・スケジューラを自ら組み立てる代わりに、ベンダーが提供するマネージドGPUクラスターを使うと、トポロジ・ヘルスチェック・再起動が事前に統合されます。大規模学習では第一級の選択肢です。

ベンダー マネージドクラスター製品 特徴
AWS SageMaker HyperPod ノードヘルスチェック・自動交換、チェックポイントベースの再開を内蔵
Azure CycleCloud + NDシリーズ HPC/AIクラスターのオーケストレーション、スケジューラ統合（ノード自動交換は非内蔵 — スケジューラ・スクリプトで構成）
Google Cloud AI Hypercomputer / Cluster Director 統合インフラスタック、トポロジ認識プロビジョニング
OCI Supercluster RDMAクラスターネットワーク、大規模GPUの超低遅延接続（Bare Metal）

オーケストレータの選択 — SlurmとKubernetes

Section titled “オーケストレータの選択 — SlurmとKubernetes”

マネージドGPUクラスターを選ぶときに突き当たる分かれ道が、ジョブをどのオーケストレータで配分するかです。大きくSlurmとKubernetesの2つがあり、両者は優劣を競う代替関係ではなく、ワークロードの性格に応じて選ぶ選択肢です。

  • Slurm — HPC（高性能コンピューティング）で長く使われてきたオープンソースのワークロードマネージャ（ジョブスケジューラ）です。ユーザーが「GPUを何枚、何時間使う」というジョブを投入すると、Slurmが優先度順の待ち行列（パーティション）に入れ、空いたノードに配分します。コンテナではなくバッチジョブが中心のため、大規模な事前学習や既存のオンプレHPC・Slurmジョブをそのまま移す場合に摩擦が少なく、投入スクリプトやレシピを再利用できます。
  • Kubernetes — コンテナオーケストレーションの標準で、バッチジョブより常駐するサービス（推論サーバーなど）を扱うのに強いです。学習・推論・サービングを一つのクラスターに混在させる場合や、名前空間の分離・マルチテナンシーが必要な場合に有利で、既存のKubernetesエコシステムをそのまま活用します。ただし分散学習に必要なgang schedulingは別途ツールで補う必要があります（GPU Kubernetesとスケジューリングを参照）。

クラウドベンダーは製品ポートフォリオ全体としてSlurmとKubernetesの両方の経路を提供することが多いものの、同一のマネージドクラスター内で両者を選択できるかどうかは製品ごとに異なります。一部の製品は両者を繋ぐハイブリッド方式も支援します。

オーケストレータ AWS Azure Google Cloud OCI
Slurm (HPC) HyperPod + Slurm (マネージド) CycleCloud Workspace for Slurm (ソリューションテンプレート・顧客テナントにデプロイ) Cluster Director (マネージド)・Cluster Toolkit (自己デプロイ) HPC Cluster Stack + Slurm (自己デプロイ・GPUクラスターネットワーク基盤)
Kubernetes HyperPod + EKS / EKS AKS GKE OKE
ハイブリッド — — Cluster Director — Slurm on GKE (Preview) —

関連文書

Section titled “関連文書”

よくある間違い

Section titled “よくある間違い”
  • ワークロード特性の分析なしに最上位GPU世代から選択 — ファインチューニング・推論に十分なワークロードに大規模事前学習用の構成を導入し、コストが急増
  • 配置グループなしで多数ノード学習 — ノードが物理的に散らばり、collective通信の遅延が大きくなって学習スループットが低下
  • ファブリックをベンダー間で1対1に置き換え — EFA・InfiniBand・RDMAを同一とみなし、性能予測が外れる
  • ストレージ帯域の過小設計 — チェックポイント保存中にGPUがアイドルで待機し、実効利用率が低下

チェックリスト

Section titled “チェックリスト”
  • ワークロードを事前学習/ファインチューニング/推論に分類し、支配的なボトルネック（演算・メモリ・通信）を特定したか
  • ノード内/ノード間/ストレージの3層をそれぞれ分離して設計したか
  • 多数ノード学習時に近接配置（placement group/cluster network）を明示的に要求したか
  • GPU-NICのNUMA整列とNCCLトポロジ認識を確認したか
  • マネージドクラスターと自己構成の移植性・運用トレードオフを評価したか

参考リンク

Section titled “参考リンク”

AWS

Section titled “AWS”

Azure

Section titled “Azure”

Google Cloud

Section titled “Google Cloud”

OCI

Section titled “OCI”

共通

Section titled “共通”