As eficiências “alternáveis”: redução dos custos de IA dentro do ciclo de treinamento

A maneira mais fácil de acelerar um carro de corrida é tirar o peso do chassi. No Deep Learning, esse peso é a precisão.

Durante anos, o ponto flutuante de 32 bits (FP32) foi o padrão. Mas hoje, mudar para matemática de precisão mista (FP16/INT8) é a maior mudança de ROI que um profissional pode fazer. Em hardware com unidades tensoras dedicadas, como NVIDIA Ampere/Hopper, AMD RDNA 3 ou Intel Gaudi 2, a precisão mista pode aumentar o rendimento em 3x ou mais.

No entanto, esta não é uma varinha mágica para todos. Se você estiver executando em GPUs anteriores a 2019 (como a arquitetura Pascal) sem Tensor Cores, poderá ver quase nenhum ganho de velocidade e correr o risco de instabilidade numérica. Da mesma forma, as cargas de trabalho de conformidade em finanças ou saúde que exigem reprodutibilidade com precisão de bits podem precisar seguir o FP32.

Mas para 90% dos casos de uso que envolvem modelos vinculados à memória (ResNet-50, GPT-2, Difusão Estável), a mudança é essencial. Ele também desbloqueia o Gradient Accumulation, permitindo treinar modelos enormes em cartões menores e mais baratos, simulando lotes maiores. A implementação: Veja como implementar precisão mista e acumulação de gradiente no PyTorch. Esta configuração permite simular um tamanho de lote de 64 em uma GPU que pode acomodar apenas 8 amostras.

python
# From 'green-ai-optimization-toolkit/01_mixed_precision.py'

import torch
from torch.cuda.amp import autocast, GradScaler

# Simulate a Batch Size of 64 using a Micro-Batch of 8
eff_batch_size = 64
micro_batch = 8
accum_steps = eff_batch_size // micro_batch 

scaler = GradScaler() # Prevents gradient underflow in FP16

for i, (data, target) in enumerate(loader):
    # 1. The Toggle: Run forward pass in FP16
    with autocast():
        output = model(data)
        loss = criterion(output, target)
        loss = loss / accum_steps # Normalize loss
    
    # 2. Scale gradients and accumulate
    scaler.scale(loss).backward()
    
    # 3. Step only after N micro-batches
    if (i + 1) % accum_steps == 0:
        scaler.step(optimizer)
        scaler.update()
        optimizer.zero_grad()

As alavancas de dados: alimentando a fera

Se a utilização da GPU estiver em torno de 40%, você não estará treinando um modelo; você está queimando dinheiro. O gargalo é quase sempre o carregador de dados.

Um erro comum é tratar o pré-processamento de dados como um imposto por época. Se você usar tokenizadores de texto caros (como codificação de pares de bytes) ou transformações de imagem complexas, armazene em cache os dados pré-processados. Tokenize ou redimensione uma vez, armazene o resultado e alimente-o diretamente.

Além disso, observe os formatos de arquivo. A leitura de milhões de pequenos arquivos JPEG ou CSV em um sistema de arquivos de rede elimina a taxa de transferência de E/S devido à sobrecarga de metadados. Em vez disso, transmita dados por meio de arquivos. Fragmentar seu conjunto de dados em arquivos tar POSIX ou formatos binários como Parquet/Avro permite que o sistema operacional leia antecipadamente, mantendo a GPU com fome.

Cuidado com:

• Aumento do armazenamento: o armazenamento em cache de dados pré-processados ​​pode triplicar seu espaço de armazenamento. Você está negociando custo de armazenamento (barato) por tempo de computação (caro).
• Remoção excessiva: embora a desduplicação de dados seja excelente para web scrapes, tome cuidado com conjuntos de dados médicos ou jurídicos selecionados. A filtragem agressiva pode descartar casos extremos raros que são críticos para a robustez do modelo.

A corrida de treinamento mais cara é aquela que trava 99% do caminho e precisa ser reiniciada.

Na nuvem, as instâncias spot (ou VMs preemptivas) oferecem descontos de até 90%. Para usá-los com segurança, você deve implementar pontos de verificação robustos. Salve o estado do modelo com frequência (a cada época ou N etapas) para que, se um nó for recuperado, você perca minutos de trabalho, não dias.

Estruturas de orquestração de código aberto como o SkyPilot tornaram-se essenciais aqui. O SkyPilot abstrai a complexidade das instâncias spot, lidando automaticamente com a recuperação de nós recuperados e permitindo que os engenheiros tratem nuvens diferentes (AWS, GCP, Azure) como um pool de recursos único e com custo otimizado.

Você também deve implementar a parada antecipada. Não há ROI em “ruído de polimento”. Se sua perda de validação estagnar por 3 épocas, interrompa a corrida. Isto é especialmente potente para tarefas de ajuste fino, onde a maioria dos ganhos chega nas primeiras épocas. No entanto, tenha cuidado se estiver a utilizar a aprendizagem curricular, onde a perda pode aumentar naturalmente antes de cair novamente à medida que exemplos mais difíceis são introduzidos.

O protocolo de “teste de fumaça”

Por fim, nunca inicie um trabalho de vários nós sem uma simulação. Um script simples que executa dois lotes em uma CPU pode capturar incompatibilidades de formas e bugs de OOM por centavos.

python
# From 'green-ai-optimization-toolkit/03_smoke_test.py'
def smoke_test(model, loader, device="cpu", steps=2):
    """
    Runs a dry-run on CPU to catch shape mismatches 
    and OOM bugs before the real run starts.
    """
    print(f"💨 Running Smoke Test on {device}...")
    model.to(device)
    model.train()
    
    try:
        for i, (data, target) in enumerate(loader):
            if i >= steps: break
            data, target = data.to(device), target.to(device)
            output = model(data)
            loss = output.sum()
            loss.backward()
        print("✅ Smoke Test Passed. Safe to launch expensive job.")
        return True
    except Exception as e:
        print(f"❌ Smoke Test Failed: {e}")
        return False

A lista de verificação rápida: 10 vitórias táticas rápidas

Além das grandes mudanças arquitetônicas, há uma longa cauda de otimizações menores que, quando empilhadas, geram economias significativas. Aqui está uma lista de verificação rápida de vitórias táticas.

1. Ajuste automático dinâmico do tamanho do lote

• A tática: Faça com que a estrutura teste a VRAM na inicialização e escolha automaticamente o maior tamanho de lote seguro.
• Melhor para: Clusters de GPU compartilhados (Kubernetes/Slurm) onde a memória livre oscila muito.
• Atenção: Pode quebrar SLAs de streaming em tempo real alterando a duração da etapa.

2. Perfil contínuo

• A tática: Execute profilers leves (PyTorch Profiler, NVIDIA Nsight) por alguns segundos por época.
• Melhor para: Trabalhos longos (>30 minutos). Encontrar até mesmo um ponto de acesso de 5% compensa as despesas gerais do criador de perfil em um dia.
• Atenção: Trabalhos vinculados a E/S. Se a utilização da GPU for <20%, um criador de perfil não ajudará; corrija seu pipeline de dados primeiro.

3. Armazene tensores com meia precisão

• A tática: Salve pontos de verificação e ativações no FP16 (em vez do padrão FP32).
• Melhor para: Grandes incorporações estáticas (visão, texto). Reduz pela metade o volume de E/S e os custos de armazenamento.
• Atenção: Cargas de trabalho de conformidade que exigem auditoria com bit exato.

4. Treinamento de CPU na fase inicial

• A tática: Execute a primeira época em CPUs mais baratas para detectar bugs grosseiros antes de alugar GPUs.
• Melhor para: Pipelines complexos com análise pesada de texto ou decodificação JSON.
• Atenção: Conjuntos de dados minúsculos em que o tempo de transferência de dados excede o tempo de computação.

5. Aumento offline

• A tática: Pré-calcule transformações pesadas (Mosaic, Style Transfer) e armazene-as, em vez de computar em tempo real.
• Melhor para: Transformações pesadas que levam >20 ms por amostra.
• Atenção: Pesquisa que estuda aleatoriedade de aumento; assá-lo remove a variabilidade.

6. Alertas e painéis de orçamento

• A tática: Transmita métricas de custo por execução e alerte quando a taxa de queima exceder um limite.
• Melhor para: Organizações com várias equipes para evitar cobranças “descontroladas”.
• Atenção: Alerta de fadiga. Se você enviar ping aos pesquisadores com muita frequência, eles ignorarão as notificações.

7. Arquivar artefatos obsoletos

• A tática: Mova automaticamente pontos de verificação com mais de 90 dias para armazenamento refrigerado (camada Glaciar/Arquivo).
• Melhor para: Projetos maduros com centenas de execuções experimentais.
• Atenção: Certifique-se de manter os pesos “Padrão Ouro” no armazenamento quente para inferência.

8. Desduplicação de dados

• A tática: Remova amostras quase duplicadas antes do treinamento.
• Melhor para: Web scrapes e registros brutos de sensores.
• Atenção: Conjuntos de dados médicos/jurídicos selecionados onde “duplicatas” podem, na verdade, ser casos extremos críticos.

9. Padrões de precisão mista para todo o cluster

• A tática: Aplique o FP16 globalmente por meio de variáveis ​​de ambiente para que ninguém “esqueça” o botão mais barato.
• Melhor para: Equipes de MLOps gerenciando frotas multilocatárias.
• Atenção: Modelos legados que podem divergir sem ajustes específicos.

10. Pesquisa de arquitetura neural (NAS)

• A tática: Automatize a busca por arquiteturas eficientes em vez de ajustes manuais.
• Melhor para: Modelos de produção de longo prazo onde a eficiência rende dividendos ao longo dos anos.
• Atenção: Custo inicial de computação extremamente alto; só valerá a pena se o modelo for implantado em grande escala.

Você não precisa esperar por uma alocação H100 para tornar sua pilha de IA eficiente. Ao implementar precisão mista, otimizar seu feed de dados e adicionar redes de segurança operacional, você pode reduzir drasticamente sua pegada de carbono e sua conta de nuvem.

A estratégia de IA mais sustentável não é comprar mais energia, mas desperdiçar menos daquilo que já se tem.

Este artigo foi publicado como parte da Foundry Expert Contributor Network.
Quer participar?