Em infraestrutura de IA, eletricidade deixou de ser utilitário invisível atrás de uma API. Capacidade da rede, densidade, cooling, carbono, água, aceleradores e prazo de interconexão determinam onde o software roda e quão rápido escala.
A IEA estima cerca de 485 TWh consumidos por data centers em 2025 e projeta aproximadamente 950 TWh em 2030, com instalações focadas em IA crescendo mais rápido. O Departamento de Energia dos EUA aponta que a carga americana pode dobrar ou triplicar até 2028. Isso não significa priorizar carbono sobre confiabilidade; significa que capacity planning não pode assumir compute ilimitado em qualquer lugar.
Uma região pode oferecer APIs cloud e ainda ter quotas de aceleradores, interconexão elétrica limitada, stress da rede, restrições de cooling ou longos prazos de capacidade. A arquitetura precisa modelar isso antes de escolher active-active, frequência de retraining, geografia de inference ou prometer elasticidade ilimitada.
Power Usage Effectiveness compara energia total com energia dos equipamentos de TI. Ajuda a medir overhead de cooling e instalação, mas não revela se o compute gera trabalho útil, se a rede elétrica é intensiva em carbono, quanta água é usada ou quanto carbono incorporado existe em hardware ocioso. A pesquisa 2025 do Uptime Institute mostra pouca mudança no PUE médio pelo sexto ano, escondendo variação por idade, tamanho, clima e região.
Software precisa de um conjunto: PUE, Carbon Usage Effectiveness, Water Usage Effectiveness, utilização, Wh por request ou job, intensidade por tempo e local, qualidade do modelo e unidade funcional. A especificação Software Carbon Intensity da Green Software Foundation, ISO/IEC 21031:2024, organiza carbono operacional e incorporado por unidade funcional.
A computação mais limpa costuma ser a que não acontece. Use cache para resultados reutilizáveis, deduplicação, batching, modelos menores, quantização quando a qualidade permitir, retrieval antes de modelos maiores, limite de tokens, menos retries, melhor utilização e remoção de réplicas ociosas. Isso reduz energia, custo e pressão de capacidade.
Carbon-aware scheduling vem depois de eficiência e correção. Mover um job para região mais limpa pode piorar o sistema se duplicar datasets, manter clusters extras quentes, aumentar rede, reduzir utilização ou criar overhead de resiliência. Calcule a fronteira inteira.
| Workload | Restrições rígidas | Flexibilidade útil | Arquitetura consciente de energia | Falha a evitar |
|---|---|---|---|---|
| Inference interativa | Latência, disponibilidade, privacidade, qualidade e capacidade regional. | Model tier, janela de batching, cache, speculative execution e features opcionais. | Roteie primeiro por SLO; use semantic cache, dynamic batching, fallback eficiente e limites de token. | Mandar usuários para outro continente por carbono e aumentar latência, retries e réplicas. |
| Batch inference | Deadline, residência, modelo aprovado e inputs. | Horário, região, paralelismo, instância e checkpoint. | Desloque tempo ou região contabilizando dados; pause em checkpoints quando capacidade apertar. | Perder prazo porque carbono virou objetivo rígido em vez de input limitado. |
| Treinamento | Topologia, bandwidth, checkpoints, fault tolerance e reprodutibilidade. | Janela, cluster, precisão, batch size, curriculum e early stopping. | Maximize utilização, use janelas de capacidade e carbono, checkpoint seguro e encerre experimentos sem valor. | Otimizar PUE enquanto GPUs esperam dados, sincronização ou jobs quebrados. |
| Retraining e avaliação | Freshness, release gate, dados representativos e compliance. | Frequência, amostra, candidatos, tempo e local. | Dispare por drift relevante, reutilize features e embeddings e avalie por etapas. | Retreinar modelos grandes por calendário sem mudança material. |
| Pipelines de dados | Chegada, consistência, SLA downstream e residência. | Micro-batch, compactação, região e tier de storage. | Reduza scans, particione corretamente, compacte em janelas favoráveis e mova compute para os dados. | Mover terabytes para economizar pouco compute em outro local. |
| Backups e manutenção | RPO, RTO, durabilidade e retenção. | Janela, compressão, verificação e tier. | Agende trabalho flexível em períodos mais limpos ou menos restritos sem quebrar recovery. | Adiar validação até o backup se tornar inútil. |
| CI e desenvolvimento | Feedback crítico, reprodutibilidade e segurança. | Jobs opcionais, testes noturnos, previews e runner. | Cache dependências, cancele builds superseded, hiberne previews e desloque suites extensas. | Manter todos os ambientes de branch e runners acelerados ligados. |
O Carbon Aware SDK da Green Software Foundation permite deslocamento temporal e geográfico por intensidade de carbono. Google Cloud e Microsoft também recomendam esse padrão quando os requisitos permitem. Carbono é um sinal entre SLO, preço, fila, capacidade, dados, água, segurança e prioridade.
Use forecasts com incerteza e fallback. O scheduler deve conhecer último horário de início, distância máxima, budget de transferência, regiões aprovadas, qualidade mínima, custo do checkpoint e quando ignorar o sinal de carbono. Dados stale não podem abandonar produção.
Clientes cloud raramente recebem joules diretos por request. Use proxies transparentes: segundos de acelerador por tipo, CPU, memória, storage, rede, utilização, relatórios do provider, métricas de instalação e intensidade regional. Declare incerteza em vez de inventar precisão.
Associe budgets a produtos e workloads, não só contas de infraestrutura. Reporte por unidade funcional como inference bem-sucedida, mil documentos, treinamento concluído ou cliente ativo. Total menor pode esconder queda de demanda; score por unidade menor pode esconder crescimento de volume. Acompanhe ambos.
Quando energia ou aceleradores ficam escassos, o software precisa de demand shaping: enfileirar jobs, reduzir model tier, cortar contexto opcional, pausar batch, rejeitar experimentos, negociar deadlines ou servir cache. Isso é contrato de produto e API.
Exponha classes como interactive, deadline batch, interruptible e best effort. Permita declarar qualidade mínima, deadline, residência e cache. O scheduler então faz tradeoffs legítimos.
Eu construiria um control plane de placement conectando contratos a inventário de aceleradores, previsão de filas, custo cloud, intensidade da rede, PUE, água, localização dos dados, benchmarks e política de confiabilidade. Ele otimizaria dentro de restrições e registraria por que decidiu.
A visão operacional mostraria trabalho útil por accelerator-hour, energia e emissões com incerteza, trabalho evitado por cache, idle, restrições regionais, risco de deadline, água e efeito marginal de modelos ou scheduling.
Arquitetura consciente de energia não é “rodar tudo na região mais verde”. Reduza demanda, preserve requisitos rígidos, exponha flexibilidade, otimize a fronteira completa e meça energia contra outcomes úteis. Eletricidade vira restrição arquitetural quando o software responde a ela com segurança.
Artigo sobre energia de data centers como restrição de arquitetura, incluindo scheduling de IA, cache, model routing, placement regional, carbono, água e capacidade.