- Use modelos que carregam rápido e exigem uma transformação mínima em estruturas prontas para GPU e otimize como elas são carregadas.
- Use configurações que permitam execução máxima, eficiente e simultânea para reduzir o número de GPUs necessárias para atender a uma solicitação de destino por segundo, mantendo os custos baixos.
Maneiras recomendadas de carregar modelos de ML grandes no Cloud Run
O Google recomenda armazenar modelos de ML dentro de imagens de contêiner. ou otimizar carregá-los do Cloud Storage.
Compensações entre armazenar e carregar modelos
Confira uma comparação das opções:
| Local do modelo | Hora da implantação | Experiência de desenvolvimento | Tempo de inicialização do contêiner | Custo de armazenamento |
| Imagem do contêiner | Lento. Uma imagem que contém um modelo grande leva mais tempo para ser importada para o Cloud Run. | As mudanças na imagem do contêiner exigirão uma nova implantação, que pode ser lenta para imagens grandes. | Depende do tamanho do modelo. Para modelos muito grandes, use o Cloud Storage para ter um desempenho mais previsível, porém mais lento. | Possivelmente várias cópias no Artifact Registry. |
| Cloud Storage, carregado usando a montagem de volume do Cloud Storage FUSE | Rápido. Modelo baixado durante a inicialização do contêiner. | Não é difícil de configurar e não requer mudanças na imagem Docker. | Rápido quando você usa otimizações de rede. Não carrega o download em paralelo. | Uma cópia no Cloud Storage. |
Cloud Storage, baixado simultaneamente usando o comando de CLI do Google Cloud gcloud storage cp ou a API de Cloud Storage conforme mostrado no exemplo de código de download simultâneo do gerente de transferência.
|
Rápido. Modelo baixado durante a inicialização do contêiner. | Um pouco mais difícil de configurar porque será preciso instalar a CLI do Google Cloud na imagem ou atualizar o código do aplicativo para usar a API Cloud Storage. | Rápido quando você usa otimizações de rede. A CLI do Google Cloud faz o download do arquivo modelo em paralelo, o que é mais rápido do que a montagem do FUSE. | Uma cópia no Cloud Storage. |
| Internet | Rápido. Modelo baixado durante a inicialização do contêiner. | Geralmente mais simples (muitos frameworks fazem o download de modelos de repositórios centrais). | Geralmente ruim e imprevisível:
|
Depende do provedor de hospedagem do modelo. |
Armazenar modelos em imagens de contêiner
Ao armazenar o modelo de ML na imagem do contêiner, o carregamento do modelo se beneficia da infraestrutura otimizada de streaming de contêineres do Cloud Run. No entanto, a criação de imagens de contêiner que incluem modelos de ML é um processo que exige muitos recursos, principalmente ao trabalhar com modelos grandes. Em particular, o processo de build pode ficar congestionado na capacidade de rede. Ao usar o Cloud Build, recomendamos usar uma máquina de build mais potente com maior desempenho de computação e rede. Para fazer isso, crie uma imagem usando um arquivo de configuração de build com estas etapas:
steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'IMAGE', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'IMAGE'] images: - IMAGE options: machineType: 'E2_HIGHCPU_32' diskSizeGb: '500'
É possível criar uma cópia de modelo por imagem se a camada que contém o modelo for distinta entre as imagens (hash diferente). Pode haver custo de Artifact Registry adicional porque pode haver uma cópia do modelo por imagem se a camada de modelo for única em cada imagem.
Armazenar modelos no Cloud Storage
Para otimizar o carregamento de modelos de ML do Cloud Storage,
usando montagens de volume do Cloud Storage
ou diretamente a API do Cloud Storage ou a linha de comando, é necessário usar a VPC direta com
o valor de configuração de saída definido como all-traffic, junto com o Acesso privado do Google.
Carregar modelos da Internet
Para otimizar o carregamento do modelo de ML pela Internet, roteie todo o tráfego pela
rede VPC com o valor de configuração de saída
definido como all-traffic e configure o Cloud NAT para acessar a Internet pública com alta largura de banda.
Considerações sobre criação, implantação, ambiente de execução e design do sistema
As seções a seguir descrevem considerações sobre build, implantação, ambiente de execução e design do sistema.
No tempo de build
A lista a seguir mostra as considerações que você precisa levar em conta ao planejar seu build:
- Escolha uma boa imagem de base. Comece com uma imagem dos contêineres de aprendizado profundo ou do registro de contêineres da NVIDIA para o framework de ML que você está usando. Essas imagens têm os pacotes mais recentes relacionados ao desempenho instalados. Não recomendamos criar uma imagem personalizada.
- Escolha modelos quantizados de 4 bits para maximizar a simultaneidade, a menos que você prove que eles afetam a qualidade dos resultados. A quantização produz modelos menores e mais rápidos, reduzindo a quantidade de memória de GPU necessária para fornecer o modelo e pode aumentar o paralelismo no ambiente de execução. O ideal é que os modelos sejam treinados na profundidade de bits desejada, em vez de serem quantizados para ela.
- Escolha um formato de modelo com tempos de carregamento rápidos para minimizar o tempo de inicialização do contêiner, como GGUF. Esses formatos refletem com mais precisão o tipo de quantização desejado e exigem menos transformações quando carregados na GPU. Por motivos de segurança, não use checkpoints no formato pickle.
- Crie e aqueça caches do LLM no tempo de build. Inicie o LLM na máquina de build enquanto cria a imagem Docker. Ative o armazenamento em cache de comandos e o feed comum ou comandos de exemplo para ajudar no armazenamento em cache para uso no mundo real. Salve as saídas que são geradas para que sejam carregadas no ambiente de execução.
- Salve seu próprio modelo de inferência gerado durante o tempo de build. Isso poupa tempo significativo em comparação ao carregamento de modelos armazenados de forma menos eficiente e aplicação de transformações como quantização na inicialização do contêiner.
Na implantação
A lista a seguir mostra as considerações que você precisa levar em conta ao planejar sua implantação:
- Não é possível escalonar automaticamente os pools de workers de GPU. Você vai receber uma cobrança pela GPU mesmo que ela não esteja executando nenhum processo.
- A CPU e a memória dos pools de workers têm preços diferentes dos serviços e jobs. No entanto, o preço da SKU de GPU é o mesmo dos serviços e jobs.
No ambiente de execução
- Gerencie ativamente o tamanho de contexto compatível. Quanto menor for a janela de contexto que você aceita, mais consultas poderão ser executadas em paralelo. Os detalhes de como fazer isso dependem da estrutura.
- Use os caches de LLM gerados no tempo de build. Forneça as mesmas flags usadas durante o tempo de build ao gerar o cache de prefixo e comando.
- Carregue o modelo salvo que você acabou de escrever. Consulte Compensações de armazenamento e carregamento de modelos para obter uma comparação sobre como carregar o modelo.
- Use um cache de chaves-valor quantizado se a estrutura for compatível. Isso pode reduzir os requisitos de memória por consulta e permite a configuração de mais paralelismo. No entanto, isso também pode afetar a qualidade.
- Ajuste a quantidade de memória da GPU a ser reservada para pesos de modelo, ativações e caches de chave-valor. Defina o valor mais alto possível sem receber um erro de falta de memória.
- Verifique se o framework tem alguma opção para melhorar o desempenho da inicialização do contêiner (por exemplo, usando o carregamento em paralelo de modelos).
No nível de design do sistema
- Adicione caches semânticos onde apropriado. Em alguns casos, o armazenamento em cache de consultas e respostas inteiras pode ser uma ótima maneira de limitar o custo de consultas comuns.
- Controle a variância nos preâmbulos. Os caches de comando são úteis apenas quando contêm os comandos em sequência. Caches são efetivamente prefixos em cache. Inserções ou edições na sequência significam que elas não estão em cache ou apenas estão parcialmente presentes.