§3 プロトタイプから ML モデルへのスケール
モデルアーキテクチャ選定・訓練・HPT・ファインチューニング・GPU/TPU と分散戦略。比重 ~21%、出題数の中核。
このセクションの結論
モデル選定はタスク・解釈性・コストで決まる。訓練は BQML → AutoML → Custom の順で重い。
GPU は PyTorch、TPU は JAX/TF。LLM ファインチューニングは LoRA が現実解。
🌳 3つの選定ツリー
タスクは？
├─ テーブル分類/回帰
│ ├─ 解釈性必要 → Linear / Logistic / Tree
│ ├─ 高精度 → Boosted Trees (XGBoost/LightGBM)
│ ├─ SQL で完結 → BigQuery ML
│ └─ コードレスで高精度 → AutoML Tables / Tabular Workflows
├─ 時系列 → ARIMA_PLUS（BQML）/ Prophet
├─ 画像分類 → CNN (ResNet/EfficientNet) or AutoML Image
├─ 物体検出 → YOLO / Faster R-CNN
├─ テキスト生成・要約・分類 → Gemini（ファインチューニング検討）
└─ 推薦 → Matrix Factorization / Two-Tower
コードを書きたい？
├─ NO → BigQuery ML（SQL） or AutoML（UI）
├─ YES + シンプルに済ませたい → Custom Training（Pre-built Container）
├─ YES + 既存 Kubeflow 資産 → Kubeflow on GKE
└─ YES + E2E パイプライン → Agent Platform Pipelines（中で Custom Training）
1. フレームワーク
├─ JAX / TF → TPU
├─ PyTorch → GPU
└─ sklearn/XGBoost → CPU
2. モデルサイズ
├─ 〜1B → GPU 単機
├─ 1B〜10B → A100 数枚
├─ 10B〜100B → A100/H100 多数 or TPU Pod
└─ 100B+ → TPU Multislice
3. 推論用途
├─ オンライン低レイテンシ → L4 / TPU v5e
├─ バッチ → T4 / L4
└─ エッジ → Edge TPU (Coral)
プロンプト/few-shot で精度足りる？
├─ YES → ファインチューニング不要、プロンプト改善 + RAG
└─ NO →
データ量は？
├─ < 1,000 件 + 軽微改善 → Prompt Tuning
├─ 数千件 + ドメイン特化 → LoRA / PEFT
├─ 数万件 + 高精度 → Full Fine-tuning
├─ チャット好み調整 → RLHF / DPO
└─ 出力形式厳密 → Supervised Fine-tuning（少量で OK）
🧠 モデル種別とプロダクトの比較
| 観点 | BQML | AutoML | Tabular WF | Custom Training |
|---|---|---|---|---|
| インターフェース | SQL | UI/SDK | パイプライン | Python |
| 自動チューニング | △ | ◎ | ◎ | 自分で実装 |
| カスタマイズ | × | × | △ | ◎ |
| 第一候補 | データが BQ | コードレス | AutoML + 細制御 | フル制御 |
🏋 訓練の基本フロー（Custom Training）
from google.cloud import aiplatform
job = aiplatform.CustomJob(
display_name="my-training",
worker_pool_specs=[{
"machine_spec": {
"machine_type": "n1-standard-4",
"accelerator_type": "NVIDIA_TESLA_T4",
"accelerator_count": 1
},
"replica_count": 1,
"container_spec": {
"image_uri": "us-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-2.py310:latest",
"args": ["--epochs=10", "--data-dir=gs://my-bucket/data"],
},
}],
)
job.run()🎯 ハイパラチューニング（Vizier）
Vizier の特徴
Google 製 ベイズ最適化 ベース。Agent Platform の HyperparameterTuningJob で利用。並列度を上げると壁時計時間短縮だが探索効率は下がる。
主要パラメータ
Learning Rate（最重要）/ Batch Size / Optimizer / 層数 / Dropout / 学習スケジューラ。
早期停止
Median Stopping などで無駄な訓練を打ち切り、トータル時間とコストを大幅削減。
🔧 ファインチューニング手法
| 手法 | データ量 | コスト | 表現力 | 用途 |
|---|---|---|---|---|
| Prompt Tuning | 小 | 低 | 低 | 軽微改善 |
| LoRA / PEFT | 中 | 中 | 中 | ドメイン特化（現実解） |
| Full Fine-tuning | 大 | 高 | 高 | 完全特化 |
| RLHF / DPO | 大 | 非常に高 | 高 | 好み調整・チャット |
| Supervised FT | 少〜中 | 中 | 中 | 出力形式厳密化 |
LoRA の核心
元の重み W を凍結、低ランク行列 A・B を追加学習（W + AB として近似）。
パラメータ数を 0.1〜1% に削減、メモリ・コストを 1/10〜1/100 に削減しつつフル FT に近い精度。
🆕 BigQuery 経由の Gemini ファインチューニング
CREATE OR REPLACE MODEL `project.dataset.tuned_gemini`
REMOTE WITH CONNECTION `project.us.vertex_conn`
OPTIONS (
endpoint = 'gemini-2.0-flash-001',
training_data = (SELECT prompt, expected_output FROM `project.dataset.train`),
tuning_method = 'supervised_fine_tuning'
);🚀 分散訓練戦略
| 戦略 | 何を分割 | 強み | 弱み |
|---|---|---|---|
| Data Parallelism | 同モデル × 異なるデータ | 実装単純 | モデルが 1 GPU に乗らないと不可 |
| Tensor Parallelism | モデル層内のテンソル | 巨大モデル分割可 | GPU 間通信が頻繁 |
| Pipeline Parallelism | モデル層をステージに | スループット向上 | パイプライン詰まり (bubble) |
| 3D Parallelism | 上記 3 つ組合せ | 100B+ LLM の標準 | 実装複雑 |
ZeRO / FSDP
Optimizer State / Gradients / Parameters を分散保持。単一 GPU の VRAM を超えるモデルを訓練可能。DeepSpeed (ZeRO)、PyTorch (FSDP)。
Reduction Server
勾配集約を専用サーバで実行、All-reduce を高速化。多数ノード分散訓練で効果大。
🖥 ハードウェア
CPU
小規模 ML、前処理、ARIMA など。コスト最低。
GPU T4
16GB。軽量推論・小規模訓練。コスト最低の GPU。
GPU L4
24GB。生成 AI 推論特化。コスト効率良い。
GPU A100
40/80GB。LLM 訓練・大型推論。標準的な選択。
GPU H100
80GB。最新、超大規模 LLM 訓練。
TPU v5e
コスト効率重視、推論にも強い。
TPU v5p
訓練特化、超大規模。
🆕 TPU Multislice
複数 Pod を結合、1 万チップ超のスーパーコンピュータ化。
🆕 Pathways
複数 TPU を単一プログラムで扱う Google 製ランタイム。JAX と相性最強。
🩺 訓練のトラブルシュート
| 症状 | 原因 | 対処 |
|---|---|---|
PERMISSION_DENIED | SA 権限不足 | aiplatform.user / storage.objectViewer 付与 |
IMAGE_NOT_FOUND | コンテナ URI 誤り | Artifact Registry パス確認 |
| Quota error | GPU/TPU 上限超過 | quota 引き上げ申請 or リージョン変更 |
| OOM | バッチサイズ過大 | バッチ下げる / 勾配蓄積 / 混合精度 |
| loss が NaN | 学習率高すぎ / fp16 overflow | LR を 1/10、Warmup 追加、bf16 へ |
| I/O 待ち | データロードが遅い | TFRecord + tf.data prefetch |
| 過学習 | 容量過大 / データ不足 | Early stopping / Dropout / Augmentation / 転移学習 |
⚠️ 試験での頻出ひっかけ
| シナリオ | 不正解 | 正解 |
|---|---|---|
| "100B LLM を A100 単機で訓練" | そのまま | 不可能。TPU v5p Multislice + Pathways |
| "PyTorch で 7B モデルをチューニング" | Full FT | LoRA / PEFT |
| "Spot VM はチェックポイントなしで OK" | そのまま | チェックポイント必須 |
| "Vizier は Grid Search" | そのまま | Bayesian Optimization |
| "訓練ジョブ quota が出ない" | 待つ | リージョン変更 or 引き上げ申請 |
| "混合精度なら必ず速くなる" | そのまま | loss scaling 必須、fp16 overflow 注意 |
| "BigQuery 内データで分類モデル、SQL で完結" | Custom Training | BigQuery ML |
| "テーブルで高精度、ML 専門家少" | DNN フルカスタム | Tabular Workflows |
📝 セルフチェック（6 問）
Q1
100B LLM を訓練したい。Google Cloud で最適な構成は？
正解: B。100B 級は TPU Multislice + Pathways が Google 標準。
Q2
PyTorch で 7B LLM をドメイン特化させたい。予算は限定的。
正解: B。LoRA は計算量・メモリを 1/10〜1/100 に。
Q3
HPT をベイズ最適化で自動化したい。
正解: A。Vizier = Google 製ベイズ最適化。
Q4 複数選択
訓練の OOM 対策として有効なもの 2 つ：
正解: A, B。
Q5
Spot 枠を確保しやすくする Google サービスは？
正解: A。DWS。
Q6
JAX で開発したモデルに最適なハードウェア。
正解: C。JAX は TPU 最適化が強い（XLA と密結合）。