注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

トレーニング済みモデルノード

トレーニング済みモデルノードを使用すると、Foundry 内外でトレーニングされたユーザー定義の機械学習モデルを、Pipeline Builder のパイプライン内で直接実行できます。これにより、ML チームやノーコードユーザーは、コードを書くことなく、モデル推論をデータパイプラインにシームレスに統合できます。

はじめに

次の手順でモデルをインポートし、バッチパイプラインまたはストリーミングパイプラインで入力と出力を設定します。

1. パイプラインを設定する

バッチパイプラインの場合は、Spark(バッチ)モードを使用していること、およびウォームプールがオフに設定されていることを確認してください。既存のパイプラインが Spark(バッチ)モードを使用するように設定されていない場合は、新しいパイプラインを作成します。

ウォームプールが無効になっているバッチパイプラインで作業していることを確認します。

ストリーミング実行の場合は、ストリーミングパイプラインを開くか、作成します。

ストリーミングパイプラインで作業していることを確認してください。

2. モデルをインポートする

インポートメニューで変数・関数 > トレーニング済みモデルに移動し、リソースのインポートフローに沿って進め、モデルをパイプラインで利用できるようにします。

トレーニング済みモデルのインポートメニュー。

3. モデルノードを追加する

パイプラインキャンバスでノードを選択し、トレーニング済みモデルを選択して挿入します。

トレーニング済みモデルの選択肢は、ステップ2に従ってパイプラインにモデルを1つ以上インポートした後にのみ表示されます。

パイプラインキャンバスでトレーニング済みモデルノードを選択する様子。

4. 入力と出力を設定する

入力列と出力列を、モデルが期待する API スキーマにマッピングします。

  • 入力列では、列の直接マッピングだけでなく、式もサポートされています。モデルに渡す前に、入力データにキャスト、変換、その他の式を適用できます。
  • 出力列には、結果のデータセットで別名を付けることができます。これにより、モデル自体を変更することなく、モデルの出力フィールドの名前を変更できます。
トレーニング済みモデルノードの入力列と出力列のマッピング。

5. パイプラインをデプロイする

ストリーミングパイプラインの場合は、デプロイする前にストリーミング設定を完了します。

モデルノードをパイプライン出力に接続し、保存を選択します。デプロイ、次にパイプラインをデプロイを選択します。デプロイとビルドのオプションについては、パイプラインを配信するを参照してください。

ストリーミング設定

モデルのインポート、ノードの作成、入力/出力のマッピングの手順は、バッチパイプラインとストリーミングパイプラインで同じです。ストリーミング実行では、推論のためにレコードをどのようにグループ化するかも設定する必要があります。

パーティションキーとウィンドウ処理を設定する

モデルノードの入力と出力を設定した後、ストリーミング設定を開きます。

  1. モデルがまとめて処理するレコードを識別するパーティションキー列を選択します。たとえば、系列識別子を使用して、時系列ごとにレコードを分離します。モデルノードより前ですでに設定されているパーティションキーを使用することもできます。ワーカー間でのレコードの分散については、ストリーミングのパーティションキーを参照してください。
  2. ウィンドウの種類を選択し、そのサイズを設定します。モデルに十分なレコードを供給しつつ、メモリーと低遅延の要件を満たすサイズを選択します。
  3. イベント時間ウィンドウの場合は、モデルノードの前にタイムスタンプとウォーターマークを割り当てを追加し、タイムスタンプ式を、各イベントが発生した時刻を表す列または式に設定します。イベント時間ウィンドウでは、ウィンドウに含めるレコードとウィンドウの完了を判断するために、これらのタイムスタンプとウォーターマークが必要です。ウォーターマークの進行状況、遅延レコード、アイドル状態の入力の処理については、イベント時間とウォーターマークを参照してください。
トレーニング済みモデルノードのストリーミング設定と入力列および出力列のマッピング。

モデルは、パーティションキーごとに、各ウィンドウで収集されたレコードに対して推論を実行します。ウィンドウが完了するまでの時間と推論時間の両方が、出力の低遅延に影響します。ウィンドウを大きくすると、結果が出るまでの待ち時間と、推論リクエストあたりの処理量が増える可能性があります。

デプロイ後は、ウィンドウが完了して推論が終了すると、出力ストリーム内のレコードを確認できます。出力の作成と確認については、ストリーミングパイプラインのウォークスルーを参照してください。ストリーミング実行では、トレーニング済みモデルのプレビューは利用できません。

サポートされるモデル

現在、モデル API に表形式の入力1つと表形式の出力1つを持つモデルのみがサポートされています。モデルには、必須の入力列が1つ以上必要です。

モデルノードを使用する場合、モデルはモデルの API で定義されている列を過不足なく返す必要があります。モデル API で定義されていない追加の列は削除されますが、必要な列がない場合はビルドエラーが発生する可能性があります。

ストリーム内の時系列

時系列モデルは、ストリーミングパイプラインでのみサポートされています。

ストリーミング設定のガイダンスに従い、時系列モデル用のレコードを準備します。

  • 異なる系列のレコードが別々に処理されるように、各時系列を識別するパーティションキー列を選択します。
  • 各観測が行われた時刻を表す列または式を使用して、タイムスタンプとウォーターマークを割り当てます。
  • イベント時間ウィンドウを使用して、タイムスタンプに基づいて観測をグループ化します。想定されるデータ頻度、メモリー要件、出力の低遅延を考慮し、モデルの推論に必要な時間間隔をカバーするウィンドウサイズを選択します。
  • 観測のタイムスタンプ、測定値、その他の必須列を、モデルの入力スキーマにマッピングします。

イベント時間ウィンドウとウォーターマーク処理では、レコードは並べ替えられません。モデルに順序付けられたシーケンスが必要な場合は、推論前にモデル内で入力レコードを観測のタイムスタンプ順に並べ替えてください。

サポートされる列のデータ型

この機能は、表形式の入力列と出力列に次のデータ型が含まれる API を持つモデルをサポートします。

  • プリミティブ: string, boolean, integer, long, float, double, date, timestamp
  • 複合: array, map, struct(ネストされたフィールドを含む)
  • メディア: mediaReference

mediaReference 列を使用すると、モデルは推論中に参照先のメディアアイテムを読み取れます。モデルアダプターでの Media Reference の使用については、Media Reference を参照してください。

objectSet などのサポートされていないデータ型は、検証時に拒否されます。

リソース設定とコンピューティングコスト

バッチ実行では、モデルは Spark エグゼキューターと並行して、分離されたサイドカープロセスとして実行され、それぞれに専用のリソースが割り当てられます。バッチ実行とストリーミング実行のいずれでも、モデルのサイドカーごとのデフォルトのリソース割り当ては次のとおりです。

リソースデフォルト
CPU1コア
メモリー8 GB
GPUなし

バッチビルドやストリーミング推論が遅い場合は、次のいずれか、または両方の対応を取ることができます。

  1. パイプラインのコンピューティングプロファイルを引き上げます。
  2. モデルに割り当てるリソースを増やします。

モデルのリソースを調整するには、モデルのインポートウィンドウ(変数・関数 > トレーニング済みモデル)を開き、リソースを設定を選択します。

リソース設定オプションが表示されたトレーニング済みモデルのインポートウィンドウ。

設定パネルが開き、CPU、メモリー、GPU の割り当てを調整できるほか、詳細な設定セクションでモデルの起動タイムアウトをオーバーライドできます。

リソース割り当てと詳細な設定のセクションが表示されたモデル設定ダイアログ。

リソース設定は、モデルノードごとではなく、Pipeline Builder のパイプラインごとに設定されます。ビルドまたはパイプライン内で同じモデルを使用するすべてのノードは、同じリソース設定を共有します。ストリーミングパイプラインでは、リソースの変更を適用するためにパイプラインを再デプロイしてください。

このサイドカープロセスの分離には、標準のトランスフォームと比較して、追加のコンピューティングオーバーヘッドが伴う点に注意してください。バッチ実行では、モデルごとに、すべての Spark エグゼキューターとドライバーでサイドカーが起動されます。ストリーミング実行では、モデルごとに、すべての Flink タスクマネージャーでサイドカーが起動されます。次の図は、バッチ実行でサイドカーがどのようにスケーリングするかを示しています。

Spark エグゼキューターとドライバー全体でモデルのサイドカーがどのようにスケーリングするかを示す図。

ストリーミングのタスクマネージャーとモデルのサイドカーは、レコードやウィンドウの完了を待っている間も含め、パイプラインの実行中は割り当てられたコンピューティングリソースを継続的に消費します。コストを見積もる際は、ワーカーの並列度、モデルのリソース割り当て、パイプラインの実行時間を考慮してください。ガイダンスについては、ストリーミングのコンピューティング使用量を参照してください。

モデルをパイプラインにインポートしていても、ノードとして使用していない場合は、サイドカーは起動されず、追加のコストも発生しません。

実行モード

実行モードサポート
バッチ (Spark)✅
ストリーミング✅
高速 (Lightweight/DataFusion)❌(予定)
プレビュー✅

自動アップグレードとブランチ

Pipeline Builder は、ビルドのブランチで利用可能なモデルの最新バージョンを常に使用します。たとえば、master でのビルドは、master に公開された最新のモデルバージョンを常に使用します。ビルドのブランチでモデルバージョンが見つからない場合、システムは設定済みのフォールバックブランチにフォールバックします。通常、別途設定されていない限り、これは master ブランチです。これにより、機械学習チームは、下流のビルドで最新バージョンが自動的に使用されることを前提に、安心してモデルを再トレーニングし、新しいバージョンを公開できます。現時点では、モデルノードを特定のバージョンに固定することはできません。バージョンを固定する機能は、今後の機能として予定されています。

ストリーミング実行では、実行中のパイプラインは読み込み済みのモデルバージョンを引き続き使用します。最新のモデルバージョンに更新するには、パイプラインを再起動または再デプロイします。

Marketplace

トレーニング済みモデルノードを使用するバッチパイプラインをパッケージ化すると、トランスフォームとして使用されるモデルが、コンテンツに含めるパッケージ化モードで Marketplace パッケージにリソースとして自動的に追加されます。つまり、インストール担当者は、1回のインストールでパイプラインとそれに関連するモデルの両方を受け取ります。モデルをパッケージ化するための追加設定は不要です。

また、バッチパイプライン内のモデルを DevOps で製品の入力として設定することもできます。これにより、インストール担当者はモデルをパッケージ化済みコンテンツとして受け取る代わりに、エンロールメントですでに利用可能なモデルを選択できます。

トレーニング済みモデルノードを含むストリーミングパイプラインは、Marketplace を通じて配布できません。

Pipeline Builder のパイプラインを Marketplace 製品に追加する方法の詳細については、パイプラインを Marketplace 製品に追加するを参照してください。

サイドカーのタイムアウト

バッチビルドまたはストリーミングパイプラインが起動すると、各モデルのサイドカーは、推論リクエストを処理できるようになる前にモデルをダウンロードして読み込む必要があります。デフォルトでは、システムはサイドカーの準備が整うまで最大10分待機します。この時間内に準備が整わない場合、モデルの読み込みがまだ続いている場合でも、サイドカーが停止した場合(多くはメモリー不足が原因)でも、実行はタイムアウトエラーで失敗します。

モデルの読み込みに必要な時間がこれより長い(または短い)場合は、デフォルトの起動タイムアウトをオーバーライドできます。モデルの構成ダイアログの詳細な設定で、モデルの起動タイムアウトのオーバーライドの値を秒単位で設定します。デフォルトを使用するには、項目を空のままにします。

起動タイムアウトのオーバーライドは、パイプライン内のモデルごとに設定され、バッチビルドまたはストリーミングパイプラインでそのモデルのために起動されるすべてのサイドカーに適用されます。

バッチ実行では、サイドカーの準備が整った後、個々の推論リクエストにタイムアウト制限はありません。つまり、複雑な計算を実行するモデルや大規模なバッチを処理するモデルなど、実行時間の長いモデルも、リクエストごとの時間制約を受けず、完了するまで実行されます。

ストリーミング実行では、実行時間の長い推論リクエストによって、対応するウィンドウの出力が遅延します。起動タイムアウトが制御するのはモデルの読み込みであり、推論の実行時間ではありません。

Foundry でのモデルのトレーニングとデプロイについて、詳しくはこちら。