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

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

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

外部アクセス統合を作成する¶

コンテナのビルドプロセスでは、conda-forge、 PyPI 、またはその他のリポジトリやサイトから依存関係をダウンロードするために、さまざまなインターネットサイトにアクセスする必要があります。これらは、 ACCOUNTADMIN ロールによって外部アクセス統合（EAIs）として設定されなければなりません。

まず、必要なネットワークルールを作成します。conda-forgeへのアクセスは常に必要です。他のパッケージリポジトリへのアクセスが不要な場合は、このルールを作成してください。

CREATE OR REPLACE NETWORK RULE conda_forge_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('conda.anaconda.org:443')

PyPI からパッケージをインストールする必要がある場合は、以下のルールも作成します。 pip を操作するためには、4つ全てのホストが必要です。

CREATE OR REPLACE NETWORK RULE pypi_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('pypi.org:443', 'pypi.python.org:443', 'pythonhosted.org:443',
                  'files.pythonhosted.org:443');

他の多くのサイトへのアクセスが必要な場合は、インターネットへの広範なアクセスを許可するルールを作成することができます。このルールがコンテナーイメージの構築に使用されるロールにのみ適用される限り、セキュリティ・リスクはほとんどありません。

CREATE OR REPLACE NETWORK RULE all_access_rule
    MODE = 'EGRESS'
    TYPE = 'HOST_PORT'
    VALUE_LIST = ('0.0.0.0:443', '0.0.0.0:80')

1つまたは複数のルールを使用して、外部アクセス統合を作成します。以下の例では、先に定義した conda_forge_rule と pypi_rule の両方を使用し、conda-forge と PyPI へのアクセスのみを許可しています。

CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION model_service_build_access
    ALLOWED_NETWORK_RULES = (conda_forge_rule, pypi_rule)
    ENABLED = true;

最後に、コンテナーイメージを構築するロールに EAI 上の USAGE を付与します。

GRANT USAGE ON INTEGRATION model_service_build_access TO ROLE model_users;

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

モデルの依存関係は、それがウェアハウスで実行できるか、 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",
              build_external_access_integration="my_external_access",
              ingress_enabled=True,
              gpu_requests=None)

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

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

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

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

• build_external_access_integration：依存関係をダウンロードする際に使用する外部アクセス統合の名前。この EA は常に conda-forge へのアクセスを許可し、 pip でインストールされた依存関係がある場合は PyPI のホストも含める必要があります。

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

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

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

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

デフォルトでは、 CPU 使用モデルは、 CPUs の2倍に1を加えた数のワーカープロセスを使用します。GPU使用型はワーカープロセスを1つ使います。 num_workers 引数を使用してオーバーライドできます。

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

デフォルトでは、推論サーバーは一度に1つの推論を実行するように最適化され、各ノードのすべての CPU とメモリをフルに活用することを目指します。

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

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

create_service はべき等関数です。複数回呼び出しても、毎回イメージ構築のトリガーにはなりません。しかし、コンテナーイメージは、依存パッケージの脆弱性の修正を含む推論サービスの更新に基づいて再構築される可能性があります。この場合、 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 のモデルのサービス関数を呼び出すには、以下のようなコードを使用します。

SELECT MY_SERVICE_PREDICT(...) FROM ...;

Python¶

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

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 使用推論のためのHugging Face sentence transformerの展開 をご参照ください。

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

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

ALTER SERVICE my_service SUSPEND;

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

モデルの削除¶

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

CPU使用推論のための 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",
    build_external_access_integration="my_egress_access_integration_for_conda_pip",
    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 使用推論のためのHugging Face sentence transformerの展開¶

このコードは、 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,
    build_external_access_integration="my_egress_access_integration_for_conda_pip",
    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")

このモデルはイングレスを有効にしているので、次のように 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 使用推論のための 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 などの属性のみです。

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