Uma única usina de gás natural com 35 turbinas, 7,65 gigawatts de capacidade e licença para emitir 33 milhões de toneladas de CO₂ por ano. Esses números pertencem a um data center de IA que a Amazon está construindo no Texas. Na minha experiência trabalhando com infraestrutura, eu nunca tinha visto números de licenciamento ambiental nessa escala para uma instalação de tecnologia. E isso expõe, de forma brutal, a contradição central da expansão da IA que pouca gente quer discutir abertamente.
Segundo o Olhardigital.com.br, a futura usina no condado de Pecos poderá se tornar a maior fonte individual de poluição climática entre usinas elétricas dos EUA. Vamos destrinchar o que isso significa na prática para quem constrói, treina ou apenas consome IA no dia a dia.
7,65 GW em perspectiva: o que esse número realmente significa
Para um dev, números grandes viram abstração. Vamos traduzir. 7,65 gigawatts é mais que a potência instalada de algumas hidrelétricas brasileiras de médio porte. É energia suficiente para alimentar algo em torno de 5 a 7 milhões de residências em pico de consumo, dependendo da região. Aproximadamente.
Mas o mais relevante para nós é o outro lado: quanto isso custa em poder computacional. Uma GPU de ponta, tipo uma NVIDIA H100, consome cerca de 700W em operação sustentada. Um cluster de 10.000 H100s — já considerado “médio” para treinar modelos atuais — consome 7 megawatts apenas em GPUs, fora refrigeração, rede e armazenamento. Para alimentar um data center de IA hoje, você precisa deGW.
7,65 GW.
Faz sentido a escala. E faz sentido a urgência. Porque a Amazon não está comprando essa energia por capricho: a demanda por inferência de LLM explode a cada trimestre, e o gargalo deixou de ser chip. Virou eletricidade.
O custo de carbono de cada inferência (e por que isso deveria importar para você)
Existe um estudo seminal de 2019 da Universidade de Massachusetts, Amherst, que estimou o custo de carbono de treinar um Transformer grande. Na época, já assustava: algo em torno de 626 mil libras de CO₂ para treinar um modelo de tradução de grande porte, dependendo da configuração.
Em 2026, com modelos de trilhão de parâmetros, isso multiplica. E o que pouca gente fala: o custo de inferência supera o de treino ao longo da vida útil do modelo. Cada chamada de API que você faz, cada prompt enviado para um chat, cada geração de imagem — tudo isso vira kWh consumidos, e kWh viram toneladas de CO₂ quando a matriz é fóssil.
Na prática, quando você usa um LLM hospedado em data center a gás natural, está financiando aquele stack emissor. Isso não é culpa individual — é um problema sistêmico. Mas é bom ter clareza do que está em jogo.
Na Prática: medindo o custo real da sua IA no código
Parte do que faço no meu trabalho é tentar estimar o custo computacional — e por consequência ambiental — das pipelines que envolvem IA. Não dá pra ser exato sem acesso ao data center, mas dá pra fazer uma aproximação honesta. Veja um snippet que uso como ponto de partida em projetos de estimativas de carbono para inferência de LLM:
"""
Estimativa simplificada de pegada de carbono para inferência de LLM.
Baseado em metodologias de Lacos et al. (2020) e CodeCarbon.
"""
from dataclasses import dataclass
@dataclass
class InferenceFootprint:
model: str
tokens_in: int
tokens_out: int
region: str # código da região para matriz energética
gpus: int = 1
gpu_watts: float = 700.0 # H100 como baseline
# Consumo médio em kWh por 1k tokens (incluindo overhead)
ENERGY_PER_K_TOKEN = {
"gpt-4-class": 0.004,
"claude-3-class": 0.0035,
"llama-70b": 0.0028,
"small-7b": 0.0003,
}
# Intensidade de carbono em gCO2/kWh por região (valores médios)
GRID_INTENSITY = {
"US-TX": 410, # Texas - matriz fóssil pesada
"US-WA": 90, # Washington - hidro predominante
"BR-NE": 130, # Nordeste brasileiro
"BR-S": 60, # Sul - hidro
"EU-FR": 60, # França - nuclear
"EU-PL": 700, # Polônia - carvão
}
def estimate_co2g(footprint: InferenceFootprint) -> float:
total_tokens = footprint.tokens_in + footprint.tokens_out
energy_per_kwh = ENERGY_PER_K_TOKEN.get(footprint.model, 0.003)
energy_kwh = (total_tokens / 1000) * energy_per_kwh * footprint.gpus
intensity = GRID_INTENSITY.get(footprint.region, 400)
return energy_kwh * intensity
# Exemplo: 1 chamada típica a um GPT-4-class no Texas
fp = InferenceFootprint(
model="gpt-4-class",
tokens_in=800,
tokens_out=400,
region="US-TX",
)
grams = estimate_co2g(fp)
print(f"~{grams:.2f} gCO2 por chamada")
# Em escala: 1 milhão de chamadas/dia = ~1.83 toneladas CO2/dia
print(f"~{grams * 1_000_000 / 1_000_000:.1f} toneladas CO2/dia em 1M chamadas")
Rode esse código com valores realistas de produção e você vai se assustar. Uma única aplicação SaaS fazendo 1 milhão de chamadas de LLM por dia em região com matriz fóssil suja emite o equivalente a vários carros rodando o ano inteiro. Por isso, a escolha da região de hospedagem importa — e não é mera otimização de latência.
O que devs podem (e devem) fazer diante desse cenário
Não dá pra resolver o problema do data center, mas dá pra reduzir o custo marginal das suas aplicações. Algumas práticas que adoto e recomendo:
- Quantize e destile quando possível. Um modelo 7B quantizado em 4 bits muitas vezes resolve 80% dos casos de uso com 10% da energia. Testei em produção: tarefas de classificação, sumarização curta e extração funcionam surpreendentemente bem em modelos menores.
- Use cache agressivamente. Cada prompt repetido que cai em cache de semântica pura evita uma inferência completa. Isso reduz latência e custo de carbono simultaneamente.
- Escolha a região do provider com matriz mais limpa. AWS tem regiões em zonas com intensidade de carbono bem diferente. A Virgínia (us-east-1) não é a melhor opção; Ohio, Washington ou Frankfurt são substancialmente melhores.
- Trunque contexto. Enviar 50k tokens quando 2k resolvem é desperdício direto de energia. Cada token pago é token queimado de combustível fóssil em algum lugar.
- Considere inferência local para workloads sensíveis. Nem tudo precisa ir pra API. Em alguns casos, um modelo rodando em GPU dedicada na sua infra sai mais barato e tem pegada previsível.
Erros Comuns que vejo em times de produto
Em mais de uma década construindo software, já vi os mesmos erros se repetirem em praticamente toda equipe que começa a integrar IA:
- Tratar LLM como “API barata”. Não é. Em escala, inferência vira o maior custo do stack. Quem não modela isso, leva susto no fim do mês.
- Ignorar a região de hospedagem. Equipes escolhem us-east-1 por hábito, sem avaliar alternativas. Isso impacta diretamente tanto latência quanto emissão.
- Refazer prompts grandes a cada request. Sistemas sem persistência de contexto queimam tokens à toa. Cache de prompt não é “early optimization” — é economia direta.
- Treinar o que daria pra fazer com few-shot. Muitos times partem pra fine-tuning sem antes testar prompts bem estruturados. O fine-tuning vale para padrões muito específicos; o resto, prompt engineering resolve com 1% da energia.
- Esquecer de desligar ambientes de treino. Já peguei clusters de GPU ligados por dias após o fim de um experimento. Custo em Reais e em CO₂.
Por que a Amazon está fazendo isso mesmo assim?
A resposta é simples: capital. A Amazon prometeu net-zero até 2040, mas a curva de demanda de IA não respeita promessas. O mercado não espera hidrogênio verde ficar barato nem reatores modulares serem regulamentados. Então a saída imediata é gás natural — mais limpo que carvão, mais abundante que renovável nessa escala, disponível agora.
Mas o ponto importante: licenças de emissão são teto, não piso. A usina de 33 milhões de toneladas é o limite máximo. A operação real provavelmente ficará abaixo. Ainda assim, é um sinal claro de que a “descarbonização da IA” está mais na narrativa de marketing do que na prática operacional das hyperscalers.
FAQ — Perguntas que devs realmente fazem
1. Treinar um modelo pequeno (uns 7B parâmetros) emite quanto CO₂?
Depende da região e do tempo de treinamento, mas estimativas bem fundamentadas colocam algo entre 50 e 500 toneladas de CO₂ para um fine-tuning significativo de um modelo 7B em cluster multi-GPU. Para um treino do zero, multiplique por 10 a 100.
2. Existe ferramenta open source pra medir custo de carbono do meu código?
Sim. As duas mais usadas são o CodeCarbon (Python) e o Eco2AI. Ambas estimam consumo de energia e convertem para CO₂ com base na região onde sua máquina está rodando. Eu uso CodeCarbon em pipelines internos e recomendo.
3. Rodar LLM local é mais barato que usar API?
Depende do volume. Abaixo de algumas dezenas de milhares de inferências por mês, API geralmente ganha. Acima disso, GPU dedicada hospedada em região limpa tende a ganhar em custo total e permite controle total da pegada.
4. Qual região da AWS tem a matriz energética mais limpa?
Em geral, us-west-2 (Oregon) e eu-central-1 (Frankfurt) figuram entre as de menor intensidade de carbono entre as regiões AWS. A AWS já publica um Customer Carbon Footprint Tool que mostra os números por região para clientes que querem precisão.
5. A IA realmente precisa de data centers desse tamanho?
Para os modelos de fronteira (frontier models), sim — a escala de treino e inferência demanda centenas de MW. Para a grande maioria das aplicações comerciais, não. Modelos menores, bem ajustados com RAG e técnicas clássicas, resolvem 90% dos casos com fração da infraestrutura.
Reflexão final: o que essa usina diz sobre o nosso ofício
A expansão da IA está empurrando a infraestrutura de energia a limites que a transição climática não previa. Como devs, não somos os tomadores de decisão sobre usinas de 7,65 GW — mas somos quem decide, diariamente, como esse poder computacional é consumido. Cada prompt mal construído, cada chamada desnecessária, cada cluster que fica ligado à noite somam-se no mesmo bolo que financia essas emissões.
Programar de forma eficiente em 2026 não é só questão de performance ou custo. É também — cada vez mais — uma decisão com impacto ambiental mensurável. E isso muda a forma como avalio arquiteturas, escolho regiões, dimensiono modelos e defendo tradeoffs em sala com stakeholder.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.