デプロイ先を選ぶ

デバイスを起点にする#

ランタイムは慣習ではなく、推論を実行する場所に基づいて選びます。上から順にたどり、最初に該当する項目で止めます。

各ランタイムは、エクスポートモードのformat=の値に対応します。

最近のAppleプラットフォームでは、Appleの新しいCore AI形式（format=coreai。macOS 26以降のApple siliconまたはx86-64 Linuxでエクスポート）にもエクスポートできます。エクスポートが初めてですか？デプロイ向けエクスポートのレッスンで基本を説明しています。

推論サーバーをまったく実行したくない場合、Ultralytics Platformではモデルを42のリージョンのいずれかに専用エンドポイントとしてデプロイでき、プロフィールの「Deployments」タブで各エンドポイントの稼働場所を確認できます。

この方法についてはエンドポイントのデプロイと呼び出しで説明しています。このコースの残りの内容は、モデルを自分で実行する場合を対象としています。

FPS目標をミリ秒単位の予算に換算する#

「リアルタイム」は要件ではなく、数値が要件です。何かをベンチマークする前に計算してください。

次の判断基準を適用してください。

• デバイスのCPUでYOLO26nがモデル予算を超える場合は、他のことを試す前にアクセラレーター（GPU、iGPU、NPU）に移行するか、imgszを小さくしてください。YOLO26のベンチマークでは、YOLO26nはCPU ONNXで38.9 ms、T4のTensorRTで1.7 msです。
• 1台のデバイスで複数のカメラを処理する場合は、モデル予算をカメラ台数で割ってください。
• フリートに多数のデバイスタイプが含まれる場合は、デバイスごとのビルドが不要なランタイムを優先するか、デバイスクラスごとにビルドを用意してください。
• 呼び出し元のコードがSwift、Kotlin、またはC++の場合は、採用を決める前に、その言語に対応するランタイムのSDKを確認してください。

候補をデバイス上でベンチマークする#

仕様書や他の人のベンチマークは出発点にすぎません。判断は実際にデプロイするハードウェア上で、平均ではなく遅いフレームを基準に行います。中央値では高速でも20フレームに1回停止するランタイムでは、フレームがドロップします。このスクリプトは各候補をエクスポートし、実際のフレームで100回推論を計測して、95パーセンタイル（p95）で評価します。

from ultralytics import YOLO
from ultralytics.utils.downloads import safe_download

BUDGET_MS = 30  # the model's share of a 20 FPS frame budget
CANDIDATES = ("onnx", "openvino")  # runtimes the decision tree allows on this machine

if __name__ == "__main__":  # exports and inference can start worker processes on macOS and Windows
    frame = str(safe_download("https://ultralytics.com/images/bus.jpg"))  # use a real frame from your camera
    for fmt in CANDIDATES:
        model = YOLO(YOLO("yolo26n.pt").export(format=fmt))
        for _ in range(5):  # warm up: the first calls include one-time setup
            model(frame, verbose=False)
        runs = sorted(model(frame, verbose=False)[0].speed["inference"] for _ in range(100))
        p50, p95 = runs[49], runs[94]
        verdict = "meets" if p95 <= BUDGET_MS else "misses"
        print(f"{fmt:9s} p50 {p50:5.1f} ms  p95 {p95:5.1f} ms  {verdict} the {BUDGET_MS} ms budget")

このコースのテストに使用したApple silicon搭載ノートPCで、他のジョブがCPUを共有している状態での結果：

onnx      p50  30.0 ms  p95  46.4 ms  misses the 30 ms budget
openvino  p50  22.8 ms  p95 113.5 ms  misses the 30 ms budget

行ごとに確認します。

• speed["inference"]はデコードや描画を含まない、そのフレームに対するモデル自体の処理時間です。そのため、ランタイムを公平に比較できます。
• OpenVINOは中央値で優位ですが、p95では2倍以上遅くなります。平均で判断すると、負荷の高いタイミングで停止するランタイムを出荷してしまいます。p95で判断した場合、このマシンではONNX Runtimeのほうが安定した選択肢です。
• どちらも予算を満たしていないため、ここで次に試すべきなのは、別のCPUランタイムではなく、小さいimgsz、アクセラレーター、またはデバイスあたりのカメラ台数の削減です。

形式ごとの精度と速度を手早く比較するには、ベンチマークモードで各形式をエクスポート、検証、計測できます。

yolo benchmark model=yolo26n.pt data=coco8.yaml imgsz=640 format=onnx

format=を省略すると、マシンが対応するすべての形式を比較できます。COCO8の検証画像は4枚しかないため、mAP列はスモークテストとして扱い、精度の判断には独自のデータセットYAMLを使用してください。

よくある落とし穴#

エッジデバイスでは4つの点を確認する#

Raspberry Pi、NVIDIA Jetson、Jetson上のDeepStreamの各ガイドで、一般的なターゲットを詳しく説明しています。エッジデバイスの採用を決める前に、次の点を確認してください。

• コールドスタート：TensorRTエンジンはどこでビルドされ、誰が完了を待ちますか？
• 電力と熱：筐体はモデルを最大FPSで終日実行し続けられますか？
• メモリ：モデルに加えて、フレームバッファーとトラッカーの状態を保持する余裕はありますか？INT8ではモデルが使用するメモリが半分になります。
• 更新：新しいbest.ptを1,000台のデバイスにどう届けますか？Dockerイメージを使うと、環境を統一できます。