Deep Dive: 訓練・サービング・Feature Store

§3+§4 を、Google Cloud の公式ドキュメントの文面に沿って深掘りします。 表面的な比較表ではなく、本番で踏むリスクと公式仕様の落とし穴に焦点 を当てています。

🏋 Custom Training の核心

Vertex AI Custom Training は、コンテナイメージと workerPoolSpecs を渡せば、クラスタ管理なしで分散訓練ジョブを起動できます。鍵となるのは「worker pool の位置順序」と「環境変数で渡されるクラスタトポロジ」です。

🧱 Worker Pool アーキテクチャ

gcloud ai custom-jobs create \
  --region=us-central1 \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=1,\
accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,\
container-image-uri=us-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-2.py310:latest \
  --worker-pool-spec=machine-type=n1-highmem-96,replica-count=4,\
accelerator-type=NVIDIA_TESLA_V100,accelerator-count=8,\
container-image-uri=us-docker.pkg.dev/vertex-ai/training/pytorch-gpu.2-2.py310:latest \
  --worker-pool-spec=machine-type=n1-highcpu-16,replica-count=16,\
container-image-uri=us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest

この例では Primary 1 + Workers 4 + Reduction Server 16 で構成。「合計 5 ノード × n1-highmem-96 × V100×8 = 約 500 Gbps の egress 帯域」を、「Reduction Server 16 × n1-highcpu-16 × 32 Gbps = 512 Gbps」でマッチさせています。帯域マッチングは公式の必須要件です。

🗺 CLUSTER_SPEC / TF_CONFIG

各レプリカコンテナには CLUSTER_SPEC（汎用）と TF_CONFIG（TF 専用）の JSON 環境変数が自動注入されます。公式は「環境変数を直接パースせず、フレームワーク標準の Distribution Strategy 経由で読む」ことを推奨。

{
  "cluster": {
    "workerpool0": ["primary-host:port"],
    "workerpool1": ["worker-host-0:port", "worker-host-1:port"],
    "workerpool2": ["ps-host-0:port"]
  },
  "environment": "cloud",
  "task": {
    "type": "workerpool1",
    "index": 1,
    "trial": "TRIAL_ID"  // HPT 時のみ
  },
  "job": { /* CustomJobSpec 全体 */ }
}

{
  "cluster": {
    "chief": ["primary-host:port"],
    "worker": ["worker-host-0:port", "worker-host-1:port"],
    "ps": ["ps-host-0:port"]
  },
  "task": {
    "type": "worker",
    "index": 1,
    "trial": "TRIAL_ID",
    "cloud": "..."
  }
}

⚙ 分散戦略の選定

strategy = tf.distribute.MultiWorkerMirroredStrategy()
with strategy.scope():
    model = build_model()
    model.compile(optimizer='adam', loss='sparse_categorical_crossentropy')
model.fit(dataset)  # フレームワークが TF_CONFIG を自動解釈

🚀 Reduction Server：勾配通信の専用高速化

大規模 GPU 訓練で All-reduce の通信レイテンシがボトルネック になる場合の Google 製ソリューション。専用ノード群が勾配集約を引き受けます。

前提条件（必須）

• NCCL all-reduce を使う分散 GPU 訓練（CPU や TPU では使えない）
• TensorFlow 2.3+ または PyTorch 1.4+ の prebuilt container、または NCCL 2.7+ かつ google-reduction-server パッケージ入りカスタムコンテナ
• Reduction Server ノード群の合計帯域 ≥ Primary+Workers の合計帯域（公式要件）

リージョン別イメージ

us-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
europe-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest
asia-docker.pkg.dev/vertex-ai-restricted/training/reductionserver:latest

性能を引き出す Tuning

🧠 TPU 深掘り：systolic array と Multislice

TPU の本質

「systolic array architecture」が GPU との根本差。「multiply-accumulator が物理的に直接接続された大きな行列」を構成し、行列乗算中に メモリアクセスが発生しない。これが von Neumann ボトルネック回避の核心です。

世代別の重要差

SparseCore

「sparse operations を加速する dataflow processor」。レコメンデーション系（埋め込みテーブル）で特に有効。v5p と TPU7x は 4 個/chip、v6e は 2 個/chip。埋め込みヘビーなモデルでは SparseCore 数が性能に直結します。

Slice / Cube / Pod / Multislice の階層

世代間コード可搬性

「同じ TensorCore 数なら同じコードが動く」（v3-128 ↔ v4-128 など）。ただし TensorCore 数が違うと 「significant tuning and optimization」 が必要、と公式が明記。「TPU 世代を上げれば自動で速くなる」ことはない。

フレームワーク

PyTorch / JAX を公式が明記。JAX は TPU 最適化が最も進む（XLA との密結合）。PyTorch は PyTorch/XLA 経由。Gemini や PaLM など Google 自社 LLM の訓練は基本 JAX + TPU + Pathways。

📡 Online Inference 深掘り

Vertex AI の Inference は Endpoint リソースに DeployedModel をデプロイする構造。リクエスト経路は API 種別とエンドポイント種別の組合せで決まります。

🔌 エンドポイントの 4 種類

# Python SDK で dedicated を有効化
prediction = endpoint.predict(
    instances=instances,
    use_dedicated_endpoint=True,  # ←これが鍵
)
# dedicatedEndpointDns はリソース取得時に返る

🎛 predict / rawPredict / StreamRawPredict / Invoke

predict の厳格フォーマット

• 「top level of instance data must be a JSON object」
• 値は string / number / list（リスト内は均質型）
• バイナリは {"b64": "<base64-encoded>"} 形式
• TF モデルは binary tensor alias を _bytes 終わりにする（命名規約）
• PyTorch (TorchServe) は {"instances": [{"data": <value>}]} で data ラッパー必須

# 画像（base64 binary）を TF サーバへ
{
  "instances": [
    { "image_bytes": { "b64": "/9j/4AAQSkZJRg..." } }
  ]
}

# PyTorch の場合
{
  "instances": [
    { "data": [0.1, 0.2, 0.3, 0.4] }
  ]
}

🗂 Feature Store (Latest) — レガシーとは別物

新 Feature Store は「BigQuery がそのまま offline store」というアーキテクチャ。レガシーは Vertex AI 内に独立した offline storage を持っていたが、新版はメタデータ層に徹し、データ複製を排除。

FeatureView の強み

1 つの FeatureView は「2 つの異なる FeatureGroup（別の BQ テーブル由来）の features を集約」できる。"user" と "product" を結合した特徴量空間を、1 回の online lookup で取得可能。

登録は optional

「Feature Group を登録しなくても features を online で serve できる」と公式が明記。ただし 登録しないと：

• 時系列点 (point-in-time) lookup ができない
• Feature Monitoring ができない
• Knowledge Catalog からの discovery 不可

🟦 Bigtable Online Serving が標準

• 「useful for serving large data volumes (terabytes of data)」
• embeddings は serve できない → 埋め込みは Vector Search を使う
• 水平スケーリング：online serving node 数を増やす
• リージョン整合性必須：「All Vertex AI Feature Store resources must be located in the same region or the same multi-regional location as your BigQuery data source.」

⚠️ Optimized Online Serving のサンセット

Sync 操作（pull 型）

新 Feature Store は pull 型。BQ で値が更新されても、FeatureViewSync を起動するまで online store には反映されません。スケジュール sync か、ETL 完了後に明示的に sync 起動が必要。

# 疑似コード
operation = feature_view.sync()
# 非同期。完了待ちは別途 wait or polling
operation.result()

Feature Monitor

登録済み feature にしか付けられない。更新頻度が違う features は 別々の FeatureMonitor に分けるのが公式の例：「f1, f2 が hourly、f3, f4 が daily なら FeatureMonitor を 2 つ作る」。

💰 コスト最適化の真実

⚠️ よくあるリスクと注意点

📚 参考リンク（一次情報）

• 分散訓練（Vertex AI 公式）
• Reduction Server
• Online predictions
• Private endpoints
• Feature Store (Latest) Overview
• Cloud TPU System Architecture
• Spot VMs with training
• Configure compute for inference