Sua infraestrutura de IA foi planejada para o horário do almoço. E os agentes não almoçam

Quem implanta infraestrutura de IA hoje convive com uma contradição diária: a mesma GPU serve duas tarefas com perfis opostos, e a maioria das empresas planeja as duas com os mesmos critérios. Esse é o erro que está gerando decisões ruins de CAPEX, dashboards que mentem e conversas erradas com produto e finanças.

O treinamento é previsível. Você empurra Dados pelo modelo repetidamente, por semanas ou meses, com utilização de GPU próxima de 100% o tempo todo. Não tem pico, não tem vale. Para quem planeja infraestrutura, é o cenário ideal: data de início, estimativa de duração, orçamento calculável antes de ligar a primeira máquina. É para esse perfil que os provedores de Cloud criaram instâncias reservadas com desconto: você se compromete com um volume fixo, paga menos por hora, mantém uso constante.

A inferência é o oposto. Quando um modelo vai para produção, a carga começa a dançar no ritmo humano: sobe de manhã, cai à noite, despenca no fim de semana. O resultado é uma carga “bursty” sem solução perfeita de dimensionamento. Provisionar para o pico significa hardware ocioso nas horas de baixa. Dimensionar para a média significa degradação de latência nos picos.

A analogia mais próxima vem da rede elétrica. A distribuidora precisa ter capacidade suficiente para o pico das 19h de uma segunda-feira fria de inverno, quando todo mundo chega em casa e liga o aquecedor, mas isso significa que a mesma rede fica subutilizada durante boa parte do dia. A diferença é que as distribuidoras têm décadas de Dados históricos para calibrar esse dimensionamento. Quem opera inferência de IA tem meses, e o padrão de uso muda todo trimestre.

Quando os agentes assumirem o trabalho
Esse equilíbrio instável está prestes a mudar. Quando agentes autônomos assumem o trabalho, o ciclo humano de sono e vigília deixa de ser o metrônomo da carga. Agentes não param às 23h, não têm almoço, não têm fim de semana. Os vales noturnos evaporam e a curva se achata em carga contínua. Um workflow Agentico típico gera de 20 a 30 vezes mais tokens do que uma troca direta entre humano e modelo. O custo não escala mais por usuário. Escala por passo de raciocínio. Uma empresa que hoje dimensiona sua infra em requisições por segundo vai precisar reaprender a calcular capacidade quando o agente substitui dez requisições humanas por trezentos steps internos.

E o ciclo humano não é o único driver que muda. Agentes respondem a eventos externos sem hora marcada. Um incidente de segurança, uma variação brusca de mercado, um evento climático que ativa automações de contingência: tudo isso pode disparar picos de carga sem correlação com qualquer padrão diário previsível. A imprevisibilidade não some. Muda de natureza.

Existe ainda uma dimensão geográfica que o ciclo humano mascarava. Enquanto a inferência seguia o relógio biológico, o vale de uma região era o pico de outra, e o que parecia carga global oscilante era na verdade carga regional sincronizada com fusos horários. Quando os agentes assumem, isso muda. Um agente de monitoramento financeiro rodando em São Paulo, um agente de processamento de logs em Frankfurt e um agente de atendimento em Singapura não compartilham fuso. A noite some em todo lugar ao mesmo tempo, e a curva de utilização vira carga industrial: constante, distribuída, sem janela natural de pausa.

Nada disso é projeção. Já está acontecendo em escala visível. Agentes de coding processam fluxos contínuos durante o dia útil de desenvolvedores em múltiplos fusos. Agentes de atendimento em alguns bancos brasileiros operam 24 horas com volume de raciocínio que saiu do call center humano tradicional. Agentes de monitoramento de infraestrutura em ambientes regulados rodam 24/7 desde sempre, com a diferença de que agora processam linguagem natural sobre logs e métricas, não apenas regras predefinidas. O perfil de carga industrial não é o que vem. É o que está sendo provisionado neste trimestre nas equipes que abriram caminho.

Essa transição não acontece de um dia para o outro. Vai existir um período onde os dois perfis coexistem nos mesmos clusters: picos humanos durante o dia, carga de agentes preenchendo os vales e os fins de semana. Para quem opera infraestrutura, isso pode parecer uma solução natural: os agentes usam capacidade que hoje está sendo desperdiçada nas horas de baixa. Mas só funciona assim se os sistemas de orquestração conseguirem distinguir os dois tipos de carga e alocar recursos com critérios distintos para cada um. Um agente de processamento batch tolerante a latência não pode ter a mesma prioridade de GPU que uma consulta de usuário esperando resposta em tempo real. Sem essa distinção na camada de orquestração, o que era para ser eficiência vira degradação cruzada: agentes consumindo recursos que deveriam servir picos humanos, ou usuários esperando porque agentes estão na frente da fila.

Há ainda um problema operacional que o setor não resolveu. Sem os vales noturnos, a janela de manutenção desaparece. Atualizações de modelo, re-indexação de embeddings, operações de cluster: tudo o que hoje acontece entre meia-noite e seis da manhã precisa migrar para um modelo de zero-downtime por padrão, não como característica especial reservada para tier-1. A maioria dos ambientes de inferência que estão entrando em produção hoje não foi desenhada com essa premissa.

Os três erros que pagam caro
Tratar os dois regimes como um só produz três erros concretos, e cada um cobra um preço diferente.

O primeiro é de provisionamento. Reservas de longo prazo funcionam bem para treinamento, mas para inferência a combinação de baseline reservada com capacidade spot para absorver picos é mais eficiente. Usar o mesmo modelo nos dois é ou pagar demais ou pagar com imprevisibilidade. Na prática, vejo organizações fechando reservas de três anos para carga de inferência cujo perfil vai mudar em dezoito meses. Quando os agentes entrarem em produção e a baseline subir, a elasticidade necessária muda, e o contrato que parecia eficiente vira um piso financeiro difícil de renegociar.

O segundo é de observabilidade. Utilização de GPU alta no cluster de inferência pode significar saturação com usuários esperando, não eficiência. A métrica que importa é latência por token e throughput por requisição. O resultado prático do dashboard errado é a equipe de operações vendo verde no monitor enquanto o P99 de latência quebra o SLA com o cliente. O alerta chega pelo produto ou pelo suporte, não pelo monitoramento de infra. Esse é exatamente o sinal de que a régua está medindo a coisa errada.

O terceiro é de custo marginal. No software tradicional, adicionar um usuário custava quase nada porque os servidores já estavam rodando e a margem incremental escalava com o volume. Na inferência, cada consulta consome GPU-hora real. Isso inverte a lógica de crescimento com que o setor aprendeu a operar e cria um problema específico para o board: o modelo financeiro que produto apresentou com premissa de crescimento de software não fecha quando aplicado à realidade de custo por inferência. A conversa com finanças precisa ser refeita antes do volume chegar, não depois.

A maioria das equipes de infra que vejo em campo ainda usa o mesmo dashboard para treinamento e inferência. Não é descuido. É que o setor aprendeu a operar IA com o problema de treinamento na cabeça e ainda não atualizou o modelo mental para o que a inferência em escala exige.

O que muda em campo para quem opera essa transição não é tecnologia, é gestão. Dashboards precisam ser separados por regime, com métricas próprias para cada um. Reservas precisam ser revisadas com horizonte mais curto e granularidade maior. A modelagem de crescimento de usuários precisa virar uma conversa com finanças que inclua premissas de custo por requisição e por step de agente. E o desenho de manutenção precisa partir da premissa de zero-downtime, não tratá-lo como exceção reservada a workloads críticos. Nada disso é caro de fazer agora. O que custa é fazer depois que a carga chegou.

A consequência sobre o modelo de negócio ainda não está resolvida. Treinamento é CAPEX com data de validade. Inferência é OPEX permanente, e a conta só fecha se a receita por requisição superar o custo de computação que ela consumiu. Gartner e Deloitte já mapearam a direção: a inferência responde por 55% do gasto global em infraestrutura de IA hoje segundo o Gartner, dois terços segundo a Deloitte, contra 33% três anos atrás, com projeção de 75-80% até 2030. Quem ainda não separou os dois problemas vai pagar caro: capacidade errada, métricas que enganam e conversas erradas com produto e finanças.

Por Claudio Frazão, gerente Sênior de Arquitetura de Soluções Gerenciadas da Equinix.