Databricks Model Serving完全解説｜リアルタイム推論

機械学習モデルを訓練しても、本番アプリケーションから使えなければ価値は生まれません。Databricks Model Servingは、MLflowで記録したカスタムモデル、DBRX・LlamaなどのFoundation Model、OpenAI・AnthropicなどのExternal Modelを、統一的なREST APIエンドポイントとして公開するサーバーレス基盤です。インフラ管理不要でオートスケール・GPU対応・Scale to zeroに対応し、推論結果のロギングやA/Bテストまでカバーします。

Model Servingの概要

Model Servingは、Databricksが提供するフルマネージドのリアルタイム推論基盤です。ユーザーがモデルをデプロイすると、Databricks側でコンテナ化・ロードバランシング・オートスケールが自動的に行われ、HTTPS経由のREST APIとして外部アプリケーションからモデルを呼び出せます。

主な特徴は4つあります。

• サーバーレス: VM・コンテナ・Kubernetesの管理が不要。デプロイ後の運用はDatabricksが担う
• REST API: 標準的なHTTPリクエストで推論を呼び出せるため、言語やフレームワークに依存しない
• オートスケール: リクエスト量に応じてインスタンス数を自動調整。トラフィックがなければ0にスケールダウン可能
• GPU対応: GPU最適化インスタンスを選択でき、LLMやディープラーニングモデルの高速推論に対応

3つのエンドポイントタイプ

Model Servingには3つのエンドポイントタイプがあり、用途に応じて使い分けます。試験ではこの3つの違いと適用シナリオの判断が問われます。

Custom Modelsは自社モデルのデプロイに使います。MLflow Model Registryに登録したモデルのバージョンを指定してエンドポイントを作成します。Foundation Model APIsはDatabricksが事前ホストしているOSSモデルをトークン単位の従量課金で利用でき、自前のGPUクラスタを用意する必要がありません。External Modelsは外部APIのプロキシで、Unity Catalogによるアクセス制御やペイロードロギングを外部モデル呼び出しに統一適用する目的で使います。

エンドポイントの作成手順

エンドポイントはUI・REST API・Python SDKの3つの方法で作成できます。本番運用ではCI/CDパイプラインに組み込むためAPIまたはSDKを使うのが一般的です。

UIでの作成

Databricksワークスペース左メニューの「Serving」→「Create serving endpoint」から、モデル名・バージョン・インスタンスサイズ・スケール設定を指定して作成します。プロトタイピングや設定の確認に適しています。

Python SDKでのMLflowモデルデプロイ

以下はMLflowで記録したモデルをPython SDKでエンドポイントとして公開する例です。

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import (
    EndpointCoreConfigInput,
    ServedEntityInput,
)

w = WorkspaceClient()

w.serving_endpoints.create_and_wait(
    name="fraud-detection-endpoint",
    config=EndpointCoreConfigInput(
        served_entities=[
            ServedEntityInput(
                entity_name="models:/fraud_detector",
                entity_version="3",
                workload_size="Small",
                scale_to_zero_enabled=True,
            )
        ]
    ),
)

entity_nameにはUnity Catalog登録モデルのパス（例: catalog.schema.model_name） またはMLflow Model Registryのモデル名を指定します。workload_sizeはSmall / Medium / Largeから選択し、scale_to_zero_enabled=Trueでトラフィックがない間のコストを削減できます。

REST APIでの作成

POST /api/2.0/serving-endpoints

{
  "name": "fraud-detection-endpoint",
  "config": {
    "served_entities": [
      {
        "entity_name": "catalog.schema.fraud_detector",
        "entity_version": "3",
        "workload_size": "Small",
        "scale_to_zero_enabled": true
      }
    ]
  }
}

Feature Servingとの統合

Model Servingの大きな強みの一つが、Feature Servingとの統合です。推論リクエスト時にクライアントが送るのは主キー（顧客IDなど）だけで、エンドポイント側がFeature Table（Unity Catalog管理のDeltaテーブル）から最新の特徴量を自動的に取得してモデルに入力します。

これにより、クライアント側で特徴量計算を再実装する必要がなくなり、訓練時と推論時の特徴量の不整合（Training-Serving Skew）を構造的に防止できます。

# Feature Serving統合の設定例
from databricks.sdk.service.serving import ServedEntityInput

ServedEntityInput(
    entity_name="catalog.schema.fraud_detector",
    entity_version="3",
    workload_size="Small",
    scale_to_zero_enabled=True,
    # Feature Specで定義されたFeature Tableから自動取得
    # モデル登録時にFeature Specを関連付けておく
)

Feature Servingを使うには、モデルをMLflowに記録する際にFeature Engineering APIのlog_modelメソッドで特徴量テーブルとの紐付け（Feature Spec）を定義しておきます。 エンドポイント側は自動的にこのSpecを読み取り、推論時にFeature Tableをルックアップします。

A/Bテストとトラフィック分割

Model Servingでは、1つのエンドポイントに複数のモデルバージョンをserved_entitiesとして登録し、 トラフィックを割合で分割できます。新旧モデルの性能比較（A/Bテスト）や、 段階的なモデル更新（カナリアデプロイ）に使います。

w.serving_endpoints.create_and_wait(
    name="recommendation-endpoint",
    config=EndpointCoreConfigInput(
        served_entities=[
            ServedEntityInput(
                name="model-v2",
                entity_name="catalog.schema.recommender",
                entity_version="2",
                workload_size="Small",
                scale_to_zero_enabled=False,
            ),
            ServedEntityInput(
                name="model-v3",
                entity_name="catalog.schema.recommender",
                entity_version="3",
                workload_size="Small",
                scale_to_zero_enabled=False,
            ),
        ],
        traffic_config={
            "routes": [
                {"served_model_name": "model-v2", "traffic_percentage": 80},
                {"served_model_name": "model-v3", "traffic_percentage": 20},
            ]
        },
    ),
)

この例ではv2に80%、v3に20%のトラフィックを割り当てています。推論テーブルに記録されたレスポンスを分析し、v3の精度が十分であればトラフィック配分を100%に切り替えることで安全にモデルを更新できます。traffic_percentageの合計は必ず100になる必要があります。

ペイロードロギングと推論テーブル

Model Servingのエンドポイントには、すべてのリクエストとレスポンスを自動的にDeltaテーブルに記録する 「推論テーブル（Inference Table）」機能があります。エンドポイント作成時にauto_capture_configを有効にすると、Unity Catalogの指定スキーマに推論ログが蓄積されます。

{
  "auto_capture_config": {
    "catalog_name": "ml_prod",
    "schema_name": "inference_logs",
    "table_name_prefix": "fraud_detection",
    "enabled": true
  }
}

推論テーブルにはリクエストのタイムスタンプ、入力データ、モデルの出力、レイテンシ、ステータスコードが記録されます。このデータを使って以下の運用タスクを実行できます。

• モデルモニタリング: Lakehouse Monitoringと連携し、予測分布のドリフトを検出
• A/Bテスト分析: モデルバージョン別の予測精度・レイテンシを比較
• デバッグ: 異常な推論結果のリクエストを特定し、入力データを確認
• コンプライアンス: 推論の監査ログとして保持

GPUサービング

LLMやディープラーニングモデルなど、GPU推論が必要なモデルには GPU最適化インスタンス（GPU workload type）を指定できます。workload_typeにGPU_SMALL、GPU_MEDIUM、GPU_LARGEを設定すると、対応するGPUインスタンスが割り当てられます。

Foundation Model APIsで提供されるLlama 3やMixtralなどの大規模モデルは、Databricks側がGPUインフラを管理するため、ユーザーがGPUインスタンスを意識する必要はありません。Custom Modelsで自前のLLMやPyTorchモデルをデプロイする場合にGPUワークロードタイプの指定が必要です。

料金体系

Model Servingの課金はDBU（Databricks Unit）ベースの従量課金です。エンドポイントタイプごとに課金モデルが異なります。

コスト最適化のポイントは、開発環境ではscale_to_zero_enabled=Trueを設定し、 本番環境では最小インスタンス数を1以上にしてコールドスタートのレイテンシを回避することです。 Foundation Model APIsはGPUクラスタの管理が不要なため、LLM利用のPoC段階では最もコスト効率が高い選択肢です。

試験で問われるポイント

Model ServingはML Associate・ML Professional・GenAI Engineerの3つの認定試験で出題されます。試験レベルごとに問われる深さが異なります。

• ML Associate: エンドポイントの作成手順、REST APIでの推論呼び出し、Scale to zeroの基本概念
• ML Professional: A/Bテストのトラフィック分割設定、Feature Serving統合によるTraining-Serving Skew防止、推論テーブルを使ったモデルモニタリング
• GenAI Engineer: Foundation Model APIsとExternal Modelsの使い分け、RAGパターンでのEmbeddingエンドポイント利用

特にML Professional試験では「Feature Servingを使う場合と使わない場合の違い」「A/Bテストで新モデルの性能を検証する手順」「推論テーブルのデータを使ったドリフト検出」の3つが頻出です。Custom Models / Foundation Model APIs / External Modelsの3タイプの違いは全試験共通で問われます。

問題で確認

よくある質問