Snowflakeモデルレジストリ¶
注釈
このトピックで説明するモデルレジストリ API は、 snowflake-ml-python パッケージバージョン1.5.0で一般的に利用可能です。
モデルをトレーニングした後、Snowflakeでモデルを運用して推論を実行するには、Snowflakeモデルレジストリにモデルをログに記録することから始めます。Model Registryを使用すると、オリジンやタイプに関係なく、Snowflakeでモデルとそのメタデータを安全に管理し、推論を簡単に実行することができます。
重要
Snowflakeモデルレジストリは、Snowflake ML エコシステム用にPythonで開発された機械学習モデルと連携します。Snowflake ML 関数 (例: FORECAST)を使用してトレーニングされたモデルはモデルレジストリに表示されません。Cortex微調整 LLMs などの一部のモデルタイプは、モデルレジストリの Snowsight UI に表示されますが、モデルレジストリ API によって管理されていません。
Snowflakeモデルレジストリは以下の機能を提供します。
モデルバージョン、モデルメトリック、モデルメタデータを保存・管理します。
Python、 SQL、または REST API エンドポイントを使用してモデルを提供し、分散推論をスケールで実行します。
柔軟なガバナンスオプションでモデルのライフサイクルを管理し、開発環境から生産環境までモデルを操作します。
Snowflake ML 可観測性を使用してモデルのパフォーマンスとドリフトを監視します。
ロールベースのアクセス制御(RBAC)でモデルアクセスを安全に管理します。
モデルレジストリは、機械学習モデルをSnowflakeのファーストクラスオブジェクトとして格納します。
After you have logged a model, you can invoke its methods (equivalent to functions or stored procedures) to perform model operations, such as inference , in a Snowflake virtual warehouse, or serve the model in Snowpark Container Services for GPU-based inference.
The Snowflake Model Registry has built-in types support for the most common model types, including scikit-learn, xgboost, LightGBM, Prophet, CatBoost, PyTorch, TensorFlow, Keras, Hugging Face pipelines, Sentence Transformer, and MLFlow pyfunc models. The Model Registry is also flexible and powerful enough to support your own previously-trained models, as well as any custom processing code.
Tip
これらのモデルタイプとエンドツーエンドのワークフローの例は、 例およびクイックスタート でご覧ください。
Snowflake Model Registry Python API の主なクラスです。
snowflake.ml.registry.Registry: スキーマ内のモデルを管理します。
snowflake.ml.model.Model: モデルを表します。
snowflake.ml.model.ModelVersion: モデルのバージョンを表します。
このトピックでは、 snowflake-ml-python ライブラリを使用して Python でレジストリ演算子を実行する方法について説明します。また、多くのレジストリ演算子を SQL で実行することもできます。Model Registry SQL を参照してください。
必要な権限¶
モデルを作成するには、モデルを作成するスキーマを所有するか、そのスキーマに対する CREATE MODEL 権限を持っている必要があります。モデルを使用するには、そのモデルを所有しているか、そのモデルに対する USAGE または READ 権限を持っている必要があります。
USAGE 権限により、付与対象者はモデルの内部を一切見ることなく、ウェアハウス推論にモデルを使用することができるようになります。
READ 権限により、付与対象者は SPCS 推論のモデルを使用でき、コメント、タグ、メトリックなどのメタデータも表示されます。
スキーマに存在するすべてのモデルへの USAGE アクセスをユーザーに与えるには、GRANT USAGE ON ALL MODELS IN SCHEMA <schema> TO ROLE <role> を使用します。 また、 GRANT USAGE ON FUTURE MODELS IN SCHEMA <schema> TO ROLE <role> を介して、スキーマに将来作成されるモデルへのアクセスをユーザーに自動的に与えることもできます。
同様に、同じ構文を使用して、 USAGE を READ に置き換えることで、スキーマ内のすべての既存または将来のモデルに対する READ アクセス権をユーザーに付与できます。
ユーザーのロールがモデルに対して OWNER、 USAGE または READ権限がある場合、その権限は Snowsightモデルレジストリページ に表示されます。Snowflake での権限の仕組みの詳細については、 アクセス制御権限 を参照してください。
現在の制限¶
以下の制限は、モデルおよびモデルのバージョンに適用されます。
モデル |
|
|---|---|
モデルのバージョン |
|
Snowflakeモデルレジストリを開く¶
モデルはファーストクラスのSnowflakeオブジェクトであり、他のSnowflakeオブジェクトと一緒にデータベースやスキーマ内に編成することができます。Snowflakeモデルレジストリは、スキーマ内のモデルを管理するためのPythonクラスを提供します。したがって、どのSnowflakeスキーマもレジストリとして使用できます。この目的のために、スキーマを初期化したり準備したりする必要はありません。Snowflakeは、 ML.REGISTRY のように、この目的のために1つ以上の専用スキーマを作成することを推奨しています。スキーマは、 CREATE SCHEMA を使用して作成できます。
レジストリのモデルを作成または変更する前に、レジストリを開く必要があります。レジストリを開くと、そのレジストリへの参照が返され、それを使用して新しいモデルを追加したり、既存のモデルへの参照を取得したりすることができます。
モデルおよびバージョンの登録¶
注釈
外部プロバイダーからSnowflakeにモデルをインポートすることもできます。詳細については、 外部サービスからモデルをインポートしてデプロイする をご参照ください。
レジストリへのモデルの追加は、モデルの ログ と呼ばれます。レジストリの log_model メソッドを呼び出してモデルをログします。Pythonオブジェクトであるモデルをシリアル化し、そこからSnowflakeモデルオブジェクトを作成します。説明などのメタデータを log_model 呼び出しで指定されたモデルに追加します。
各モデルは無制限にバージョンを持つことができます。モデルの追加バージョンをログするには、同じ model_name で異なる version_name を指定して log_model を再度呼び出します。
タグがレジストリに追加されている場合は、モデルにタグを追加することはできません。タグはモデルの属性であり、 log_model は特定のモデルのバージョンを追加し、最初のバージョン追加時にのみモデルを作成するからです。モデルの最初のバージョンをログした後に、 モデルのタグを更新する ことができます。
次の例では、 clf は、「classifier,」の略で、コード内で既に作成されたPythonのモデルオブジェクトです。ここに示すように、登録時にコメントを追加することができます。名前とバージョンの組み合わせは、スキーマ内で一意にする必要があります。conda_dependencies リストを指定します。指定したパッケージはモデルと合わせて展開されます。
ここで log_model の引数を説明します。
必要な引数
引数 |
説明 |
|---|---|
|
サポートされているモデル型のPythonモデルオブジェクト。シリアル化可能(「ピクル化可能」)である必要があります。 |
|
モデルの名前。レジストリでモデルを識別するために |
注釈
モデル名とバージョンの組み合わせは、スキーマ内で一意にする必要があります。
オプションの引数
引数 |
説明 |
|---|---|
|
モデルのバージョンを指定する文字列。レジストリでモデルを識別するために |
|
モデルをロードまたは展開する際にインポートするコードディレクトリへのパスのリスト。 |
|
コメント、たとえばモデルの説明など。 |
|
モデルに必要なCondaパッケージのリスト。この引数は `Conda形式<https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/pkg-search.html>`__、つまり |
|
モデルと一緒にピクルする外部モジュールのリスト。scikit-learn、Snowpark ML、 PyTorch、 TorchScript、およびカスタムモデルのサポート。 |
|
モデルバージョンにリンクされたメトリクスを含むディクショナリ。 |
|
モデル作成のオプションを含むディクショナリ。次のオプションはすべてのモデル型で利用できます:
個々のモデル型によっては、追加オプションをサポートしている場合もあります。組み込みモデルタイプの使用 をご参照ください。 |
|
モデルで必要な PyPI パッケージのパッケージ仕様のリスト。ウェアハウスで実行するモデルは、pipアーティファクトリポジトリも指定する必要があります(次の |
|
アーティファクトリポジトリタイプ( 指定すると、pip要件はウェアハウス環境のアーティファクトリポジトリ経由でインストールされます。以下のモデルはウェアハウスで実行可能です。scikit-learnは組み込み |
|
ウェアハウスリソース制約キーと値の辞書マッピング。例:{"archiver": "x86"}。これは、必要なアーキテクチャを持つウェアハウスでモデルを実行するために使用できます。 |
|
モデルを実行するターゲットプラットフォームのリスト。許容可能な入力は、 |
|
モデルを実行する Python のバージョン。デフォルトは |
|
サンプルの入力データを含む DataFrame 。この DataFrame から、モデルが必要とする特徴量名とその型が抽出されます。Snowpark ML と MLFlow 以外のモデルおよびHugging Faceパイプラインでは、この引数か |
|
メソッド署名を、ターゲットメソッド名から入力と出力の署名へのマッピングとしてモデル化します。Snowpark ML と MLFlow 以外のモデルおよびHugging Faceパイプラインでは、この引数か |
|
そのモデルが解決しようとする問題を定義するタスク。未指定の場合、Snowflakeはモデルクラスからモデルタスクを推測する最善の努力をします。モデルクラスが推測できない場合、モデルタスクは どのモニタリングメトリックがお客様のモデルに関連するかを識別するのに役立ちます。 有効な値:
|
|
ステージサブディレクトリのパスをローカルファイルパスのリストにマッピングした辞書。ファイルパスには Snowflake-ml-pythonのバージョンが>=1.7.3および<1.8.1の場合、ユーザーはユーザーファイルを含めるために以下のフラグをセットする必要があります。 |
log_model は、レジストリに追加されたモデルのバージョンを表す snowflake.ml.model.ModelVersion オブジェクトを返します。
一度登録されると、モデル自体を変更することはできません(メタデータを変更することはできます)。モデルとそのすべてのバージョンを削除するには、レジストリの delete_model メソッドを使用します。
依存関係やターゲットプラットフォームとの連携¶
target_platforms |
モデルタイプ |
|
その他のオプション |
|---|---|---|---|
(コンテナランタイムのデフォルト) |
組み込みモデルタイプ |
|
|
カスタムモデル |
|
||
(分割モデルの使用) |
組み込みモデルタイプ |
|
|
カスタムモデル |
|
|
|
(コンテナランタイムを除くすべてのデフォルト) |
組み込みモデルタイプ |
|
|
カスタムモデル |
|
|
モデルアーティファクトの操作¶
モデルがログに記録された後、その成果物(シリアライズされたPythonオブジェクトや、マニフェストなどの様々なメタデータファイルを含む、モデルをバックアップするファイル)は内部ステージで利用可能になります。アーティファクトを変更することはできませんが、所有するモデルのアーティファクトを表示またはダウンロードすることはできます。
注釈
モデルのUSAGE権限を持っていても、そのアーティファクトにアクセスすることはできません。
ステージからモデルアーティファクトにアクセスするには、例えば GET コマンド や、Snowpark Pythonの同等のコマンド FileOperation.get を使用します。
しかし、通常のステージパス構文を使ってモデルのアーティファクトを扱うことはできません。代わりに、 snow:// URL、Snowflakeのオブジェクトの位置を指定する、より一般的な方法を使用します。例えば、モデル内のバージョンは、 snow://model/<model_name>/versions/<version_name>/ という形式の URL で指定することができます。
モデルの名前と必要なバージョンを知っていれば、 LIST コマンド を使って、次のようにモデルのアーティファクトを表示することができます。
出力は似ています。
これらのアーティファクトを取得するには、 SQL GET コマンドを使用します。
あるいはSnowpark Pythonと同等です。
注釈
モデルのアーティファクトの名前と構成は、モデルのタイプによって異なり、変更されることがあります。上記のアーティファクトリストの例は、あくまで説明用であり、権威あるものではありません。
モデルの削除¶
レジストリの delete_model メソッドを使用して、モデルとそのすべてのバージョンを削除します。
Tip
DROP MODEL を使用して、SQL のモデルを削除することもできます。
レジストリからのモデルの取得¶
各モデルの情報を得るには、 show_models メソッドを使用します。
Tip
SQL で、 SHOW MODELS を使ってモデルのリストを取得します。
show_models の結果は、pandas DataFrame です。利用可能なカラムはこちらです。
列 |
説明 |
|---|---|
|
モデルが作成された日時。 |
|
モデルの名前。 |
|
モデルが格納されているデータベース。 |
|
モデルが格納されているスキーマ。 |
|
モデルを所有するロールの名前。 |
|
モデルのコメント。 |
|
モデルのバージョンをリストした JSON 配列。 |
|
バージョンを指定せずにモデルを参照する場合に使用されるモデルのバージョン。 |
代わりにレジストリにあるモデルのリストを、それぞれ Model インスタンスとして取得するには models メソッドを使用します。
レジストリから特定のモデルへの参照を名前で取得するには、レジストリの get_model メソッドを使用します。
注釈
Model インスタンスは、ログされた元のPythonモデルオブジェクトのコピーではなく、レジストリ内の基になるモデルオブジェクトへの参照です。
models メソッドで返されたリストのモデル、または get_model を使用して取得したモデルへの参照があると、 そのメタデータ と そのバージョン を操作することができます。
モデルのメタデータの表示および更新¶
レジストリ内のモデルのメタデータ属性(名前、コメント、タグ、メトリックなど)を表示したり、更新したりすることができます。
コメントの取得および更新¶
モデルのコメントを取得したり、更新したりするには、モデルの comment 属性を使用します。
注釈
description 属性は、 comment の同義語です。先のコードもこのように書くことができます。
Tip
ALTER MODEL を使って、 SQL にモデルのコメントを設定することもできます。
モデル名の変更¶
モデルの名前を変更したり移動したりするには、 rename メソッドを使用します。モデルを別のデータベースまたはスキーマに移動するには、新しい名前として完全修飾名を指定します。
Tip
ALTER MODEL を使用して、SQL のモデル名を変更することもできます。
モデルバージョンの操作¶
モデルは無制限にバージョンを持つことができ、それぞれが文字列で識別されます。希望するバージョンの命名規則を使用することができます。モデルをログすることは、実際にはモデルの 特定のバージョン をログすることです。モデルの追加バージョンをログするには、同じ model_name で異なる version_name を指定して log_model を再度呼び出します。
Tip
SQL で、モデルのバージョンを見るには SHOW VERSIONS IN MODEL を使います。
モデルのバージョンは、 snowflake.ml.model.ModelVersion クラスのインスタンスで表されます。
モデルの全バージョンのリストを取得するには、モデルオブジェクトの versions メソッドを呼び出します。結果は ModelVersion インスタンスのリストです。
代わりに DataFrame として各モデルの情報を取得するには、モデルの show_versions メソッドを呼び出します。
できあがった DataFrame には以下の列が含まれます。
列 |
説明 |
|---|---|
|
モデルバージョンが作成された日時 |
|
バージョンの名前。 |
|
バージョンが格納されているデータベース。 |
|
バージョンが格納されているスキーマ。 |
|
このバージョンが属するモデルの名前。 |
|
このバージョンがモデルのデフォルトバージョンであるかどうかを示すブール値。 |
|
このバージョンで使用可能な関数名の JSON 配列。 |
|
JSON メタデータをキーと値のペアとして含むオブジェクト(メタデータが指定されていない場合は |
|
モデル定義マニフェストの |
モデルバージョンの削除¶
モデルの delete_version メソッドを使用してモデルのバージョンを削除できます。
Tip
ALTER MODEL ... DROP VERSION を使用して、 SQL のモデルバージョンを削除することもできます。
デフォルトバージョン¶
モデルのバージョンをデフォルトモデルとして指定することができます。モデルの default 属性を取得または設定して、現在のデフォルトバージョンを(ModelVersion オブジェクトとして)取得するか、変更(文字列を使用して)します。
Tip
SQL では、 ALTER MODEL を使ってデフォルトのバージョンを設定します。
モデルバージョンのエイリアス¶
SQL ALTER MODEL コマンドを使って、モデルのバージョンにエイリアスを割り当てることができます。PythonやSQLでモデルのバージョンへの参照を取得するときなど、バージョン名が必要な場合はどこでもエイリアスを使うことができます。与えられたエイリアスは、一度に1つのモデル・バージョンにのみ割り当てることができます。
自分で作成したエイリアスに加えて、以下のシステムエイリアスはすべてのモデルで利用可能です。
DEFAULTは、モデルのデフォルトバージョンを指します。FIRSTは、作成時間が最も古いモデルバージョンを指します。LASTは、作成時間が最新のモデルバージョンを指します。
作成したエイリアス名は、システムエイリアスを含め、モデル内の既存のバージョン名やエイリアスと同じにできません。
モデルバージョンへの参照の取得¶
モデルの特定バージョンへの参照を ModelVersion インスタンスとして取得するには、モデルの version メソッドを使用します。モデルのデフォルトバージョンを取得するには、モデルの default 属性を使用します。
モデルの特定バージョン(この例の変数 mv など)への参照を取得すると、そのコメントやメトリクスを取得または更新し、以下のセクションで示すようにモデルのメソッド(または関数)を呼び出すことができます。
コメントの取得および更新¶
モデルと同様に、モデルのバージョンはコメントを持つことができ、モデルのバージョンの comment または description 属性を介してアクセスし、設定することができます。
Tip
ALTER MODEL ... MODIFY VERSION を使って、SQL のモデルバージョンのコメントを変更することもできます。
メトリクスの取得および更新¶
メトリクスは、予測精度やその他のモデルバージョンの特性を追跡するために使用されるキーと値のペアです。モデルバージョンの作成時にメトリクスを設定することも、 set_metric メソッドを使用して設定することもできます。メトリクス値は、数値、文字列、リスト、ディクショナリなど、 JSON にシリアル化できる任意のPythonオブジェクトにすることができます。タグとは異なり、メトリクス名と可能な値を事前に定義する必要はありません。
テスト精度のメトリクスは、sklearnの accuracy_score を使用して生成される場合があります。
混同行列はsklearnを使用して同様に生成できます。
そして、これらの値をメトリクスとして設定することができます:
モデルバージョンのメトリクスをPythonディクショナリとして取得するには、 show_metrics を使用します。
メトリクスを削除するには、 delete_metric を呼び出します。
Tip
また、 ALTER MODEL ... MODIFY VERSION を使用して、 SQL でモデルバージョンのメトリック(メタデータとして格納される)を変更することもできます。
モデル説明の取得¶
モデルレジストリは、 Shapley値 を計算することで、モデルの結果を説明し、どの入力機能が予測に最も寄与しているかを伝えることができます。このプレビュー機能は、Snowflake 8.31以降で作成されたすべてのモデルビューで、基本モデルの explain メソッドを通じてデフォルトで利用できます。Pythonの SQL 、またはモデルビューの run メソッドから explain を呼び出せます。
この機能の詳細については、 モデルの説明可能性 をご参照ください。
モデルバージョンのエクスポート¶
モデルのファイルをローカルディレクトリにエクスポートするには、 mv.export を使用します。ディレクトリが存在しない場合は作成されます。
デフォルトでは、エクスポートされるファイルには、コード、モデルをロードする環境、モデルの重みが含まれます。ウェアハウスでモデルを実行するために必要なファイルもエクスポートするには、 export_mode = ExportMode.FULL を指定します。
モデルバージョンの読み込み¶
mv.load を使って、もともとレジストリに追加されていたオリジナルのPythonモデルオブジェクトを読み込みます。そうすれば、Pythonのコードで定義したのと同じように、推論にそのモデルを使うことができます。
モデルの適切な関数を保証するために、ターゲットのPython環境(すなわち、Pythonインタプリターとすべてのライブラリのバージョン)は、モデルがログに記録された環境と同一でなければなりません。load の呼び出しで force=True を指定すると、環境が異なっていてもモデルを強制的にロードします。
Tip
モデルがホストされている環境と同じであることを確認するために、モデルレジストリからconda環境のコピーをダウンロードします。
そして、このファイルから新しいconda環境を作成します。
オプションの options 引数は、モデルを読み込むためのオプションの辞書です。現在、この引数は use_gpu オプションのみをサポートしています。
オプション |
型 |
説明 |
デフォルト |
|---|---|---|---|
|
|
GPU 固有のロードロジックを有効にします。 |
|
次の例は、 options 引数の使い方を示しています。
モデルメソッドの呼び出し¶
モデルのバージョンは、推論や他のモデル操作を実行するための付属関数である メソッド を持つことができます。モデルのバージョンは異なるメソッドを持つことができ、これらのメソッドの署名も異なる場合があります。
モデルのバージョンのメソッドを呼び出すには、 mv.run を使います。mv は ModelVersion オブジェクトです。呼び出される関数の名前を指定し、推論データを含む Snowpark または pandas DataFrame と必要なパラメーターを渡します。このメソッドは、Snowflakeウェアハウスで実行されます。
メソッドの戻り値は、渡された DataFrame のタイプにマッチする Snowpark または pandas DataFrame です。Snowpark DataFrames は遅延評価されるため、DataFrame の collect、 show、 to_pandas メソッドが呼び出されたときのみメソッドが実行されます。
注釈
メソッドを起動すると、レジストリへの接続に使用しているセッションで指定されたウェアハウスでメソッドが実行されます。ウェアハウスサイズの指定 をご参照ください。
次の例は、モデルの predict メソッドの実行を示しています。このモデルの predict メソッドは、推論データ(ここでは test_features)以外にパラメーターを必要としません。必要な場合は、推論データの後に追加の引数として渡されることになります。
指定されたモデルでどのメソッドが呼び出せるかを確認するには、 mv.show_functions を呼び出します。このメソッドの返り値は、 ModelFunctionInfo オブジェクトのリストです。これらの各オブジェクトには以下の属性が含まれます。
name:Pythonまたは SQL から呼び出せる関数名。target_method:元のログモデルのPythonメソッド名。
Tip
You can also call model methods in SQL. See Inference from SQL.
コストの考慮事項¶
Snowflake モデルレジストリを使用すると、標準的なSnowflake消費ベースのコストが発生します。これらには次が含まれます。
モデルのアーティファクト、メタデータ、および関数を格納するためのコスト。ストレージコストに関する一般情報については、 ストレージコストの調査 をご参照ください。
ステージ間のファイルをSnowflakeにコピーするコスト。COPY FILES をご参照ください。
モデルやモデルのバージョンの表示、モデルのコメント、タグ、メトリクスの変更など、 Snowsight UI や SQL 、Pythonインターフェイスを介したサーバーレスモデルオブジェクト操作のコスト。
ウェアハウスコンピューティングコスト。コストは、モデルの型や学習予測に使用するデータ量によって異なります。Snowflakeのコンピューティングコストに関する一般的な情報については、 コンピューティングコストについて をご参照ください。ウェアハウスのコンピューティングコストは、次のような場合に発生します。
モデルおよびバージョンの作成操作。
モデルのメソッドの呼び出し