故障排除¶

本指南介绍如何在 Snowpark Container Services (SPCS) 中监控部署并解决与包依赖项、内存和环境配置相关的常见问题。

监控 SPCS 部署¶

您可以使用以下 SQL 查询检查正在启动的服务，从而监控部署情况。

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

启动两项作业：

MODEL_BUILD_xxxxx：此作业会构建镜像，并在镜像构建完成后结束。此作业会构建镜像，并在镜像构建完成后结束。如果镜像已经存在，则跳过该作业。

日志对于调试包依赖项冲突等问题非常有用。要查看此作业的日志，请运行下面的 SQL，确保使用相同的最后字符：
```
CALL SYSTEM$GET_SERVICE_LOGS('MODEL_BUILD_xxxxx', 0, 'model-build');
```
MYSERVICE：如果 create_service 作业成功或被跳过，则启动此作业。如果 MODEL_BUILD 作业成功或被跳过，则启动此作业。要查看此作业的日志，请运行下面的 SQL：
```
CALL SYSTEM$GET_SERVICE_LOGS('MYSERVICE', 0, 'model-inference');
```

如果 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;

包冲突¶

有两个系统决定了安装在服务容器中的包：模型本身和推理服务器。为了减少与模型依赖项的冲突，推理服务器只需要以下包：

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，则即使这两组依赖项不兼容，容器镜像也会成功构建，这可能会导致生成的容器映像无法按预期工作。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

这是因为该 transformers 包没有指定正确的 huggingface-hub 依赖关系，而是检查代码。要解决此问题，请再次记录模型，这次是在 conda_dependencies 或 pip_requirements 中显式指定所需的 huggingface-hub 版本。

CUDA 启用后未编译 Torch¶

此错误的典型原因是您同时指定了 conda_dependencies 和 pip_requirements。如包冲突部分所述，conda 是用于构建容器镜像的包管理器。Anaconda 不会同时解析来自 conda_dependencies 和 pip_requirements 的包，而是优先解析 conda 包。这可能会导致 conda 包与 pip 包不兼容。您可能是在 torch 而非 pip_requirements 中指定的 conda_dependencies。考虑将依赖项合并为 conda_dependencies 或 pip_requirements。如果不可能，则最好在 conda_dependencies 中指定最重要的包。