目次 › 第4章 › 4-2

第4章 アプリケーションの組み立てとデプロイ / 想定学習時間:30〜40分 / 最終確認:2026年8月

4-2. Model Serving(Foundation Model APIエンドポイント)での配信

1. Mosaic AI Model Servingとは

Unity Catalogに登録したモデルやチェーンを、アプリケーションから呼び出せるようにする仕組みがMosaic AI Model Servingです。UC登録済みモデルをREST APIエンドポイントとして公開するマネージドサービスで、次の特徴を持ちます。

• サーバーレス — 利用者がクラスタやインフラを管理する必要がない
• オートスケール — リクエスト量に応じて自動的にスケールアウト/イン
• scale-to-zero — アイドル時にゼロまで縮退してコストを抑えられる(コールドスタートのトレードオフは4-7で詳述)
• 高可用性・低レイテンシ — 本番のリアルタイム推論を前提とした運用基盤

Model Servingのエンドポイントには、配信対象によって主に3種類があります。試験ではこの整理がよく問われます。

2. エンドポイントの作成:UI / API / SDK

カスタムモデルのエンドポイントは、Serving UIの画面操作、REST API、SDKのいずれでも作成できます。中核概念はserved entity(配信対象の指定)で、UC上のモデル名とバージョン(またはエイリアス)を指定します。

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

w = WorkspaceClient()
w.serving_endpoints.create(
    name="support-rag-endpoint",
    config=EndpointCoreConfigInput(
        served_entities=[
            ServedEntityInput(
                entity_name="prod.genai_apps.support_rag_chain",
                entity_version="3",
                workload_size="Small",
                scale_to_zero_enabled=True,
            )
        ]
    ),
)

作成後はhttps://<workspace>/serving-endpoints/support-rag-endpoint/invocationsというURLでRESTリクエストを受け付けるようになります。

3. エージェント/チェーンならagents.deploy()が近道

RAGチェーンやエージェントをデプロイする場合、素のModel Servingを手作業で構成する代わりに、databricks.agents.deploy()を使うのが推奨パターンです。UC登録済みのエージェント(チェーン)を指定して呼び出すだけで、次が自動でセットアップされます。

• Model Servingエンドポイントの作成
• Review App — 業務担当者(SME)がブラウザからエージェントと対話し、回答へのフィードバックを残せるレビュー用アプリ
• 推論テーブル(inference table) — リクエスト/レスポンスをDeltaテーブルへ自動記録し、監視・評価(第5章)につなげる

from databricks import agents

deployment = agents.deploy(
    model_name="prod.genai_apps.support_rag_chain",
    model_version="3",
)
# Review AppのURLや、エンドポイント名が返る

4. エンドポイントへのクエリ方法

公開したエンドポイントは、用途に応じて複数の方法で呼び出せます。

-- SQLからのバッチ推論の例
SELECT
  ticket_id,
  ai_query(
    "support-rag-endpoint",
    concat("次の問い合わせを要約してください: ", body)
  ) AS summary
FROM prod.support.tickets;

5. 無停止更新とトラフィック分割

本番エンドポイントの更新(新バージョンへの差し替え)は、エンドポイントのconfig更新として行います。更新中も旧構成がリクエストを処理し続け、新構成の準備が整ってから切り替わるローリング更新のため、ダウンタイムなしで差し替えられます。

さらに、1つのエンドポイントに複数のserved entityを載せ、トラフィックを%で振り分けることができます。段階的リリース(カナリアリリース)やA/Bテストの基盤になります。

w.serving_endpoints.update_config(
    name="support-rag-endpoint",
    served_entities=[
        ServedEntityInput(entity_name="prod.genai_apps.support_rag_chain",
                          entity_version="3", workload_size="Small",
                          scale_to_zero_enabled=True),
        ServedEntityInput(entity_name="prod.genai_apps.support_rag_chain",
                          entity_version="4", workload_size="Small",
                          scale_to_zero_enabled=True),
    ],
    traffic_config=TrafficConfig(routes=[
        Route(served_model_name="support_rag_chain-3", traffic_percentage=90),
        Route(served_model_name="support_rag_chain-4", traffic_percentage=10),
    ]),
)

練習問題