Azure 上の AI ワークロード用のアプリケーション プラットフォーム

効率、運用のセキュリティ、信頼性を最大限に高めるために、AI ワークロードがデプロイされているアプリケーション ホスティング プラットフォームを慎重に検討する必要があります。

この設計領域では、AI ワークロードに関連する可能性があるいくつかの種類のアプリケーションについて説明します。

• 探索的データ分析 (EDA)
• モデルトレーニングと微調整
• 推論

この記事では、ビジネス ニーズを満たすために、これらの各機能に最適なプラットフォームを選択するためのガイダンスを提供します。 これらのすべての関数に適用できる一般的な推奨事項もあります。

推奨事項

この記事で提供される推奨事項の概要を次に示します。

EDA プラットフォームに関する考慮事項

EDA は、データ サイエンティストがモデリングまたは統計分析の前に実行する一般的な予備関数です。 したがって、開発フェーズと見なすことができます。つまり、信頼性とパフォーマンスのターゲットは、運用リソースのターゲットよりも大幅に低くなり、生産性を維持することがより重要な要素になります。

このセクションでは、EDA プラットフォーム ソリューションを選択するときに考慮する機能に関するガイダンスを提供します。

機能要件

EDA プラットフォームを評価するときは、次の点を考慮してください。

• プラットフォームは一時的な使用をサポートしていますか?

  プラットフォームは、一時的なワークスペースとコンピューティングをサポートする必要があります。つまり、必要なリソースが使用されていないときに停止できる必要があります。 この機能は、コストの管理に役立ちます。 通常、EDA ジョブは対話型であるため、ユーザーは VM を起動し、ジョブの実行時にそれらを停止できる必要があります。

• プラットフォームはコンピューティングのオプションをサポートしていますか?

  プラットフォームでは、必要に応じて GPU へのオンデマンド アクセスを有効にし、プラットフォームのサイズを適切に設定するのに役立つさまざまなコンピューティング オプションを提供する必要があります。

• プラットフォームは MLflow をサポートしていますか?

  EDA プラットフォームでは、実験を追跡するために MLflow との統合を可能にするテクノロジを選択できるようにする必要があります。 MLflow は、次の利点があるため、モデル開発、デプロイ、および管理プロトコルとしてお勧めします。

  • 実験の追跡。 MLflow を使用すると、パラメーター、メトリック、成果物を記録して実験を追跡できます。 この機能は、さまざまなデータ前処理手順と特徴エンジニアリング手法とそのモデル パフォーマンスへの影響を追跡できるように、EDA 中に不可欠です。
  • 再現。 実験のすべての詳細がログに記録されるため、MLflow は結果を確実に再現するのに役立ちます。これは、結果の検証に不可欠です。
  • データとモデルのバージョン管理。 MLflow は、データセットとモデルのバージョン管理に役立ちます。これにより、さまざまなバージョンのデータ変換とテスト済みモデルを簡単に管理できます。
  • 共同作業。 MLflow は、データ サイエンティストが実験と結果を共有できる一元化されたプラットフォームを提供し、コラボレーションと知識の共有を容易にします。

非機能要件

次の質問も考慮してください。

• プラットフォームがコストを管理するのにどのように役立ちますか?

  このプラットフォームでは、データ サイエンティストがスケジュールの要件に従って作業を実行できるようにする必要がありますが、コストの期待が満たされるように適切なサイズにする必要があります。

• プラットフォームでは、どのようなセキュリティ要件に従う必要がありますか?

  EDA フェーズで使用されるデータは、運用データである可能性があります。そのため、運用プラクティスに従ってデータをセキュリティで保護し、プラットフォームを監視する必要があります。 そのためには、次のような必要なすべてのセキュリティ制御をプラットフォームでサポートする必要があります。

  • アクセスと承認。
  • 保存時と転送中の暗号化。
  • リージョンデータ保護の要件。
  • ログ記録と監査可能性など、堅牢な監視とアラート機能。
  • コンテナー イメージ、データ、およびコード資産の一元化されたリポジトリへのプライベート ネットワーク アクセス。

ツール

Azure Machine Learning コンピューティング インスタンスを使用しますチーム レベルのファイル共有を EDA プラットフォームとして使用します。 これに対する 1 つの例外は、たとえば、チームまたは組織が Databricks の GPU 対応コンピューティング クラスターなどの適切なホスティング プラットフォームを既に使用している場合です。 その場合は、そのプラットフォームに留まる方が適切な場合があります。

モデルトレーニングと微調整プラットフォームに関する考慮事項

モデルのトレーニングと微調整に移行する場合は、それらのアクティビティに必要なコンピューティング集中型の作業のために、高パフォーマンスの GPU 最適化コンピューティングが必要になる可能性があります。 この作業のほとんどはバックグラウンドで行われるため、通常、信頼性はパフォーマンスほど重要ではありません。 高い信頼性が必要な場合は、ワークロードを可用性ゾーンまたはリージョン全体に分散する必要があるかどうかを評価します。 モデルの鮮度を頻繁に更新する場合は、高い信頼性がより重要になり、より厳密なスケジュールでトレーニングを完了する必要があります。 RTOは、選択した信頼性設計を決定する必要があります。

このセクションのガイダンスは、モデルのトレーニングと微調整の両方に適用されます。 これらの関数に個別のプラットフォームを使用することを強制されない限り、単一のプラットフォームを使用する必要があります。

機能要件

モデルのトレーニングと微調整のためにプラットフォームを評価する場合は、次の質問を考慮してください。

• プラットフォームは一時的な使用をサポートしていますか?

  EDA アクティビティと同様に、モデルのトレーニングと微調整は通常、フルタイムで実行されないため、コストを制御するために使用されていないときに停止できるプラットフォームを使用する必要があります。 ただし、EDA とは異なり、モデル トレーニングは通常バッチ プロセスであるため、コンピューティングはバッチの実行時にのみ必要であり、次の実行までシャットダウンできます。

• プラットフォームはオーケストレーションを提供しますか?

  モデルのトレーニングと微調整のためにコンピューティングを管理する際に必要な複雑さがあるため、オーケストレーターをお勧めします。

• 環境内の既存のテクノロジをソリューションの一部にすることはできますか?

  Azure Databricks など、既存のデータ プラットフォームに機械学習機能がある場合は、データ変換や特徴エンジニアリング、トレーニング、微調整、Machine Learning のその他の手順など、特定の手順に使用できます。 テクノロジを組み合わせることにより、理想的には適さない関数に対するデータ プラットフォームの使用に伴うコストと複雑さを最小限に抑えることができます。

非機能要件

この質問も考慮してください。

• コストとパフォーマンスの間の許容できるトレードオフは何ですか?

  高パフォーマンスで GPU に最適化されたコンピューティング要件を考えると、パフォーマンスとコストのバランスを取る理想的な SKU を決定するために、トレーニングと微調整を広範にテストしてベンチマークすることを確認してください。

ツール

Azure Machine Learning は、バッチ コンピューティングのサポートを備えたオーケストレーション機能を提供するため、モデルトレーニングと微調整プラットフォームに推奨されます。 評価するコンピューティング オプションは 2 つあります。

• サーバーレス コンピューティング は、ノイズの多い近隣の影響を許容できる、短時間で頻度の低い実行に最適です。 標準価格またはスポット価格のいずれかを選択できます。 スポット価格は、非常に中断可能なトレーニングにのみ推奨されます。 サーバーレス コンピューティングは、フルタイム操作には使用しないでください。 コストは迅速にエスカレートできます。
• コンピューティング クラスター 使用可能なハードウェアを大幅に制御でき、並列または分散トレーニング用に調整されます。

モデルホスティングおよび推論プラットフォームに関する考慮事項

モデル ホスティングと推論関数は、AI ワークロードのサービス レイヤーを構成します。 これらの機能は、使用するソフトウェアに固有のエンドポイントで実行されます。 NVIDIA Triton、TorchServe、TensorFlow Serving などのモデル提供ソフトウェア ソリューションは、基本的に、API を使用してモデルを前面に出し、ソリューションに固有の機能を追加する Python SDK です。 ソフトウェアの選択に基づいてホスティング プラットフォームを選択することも、ホスティング プラットフォームの選択に基づいてソフトウェアを選択することもできます。

Azure OpenAI で利用できる大規模な言語モデルなど、事前にパッケージ化されたモデルで SaaS または PaaS ソリューションを使用する場合、提供するソフトウェアを選択する機会はほとんどありません。 代わりに、使用しているサービスによって API が提供されます。 これにより、モデル デプロイを作成するプロセスの柔軟性が低下し、長所と短所が得られます。 たとえば、ワークロードの開発プロセスを効率化できます。 一方、アプリケーションがモデルを呼び出して対話する方法の柔軟性が低下します。

基本的に、サービス レイヤーの API はマイクロサービスであるため、環境内の他のマイクロサービスに対して従うのと同じプラクティスに従う必要があります。 コンテナー化し、他のサービスからして、他のサービスや API から独立した独自のライフサイクルを持つ必要があります。 ただし、レイヤー API を提供する場合は、一般に、従来の API よりも GPU ベースのコンピューティング能力と大きなコンテナー イメージが必要であることに注意してください。

このセクションでは、モデルホスティングおよび推論プラットフォームを選択するときに考慮する機能に関するガイダンスを提供します。

機能要件

モデルのホスティングと推論のプラットフォームを評価する場合は、次の質問を考慮してください。

• ワークロードにはバッチ推論またはオンライン推論が必要ですか?

  推論エンドポイントはバッチ推論プロセスまたはオンライン推論プロセスに使用され、推論方法は適切なホスティング プラットフォームを決定するのに役立ちます。 バッチ推論は、一時的な使用をサポートし、使用されていないときにコンピューティングをシャットダウンできるプラットフォームで最適にホストされます。 オンライン推論は、任意の時点で負荷に基づいて自動的にスケーリングされるエラスティック コンピューティング使用率をサポートするプラットフォームで最適にホストされます。

• プラットフォームは追跡可能性をサポートしていますか?

  追跡可能性は、ワークロードで使用されるモデルの整合性を維持するために重要です。 モデルに関する情報 (現在のバージョン、デプロイしたユーザー、デプロイ日時、モデルのデータ系列など) を把握することが重要です。

  コンテナー レジストリ内のイメージに意味のあるタグを適用して、モデル ホスティング サービスがチームが簡単に識別できる特定のバージョンを確実にプルできるようにします。 このアプローチは、運用環境で使用されている古いモデルや不適切なモデルのリスクを軽減することで、データ ガバナンスに役立ちます。

• ホスティング プラットフォームは一元化されたリソースになりますか?

  多くの組織では、さまざまなチームが独自のワークロードに使用する一元化されたモデル ホスティング プラットフォームを使用しています。 ホスティング プラットフォームが一元化されている場合は、チャージバックのサポートが必要かどうかを検討する必要があります。 この機能を使用すると、チームとワークロード別にプラットフォームの使用率を追跡できます。

非機能要件

次の質問も考慮してください。

• プラットフォームの信頼性要件は何ですか?

  サービス レイヤー API は運用リソースであるため、その 重要度 評価に一致する他のワークロード フローに適用するのと同じ信頼性要件を適用する必要があります。 重要度に高可用性が必要な場合は、ホスティング プラットフォームで可用性ゾーンまたはマルチリージョン設計をサポートする必要があります。

• プラットフォームに必要なネットワーク制御は何ですか?

  プラットフォームの保護を提供するためにプライベート ネットワークまたはエグレス ファイアウォールが必要かどうかを判断します。

• プラットフォームの ID とアクセスセキュリティの要件は何ですか?

  エンドポイントに必要な ID とアクセス制御を決定します。 ネイティブのロールベースのアクセス制御 (RBAC) または ID とアクセス プラットフォームの組み込みサポート (Microsoft Entra ID など) が必要かどうかを検討します。

• プラットフォームはどのような監視機能をサポートしていますか?

  エンドポイントに必要な監視機能を決定します。 プラットフォームによっては、ログとメトリックへのアクセスが制限されている場合があり、アクティビティを監査したり、誤動作を検出したりする機能が制限される可能性があります。

• プラットフォームのパフォーマンス要件は何ですか?

  推論の待機時間は一般的な懸念事項であり、プラットフォームによってパフォーマンス プロファイルが異なります。 ユーティリティ モデルを使用するサーバーレス サービスと PaaS サービスは、ノイズの多い近隣の問題の影響を受ける可能性があり、多くの場合、スループットの保証はありません。 一方、同じプラットフォームでは、購入前モデルで保証されたスループットを提供するセルフホステッド オプションが提供される場合があります。 さらに予測可能な待機時間の動作のために、Kubernetes でのセルフホスティングを検討することもできます。

  Azure OpenAI の場合と同様に、パフォーマンスに影響する可能性があるサービスの制限とクォータに注意してください。 多くの場合、これらのクォータと制限は容量の需要を満たすように積極的に設定されるため、プラットフォームの選択で必要なパフォーマンスが提供されない場合は、インスタンス間でコンピューティング需要を分散するための戦略を採用する必要があります。

  高度なアーキテクチャでは、複数のデプロイを組み合わせて、ワークロードの大部分の固定スループットと、より柔軟なコンピューティングのためのバースト機能を実現できます。

ツール

バッチ推論

• Databricks などのモデル ホスティングをサポートするプラットフォームに存在するデータに対して推論を実行する場合は、そのプラットフォームを推論に使用することを検討してください。 推論コンピューティングは、データ プラットフォームによって実行される他の関数から分離してください。

• 基盤モデル Azure OpenAI Batch API をお勧めします。

• 非基礎モデルの場合は、次の推奨事項を検討してください。

  • 次のシナリオでは、 Azure Machine Learning バッチ エンドポイント を使用することを検討してください。

    • 複数のファイルに分散されている大規模なデータセットに対して推論を実行する必要があり、待機時間を短くする必要はありません。

    • 大規模なデータセットに対して実行時間の長いバッチ操作を実行する必要があり、並列処理を利用できます。

    • バッチ処理用のパイプライン コンポーネントをデプロイする必要があります。

  • 分散データ処理のために Spark ジョブを実行する必要がある場合は、 Azure Synapse Analytics、 Databricks、またはmachine Learning サーバーレス Spark コンピューティング 使用することを検討。

  • これらのシナリオのいずれも適用されない場合は、Machine Learning バッチ エンドポイントをお勧めします。

オンライン推論

• プラットフォーム PaaS とサーバーレス ソリューションを最初のステップとして評価します。 通常、これらのサービスは、設計を簡素化し、運用上の負担を最小限に抑えるため、導入と管理が最も簡単です。 たとえば、Azure OpenAI は基礎モデルに適しています。

  • Azure OpenAI または別の基盤モデル ホスティング ソリューションを使用している場合でも、Azure Machine Learning サーバーレス API を使用してエンドポイント アクセスを集計することを検討してください。

• PaaS またはサーバーレス ソリューションが最適でない場合は、マネージド コンピューティング クラスターでの Machine Learning を検討してください。 Machine Learning によって管理されるコンピューティングでは、A/B テスト、デバッグ、堅牢な監査のためのトラフィック分割とミラーリングがサポートされます。 コンピューティングはサービスによって管理されるため、モデルをセルフホストすると、Day-2 の操作が簡単になります。 マネージド コンピューティングには、コンピューティング構成とスケーリング機能も幅広く用意されています。

• Machine Learning または別のコンテナー ベースのプラットフォームに接続 Azure Kubernetes Service (AKS) クラスターでモデルをセルフホストする場合は、予測可能なパフォーマンスを実現し、セキュリティを最適化するために、ノード プールが他の API またはクラスター上の他のワークロードから分離されていることを確認してください。 コストを削減するために、AI ワークロード関数以外に GPU ベースまたは GPU 最適化コンピューティングを使用しないようにします。 代わりに、テストを通じてパフォーマンス ベースラインを確立し、過剰なプロビジョニングを行わずにパフォーマンス要件を満たすようにコンピューティングのサイズを適切に設定します。

• Azure Data Science Virtual Machine などのサービスとしてのインフラストラクチャ (IaaS) ソリューションを使用して、モデルをセルフホストすることもできます。

オーケストレーション プラットフォームに関する考慮事項

オーケストレーションは、AI ワークロード アプリケーション プラットフォームのコンテキストで、 Machine Learning および Azure AI Studio でのプロンプト フローなどのツールを指します。 これらのツールは、多くの一般的なワークフロー機能を自動化することで、AI アプリケーションの開発サイクル全体を効率化するように設計されています。

非機能要件

クラウド資産内の他のすべての運用ワークロードと同様に、オーケストレーション ツールを評価するときは、次の点を考慮する必要があります。

• 信頼性、セキュリティ、監視。 オーケストレーション ツールは、運用ワークロードの信頼性、セキュリティ、監視の標準に準拠している必要があります。

• パフォーマンス。 オーケストレーション ツールでは、GPU 最適化または GPU ベースのコンピューティングは必要ありません。汎用 SKU を検討してください。

• コストの最適化。 オーケストレーション ツールは使用コストを最小限に抑えるために、エラスティック コンピューティング オプションを検討してください。

ツール

• プロンプト フローのような既製のソリューションを好みます。 LangChain やセマンティック カーネルなどのツールを使用してカスタム ホスティングを調べる前に、その機能がオーケストレーションのニーズと一致するかどうかを判断します。

• コンピューティング インスタンスを使用した Machine Learning でのプロンプト フローや、自己ホストを使用した AKS でのプロンプト フローなどのソリューションのエンドポイントをホストします。

次のステップ