Pular para conteúdo

Capítulo 7.7 — ML tradicional em escala: treinamento distribuído

🎯 Objetivo

Cobrir, em nível mínimo e útil, as opções de treinamento distribuído e as situações em que isso importa de verdade para um time de produção. Este capítulo não pretende ser manual de distributed training; ele fecha a lacuna entre "treinar modelo tradicional em um laptop" e "treinar/fine-tunar em cluster".

🧠 Quando isso importa

  • Modelos grandes (LLMs open-weight em fine-tuning, alguns modelos de visão e fala) que não cabem em uma única GPU.
  • Datasets grandes onde o tempo de treino em uma máquina é inviável.
  • Throughput de treinamento importa para iteração rápida.

Quando não importa para a maior parte dos times:

  • Modelos clássicos (gradient boosting, linear, redes pequenas).
  • Fine-tuning leve com LoRA/QLoRA em uma GPU.
  • Volume de dado em centenas de MB a poucos GB.

🧠 Conceitos centrais

  • Data parallelism (DP). Cada GPU tem uma cópia completa do modelo; dados são particionados. Gradiente é sincronizado entre GPUs (AllReduce). Mais simples; bate em limite de memória.
  • Model parallelism. O modelo é particionado entre GPUs. Necessário quando o modelo não cabe em uma única GPU.
  • Tensor parallelism (TP). Divide cada tensor em pedaços entre GPUs (por linha/coluna). Boa eficiência intra-nó.
  • Pipeline parallelism (PP). Divide camadas em GPUs sequenciais. Útil para modelos muito profundos; requer cuidado com bubbles de pipeline.
  • ZeRO (Zero Redundancy Optimizer). Particiona estados do otimizador, gradientes e parâmetros entre GPUs, reduzindo a memória por GPU. Implementado em DeepSpeed (estágios 1, 2, 3).
  • FSDP (Fully Sharded Data Parallel, PyTorch). Equivalente conceitual ao ZeRO-3 integrado no PyTorch nativo: parâmetros, gradientes e estados do otimizador são shardeados.
  • Activation checkpointing. Recomputa ativações no backward em troca de menos memória; troca compute por memória.
  • Mixed precision (FP16/BF16 + FP32 master). Reduz memória e acelera com Tensor Cores; padrão em treino moderno.

🧠 Diferença entre treinar modelos grandes e operar modelos clássicos

Operar um classificador clássico em produção é tema de MLOps tradicional: ingestão, features, monitoramento, retraining periódico. O ciclo é mensal/trimestral, com hardware modesto.

Treinar/fine-tunar um modelo grande é tema de infra de treinamento: cluster GPU, schedulers, checkpoints, recovery, custo de hora-GPU. O ciclo é raro (alguns ao ano) e exige time especializado.

Times enterprise que consomem modelos prontos via API geralmente não precisam dessa infraestrutura. Quando precisam, é uma decisão estratégica explícita.

⚠️ Honestidade sobre o escopo

Este livro não pretende substituir as documentações oficiais e materiais especializados em distributed training. O objetivo aqui é fechar a lacuna de vocabulário para que arquitetos não confundam "treinar LLM" com "fine-tunar com LoRA" nem subestimem o custo de infra de cluster.

📚 Referências