本番環境用の ML パイプラインを準備するには、次のことを行う必要があります。
- パイプラインのコンピューティング リソースをプロビジョニングする
- ロギング、モニタリング、アラートを実装する
コンピューティング リソースのプロビジョニング
ML パイプラインを実行するには、RAM、CPU、GPU/TPU などのコンピューティング リソースが必要です。 十分なコンピューティングがないとパイプラインを実行できません。そのため パイプラインに必要なリソースをプロビジョニングするために 必要ありません。
サービング、トレーニング、検証のパイプライン。これらのパイプラインでは TPU、GPU、CPU です。ユースケースによっては、トレーニングとサービングを 使用するか 同じですたとえば、トレーニングは TPU を使用する、またはその逆を行う場合もあります。一般的に、 大規模なハードウェアでトレーニングしてから、より小さなハードウェアでサービングするのが一般的です。
ハードウェアを選択する際は、次の点を考慮してください。
- 安価なハードウェアでトレーニングできますか？
- 別のハードウェアに切り替えると、パフォーマンスが向上しますか？
- モデルのサイズはどれくらいか、パフォーマンスを最適化するハードウェアはどれか？
- モデルのアーキテクチャではどのハードウェアが理想的ですか？
データ パイプライン。データ パイプラインには RAM と CPU の割り当てが必要です 予測を行うために必要な トレーニング データセットとテスト用データセットの生成にパイプラインで必要な割り当ての量です。
パイプラインごとに割り当てを割り当てない場合があります。代わりに パイプラインが共有する割り当てが 割り当てられますこのような場合は、 すべてのパイプラインを実行するのに十分な割り当てがあること、 変更することで、1 つの誤ったパイプラインですべての割り当てが消費されるのを防ぐことができます。
割り当ての見積もり
データとトレーニング パイプラインに必要な割り当てを見積もるには、以下をご覧ください。 類似のプロジェクトを作成できます。配信割り当てを見積もるには 秒間クエリ数を予測しますこれらのメソッドはベースラインを提供します。として テストフェーズでソリューションのプロトタイピングを開始すると、 割り当てのより正確な推定額を取得できます
割り当てを見積もる際は、本番環境だけでなく、割り当ても考慮する必要があります。 継続的なテストにも活用できます
理解度をチェックする
ロギング、モニタリング、アラート
本番環境モデルの動作をログに記録してモニタリングすることは非常に重要です。Robust モニタリング インフラストラクチャにより、モデルが信頼性の高い 構築できます。
ロギングとモニタリングを適切に行うと、ML の問題をプロアクティブに特定できます。 潜在的なビジネスへの影響を軽減できます。問題が発生すると 包括的なログにより、インフラストラクチャの診断が容易になり、 特定することです
ロギングとモニタリングを実装して、次の問題を検出する必要があります。 ML パイプラインの場合：
| パイプライン | モニタリング |
|---|---|
| サービス提供 |
|
| データ |
|
| トレーニング |
|
| 検証 |
|
以下に対するロギング、モニタリング、アラートも必要です。
- レイテンシ。予測を提供するのにかかる時間
- サービス停止。モデルによる予測の提供は停止しましたか？
理解度をチェックする
モデルのデプロイ
モデルのデプロイでは、次の内容を文書化する必要があります。
- デプロイを開始し、ロールアウトを増やすには承認が必要です。
- モデルを本番環境に投入する方法
- モデルがデプロイされる場所（ステージング環境やカナリア環境など） 必要があります。
- デプロイが失敗した場合の対応方法
- すでに本番環境にあるモデルをロールバックする方法。
モデルのトレーニングを自動化したら、 3 つありますデプロイを自動化すると、 デプロイがボトルネックになる可能性が低減されます。 1 人です。また、潜在的なミスが減り、効率が上がり、 オンコール ローテーションと SRE サポートが可能になります。
通常、新しいモデルをユーザーのサブセットにデプロイして、モデルが 確認する必要があります正しい場合は、デプロイを続行します。そうでない場合 Deployment をロールバックし、問題の診断とデバッグを開始します。