マネージドクラウドとセルフホスト型コンピュータービジョン導入の比較

マネージドクラウドは通常、コンピュータービジョンサービスを迅速に立ち上げる方法です。レイテンシ、データ境界、インフラ制御が厳格な要件である場合は、セルフホストが通常より適しています。難しいのは、チームがシステムのどの部分を制御したいのかを定義する前に、この2つを比較しがちなことです。

ビジョンアプリケーションでは、少なくとも4つの場所を決める必要があります。画像の保存場所、モデルのトレーニング場所、推論の実行場所、周辺アプリケーションの実行場所です。これらを同じ場所にする必要はありません。ソース画像とトレーニングを自社インフラに置き、エッジデバイスで推論を実行しながら、実験トラッキングとモデル管理にはマネージドプラットフォームを利用できます。

Ultralytics YOLOモデルは、このようなポータブルなワークフローに対応しています。Ultralytics Platformでデータとトレーニングのライフサイクルを管理し、エクスポートしたモデルをアプリケーションに適したインフラで実行できます。したがって、適切な選択が常にクラウドかセルフホストかの二者択一とは限りません。各コンポーネントの境界を明確にしたハイブリッド構成が適している場合もよくあります。

マネージドクラウドとセルフホストの概要#

スピード、変動する需要、少人数のインフラチームを最優先する場合は、マネージドクラウドを選びます。ワークロードを管理された環境内に置く必要がある場合や、ネットワーク接続なしで推論を続ける必要がある場合は、セルフホストを選びます。データ、トレーニング、推論にそれぞれ異なる要件がある場合は、ハイブリッドを選びます。

コンピュータービジョンにおけるマネージドクラウドとは#

マネージドデプロイでは、プロバイダーがモデルサービングを支えるインフラの一部または全部を運用します。チームはモデルを提供するか、マネージドモデルを選択してエンドポイントを設定し、消費したリソースまたはリクエストに応じて料金を支払います。

プロバイダーは、エンドポイントのプロビジョニング、ヘルスチェック、自動スケーリング、サービングレイヤーの更新、監視スタックとの統合を担う場合があります。これによりプラットフォーム関連の作業は大幅に減りますが、アプリケーションに対する責任がなくなるわけではありません。モデル品質、入力検証、ビジネスロジック、アクセス制御、サービスに送信できる画像の判断は、引き続きチームが担います。

マネージドクラウドは、トラフィックが時間とともに大きく変動し、組織がすでにそのクラウドを利用していて、ネットワークの往復時間がレイテンシ予算内に収まる場合に特に適しています。また、パイロット時にも有用です。ワークロードが把握できる前に専用GPUフリートを購入・運用することで、先行コストが発生するのを避けられます。

その代わり、プロバイダーのエンドポイントモデル、リージョン、クォータ、料金体系への依存が生じます。パイロット規模では安価なサービスでも、すべてのカメラがすべてのフレームをクラウドに送信すると、本番環境で最大のコストになる可能性があります。

コンピュータービジョンにおけるセルフホストとは#

セルフホストのデプロイでは、組織がサービングインフラを運用します。データセンターのサーバー、Kubernetesクラスター、生産ライン脇の産業用コンピューター、カメラに接続された組み込みデバイスなどが該当します。

組織は、データの流れとソフトウェアを変更するタイミングを制御できます。その一方で、キャパシティ計画、GPUドライバー、ランタイム互換性、モデルのロールアウト、オブザーバビリティ、セキュリティ更新、バックアップ、復旧も担います。「自社ハードウェアで動く」だけでは、これらの各業務の担当者が決まっていない限り、運用モデルとは言えません。

推論をオフラインで続ける必要がある場合、画像を拠点外に持ち出せない場合、または安定した大量ワークロードによって専用コンピューティングが経済的になる場合は、セルフホストが特に適しています。また、クラウドとの往復時間では満たせないレイテンシ予算内で結果を返す必要があるアプリケーションにも自然な選択肢です。

その代わり、運用の負荷が増します。1台のGPUでコンテナが動作することと、多数の拠点で信頼性の高い本番サービスを運用することは同じではありません。

実際のコストを比較する#

クラウドエンドポイントのリクエスト料金とサーバーの購入価格を比較してはいけません。同じ期間とワークロードを対象に、システム全体のコストを比較してください。

マネージドクラウドでは、以下を含めます：

• 推論用コンピューティングと、最低プロビジョニング容量があればその費用；
• ストレージとデータ転送；
• 監視、ログ、保持するアーティファクト；
• 開発用エンドポイントとステージング用エンドポイント；
• トラフィック急増の合間も稼働し続けるアイドルリソース；および
• サービス統合とコスト管理に必要なエンジニアリング時間。

セルフホストでは、以下を含めます：

• サーバー、エッジデバイス、アクセラレーター、予備容量;
• 設置、電力、冷却、施設へのアクセス;
• オーケストレーション、監視、更新のためのインフラ;
• ドライバー、ランタイム、セキュリティ、インシデント対応にかかるスタッフの時間;
• 交換用ハードウェアとサポート、そして
• ピーク時や障害に備えて確保する容量。

ワークロードの特性によって答えは変わります。不確実な需要や急増する需要には、ハードウェアを購入せずに容量を追加できるため、クラウドが適しています。利用率が高く、予測可能で、インフラを運用する人員がすでにいる場合は、専用インフラの魅力が高まります。

レイテンシと帯域幅を比較する#

コンピュータービジョンのワークロードは、データ転送の影響を特に受けやすいものです。画像や動画は通常のAPIペイロードよりはるかに大きく、カメラがアプリケーションで分析する必要のある量を超えるフレームを生成することもあります。

まず、アプリケーションのエンドツーエンドのレイテンシ予算を確認します。撮影、エンコード、ネットワーク転送、キューイング、推論、そして機械やユーザーに判断結果を返すまでの時間を含めます。結果がロボット、生産ライン、安全警報を制御する場合は、モデル管理をクラウドに残す場合でも、ローカル推論が必要になることがあります。

帯域幅は別の制約です。連続動画をリモートエンドポイントに送信すると、コストの大部分を占める可能性があり、接続が不安定な場合には失敗することもあります。エッジシステムでは推論をローカルで実行し、イベント、メタデータ、選択したフレームのみを上位システムに送信できます。

プライバシーとデータ境界を比較する#

「オンプレミス」と「プライベート」は同じ意味ではありません。セルフホスト型システムでもセキュリティが不十分な場合があり、マネージドサービスでも強力な制御を提供できます。判断は、次のデータマップの作成から始めます。

• 元画像を撮影・保存する場所;
• 派生画像やクロップ画像が施設外に出るかどうか;
• ラベルとアノテーションの保存場所;
• データから学習した情報をどのモデルアーティファクトが保持しているか;
• 各レイヤーにアクセスできるスタッフとシステム、そして
• ログ、リクエスト、出力を保持する期間。

Ultralytics Platformのオンプレミス連携は、境界を具体的に定める必要がある理由を示しています。取り込み、プレビュー、トレーニングの際、元データセットと派生データセットのピクセルは接続されたコンピューター上に保持されます。クラス、ラベル、アノテーションはPlatformのメタデータとして保存され、トレーニング指標はPlatformにストリーミングされ、最良のチェックポイントは後続のワークフローで使用するためにアップロードされます。この設計では、データセットのピクセルをローカルに保ちますが、すべてのアーティファクトがローカルに留まるとは主張していません。

コンプライアンス管理策として扱う前に、組織の要件に照らして最新のUltralytics Platformオンプレミスドキュメントを確認してください。

スケーリングと信頼性を比較する#

マネージドプラットフォームは、エンドポイント容量を追加する作業を軽減できますが、自動スケーリングは即時ではなく、各サービスには制限があります。コールドスタート、キューの挙動、必要なリージョンで利用できる容量を測定してください。

セルフホスト型のスケーリングには、計画的なエンジニアリングが必要です。モデルのパッケージ化、リクエストの負荷分散、GPUのスケジューリング、ノード障害時の処理方法はチームが決定します。Kubernetesはインフラの調整に役立ちますが、適切なレプリカ数、ロールアウトポリシー、レイテンシ目標を決めるものではありません。

エッジのフリートでは、信頼性はエンドポイントの稼働率だけではありません。デバイスが接続を失ったり、ハードウェアのリビジョンが異なったり、更新を受け取れなかったりする可能性があります。本番環境の計画には、モデルのバージョン管理、段階的なロールアウト、ロールバック、各拠点を訪問せずに障害を診断する方法が必要です。

実用的な3つのデプロイパターン#

マネージドトレーニングとマネージド推論#

データセットからエンドポイントまでの最短経路を求め、クラウドのレイテンシが許容できる場合に、このパターンを使用します。インフラを自ら管理する負担を最小限に抑えられるため、パイロット、社内ツール、需要が変動するサービスに適しています。

主な管理項目は、コスト上限、リージョンごとのデータ取り扱い、エンドポイントへのアクセス、サービスを後で移行する必要が生じた場合のエクスポート経路です。

マネージドトレーニングとセルフホスト型推論#

クラウドコンピューティングでモデル開発を簡素化しつつ、推論をローカルで実行する必要がある場合に、このパターンを使用します。マネージド環境でトレーニングと評価を行い、テスト済みのモデルをエクスポートして、エッジまたはデータセンターにデプロイします。

モデルの反復開発にはマネージドコンピューティングが役立つ一方、本番環境での判断はネットワーク往復に依存できないため、このパターンは製造業やロボティクスでよく使われます。

ローカルデータとトレーニング、マネージドなライフサイクルツール#

元データを管理下のインフラに保持する必要がありながら、アノテーション、指標、モデル管理に共通のインターフェースを利用したい場合に、このパターンを使用します。Ultralytics Platformオンプレミスは、この分担を想定して設計されています。データセットのピクセルとトレーニングの計算処理は接続されたコンピューターに保持し、選択したメタデータ、指標、完成したチェックポイントをPlatformに接続します。

運用上の表現で境界を文書化します。ローカルに保持するもの、アップロードするもの、別途送信された画像を処理するクラウドワークフローを明記してください。

一般的なワークロードの判断手順#

工場での検査。 ライン速度に合わせて部品を停止または振り分ける必要がある場合は、ローカル推論またはエッジ推論を優先します。マネージドトレーニングも適しています。

小売業または施設の分析。 連続動画によって帯域幅やプライバシーの問題が生じる場合は、エッジで前処理を行います。適切な場合は、イベントや選択したフレームをクラウドに送信します。

バッチ画像分析。 レイテンシに即時性が求められず、ジョブが集中して到着する場合は、マネージドクラウドが適していることがよくあります。

エアギャップ環境または接続が断続的な拠点。 推論と運用に必要なランタイム一式をセルフホストします。クラウドのコントロールプレーンをクリティカルパスに含めないでください。

開発者向けビジョンAPI。 特にトラフィックが不確実な段階では、マネージドエンドポイントによって立ち上げまでの時間を短縮できます。利用量が増える前に、リクエスト制限、可観測性、移行経路を設計してください。

デプロイ前に移行計画を立てる#

モデルファイルをダウンロードできるだけでは、ポータビリティが証明されたことにはなりません。次の一連の処理をテストしてください。

1. モデルを、移行先のハードウェアがサポートするランタイムにエクスポートします。
2. 元のサービスの外部で、前処理と後処理を再現します。
3. 固定のテストセットで出力の一致を検証します。
4. 監視、アクセス制御、ロールアウト手順を再構築します。
5. 移行先の環境でレイテンシとリソース使用量を測定します。
6. データ、ラベル、モデルのバージョン、監査記録の移動方法を文書化します。

この取り組みは現在のデプロイの改善にもつながります。障害、料金変更、新たなデータ要件によって急な移行を迫られる前に、潜在的な依存関係を明らかにできます。