Especificações de imagem personalizada para criar aplicações de IA

Ao criar uma imagem personalizada usando um modelo desenvolvido localmente, certifique-se de que a imagem esteja em conformidade com as especificações do ModelArts.

• Nenhum código malicioso é permitido.
• Uma imagem personalizada não pode ter mais de 50 GB.
• APIs externas

  Defina a API de serviço externo para uma imagem personalizada. A API de inferência deve ser a mesma que o URL definido pelo apis em config.json. Em seguida, a API de serviço externo pode ser acessada diretamente quando a imagem é iniciada. Segue-se um exemplo de acesso a uma imagem de MNIST. A imagem contém um modelo treinado usando um conjunto de dados de MNIST e pode identificar dígitos manuscritos. listen_ip indica o endereço IP do contêiner. Você pode iniciar uma imagem personalizada para obter o endereço IP do contêiner.

  • Exemplo de solicitação

    curl -X POST \ http://{Listening IP address}:8080/ \ -F images=@seven.jpg
    Figura 1 Exemplo de obtenção de listen_ip
    
  • Exemplo de resposta

    {"mnist_result": 7}
• (Opcional) API de verificação de integridade
  Se os serviços não forem interrompidos durante uma atualização contínua, a API de verificação de integridade deve ser configurada em config.json para ModelArts. A API de verificação de integridade retorna o estado de integridade de um serviço quando o serviço está sendo executado corretamente ou um erro quando o serviço se torna defeituoso.

  

  A API de verificação de integridade deve ser configurada para uma atualização contínua sem acertos.

  A seguir, mostramos uma API de verificação de integridade de exemplo:

  • URI

    GET /health
  • Exemplo de solicitação: curl -X GET \ http://{Listening IP address}:8080/health
  • Exemplo de resposta

    {"health": "true"}
  • Código de status

    Tabela 1 Código de status

    Código de status	Mensagem	Descrição
    200	OK	Solicitação enviada.

• Saída do arquivo de log

  Configure a saída padrão para que os logs possam ser exibidos corretamente.

• Arquivo de inicialização de imagem

  Para implementar um serviço em lote, defina o arquivo de inicialização de uma imagem como /home/run.sh e use CMD para definir o caminho de inicialização padrão. A seguir está um exemplo de Dockerfile:

  CMD ["sh", "/home/run.sh"]

• Dependências de imagem

  Para implementar um serviço em lote, instale pacotes de dependência como Python, JRE/JDK e ZIP na imagem.

• (Opcional) Atualização contínua sem acertos

  Para garantir que os serviços não sejam interrompidos durante uma atualização contínua, defina HTTP keep-alive como 200. Por exemplo, Gunicorn não suporta Keep-alive por padrão. Para garantir uma atualização contínua sem acertos, instale Gevent e configure --keep-alive 200 -k gevent na imagem. As configurações de parâmetros variam dependendo da estrutura de serviço. Defina os parâmetros conforme necessário.

• (Opcional) Saída graciosa de um contêiner

  Para garantir que os serviços não sejam interrompidos durante uma atualização contínua, o sistema deve capturar sinais SIGTERM no contêiner e aguardar 60s antes de sair do contêiner. Se a duração for inferior a 60s antes da saída graciosa, os serviços podem ser interrompidos durante a atualização rolante. Para garantir a execução ininterrupta do serviço, o sistema sai do contêiner depois que o sistema recebe sinais SIGTERM e processa todas as solicitações recebidas. Toda a duração não é superior a 90s. A seguir, mostra o exemplo run.sh:

  #!/bin/bash
  gunicorn_pid=""
  
  handle_sigterm() {
    echo "Received SIGTERM, send SIGTERM to $gunicorn_pid"
    if [ $gunicorn_pid != "" ]; then
        sleep 60
        kill -15 $gunicorn_pid  # Transfer SIGTERM signals to the Gunicorn process.
        wait $gunicorn_pid           # Wait until the Gunicorn process stops.
    fi
  }
  
  trap handle_sigterm TERM