Model Serving

モデルサービングとは、学習済みの機械学習モデルを通常はHTTPまたはgRPCのネットワークエンドポイントの背後でホストし、アプリケーションから入力を送信して予測を受け取れるようにすることです。サービングシステムは重みを一度読み込み、CPUまたはGPUのメモリに保持し、多数の同時リクエストを受け付け、リクエストをバッチにまとめ、トラフィックの変化に応じてレプリカを増減し、モデルのバージョンを切り替え、健全性を報告します。Googleは2016年2月、本番環境でTensorFlowモデルを実行するためにTensorFlow Servingをオープンソース化しました。現在、サービングはモデルのパッケージ化と予測のモニタリングの間を担う、機械学習運用（MLOps）の実行時レイヤーです。

サービングシステムによるリクエスト処理#

各リクエストは、入力検証、画像のデコードやリサイズなどの前処理、キュー、モデル本体、そしてJSONなどのレスポンス形式への後処理を経由します。サービングに関する判断の多くはキューで行われます。動的バッチ処理では、アクセラレーターが1回のフォワードパスで複数の入力を処理できるよう、数ミリ秒だけリクエストを保持します。これにより、推論レイテンシをわずかに犠牲にしてスループットを向上させます。キューが満杯になると、サーバーはHTTP 429で新しいリクエストを拒否し、クライアントに送信間隔を空けるよう促します。

サービングチームは、p95やp99などのレイテンシパーセンタイル、1秒あたりのリクエスト数で表すスループット、アクセラレーターの使用率、エラー率、コールドスタート時間を追跡します。コールドスタート時間とは、ゼロからスケールアップしたレプリカが応答できるようになるまでの遅延です。バージョンは段階的にリリースします。カナリアリリースではトラフィックの一部を新しいモデルに送り、シャドーデプロイではライブリクエストのコピーを新しいモデルに送信しますが、その応答は返しません。

このFastAPIアプリは起動時にYOLO26を一度読み込み、検出結果をJSONとして返します。FastAPIのTestClientは同一プロセス内でHTTPスタック全体を通るリクエストを1つ送信するため、サーバーを起動せずに実行できます。

from fastapi import FastAPI
from fastapi.testclient import TestClient
from ultralytics import YOLO

app = FastAPI()
model = YOLO("yolo26n.pt")  # サーバーの起動時に重みを一度だけ読み込みます


@app.get("/predict")
async def predict(url: str):
    """Detect objects in the image at `url` and return them as JSON."""
    results = model(url)
    return results[0].summary()


client = TestClient(app)
response = client.get("/predict", params={"url": "https://ultralytics.com/images/bus.jpg"})
print(response.status_code, response.json()[0])

出力にはステータス200と、クラス名、信頼度、ボックス座標を含む辞書として最初の検出結果が表示されます。この構造は、検出されたすべてのオブジェクトについてsummary()が生成します。ハンドラーはasync defであるため、FastAPIは単一のイベントループ上で実行し、共有モデルが同時に2つのリクエストを処理することはありません。並列処理が必要なサーバーでは、複数のワーカープロセスを実行し、それぞれが独自のモデルを読み込みます。

サービングの方式とソフトウェア#

カメラ映像に対するリアルタイム推論から夜間バッチ処理まで、モデルの応答が必要となるタイミングによってサービング方式が決まります。

• オンラインサービング： RESTまたはgRPC経由で、呼び出し元が待機している間に各リクエストへ応答します。ユーザー向けアプリやライブカメラ映像などが該当します。
• バッチサービング： 夜間に1日分の画像を処理するなど、スケジュールされたジョブが大規模なデータセットをオフラインで採点し、レイテンシよりスループットを優先します。
• ストリーミング： 動画フレームやセンサー読み取り値の到着に合わせて、結果を継続的に送信します。
• エッジAI： 多くの場合、最適化された形式にエクスポートしたモデルをデバイス上で実行するため、ネットワークとの往復が発生しません。

汎用サービングソフトウェアには、旧称Triton Inference ServerであるNVIDIA Dynamo-Triton、TensorFlow Serving、Ray Serve、BentoML、Kubernetes上のKServeなどがあります。PyTorchのTorchServeは限定的な保守モードで、今後の更新予定はありません。vLLM、SGLang、TensorRT-LLMなどのLLMサーバーは、トークンごとの生成向けに連続バッチ処理とページング方式のKVキャッシュ管理を追加します。これらのシステムの多くはコンテナ内で実行されるため、モデル、ランタイム、依存関係を1つのイメージとして配布できます。

サービング、デプロイ、推論エンジンの違い#

モデルサービングは、いくつかの関連用語と密接に結び付いています。モデルデプロイは、パッケージ化、インフラストラクチャ、段階的なリリースを含め、モデルを本番環境に導入する広範なプロセスです。サービングは、モデルが稼働した後にリクエストへ応答する部分を指します。TensorRT、ONNX Runtime、OpenVINOなどの推論エンジンはモデルの計算を実行し、サービングシステムは1つ以上のエンジンをネットワーク通信、キューイング、スケーリングで包みます。

Ultralytics Platformは専用エンドポイントを通じてYOLOモデルを提供します。各エンドポイントは42のリージョンのいずれかにあるシングルテナントサービスで、/predict、/health、自動生成される/docsルートを備えています。デフォルトサイズはアイドル時にゼロまでスケールし、起動に約1分かかることがあります。モデルを置き換えてもエンドポイントURLは維持され、新しいモデルの準備が整うまで以前のモデルが引き続き応答します。