Pesquisa usa reinforcement learning para cortar energia em treino de IA

Controlador adapta geração de tokens à potência medida e reduz violações de limite em até 89,8% em GPUs A100

Por Redação Mapa Paper13 ago 2026
Pesquisa usa reinforcement learning para cortar energia em treino de IA

O que aconteceu

Um paper disponibilizado no arXiv (2608.11226v1), na área de cs.AI, descreve um método para controlar o consumo de energia de treinamento de LLMs usando reinforcement learning. Os autores instrumentaram treino GRPO com telemetria de potência em intervalos de meio segundo, em escalas de 7B, 14B e 72B de parâmetros, em uma a quatro GPUs A100, com mais de 380 mil amostras.

Sobre essa base, treinaram um meta-controlador PPO que ajusta os próprios parâmetros de geração do workload com base na potência medida. No traço completo de 500 passos da escala 7B, o controlador reduziu as violações de limite de energia em 89,8%, aumentou a produção de tokens em 18,1% e melhorou a eficiência energética em 26,2% (tokens por MWh).

A implantação ao vivo na escala 72B, porém, não repetiu o resultado: o estudo relata resultados nulos replicados, diagnosticados como perda de autoridade do atuador de group size sob model sharding. Quando os mesmos parâmetros foram aplicados como concorrência de geração, a autoridade de energia subiu para 17-22%, isolando um princípio de ocupação versus volume.

Contexto

O pós-treinamento com reinforcement learning domina o desenvolvimento atual de modelos de linguagem, mas seu comportamento de consumo de energia em GPUs não havia sido caracterizado. Datacenters, segundo o paper, gerenciam potência com mecanismos cegos ao workload: limites estáticos e throttling reativo, que desaceleram o hardware de forma indiscriminada.

O estudo parte justamente dessa lacuna: em vez de travar a GPU, o controlador ajusta como o próprio workload gera tokens para se manter dentro do orçamento de energia.

Por que importa

O consumo de energia é um dos maiores custos operacionais de datacenters que treinam modelos de grande porte. Um controlador que reduz violações de limite sem sacrificar throughput permite operar hardware com menos folga de capacidade, sem precisar de novas infraestruturas — algo relevante também para o Brasil, onde a expansão de capacidade de nuvem e IA esbarra em restrições de energia e prazos de conexão à rede.

Os números da escala 7B mostram que é possível ganhar eficiência e produção ao mesmo tempo. Na escala 72B, o controlador reconstruído entregou 35,7% mais output que uma linha de base estática segura, com 2,27% ± 1,08% de violações de orçamento — 87,2% menos violações que a operação sem controle.

Impacto

Sob janelas de medição realistas, os transitórios de energia na escala 72B caem de 23,6% em resolução de meio segundo para 1,6% em janelas de 30 segundos e zero em cinco minutos. Em uma frota composta de 16 GPUs, o estudo registrou zero violações em janelas de 30 segundos ou mais, com pico de demanda entre 50% e 56% da capacidade nominal (nameplate).

Com essa margem, os autores estimam que uma oversubscription de aproximadamente 2x da capacidade nominal é viável para essa composição de frota, sujeita a validação pelo operador. O paper também quantifica consequências econômicas e de carbono da abordagem.

O que muda

A proposta troca o controle de energia reativo e padronizado por um controle orientado ao workload, que decide no nível da geração de tokens. Para operadores, isso abre caminho para aproveitar melhor a capacidade instalada antes de comprar mais GPUs ou ampliar contratos de energia.

O que vem agora

O próprio estudo especifica um piloto de baixo custo para operadores validarem a técnica em ambiente de produção. Restam questões abertas sobre o comportamento do controlador em outras arquiteturas de GPU, em frotas maiores e em workloads com dinâmica diferente — e a necessidade de validar a oversubscription de 2x apontada pelos autores.

Fontes

  • arXiv cs.AI — Cutting AI Datacenter Energy with Reinforcement Learning: Measured Power Control of LLM Training from One GPU to the Fleet (arXiv:2608.11226v1) — https://arxiv.org/abs/2608.11226