Solução de problemas¶

Monitoramento das implementações SPCS¶

É possível monitorar a implementação inspecionando os serviços que estão sendo iniciados usando a seguinte consulta SQL.

SHOW SERVICES IN COMPUTE POOL my_compute_pool;

Dois trabalhos são lançados:

• MODEL_BUILD_xxxxx: os caracteres finais do nome são inseridos aleatoriamente para evitar conflitos de nomes. Este trabalho cria a imagem e termina depois que ela é criada. Se uma imagem já existir, o trabalho será ignorado.

  Os logs são úteis para a depuração de problemas, como conflitos nas dependências de pacotes. Para ver os logs deste trabalho, execute o SQL abaixo, certificando-se de usar os mesmos caracteres finais:

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

  Copy

• MYSERVICE: o nome do serviço conforme especificado na chamada para create_service. Este trabalho é iniciado se o trabalho de MODEL_BUILD for bem-sucedido ou ignorado. Para ver os logs deste trabalho, execute o SQL abaixo:

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

  Copy

Se os logs não estiverem disponíveis com SYSTEM$GET_SERVICE_LOG porque o trabalho ou serviço de compilação foi excluído, você poderá consultar a tabela de eventos (se habilitada) para ver os logs:

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;

Conflitos de pacotes¶

Dois sistemas determinam os pacotes instalados no contêiner de serviço: o próprio modelo e o servidor de inferência. Para minimizar os conflitos com as dependências do seu modelo, o servidor de inferência requer apenas os seguintes pacotes:

• gunicorn<24.0.0

• starlette<1.0.0

• uvicorn-standard<1.0.0

Certifique-se de que as dependências do modelo, junto com as dependências acima, possam ser resolvidas por pip ou conda, qualquer um que você use.

Se um modelo tiver conda_dependencies e pip_requirements definidos, eles serão instalados da seguinte forma via conda:

• Canais:

  • conda-forge

  • nodefaults

• Dependências:

  • all_conda_packages

  • pip:

    • all_pip_packages

O Snowflake obtém os pacotes do Anaconda do conda-forge ao criar imagens de contêiner porque o canal conda do Snowflake está disponível apenas em warehouses, e o canal defaults exige que os usuários aceitem os termos de uso do Anaconda, o que não é possível durante a criação automatizada. Para obter pacotes de um canal diferente, como defaults, especifique cada pacote com o nome do canal, conforme mostrado em defaults::pkg_name.

Serviço sem memória¶

Alguns modelos não são thread-safe, portanto o Snowflake carrega uma cópia do modelo separada na memória para cada processo de trabalho. Isso pode causar condições de falta de memória para modelos grandes com um número maior de trabalhadores. Tente reduzir num_workers.

Não é possível alterar a especificação do serviço¶

As especificações da compilação do modelo e dos serviços de inferência não podem ser alteradas usando ALTER SERVICE. Somente é possível alterar atributos como TAG, MIN_INSTANCES e assim por diante. No entanto, como a imagem é publicada no repositório de imagens, você pode copiar a especificação, modificá-la e criar um novo serviço a partir dela, que pode ser iniciado manualmente.

Pacote não encontrado¶

A implantação do modelo falhou durante a fase de criação da imagem. Os logs de compilação do modelo sugerem que um pacote solicitado não foi encontrado. (Por padrão, esta etapa usará o conda-forge se o pacote for mencionado em conda_dependencies.)

A instalação do pacote pode falhar por qualquer um dos seguintes motivos:

• O nome ou a versão do pacote é inválido. Verifique a ortografia e a versão do pacote.

• A versão solicitada do pacote não existe no conda-forge. Você pode tentar remover a especificação da versão para obter a versão mais recente disponível no conda-forge ou usar pip_requirements em vez disso. É possível navegar por todos os pacotes disponíveis aqui.

• Em alguns casos, você pode precisar de um pacote de um canal especial (por exemplo, pytorch). Adicione um prefixo channel_name:: à dependência, como pytorch::torch.

Incompatibilidade de versão do Huggingface Hub¶

Um serviço de inferência de modelo Hugging Face pode falhar com a mensagem de erro:

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

Isso ocorre porque o pacote transformers não especifica as dependências corretas do huggingface-hub, mas as verifica no código. Para resolver esse problema, registre o modelo novamente, dessa vez especificando explicitamente a versão necessária do huggingface-hub em conda_dependencies ou pip_requirements.

Torch não compilado com CUDA ativado¶

A causa mais comum desse erro é que você especificou ambos conda_dependencies e pip_requirements. Conforme mencionado na seção de conflitos de pacotes, conda é o gerenciador de pacotes usado para criar a imagem de contêiner. O Anaconda não resolve pacotes juntos de conda_dependencies e pip_requirements e dá precedência aos pacotes conda. Isso pode levar a uma situação em que os pacotes conda não sejam compatíveis com os pacotes pip. Você pode ter especificado torch em pip_requirements, e não em conda_dependencies. Considere consolidar as dependências em conda_dependencies ou em pip_requirements. Se isso não for possível, prefira especificar os pacotes mais importantes em conda_dependencies.