モデルサービング
TL;DR
モデルサービングは、学習済み成果物を本番予測に変換します。設計は、レイテンシ、スループット、モデルサイズ、ハードウェア、特徴量鮮度、ロールアウト安全性、観測性に左右されます。良いサービング基盤は、モデル版のロード、トラフィックルーティング、バッチング、タイムアウト、障害説明、アプリケーションコードから独立したロールバックを扱えます。
サービングモード
| モード | レイテンシ | 用途 |
|---|---|---|
| バッチスコアリング | 分から時間 | 日次推薦、チャーンスコア |
| オンライン同期 | ミリ秒から秒 | 不正検知、ランキング、パーソナライズ |
| オンライン非同期 | 秒から分 | エンリッチメント、レビューキュー |
| ストリーミング推論 | イベントごとに低遅延 | 異常検知、不正検知 |
| エッジ推論 | ローカル | オフラインアプリ、プライバシー重視 |
サービングトポロジー
| 構成 | 適する条件 | トレードオフ |
|---|---|---|
| ライブラリ埋め込み | 超低レイテンシ、単純モデル | 中央更新と監視が難しい |
| サイドカー予測器 | サービス近接で低遅延 | デプロイが複雑 |
| 中央予測サービス | ロールアウト、ログ、統制を集中 | ネットワークホップと共有依存 |
| モデルメッシュ | 多数モデルを共通ランタイムで運用 | noisy neighbor とルーティング複雑性 |
| 非同期スコアリング | 応答をブロックしない | 意思決定が遅れる |
| バッチスコアリング | 安価で高スループット | 予測が古くなる |
不正承認は同期オンラインと厳格なフォールバック、日次マーケティングスコアはバッチが向きます。
オンラインサービング構成
予測ログは必須です。リクエスト、モデルバージョン、特徴量、予測、レイテンシ、後から結合されるラベルを残します。
予測API契約
request:
request_id: string
entity_id: string
model_name: string
feature_refs: object
context: object
response:
model_version: string
policy_version: string
score: number
decision: string
confidence: number
fallback_used: booleanモデル版とポリシー版を返すことで、後から意思決定を再構築できます。スコアだけを返すAPIは事故調査を難しくします。
レイテンシ予算
合計p99予算: 100 ms
ネットワーク入力 10 ms
認証/ルーティング 5 ms
特徴量参照 25 ms
モデル推論 40 ms
後処理 10 ms
ログ/応答 10 ms特徴量参照が予算を使い切るなら、モデルだけを高速化してもユーザー体験は改善しません。
特徴量取得パターン
| パターン | 使う条件 | リスク |
|---|---|---|
| ゲートウェイが取得 | ログとフォールバックを集中 | ゲートウェイがボトルネック |
| モデルサーバーが取得 | モデルが特徴量集合を所有 | 隠れた依存先fanout |
| 呼び出し元が渡す | 呼び出し元が文脈を持つ | 呼び出し元ごとのズレ |
| 事前計算ベクトル | 厳しいp99 | 古い値 |
| 2段階取得 | 安価な特徴量で絞って高価な特徴量を取得 | ロジックとログが複雑 |
特徴量取得は推論より壊れやすいことがあります。独自のSLO、タイムアウト、フォールバックを持たせます。
モデルバージョンとルーティング
代表的な方針:
- Champion/challenger: 現行モデルと候補モデルを比較する。
- Canary: 少量のライブトラフィックで候補を検証する。
- Shadow: 応答には使わず候補を実行する。
- Segment routing: 地域、テナント、端末、リスク層で分ける。
- Fallback: 主要経路が失敗したら単純モデルやルールに戻す。
バッチング
| 戦略 | 長所 | リスク |
|---|---|---|
| バッチなし | 予測可能なレイテンシ | ハードウェア利用率が低い |
| 固定バッチ | 容量計画が簡単 | バッチ充填待ちが発生 |
| 動的バッチ | 利用率が高い | p99挙動が複雑 |
| 継続バッチ | 大型モデルで効率的 | スケジューラが複雑 |
計算が重く、少し待てるリクエストでは有効です。厳しいp99予算がある場合は慎重に使います。
キャパシティ計画
必要worker数 =
peak_qps * p99_inference_seconds / target_utilizationさらに、特徴量ストアの遅延、モデルロード時間、カナリー/シャドー負荷、バッチサイズ分散、リージョンフェイルオーバーの余裕を加えます。GPUサービングでは計算よりメモリが先に制約になることがあります。
劣化ラダー
各段階でユーザー影響を明示します。不正では手動レビュー、推薦では人気コンテンツが安全defaultになりえます。
障害モード
モデルロード失敗
成果物が壊れている、ランタイム非互換、依存関係不足、テンソル形状不一致などでロードできません。
対策: 昇格前に成果物を検証し、新モデルがヘルスチェックに通るまで旧モデルを維持します。
特徴量取得タイムアウト
モデルサーバーは正常でも、特徴量取得が失敗します。
対策: 厳しいタイムアウト、フォールバック特徴量、安全なキャッシュ、特徴量ストア単独の可用性監視を用意します。
テールレイテンシ崩壊
平均は正常でも、バースト時にキューが伸びてp99が悪化します。
対策: キュー上限、ロードシェディング、入場制御、高コストモデル用の別プールを使います。
運用メトリクス
| レイヤー | メトリクス |
|---|---|
| リクエスト | QPS、p50/p95/p99、タイムアウト率、エラー率 |
| キュー | 深さ、待ち時間、破棄数 |
| モデル | 推論時間、ロード時間、バージョン、メモリ |
| ハードウェア | CPU/GPU使用率、GPUメモリ、アクセラレータエラー |
| 特徴量 | 参照レイテンシ、鮮度、ミス率 |
| 品質 | ガードレール、遅延ラベル、ドリフト、キャリブレーション |
重要なポイント
- モデルサービングはモデル固有の障害モードを持つ本番サービスである。
- モデル成果物はアプリケーションコードから独立してロールアウトする。
- 予測ログは監視、デバッグ、再学習に必須。
- バッチングはスループットを改善するがp99と交換になる。
- フォールバック動作はデプロイ前に設計する。