セクション4 応用 — モデルのサービングとスケール
🔧 対象:中堅エンジニア。ロールアウト戦略・スケーリング・コスト最適化・Edge デプロイの実務観点を押さえる。
1. ロールアウト戦略
1.1 A/B テスト
- 2つ以上のモデルに同時にトラフィックを分割(例:50/50)
- ビジネスメトリクス(CTR / コンバージョン / 売上)で比較
- 統計的に有意な差が出たら勝者を 100% に
- Endpoint の
traffic_split で実現
1.2 カナリアデプロイ
- 新モデルに 少量(5〜10%) から開始
- 異常なら即ロールバック、問題なければ徐々に拡大(25% → 50% → 100%)
- メトリクス監視(精度・レイテンシ・エラー率)と組み合わせ
1.3 シャドウデプロイ
- 新モデルにもリクエストを流すが 結果はユーザーに返さない
- ログだけ比較、本番影響ゼロで検証可能
- Cloud Run / GKE で簡単、Endpoint では工夫が必要
1.4 ブルー/グリーン
- 旧 (Blue) と新 (Green) を完全に並列稼働
- ルーティングを一括切り替え
- ロールバックが速い、コストは2倍
1.5 ローリング
- 旧から新へ徐々に置き換え
- インフラ更新(マシン種別変更等)で使う
1.6 試験での頻出シナリオ
| シナリオ |
戦略 |
| 「新モデルが本当に良いかビジネス指標で測りたい」 |
A/B テスト |
| 「リスクを最小化して新モデルを徐々に展開」 |
カナリアデプロイ |
| 「本番影響を一切出さず性能比較」 |
シャドウデプロイ |
| 「即ロールバック可能な切替」 |
ブルー/グリーン |
2. オートスケーリング
2.1 Agent Platform Endpoint のオートスケール
min_replica_count から max_replica_count まで自動スケール
- メトリクス:CPU 使用率(デフォルト 60%)、GPU 使用率、カスタムメトリクス
- スケールイン/アウトの遅延時間も調整可能
2.2 Cloud Run のオートスケール
- 0 → N にスケール(idle 時無料)
min-instances=0 でコールドスタートあり、min-instances=1+ で warm
- リクエスト同時数で課金
- GPU 付き Cloud Run も登場(小〜中規模 LLM 推論に有用)
2.3 GKE のオートスケール
- Horizontal Pod Autoscaler (HPA):Pod 数スケール
- Cluster Autoscaler:ノード数スケール
- Vertical Pod Autoscaler (VPA):Pod リソースサイズ調整
- 細かい制御可能だが運用負荷高い
2.4 スケール戦略の選び方
| 条件 |
推奨 |
| ベースラインの常時トラフィック有 |
Endpoint with min_replicas ≥ 1 |
| スパイク + アイドル時間長 |
Cloud Run (0→N) or Endpoint with min=0 |
| 複雑な複数モデル併存 |
GKE + KServe |
3. レイテンシ最適化
3.1 主要ボトルネック
- コールドスタート:min_replicas=0 だと初回 5〜30秒
- モデル読み込み:大型モデル(10GB+)は読込数十秒
- 特徴量取得:DB アクセスで 50〜200ms
- 推論計算:モデルサイズに比例
- ネットワーク:リージョン跨ぎで 100ms+
3.2 対策
| ボトルネック |
対策 |
| コールドスタート |
min_replicas を増やす、Cloud Run keep-warm |
| モデル読み込み |
プレロード、shared memory、コンテナイメージ最適化 |
| 特徴量取得 |
Feature Store Online Store で ms 級 |
| 推論計算 |
GPU 化 / 量子化 / バッチ化 |
| ネットワーク |
同一リージョン、プライベートエンドポイント |
3.3 量子化と最適化
- INT8 量子化:精度わずか低下、2〜4倍速
- FP16 / BF16:fp32 比 2倍速、精度ほぼ維持
- モデル蒸留 (Distillation):大モデル → 小モデルで知識転移
- NVIDIA TensorRT / OpenVINO:推論最適化
- vLLM / Triton:LLM 向け高スループット推論サーバ
4. LLM サービング特有の論点
4.1 LLM 推論の特徴
- KV キャッシュ:トークン生成中の状態を保持、メモリ大
- Prefill / Decode の2フェーズ:プロンプト処理 vs 1トークン生成
- 動的バッチング:複数リクエストを束ねてスループット向上
- Continuous Batching:vLLM 標準、生成途中でも合流
4.2 LLM デプロイ選択肢
| 選択肢 |
説明 |
| Model Garden (MaaS) |
Gemini / Llama / Mistral を API として |
| Agent Platform Inference + LLM container |
カスタムモデルを Endpoint に |
| GKE + vLLM |
高スループット、自前運用 |
| Cloud Run + GPU |
スパイク対応、コスト効率 |
4.3 LLM コスト最適化
- モデルサイズ選定:Flash > Pro > Ultra のコスト差大
- プロンプトキャッシング:固定プレフィックス再利用
- コンテキストキャッシング:明示的キャッシュ
- Batch API:レイテンシ不要なジョブは半額
- 量子化:INT8 / GGUF で VRAM 削減
5. バッチ推論の応用
5.1 Agent Platform Batch Prediction
batch_prediction_job = model.batch_predict(
job_display_name="nightly-churn-scoring",
gcs_source="gs://my-bucket/input/customers/*.csv",
gcs_destination_prefix="gs://my-bucket/output/scores/",
machine_type="n1-standard-4",
accelerator_type=None, # GPU 不要ならコスト削減
starting_replica_count=10,
max_replica_count=50,
)
5.2 BigQuery ML での予測
- データが BigQuery にあるなら
ML.PREDICT が最速
- 結果テーブルもそのまま BigQuery に
- スケジュールクエリで自動化
5.3 Dataflow + サイドカー推論
- ストリーミング ETL + 推論を組み合わせ
- TFX BulkInferrer などのテンプレ活用
6. Edge / オンデバイス推論
6.1 Edge デプロイの選択肢
|
TFLite |
Edge TPU (Coral) |
ONNX Runtime |
| 対応 |
TF / Keras |
TFLite (量子化必須) |
多フレームワーク |
| 強み |
軽量・モバイル標準 |
低消費電力・高速 |
クロスプラットフォーム |
6.2 モデル準備
- 量子化 (post-training quantization) が必須
- INT8 / Float16 量子化で 2〜4倍速、精度わずか低下
- TFLite Converter で変換
6.3 Gemini Nano
- オンデバイス向け Gemini
- モバイル端末で完結(プライバシー・オフライン対応)
- Android Edge AI(AICore)から利用
6.4 試験での頻出シナリオ
- 「IoT カメラで物体検出」 → Edge TPU
- 「モバイルアプリで翻訳(オフライン)」 → TFLite or Gemini Nano
- 「工場の振動センサで異常検知」 → 軽量モデル + Edge TPU
7. セキュアなサービング
7.1 認証
- IAM:基本。サービスアカウントベース
- API Gateway / Cloud Endpoints:API キーや OAuth
- JWT 検証:カスタム
7.2 ネットワーク
- Private Service Connect:VPC 間の private 接続
- VPC Peering:旧来の方式
- VPC Service Controls:境界制御
7.3 暗号化
- TLS 必須(HTTPS)
- CMEK で永続データ暗号化
- 機密リクエスト/レスポンスは追加で application 層で暗号化
7.4 ロギング・監査
- Cloud Audit Logs で誰がいつ呼んだか
- Cloud Logging で推論結果のサンプリングログ
- 機微データの ログ漏洩 に注意(マスキング)
8. コスト最適化
| 戦略 |
効果 |
| min_replicas を 0 にしてスケールイン |
アイドル時コストゼロ(コールドスタート受容) |
| L4 / T4 などの低価格 GPU |
A100 比 1/5 程度のコスト |
| TPU v5e |
コスト性能比が良い |
| バッチ推論を夜間に Spot で |
オンライン比 1/10 |
| モデル量子化 |
同性能で小型 GPU で済む |
| プロンプトキャッシング (LLM) |
再利用部分 75% 割引 |
| コンテナイメージ最適化 |
コールドスタート短縮 |
| 常時アクセスを Cloud Run min=1 |
スパイク対応 + コスト適度 |
9. 試験での頻出ひっかけ
| シナリオ |
不正解になりがち |
正解の方向 |
| 「夜間に全顧客スコアリング」 |
オンライン Endpoint で順次 |
Batch Prediction Job |
| 「リアルタイム推薦で 50ms 以内」 |
バッチ + キャッシュ |
オンライン Endpoint + Feature Store |
| 「軽量モデルで、リクエストない時はゼロにしたい」 |
Endpoint min=1 |
Cloud Run (0→N) |
| 「100B LLM の高スループット推論」 |
T4 GPU |
A100/H100 or TPU v5e + vLLM |
| 「機微データの推論」 |
パブリック Endpoint |
Private Endpoint (PSC) |
| 「新モデルを安全に展開」 |
即時全置換 |
カナリア(5% → 段階拡大) |
| 「新旧の精度をユーザー影響なしで比較」 |
A/B |
シャドウデプロイ |
| 「IoT カメラで物体検出」 |
クラウド API 呼び出し |
Edge TPU (Coral) |
| 「モデル読み込みが遅くてコールドスタート長い」 |
何もしない |
min_replicas ≥ 1 / イメージ最適化 |
| 「特徴量取得で 300ms かかる」 |
DB を素のままたたく |
Feature Store Online Store |
| 「LLM 推論コスト高すぎ」 |
Pro 使い続ける |
Flash + プロンプトキャッシング + Batch API |
| 「複数モデルを切り替えながら使う」 |
各々別 Endpoint |
同一 Endpoint で traffic_split |
| 「TF と PyTorch の両モデルを同居」 |
サーバを別立て |
Endpoint で異なるコンテナ DeployedModel |
| 「推論前に複雑な前処理が必要」 |
クライアント側で実装 |
Custom Container で前処理込み |
10. 設計パターン例
10.1 標準的なオンライン推論
[Client] → [API Gateway] → [Agent Platform Endpoint (Model Registry v3)]
↓ feature lookup
[Feature Store Online]
↓
[Model Container (FastAPI)]
↓
[Response]
10.2 LLM チャットボット
[Client] → [Cloud Run (FastAPI + RAG orchestration)]
↓
[Vector Search] (関連文書取得)
↓
[Gemini (Model Garden)] (生成)
↓
[Model Armor] (出力フィルタ)
↓
[Response]
10.3 夜間バッチスコアリング
[Cloud Scheduler] → [Cloud Workflows] → [Agent Platform Batch Prediction Job]
↓ input: BigQuery
[model: Model Registry v3]
↓ output: BigQuery / GCS
[Downstream: Looker dashboard]
次は 03_要点と暗記.md で意思決定ツリー・暗記カード・頻出パターンを集めます。