セクション4 基礎 — モデルのサービングとスケール
📘 対象：新人エンジニア。バッチ推論とオンライン推論、Endpoint、Model Registry の基本フローを押さえる。
1. バッチ推論 vs オンライン推論
1.1 違い
|
バッチ推論 |
オンライン推論 |
| 入力 |
データセット（GCS/BQ） |
単発リクエスト（API） |
| レイテンシ |
数分〜時間（許容） |
数 ms〜100ms（厳格） |
| スループット |
一度に大量 |
高 QPS |
| 用途 |
夜間スコアリング・レポート |
チャット・推薦・検知 |
| コスト |
安い（必要なときだけ起動） |
高い（常時起動） |
1.2 ユースケース別の使い分け
| 課題 |
推論方式 |
理由 |
| 毎日全顧客の解約スコアを計算 |
バッチ |
即時性不要、コスト最優先 |
| ECサイトの商品推薦（リクエスト時に表示） |
オンライン |
< 100ms 要件 |
| メール分類（受信時に自動振り分け） |
オンライン |
リアルタイム性 |
| マーケティング配信リストの作成（月次） |
バッチ |
即時性不要 |
| 不正検知（決済時） |
オンライン |
即時判定必要 |
| ログ分析の異常検知（日次） |
バッチ |
集計バッチで OK |
2. サービング方法の選択肢
2.1 Agent Platform Inference（旧 Vertex AI Prediction / Endpoints）
- マネージドな推論サービス。モデルを Model Registry に登録 → Endpoint にデプロイ → REST/gRPC API で呼ぶ
- オンライン推論（Endpoint）とバッチ推論（Batch Prediction Job）の両方
- オートスケール、A/B トラフィック分割、モニタリング統合
2.2 Cloud Run
- サーバーレスコンテナ。リクエスト数に応じて 0 → N にスケール
- 軽量モデル（< 1GB / CPU 推論）に向く
- GPU 対応（最新）：小〜中規模 LLM 推論
2.3 GKE (Google Kubernetes Engine)
- 完全制御。kubeflow、KServe、Triton、独自構成
- 複雑なオートスケール・カナリア・複数モデル併存
- 運用負荷は高い
2.4 Model Garden（Models as a Service）
- Gemini / Imagen 等の Google 製・OSS モデルを API として直接利用
- ホスティング不要、トークン課金
2.5 使い分け
| 条件 |
推奨 |
| 標準的な ML 推論を最も簡単に |
Agent Platform Inference |
| 軽量モデル + スケールゼロでコスト最適 |
Cloud Run |
| Kubernetes 既存資産・複雑な構成 |
GKE (with KServe / Triton) |
| 基盤モデルそのまま使う |
Model Garden (MaaS) |
| エッジデバイス |
TFLite / Edge TPU / Coral |
3. Model Registry
3.1 役割
- モデルファイル・メタデータ・系統 (lineage) の 中央カタログ
- バージョン管理（v1 / v2 / v3 ... ）
- 複数モデルをまとめる "Model Resource" 単位で管理
3.2 基本操作
from google.cloud import aiplatform
# 訓練後にモデルをアップロード
model = aiplatform.Model.upload(
display_name="churn-predictor",
artifact_uri="gs://my-bucket/models/churn/v2/",
serving_container_image_uri="us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-3:latest",
)
# Endpoint にデプロイ
endpoint = model.deploy(
machine_type="n1-standard-4",
min_replica_count=1,
max_replica_count=3,
traffic_split={"0": 100},
)
3.3 バージョン管理の効能
- ロールバック容易（直前バージョンに即戻せる）
- 監査対応（誰がいつどのモデルを本番化）
- カナリア・A/B テストの土台
4. エンドポイントとトラフィック分割
4.1 Endpoint の構造
Endpoint
├─ Model v1 (50% traffic)
├─ Model v2 (40% traffic)
└─ Model v3 (10% traffic) ← カナリア
4.2 デプロイの粒度
- DeployedModel：Endpoint にデプロイされたモデル1つ
- traffic_split：DeployedModel ID → % のマップ
- machine_spec：マシン種別・GPU・accelerator_count
- min/max replica：オートスケールの範囲
4.3 トラフィック分割の例
- A/B テスト：50/50 で複数モデル比較
- カナリア：新モデルに 5% から開始、徐々に増やす
- シャドウデプロイ：新モデルにもリクエストを流すが結果はユーザに返さない（観測のみ）
5. サービングコンテナ
5.1 Pre-built Container
- TensorFlow Serving / TorchServe / XGBoost / sklearn / NVIDIA Triton など
- 標準的なモデルなら upload するだけで動く
5.2 Custom Container
- 自分の Dockerfile で完全制御
- 前処理・後処理のロジックを推論サーバ内に組み込み可能
- Flask / FastAPI ベースで推論エンドポイント実装
5.3 主要なフォーマット
| フォーマット |
用途 |
| SavedModel (TF) |
TensorFlow Serving / Agent Platform 標準 |
| TorchScript / PyTorch state_dict |
PyTorch |
| ONNX |
フレームワーク間互換 |
| JOBLIB / pickle |
scikit-learn |
| XGBoost JSON |
XGBoost |
| GGUF |
量子化 LLM（llama.cpp） |
| TFLite |
エッジデプロイ |
6. 推論の前処理・後処理
6.1 どこで実行するか
| 場所 |
利点 |
欠点 |
| クライアント側 |
サーバ負荷軽減 |
バージョン管理難、Skew リスク |
| API ゲートウェイ層 |
言語横断 |
複雑化 |
| 推論コンテナ内（custom prediction） |
モデルとセットで管理 |
コンテナ複雑化 |
| Feature Store |
訓練と完全一致 |
レイテンシ追加 |
6.2 推奨パターン
- Training-Serving Skew 防止が最優先 → Feature Store または TFT で訓練・推論で同じ前処理コード
- 複雑な後処理（閾値判定・ビジネスルール） → 推論コンテナ内 or 別 Cloud Function
7. Feature Store オンライン取得
7.1 役割
- 推論時に 特徴量を ms 級で取得
- Online Store にキャッシュ、Offline は BigQuery バックエンド
7.2 取得フロー
# 推論サーバ側のコード（疑似）
features = feature_store.get_online_features(
entity_type="user",
entity_ids=[user_id],
feature_ids=["avg_purchase_30d", "session_count_7d", "ltv"],
)
prediction = model.predict([request_features + features])
7.3 Online Store の選択肢
- Bigtable-backed：高スループット・大量エンティティ
- Optimized Online Store：マネージドのデフォルト（新ガイド推奨）
8. パブリック / プライベートエンドポイント
8.1 パブリックエンドポイント
- インターネット経由でアクセス可能
- 認証は IAM
- 簡単・標準
8.2 プライベートエンドポイント
- VPC ピアリング or Private Service Connect 経由
- インターネット非経由 → セキュリティ強化、レイテンシ低減
- 機微データ・規制対応に必須
8.3 使い分け
- 社内ツール・外部 API として公開 → パブリック
- 機密データ・社内 VPC からのみ呼ぶ → プライベート
- ハイブリッド/オンプレ連携 → プライベート + Cloud Interconnect
9. ハードウェア選定（サービング基礎）
| シナリオ |
ハードウェア |
| 軽量 ML（< 100MB） |
CPU |
| 中規模 NN / 小型 LLM |
L4 GPU |
| 大規模 LLM（Gemini Pro 級） |
A100 / H100 / TPU v5e |
| 推論コスト最優先 |
L4 / TPU v5e |
| エッジ・モバイル |
Edge TPU / Coral / TFLite |
10. このセクションで覚えるキーワード
- Agent Platform Inference：マネージド推論サービス（旧 Vertex AI Prediction）
- Endpoint / DeployedModel / traffic_split：オンライン推論の構成要素
- Model Registry：モデルの中央カタログ
- Batch Prediction Job：バッチ推論ジョブ
- Feature Store Online Store：推論用特徴量取得
- Public / Private Endpoint：アクセス境界
- L4 / T4 / TPU v5e：推論向けハードウェア
- Edge TPU / Coral / TFLite：エッジ推論
次は 02_応用.md で A/B テスト・カナリア・スケーリング・コスト最適化・前後処理パターンを扱います。