Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
Estava fazendo o projeto de visão computacional do mestrado e, assim como todo treinamento de transformers, estava demorando muito. Comecei a cogitar pagar o google colab pro, pra poder usar a GPU A100, mas um colega me falou que não viu muita diferença comparado à GPU gratuita, a T4. Achei estranho, então fui pesquisar um pouco e descobri que, com alguns ajustes no modelo, é possível otimizar o uso da GPU. Então resolvi escrever sobre algumas dessas otimizações que me ajudaram a acelerar MUITO o fine-tuning, para caso alguém esteja com o mesmo problema. Vou explicar no contexto do meu projeto, que era a detecção de violência em vídeos.
Mixed Precision Training
Imagine que o seu modelo precisa "assistir" a sequência de frames do vídeo e "entender" o que está acontecendo em cada frame e como eles se relacionam no tempo para decidir se há violência. Para fazer isso, o modelo realiza milhões, talvez até bilhões, de operações matemáticas complexas em cada frame e entre os frames (que é algo que os modelos tansformers fazem muito bem, devido ao mecanismo de atenção).
Cada frame é uma imagem, que são são representadas por muitos números. Uma sequência de frames de um vídeo de alta resolução é uma quantidade ENORME de dados numéricos. O modelo transformer também tem muitos parâmetros (pesos), que também são números. Armazenar e processar todos esses números com a "precisão total" (FP32) exige uma quantidade gigantesca da memória da GPU. Isso limita o tamanho dos vídeos que você pode analisar de uma vez (batch size) ou a resolução dos frames que você pode usar. E fazer todas essas bilhões de contas com "precisão total" leva tempo. Mesmo com uma GPU poderosa, o treinamento (o processo de ensinar o modelo a detectar violência) pode ser muito lento.
Com mixed precision, o sistema decide que essas operações podem ser feitas usando a "meia precisão" (FP16), então a maior parte das operações dentro do seu transformer, como as que processam a informação de cada frame, calculam a atenção entre frames, ou transformam os dados através das camadas internas, não precisa de toda a precisão do FP32 o tempo todo. É como se, para a maior parte da análise visual e temporal dos frames, o modelo usasse uma representação numérica mais resumida. Isso usa metade da memória por número e, além disso, as GPUs do google colab têm unidades especiais (os chamados tensor cores da NVIDIA) que fazem contas em FP16 muito mais rápido do que em FP32.
O "conhecimento" do seu modelo, que são os pesos que ele aprende para identificar padrões de violência, continua sendo guardado com "precisão total" (FP32). Se eles continuassem sendo guardados em FP16, eles poderiam simplesmente virar zero devido à menor precisão do formato. É aí que entra o GradScaler: ele "amplifica" esses pequenos ajustes temporariamente para que eles não sumam durante os cálculos feitos em FP16. Depois que os cálculos são feitos, ele retorna os ajustes de volta ao tamanho original antes de usá-los para atualizar os pesos principais (que estão em FP32). Isso garante que o modelo possa aprender até os detalhes mais sutis que são necessários, mesmo usando FP16 para a maior parte do processamento.
Ajuste de batch_size
O batch_size representa quantos blocos de imagens (sequências de frames) são mostrados ao modelo de uma vez durante o treinamento. Quando você envia um batch maior, você dá mais trabalho para a GPU fazer em paralelo em vez de esperar por vários batches pequenos. Isso mantém as unidades de processamento da GPU mais ocupadas, levando a uma utilização melhor e maior velocidade no processamento de dados. O objetivo é usar o máximo de recursos da GPU sem estourar a memória, então processar mais exemplos de uma vez resulta em melhor aproveitamento da GPU.
Além disso, durante o treinamento, o modelo calcula o erro (loss) para cada batch e usa esse erro para calcular os gradientes (as direções de ajuste) para aquele batch específico. O gradiente é um vetor que aponta para a direção de maior aumento da função de perda (erro) em relação aos pesos do modelo naquele momento. Em termos simples, ele mostra como cada peso do modelo deve ser ajustado (para mais ou para menos, e quanto) para diminuir o erro de forma mais eficiente. Os pesos do modelo são então atualizados com base nesses gradientes calculados a partir do batch.
O gradiente calculado a partir de um batch é uma estimativa do gradiente "verdadeiro" que seria calculado se usássemos todo o conjunto de dados de treinamento (o que é impraticável). Um batch maior geralmente fornece uma estimativa de gradiente mais precisa e menos ruidosa do gradiente global, já que estamos calculando a média do "direcionamento" de erro sobre mais exemplos. Isso leva a um caminho de otimização mais estável e direto em direção ao mínimo da função de loss.
torch.backends.cudnn.benchmark
Essa configuração, quando configurada como True, instrui a biblioteca cuDNN (uma biblioteca da NVIDIA otimizada para operações de redes neurais que o PyTorch utiliza em GPUs) a encontrar e usar os algoritmos mais rápidos para as operações que ela executa para uma dada configuração específica de input e operação.
O que acontece é que, para cada tipo de operação matemática que o cuDNN otimiza (como as multiplicações de matrizes usadas intensivamente no seu modelo Transformer, ou possíveis convoluções iniciais) e para cada tamanho específico de dados de entrada que essa operação recebe pela primeira vez durante o treinamento, o cuDNN realiza internamente um pequeno teste. Ele executa essa mesma operação usando diferentes algoritmos que tem disponíveis e mede qual deles termina mais rápido na sua GPU atual com aqueles dados daquele tamanho. Uma vez encontrado o algoritmo mais veloz para essa configuração específica de operação e dados, o cuDNN armazena essa informação.
A mágica acontece nas centenas de milhares ou milhões de vezes seguintes que o seu modelo precisa executar exatamente essa mesma operação com os mesmos tamanhos de dados (o que ocorre repetidamente em cada passo de treinamento, batch após batch). Em vez de gastar tempo escolhendo um algoritmo ou usando um padrão que pode não ser o ideal, o cuDNN vai direto e usa o algoritmo mais rápido que ele descobriu no teste inicial. Isso resulta em uma aceleração significativa no tempo total de treinamento, pois as partes mais pesadas e repetitivas dos cálculos do seu modelo são executadas da maneira mais eficiente que a sua GPU permite para aquelas dimensões exatas, o que funciona muito bem quando os tamanhos de input do modelo (como frames de vídeo redimensionados) são consistentes.
Mixed Precision Training
Imagine que o seu modelo precisa "assistir" a sequência de frames do vídeo e "entender" o que está acontecendo em cada frame e como eles se relacionam no tempo para decidir se há violência. Para fazer isso, o modelo realiza milhões, talvez até bilhões, de operações matemáticas complexas em cada frame e entre os frames (que é algo que os modelos tansformers fazem muito bem, devido ao mecanismo de atenção).
Cada frame é uma imagem, que são são representadas por muitos números. Uma sequência de frames de um vídeo de alta resolução é uma quantidade ENORME de dados numéricos. O modelo transformer também tem muitos parâmetros (pesos), que também são números. Armazenar e processar todos esses números com a "precisão total" (FP32) exige uma quantidade gigantesca da memória da GPU. Isso limita o tamanho dos vídeos que você pode analisar de uma vez (batch size) ou a resolução dos frames que você pode usar. E fazer todas essas bilhões de contas com "precisão total" leva tempo. Mesmo com uma GPU poderosa, o treinamento (o processo de ensinar o modelo a detectar violência) pode ser muito lento.
Com mixed precision, o sistema decide que essas operações podem ser feitas usando a "meia precisão" (FP16), então a maior parte das operações dentro do seu transformer, como as que processam a informação de cada frame, calculam a atenção entre frames, ou transformam os dados através das camadas internas, não precisa de toda a precisão do FP32 o tempo todo. É como se, para a maior parte da análise visual e temporal dos frames, o modelo usasse uma representação numérica mais resumida. Isso usa metade da memória por número e, além disso, as GPUs do google colab têm unidades especiais (os chamados tensor cores da NVIDIA) que fazem contas em FP16 muito mais rápido do que em FP32.
O "conhecimento" do seu modelo, que são os pesos que ele aprende para identificar padrões de violência, continua sendo guardado com "precisão total" (FP32). Se eles continuassem sendo guardados em FP16, eles poderiam simplesmente virar zero devido à menor precisão do formato. É aí que entra o GradScaler: ele "amplifica" esses pequenos ajustes temporariamente para que eles não sumam durante os cálculos feitos em FP16. Depois que os cálculos são feitos, ele retorna os ajustes de volta ao tamanho original antes de usá-los para atualizar os pesos principais (que estão em FP32). Isso garante que o modelo possa aprender até os detalhes mais sutis que são necessários, mesmo usando FP16 para a maior parte do processamento.
Ajuste de batch_size
O batch_size representa quantos blocos de imagens (sequências de frames) são mostrados ao modelo de uma vez durante o treinamento. Quando você envia um batch maior, você dá mais trabalho para a GPU fazer em paralelo em vez de esperar por vários batches pequenos. Isso mantém as unidades de processamento da GPU mais ocupadas, levando a uma utilização melhor e maior velocidade no processamento de dados. O objetivo é usar o máximo de recursos da GPU sem estourar a memória, então processar mais exemplos de uma vez resulta em melhor aproveitamento da GPU.
Além disso, durante o treinamento, o modelo calcula o erro (loss) para cada batch e usa esse erro para calcular os gradientes (as direções de ajuste) para aquele batch específico. O gradiente é um vetor que aponta para a direção de maior aumento da função de perda (erro) em relação aos pesos do modelo naquele momento. Em termos simples, ele mostra como cada peso do modelo deve ser ajustado (para mais ou para menos, e quanto) para diminuir o erro de forma mais eficiente. Os pesos do modelo são então atualizados com base nesses gradientes calculados a partir do batch.
O gradiente calculado a partir de um batch é uma estimativa do gradiente "verdadeiro" que seria calculado se usássemos todo o conjunto de dados de treinamento (o que é impraticável). Um batch maior geralmente fornece uma estimativa de gradiente mais precisa e menos ruidosa do gradiente global, já que estamos calculando a média do "direcionamento" de erro sobre mais exemplos. Isso leva a um caminho de otimização mais estável e direto em direção ao mínimo da função de loss.
torch.backends.cudnn.benchmark
Essa configuração, quando configurada como True, instrui a biblioteca cuDNN (uma biblioteca da NVIDIA otimizada para operações de redes neurais que o PyTorch utiliza em GPUs) a encontrar e usar os algoritmos mais rápidos para as operações que ela executa para uma dada configuração específica de input e operação.
O que acontece é que, para cada tipo de operação matemática que o cuDNN otimiza (como as multiplicações de matrizes usadas intensivamente no seu modelo Transformer, ou possíveis convoluções iniciais) e para cada tamanho específico de dados de entrada que essa operação recebe pela primeira vez durante o treinamento, o cuDNN realiza internamente um pequeno teste. Ele executa essa mesma operação usando diferentes algoritmos que tem disponíveis e mede qual deles termina mais rápido na sua GPU atual com aqueles dados daquele tamanho. Uma vez encontrado o algoritmo mais veloz para essa configuração específica de operação e dados, o cuDNN armazena essa informação.
A mágica acontece nas centenas de milhares ou milhões de vezes seguintes que o seu modelo precisa executar exatamente essa mesma operação com os mesmos tamanhos de dados (o que ocorre repetidamente em cada passo de treinamento, batch após batch). Em vez de gastar tempo escolhendo um algoritmo ou usando um padrão que pode não ser o ideal, o cuDNN vai direto e usa o algoritmo mais rápido que ele descobriu no teste inicial. Isso resulta em uma aceleração significativa no tempo total de treinamento, pois as partes mais pesadas e repetitivas dos cálculos do seu modelo são executadas da maneira mais eficiente que a sua GPU permite para aquelas dimensões exatas, o que funciona muito bem quando os tamanhos de input do modelo (como frames de vídeo redimensionados) são consistentes.