Function Compute:Perguntas frequentes sobre instâncias aceleradas por GPU

Quais são as versões do driver e do CUDA para instâncias aceleradas por GPU do Function Compute?

Resumo: O Function Compute atualmente executa a versão do driver 580.95.05 (driver de modo de usuário do CUDA 13.0). Para que a plataforma gerencie o restante, use o CUDA Toolkit 11.8 ou posterior na sua imagem.

As instâncias aceleradas por GPU possuem duas camadas de versão distintas:

Gerenciado pela plataforma (não é possível alterar):

• Versão do driver — o driver de modo kernel (nvidia.ko) e o driver de modo de usuário do CUDA (libcuda.so). A plataforma injeta esses componentes em cada contêiner durante a criação da instância. Não os inclua na sua imagem.

Gerenciado por você:

• Versão do CUDA Toolkit — CUDA Runtime, cuDNN e cuFFT. Ao criar a imagem do seu contêiner, especifique a versão do CUDA Toolkit. Para melhor compatibilidade, use o CUDA Toolkit 11.8 ou posterior, mas não superior à versão do driver de modo de usuário do CUDA (13.0) fornecida pela plataforma.

A versão do driver pode mudar devido a atualizações de recursos, novos modelos de placas de GPU, correções de bugs ou fim do ciclo de vida do driver. Para a matriz completa de compatibilidade de versões, consulte as Notas de versão do CUDA Toolkit.

O que fazer se eu encontrar um CUFFT_INTERNAL_ERROR durante a execução?

Causa: A biblioteca cuFFT no CUDA 11.7 tem um problema conhecido de compatibilidade com versões futuras que causa esse erro em modelos mais recentes de placas de GPU.

Solução: Atualize para o CUDA 11.8 ou posterior.

Após atualizar, verifique a correção com este trecho de código PyTorch:

import torch
out = torch.fft.rfft(torch.randn(1000).cuda())

Se não houver erro, a atualização foi bem-sucedida. Para os modelos de placas de GPU suportados, consulte Instance types and specifications.

Como resolver um erro GPG do CUDA que ocorre ao criar uma imagem?

Erro:

W: GPG error: https://developer.download.nvidia.cn/compute/cuda/repos/ubuntu2004/x86_64  InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A4B469963BF863CC
E: The repository 'https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64  InRelease' is not signed.

Causa: A chave pública do repositório NVIDIA CUDA está ausente no seu ambiente de compilação.

Solução: Adicione a seguinte linha após o comando RUN rm no seu Dockerfile e, em seguida, recrie a imagem:

RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A4B469963BF863CC

Por que o meu tipo de instância acelerada por GPU é exibido como g1?

g1 é um alias para fc.gpu.tesla.1. Ambos são equivalentes. Para a lista completa de tipos de instâncias e suas especificações, consulte Instance types and specifications.

Por que a minha instância falha ao iniciar?

Existem duas causas comuns:

Tempo limite de inicialização

• Código de erro: FunctionNotStarted

• Mensagem de erro: Function instance health check failed on port XXX in 120 seconds

• Causa: O aplicativo demora muito para iniciar — geralmente porque carrega um modelo grande (mais de 10 GB) da rede pública antes de o servidor web estar pronto.

• Solução: Inicie o servidor web primeiro e, em seguida, carregue os modelos em segundo plano ou no método /initialize. Evite bloquear a inicialização do servidor; baixe arquivos grandes da rede pública em segundo plano.

Cota excedida

• Código de erro: ResourceThrottled

• Mensagem de erro: Reserve resource exceeded limit

• Causa: A cota padrão é de 30 GPUs físicas por região e por conta da Alibaba Cloud.

• Solução: Verifique sua cota atual no Quota Center. Para solicitar um aumento, envie uma solicitação no Quota Center.

O que fazer se instâncias elásticas de GPU não puderem ser criadas e um erro "ResourceExhausted" ou "ResourceThrottled" for relatado?

Causa: Os recursos de GPU são compartilhados e sujeitos a flutuações no pool. Quando a demanda aumenta abruptamente, as instâncias elásticas de GPU podem não ser provisionadas a tempo de atender às solicitações de invocação.

Solução: Configure um número mínimo de instâncias para sua função. Isso reserva recursos de GPU com antecedência, em vez de esperar pelo provisionamento sob demanda. Para obter instruções de configuração, consulte Configure an elastic policy with a minimum number of instances.

Qual é o limite de tamanho para uma imagem de GPU?

O limite de tamanho aplica-se à imagem compactada. Imagens com menos de 20 GB antes da compactação normalmente podem ser implantadas no Function Compute.

Para verificar o tamanho das imagens:

• Tamanho compactado: Visualize no console do Container Registry.

• Tamanho não compactado: Para verificar, execute docker images localmente.

O que fazer se a aceleração de imagem de GPU falhar?

Causa: À medida que o tamanho da imagem aumenta, o processo de conversão de imagem acelerada demora mais e pode esgotar o tempo limite.

Solução: Para reacionar a conversão, abra o console do Function Compute, edite a configuração da função e salve — não é necessário alterar nenhum parâmetro.

O modelo deve ser empacotado na imagem ou separado dela?

Separe o modelo da imagem nos seguintes casos:

• O arquivo do modelo é grande.

• O modelo é atualizado com frequência.

• Incluir o modelo faria a imagem exceder o limite de tamanho da plataforma.

Ao separá-lo, armazene o modelo em um sistema de arquivos do File Storage NAS (NAS) ou Object Storage Service (OSS). Para obter orientações detalhadas, consulte Best practices for model storage in GPU-accelerated instances.

Como fazer o aquecimento do modelo e quais são as práticas recomendadas?

Insira a lógica de inicialização do modelo no método /initialize. O Function Compute retém todo o tráfego de entrada até que o método /initialize seja concluído, portanto, a instância só começa a atender às solicitações de produção depois que o modelo estiver totalmente carregado.

Para mais detalhes, consulte:

• Configure the instance lifecycle

• Exemplo de código de aquecimento de modelo

O que fazer se uma imagem de GPU falhar ao iniciar e relatar "FunctionNotStarted: Function Instance health check failed on port xxx in 120 seconds"?

Causa: O servidor web demora muito para iniciar — geralmente porque o aplicativo carrega um modelo grande antes de o servidor estar pronto para aceitar conexões.

Solução:

• Não carregue modelos da rede pública durante a inicialização. Armazene os modelos dentro da imagem ou em um sistema de arquivos NAS para um acesso mais rápido.

• Mova a inicialização do modelo para o método /initialize. Isso permite que o servidor web seja iniciado primeiro e passe na verificação de integridade, enquanto o modelo é carregado em segundo plano.

Minha função apresenta latência de ponta a ponta alta e flutuante. Como resolver?

A alta latência em funções de GPU geralmente provém de duas fontes: tempo de espera de recursos e tempo de inicialização. Identificar a causa exata ajuda a aplicar a correção certa.

A latência ocorre antes do início do processamento da invocação (espera de recursos)?

Se as invocações passarem muito tempo em um estado pendente esperando que um contêiner de GPU fique disponível, o problema é a disponibilidade de recursos, não a velocidade de inicialização. Solução: configure um número mínimo de instâncias para manter os contêineres aquecidos. Consulte Configure an elastic policy with a minimum number of instances.

A latência está concentrada na primeira invocação em uma nova instância (inicialização)?

Se algumas invocações forem muito mais lentas que outras e essas invocações forem sempre as primeiras em um contêiner recém-iniciado, o problema é o tempo de inicialização. Verifique o seguinte:

1. Confirme se a aceleração de imagem está ativa. No console do Function Compute, verifique se o status de aceleração de imagem exibe Available. Caso contrário, reacione a conversão editando e salvando a configuração da função — não é necessário alterar nenhum parâmetro.

2. Verifique o tipo do seu sistema de arquivos NAS. Se a sua função ler um modelo do NAS, use um sistema de arquivos NAS de uso geral otimizado para computação. Sistemas de arquivos otimizados para armazenamento têm menor throughput e tornam o carregamento do modelo mais lento. Para obter detalhes, consulte General-purpose NAS file system.

3. **Mova o carregamento do modelo para /initialize.** A instância não é considerada aquecida até que o /initialize seja concluído, portanto, nenhum tráfego é direcionado para ela durante o carregamento do modelo. Isso elimina a latência de carregamento do modelo das solicitações de produção.

O que fazer se o driver NVIDIA não puder ser encontrado?

Causa: Você criou a imagem do seu contêiner usando docker run --gpus all seguido por docker commit. Isso captura o estado do driver NVIDIA local na imagem, o que entra em conflito com o driver que a plataforma do Function Compute injeta em tempo de execução.

Solução: use sempre um Dockerfile para criar a imagem do seu aplicativo. Consulte Dockerfile para referência.

Além disso, mantenha sua imagem livre de componentes específicos do driver:

• Não inclua libcuda.so na imagem. Essa biblioteca está fortemente acoplada à versão do driver do kernel do host. Se ela não corresponder ao que a plataforma fornece, seu aplicativo pode se comportar de maneira inesperada.

• Não torne seu aplicativo dependente de uma versão específica do driver.

Quando uma instância da função é iniciada, a plataforma do Function Compute injeta automaticamente os componentes corretos do driver de modo de usuário no contêiner. Esse é o mesmo mecanismo usado por tecnologias de virtualização de contêineres de GPU como o NVIDIA Container Runtime — ele mantém o gerenciamento do driver na plataforma para que sua imagem permaneça portátil, independente das atualizações de driver.

Se você já usa o NVIDIA Container Runtime ou uma tecnologia semelhante, evite docker commit. As imagens criadas dessa forma contêm componentes de driver injetados que podem apresentar incompatibilidade de versão com o que a plataforma do Function Compute fornece, causando comportamento indefinido.