トラブルシューティング¶

このガイドでは、Snowpark Container Services（ SPCS ）でデプロイメントを監視し、パッケージの依存関係、メモリ、環境構成に関連する一般的な問題を解決する方法を説明します。

SPCS 展開の監視¶

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

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

Copy

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

構築ジョブまたはサービスが削除されたためにログが SYSTEM$GET_SERVICE_LOG を介して利用できない場合、イベントテーブル（有効化されている場合）をチェックして、ログを確認できます。

SELECT RESOURCE_ATTRIBUTES, VALUE
FROM <EVENT_TABLE_NAME>
WHERE true
    AND timestamp > dateadd(day, -1, current_timestamp())  -- choose appropriate timestamp range
    AND RESOURCE_ATTRIBUTES:"snow.database.name" = '<db of the service>'
    AND RESOURCE_ATTRIBUTES:"snow.schema.name" = '<schema of the service>'
    AND RESOURCE_ATTRIBUTES:"snow.service.name" = '<Job or Service name>'
    AND RESOURCE_ATTRIBUTES:"snow.service.container.instance" = '0'  -- choose all instances or one particular
    AND RESOURCE_ATTRIBUTES:"snow.service.container.name" != 'snowflake-ingress' --skip logs from internal sidecar
ORDER BY timestamp ASC;

Copy

パッケージの競合¶

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

gunicorn<24.0.0
starlette<1.0.0
uvicorn-standard<1.0.0

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

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

チャンネル
- conda-forge
- nodefaults
**依存関係: **
- all_conda_packages
- pip:
  - all_pip_packages

Snowflakeは、コンテナイメージをビルドするときにconda-forgeからAnacaondaパッケージを取得します。これは、Snowflakeのcondaチャネルはウェアハウスでのみ利用可能であり、デフォルトチャネルでは、ユーザーがAnacondaの利用規約に同意する必要がありますが、自動ビルド中に同意できないためです。デフォルトなど、別のチャネルからパッケージを取得するには、 defaults::pkg_name のようにチャネル名で各パッケージを指定します。

注釈

conda_dependencies と pip_requirements の両方を指定すると、2つの依存関係セットに互換性がない場合でもコンテナーイメージは正常にビルドされますが、結果のコンテナーイメージが期待どおりに動作しない可能性があります。Snowflakeでは、 conda_dependencies のみ、または pip_requirements のみを使用することを推奨しており、両方を使用することは推奨しません。

メモリ不足のサービス¶

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

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

モデル構築および推論サービスの仕様は、 ALTER SERVICE を使用して変更することはできません。変更できるのは、 TAG 、 MIN_INSTANCES などの属性のみです。しかし、イメージはイメージ・レポで公開されているので、スペックをコピーして修正し、そこから新しいサービスを作成して手動で起動することができます。

パッケージが見つかりません¶

イメージ構築フェーズ中にモデルの展開に失敗しました。Model-buildログは、リクエストされたパッケージが見つからなかったことを示しています。（パッケージが conda_dependencies で言及されている場合、このステップはデフォルトでconda-forgeを使用します。）

パッケージのインストールは以下のような理由で失敗することがあります。

パッケージ名またはバージョンが無効です。パッケージのスペルとバージョンを確認してください。
パッケージのリクエストされたバージョンがconda-forgeに存在しません。conda-forgeで利用可能な最新バージョンを取得するには、バージョン仕様の削除を試みるか、代わりに pip_requirements を使用してください。ここで利用可能なすべてのパッケージを閲覧できます。
場合によっては、特別なチャネル（例: pytorch）からのパッケージが必要になる場合があります。依存関係に channel_name:: プレフィックスを追加します（例: pytorch::torch ）

Huggingface Hubのバージョン不一致¶

Hugging Faceモデル推論サービスがエラーメッセージで失敗することがあります。

ImportError: huggingface-hub>=0.30.0,<1.0 is required for a normal functioning of this module, but found huggingface-hub==0.25.2

Copy

これは、 transformers パッケージが、 huggingface-hub への正しい依存関係を指定せず、代わりにコードでチェックするためです。この問題を解決するには、モデルを再度ログに記録し、今度は conda_dependencies または pip_requirements で huggingface-hub の必要なバージョンを明示的に指定します。

torchが CUDA を有効にしてコンパイルされていません¶

このエラーの一般的な原因は、 conda_dependencies および pip_requirements 両方を指定していることです。パッケージの競合セクションで述べたように、condaはコンテナイメージのビルドに使用されるパッケージマネージャーです。Anacondaは conda_dependencies および pip_requirements からのパッケージを一緒に解決せず、condaパッケージに優先順位を与えます。これにより、condaパッケージがpipパッケージと互換性のない状況が発生する可能性があります。conda_dependencies ではなく、 pip_requirements で torch を指定した可能性があります。依存関係を conda_dependencies または pip_requirements いずれかに統合することを検討してください。それが不可能な場合は、 conda_dependencies で最も重要なパッケージを指定することをお勧めします。