Conetor para PyTorch

O conetor do Cloud Storage para PyTorch é um produto de código aberto suportado pela Google que oferece uma integração direta do Cloud Storage com o PyTorch.

Vista geral

O conetor para PyTorch oferece vantagens para o carregamento de dados na preparação e para a criação de pontos de verificação e o carregamento de modelos:

Para o carregamento de dados na preparação, o conetor para PyTorch oferece as seguintes vantagens:

• O conetor para PyTorch contém otimizações para tornar o treino até três vezes mais rápido do que o PyTorch predefinido em conjuntos de dados compostos principalmente por ficheiros com menos de 1 MB.
• O conetor para o PyTorch implementa a primitiva de conjunto de dados do PyTorch que pode ser usada para ajudar a carregar de forma eficiente dados de preparação de contentores do Cloud Storage.
• Suporte para conjuntos de dados de estilo de mapa para padrões de acesso a dados aleatórios e conjuntos de dados de estilo iterável para padrões de acesso a dados de streaming.
• A capacidade de transformar os bytes de dados não processados transferidos no formato à sua escolha, o que permite que o PyTorch DataLoader funcione de forma flexível com matrizes NumPy ou tensores PyTorch.

Para a criação de pontos de verificação e o carregamento de modelos, o conector para o PyTorch oferece as seguintes vantagens:

• Uma interface de criação de pontos de verificação para guardar de forma conveniente e direta os pontos de verificação do modelo num contentor do Cloud Storage e carregar os pontos de verificação do modelo a partir do contentor.
• O conetor para PyTorch suporta a criação de pontos de verificação do PyTorch Lightning através da implementação DatafluxLightningCheckpoint do CheckpointIO do PyTorch Lightning.
• O conector para PyTorch oferece implementações StorageWriter e StorageReader para utilização com a criação de pontos de verificação distribuídos do PyTorch. A biblioteca de demonstração do conetor para PyTorch inclui código de exemplo para usar isto numa carga de trabalho FSDP do PyTorch Lightning.
• A criação de pontos de verificação de conetores inclui suporte para guardar pontos de verificação assíncronos com o Lightning e o PyTorch base.

Para mais informações, consulte a página de destino do GitHub do conetor para PyTorch.

Frameworks

O conetor para PyTorch é suportado nas seguintes versões do framework:

• Python 3.8 ou superior
• PyTorch Lightning 2.0 ou superior
• PyTorch 2.3.1 ou superior

Começar

Para usar o conector para PyTorch, tem de ter o seguinte:

• Um contentor do Cloud Storage que contém os dados com os quais quer trabalhar.
  • Consulte a utilização de objetos compostos para ver definições recomendadas adicionais para o contentor.
• As seguintes autorizações para trabalhar com os dados armazenados no contentor:
  • storage.objects.create
  • storage.objects.list
  • storage.objects.get
  • storage.objects.delete, se pretender usar transferências compostas

Estas autorizações têm de ser concedidas à conta que o conector para PyTorch vai usar para autenticação através de uma função do IAM, como utilizador de objetos de armazenamento.

Instalação

Para instalar o conetor para PyTorch, use o seguinte comando:

pip install gcs-torch-dataflux

Configuração

Tem de fornecer a autenticação para usar o conector para PyTorch Credenciais predefinidas da aplicação através de um dos seguintes métodos:

• Ao executar o conetor para PyTorch numa VM do Compute Engine, as credenciais predefinidas da aplicação usam automaticamente a conta de serviço anexada à VM por predefinição. Para mais informações, consulte o artigo Escolha um método de autenticação de cargas de trabalho.
• As Credenciais padrão da aplicação também podem ser configuradas manualmente. Pode iniciar sessão diretamente através da Google Cloud CLI:

gcloud auth application-default login

Exemplos

Pode encontrar um conjunto completo de exemplos para trabalhar com o conetor para PyTorch no diretório de demonstração do repositório GitHub do conetor para PyTorch. Os exemplos incluem:

• Um Jupyter Notebook básico inicial (alojado pelo Google Colab).
• Uma explicação detalhada da carga de trabalho de preparação da segmentação de imagens integral.
• Um exemplo ponto a ponto e o bloco de notas para a integração do PyTorch Lightning.

Desempenho

O conector para PyTorch tem otimizações específicas concebidas para cargas de trabalho de ML que podem oferecer um desempenho significativamente melhor do que as chamadas diretas à API para o Cloud Storage:

• Para otimizar o desempenho da listagem, o conetor para PyTorch usa um algoritmo de listagem rápida desenvolvido para equilibrar a carga de trabalho da listagem entre processos de listagem de objetos paralelizados.
• Para otimizar o desempenho do download de ficheiros pequenos, o conetor para PyTorch usa a operação de composição para concatenar conjuntos de objetos mais pequenos em objetos únicos e maiores. Estes novos objetos compostos são armazenados no mesmo contentor que os objetos de origem e têm o prefixo dataflux-composed-objects/ nos respetivos nomes.
• O carregamento multipartes para a gravação de pontos de verificação permite uma melhoria do desempenho até 10 vezes superior ao carregamento de pontos de verificação padrão.

Pode encontrar dados de desempenho no GitHub para o seguinte:

• Formação baseada em texto do Lightning
• Lightning Image Training
• Criação de pontos de verificação de nó único
• Criação de pontos de verificação com vários nós

Considerações

Deve ter em consideração o seguinte com base na carga de trabalho.

Operações de apresentação rápidas

O conetor para o algoritmo de listagem rápida do PyTorch faz com que o conetor para o PyTorch use mais operações de listagem do que uma listagem sequencial normal. As operações de apresentação são cobradas como operações de classe A.

Utilização de objetos compostos

Para evitar cobranças de armazenamento excessivas e cobranças de eliminação antecipada quando trabalha com objetos compostos temporários, deve garantir que o seu contentor usa as seguintes definições:

• Eliminação recuperável desativada
• Bloqueio de contentores desativado
• Controlo de versões de objetos desativado
• Armazenamento padrão como classe de armazenamento para o contentor e os objetos.

Normalmente, os objetos compostos criados pelo conetor para PyTorch são removidos automaticamente no final do ciclo de preparação, mas, em casos raros, podem não ser. Para garantir que os objetos são removidos do seu contentor, pode executar o seguinte comando:

gcloud storage rm gs://<my-bucket>/dataflux-composed-objects/ --recursive

Pode desativar a utilização de objetos compostos incluindo disable_compose=True ou max_composite_object_size=0 na parte de configuração do conjunto de dados que está a criar. No entanto, desativar este comportamento pode fazer com que os ciclos de preparação demorem significativamente mais tempo, especialmente quando trabalha com ficheiros pequenos.

A utilização de objetos compostos faz com que o Cloud Storage atinja os limites de QPS e débito a uma escala inferior à da transferência direta de ficheiros. Deve desativar a utilização de objetos compostos quando executar a um nível de vários nós elevado em que atinge os limites de QPS ou débito do projeto, mesmo sem usar objetos compostos.

Erros 429 e desempenho degradado

Ao trabalhar com o conetor para PyTorch, pode receber erros 429 ou tempos de execução mais lentos do que o esperado. Existem vários motivos comuns para que isto aconteça:

• Muitos esforços de aprendizagem automática optam por um modelo de preparação altamente distribuído que tira partido de ferramentas como o PyTorch Lightning e o Ray. Estes modelos são compatíveis com o conetor para o PyTorch, mas podem acionar frequentemente os limites de taxa do Cloud Storage.
• Os erros 429 acompanhados de mensagens como "Esta carga de trabalho está a usar demasiada largura de banda de saída do Cloud Storage" ou "Esta carga de trabalho acionou o limite de largura de banda de saída do Cloud Storage" indicam que a taxa de débito de dados da sua carga de trabalho está a exceder a capacidade máxima do seu projeto Google Cloud . Para resolver estes problemas, siga os seguintes passos:
  • Verifique se outras cargas de trabalho no seu projeto não estão a usar largura de banda excessiva.
  • Candidatar-se a um aumento da quota.
  • Ajuste as opções list_retry_config e download_retry_config na secção de configuração dos conjuntos de dados que está a criar para ajustar a repetição com recuo e maximizar o desempenho.
• Os limites de QPS podem acionar erros 429 com uma mensagem no corpo a indicar TooManyRequests, mas manifestam-se mais frequentemente em tempos de execução mais lentos do que o esperado. Os gargalos de QPS são mais comuns quando se opera com grandes volumes de ficheiros pequenos. Os limites de QPS de bucket são naturalmente dimensionados ao longo do tempo, pelo que permitir um período de preparação pode, muitas vezes, levar a um desempenho mais rápido. Para ver mais detalhes sobre o desempenho de um segmento de destino, consulte o separador Observabilidade quando vir o segmento a partir da Google Cloud consola.
• Se a sua carga de trabalho estiver a falhar com um erro TooManyRequests que inclua a palavra-chave dataflux-composed-objects na mensagem de erro, desativar a utilização de objetos compostos é o melhor primeiro passo de resolução de problemas. Ao fazê-lo, pode reduzir a carga de QPS causada pelas operações de composição quando usadas em grande escala.

Consumo de memória

As escritas e os carregamentos de pontos de verificação, incluindo os modelos finais para inferência, são totalmente preparados na memória para otimizar o desempenho de carregamento e transferência. Cada máquina tem de ter RAM livre suficiente para preparar o respetivo ponto de verificação na memória, de modo a poder tirar partido destas melhorias de desempenho.

Obter apoio técnico

Pode receber apoio técnico, enviar perguntas gerais e pedir novas funcionalidades através de um dos Google Cloud canais de apoio técnico oficiais. Também pode receber apoio técnico comunicando problemas no GitHub.

PyTorch, o logótipo PyTorch e quaisquer marcas relacionadas são marcas comerciais da The Linux Foundation.