CDMS | Watts Behind the Weights: para onde vai a energia do treino de IA
Todos os modelos de IA assentam em eletricidade. Segundo a Agência Internacional de Energia, os centros de dados consumiram cerca de 415 TWh em 2024, aproximadamente 1,5% do consumo mundial de eletricidade. Até 2030, prevê-se que esse valor mais do que duplique, para cerca de 945 TWh, um pouco mais do que o Japão consome atualmente, sendo a IA o principal motor deste aumento (IEA, 2025).
No CDMS (Claim Denials Management Solution), a IA está no centro do sistema: os modelos preveem quais as claims de saúde com maior probabilidade de serem recusados, mapeiam a forma como os códigos de procedimentos interagem entre si e estimam que intervenções alteram efetivamente o resultado.
À medida que o projeto entra na sua fase final, surge uma segunda questão, a par daquilo que estes modelos conseguem explicar: em termos de consumo energético, quanto custa treiná-los e onde é que esse custo é efetivamente gerado?
A maioria dos estudos responde à primeira parte com um único número: a energia consumida numa execução completa de treino. Esse número esconde quase tudo. Treinar um modelo num supercomputador é um ciclo de vida, não um evento: conjuntos de dados e modelos são descarregados, preparados, carregados em memória, processados em GPUs, guardados em checkpoints, validados e, no final, transferidos para fora. Cada passo solicita componentes de hardware diferentes e consome energia de forma distinta.
É esta a lacuna que o estudo “Watts Behind the Weights: Characterizing Energy Consumption of the AI Training Lifecycle in HPC”, desenvolvido por investigadores do INESC TEC e da Universidade do Minho no âmbito do CDMS, procura colmatar. O trabalho foi realizado no Deucalion, o supercomputador EuroHPC instalado em Portugal. Em vez de medir o treino como um bloco único, a equipa atribuiu a energia a cada fase e evento individual do ciclo de vida. O artigo, da autoria de Alexandre Fernandes, Alícia Oliveira, Beatriz Cepa, Cláudia Brito e Ricardo Macedo, será apresentado nos SC26 Workshops, em Chicago (15 a 20 de novembro de 2026). Tanto quanto é do conhecimento dos autores, trata-se do primeiro estudo a quantificar a energia de cada fase ao longo de todo o ciclo de vida do treino de IA num contexto de HPC, e não apenas da fase de execução.
Então, para onde vai realmente a energia do treino de IA e que parte dela pode ser evitada?
O treino não é um bloco único
Pode parecer abstrato, por isso vamos acompanhar um processo de treino do início ao fim.
Antes de qualquer execução, o utilizador prepara o ambiente. Os conjuntos de dados e os modelos são descarregados de repositórios públicos, como o Hugging Face ou o Kaggle, para o armazenamento partilhado do supercomputador. Este passo decorre num nó de acesso (login node) e a sua velocidade depende sobretudo da rede, e não da capacidade computacional da máquina.
Segue-se a execução, nos nós de computação. Em cada iteração do treino, os dados são lidos do armazenamento para a memória, transferidos para as GPUs e processados através de um forward pass, de um backward pass e de uma atualização dos pesos. Quando se usam várias GPUs, estas têm também de se sincronizar. Periodicamente, o modelo é validado com dados reservados para esse fim e guardado em disco sob a forma de checkpoint, para que o treino possa ser retomado em caso de falha.
Por fim, na fase de pós-execução, o modelo treinado sai da infraestrutura para ser colocado em produção noutro local.
Imagem: Fig. 1 do artigo, ciclo de vida típico do treino de IA em HPC (Fonte: Fernandes et al., SC26 Workshops, © 2026 IEEE)
Para medir cada um destes passos separadamente, a equipa desenvolveu uma ferramenta de monitorização própria que regista o consumo energético do CPU e das GPUs a cada 50 milissegundos e instrumentou o código de treino para identificar o início e o fim de cada fase. Cruzando os dois registos a posteriori, é possível saber quanta energia consumiu cada fase, e não apenas a execução no seu conjunto.
A fase de execução foi testada com duas cargas de trabalho (workloads) deliberadamente distintas, usando quatro GPUs NVIDIA A100 no Deucalion:
ResNet-50, um modelo de classificação de imagem treinado com o ImageNet (167 GB), exigente na leitura de dados (I/O-bound);
Qwen3-8B, um modelo de linguagem de grande escala (LLM) treinado com o WikiText (644 MB), exigente em computação nas GPUs (GPU-bound).
A fase de preparação foi testada separadamente, com 7 conjuntos de dados (de 486 MB a 549 GB) e 5 modelos (de 25,6 milhões a 27 mil milhões de parâmetros). Todos são modelos e conjuntos de dados públicos de referência (benchmarks), escolhidos por representarem perfis típicos de utilização de recursos; nenhuma das experiências utilizou dados de claims do CDMS.
Preparação: pouco por download, muito à escala
Descarregar dados e modelos raramente é contabilizado como parte do treino. Os resultados mostram por que razão é fácil ignorar este passo, e por que razão não se deve fazê-lo.
Tanto a energia como o tempo crescem de forma quase linear com o tamanho. Um modelo maior custa mais a descarregar por ser maior, não por ser mais complexo. E, como estes passos estão limitados pela rede, demoram muito tempo e consomem pouca energia.
Isoladamente e em comparação com a fase de execução propriamente dita, estes valores são insignificantes. O problema está na repetição. Num supercomputador partilhado, os mesmos conjuntos de dados e modelos mais populares são descarregados vezes sem conta por centenas de utilizadores, cada um a pagar o mesmo custo pelos mesmos ficheiros. Uma energia que parece irrelevante em cada download torna-se um custo recorrente, e evitável, à escala da infraestrutura.
Execução: tempo não é energia
Em ambas as cargas de trabalho, o treino domina e a validação acrescenta apenas uma pequena fração. Para além disso, os dois modelos comportam-se de forma muito diferente.
O ResNet-50 distribui a energia entre CPU e GPU: em média, 16% vai para o CPU e 84% para as GPUs, sendo o backward pass o maior consumidor individual. O Qwen3-8B concentra quase tudo nas GPUs, cerca de 92%, no forward pass e no backward pass, nas atualizações dos pesos e na sincronização entre GPUs.
Imagem: Figs. 4 e 5 do artigo, energia e tempo por fase para o ResNet-50 e o Qwen3-8B (Fonte: Fernandes et al., SC26 Workshops, © 2026 IEEE)
O resultado mais revelador está no ResNet-50. A cópia do conjunto de dados para o nó e o carregamento dos dados representam cerca de 39% e 7% do tempo de execução, respetivamente, mas uma parcela muito menor da energia. Ambos os passos correm apenas no CPU, que consome muito menos energia do que uma GPU, enquanto as GPUs ficam paradas. No Qwen3-8B, em que quase todo o tempo e energia se concentram na GPU, tempo e energia acompanham-se de perto.
Por outras palavras, duas fases com duração semelhante podem ter custos energéticos muito diferentes. O tempo de execução, por si só, não é um indicador fiável do consumo energético e nenhuma fase domina em todas as cargas de trabalho. Para saber o que otimizar, a energia tem de ser medida fase a fase, e não execução a execução.
A mesma otimização, resultados diferentes
O estudo testou também duas práticas comuns: onde ficam guardados os dados e se o modelo é guardado em checkpoints. Nenhuma delas tem uma resposta universal.
Armazenamento partilhado vs. disco local. Copiar o conjunto de dados do sistema de ficheiros paralelo partilhado (Lustre) para o disco local do nó é uma forma habitual de acelerar o treino. No ResNet-50, resulta: o armazenamento local poupou 17 minutos e 88 kJ no carregamento de dados durante o treino e 5 minutos e 4 kJ na validação, com menos paragens à espera de dados e GPUs mais ocupadas. Mas a própria cópia tem um custo e, consoante o tamanho do conjunto de dados e o número de épocas (epochs), pode anular o ganho. No Qwen3-8B, o local de armazenamento quase não fez diferença: o WikiText é suficientemente pequeno para caber na memória da GPU depois de lido, e a computação continua a ser o ponto de estrangulamento em qualquer dos casos.
Checkpointing ativo vs. inativo. A intuição diz que guardar mais dados custa mais energia. Os resultados são mais matizados. No ResNet-50, guardar checkpoints no armazenamento partilhado aumentou visivelmente o tempo e a energia, enquanto fazê-lo no disco local teve um impacto mínimo. O Qwen3-8B guarda um checkpoint muito maior, com milhares de milhões de parâmetros e o estado do otimizador, mas o impacto foi mínimo, porque o trabalho das GPUs à sua volta é tão pesado que o checkpoint quase não se nota.
O custo de uma otimização depende menos da sua dimensão do que do seu peso face à fase dominante da carga de trabalho. O que ajuda um modelo exigente em I/O pode ser irrelevante para um modelo exigente em GPU.
Pós-execução: o custo que ninguém reporta
A última fase, o envio do modelo treinado para fora da infraestrutura, comporta-se como o download do modelo: limitada pela rede e executada no CPU. O estudo trata-a como equivalente ao download, em vez de a medir separadamente, mas a conclusão mantém-se: como acontece depois de o treino terminar, fica normalmente de fora dos valores de energia reportados.
Da medição a melhores decisões
A energia do treino de IA não é um número único. Depende do modelo, dos dados, do local onde estes estão guardados e da forma como o pipeline está configurado. Nenhuma fase ou otimização ganha em todas as cargas de trabalho, e mesmo passos menores, como os downloads, acumulam-se num custo real e evitável em infraestruturas partilhadas.
Há uma ressalva importante na leitura dos números: as medições são feitas por software e abrangem apenas CPU e GPU, pelo que subestimam a energia total do sistema. O que preservam são as proporções e as tendências entre fases, que é precisamente o necessário para decidir onde agir.
Os próximos passos do estudo alargam a análise a mais modelos e estratégias de paralelização, a outras plataformas de HPC, ao treino distribuído por vários nós e, mais tarde, ao model serving, a fase em que os modelos treinados são utilizados em produção.
Leia o artigo completo (SC26 Workshops):
Comentários