OCI GPU Compute (Bare Metal/VM)

解決する課題

• 大規模言語モデルの学習・ファインチューニングに必要な GPU を確保したい
• 推論・画像生成・HPC（数値計算・シミュレーション）を高速化したい
• 単一ノードに収まらないモデルを、複数 GPU ノードへ分散して学習したい
• ノード間の通信がボトルネックにならない低遅延・高帯域ネットワークが欲しい

主要概念と用語

• GPU シェイプ: BM.GPU 系（ベアメタル）と VM.GPU 系（VM）があり、NVIDIA または AMD の GPU を搭載する。GPU 数、GPU メモリ、CPU、ローカル NVMe、ネットワークはシェイプごとに固定される
• ベアメタル / VM: ベアメタルは仮想化レイヤーなしでホストを専有し全 GPU を使える。VM は GPU をより小さい単位で使える
• クラスタネットワーク: 複数の GPU ノードを RDMA（RoCE） で接続し、低遅延・高帯域でノード間通信を行う専用ネットワーク
• GPU メモリ（VRAM）: GPU 上のメモリ。モデルとバッチが収まるかを左右する最重要リソース
• ノード内 GPU 接続: NVIDIA の NVLink / NVSwitch、AMD の Infinity Fabric などで、1台の複数 GPU を高速に接続する
• GPU ドライバ / CUDA・ROCm: NVIDIA は CUDA、AMD は ROCm を中心に、ドライバ、ランタイム、学習基盤、イメージの対応版をそろえる

仕様・制限・クォータ

• GPU シェイプは世代・GPU 種別ごとに搭載数や GPU メモリが異なる。提供有無はリージョンと可用性ドメインに依存し、全リージョンにあるわけではない
• 現行ベアメタルには NVIDIA A100 / H100 / H200 / B200 / B300 / GB200 / GB300 / L40S / RTX PRO 系と、AMD MI300X / MI355X 系がある。追加・廃止があるため、設計時は ListShapes の結果を正とする
• GPU 容量は需要が高く、サービスリミット（クォータ）の引き上げ申請や容量予約が前提になることが多い
• 全ベアメタル GPU と、VM.GPU.A10 以外の GPU VM は停止中もコンピューティング課金が続く。VM.GPU.A10 は停止で Compute 課金が一時停止するが、ストレージ課金とサービス制限の消費は残る
• マルチノード学習にはクラスタネットワーク対応のシェイプが必要。RDMA を使うには対応シェイプ・イメージ・配置の条件を満たす
• OCPU/メモリの考え方は通常の Compute と共通だが、GPU 数は固定の組み合わせで提供されることが多い

内部の仕組み

OCI の GPU はベアメタルでは仮想化レイヤーなしにホストの全 GPU を専有できます。ノード内は GPU 世代固有の高速接続、複数ノード間は対応シェイプの RDMA を使います。ノード内とノード間で、通信層と対応シェイプが異なる点が重要です。

• クラスタネットワークは RDMA over Converged Ethernet（RoCE） を用い、CPU を介さずに GPU/メモリ間でデータを転送して低遅延・高帯域を実現する
• ノードは近接配置され、集団通信（all-reduce など）の遅延を抑える
• ローカル NVMe を持つシェイプはホスト直結で高速だが揮発性。永続化はブロックボリューム/Object Storage へ

横にスクロール

設計パターン / ベストプラクティス

• まず VM の小さい GPU で検証し、本番の大規模学習でベアメタル/クラスタネットワークへ拡張
• 分散学習はクラスタネットワーク対応シェイプを選び、近接配置で集団通信の遅延を抑える
• データセットや成果物は Object Storage に置き、ノードはステートレスに保って再作成しやすくする
• GPU ドライバと CUDA / ROCm の整合を取るため、対象GPU対応イメージや検証済みのHPC/MLイメージを起点にする
• 高価な GPU を遊ばせないよう、ジョブ単位で起動・終了し、利用状況を監視して稼働率を上げる

運用・監視

• OCI Monitoring でインスタンスのメトリクス、Logging でログを収集
• GPU 使用率・GPU メモリ・温度は nvidia-smi や NVIDIA のエクスポータで取得し、稼働率とボトルネックを把握
• クラスタネットワーク利用時はノード間帯域・遅延と集団通信の効率を確認
• 起動トラブルはインスタンスコンソール接続 / シリアルコンソールで調査。GPU が見えない場合はドライバとイメージの整合を確認

コスト

GPU は単価が高いため、稼働率と中断許容性の設計がコストを大きく左右します。

セキュリティ

• インスタンスプリンシパルで資格情報のハードコードを回避し、Object Storage などへ安全にアクセス
• プライベートサブネット + セキュリティリスト / NSG で公開範囲を最小化し、必要なら Bastion 経由で接続
• ブート/ブロックボリュームは既定で暗号化、鍵は OCI Vault で管理
• モデルや学習データは機微情報になり得るため、コンパートメントと IAM ポリシーで分離・最小権限を徹底

関連サービス・比較

通常の OCI Compute が CPU 中心の汎用 IaaS なのに対し、GPU Compute はそのシェイプ選択肢のうち GPU とクラスタネットワークに特化した使い方です。

ハンズオン / CLI例

# GPU 対応シェイプの一覧を確認（コンパートメント内で利用可能なシェイプ）
oci compute shape list \
  --compartment-id ocid1.compartment.oc1..aaaa \
  --query "data[?contains(shape, 'GPU')].{Shape:shape, GPUs:gpus, GPUDescription:\"gpu-description\"}" \
  --output table

# VM の GPU シェイプでインスタンスを起動（要: 適切な GPU 対応イメージ OCID）
oci compute instance launch \
  --availability-domain "xxxx:AP-TOKYO-1-AD-1" \
  --compartment-id ocid1.compartment.oc1..aaaa \
  --shape "VM.GPU.A10.1" \
  --image-id ocid1.image.oc1..bbbb \
  --subnet-id ocid1.subnet.oc1..cccc \
  --display-name gpu-train

# 起動後、SSH接続してGPUを確認（ベンダーに合わせる）
# NVIDIA: nvidia-smi
# AMD:    rocm-smi