セクション3 要点と暗記 — プロトタイプから ML モデルへのスケール

🎯 最重要セクションの暗記版。意思決定ツリーと頻出問題パターン。

🌳 モデル選定ツリー

タスクは？
├─ テーブル分類/回帰
│  ├─ 解釈性必要 → 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）

🃏 暗記カード

Q	A
BigQuery ML の時系列モデル名は？	ARIMA_PLUS
Vizier のアルゴリズムは？	Bayesian Optimization
訓練の並列化3種類は？	Data / Tensor (Model) / Pipeline Parallelism
3D 並列 = ？	上記3つを組み合わせる
単一 GPU に乗らないモデルを訓練するには？	ZeRO / FSDP / Model Parallelism
数千〜1万 TPU チップを束ねるには？	Multislice
複数 TPU を単一プログラムで扱うランタイムは？	Pathways
LoRA は何の略 + 何をする？	Low-Rank Adaptation。低ランク行列で PEFT（パラメータ効率）
Spot VM / Preemptible を使う前提条件は？	チェックポイント保存
Spot 枠を確保しやすくするサービスは？	Dynamic Workload Scheduler (DWS)
大量分散の All-reduce を高速化するには？	Reduction Server
訓練 loss が NaN になる主原因2つ	学習率高すぎ / 混合精度 overflow
過学習対策3つ	Early stopping / Dropout / Augmentation / 正則化
AutoML より細かい制御がほしい・コードは少なめ	Tabular Workflows
100B LLM を訓練する Google の標準構成	TPU v5p Multislice + Pathways
Gemini ファインチューニングを BigQuery で行う構文	`CREATE MODEL ... REMOTE WITH CONNECTION ...`

📊 対比表

BigQuery ML vs AutoML Tables vs Tabular Workflows vs Custom Training

	BQML	AutoML	Tabular WF	Custom
インターフェース	SQL	UI/SDK	パイプライン	Python
自動チューニング	△	◎	◎	自分で実装
カスタマイズ	×	×	△	◎
第一候補	データが BQ	コードレス	カスタマイズ + AutoML	フル制御

CPU / GPU / TPU

	CPU	GPU	TPU
汎用性	◎	○	△
行列演算	×	◎	◎◎
標準 FW	全部	PyTorch	JAX/TF
巨大 LLM	×	△	◎

並列化戦略

	Data	Tensor (Model)	Pipeline
何を分割	データ	テンソル	層
通信頻度	中（all-reduce）	高	低（パイプライン段間）
適用条件	モデルが1GPUに乗る	巨大モデル	スループット重視

ファインチューニング手法

	Prompt	LoRA	Full FT	RLHF
データ量	小	中	大	大
コスト	低	中	高	非常に高
表現力	低	中	高	高
用途	軽微改善	ドメイン特化	完全特化	好み調整

🔥 頻出シナリオ → 即答パターン

シナリオ	即答
BigQuery に顧客テーブル、解約予測モデル	BQML logistic_reg / boosted_tree
時系列予測 with BQML	ARIMA_PLUS
100B LLM 訓練	TPU v5p Multislice + JAX/Pathways
7B LLM を 8 GPU でチューニング	LoRA + FSDP
訓練ジョブが OOM	混合精度 + 勾配蓄積 + FSDP
Vision Transformer 訓練、データロード遅い	TFRecord + tf.data prefetch
ハイパラ探索を効率化	Vizier (HyperparameterTuningJob)
訓練コスト 50% 削減	Spot VM + チェックポイント
Spot が確保できない	Dynamic Workload Scheduler (DWS)
ストリーミング推論で低レイテンシ	L4 GPU エンドポイント
Edge デプロイ	TFLite + Edge TPU + 量子化
Gemini 出力フォーマットを安定化	Supervised Fine-tuning
自社ドメイン Q&A の精度向上	LoRA ファインチューニング + RAG
既存 PySpark で訓練	Dataproc Serverless for Spark
訓練と推論の前処理コードがずれる	TFT または Feature Store

⚠️ ひっかけ警報

「コードを書きたくない」「ML 専門家がいない」 → Custom Training を選ばない（AutoML/BQML/Tabular Workflows）
「100B LLM を A100 単機で訓練」 → 不可能。TPU Multislice か多数 GPU
「LoRA は精度が低い」 → 多くの実用ケースでフルチューニングと近い精度、コスト1/100
「Spot VM はチェックポイントなしで OK」 → 必須。落ちると最初から
「Vizier は Grid Search」 → Bayesian Optimization が基本
「PyTorch なら TPU は使えない」 → PyTorch/XLA で可能。ただし GPU が普通
「ファインチューニングはどんなときも必要」 → プロンプト+RAG で十分なケースも多い。コスト的に最後の手段
「混合精度なら必ず速くなる」 → loss スケーリング忘れると発散

📝 一行サマリー

モデル選定はタスク・解釈性・コストで決まる。訓練は BQML→AutoML→Custom の順で重い。GPU は PyTorch・TPU は JAX/TF。LLM ファインチューニングは LoRA が現実解。