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

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

Resumo: O Function Compute usa atualmente o driver versão 580.95.05 (driver de modo de usuário CUDA 13,0). Use o CUDA Toolkit 11,8 ou superior na imagem; a plataforma gerencia o restante.

As instâncias aceleradas por GPU têm duas camadas de versão distintas:

Gerenciado pela plataforma (não modificável):

• Versão do driver: driver de modo kernel (nvidia.ko) e driver de modo de usuário CUDA (libcuda.so). A plataforma injeta esses componentes em cada container ao criar a instância. Não os inclua na imagem.

Gerenciado por você:

• Versão do CUDA Toolkit: CUDA Runtime, cuDNN e cuFFT. Especifique a versão do CUDA Toolkit ao criar a imagem do container. Para melhor compatibilidade, use o CUDA Toolkit 11,8 ou superior, sem exceder a versão do driver de modo de usuário CUDA (13,0) fornecida pela plataforma.

A versão do driver pode mudar devido a atualizações de recursos, novos modelos de placas 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 lançamento do CUDA Toolkit.

Como proceder ao encontrar um CUFFT_INTERNAL_ERROR durante a execução?

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

Solução: Atualize para o CUDA 11,8 ou superior.

Após a atualização, verifique a correção com este trecho PyTorch:

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

Se nenhum erro for relatado, a atualização foi bem-sucedida. Para modelos de placas GPU suportados, consulte Tipos e especificações de instância.

Como resolver um erro GPG do CUDA 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 ambiente de build.

Solução: Adicione a linha abaixo após o comando RUN rm no Dockerfile e reconstrua a imagem:

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

Por que o tipo da minha instância acelerada por GPU aparece como g1?

g1 é um alias para fc.gpu.tesla.1. Ambos são equivalentes. Para a lista completa de tipos de instância e especificações, consulte Tipos e especificações de instância.

Por que minha instância não inicia?

Há 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 ficar pronto.

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

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 por conta Alibaba Cloud.

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

Como agir se não for possível criar instâncias GPU elásticas e ocorrer o erro "ResourceExhausted" ou "ResourceThrottled"?

Causa: Os recursos de GPU são compartilhados e sujeitos a flutuações no pool. Quando a demanda aumenta abruptamente, as instâncias GPU elásticas 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 a função. Isso reserva recursos de GPU antecipadamente, evitando a espera pelo provisionamento sob demanda. Para instruções de configuração, consulte Configurar uma política elástica com número mínimo de instâncias.

Qual é o limite de tamanho de uma imagem GPU?

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

Para verificar os tamanhos da imagem:

• Tamanho compactado: Visualize no console do Container Registry.

• Tamanho descompactado: Execute docker images localmente.

Como proceder se a aceleração da imagem GPU falhar?

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

Solução: Para reativar a conversão, abra o console do Function Compute, edite a configuração da função e salve. Nenhuma alteração de parâmetro é necessária.

Devo empacotar o modelo na imagem ou mantê-lo separado?

Separe o modelo da imagem se alguma das condições a seguir se aplicar:

• O arquivo do modelo é grande.

• O modelo é atualizado frequentemente.

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

Ao separar, armazene o modelo em um sistema de arquivos File Storage NAS (NAS) ou Object Storage Service (OSS). Para orientações detalhadas, consulte Práticas recomendadas para armazenamento de modelos em instâncias aceleradas por GPU.

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 recebido até a conclusão do método /initialize, então a instância só começa a atender solicitações de produção após o carregamento total do modelo.

Para mais detalhes, consulte:

• Configurar o ciclo de vida da instância

• Exemplo de código de aquecimento de modelo

Como proceder se uma imagem GPU falhar ao iniciar com o erro "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 na inicialização. Coloque os modelos na imagem ou em um sistema de arquivos NAS para acesso mais rápido.

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

Minha função apresenta latência ponta a ponta alta e instável. Como resolver?

A alta latência em funções GPU geralmente vem de duas fontes: tempo de espera por recursos e tempo de inicialização. Diagnosticar a causa correta ajuda a aplicar a solução adequada.

A latência ocorre antes do início do trabalho de invocação (espera por recurso)?

Se as invocações passam muito tempo em estado pendente esperando um container GPU ficar disponível, o problema é disponibilidade de recursos, não velocidade de inicialização. Solução: configure um número mínimo de instâncias para manter containers aquecidos prontos. Consulte Configurar uma política elástica com número mínimo de instâncias.

A latência concentra-se na primeira invocação em uma nova instância (inicialização)?

Se algumas invocações são muito mais lentas que outras e ocorrem sempre na primeira vez em um container 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 da imagem mostra Available. Caso contrário, reative a conversão editando e salvando a configuração da função. Nenhuma alteração de parâmetro é necessária.

2. Verifique o tipo do sistema de arquivos NAS. Se a função lê um modelo do NAS, use um sistema de arquivos NAS de uso geral otimizado para computação. Sistemas otimizados para armazenamento têm menor throughput e tornam o carregamento do modelo mais lento. Para detalhes, consulte Sistema de arquivos NAS de uso geral.

3. **Mova o carregamento do modelo para /initialize.** A instância só é considerada aquecida após a conclusão de /initialize, portanto, nenhum tráfego é roteado para ela durante o carregamento do modelo. Isso elimina a latência de carregamento do modelo das solicitações de produção.

Como proceder se o driver NVIDIA não for encontrado?

Causa: Você criou a imagem do container 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 Function Compute injeta em tempo de execução.

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

Além disso, mantenha a 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 não corresponder à versão fornecida pela plataforma, o aplicativo pode apresentar comportamento inesperado.

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

Quando uma instância de função inicia, a plataforma Function Compute injeta automaticamente os componentes corretos do driver de modo de usuário no container. Esse é o mesmo mecanismo usado por tecnologias de virtualização de container GPU, como NVIDIA Container Runtime, que mantém o gerenciamento do driver na plataforma para garantir a portabilidade da imagem entre atualizações de driver.

Se você já usa NVIDIA Container Runtime ou tecnologia similar, evite docker commit. Imagens criadas dessa forma contêm componentes de driver injetados que podem ter incompatibilidade de versão com os fornecidos pela plataforma Function Compute, causando comportamento indefinido.