1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sukimaengineer

RTX PRO 6000 Blackwell を借りて QLoRA する ─ AWS / GCP / Azure を最安リージョンまで比較(机上検討)してみた話

1
Last updated at Posted at 2026-07-17

はじめに

前回、GLM-5.2 の 2-bit 推論をクラウドで回す構成を机上検討しました。

今回はその続編で、条件を3つ変えます。

1つ目、目的を「推論評価」から「QLoRA」に変えます。ローカル LLM を SV/UVM 用に育てるシリーズでずっと先送りにしてきた、自前コーパスでのファインチューニングを、NVIDIA CUDA スタック(bitsandbytes + PEFT/TRL)でクラウド上で回したい、というのが今回の動機です。

2つ目、GPU を Blackwell 世代以降の 96GB ×2 枚または ×4 枚に絞ります。前作は「枯れて在庫が厚く安い A100」という割り切りでしたが、学習用途なので今回は新しめの世代で揃えます。

3つ目、リージョンの縛りを緩めます。前作は「データ主権最優先 → 日本国内固定」でしたが、今回はまず米国・日本まで広げ、調べているうちに想像以上の価格差が見えてきたので、最安リージョン探しまで踏み込みます。CLI ベースの学習ジョブならリージョンの遠さはほぼ効かない、という点も後半で整理します。

想定利用は月100時間程度(平日夜と週末に回すイメージ)です。

本記事の価格はすべて 2026年7月時点の概算です。クラウド GPU の単価・在庫・Spot 価格は頻繁に動きます(AWS の Spot は分単位、GCP の Spot は最大30日ごとに改定)。実際に発注する前に、各社の料金ページ・コンソールで必ず最新値を確認してください。為替は前作に合わせ 1USD≈¥162 で換算しています。

要点(先にまとめ)

  • Blackwell 世代で「96GB の GPU」は実質 RTX PRO 6000 Blackwell(Server Edition)一択です。B200 は 1枚 180GB でハイパースケーラでは 8枚ノード固定、今回の 2〜4枚・月100時間という粒度には合いません。
  • この半年で 3社に出揃いました。GCP G4(2025年10月 GA)、AWS G7e(2026年1月 GA、2月に東京展開)、Azure NC RTX PRO 6000 BSE v6(NCv6、GA 済・Japan East 含む14リージョン)。前作時点では GCP 東京しか選択肢がなかったのが様変わりです。
  • ただし Azure は 1 VM あたり最大2枚(1/4〜2枚の SR-IOV 割当)です。96GB×4 の単一ノードは GCP か AWS の二択になります。
  • 最安リージョンは、瞬間値なら AWS ソウルの Spot($2.88/h、4枚、スナップショット)、価格の読みやすさなら GCP us-central1 の Spot($3.69/h、4枚、改定は最大30日毎)。月100時間で約4.7万〜6.0万円です。
  • 東京プレミアムは AWS オンデマンドで米国比 +45%($16.57 → $24.03)。Azure も Japan East は East US 比 +45% でした。データ所在を日本に固定するコストが具体的な数字で見えます。
  • GCP には DWS Flex-start という中間形態があり、G4 では定価のちょうど半額($2.25/GPU/h)。キュー待ちで容量を確保し、確保後は最長7日、途中で落とされずに走り切る建て付けです。公式ドキュメントがユースケースとして「モデルのファインチューニング」を名指ししています。
  • QLoRA は Trainer のチェックポイント再開がそのまま Spot 耐性になるため、前作の「30秒で落とされる前提の resumable 設計」がほぼそのまま流用でき、しかも保存対象が小さな LoRA アダプタなので前作より条件が良いです。
  • CLI で回す学習ジョブにとってリージョンの遠さはほぼ無関係です。効くのは SSH の体感(RTT)とデータ転送で、前者は mosh/tmux で緩和、後者は並列転送でほぼ解決します。ソウルは Spot 最安と RTT 約30〜40ms を両取りできる面白いポジションです。
  • 96GB 構成で QLoRA できる上限の目安は、1枚で ~70B dense(gpt-oss-120b もぎりぎり)、2枚で ~120B 級、4枚で 235B〜355B 級。GLM-5.2(744B)は NF4 でも重みだけで 400GB を超えるため 4枚でも圏外です。
  • sm_120(RTX PRO 6000 の compute capability 12.0)は、学習に必要な bitsandbytes NF4 + FlashAttention-2 の経路は実用段階ですが、FA3 は Hopper 専用、FA4 は SM100(B200)向けで sm_120 は未対応です。学習は FA2 / SDPA で回す前提になります。

前提1: 「Blackwell で 96GB」は RTX PRO 6000 Blackwell 一択

Blackwell 世代のデータセンター向けラインナップで 96GB という容量は RTX PRO 6000 Blackwell(Server Edition)だけです。B200 は 1枚 180GB と大きいぶん、ハイパースケーラでは 8枚ノード(AWS P6-B200、GCP A4、Azure ND GB200 系)でしか借りられず、たとえば AWS の p6-b200.48xlarge はオンデマンド $113.93/h(us-east-1)、Spot でも $21.6/h 前後からで、月100時間だと Spot でも約35万円になります。加えて P6 はクォータ承認に3〜7営業日、提供も米国リージョンのみです。2〜4枚を月100時間だけ、という今回の粒度には根本的に合わないので、B200 系は「NVLink と HBM3e がどうしても要る規模になったら別記事」として切り分けます。

RTX PRO 6000 Blackwell Server Edition の素性を整理しておきます。

項目 値
メモリ 96GB GDDR7(ECC)
メモリ帯域 約 1.6TB/s(Server Edition。Workstation 版は約 1.8TB/s)
演算 第5世代 Tensor Core、FP4 ネイティブ対応
compute capability 12.0(sm_120)
GPU 間接続 NVLink なし。PCIe Gen5 のみ
消費電力 400〜600W(Server Edition)

NVLink がない、というのがこの GPU の性格を決めています。マルチ GPU の通信はすべて PCIe Gen5 経由で、ここをどう扱うかが各社の差別化ポイントになっています(後述)。

3社の提供状況はこうなりました。

会社 ファミリ GA 枚数レンジ GPU の見え方 マルチ GPU 通信
GCP G4(g4-standard-*) 2025年10月 1/8〜8枚 パススルー相当、MIG 分割可(最大4) 独自のソフトウェア定義 PCIe ファブリックで P2P 対応(96/192/384 の複数枚シェイプ)
AWS G7e(g7e.*) 2026年1月(東京は2月) 1〜8枚 パススルー相当 GPUDirect P2P 対応。マルチノードは EFA + GPUDirect RDMA
Azure NCv6(NC*ds_xl_RTXPRO6000BSE_v6) 2026年(GA 済) 1/4〜2枚 SR-IOV(vGPU)経由 最大2枚。P2P の可否は明記なし(要確認)

GCP は G4 の P2P ファブリックについて、テンソル並列のモデルサービングで最大 168% のスループット向上・41% のレイテンシ低減を謳っており、「30B 未満から 100B 超までの推論とファインチューニングで最高性能」とファインチューニングを明示的にターゲットにしています。AWS の G7e も GPUDirect P2P を公式にサポートします。一方 Azure の NCv6 は SR-IOV 経由で GPU を見せる方式(部分割当を実現するための設計で、一部テレメトリに制限あり)で、そもそも 1 VM 最大2枚なので、4枚構成を組みたい場合は最初から GCP か AWS の二択です。

なお Azure のサイズ名と GPU 枚数の対応は分かりにくいので、Microsoft 公式ドキュメントの値を載せておきます(第三者の価格サイトには誤記があったので注意してください)。

サイズ(ds / lds 共通の枚数) GPU GPU メモリ
NC36ds / NC24lds / NC36lds 1/4枚 24GB
NC72ds / NC72lds 1/2枚 48GB
NC144ds / NC144lds 1枚 96GB
NC288ds / NC288lds 2枚 192GB

前提2: QLoRA に必要なメモリと並列戦略

何が載るか

QLoRA は凍結したベースモデルを NF4(4-bit)で持ち、LoRA アダプタだけを学習します。VRAM の主成分は NF4 重みで、量子化定数込みで実効 4.5bit/パラメータ前後、ざっくり「パラメータ数(B)× 0.56 ≒ 重み GB」で見積もれます。そこに LoRA パラメータと optimizer 状態(rank と対象層数次第で数 GB)、アクティベーション(gradient checkpointing 前提でシーケンス長依存の数〜十数 GB)、CUDA のオーバーヘッドが乗ります。

96GB ×1/×2/×4 に何が載るかの目安です。

ターゲット 総パラメータ NF4 重み概算 1枚(96GB) 2枚(192GB) 4枚(384GB)
Llama 3.3 70B 級 dense 70B 約 40GB ○ ○(DDP で高速化) ○(DDP で高速化)
gpt-oss-120b 117B MoE 約 65GB △ ぎりぎり ○ ○
Qwen3 235B 級 MoE 235B 約 130GB ✕ △ 逼迫 ○
GLM-4.6 355B MoE 約 200GB ✕ ✕ △ FSDP 前提で視野
GLM-5.2 744B MoE 約 420GB ✕ ✕ ✕

注意: あくまで重みベースの粗い概算です。シーケンス長・バッチ・LoRA 対象層で実効必要量は変わります(重み概算 × 1.2〜1.4 を見ておくと安全)。また MoE モデルの bitsandbytes 量子化対応・学習対応はモデルごとに差があるので、Unsloth などの対応状況を個別に確認してください。前作の主役だった GLM-5.2(744B)は、4-bit でも重みだけで 96GB×4 = 384GB を超えるため、今回の構成では QLoRA 圏外です。ここは正直に認めておきます。

枚数と並列方式の関係

マルチ GPU QLoRA は、モデルが1枚に載るかどうかで戦略が変わります。

  • 1枚に載る規模(〜70B dense): 各 GPU にモデルを丸ごと複製する DDP が使えます。学習で同期するのは LoRA アダプタの勾配だけなので、1ステップあたりの通信は数百 MB 程度。PCIe Gen5 でも通信は問題になりにくく、ほぼ枚数分のスループット向上が狙えます。2〜4枚は「容量」ではなく「速度」を買う使い方です。
  • 1枚に載らない規模(120B〜355B 級): FSDP + QLoRA(または DeepSpeed ZeRO-3)で NF4 重みを GPU 間にシャーディングします。この場合、層ごとに凍結重みの all-gather が走るため、GPU 間帯域が効いてきます。NVLink がない RTX PRO 6000 の弱点がここで出ますが、GCP は G4 の P2P ファブリック、AWS は GPUDirect P2P でこの経路を底上げしています(公表値はテンソル並列「推論」の数字なので、FSDP 学習でどこまで効くかは要実測です)。

構成の決め方をフローにするとこうなります。

比較: 3社 × リージョン価格

GCP G4(公式料金、us-central1)

Google の公式料金ページから、G4 の価格体系です。GCP は同じシェイプに4つの買い方があるのが特徴です。

シェイプ GPU オンデマンド DWS Flex-start Spot 1年 CUD
g4-standard-48 1枚 $4.50 $2.25 $0.923 $3.105
g4-standard-96 2枚 $9.00 $4.50 $1.847 $6.21
g4-standard-192 4枚 $18.00 $9.00 $3.693 $12.42
g4-standard-384 8枚 $36.00 $18.00 $7.387 $24.84

注意: 上表は us-central1(アイオワ)の表示値です。GCP はアジアリージョンに最大 15% 程度のプレミアムが乗るのが通例で、東京・ソウルの実値は料金ページのリージョン切替か料金計算ツールで確認してください。ひとつ白状すると、前作で「東京の G4 Spot $3.69」と書いた値は us-central1 の公式 Spot 価格と一致しており、東京の実値はもう少し高い可能性があります。GCP の Spot は改定が最大30日に1回・割引率 60〜91% という仕様なので、AWS のように分単位では動かず、月次予算が読みやすいのが利点です。

AWS G7e(リージョン別)

G7e は 2026年1月に米国東部で GA になり、2月に東京、3月にソウル・スペインへ広がりました。4枚構成 g7e.24xlarge(96 vCPU / 1TB RAM / NVMe 7.6TB)のリージョン別価格です(Spare Cores の 2026年5月末スナップショット。Spot は分単位で変動します)。

リージョン Spot オンデマンド OD の対米プレミアム
オハイオ us-east-2 $4.01 $16.57 ─
オレゴン us-west-2 $5.33 $16.57 ─
バージニア us-east-1 $6.95 $16.57 ─
スペイン eu-south-2 $3.62 $17.46 +5%
ソウル ap-northeast-2 $2.88 $20.37 +23%
東京 ap-northeast-1 $5.34 $24.03 +45%
ロンドン eu-west-2 $28.63 $28.80 +74%

見どころが3つあります。まずソウルの Spot が $2.88/h(GPU あたり $0.72/h)と全体の最安で、しかも日本から最も近いリージョンです。次に東京のオンデマンドは米国比 +45% と明確に割高で、Spot もオレゴン並みです。最後にロンドンは Spot が OD にほぼ張り付いており、実質 Spot 枠がありません。「リージョンを選べば安い」と「選び損ねると高い」が両方はっきり出ています。

2枚構成の g7e.12xlarge は米国 OD $8.29/h、Spot は us-east-1b で $3.29/h(67%引・中断率5%未満)の実績がありました。1枚だけのお試しなら、g7e.8xlarge(1枚・32vCPU/256GB)の Spot 最安ゾーンで $0.58/h という記録もあります。70B 級 QLoRA の入口としては最安級です。

Azure NCv6(リージョン別)

実測値が取れたのは NC72lds(1/2枚・72vCPU/132GB)です。フル1枚(NC144lds)・2枚(NC288lds)は2倍・4倍の線形換算による推定なので、ポータルでの確認を前提にしてください。

リージョン NC72lds 実測(1/2枚) Spot / OD 2枚換算(NC288lds 推定) Spot / OD
East US / East US 2 / West US 2 $0.488 / $2.44 約 $1.95 / $9.76
South Central US $0.586 / $2.93 約 $2.34 / $11.71
Korea Central $0.659 / $3.30 約 $2.64 / $13.18
Japan East $0.708 / $3.54 約 $2.83 / $14.16

米国東部3リージョンが最安で、Japan East は +45%。AWS と同じ比率の東京(日本)プレミアムです。なお NCv6 は AKS / Azure Batch 対応が 2026年8月頃予定、ドライバは R595 系推奨、という段階です。

総合ランキング(96GB×4、月100時間、1USD≈¥162)

順位 構成 時間単価 月100h ひとこと
1 AWS ソウル Spot $2.88 $288 ≈ ¥4.7万 瞬間最安 + 日本から最寄り。ただし変動大
2 AWS スペイン Spot $3.62 $362 ≈ ¥5.9万 欧州の穴場
3 GCP us-central1 Spot $3.69 $369 ≈ ¥6.0万 改定30日毎で予算が読める
4 AWS オハイオ Spot $4.01 $401 ≈ ¥6.5万 米国内最安 Spot
5 AWS 東京 Spot $5.34 $534 ≈ ¥8.7万 国内固定の実質最安
6 GCP Flex-start(us-central1) $9.00 $900 ≈ ¥14.6万 中断なし。長い run 用の保険
7 AWS 米国 OD $16.57 $1,657 ≈ ¥26.8万 フォールバック用
参考 GCP us-central1 OD $18.00 $1,800 ≈ ¥29.2万 ─
参考 AWS 東京 OD $24.03 $2,403 ≈ ¥38.9万 東京プレミアムの実態

2枚構成では GCP us-central1 Spot が $1.85/h(月 $185 ≈ ¥3.0万)で頭ひとつ抜けており、Azure East US の Spot 推定 $1.95/h(≈ ¥3.2万)、AWS us-east-1 Spot $3.29/h(≈ ¥5.3万)が続きます。

面白いのは、ハイパースケーラの Spot(GPU あたり $0.7〜1.0/h)が、ネオクラウドのオンデマンド(RTX PRO 6000 で Vast $1.42、RunPod $1.69〜2.09、Nebius $1.80 前後)を下回っている点です。前作では「ネオクラウドはハイパースケーラの 1/3〜1/5」でしたが、この GPU に関しては自サブスク・大手データセンターのまま最安、という逆転が起きています。ちなみに B200 側は、GCP A4(B200×8)がオンデマンド販売なしで Flex-start $64.44/h・Spot $34.24/h という提供形態になっており、8枚固定という点も含めて今回の用途とは土俵が違います。

Spot・Flex-start・オンデマンドの使い分け

QLoRA は Spot と構造的に相性が良い

前作の推論評価では「評価バッチの進捗を Blob に逐次記録して resumable にする」仕組みを自作しました。QLoRA では、これに相当するものが Hugging Face Trainer に最初から入っています。save_steps ごとのチェックポイント保存と resume_from_checkpoint です。しかも保存対象は LoRA アダプタ+optimizer 状態で、フルモデルと違って数十MB〜数GB と小さく、高頻度保存のコストがほぼゼロ。ベースモデルは読み取り専用なので再起動時にオブジェクトストレージから再ステージングするだけです。落とされる前提の設計が、前作より少ない工作量で成立します。

各社の退去通知はこうなっています。

方式 事前通知 検知方法
GCP Spot 30秒前 metadata の preempted フラグ / ACPI シャットダウン信号
AWS Spot 2分前 IMDS の spot/instance-action / EventBridge イベント
Azure Spot 30秒前 Scheduled Events(前作参照)
GCP Flex-start 期間満了のみ maxRunDuration を自分で決める(途中退去なし)

Flex-start という中間の道具

今回の調査で一番の発見は GCP の DWS Flex-start でした。仕様を要約すると次の通りです。

  • provisioning model に FLEX_START を指定して VM を作ると、DWS のキューに入り、容量が確保でき次第起動します(確保できなければ作成要求は失敗し、リトライします)。
  • 起動後は指定した実行時間(600秒〜最長7日)を走り切る建て付けで、Spot のように途中で落とされる前提が要りません。早く終われば削除して、使った分だけの支払いです。
  • 価格は G4 で定価のちょうど半額($2.25/GPU/h)。公式ドキュメントがユースケースとして「モデルのファインチューニング」「バッチ推論」を名指ししています。
  • クォータはプリエンプティブル側の枠を消費するという解説があります(要確認)。7日を超える用途は DWS のカレンダーモード(将来予約)側です。

つまり運用は「普段の実験は Spot、チェックポイントをまたぎたくない本番の長い run だけ Flex-start」という二段構えが組めます。前作で「長い1本の run だけは別扱い」と書いた問題への、プラットフォーム側の回答がこれだと理解しました。

学習ループの全体像

GCP での最小限のコマンド例です(フラグ名・イメージ名はバージョンで変わる可能性があるので、実行前に help と images list で確認してください)。

# RTX PRO 6000 が置いてあるゾーンの確認
gcloud compute accelerator-types list \
  --filter="name=nvidia-rtx-pro-6000" \
  --format="table(zone, name)"

# g4-standard-192(4枚)を Spot で起動する例
gcloud compute instances create qlora-spot \
  --zone=us-central1-b \
  --machine-type=g4-standard-192 \
  --provisioning-model=SPOT \
  --instance-termination-action=DELETE \
  --image-project=deeplearning-platform-release \
  --image-family=common-cu128-ubuntu-2204-py310 \
  --boot-disk-size=200GB

# 落とされたくない本番 run は Flex-start で(最長7日)
gcloud compute instances create qlora-flex \
  --zone=us-central1-b \
  --machine-type=g4-standard-192 \
  --provisioning-model=FLEX_START \
  --max-run-duration=36000s \
  --instance-termination-action=DELETE \
  --image-project=deeplearning-platform-release \
  --image-family=common-cu128-ubuntu-2204-py310

退去監視は前作の Azure 版とほぼ同型で、GCP はメタデータの preempted フラグを見ます。

#!/usr/bin/env bash
# preempt-watch-gcp.sh : 30秒前通知を拾い、最後の同期だけ確実に行う
ENDPOINT="http://metadata.google.internal/computeMetadata/v1/instance/preempted"
while true; do
  P=$(curl -s -H "Metadata-Flavor: Google" "$ENDPOINT")
  if [ "$P" = "TRUE" ]; then
    echo "$(date -Is) preemption -> final sync"
    # アダプタは save_steps で逐次保存済み。ここでは同期のみ
    gsutil -m rsync -r /mnt/localssd/outputs gs://my-bucket/qlora-ckpt/
    break
  fi
  sleep 2
done

Trainer 側は逐次保存と再開を仕込んでおくだけです。

from transformers import TrainingArguments

args = TrainingArguments(
    output_dir="/mnt/localssd/outputs",
    save_steps=50,          # LoRA アダプタは小さいので高頻度でよい
    save_total_limit=3,
    # ...
)
# 再起動後はチェックポイントから続きを学習
trainer.train(resume_from_checkpoint=True)

30秒で書けるのは小さなアダプタだからこそで、ここが「240GB の状態を持つ推論サーバを守る」前作より条件が良い点です。

リージョンとレイテンシ: CLI 学習ならほぼ自由

「東京以外だとレスポンスが心配」という点は、結論から言うとこの用途ではほぼ問題になりません。QLoRA の学習ジョブは完全にサーバ側で走るバッチ処理で、リージョンの遠さがジョブの速度に影響することはないからです。効いてくるのは次の3箇所だけです。

1つ目は SSH の対話操作で、エコーバック遅延 ≒ RTT です。日本からの目安(経路依存の概数)はこうなります。

リージョン RTT 目安 体感
ソウル 約 30〜40ms ほぼ気づかない
米国西部(オレゴン) 約 100〜130ms わずかに感じる
米国中部(アイオワ) 約 130〜160ms ワンテンポ
米国東部(バージニア/オハイオ) 約 150〜180ms ワンテンポ。mosh 推奨
欧州(スペイン) 約 230〜280ms 対話はやや重い。バッチなら無関係

150ms を超えるとタイピングに遅れを感じますが、mosh(ローカルエコー+回線断に強い)か tmux 常用でほぼ解消します。Spot の切断・再接続とも相性の良い組み合わせです。

2つ目はデータ転送で、これはレイテンシではなく帯域とセッション数の問題です。長距離の単一 TCP はスループットが落ちるので、gsutil -m / aws s3 のマルチパート / s5cmd / rclone の並列転送を使えば距離の影響はほぼ消えます。そもそもベースモデルの取得はクラウド側から Hugging Face を叩くので手元の回線は通らず、米国リージョンのほうがむしろ速いくらいです。学習コーパス(数 GB 想定)は一度上げれば済みます。

3つ目は帰り道の egress です。持ち帰るのを LoRA アダプタだけ(数十MB〜数GB)にすれば誤差ですが、マージ済みモデル(数百GB)を都度ダウンロードすると AWS で $0.09/GB(月100GB 無料枠超過後)が効いてきます。マージと評価はクラウド側で済ませ、アダプタだけ持ち帰るのが基本です。

逆に、学習したモデルを対話型のコーディングエージェントとしてサービングする段になると、RTT がそのまま TTFT に乗り、エージェントの多段呼び出しでは往復回数分積み上がります。「学習は最安リージョン、サービングするなら近場」という使い分けが素直で、その意味でもソウルは Spot 最安と RTT 約30ms を両取りできる稀有なポジションです。

主権の再整理

前作の序列を今回の条件でアップデートします。

選択肢 所在/法域 今回の位置づけ
ローカル実行 手元・日本 96GB×4 は調達コスト的に消えた(カード実売 $13,250)
東京ハイパースケーラ 日本 前作の本命。最安構成比 +45% 前後のプレミアム
ソウル/米国ハイパースケーラ 韓国/米国 今回解禁。自サブスク・自分の契約・自分の鍵のまま、物理所在だけ譲る
ネオクラウド 各国(不明含む) Spot 逆転で価格優位が薄れ、採る理由が減った
中国系 中国 対象外(前作参照)

注意したいのは、学習は推論より「出すもの」が増える点です。前作はプロンプトと生成結果でしたが、今回は学習コーパスそのものをクラウドのストレージに置きます。私の場合、コーパスは自作 OSS(sukimasim など)と公開仕様から作った自前データに限定し、業務で触るコードは一切含めない前提です。そのうえで、バケットは自サブスク内・保存時暗号化・リージョン固定・使い終わったら削除、を徹底します。物理所在を米国・韓国にすることでその国の法域の影響(域外適用の議論を含む)がゼロになるわけではありませんが、契約主体・アカウント・鍵を自分で握る「自前ホスト」の段は維持されるので、序列としては Western API(第三者ホスト)より上、東京自サブスクより半歩下、と整理しています。私は法律の専門家ではないので、機微なデータを扱う場合は各自の規程と一次情報で判断してください。

sm_120 ソフトウェアスタックの現在地

RTX PRO 6000 は compute capability 12.0(sm_120)で、同じ Blackwell でも B200(SM100)とは別物として扱われます。QLoRA に関係する範囲の現状です。

  • 基盤: CUDA 12.8 以降 + 新しめの PyTorch(cu128/cu130 系ホイール)が前提です。古い PyTorch は sm_90 までしか含まず起動できません。
  • QLoRA 本体: bitsandbytes の NF4 + PEFT/TRL/accelerate は Blackwell で動作します。NVIDIA の公式ブログが Unsloth による Blackwell 世代での QLoRA(gpt-oss-20b/120b の bnb-4bit)を紹介しており、経路としては枯れてきました。
  • Attention: 実用線は FlashAttention-2 です。vLLM も sm_120 では FA2 にフォールバックする実装になっています。FA3 は Hopper 専用、FA4 は SM100(B200/GB200)向けで sm_120 は未対応(tcgen05/TMEM がない等ハードが異なるため)。コミュニティが upstream の PR を束ねた sm_120 向け配布を出している段階で、head_dim > 128 のモデルは FA2 経路になる、といった制約もあります。学習は FA2 か PyTorch SDPA で回す前提にしておけば安全です。
  • 推論側の注意: 学習後に同じ箱で vLLM を立てて動作確認する場合、sm_120 は NVFP4 ネイティブカーネルの選択に穴があり Marlin フォールバックになる報告や、大型 MoE では SGLang の Blackwell 用イメージが現実解という報告があります。QLoRA(bnb NF4)には影響しませんが、頭の片隅に。
  • ドライバ: R580〜R595 世代です(Azure は R595 系を推奨と明記)。

構成例(検討してみた案)

以上を踏まえた本命はこれです。

GCP us-central1 の g4-standard-192(RTX PRO 6000 ×4)を Spot で使い、落とせない長い run だけ Flex-start に切り替える

  • コスト: Spot $3.69/h × 100h ≈ 月 ¥6.0万。Flex-start に切り替えた分は $9.00/h。
  • 理由1: Spot の改定が最大30日毎で、月次予算が読みやすい(AWS Spot は分単位で動く)。
  • 理由2: G4 の P2P ファブリックがファインチューニングを名指しで最適化対象にしており、FSDP の all-gather が PCIe 律速になる大型モデルで効く期待がある(要実測)。
  • 理由3: Spot ⇔ Flex-start ⇔ OD のフォールバックが同一プラットフォーム・同一イメージで完結する。
  • 理由4: 1/8〜8枚の細かい粒度で、2枚(96)と4枚(192)を行き来しやすい。

対抗はこの2つです。

  • AWS ソウル g7e.24xlarge Spot(時点 $2.88/h、月 ¥4.7万): 瞬間最安で、RTT 約30〜40ms と対話も快適。Spot 変動と在庫は要ウォッチで、価格が跳ねたらオハイオ($4.01/h)へ逃がす前提。
  • 国内固定要件なら AWS 東京 Spot($5.34/h、月 ¥8.7万)か GCP 東京 Spot(実値要確認)。前作の Azure A100 Spot(月160h で ¥8.5万)と比べても、Blackwell 4枚が月100h でこの水準なら悪くない選択です。

発注前のチェックリストです。

  • クォータ申請: GCP はリージョン別の GPU クォータ(Spot はプリエンプティブル側)、AWS は G 系 Spot vCPU 枠(g7e.24xlarge で 96 vCPU)、Azure は NCdsRTXPRO6000BSEv6XL ファミリの vCPU 枠(初期値ゼロ、Spot は別枠)。
  • ゾーン在庫: gcloud compute accelerator-types list と、AWS のコンソール(Spot placement score)で事前確認。
  • モデル配置: 学習用なので GGUF ではなく Hugging Face 形式(safetensors)を同一リージョンの GCS/S3 に置き、起動時にローカル NVMe へステージング。
  • イメージ: CUDA 12.8 系 + PyTorch + bitsandbytes を焼いたカスタムイメージで cold start を短縮(前作⑤と同じ発想)。

残る不確定要素(要実測)

机上検討で埋めきれなかった点を正直に挙げておきます。

  1. FSDP + QLoRA の PCIe 実効スループット。G4 の P2P 公表値(+168%/-41%)はテンソル並列「推論」の数字で、学習の all-gather にどこまで効くかは実測が要ります。特に「2枚で 235B 級」の逼迫構成が実用速度で回るかは未知数です。
  2. リージョン別 Spot の実値と preemption 率。本文の AWS 値はスナップショット、GCP 値は us-central1 表示です。東京・ソウルの現在値と落ちやすさは発注時にコンソールで確認します。
  3. Azure の NC144lds / NC288lds の実価格。本文は NC72lds 実測の線形換算です。
  4. G4 のゾーン在庫。
  5. FlashAttention-2 の sm_120 ビルドの最新状況と、対象モデルの head_dim。
  6. 為替変動。

まとめ

  • 96GB Blackwell(RTX PRO 6000)がこの半年で GCP G4 / AWS G7e / Azure NCv6 と3社に出揃い、前作の「A100 で割り切る」から状況が変わりました。ただし Azure は最大2枚/VM で、4枚は GCP か AWS の二択です。
  • 東京にこだわらなければ、4枚 Spot が月100時間で ¥4.7万〜6.5万(ソウル/米中部/スペイン)、2枚なら ¥3万前後まで下がります。東京固定のプレミアムは OD で +45% 前後、という具体的な数字が見えました。
  • CLI で回す学習ジョブにとってリージョンの遠さはほぼ無関係で、SSH の体感は mosh/tmux、転送は並列化で解決します。ソウルは最安と近さを両取りできる面白い選択肢です。
  • QLoRA はチェックポイント再開が標準装備なので Spot と構造的に相性が良く、さらに GCP の Flex-start(半額・最長7日・途中退去なし)が「落とせない長い run」の受け皿になります。前作で自作した resumable 設計の、いわば公式版です。
  • ターゲットの現実解は、1枚で 70B 級、2枚で 120B 級、4枚で 235B〜355B 級まで。GLM-5.2(744B)の QLoRA は 96GB×4 でも圏外で、これは次の宿題です。

参考

本記事は概算と一般的な仕様に基づく検討メモです。価格・仕様・ソフトウェア対応状況は変動するため、導入を検討する場合は必ず一次情報での確認をお願い致します。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?