セクション3 応用 — プロトタイプから ML モデルへのスケール

🔧 対象：中堅エンジニア。分散訓練・大規模ファインチューニング・トラブルシューティング・ハードウェア選定の判断力を養う。

1. 分散訓練戦略

1.1 3つの並列化

戦略	何を分散	強み	弱み
Data Parallelism	同じモデルを複製、データを分割	実装が単純、ほとんどの場合 OK	モデルが 1 GPU に乗らないと使えない
Model Parallelism (Tensor Parallelism)	モデル層内のテンソルを分割	巨大モデルを分割可能	GPU 間通信が頻繁
Pipeline Parallelism	モデル層をステージに分割	スループット向上	パイプライン詰まり (bubble) が起きる

1.2 3D 並列

Data + Tensor + Pipeline を組み合わせる
大規模 LLM (Llama 2 70B / Gemini レベル) の標準
PyTorch FSDP / DeepSpeed / Megatron-LM / JAX (Pathways)

1.3 ZeRO / FSDP（メモリ最適化）

ZeRO (DeepSpeed)：Optimizer State / Gradients / Parameters を分散して保持
PyTorch FSDP：ZeRO 相当の機能
単一 GPU の VRAM を超えるモデルを訓練可能

1.4 Google Cloud での実装

Agent Platform Custom Training：マルチノード / マルチ GPU / TPU をサポート
Reduction Server：勾配集約を専用サーバで行い All-reduce を高速化
NCCL (GPU 間), TPU Inter-Chip Interconnect (ICI) (TPU 間)

2. TPU の応用

2.1 Multislice

複数の TPU Pod を 1 つの学習ジョブとして使う
数千〜1万チップ規模の超大規模訓練が可能
Gemini / Llama などの基盤モデル訓練で使用

2.2 Pathways

複数 TPU を 単一プログラム で扱う Google 製ランタイム
JAX と相性が良い
異種ハードウェア（GPU + TPU）の混在も可能

2.3 TPU を選ぶ判断

モデルが TensorFlow / JAX で書かれている → TPU 第一候補
巨大 LLM 訓練（数十 B〜数百 B パラメータ） → TPU v5p Multislice
PyTorch だが TPU 使いたい → PyTorch/XLA で対応可能（ただし GPU の方が普通）
訓練だけでなく推論も TPU → v5e（推論コスト最適）

3. ファインチューニングの応用

3.1 手法の選択基準

データ量と精度要件は？
├─ < 1,000 件 + プロンプトで微改善したい
│   → Prompt Tuning（最軽量）
├─ 数千件 + ドメイン特化
│   → LoRA / PEFT（コスト効率良い）
├─ 数万件 + 高精度
│   → Full Fine-tuning
├─ チャット品質・人間の好み調整
│   → RLHF / DPO
└─ 出力フォーマット厳密化
    → Supervised Fine-tuning（少量データで OK）

3.2 LoRA の仕組み

元の重み W を凍結、低ランク行列 A・B を追加学習（W + AB として近似）
ランク r = 4〜64 程度
パラメータ数を 0.1〜1% に削減、メモリ大幅減
複数 LoRA を切り替えてマルチタスク化可能

3.3 BigQuery 経由の Gemini ファインチューニング

CREATE 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'
);

3.4 ファインチューニング後の検証

ホールドアウトデータで自動評価
LLM-as-a-judge で多面評価
本番デプロイ前にカナリアで小規模テスト
退行（前バージョンで取れていた正解が落ちる）に注意

3.5 Continual Fine-tuning

既存のチューニング済みモデルにさらに新データで再チューニング
既存知識を保持しつつ新知識を追加
Catastrophic Forgetting に注意（古いタスクの精度低下）

4. 訓練の主要なトラブルシューティング

4.1 訓練が始まらない / 即時失敗

症状	原因	対処
`PERMISSION_DENIED`	サービスアカウントに権限不足	`aiplatform.user`, `storage.objectViewer` 等を付与
`IMAGE_NOT_FOUND`	コンテナイメージの URI 誤り	Artifact Registry のパス確認
Quota error	GPU/TPU 上限超過	リージョン別 quota 確認・引き上げ申請
`OOM (Out of Memory)`	バッチサイズ過大	バッチを下げる / 勾配蓄積 / 混合精度

4.2 訓練が遅い

GPU 利用率が低い：データローダーがボトルネック → num_workers, prefetch 設定
I/O 待ち：Cloud Storage からの読み込みが遅い → Filestore / TFRecord で sequential read
ネットワーク待ち：分散訓練の All-reduce → Reduction Server 検討

4.3 損失が NaN / 発散

学習率が高すぎる → 1/10 に下げる、Warmup 追加
データに inf / NaN が混入 → 前処理で除去
混合精度 (fp16/bf16) で overflow → bf16 に変更、loss scaling 追加

4.4 過学習

訓練 loss は下がるが val が上がる → Early stopping / Dropout / Augmentation / 正則化
データ漏洩：テストデータが訓練に混入していないか確認
小さすぎるデータ → Data Augmentation / 転移学習

4.5 訓練が不安定（毎回 loss が違う）

Random Seed 固定
データの順序固定 / シャッフル方式確認
Mixed Precision のロススケーリング設定

5. 大規模訓練のチェックポイントとリトライ

5.1 チェックポイント

定期的に Cloud Storage にモデル状態を保存
失敗時に最新チェックポイントから resume
TPU では Orbax (JAX) / PyTorch DCP が標準

5.2 プリエンプティブル / Spot VM

通常の 60〜80% 安い
24時間以内に終了される可能性
大規模訓練ではチェックポイントが必須
Dynamic Workload Scheduler (DWS) で確保しやすくする

6. ハードウェア選定の応用

6.1 マシンサイズの選び方

まず 小型 GPU (T4) で動作確認
メモリ不足なら 大型 GPU (A100 80GB / H100) か TPU v5p
推論コスト最適化なら L4 / TPU v5e

6.2 GPU vs TPU の決定木

1. フレームワークは？
   ├─ JAX / TF → TPU が第一候補
   ├─ PyTorch → GPU 推奨（XLA で TPU も可）
   └─ scikit-learn / XGBoost → CPU で十分（GPU 版もある）
2. モデルサイズは？
   ├─ < 1B → GPU 単機 or 少数 GPU 分散
   ├─ 1B〜100B → 多数 GPU or TPU Pod
   └─ > 100B → TPU Multislice
3. コスト性能比は？
   → 同等性能なら TPU が安いケースが多い（TF/JAX なら）

6.3 推論ハードウェア

オンライン推論 + 中規模 LLM → L4 GPU
オンライン推論 + 大規模 LLM → A100 / H100 / TPU v5e
バッチ推論 → コスト重視で T4 / L4
エッジ推論 → Edge TPU (Coral)

7. Tabular Workflows の応用

7.1 Tabular Workflows とは

AutoML Tables の進化版、E2E 自動 ML パイプライン
End-to-End AutoML：データ → 特徴量エンジニアリング → 訓練 → デプロイ
TabNet Workflow / Wide & Deep Workflow / XGBoost Workflow など
パイプラインのカスタマイズが可能（AutoML より柔軟）

7.2 いつ使う

高精度のテーブルデータモデルが必要
特徴量エンジニアリングまで自動化したい
AutoML より細かい制御が欲しいが Custom Training は重い

8. 試験での頻出ひっかけ

シナリオ	不正解になりがち	正解の方向
「100B パラメータの LLM を訓練したい」	A100 単機	TPU v5p Multislice + Pathways
「PyTorch で 7B モデルをチューニング」	フルファインチューニング	LoRA / PEFT
「BigQuery のデータで分類モデル、SQL で完結」	Custom Training	BigQuery ML
「テーブルデータで高精度、ML 専門家少」	DNN フルカスタム	Tabular Workflows
「訓練データが急増、コスト最適化」	通常 GPU 連続使用	Spot VM / プリエンプティブル + チェックポイント
「分散訓練で All-reduce が遅い」	バッチサイズ縮小	Reduction Server
「Vision Transformer の訓練が OOM」	バッチ拡大	勾配蓄積 / 混合精度 / FSDP
「推論レイテンシ厳しく、コスト抑えたい」	A100 オンデマンド	L4 GPU / TPU v5e
「ハイパラ探索を自動化」	Grid Search 自作	Vizier (HyperparameterTuningJob)
「訓練ジョブの quota が出ない」	待つ	リージョン変更 or quota 引き上げ申請
「Gemini に厳格な JSON 出力をさせたい」	プロンプトで頑張る	Supervised Fine-tuning
「数千件で Gemini をドメイン特化」	フルチューニング	LoRA / PEFT が現実的

9. ベンチマーク・実例の感覚

A100 80GB 単機：7B LLM ファインチューニングが可能、13B は難しい
A100 8枚 (DGX)：70B LoRA チューニング可能
TPU v5p Pod (4096 chips)：1T パラメータクラスの訓練
Gemini Flash ファインチューニング：数千件・数時間で完了

次は 03_要点と暗記.md で意思決定ツリーと暗記カードを集めます。