문제 해결하기¶

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');
  

  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;

패키지 충돌¶

서비스 컨테이너에 설치되는 패키지는 두 가지 시스템, 즉 모델 자체와 추론 서버에 의해 결정됩니다. 모델의 종속성으로 인한 충돌을 최소화하기 위해 추론 서버에는 다음 패키지만 필요합니다.

• 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``과 같은 이름의 채널과 각 패키지를 지정합니다.

서비스 메모리 부족¶

일부 모델은 스레드에 안전하지 않으므로 Snowflake는 각 작업자 프로세스에 대해 모델의 별도 복사본을 메모리에 로드합니다. 이로 인해 워커의 수가 많은 대규모 모델의 경우 메모리 부족 조건이 발생할 수 있습니다. num_workers 를 줄여보십시오.

서비스 사양 변경 불가¶

모델 빌드 및 추론 서비스의 사양은 ALTER SERVICE``를 사용하여 변경할 수 없습니다. ``TAG, MIN_INSTANCES 등의 특성만 변경할 수 있습니다. 그러나 이미지가 이미지 리포지토리에 게시되어 있으므로 사양을 복사하고 수정한 후 수동으로 시작할 수 있는 새 서비스를 생성할 수 있습니다.

패키지를 찾을 수 없음¶

이미지 빌드 단계에서 모델 배포에 실패했습니다. 모델 빌드 로그에 요청된 패키지를 찾을 수 없다는 메시지가 표시됩니다. (이 단계에서는 패키지가 ``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 패키지와 호환되지 않는 상황이 발생할 수 있습니다. ``conda_dependencies``가 아닌 ``pip_requirements``에 ``torch``를 지정했을 수도 있습니다. 종속성을 ``conda_dependencies 또는 pip_requirements 중 하나에 통합하는 것이 좋습니다. 가능하지 않은 경우 ``conda_dependencies``에서 가장 중요한 패키지를 지정하는 것이 좋습니다.