モデルサービング

モデル提供は、機械学習のライフサイクルにおける重要な段階であり、学習されたモデルがサーバーやデバイス上でホストされる。 デバイスにホストされる。 機械学習（ML）モデルが学習され、検証されたら 機械学習（ML）モデルが学習され検証されると、価値を提供するために本番環境に統合されなければならない。サービングは サービングは、静的なモデルファイルとエンドユーザーアプリケーションの間の橋渡し役として機能し、画像やテキストなどの入力データをAPI経由でリッスンし のような入力データをAPI経由でリッスンし、モデルの予測を返します。このプロセス により、ソフトウェア・システムは 予測モデリング機能を即座に スケールで利用できる。

効果的なモデルサービングには、モデルをメモリにロードし、GPUのようなハードウェアリソースを管理できる堅牢なソフトウェアアーキテクチャが必要です。 GPUなどのハードウェアリソースを管理し リクエストを効率的に処理する。単純なスクリプトでも推論を実行することはできますが、本番レベルのサービングには、多くの場合、次のような特殊なフレームワークが使用されます。 のような特殊なフレームワークを利用することが多い。 NVIDIA Triton 推論サーバーや TorchServeのような特殊なフレームワークを利用することが多い。これらのツールは、高スループットと低 最適化されているため、アプリケーションは ユーザー負荷が高い場合でも、アプリケーションの応答性を維持することができます。

サービング・アーキテクチャーのコア・コンポーネント

包括的なサービングのセットアップには、予測を確実に提供するために一体となって機能するいくつかの異なるレイヤーが含まれる。

• 推論エンジン：モデルの数学的演算を実行する中核となるソフトウェア。 エンジンは多くの場合、以下のような特定のハードウェアに最適化されている。 TensorRTや OpenVINOを使用することで、パフォーマンスを最大化することができます。
• APIインターフェース：アプリケーションは、定義されたプロトコルを介して提供モデルと通信する。 REST APIはシンプルであるため、Webインテグレーションでは一般的です。 gRPCは、高パフォーマンスと低レイテンシーを必要とする内部マイクロサービスには好まれます。 gRPCが好まれます。
• モデルレジストリ：学習済みモデルの異なるバージョンを管理するための一元化されたリポジトリ。これにより これにより、新しいモデルの導入で予期せぬ問題が発生した場合に、サービングシステムが簡単に以前のバージョンにロールバックできるようになります。 に簡単にロールバックできる。
• コンテナ化：以下のようなツールがある。 Dockerのようなツールは、依存関係とともにモデルをパッケージ化して 分離されたコンテナにパッケージする。これにより、開発者のラップトップからクラウドのKubernetesクラスタまで、異なる環境間での一貫性が保証される。 クラウド上のKubernetesクラスタに至るまで、異なる環境間での一貫性が保証される。
• ロードバランサー：高トラフィックシナリオでは ロードバランサーは、入力された推論要求を複数のモデルレプリカに分散させる。 単一のサーバーがボトルネックになるのを防ぎ、スケーラビリティを確保する。 スケーラビリティを確保します。

実践的な実施

モデルを効果的に提供するためには、多くの場合、次のような標準化されたフォーマットにエクスポートすることが有益です。 ONNXのような これは、異なるトレーニングフレームワークや提供エンジン間の相互運用性を促進します。次の例は をロードする方法を示します。 YOLO11モデルをロードし、推論を実行する方法を示している。 をシミュレートしています。

from ultralytics import YOLO

# Load the YOLO11 model (this would happen once when the server starts)
model = YOLO("yolo11n.pt")

# Simulate an incoming request with an image source
image_source = "https://ultralytics.com/images/bus.jpg"

# Run inference to generate predictions
results = model.predict(source=image_source)

# Process and return the results (e.g., bounding boxes)
for box in results[0].boxes:
    print(f"Class: {box.cls}, Confidence: {box.conf}")

実際のアプリケーション

モデルサービングは、データに基づいて即座に意思決定ができるようにすることで、様々な業界におけるユビキタスAI機能を強化します。 データ

• スマートリテール：小売業は 小売業でAIを活用し、レジ処理を自動化。 物体検出モデル がベルトコンベア上の商品をリアルタイムで識別し、バーコードスキャンなしで総コストを集計します。
• 品質保証：産業環境において、 製造システムのAIは モデルを使用して組立ラインを検査する。部品の高解像度画像はローカルのエッジ・サーバーに送られ、そこでモデルが傷やズレなどの欠陥を検出すると、直ちに警告が発せられる。 モデルが傷や位置のずれなどの欠陥を検出すると、即座に警告が発せられ、不良品が取り除かれる。
• 金融詐欺の検出銀行は セキュアなAPIを介して提供される異常検知モデル を通じて提供される異常検知モデルを採用している。ある取引が不正行為のパターンに合致する場合、システムは即座にその取引をブロックし、金銭的損失を防ぐことができる。 即座にブロックし、金銭的損失を防ぐことができる。

モデル・サービングとモデル・デプロイメント

しばしば同じ意味で使われるが、モデルサービングとモデルデプロイメントは区別する必要がある。 モデルデプロイメントを区別する必要がある。デプロイメントとは デプロイメントとは、モデルを本番環境にリリースする、より広範なプロセスのことです。 インフラストラクチャのセットアップなどのステップが含まれます。モデルサービングとは、デプロイの特定の実行時側面（モデルを実際に実行し、リクエストを処理する行為）を指します。 を実際に実行し、リクエストを処理する行為です。

効果的なサービスには、継続的な モデル・モニタリング データドリフトを検出する必要があります。 精度を低下させる可能性がある。 精度が低下する可能性がある。今後の Ultralytics ような最新のプラットフォームは、これらの段階を統合し、トレーニングから配信、モニタリングへのシームレスな移行を提供することを目指している。 を提供する。

正しい戦略の選択

配信戦略の選択は、ユースケースに大きく依存します。オンライン・サーバーは、ユーザー ユーザー向けアプリケーションに即時レスポンスを提供するが、低レイテンシーが要求される。逆に、バッチ・サーヴィングは 大量のデータをオフラインで処理するため、即時のフィードバックが重要でない夜間レポート作成などのタスクに適している。 に適している。ドローンや携帯電話など、遠隔地のハードウェアに展開されるアプリケーションの場合、 エッジAIは、処理プロセスをデバイスに直接移行します、 クラウド接続への依存を排除し、帯域幅コストを削減します。

Prometheusのようなツールをメトリクス収集に使用し 可視化のためにGrafanaのようなツールを使用することで、エンジニアリングチームはサービングインフラの健全性をtrack できます。 インフラストラクチャの健全性を追跡し、モデルが コンピュータビジョン機能を提供し続けることを保証します。 を提供し続けることができます。