A fatura de IA sobe, o time habilita prompt caching, reduz o max_tokens, troca o modelo por um menor — e o custo por atendimento continua aumentando. Quando eu abro a arquitetura, quase sempre encontro o mesmo desenho: processamento noturno rodando como chamada síncrona, capacidade provisionada para o pico e ociosa fora dele, retries escondidos atrás de uma resposta bem-sucedida e um roteador promovendo requisições simples para modelos mais caros sem que ninguém meça o ganho de qualidade. O problema não é falta de otimização. É otimizar a alavanca errada.

A decisão que falta Caching resolve reuso. FinOps de IA começa quando você separa quatro perguntas que parecem uma só: quando executar, como comprar capacidade, como absorver variação e qual modelo deve responder. Batch, PTU, pay-as-you-go e Model Router não são concorrentes diretos. Eles atuam em dimensões diferentes — e o custo sustentável aparece quando cada carga entra na faixa certa.

O que é FinOps de IA?

FinOps de IA é a disciplina operacional que conecta consumo, capacidade, qualidade e resultado de negócio. Não é apenas acompanhar gasto por assinatura nem comparar preço por milhão de tokens. É conseguir responder, por caso de uso: quanto custa uma tarefa aceita, qual qualidade foi entregue, qual latência foi necessária e quanto da capacidade comprada ficou ociosa.

O contraste com o FinOps tradicional importa. Em uma API determinística, uma chamada tende a produzir o mesmo tipo de trabalho. Em IA generativa, duas requisições para o mesmo endpoint podem usar contextos diferentes, acionar ferramentas, gerar retries, cair em modelos distintos e terminar com níveis de qualidade incompatíveis. Por isso, custo por token é uma métrica de infraestrutura; custo por tarefa aprovada é uma métrica de produto.

Uma fórmula simples expõe o que a fatura esconde:

Custo por tarefa aprovada = inferência + contexto recuperado + chamadas de ferramenta + retries + capacidade ociosa, dividido pelas respostas que passaram no critério de qualidade.

O problema que resolve

Sem essa visão, cada otimização local cria um efeito colateral em outro lugar:

1. Modelo menor sem avaliação reduz a tarifa por token, mas aumenta fallback e retrabalho.
2. PTU comprada cedo demais estabiliza capacidade, mas transforma adoção incerta em ociosidade contratada.
3. Batch ignorado mantém cargas que poderiam esperar disputando quota e preço com o tráfego interativo.
4. Model Router sem telemetria muda o mix de modelos, mas ninguém sabe se o ganho de qualidade compensa a seleção.
5. Caching tratado como estratégia completa economiza prefixos repetidos, mas não corrige uma carga executada no modo errado.

Como funciona — passo a passo

1. Fixe a fronteira de processamento e o contrato de latência. Comece pelo requisito de residência: Global Standard para a maioria das cargas sem restrição específica, Data Zone quando o processamento precisa ficar na zona e implantação regional quando a exigência é de uma única região. Depois separe o que responde em segundos do que pode esperar.
2. Meça uma linha de base em pay-as-you-go. Antes de assumir capacidade, registre tokens de entrada e saída, chamadas por hora, picos, retries, latência e taxa de aprovação por caso de uso.
3. Mova o que pode esperar para Batch. Classificação em massa, enriquecimento de catálogo, geração de embeddings e sumarização offline devem usar uma fila assíncrona quando a janela operacional permitir.
4. Isole a base estável do burst. Demanda previsível pode justificar PTU; crescimento incerto, sazonalidade e picos continuam em pay-as-you-go. A arquitetura madura frequentemente usa os dois.
5. Use roteamento apenas onde a complexidade varia. Se todas as requisições exigem o mesmo nível de raciocínio, um modelo fixo é mais simples de governar. Se variam, o Model Router pode escolher entre modelos suportados — desde que qualidade, modelo escolhido e custo fiquem observáveis.
6. Aplique caching como camada transversal. Prefixos estáveis, instruções de sistema e contexto repetido devem ser reutilizados, mas o cache não decide prazo, capacidade nem modelo.
7. Feche o ciclo com custo por resultado. Um dashboard FinOps precisa unir consumo e telemetria técnica ao resultado da avaliação: tarefa aprovada, resposta fundamentada, documento processado ou atendimento resolvido.

Exemplo técnico de implantação

Em produção, eu separaria as modalidades em deployments distintos e deixaria a política de seleção na aplicação. O YAML abaixo é uma pseudoconfiguração da política operacional — não é um schema ARM/Bicep nem deve ser enviado diretamente para a API:

deployments:
  batch: llm-batch
  ptu: llm-ptu
  payg: llm-payg
  router: llm-router

policy:
  contracts-nightly:
    execution: batch
    latency_slo: 24h
  service-copilot:
    execution: online
    baseline: ptu
    spillover: payg  # quando suportado
  public-assistant:
    execution: online
    capacity: payg
  variable-complexity:
    execution: online
    model_selection: router

A aplicação pode resolver essa política antes de chamar o SDK. O exemplo é deliberadamente simples: em produção, a decisão também precisa considerar residência, modelo disponível, quota, avaliação e estado do circuito.

def select_deployment(workload):
    if workload["offline"] and workload["deadline_hours"] >= 24:
        return "llm-batch"
    if workload["stable_baseline"] and workload["ptu_benchmark_passed"]:
        return "llm-ptu"
    if workload["complexity_varies"]:
        return "llm-router"
    return "llm-payg"

Cada chamada deve carregar, no mesmo trace, use_case, prompt_version, deployment solicitado, modelo executado, cache hit, tokens, retries, TTFT/TTLT e o resultado da avaliação. Antes de reservar PTU, implante e teste com tráfego representativo; antes de ativar o router, compare-o com uma política fixa; antes de mover uma carga para Batch, valide que fila, retry e conclusão posterior cabem no processo de negócio.

As quatro decisões que não devem ser misturadas — e a camada que as atravessa

As escolhas são independentes na lógica de arquitetura, mas combinações, quotas e disponibilidade variam por modelo, região e implantação.

Batch muda quando o trabalho roda

Batch serve quando o resultado pode chegar dentro de uma janela. A Microsoft documenta Global Batch com 50% menos custo que Global Standard, quota separada e alvo de 24 horas — sem expirar o job se ele demorar mais. Modelo e região continuam sendo condicionantes.

PTU e pay-as-you-go mudam como a capacidade é comprada

PTU é cobrada pela capacidade implantada, não pelos tokens usados. Quota não garante capacidade disponível: dimensione e implante antes de comprar a reserva. Pay-as-you-go absorve incerteza e burst. O padrão saudável é base no PTU, cauda no consumo, com spillover observável quando suportado.

Model Router muda qual modelo atende

Roteamento atende cargas de complexidade variável, mas não garante economia. Registre o modelo retornado na resposta, limite o subconjunto permitido e compare contra uma política fixa. O contexto efetivo é condicionado pelo menor modelo subjacente; sem avaliação, o router vira uma caixa-preta.

Caching muda quanto contexto precisa ser recomputado

Caching atua sobre reuso. A implementação atual considera cache a partir de 1.024 tokens, e modelos mais novos podem cobrar escrita de cache. Consulte o preço vigente: cache hit alto não corrige uma carga executada na modalidade errada.

Uma arquitetura híbrida que fecha a conta

Imagine uma instituição financeira com quatro cargas:

• Copiloto interno de atendimento, usado em horário comercial, com volume previsível e contexto governado: candidato a uma base provisionada depois do benchmark.
• Assistente público, sujeito a campanhas, incidentes e sazonalidade: pay-as-you-go para absorver burst, com limites por canal e caso de uso.
• Análise noturna de contratos e comunicações, sem exigência de resposta imediata: Batch, isolado do tráfego online.
• Perguntas de complexidade muito diferente, da consulta cadastral à análise de uma política de risco: roteamento, mas somente com avaliação e telemetria do mix de modelos.

Prompt caching atravessa as quatro quando há prefixos repetidos. A observabilidade também: cada chamada carrega use_case, ambiente, versão do prompt, modelo solicitado, modelo executado, cache hit, tokens, retries e resultado da avaliação.

O ponto central é não procurar uma modalidade vencedora. O portfólio de capacidade é que deve refletir o portfólio de cargas.

A conta que importa

Um painel de IA que mostra somente gasto e tokens explica a fatura, mas não orienta decisão. O conjunto mínimo de métricas é:

O número executivo é custo por tarefa aprovada. Os demais explicam por que ele mudou.

Boas práticas para produção

• Defina orçamento e limite por caso de uso, não apenas por recurso Azure.
• Versione prompt e política de roteamento junto com o código; mudança econômica também é mudança de produto.
• Use um conjunto de avaliação antes de trocar modelo, ativar router ou reduzir contexto.
• Use métricas específicas do Azure OpenAI, como Prompt Tokens, Generated Tokens, TTLT, Prompt Token Cache Match Rate, PTU Utilization V2, Service Tier e IsSpillover; não use a latência genérica legada como referência.
• Controle loops de ferramentas e retries com limites explícitos e falha visível.
• Teste PTU com tráfego representativo, incluindo contexto, concorrência e distribuição real de chamadas.
• Mantenha burst fora da base provisionada e revise a utilização antes de ampliar compromisso.
• Valide preço e disponibilidade no momento da decisão. Use a página dinâmica de preços, as tabelas regionais e o Azure Cost Management; modelo, região, implantação e contrato comercial alteram a conta.

O que precisa estar de pé

Fundação — custo atribuível e qualidade mensurável. Cada chamada pertence a um caso de uso e a um owner. Prompt, modelo, tokens, latência, retries e resultado da avaliação estão no mesmo trace. Existe uma linha de base em pay-as-you-go e um conjunto mínimo de tarefas que define “bom o suficiente”.

Está de pé quando você consegue explicar o custo de uma tarefa aprovada sem dividir a fatura igualmente entre produtos.

Produção com contexto — cada carga na faixa certa. Trabalho offline usa Batch; tráfego variável continua elástico; a base estável tem benchmark para PTU; roteamento só entra onde a complexidade varia. Caching e limites de contexto reduzem repetição, e toda mudança passa por avaliação de qualidade.

Está de pé quando uma redução de custo não precisa ser defendida com a frase “parece que a qualidade continuou boa”.

Escala e eficiência — capacidade como portfólio. PTU, pay-as-you-go, Batch e roteamento são tratados como uma carteira única. Compromissos têm owner, critério de entrada e saída; bursts não contaminam a base; custo por tarefa e qualidade orientam revisão de modelo e capacidade.

Está de pé quando o time consegue mover uma carga entre modalidades sem perder rastreabilidade, SLA ou responsabilidade financeira.

A ordem é causal, não cronológica. Não existe compromisso eficiente sem linha de base, nem roteamento eficiente sem avaliação.

Referências oficiais

• Tipos de implantação no Microsoft Foundry Models
• Global Batch no Azure OpenAI em Microsoft Foundry Models
• Model Router: conceitos e funcionamento
• Provisioned throughput e gestão de custo
• Prompt caching no Azure OpenAI
• Métricas de monitoramento do Azure OpenAI
• Preços do Azure OpenAI Service

Perguntas frequentes (FAQ)

Batch é sempre a opção mais barata?

A oferta Global Batch é documentada com 50% menos custo que Global Standard e alvo de conclusão em 24 horas, mas só é vantajosa quando o processo aceita a janela e foi desenhado para fila, retry e conclusão posterior. O job não expira apenas por ultrapassar o alvo; disponibilidade varia por modelo e região.

Quando PTU começa a fazer sentido?

Quando existe uma base sustentada, previsível e medida com o modelo real. Não use apenas média mensal: observe concorrência, tamanho do contexto, distribuição horária, sazonalidade e utilização. PTU é decisão de capacidade, não desconto automático.

Model Router garante economia?

Não. Ele pode melhorar o mix entre modelos, mas precisa ser comparado contra uma política fixa usando qualidade, latência e custo por tarefa. Sem avaliação, o router pode aumentar a seleção de modelos caros ou gerar fallback sem benefício mensurável.

Posso combinar PTU e pay-as-you-go?

Sim. Uma arquitetura comum mantém a base previsível na capacidade provisionada e deixa burst, experimentação, novos modelos e cauda variável no consumo. A fronteira deve ser revista com dados de utilização.

Prompt caching ainda importa?

Muito. Ele reduz recomputação de contexto repetido e pode melhorar latência e custo de entrada. Só não substitui as demais decisões: quando executar, como comprar capacidade e qual modelo usar.

Conclusão

O erro mais comum em FinOps de IA é procurar uma única alavanca de economia. Batch, PTU, pay-as-you-go, Model Router e caching resolvem problemas diferentes. Quando são tratados como substitutos, a arquitetura vira uma sequência de otimizações locais e a fatura continua sem explicar o valor entregue.

A decisão madura começa pelo contrato da carga: o que pode esperar, o que é estável, o que varia e onde a complexidade muda. Depois, mede custo por tarefa aprovada — não apenas por token. É assim que FinOps deixa de ser reação à fatura e vira arquitetura de produto.

👉 Se sua equipe já reduziu tokens, trocou modelos e mesmo assim não consegue explicar o custo por resultado — especialmente em cargas corporativas com SLA, burst e governança —, este é o ponto de decisão. Quer trocar ideia sobre FinOps de IA e Microsoft Foundry? Me chama no LinkedIn.