AI/MLインフラ（クラウド）

モデルサービングもでるさーびんぐ

推論エンドポイントREST APIMLOpsコンテナスケーリングバッチ推論

モデルサービングについて教えて

簡単に言うとこんな感じ！

AIモデルって、作っただけじゃ使えないんだ。「モデルサービング」は、完成したAIモデルをアプリやシステムから呼び出せるように「窓口」として公開する仕組みのことだよ。料理に例えると、シェフが作った料理をお客さんに届けるウェイターみたいな役割ってこと！

モデルサービングとは

モデルサービング（Model Serving） とは、機械学習で訓練済みのAIモデルを本番環境に展開し、外部のアプリケーションやユーザーからリクエストを受け付けて推論結果を返せる状態にすることを指します。「モデルデプロイメント」や「推論サービング」とも呼ばれます。

AIの開発プロセスでは、データ収集・モデルの訓練（トレーニング）・評価という段階を経て初めてモデルが完成しますが、それだけでは実際のビジネスには活用できません。モデルサービングは、完成したモデルをAPIエンドポイント（HTTPで呼び出せる窓口）として公開することで、「画像を送ったら分類結果が返ってくる」「テキストを送ったら感情分析の結果が返ってくる」といった実用的な使い方を可能にします。

昨今のAI活用の広がりに伴い、モデルサービングはMLOps（機械学習の開発・運用を効率化するプラクティス）の中でも特に重要な領域として注目されています。適切なサービング基盤がなければ、どれだけ精度の高いモデルを作っても、ビジネス価値に結びつけることができません。

モデルサービングの仕組みと構成要素

モデルサービングを実現するには、いくつかの構成要素が連携します。

構成要素	役割	具体例
モデルストア	訓練済みモデルのファイルを保管する場所	MLflow Model Registry、S3
推論サーバー	モデルをロードしてリクエストを処理する	TorchServe、Triton Inference Server
APIエンドポイント	外部からHTTPでアクセスできる窓口	REST API、gRPC
コンテナ	推論環境をパッケージ化して持ち運び可能にする	Docker、Kubernetes Pod
スケーラー	負荷に応じてサーバー台数を増減させる	Kubernetes HPA、AWS Auto Scaling
モニタリング	推論の精度・レイテンシ・エラーを監視する	Prometheus、Grafana

リクエストの流れ

クライアント（アプリ/ユーザー）
        |
        | HTTPリクエスト（例: POST /predict）
        v
  ロードバランサー
        |
        v
  推論サーバー（複数台）
   ┌──────────────────┐
   │ 1. 入力データの前処理 │
   │ 2. モデルへ入力      │
   │ 3. 推論実行          │
   │ 4. 結果の後処理      │
   └──────────────────┘
        |
        | HTTPレスポンス（JSON形式で結果を返す）
        v
クライアント（アプリ/ユーザー）

サービング方式の2種類

リアルタイム推論（オンライン推論） と バッチ推論 の2つが代表的な方式です。

方式	特徴	向いているケース
リアルタイム推論	リクエストの都度即座に結果を返す。低レイテンシが求められる	チャットボット、不正検知、レコメンド
バッチ推論	大量データをまとめて処理する。コスト効率が高い	夜間の需要予測、月次レポート生成

歴史と背景

〜2015年頃 — AIモデルのデプロイは各チームが独自にFlaskやDjangoなどのWebフレームワークで手作りする状況。再利用性が低く、本番化に膨大な工数がかかっていた
2017年 — TensorFlowのTensorFlow Servingがリリース。モデルサービングに特化した専用サーバーという概念が広まる
2018〜2019年 — KFServing（現KServe）やSeldon Coreなど、Kubernetes上でモデルをサービングするOSSが登場。クラウドネイティブなサービング基盤が整備され始める
2019年 — AWS SageMaker、Google AI Platform、Azure MLなど、主要クラウドがマネージドなモデルサービング機能を強化。インフラ管理不要でモデルを公開できる環境が整う
2020年 — NVIDIAがTriton Inference Serverをオープンソース化。GPU推論の効率化・マルチフレームワーク対応が進む
2022年以降 — 大規模言語モデル（LLM）の登場により、サービングの難易度が急上昇。vLLMやTGI（Text Generation Inference）など、LLM特化のサービング技術が台頭

サービング方式・ツールの比較

モデルサービングを実現するアプローチは大きく「クラウドマネージド」「OSS自前構築」に分かれます。

選択の目安

条件	おすすめアプローチ
インフラ管理の人員が少ない、早く本番化したい	クラウドマネージド
特定クラウドに依存したくない（マルチクラウド・オンプレミス）	OSS自前構築
LLMを低コストで大量に呼び出したい	vLLM / TGI
複数フレームワークのモデルを混在させたい	Triton

規格・仕様	内容
KFServing v2 Inference Protocol	Kubernetes上のモデルサービングの標準APIインターフェース仕様（現KServe）
ONNX（Open Neural Network Exchange）	モデルの相互運用性を高めるフォーマット。サービング環境でのモデル変換に広く使われる
OpenAPI / Swagger	推論エンドポイントのAPIドキュメント標準
Prometheus exposition format	サービングサーバーのメトリクス収集に使われる監視規格