Snowpark Container Servicesのモデルサービス¶

コンピューティングプールの作成¶

Snowpark Container Services （SPCS） は、コンピューティングプールでコンテナーイメージを実行します。適切なコンピューティングプールがまだない場合は、以下のようにして作成します。

CREATE COMPUTE POOL IF NOT EXISTS mypool
    MIN_NODES = 2
    MAX_NODES = 4
    INSTANCE_FAMILY = 'CPU_X64_M'
    AUTO_RESUME = TRUE;

有効なインスタンスファミリーの一覧は、 ファミリ名のテーブル をご参照ください。

モデルを実行するロールが、コンピューティングプールのオーナーであるか、あるいは、 USAGE 、あるいは、 OPERATE 、そのプールの権限を持っていることをご確認しださい。

イメージリポジトリの作成¶

Snowflake Model Servingは、モデルとその依存関係を保持するコンテナーイメージを構築します。このイメージを保存するには、イメージリポジトリが必要です。まだお持ちではない場合は、以下のように作成してください。

CREATE IMAGE REPOSITORY IF NOT EXISTS my_inference_images

所有していないイメージ・リポジトリを使用する場合は、コンテナー・イメージを構築するロールがリポジトリ上で READ WRITE 、 SERVICE READ 、 SERVICE 、 WRITE の権限を持っていることを確認してください。これらの権限を以下のように付与します。

GRANT READ ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT WRITE ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT SERVICE READ ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;
GRANT SERVICE WRITE ON IMAGE REPOSITORY my_inference_images TO ROLE myrole;

モデルの依存性と適格性¶

モデルの依存関係は、それがウェアハウスで実行できるか、 SPCS サービスで実行できるか、あるいはその両方で実行できるかを決定します。必要であれば、依存関係を意図的に指定して、モデルをこれらの環境のいずれかで実行できないようにすることができます。

Snowflake の conda チャネルはウェアハウスでのみ利用可能で、ウェアハウスの依存関係の唯一のソースです。デフォルトでは、 SPCS モデルの conda 依存関係は conda-forge から取得します。

モデルのバージョンをログに記録すると、モデルの conda 依存関係が Snowflake の conda チャンネルに対して検証されます。モデルのすべてのconda依存関係がそこで利用可能であれば、そのモデルはウェアハウスで実行する資格があるとみなされます。また、依存関係がすべてconda-forgeから利用可能であれば、 SPCS サービスで実行することもできます。ただし、これはサービスを作成するまで確認されません。

PyPI の依存関係でログに記録されたモデルは、 SPCS で実行する必要があります。少なくとも1つの PyPI 依存関係を指定することは、モデルをウェアハウスで実行する資格がないようにする1つの方法です。モデルにcondaの依存関係しかない場合は、次の例に示すように、少なくとも1つのチャネルを明示的に指定します（conda-forgeでも構いません）。

reg.log_model(
    model_name="my_model",
    version_name="v1",
    model=model,
    conda_dependencies=["conda-forge::scikit-learn"])

SPCS-deployedモデルの場合、condaの依存関係があれば、まずインストールされ、次に PyPI の依存関係があれば、 pip を使ってconda環境にインストールされます。

サービスの作成¶

SPCS サービスを作成し、そこにモデルをデプロイするには、次の例に示すように、モデルバージョンの create_service メソッドを呼び出します。

mv.create_service(service_name="myservice",
                  service_compute_pool="my_compute_pool",
                  image_repo="mydb.myschema.my_image_repo",
                  ingress_enabled=True,
                  gpu_requests=None)

create_service に必要な引数を以下に示します。

• service_name: 作成するサービス名。この名前はアカウント内で一意である必要があります。

• service_compute_pool: モデルの実行に使用するコンピュートプールの名前。コンピューティングプールはすでに存在している必要があります。

• image_repo: コンテナーイメージの保存に使用するイメージリポジトリの名前。レポがすでに存在し、そのユーザーには SERVICE WRITE 権限（または OWNERSHIP）が必要です。

• ingress_enabled: True の場合、サービスは HTTP エンドポイント経由でアクセスできるようになります。エンドポイントを作成するには、 BIND SERVICE ENDPOINT の権限が必要です。

• gpu_requests: GPUs の数を指定する文字列。CPU または GPU のいずれかで実行できるモデルの場合、この引数は、モデルが CPU と GPUs のどちらで実行されるかを決定します。モデルが CPU （例えばscikit-learnモデル）でしか実行できない既知のタイプの場合、 GPUs を要求するとイメージビルドは失敗します。

この例では、必須かつ最もよく使われる引数のみを示しています。引数の完全なリストは ModelVersion API reference をご参照ください。

デフォルトのサービス構成¶

Inference Serverは、ほとんどの大文字と小文字で動作する使いやすいデフォルトを使用しています。そのセットは以下です。

• ワーカースレッド数： CPU-poweredモデルの場合、サーバーは CPUs の2倍＋1個のワーカープロセスを使用します。GPU使用型はワーカープロセスを1つ使います。 create_service の呼び出しでは、 num_workers 引数を使用してオーバーライドできます。

• スレッドセーフティ：スレッドセーフでないモデルもあります。そのため、サービスはワーカープロセスごとにモデルの別個のコピーをロードします。その結果、大規模なモデルではリソースが枯渇する可能性があります。

• ノード利用：デフォルトでは、1つの推論サーバーインスタンスは、実行するノードのすべての CPU とメモリをリクエストすることで、ノード全体をリクエストします。インスタンスごとのリソース割り当てをカスタマイズするには、 cpu_requests、 memory_requests、 gpu_requests のような引数を使用します。

• エンドポイント：推論エンドポイントは inference と名付けられ、ポート5000を使用します。これらはカスタマイズできません。

コンテナイメージのビルド動作¶

デフォルトでは、Snowflake Model Servingは、モデルの実行に使用されるのと同じコンピューティングプールを使用してコンテナーイメージを構築します。この推論コンピューティングプールは、このタスクにはオーバーパワーである可能性が高いです（例えば、 GPUs は、コンテナーイメージの構築には使用されません）。ほとんどの場合、これはコンピューティングコストに大きな影響を与えませんが、気になる場合は、 image_build_compute_pool 引数を指定することでイメージのビルドのためによりパワフルではないコンピューティングプールを選択できます。

create_service はべき等関数です。複数回呼び出しても、毎回イメージ構築のトリガーにはなりません。しかし、コンテナーイメージは、依存パッケージの脆弱性の修正を含む推論サービスの更新に基づいて再構築される可能性があります。この場合、 create_service 、自動的にイメージの再構築がトリガーされます。

SQL¶

Snowflake Model Serving は、モデルを SPCS にデプロイする際にサービス関数を作成します。これらの関数は、 SQL から、 SPCS のコンピューティングプールで実行されているモデルへのブリッジとして機能します。モデルの各メソッドに対して1つのサービス関数が作成され、それらは model_name_method_name のように命名されます。例えば、モデルが PREDICT と EXPLAIN という2つのメソッドを持ち、 MY_SERVICE というサービスにデプロイされる場合、結果として生じるサービス関数は MY_SERVICE_PREDICT と MY_SERVICE_EXPLAIN となります。

SQL のモデルのサービス関数を呼び出すには、以下のようなコードを使用します。

-- See signature of the inference function in SQL.
SHOW FUNCTIONS IN MODEL my_native_xgb_model VERSION ...;

-- Call the inference function in SQL following the same signature (from `arguments` column of the above query)
SELECT MY_SERVICE_PREDICT(feature1, feature2, ...) FROM input_data_table;

Python¶

モデルバージョンオブジェクトの run メソッドを使用して、サービスのメソッドを呼び出します。 service_name 引数を指定して、メソッドが実行されるサービスを指定することを含みます。例:

# Get signature of the inference function in Python
mv.show_functions()
# Call the function in Python
service_prediction = mv.run(
    test_df,
    function_name="predict",
    service_name="my_service")

service_name 引数を含めない場合、モデルはウェアハウスで実行されます。

HTTP エンドポイント¶

イングレスを有効にしてサービスをデプロイすると、サービスを呼び出すための HTTP エンドポイントが作成されます。ShOW ENDPOINTS IN SERVICE コマンドを使ってエンドポイントを見つけることができます。

SHOW ENDPOINTS IN SERVICE my_service;

ingress_url 列に注目すると、 random_str-account-id.snowflakecomputing.app のようになっているはずです。

このエンドポイントの使用方法については、 SPCS チュートリアル Create a Snowpark Container Services service および Developer Guide のトピック Using a service from outside Snowflake をご参照ください。必要なデータ形式の詳細については、 リモートサービスの入力および出力データ形式 をご参照ください。

モデルサービス HTTP エンドポイントの使用例については GPU-powered推論のためのHugging Face文型変換器の展開 をご参照ください。

サービスを一時停止します。¶

あるモデルを使い終わったら、あるいは利用がなければ、コストを節約するためにサービスを停止するのがよい方法です。ALTER SERVICE コマンドを使用してこれを実行できます。

ALTER SERVICE my_service SUSPEND;

サービスは、スケジューリングと起動の遅延に従いますが、リクエストを受け取ると自動的に再起動します。スケジューリングの遅延はコンピュートプールの可用性に依存し、起動の遅延はモデルのサイズに依存します。

モデルの削除¶

モデルやモデルのバージョンは、 SQL インターフェイスや Python API を使って通常通り管理することができますが、サービスによって（実行中であれ中断中であれ）使われているモデルやモデルのバージョンはドロップ（削除）することができません。モデルまたはモデルのバージョンを削除するには、まずサービスを削除します。

CPU-powered推論のための XGBoost モデルの展開¶

THe 次のコードは、 SPCS で推論のために XGBoost モデルをデプロイし、デプロイされたモデルを推論に使用する主な手順を示しています。この例のノートブック は使用可能です 。

from snowflake.ml.registry import registry
from snowflake.ml.utils.connection_params import SnowflakeLoginOptions
from snowflake.snowpark import Session
from snowflake.ml.modeling.xgboost import XGBRegressor

# your model training code here output of which is a trained xgb_model

# Open model registry
reg = registry.Registry(session=session, database_name='my_registry_db', schema_name='my_registry_schema')

# Log the model in Snowflake Model Registry
model_ref = reg.log_model(
    model_name="my_xgb_forecasting_model",
    version_name="v1",
    model=xgb_model,
    conda_dependencies=["scikit-learn","xgboost"],
    sample_input_data=train,
    comment="XGBoost model for forecasting customer demand"
)

# Deploy the model to SPCS
reg_model.create_service(
    service_name="ForecastModelServicev1",
    service_compute_pool="my_cpu_pool",
    image_repo="my_db.data.my_images",
    ingress_enabled=True)

# See all services running a model
reg_model.list_services()

# Run on SPCS
reg_model.run(input_data, function_name="predict", service_name="ForecastModelServicev1")

# Delete the service
reg_model.delete_service("ForecastModelServicev1")

GPU-powered推論のためのHugging Face文型変換器の展開¶

このコードは、 HTTP エンドポイントを含む、Hugging Face sentence transformerをトレーニングし、配備します。

from snowflake.ml.registry import registry
from snowflake.ml.utils.connection_params import SnowflakeLoginOptions
from snowflake.snowpark import Session
from sentence_transformers import SentenceTransformer

session = Session.builder.configs(SnowflakeLoginOptions("connection_name")).create()
reg = registry.Registry(session=session, database_name='my_registry_db', schema_name='my_registry_schema')

# Take an example sentence transformer from HF
embed_model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2')

# Have some sample input data
input_data = [
    "This is the first sentence.",
    "Here's another sentence for testing.",
    "The quick brown fox jumps over the lazy dog.",
    "I love coding and programming.",
    "Machine learning is an exciting field.",
    "Python is a popular programming language.",
    "I enjoy working with data.",
    "Deep learning models are powerful.",
    "Natural language processing is fascinating.",
    "I want to improve my NLP skills.",
]

# Log the model with pip dependencies
pip_model = reg.log_model(
    embed_model,
    model_name="sentence_transformer_minilm",
    version_name='pip',
    sample_input_data=input_data,  # Needed for determining signature of the model
pip_requirements=["sentence-transformers", "torch", "transformers"], # If you want to run this model in the Warehouse, you can use conda_dependencies instead
)

# Force Snowflake to not try to check warehouse
conda_forge_model = reg.log_model(
    embed_model,
    model_name="sentence_transformer_minilm",
    version_name='conda_forge_force',
    sample_input_data=input_data,
    # setting any package from conda-forge is sufficient to know that it can't be run in warehouse
    conda_dependencies=["sentence-transformers", "conda-forge::pytorch", "transformers"]
)

# Deploy the model to SPCS
pip_model.create_service(
    service_name="my_minilm_service",
    service_compute_pool="my_gpu_pool",  # Using GPU_NV_S - smallest GPU node that can run the model
    image_repo="my_db.data.my_images",
    ingress_enabled=True,
    gpu_requests="1", # Model fits in GPU memory; only needed for GPU pool
    max_instances=4, # 4 instances were able to run 10M inferences from an XS warehouse
)

# See all services running a model
pip_model.list_services()

# Run on SPCS
pip_model.run(input_data, function_name="encode", service_name="my_minilm_service")

# Delete the service
pip_model.delete_service("my_minilm_service")

SQL では、次のようにサービス関数を呼び出すことができます：

SELECT my_minilm_service_encode('This is a test sentence.');

このモデルはイングレスを有効にしているので、次のように HTTP エンドポイントを呼び出すことができます。

import json
from pprint import pprint
import requests
import snowflake.connector

# Generate right header
# Note that, ideally user should use key-pair authentication for API access (see this).
def initiate_snowflake_connection():
    connection_parameters = SnowflakeLoginOptions("connection_name")
    connection_parameters["session_parameters"] = {"PYTHON_CONNECTOR_QUERY_RESULT_FORMAT": "json"}
    snowflake_conn = snowflake.connector.connect(**connection_parameters)
    return snowflake_conn

def get_headers(snowflake_conn):
    token = snowflake_conn._rest._token_request('ISSUE')
    headers = {'Authorization': f'Snowflake Token=\"{token["data"]["sessionToken"]}\"'}
    return headers

headers = get_headers(initiate_snowflake_connection())

# Put the endpoint url with method name
URL='https://<random_str>-<account>.snowflakecomputing.app/encode'

# Prepare data to be sent
data = {
    'data': []
}
for idx, x in enumerate(input_data):
    data['data'].append([idx, x])

# Send over HTTP
def send_request(data: dict):
    output = requests.post(URL, json=data, headers=headers)
    assert (output.status_code == 200), f"Failed to get response from the service. Status code: {output.status_code}"
    return output.content

# Test
results = send_request(data=data)
pprint(json.loads(results))

GPU-powered推論のための PyTorch モデルの展開¶

PyTorch ディープラーニング推奨モデル（DLRM）を GPU 推論のために SPCS にトレーニングしてデプロイする例については、 次のクイックスタート をご参照ください。

SPCS 展開の監視¶

次の SQL クエリを使用して起動中のサービスを検査することで、デプロイメントを監視できます。

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

2つのジョブが開始されます。

• MODEL_BUILD_xxxxx：名前の衝突を避けるため、名前の最後の文字はランダム化されます。このジョブはイメージを構築し、イメージが構築された後に終了します。イメージがすでに存在する場合は、ジョブはスキップされます。

  ログは、パッケージの依存関係の衝突などの問題をデバッグするのに便利です。このジョブのログを見るには、最後の文字が同じになるようにしたうえで以下の SQL を起動します。

  CALL SYSTEM$GET_SERVICE_LOGS('MODEL_BUILD_xxxxx', 0, 'model-build');
  

  Copy

• MYSERVICE: create_service へのコールで指定されたサービス名。このジョブは、 MODEL_BUILD のジョブが成功またはスキップされた場合に開始されます。このジョブのログを見るには、以下の SQL を起動します。

  CALL SYSTEM$GET_SERVICE_LOGS('MYSERVICE', 0, 'model-inference');
  

  Copy

パッケージの競合¶

サービスコンテナーにインストールされるパッケージは、モデル本体と推論サーバーの2つのシステムによって決定されます。モデルの依存関係との衝突を最小限にするために、推論サーバーは以下のパッケージのみを必要とします。

• gunicorn<24.0.0

• starlette<1.0.0

• uvicorn-standard<1.0.0

モデルの依存関係が、上記と同様に、 pip または conda のどちらかによって解決可能であることを確認してください。

モデルに conda_dependencies と pip_requirements の両方が設定されている場合、これらはcondaを介して以下のようにインストールされます。

チャネル

• conda-forge

• ノードデフォルト

依存関係

• all_conda_packages

• pip:

  • all_pip_packages

デフォルトでは、Snowflake は Anaconda パッケージのために conda-forge を使用します。これは、Snowflake の conda チャンネルがウェアハウスで利用可能であり、 defaults チャンネルはユーザーが Anaconda の利用規約に同意する必要があるためです。デフォルトチャンネルからパッケージを指定するには、このパッケージ名を含めます： defaults::pkg_name

メモリ不足のサービス¶

モデルの中にはスレッドセーフでないものもあるため、Snowflakeはワーカープロセスごとにモデルのコピーをメモリにロードします。これは、ワーカー数の多い大規模なモデルでは、メモリ不足を引き起こす可能性があります。 num_workers の削減を試します。

不満足のクエリパフォーマンス¶

通常、推論は推論サービスのインスタンス数がボトルネックになります。モデルのデプロイ時に、 max_instances に高い値を渡してみてください。

サービス仕様を変更できない¶

モデル構築および推論サービスの仕様は、 ALTER SERVICE を使用して変更することはできません。変更できるのは、 TAG 、 MIN_INSTANCES などの属性のみです。

しかし、イメージはイメージ・レポで公開されているので、スペックをコピーして修正し、そこから新しいサービスを作成して手動で起動することができます。