Impactos Ambientais

Impactos ambientais são uma parte cada vez mais importante da IA Responsável (Responsible AI): sistemas modernos de aprendizado de máquina (machine learning) consomem energia e água durante o treinamento (training) e a implantação (deployment), e dependem de infraestrutura física (chips, servidores, centros de dados (data centers)) com pegadas reais ao longo do ciclo de vida (lifecycle). Esses impactos não são uniformes — dois modelos com acurácia semelhante podem ter demandas de recursos muito diferentes dependendo da arquitetura (architecture), da estratégia de treinamento, do hardware, da localização e de quão amplamente o modelo é usado.

Este artigo explica os principais caminhos de impacto, como estimá-los e reportá-los, e estratégias práticas para reduzir custos ambientais sem sacrificar a utilidade.

Por que os impactos ambientais importam em IA

Os impactos ambientais da IA aparecem de três formas interconectadas:

  • Impactos operacionais: eletricidade usada para treinar e executar modelos, além de resfriamento e uso de água associado.
  • Impactos do ciclo de vida: emissões e uso de recursos da fabricação de hardware, construção de centros de dados e descarte/reciclagem de equipamentos.
  • Efeitos no nível do sistema: mudanças em demanda e comportamento (ex.: um “efeito rebote (rebound effect)”, em que inferência mais barata leva a muito mais uso).

Esses são impactos sociais: afetam metas climáticas, estresse hídrico local, poluição do ar (dependendo da rede elétrica) e cadeias de suprimento de minerais críticos. Eles também criam trade-offs com outras prioridades de IA Responsável (por exemplo, executar mais avaliações de segurança aumenta o cômputo (compute)).

De onde vêm os impactos ao longo do ciclo de vida de ML

Treinamento (incluindo experimentação)

O treinamento costuma ser o custo mais visível para modelos de fronteira (frontier models), mas em muitos projetos do mundo real o maior custo não é a execução final — é a soma de:

Uma implicação prática: reduzir treinamento “desperdiçado” (varreduras mal planejadas, baixa utilização (utilization), execuções desnecessárias) pode importar tanto quanto melhorar a eficiência do modelo.

Inferência e implantação

Para sistemas amplamente usados — recomendação, ranqueamento de busca, predição de anúncios, chatbots — a inferência (inference) pode dominar ao longo do tempo. Os impactos escalam com:

  • número de requisições / tokens (tokens) gerados
  • metas de latência (latency) (latência rígida pode reduzir o agrupamento (batching) e prejudicar a eficiência)
  • tamanho do modelo e estratégia de decodificação
  • cache (caching) e reutilização
  • hardware de serving e utilização (servidores ociosos ainda consomem energia)

A eficiência de inferência é, portanto, tanto um custo quanto um tema de sustentabilidade.

Pipelines e armazenamento de dados

Mesmo quando o cômputo do modelo é modesto, a engenharia de dados pode ser significativa:

  • computação contínua de features
  • jobs de ETL em larga escala
  • data warehouses sempre ligados
  • armazenamento e replicação de longo prazo

Ciclo de vida de hardware e infraestrutura

A eletricidade operacional é apenas parte do quadro. O hardware tem impactos incorporados (emissões de fabricação, água, químicos, impactos de mineração). Centros de dados exigem concreto, aço, energia de backup e sistemas de resfriamento.

Em ciclos curtos de renovação de hardware (por exemplo, substituir GPUs a cada 2–4 anos), impactos incorporados podem representar uma parcela substancial da pegada total.

Fundamentos: de cômputo a energia e a emissões

Cômputo não é energia

Artigos de ML frequentemente reportam cômputo em operações de ponto flutuante (FLOPs), horas de GPU (GPU-hours) ou passos de treinamento (training steps). Os impactos ambientais dependem de como o cômputo se traduz em eletricidade, o que depende de:

  • tipo de acelerador (accelerator) e consumo de potência (power draw) (por exemplo, uma GPU com TDP de 400–700W, muitas vezes menor/maior na prática)
  • utilização (uma GPU meio ociosa ainda consome muita energia)
  • sobrecarga de memória e interconexão (modelos grandes podem ser limitados por largura de banda (bandwidth-bound))
  • sobrecarga do centro de dados (resfriamento, conversão de energia), capturada por PUE

Métricas-chave

Energia (kWh)

Uma aproximação comum:

  • Energia de TI ≈ potência média do dispositivo (kW) × tempo de execução (horas) × número de dispositivos
  • Energia da instalação ≈ energia de TI × PUE (Eficácia do Uso de Energia (Power Usage Effectiveness))

PUE é definido como:

  • PUE = energia total da instalação / energia do equipamento de TI
  • Centros de dados de referência podem se aproximar de ~1.1; instalações mais antigas ou menores podem ser bem mais altas.

Emissões de carbono (kgCO₂e)

As emissões dependem da intensidade de carbono (carbon intensity) da eletricidade:

  • Emissões (kgCO₂e) = energia (kWh) × intensidade de carbono (kgCO₂e/kWh)

A intensidade de carbono varia dramaticamente por região e hora do dia. Usar valores médios anuais é comum, mas a contabilização alinhada no tempo (time-matched) pode ser mais precisa (e pode incentivar agendar trabalho quando a rede elétrica está mais limpa).

Uso de água (litros)

Impactos de água vêm de duas fontes:

  • Uso direto de água no centro de dados (especialmente resfriamento evaporativo).
  • Uso indireto de água na geração de eletricidade (usinas térmicas frequentemente usam água; fontes renováveis diferem).

Alguns operadores reportam WUE (Eficácia do Uso de Água (Water Usage Effectiveness)):

  • WUE = uso anual de água do site / energia de TI (L/kWh)

WUE varia por clima, projeto de resfriamento e restrições hídricas locais. Importante: escassez de água é local, então litros não são igualmente prejudiciais em todos os lugares.

Estimativa prática: uma abordagem simples

Você pode estimar energia e emissões usando consumo de potência e tempo de execução medidos (ou assumidos). Quanto mais você puder medir diretamente (por exemplo, telemetria de potência do nó (node power telemetry)), melhor.

Exemplo: estimar energia e emissões de treinamento a partir de horas de GPU

def estimate_energy_emissions(
    num_gpus: int,
    avg_gpu_power_w: float,
    hours: float,
    pue: float = 1.2,
    carbon_intensity_kg_per_kwh: float = 0.4,
):
    """
    Rough estimate of facility energy (kWh) and emissions (kgCO2e).

    avg_gpu_power_w should reflect *average* draw, not peak TDP.
    carbon_intensity_kg_per_kwh is location- and time-dependent.
    """
    it_kwh = (num_gpus * avg_gpu_power_w * hours) / 1000.0
    facility_kwh = it_kwh * pue
    kg_co2e = facility_kwh * carbon_intensity_kg_per_kwh
    return facility_kwh, kg_co2e

kwh, kg = estimate_energy_emissions(
    num_gpus=64,
    avg_gpu_power_w=450,
    hours=24,
    pue=1.2,
    carbon_intensity_kg_per_kwh=0.35,
)

print(f"Estimated energy: {kwh:.0f} kWh")
print(f"Estimated emissions: {kg:.0f} kgCO2e")

O que isso faz bem

  • Produz uma estimativa auditável de ordem de grandeza
  • Destaca os maiores fatores: utilização/potência, tempo de execução, PUE, intensidade da rede elétrica

O que isso não cobre

  • potência de CPU/rede/armazenamento (pode ser não trivial)
  • ineficiências multi-nó (por exemplo, escalabilidade ruim aumenta o tempo)
  • intensidade de carbono variável no tempo
  • emissões incorporadas do hardware

Para melhorar o acompanhamento, equipes frequentemente integram ferramentas que registram tempo de execução e estimam emissões (por exemplo, abordagens ao estilo CodeCarbon) ou usam painéis de carbono do provedor de nuvem (cloud provider carbon dashboards). Trate isso como estimativas e documente as suposições.

Impactos de treinamento na prática

Por que modelos grandes podem ser especialmente caros

Muitos modelos de alta capacidade (notavelmente sistemas baseados em Arquitetura Transformer (Transformer Architecture)) escalam o cômputo de treinamento com:

  • contagem de parâmetros
  • comprimento de sequência
  • número de tokens de treinamento
  • sobrecarga de otimizador/memória
  • ineficiências de treinamento distribuído

Leis de escalonamento (scaling laws) (veja Leis de Escalonamento) mostram que ganhos de desempenho frequentemente seguem retornos decrescentes: cada unidade adicional de cômputo gera melhorias menores. Isso cria uma questão natural de sustentabilidade: o ganho marginal de qualidade vale a pegada marginal?

Experimentação é frequentemente o multiplicador oculto

Uma única execução “final” de treinamento pode representar apenas uma fração do cômputo total se uma equipe faz:

  • dezenas de testes de HPO
  • reconstruções repetidas do conjunto de dados
  • execuções extensas de depuração em clusters grandes

Mitigações incluem:

  • usar modelos proxy menores para exploração inicial
  • parada antecipada (early stopping) agressiva para testes ruins de HPO
  • acompanhar orçamentos de experimentos (o “gasto” de cômputo) como orçamentos financeiros

Impactos de inferência: eficiência em escala

A energia de inferência está fortemente acoplada à vazão (throughput) e às restrições de latência.

Conceitos-chave de serving que afetam a pegada

  • Agrupamento: Batches maiores melhoram a utilização do acelerador (mais tokens/s/W), mas aumentam a latência.
  • Cacheamento: Reutilizar computações anteriores (por exemplo, caches de prompt ou de vetores de incorporação (embeddings)) evita trabalho repetido.
  • Cache de KV (KV caching) (para transformers): Reduz recomputação durante a decodificação autorregressiva (autoregressive decoding), mas aumenta o uso de memória.
  • Decodificação especulativa (speculative decoding): Usa um modelo pequeno “rascunho” para reduzir etapas caras de um modelo grande.
  • Roteamento / esparsidade (sparsity): Mistura de Especialistas (Mixture of Experts) ativa apenas partes de um modelo por token. (MoE)
  • Escolha do modelo: Um modelo menor, ajustado por ajuste fino (fine-tuning) para uma tarefa, pode superar um modelo geral maior tanto em custo quanto em pegada.

Exemplo prático: reduzir a pegada com arquiteturas apropriadas à tarefa

Em vez de responder toda consulta do usuário com um grande modelo generativo, uma aplicação pode:

Isso pode reduzir tokens gerados e o cômputo total, ao mesmo tempo em que melhora a confiabilidade.

Impactos de água: o que saber e o que medir

O uso de água é frequentemente ignorado porque é menos visível do que eletricidade, mas importa para:

  • regiões propensas a seca
  • comunidades competindo por água limitada
  • impactos ecológicos locais

Água direta vs indireta

  • Água direta: Usada no local para resfriamento (comumente resfriamento evaporativo em alguns climas).
  • Água indireta: Água usada na produção da eletricidade consumida pelo centro de dados.

Um centro de dados pode reduzir água direta via diferentes projetos de resfriamento, mas pode aumentar o uso de eletricidade (e, portanto, água indireta) dependendo do clima e do mix da rede elétrica. A melhor estratégia é específica do local.

Orientação prática de reporte

Se possível, reporte:

  • região do centro de dados (ou região de nuvem)
  • abordagem de resfriamento (se conhecida)
  • WUE ou intensidade de água estimada
  • se a água vem de bacias sob estresse (quando disponível)

A contabilização de água ainda está amadurecendo, então transparência sobre suposições é essencial.

Impactos de ciclo de vida: além da energia operacional

Emissões incorporadas e uso de recursos

Impactos de ciclo de vida incluem:

  • mineração e refino (cobre, alumínio, terras raras)
  • fabricação de semicondutores (energia, água, químicos de processo)
  • manufatura de servidores e equipamentos de rede
  • construção de centros de dados (concreto e aço são intensivos em carbono)
  • lixo eletrônico e reciclagem

Esses impactos normalmente são amortizados ao longo da vida útil do equipamento. Estender a vida do hardware e aumentar a utilização pode reduzir o impacto incorporado por unidade de trabalho do modelo.

Por que utilização é um tema ambiental

Servidores ociosos ou subutilizados “desperdiçam” carbono incorporado porque:

  • você pagou a pegada de fabricação independentemente do uso
  • o equipamento envelhece e fica obsoleto com o tempo

Melhor escalonamento de cluster, maior utilização média e compartilhamento de infraestrutura entre cargas de trabalho podem reduzir o impacto de ciclo de vida por tarefa.

Armadilhas e equívocos comuns

“Usamos energia renovável, então as emissões são zero”

Muitas organizações compram créditos de energia renovável (renewable energy credits, RECs) ou assinam contratos de compra de energia (power purchase agreements, PPAs). Isso pode ajudar a descarbonizar redes elétricas, mas afirmações de “zero” dependem de:

  • adicionalidade (a compra causou nova geração limpa?)
  • correspondência de tempo e local (correspondência 24/7 é mais rigorosa do que correspondência anual)
  • restrições da rede (energia limpa pode ser cortada (curtailed) ou exportada)

Compensações (offsets) podem ter um papel, mas não substituem reduzir a demanda real de energia.

“Treinamento é a única coisa que importa”

Para sistemas voltados ao consumidor em escala massiva, inferência frequentemente domina. Para modelos internos de analytics, pipelines de dados podem ser comparáveis. Sempre avalie o ciclo de vida completo e o uso esperado.

“Eficiência sempre vence”

Melhorias de eficiência podem disparar efeitos rebote: se a inferência fica mais barata, o uso pode crescer mais rápido, aumentando a pegada total. Planejamento responsável considera tanto a eficiência por requisição quanto a demanda total.

Estratégias para reduzir impactos ambientais

1) Medir e definir orçamentos

  • Acompanhe horas de GPU, kWh e (estimados) kgCO₂e por projeto.
  • Defina orçamentos de experimentos e exija justificativa para grandes varreduras.
  • Reporte suposições na documentação (por exemplo, Cartões de Modelo (Model Cards) ou documentação do sistema).

2) Reduzir cômputo de treinamento preservando qualidade

Técnicas comuns incluem:

3) Tornar a inferência mais barata e mais limpa

  • Use modelos menores ou especializados quando possível.
  • Faça cache de vetores de incorporação, resultados de recuperação e prompts repetidos.
  • Use agrupamento e serving otimizado para vazão quando a latência permitir.
  • Considere MoE ou roteamento para evitar executar o maior modelo para cada requisição.
  • Reduza o tamanho da saída (por exemplo, padrões “seja conciso”) quando apropriado — o comprimento de geração afeta diretamente o custo.

4) Melhorar a eficiência da infraestrutura

  • Escolha regiões com menor intensidade de carbono quando as restrições permitirem.
  • Agende grandes execuções de treinamento para horas em que a rede esteja mais limpa (quando houver ferramentas para isso).
  • Mire alta utilização; evite frotas sempre ligadas e subcarregadas.
  • Prefira aceleradores eficientes para a carga de trabalho e mantenha as pilhas de software otimizadas.

5) Considerar água e localidade

  • Evite regiões sob estresse hídrico para nova capacidade quando possível.
  • Favoreça estratégias de resfriamento apropriadas ao clima e à disponibilidade de água.
  • Trate “litros usados” como dependentes de contexto — escassez local importa.

6) Incluir pensamento de ciclo de vida em compras e governança

  • Estenda a vida útil do hardware quando viável; reaproveite aceleradores mais antigos para inferência menos exigente.
  • Exija que fornecedores forneçam divulgações de ciclo de vida (carbono incorporado, programas de reciclagem).
  • Integre revisão ambiental a processos mais amplos de Governança de IA (AI Governance).

Como é um “bom” reporte ambiental

Uma divulgação robusta tipicamente inclui:

  • Descrição da carga de trabalho: treinamento vs inferência, níveis de uso esperados
  • Hardware: tipo de acelerador, quantidade e tempo de execução
  • Fatores do centro de dados: região, PUE estimado (ou reportado pelo provedor)
  • Intensidade de carbono da eletricidade: fonte e se é alinhada no tempo
  • Considerações de água: WUE ou notas qualitativas sobre resfriamento/água se dados quantitativos não estiverem disponíveis
  • Incerteza e suposições: faixas e o que foi excluído (por exemplo, emissões incorporadas)

O objetivo não é precisão perfeita — é comparabilidade, responsabilização e melhores decisões.

Checklist: ações práticas para equipes

  • Defina um orçamento de cômputo/emissões para experimentos e faça valer.
  • Prefira baselines menores e estudos de escalonamento antes de se comprometer com execuções grandes.
  • Acompanhe utilização; otimize pipelines de entrada para evitar travamentos do acelerador.
  • Reduza carga de inferência com roteamento, cacheamento e saídas mais curtas.
  • Escolha regiões de implantação com redes mais limpas quando viável.
  • Documente estimativas e suposições em um relatório do modelo/sistema.
  • Reavalie a pegada após o lançamento — o uso real frequentemente difere das previsões.

Impactos ambientais não são um motivo para evitar IA; são um motivo para tratar cômputo, água e hardware como restrições de projeto de primeira classe. Quando bem feito, trabalho de sustentabilidade frequentemente melhora custo, confiabilidade e escalabilidade, além de reduzir emissões e estresse hídrico.