4. 堅牢なパイプラインとプロモーション

4.1 大規模な分散トレーニング

成熟した ML システムは、大規模なコンピューティング最適化インスタンスでトレーニングを並行して実行する機能をサポートします。これらのリソースが十分に活用され、トレーニングがコンピューティングクラスター全体で均等にスケーリングされるようにするためのツールが用意されています。

4.2 複数のフレームワークのサポート

開発者は、PyTorch や Flax などのさまざまなプラットフォームフレームワークを移植して、トレーニングジョブや推論ジョブを実行できます。同様に、さまざまな言語とバージョンがサポートされ、使用できます。別のフレームワークに切り替えても、システムが破損することはありません。

4.3 ハイパーパラメータの調整

ハイパーパラメータの調整ステップは、トレーニングパイプラインの一部です。デプロイされたモデルでは、ハイパーパラメータが調整されています。ハイパーパラメータの調整には複数のオプションがあります。精度を向上させるには、少なくとも 1 つの調整オプションにベイズ推論またはアプローチが必要です。

4.4 AutoML オプション

手作業での実験と比較を減らすために、成熟した ML システムは AutoML の実行をサポートします。AutoML は、最適な機能パイプライン、ハイパーパラメータ、モデルを自動的に選択します。AutoML は実用的な機能ですが、万能薬ではないことに注意してください。

4.5 推論のサポート: リアルタイム

これは一般的に、Model as a Service (MaaS) と呼ばれます。このシステムは、REST API オペレーションによるリアルタイム推論をサポートし、オンデマンドで推論リクエストを行います。モデルの水平スケーリングと垂直スケーリングのどちらにも対応する MaaS インフラストラクチャを、スタンドアロン API または他のアプリケーションに関連付けられたエンドポイントとして配布できます。または、サーバーレステクノロジーを使用してデプロイすることもできます。

4.6 推論のサポート: ストリーミング

Amazon Kinesis や Amazon Managed Streaming for Apache Kafka などのリアルタイム推論形式にモデルを昇格できます。これにより、推論はモデル上でストリーミング形式で実行されます。リアルタイム推論にはガードレール、オブザーバビリティ、モニタリングが不可欠であるため、チェックリストの少なくとも 90% を満たす必要があります。

4.7 推論のサポート: バッチ

モデルのバッチデプロイは、スケジュールされたジョブまたは開始されたジョブとしてサポートされます。システムは、抽出、変換、ロード (ETL) プロセスの一部として、または単独でモデルを実行できます。バッチジョブは、各ステップの状態を記録し、有向非巡回グラフなどの順序付けられたパターンで実行されます。または、ジョブはモデル推論のサーバーとして機能するデータベースに書き込むことができます。

4.8 前処理と後処理ルーチン

必要に応じて、データはモデル取り込みプロセスまたはバッチジョブの一部として特徴化されます。複数のモデルまたは複数のステップが進行中である場合、後処理ルーチンがデータの機能化を処理します。

4.9 階層モデルまたは同時モデルを呼び出す機能

ML システムは、多くのモデルを一緒にデプロイしたり、順番に実行したりできます。前者は、リソースのフリート全体で単一のエンドポイント上でモデルをホストすることを意味します。後者は、複数のモデルを順番に連鎖的に実行する必要があることを意味します。システムは、どちらのタイプの複雑さも弾力的に処理できます。

4.10 水平スケーリング戦略と垂直スケーリング戦略

パイプラインは、トレーニングと推論のための両方のスケーリング戦略をサポートする必要があります。ML システムは、レイテンシーまたはスループットが増加すると、そのサイズを増やし、複数のマシンにトラフィックを分散できます。このタイプの動作のためのポリシーが設定され、最適なリソース割り当てが考慮されます。

4.11 エンドツーエンドのログ記録

開発チームは、ログ記録がシステム内の入力、出力、中間ステップをキャプチャできるように、すべてのパイプラインコード内にログ記録を設定する必要があります。ログ記録は、パイプラインでの実行のトレースとエラーのデバッグをサポートする必要があります。