Impacto ambiental da IA: como devs medem emissões com codecarbon

Centros de dados de IA estão sendo rejeitados pelas comunidades locais, e isso afeta diretamente a infraestrutura que sustentam o nosso trabalho. A Apple aprendeu isso na pele em 2015, quando tentou erguer um complexo de US$ 1 bilhão em Athenry, na Irlanda. Segundo o Sapo.pt, a empresa não antecipou a resistência que viria — e isso é apenas o começo. Na minha experiência como dev, vejo colegas ignorarem completamente o impacto físico do que programam. Esse artigo é sobre o que está acontecendo, por que importa para nós, e o que podemos fazer a respeito.

O que realmente aconteceu em Athenry — e por que esse caso importa

A Apple prometeu maravilhas em Athenry: energia 100% renovável, reflorestação com espécies locais, espaços educativos. Tudo greenwashing bonito no papel. Mas os residentes da pacata vila irlandesa fizeram o que a maioria das pessoas em 2015 não fazia: questionaram os números. Poluição sonora, perturbação luminosa, risco de cheias, impacto na fauna — reclamações que soam técnicas, mas que tocam num ponto nevrálgico.

Na minha visão, o caso Athenry é um divisor de águas. Foi um dos primeiros exemplos onde uma comunidade organizada usou legislação ambiental, planejamento urbano e pressão pública para travar um projeto bilionário de uma Big Tech. O resultado? O projeto foi suspenso indefinidamente em 2018 após anos de batalhas legais. A Apple recuou silenciosamente.

Desde então, o padrão se repetiu: Microsoft em Iowa, Meta na Louisiana, Google em países nórdicos. Cada vez que uma comunidade percebe que vai arcar com o custo ambiental de treinar o próximo GPT, aparece resistência. E essa resistência está escalando.

Os números reais que ninguém quer ver

Aqui é onde a conversa fica desconfortável para nós, devs. A indústria de IA é, sem exagero, uma das maiores consumidoras de recursos naturais da história da computação. Alguns dados que costumo citar quando levo esse tema a sério:

Treinamento de modelos grandes: O GPT-3 consumiu cerca de 1.287 MWh para treinar — equivalente ao consumo anual de 121 casas americanas. O GPT-4 e modelos posteriores multiplicam isso por ordens de magnitude.
Uma única query: Uma consulta ao ChatGPT consome aproximadamente 10x mais energia que uma busca no Google. Multiplique isso por bilhões de requests diários.
Água para refrigeração: Sistemas tradicionais de cooling usam entre 1 a 2 litros de água por kWh. Treinar um modelo grande pode evaporar milhões de litros.
Projeção global: Centros de dados consomem hoje cerca de 1,5% da eletricidade mundial. Estimativas da IEA projetam 8% até 2030 se o crescimento continuar nesse ritmo.

Quando você usa a API da OpenAI ou faz deploy de um modelo Llama no seu backend, está consumindo uma fração disso. Mas fração de algo gigantesco ainda é algo significativo. E as comunidades ao redor desses data centers estão começando a fazer as contas.

Por que isso importa para quem programa

A questão não é só filosófica. Tem implicações práticas imediatas no nosso trabalho:

Custo de inferência: Se a regulamentação ambiental apertar (e vai apertar), o preço das APIs de IA vai subir. Modelos menos eficientes serão os primeiros a ser taxados.
Latência e soberania: Pressão por data centers locais em cada região. Edge computing deixa de ser luxo e vira necessidade regulatória.
Critérios de contratação: Empresas B2B e consumidores finais vão começar a perguntar sobre o impacto ambiental das soluções de IA. Green software vira diferencial competitivo.
Disponibilidade de modelos: Se data centers grandes forem travados por legislação, sua escolha de modelos hospedados diminui. Modelos pequenos e locais ganham espaço.

Já vi clientes meus repensarem stacks inteiros depois de uma pergunta simples: “quanto de carbono emite esse pipeline de inferência?” Saber responder isso está virando parte do trabalho de quem sênior.

Na Prática: medindo o impacto do seu código de IA

Vamos ao que interessa. Existe uma lib Python chamada codecarbon que rastreia emissões de CO₂ durante execução de código. Funciona estimando consumo de CPU/GPU/RAM e convertendo para kgCO₂eq baseado na matriz energética da região. É uma forma tangível de medir o que seu código de IA custa em termos ambientais.

Passo a passo:

Instale a lib: pip install codecarbon
Adicione o tracker no início do seu script de treino ou inferência
Exporte o resultado para CSV ou dashboard
Compare execuções entre modelos diferentes

Exemplo funcional que adaptei para medir inferência de modelos:

from codecarbon import EmissionsTracker
from transformers import pipeline
import time

# Inicializa o tracker apontando para a região do data center
tracker = EmissionsTracker(
    project_name="llm-inference-benchmark",
    output_dir="./emissions",
    country_iso_code="BRA",  # Matriz energética brasileira
    measure_power_secs=1,
)

# Comparação entre modelos de tamanhos diferentes
modelos = [
    ("distilbert-base-uncased-finetuned-sst-2-english", "Pequeno (66M params)"),
    ("bert-base-uncased", "Médio (110M params)"),
    ("roberta-base", "Médio+ (125M params)"),
]

resultados = []

for model_id, descricao in modelos:
    tracker.start_task(f"inferencia-{model_id}")
    
    classifier = pipeline("sentiment-analysis", model=model_id)
    
    # Simula 1000 inferências para medir custo real
    textos = ["Adorei o produto!" for _ in range(1000)]
    inicio = time.time()
    outputs = classifier(textos)
    duracao = time.time() - inicio
    
    emissions = tracker.stop_task()
    
    resultados.append({
        "modelo": descricao,
        "emissions_kgCO2eq": emissions,
        "throughput": len(textos) / duracao,
        "emissions_per_request": emissions / len(textos),
    })
    print(f"{descricao}: {emissions:.6f} kgCO2eq | {len(textos)/duracao:.1f} req/s")

# Análise comparativa
print("\n--- RESUMO COMPARATIVO ---")
for r in resultados:
    print(f"{r['modelo']}: {r['emissions_per_request']*1e6:.3f} gCO2eq/req")

Esse script mede, em condições reais, quanto cada modelo emite por inferência. Quando rodei em ambiente brasileiro, a diferença entre modelos pequenos e grandes chegou a 40x em emissões por request. Multiplique isso por milhões de chamadas diárias e você tem o tamanho real do problema.

Erros Comuns que devs cometem (e que pagam caro depois)

Depois de anos revisando código e arquiteturas de IA, vejo os mesmos equívocos se repetindo. Anota aí:

Escolher modelo grande por default: Muita gente usa GPT-4 ou Claude Opus para tarefas que o GPT-3.5-turbo ou um modelo local resolveria com 10% do custo ambiental. Sempre faça benchmark antes.
Ignorar batch processing: Inferência em loop com requests unitários é absurdamente ineficiente. Agrupe sempre que possível. Um batch de 32 custa menos — em tempo, dinheiro e emissões — que 32 chamadas individuais.
Não configurar TTL em embeddings: Cálculo de embeddings é caro. Se você recalcula o mesmo embedding várias vezes por não ter cache, está queimando dinheiro e carbono sem necessidade.
Rodar treino em região com matriz energética suja: AWS us-east-1 (Virgínia) tem matriz mais carvão-dependente que eu-west-1 (Irlanda). Mesma conta, impacto 3x maior. Considere região do data center como variável de arquitetura.
Subestimar cooling em deploys on-prem: Quem roda LLM local em servidor próprio ignora que refrigeração pode dobrar o consumo energético total. Hardware eficiente + refrigeração adequada = menos dor de cabeça.
Não questionar vendor lock-in: Dependência 100% de uma API fechada te deixa refém de decisões geopolíticas e ambientais que você não controla. Tenha plano B com modelo open-source.

Arquiteturas mais sustentáveis que valem considerar

Não é só sobre “usar menos”. Existem caminhos técnicos reais que entregam resultado com menos impacto:

Model distillation: Pegar um modelo grande, treinar um menor que imite o comportamento. Você perde 5-10% de qualidade e ganha 10x em eficiência.
Quantização (INT8/INT4): Reduz precisão numérica sem perda significativa de qualidade. Bibliotecas como bitsandbytes e ONNX Runtime facilitam isso.
Edge inference: Rodar modelos diretamente no dispositivo do usuário final. Para apps mobile, isso é quase obrigatório hoje.
Modelos Mixture of Experts (MoE): Ativar apenas parte dos parâmetros por inferência. Mixtral 8x7B, por exemplo, usa só 13B dos 47B por token.
Cache semântico: Antes de chamar a API, verifique se já tem resposta similar cacheada. Reduz drasticamente chamadas redundantes.

FAQ — perguntas reais de devs sobre IA e meio ambiente

1. Realmente faz diferença qual região do data center eu escolho?

Sim. A matriz energética varia drasticamente. Noruega (hidroelétrica) emite ~30g CO₂/kWh. Polônia (carvão) emite ~700g CO₂/kWh. Mesma operação, mais de 20x de diferença em emissões.

2. Como sei se minha empresa precisa se preocupar com isso agora?

Se você atende clientes europeus, sim — a CSRD (Corporate Sustainability Reporting Directive) já exige relatórios ESG detalhados desde 2024. Clientes B2B grandes começam a cobrar. Se é só produto interno americano, ainda tem algum tempo, mas a regulação está chegando.

3. Treinar modelo pequeno próprio compensa versus usar API?

Depende do volume. Faça a conta: custo da API × volume anual vs. custo de treino + infraestrutura. Geralmente, acima de ~500k requests/mês, modelo próprio bem otimizado começa a compensar financeiramente E ambientalmente.

4. Vale a pena usar modelos open-source menores em vez de API paga?

Para tarefas repetitivas e de baixa complexidade, quase sempre vale. Para raciocínio complexo, APIs grandes ainda ganham. Estratégia híbrida (router que decide qual modelo chamar baseado na tarefa) é o sweet spot atual.

5. Green software é marketing ou tendência técnica real?

Os dois. Mas a parte técnica é concreta: existem métricas (SCI — Software Carbon Intensity), ferramentas (codecarbon, Green Software Foundation) e regulamentações que vão tornar isso obrigatório, não opcional.

O que eu espero dos próximos anos

A revolta das comunidades contra centros de dados de IA não é passageira. É sintoma de uma indústria que cresceu sem pedir licença. E, honestamente, parte da responsabilidade é nossa — devs e engenheiros que desenharam esses sistemas sem incluir variável ambiental nas decisões de arquitetura.

Daqui pra frente, otimizar modelo pela métrica de acurácia isolada vai ser tão absurdo quanto otimizar query SQL sem olhar plano de execução. Otimizar considerando energia, emissões e impacto social vai ser o padrão. Quem se preparar agora sai na frente.

O caso da Apple em Athenry mostrou que comunidades organizadas conseguem travar até as maiores Big Techs do mundo. A questão não é “se” a regulação vai apertar, mas “quando”. E quando apertar, quem já tinha o código preparado vai colher os frutos.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Quer ver um benchmark real entre modelos? Posso fazer um post dedicado só a isso.