Esta semana em cloud (24–30/ago): o token ficou barato — a capacidade, não

Q: Teto de gasto por projeto não vai derrubar a minha aplicação em produção?

Vai pausar as chamadas de API do agente naquele projeto ao atingir o limite — e é justamente por isso que o recurso serve para ambiente de desenvolvimento, experimentação e workload interno antes de servir para produção crítica. O desenho do Google Cloud prevê alertas em 50%, 80% e 100% do orçamento e a retomada com um clique, além de permitir habilitar overage para que o excedente seja cobrado a taxa de consumo em vez de interromper. A recomendação é escalonada: teto rígido onde a interrupção é aceitável, teto com overage habilitado onde não é, e alerta sem teto no núcleo de produção. O que não faz sentido é manter tudo sem limite algum porque o pior caso assusta — o pior caso sem teto é a fatura.

Q: Vale a pena adiar execução de agente para pagar menos?

Vale para tudo que não olha para um humano esperando. O Deferred Execution Pricing anunciado pelo Google Cloud promete até 50% de desconto em inferência para workloads marcados como adiáveis, executados em janelas de capacidade fora de pico, e o Dynamic Workload Scheduler já oferece a mesma lógica para compute em modo flex-start. O trabalho real é de classificação: separar o que é interativo (atendimento, copiloto no fluxo de trabalho, resposta a incidente) do que é batch disfarçado de tempo real (enriquecimento de base, reprocessamento, sumarização noturna, avaliação de qualidade de modelo). Na maioria das operações a segunda categoria é maior do que se imagina, e ela é quase toda adiável sem que ninguém perceba.

Banner - Esta semana em cloud (24–30/ago): o token ficou barato — a capacidade, não

TL;DR — O Google Cloud lançou teto de gasto por projeto, savings de 10 a 20% e execução adiada com até 50% de desconto para agentes. A Equinix explicou por que a conta sobe mesmo com modelo 99% mais barato: o custo migrou do token para a capacidade. A CNCF publicou o outro lado — autoscaling preditivo para GPU e GPU como pool compartilhado. A variável de controle não é mais qual modelo, e sim quanta capacidade e com que teto.

A semana passada foi sobre quem pode entrar. Esta foi sobre quem paga a conta — e sobre uma constatação incômoda que apareceu, na mesma semana, num blog de infraestrutura, num anúncio de billing e em dois textos da CNCF.

A constatação é esta: o preço do modelo caiu e a fatura subiu. Não é contradição nem erro de medição. É o sinal de que a variável que controla o custo de IA mudou de lugar — saiu do preço por token, que todo mundo aprendeu a negociar, e foi para a capacidade, que quase ninguém está medindo direito.

Por que a conta sobe enquanto o preço do token cai?

A pergunta é o título de um texto da Equinix publicado na quinta-feira, e a resposta dele começa desmontando a premissa mais confortável do mercado: um token não é uma unidade padronizada de inteligência. Um milhão de tokens de um modelo e um milhão de tokens de outro não entregam a mesma coisa em capacidade, confiabilidade ou latência — comparar os dois pelo preço de lista é comparar litros de combustível sem olhar o rendimento do motor.

Com modelos como o DeepSeek V4 anunciando descontos de até 99% em tarefas de codificação, a tentação de trocar tudo pelo mais barato é enorme. E é aí que o TCO cobra a diferença, em três frentes que o texto detalha:

Infraestrutura de compute. Modelo mais barato frequentemente exige otimização específica de hardware e framework de inferência. Sem esse ajuste, a saída padrão é provisionar mais capacidade do que o necessário — e capacidade ociosa não aparece na comparação de preço por token.
Latência e throughput. Para aplicação em tempo real, modelo mais lento significa mais caching, mais rede e mais armazenamento para compensar. A economia no insumo vira despesa no entorno.
Governança. Cada novo modelo e cada novo provedor adiciona uma camada de IAM, de conformidade com a LGPD e de monitoramento de uso. É custo operacional que não tem SKU, mas tem folha de pagamento.

O corolário prático é desconfortável para quem monta planilha de comparação: um modelo 99% mais barato por token que precisa de dez vezes mais capacidade para atingir a mesma qualidade não é 99% mais barato. A métrica honesta é custo por tarefa concluída com sucesso — e ela quase nunca está no dashboard.

O que mudou no billing dos provedores?

Na quarta-feira, o Google Cloud anunciou o pacote mais concreto de FinOps para agentes que vimos até agora — e o desenho dele confirma o diagnóstico da Equinix, porque nenhum dos controles novos tenta baratear o token. Todos atacam quando e até quanto se gasta:

O problema	O que chegou	O que muda na prática
Assento ocioso pago por usuário	Pay-as-you-go no Gemini Enterprise, combinável com assinatura por assento	Demanda variável para de pagar por licença parada, e a tarefa não bate em cota no meio da execução
Compromisso rígido demais para uso que cresce	Flexible Savings Plans — 10 a 20% de desconto em tokens, sem mínimo nem máximo	Desconto sem criar mais um silo de billing, compatível com Enterprise Agreement
Estouro de orçamento descoberto na fatura	Teto mensal por projeto no Billing Console, com alertas em 50%, 80% e 100%	Ao bater o limite, as chamadas do agente pausam; retomada em um clique ou overage habilitado
Tudo tratado como urgente	Deferred Execution Pricing (anunciado, ainda por chegar) — até 50% de desconto	Workload marcado como adiável roda em janela de capacidade ociosa, fora da cota padrão
"Quanto foi para IA?" respondido em três consoles	Relatórios centralizados com detecção de anomalia e RCA por SKU	O desvio de gasto é sinalizado com os três SKUs responsáveis, não descoberto no fechamento

Repare no que não está na tabela: nenhuma linha diz "negocie um preço por token melhor". O provedor está admitindo que o controle útil é o guardrail, não a tabela de preços.

A Microsoft foi na mesma direção por outro caminho. O Azure Resource Manager MCP Server ganhou capacidades de Cost Management, permitindo que um agente consulte gasto, crie budget, analise Savings Plans e estime custo antes do deploy, sem sair do ambiente de desenvolvimento. É um detalhe com consequência maior do que parece: encurta a distância entre a decisão de arquitetura e o dado financeiro, que hoje é medida em dias e reuniões. Na mesma semana saiu um guia detalhado de otimização de custos no Azure Databricks, estruturado em três fases — mapeamento do ambiente, ajuste técnico de clusters e código, e alinhamento de time com tagging e observabilidade. A terceira fase é a que costuma faltar, e é a que decide se as outras duas duram.

Você consegue dizer, hoje, quanto custou cada tarefa concluída pelos seus agentes? Podemos montar essa medição com o seu time.

Onde o dinheiro está realmente sendo queimado?

Em capacidade que você reservou e não usou. E foi a CNCF, não os provedores, que publicou nesta semana os dois textos mais úteis sobre isso.

O primeiro traz o número que explica a década: 66% das organizações já usam Kubernetes para inferência, mas apenas 7% fazem deploy de modelo diariamente. A lacuna não é de capacidade de execução — o cluster roda. É de maturidade operacional: enquanto GPU não é um recurso de primeira classe no modelo de recursos da plataforma, cada modelo em produção é um projeto, e cada projeto reserva hardware por garantia.

O segundo texto ataca exatamente essa reserva por garantia, propondo tratar GPU como pool compartilhado entre times em vez de alocação dedicada — com Dynamic Resource Allocation, MIG e HAMi para fatiar o acelerador, tenant clusters para isolar, e chargeback para que a conta chegue a quem consumiu. É a diferença entre comprar um carro para cada diretor e operar uma frota. A observação mais dura do artigo é que topologia de hardware define desempenho tanto quanto software: em fábrica de IA, o desenho físico não é detalhe de infraestrutura, é decisão de arquitetura.

Do outro lado do mesmo problema está o pico. Um trabalho publicado na sexta mostra por que o HPA reativo falha em GPU: o provisionamento de nó com acelerador leva de três a cinco vezes mais tempo que o de CPU, então quando a métrica dispara já é tarde. A proposta — um controlador Kubernetes com modelo Bi-LSTM treinado sobre métricas do Prometheus — prevê a demanda com dez minutos de antecedência e escala de forma gradual, a vinte pods por minuto, evitando o crash sem inflar o cluster. É open source, coexiste com o HPA e não exige plataforma de ML externa. Vale como referência de padrão mesmo para quem não vai treinar modelo nenhum: a lição transferível é que em GPU, escalar na hora do pico é escalar tarde.

O Google Cloud publicou a versão para VMs da mesma tese, num guia de gerenciamento dinâmico de capacidade com três movimentos que valem para qualquer nuvem: reservar antecipadamente o que é previsível (com flex-start para batch tolerante a latência e calendar mode para evento com data marcada), manter uma lista priorizada de hardware alternativo para cada aplicação — para que a carga migre sozinha quando a família preferida some — e automatizar o ciclo inteiro num único control plane, com ComputeClasses e alocação granular de acelerador. O dado que sustenta a urgência vem do próprio Google: 90% das empresas pretendem implantar agentes nos próximos três anos, e apenas 17% dos líderes de TI confiam que a infraestrutura atual aguenta.

E há a frente do silício, onde a Microsoft detalhou o Maia 200, seu acelerador focado em eficiência de inferência, com rede all-Ethernet em dois níveis e a promessa de até 40% mais tokens gerados por rack que GPUs concorrentes. Ainda que o número seja do fabricante, a métrica escolhida diz tudo sobre o momento: não é FLOPS, é token por rack — desempenho normalizado por capacidade instalada.

O que mais mereceu atenção

Rede. O Azure Multicloud Interconnect trouxe conectividade privada entre Azure e AWS sem montar VPN ou circuito dedicado à mão — bom para quem já opera nos dois, com a ressalva de sempre: leia os limites de throughput antes de desenhar em cima. E o Azure passou a anunciar prefixos de gateway, reduzindo o número de rotas BGP em topologias hub-and-spoke, alívio concreto para quem esbarra em limite de tabela de rotas.

Identidade e acesso. O suporte a workload identity no driver CSI do Azure Files (SMB) no AKS chegou a GA — mais uma chave compartilhada saindo do caminho, na esteira exata do que discutimos na edição passada. O Azure Bastion ganhou expiração para links compartilháveis e dual-stack IPv4/IPv6, além de conexão a clusters AKS em disponibilidade geral.

Operação. O Azure SRE Agent ganhou Live Reports — dashboards persistentes gerados a partir de conversa que, uma vez criados, rodam sem consumir tokens do LLM. É o tema da semana aparecendo onde menos se espera: até a observabilidade do agente foi redesenhada para parar de queimar inferência. No Google Cloud, o Fault Injection Testing entrou em preview, trazendo injeção de falha gerenciada para validar resiliência sem escrever o arcabouço de caos por conta própria.

Fim de vida. O Node 22 LTS tem data marcada e as equipes precisam se mover antes de abril de 2027 — parece distante, e não é, porque runtime de aplicação atravessa mais times do que qualquer plano de migração prevê. Já o Azure Database for PostgreSQL Flexible Server ganhou suporte estendido, o que compra fôlego para quem está com upgrade de versão maior atrasado — fôlego, não anistia.

Comunidade. A CNCF publicou um guia de governança para projetos, ajudando mantenedores a escolher estrutura conforme tamanho e estágio — leitura útil para quem avalia a saúde de um projeto antes de colocá-lo em produção. E o EC2 completou 20 anos: o serviço que inaugurou a ideia de alugar capacidade por hora chega ao aniversário numa semana em que o setor inteiro discute como parar de pagar por capacidade parada. A simetria é boa demais para deixar passar.

O que isso muda para quem opera infra no Brasil?

Três decisões que cabem nesta semana:

Troque a métrica antes de trocar o modelo. Enquanto o indicador for custo por milhão de tokens, toda decisão vai favorecer o modelo mais barato e a conta vai continuar subindo. Instrumente custo por tarefa concluída com sucesso — por aplicação, por time, por fluxo — e só depois compare fornecedores. No Brasil isso tem um agravante que o texto da Equinix não cobre: latência de saída internacional entra na conta como retry e timeout, e retry é token pago duas vezes.
Coloque teto onde a interrupção é barata, hoje. Ambiente de desenvolvimento, experimentação e workload interno não precisam de orçamento infinito, e o custo de descobrir isso na fatura é sempre maior que o de descobrir num alerta em 50%. Comece por aí, com alerta escalonado, e só depois discuta o teto de produção — onde a resposta certa costuma ser overage habilitado, não bloqueio.
Classifique o que é adiável antes de negociar desconto. Antes de assinar compromisso de gasto, separe o interativo do batch disfarçado de tempo real. Reprocessamento, enriquecimento de base, avaliação de qualidade e sumarização noturna quase sempre podem esperar por janela de capacidade ociosa — e é essa classificação que destrava tanto a execução adiada quanto o scheduling de GPU. O mesmo raciocínio de "escalar antes do pico, não durante" que aplicamos em autoscaling no Kubernetes com KEDA e HPA vale aqui, com uma diferença de grau: em GPU, chegar tarde não degrada, derruba. E se os agentes já estão em produção, a medição de custo precisa andar junto com a de qualidade, como argumentamos em governança de agentes em produção.

O padrão da semana é o de toda tecnologia que amadurece: o insumo vira commodity e o gargalo migra para a operação. Aconteceu com CPU, aconteceu com armazenamento, está acontecendo com inferência. A diferença é a velocidade — o token levou dois anos para percorrer o caminho que o compute levou uma década. Quem ainda estiver escolhendo modelo por preço de lista em 2027 vai estar otimizando a menor linha da fatura.

Perguntas Frequentes

Se o preço por token caiu tanto, por que minha conta de IA subiu?
Porque o token deixou de ser a maior linha da conta. O que cresce é o entorno: GPU reservada e subutilizada, nós provisionados para o pico, retries que refazem trabalho, contexto reenviado a cada passo e a orquestração que sustenta tudo. Como resume a Equinix, um token não é unidade padronizada de inteligência — um modelo 99% mais barato pode precisar de mais chamadas, mais contexto ou mais hardware para o mesmo resultado. A checagem prática é comparar custo por tarefa concluída com sucesso, não por milhão de tokens. Se você não consegue calcular esse número hoje, o problema está aí, não no preço de lista.

Teto de gasto por projeto não vai derrubar a minha aplicação em produção?
Ao atingir o limite, as chamadas de API do agente naquele projeto são pausadas — por isso o recurso serve primeiro a desenvolvimento, experimentação e workload interno. O desenho do Google Cloud prevê alertas em 50%, 80% e 100%, retomada em um clique e a opção de habilitar overage, cobrando o excedente a taxa de consumo em vez de interromper. Use escalonado: teto rígido onde a interrupção é aceitável, teto com overage onde não é, e alerta sem teto no núcleo de produção. O que não faz sentido é manter tudo sem limite porque o pior caso assusta — sem teto, o pior caso é a fatura.

Vale a pena adiar execução de agente para pagar menos?
Vale para tudo que não tem um humano esperando. O Deferred Execution Pricing promete até 50% de desconto em inferência para workloads adiáveis executados fora de pico, e o Dynamic Workload Scheduler já aplica a mesma lógica ao compute em flex-start. O trabalho real é de classificação: separar o interativo (atendimento, copiloto, resposta a incidente) do batch disfarçado de tempo real (enriquecimento de base, reprocessamento, sumarização noturna, avaliação de modelo). Na maioria das operações a segunda categoria é maior do que se imagina — e quase toda adiável sem que ninguém perceba.

Autoscaling preditivo para GPU é exagero para quem tem poucos nós?
Depende de quanto tempo leva para o seu nó de GPU ficar pronto. O ponto do trabalho da CNCF é que o HPA reativo falha porque provisionar acelerador leva de três a cinco vezes mais tempo que CPU: quando a métrica dispara, a fila já estourou. Com poucos nós o efeito piora, porque não há folga para absorver o pico. Antes de partir para previsão com modelo, esgote o barato: nós quentes em espera, warm pool, limites de concorrência que degradam com elegância e fallback automático para outra família de hardware. Se depois disso o tráfego ainda for previsível — e pico de negócio costuma ser —, a previsão paga.

Fontes: