Benchmark de LLMs para CFOs: Custo, Não Score Técnico

A maioria das empresas que adota LLMs em produção comete o mesmo erro de procurement: avalia o modelo pelos scores técnicos e paga a conta sem fazer a matemática financeira. O CFO recebe uma fatura de API. O CTO apresenta um slide com MMLU, HumanEval e throughput. Duas linguagens diferentes, uma decisão que custa caro.

O benchmark de LLMs tradicional mede performance. O financeiro mede retorno. O primeiro testa o modelo. O segundo testa a decisão de compra.

Este artigo opera na segunda camada: TCO, custo por token ponderado por caso de uso, inteligência por dólar e payback. As métricas que transformam uma comparação de modelos em uma decisão de alocação de capital.

Por que o benchmark técnico não responde à pergunta do CFO?

O CFO não precisa saber se o Claude supera o GPT-5.6 em raciocínio científico com 3 pontos de vantagem no GPQA Diamond. Ele precisa saber qual modelo executa as tarefas da operação real da empresa ao menor custo total, com o menor risco de interrupção e com previsibilidade orçamentária.

A diferença é de categoria, não de granularidade.

Um score no MMLU diz se o modelo acerta mais perguntas de conhecimento geral. Não diz nada sobre o custo de servir 50 mil chamadas de API por dia com latência abaixo de 800 milissegundos. Não precifica o custo de um fallback entre provedores quando a API primária sofre degradação. Não calcula o impacto do câmbio e dos impostos na fatura em reais.

O que interessa ao CFO são quatro indicadores financeiros. Cada um ilumina uma dimensão diferente do gasto com IA.

Os 4 indicadores financeiros que medem um LLM

1. Custo por tarefa ponderada (Weighted Cost per Task). O preço por token é o número que aparece na página de pricing do provedor. O custo por tarefa é o número que aparece na fatura depois de um mês de uso real. A diferença entre eles é onde o dinheiro desaparece: tokens de raciocínio que o modelo gera sem o usuário ver, prompts longos com baixa densidade de instrução, cache hits que não estão sendo usados e respostas verbosas que o output pricing cobra na íntegra.

2. Inteligência por dólar (Intelligence per Dollar). O custo bruto não existe no vácuo. Cada dólar gasto compra um nível de acurácia, latência e completude. Modelos mais baratos por token frequentemente exigem mais chamadas para chegar ao mesmo resultado, queimando a economia no volume. A métrica correta é o custo dividido pela taxa de sucesso na tarefa específica. O CFO quer a resposta: quanto custa resolver 100% dos tickets de classificação de documentos, não quanto custa o milhão de tokens.

3. TCO do stack de inferência. O custo do modelo é uma fatia do custo total. O restante está no middleware que roteia as chamadas, na infraestrutura de cache, nos mecanismos de fallback entre provedores, na camada de observabilidade e no tempo de engenharia gasto refazendo integrações quando um modelo é descontinuado ou tem o preço alterado. Empresas que rodam LLMs sem uma camada de roteamento pagam o preço cheio de cada chamada e arcam com o custo de downtime em cada falha de API, como detalhado na análise sobre o Model Router como middleware essencial.

4. Payback do caso de uso. Cada implementação de LLM tem um break-even. Um agente de suporte que substitui 30% do volume do tier 1 tem um payback calculável. Um gerador de relatórios que reduz 12 horas por semana de um analista tem outro. A tarefa do CFO é modelar cada caso como um investimento com retorno esperado, comparar alternativas de modelo para o mesmo caso, e aprovar o que maximiza o retorno sobre o custo de inferência.

[IMAGEM TECNICA type: comparison-table title: Indicadores Financeiros de LLMs data: | | Indicador | O que mede | Pergunta do CFO | Armadilha comum | |---|---|---|---| | Custo por tarefa ponderada | Custo real por unidade de trabalho concluída | Quanto estou gastando por transação processada? | Confundir preço de tabela (por token) com custo efetivo (por tarefa) | | Inteligência por dólar | Acurácia entregue por unidade de custo | Quanto de performance estou comprando com cada real? | Comparar custo sem normalizar pela taxa de sucesso na tarefa | | TCO do stack | Custo total incluindo middleware, cache, fallback e engenharia | Qual é o custo completo de servir inferência? | Olhar só o pricing do modelo e ignorar a infraestrutura ao redor | | Payback do caso de uso | Tempo até o retorno cobrir o investimento em inferência | Em quantos meses esse agente se paga? | Tratar LLM como custo fixo em vez de investimento com ROI | source: article section "Os 4 indicadores financeiros que medem um LLM" language: pt-BR ]

A armadilha do preço por token e o que o custo real revela

As tabelas de preços dos provedores contam uma história limpa. GPT-5.6 Terra custa X por milhão de tokens de input. Claude Opus custa Y. DeepSeek V4 custa Z.

A fatura conta outra história.

O consumo real de uma aplicação em produção inclui tokens de input que o sistema envia, tokens de output que o modelo gera, tokens de raciocínio que os modelos reasoning produzem em cadeias internas invisíveis ao usuário, tokens de cache write e cache hit (que custam valores diferentes e reduzem ou inflam a conta dependendo da arquitetura de prompts) e tokens de re-tentativa quando uma chamada falha e o sistema refaz o request.

Um estudo da Artificial Analysis sobre custo real de inferência mostra que o custo ponderado por tarefa pode divergir do preço de tabela por um fator de 2x a 5x, dependendo do padrão de uso e do provedor. O mesmo relatório indica que modelos com preços nominais próximos podem apresentar custo efetivo radicalmente diferente quando medidos em workloads reais.

O CFO que aprova budget baseado na página de pricing está aprovando uma estimativa. O que paga a conta é o custo por tarefa medida no stack.

Inteligência por dólar: a métrica que os provedores não publicam

Modelos de baixo custo por token seduzem pela linha do pricing. Mas a economia desaparece quando a acurácia cai e o sistema precisa de três chamadas para resolver o que um modelo mais caro resolve em uma.

A conta é direta. Se um modelo de $1 por milhão de tokens entrega 60% de taxa de sucesso na tarefa-alvo, e outro de $5 por milhão de tokens entrega 95%, a inteligência por dólar favorece o segundo: o custo efetivo por tarefa bem-sucedida é $1,67 para o modelo barato ($1 / 0,60) contra $5,26 para o modelo caro ($5 / 0,95). O modelo barato vence nesse caso.

Mas a equação inverte quando a tarefa admite re-tentativas sem custo marginal alto. Se cada falha pode ser corrigida com uma segunda chamada, o custo do modelo barato sobe para $1,67 (primeira chamada) mais $0,67 (segunda chamada nos 40% que falharam, assumindo que a segunda resolve), totalizando $2,34 por tarefa concluída. Nesse cenário, o modelo barato ganha com folga.

O ponto não é que um modelo é sempre melhor. O ponto é que a resposta depende da curva de acurácia da tarefa específica, do custo de re-tentativa e da tolerância a falha do caso de uso. O CFO não precisa rodar esses cálculos. Mas precisa exigir que o time técnico os apresente antes da aprovação de budget.

A tabela que o CFO deveria pedir na reunião de aprovação de budget

A comparação financeira de LLMs não cabe em uma tabela estática porque os preços mudam a cada trimestre. O que cabe é um framework de avaliação que o time técnico preenche com dados reais do workload da empresa.

[IMAGEM TECNICA type: comparison-table title: Framework de Avaliação Financeira de LLMs data: | | Dimensão | Modelo A (Frontier) | Modelo B (Mid-tier) | Modelo C (Open-source hospedado) | |---|---|---|---| | Preço input (US$/1M tokens) | $3,00 | $0,60 | $0,20 (hospedagem) | | Preço output (US$/1M tokens) | $15,00 | $2,40 | $0,60 (hospedagem) | | Taxa de sucesso na tarefa-alvo | 96% | 82% | 74% | | Custo por tarefa bem-sucedida | $0,018 | $0,007 | $0,004 | | Custo por 100.000 tarefas/mês | $1.800 | $700 | $400 | | Custo de fallback (5% de falhas de API) | $250/mês | $250/mês | $400/mês (infra própria) | | Tempo de engenharia (integração + manutenção) | 20h/mês | 25h/mês | 80h/mês | | Custo total estimado (3 meses) | $6.900 | $3.600 | $10.200 | source: hypothetical workload simulation for 100k monthly tasks language: pt-BR ]

A tabela acima é ilustrativa e usa dados simulados. Os preços de modelos em julho de 2026 estão documentados nas páginas oficiais de OpenAI, Anthropic, Google e DeepSeek. A guerra de preços entre provedores comprime margens a cada trimestre. O que a tabela demonstra é o método: custo por tarefa ponderada, TCO de três meses incluindo fallback e engenharia, e acurácia medida no workload específico da empresa.

O modelo C, de código aberto hospedado em infraestrutura própria, aparece como o mais barato por tarefa, mas o custo de engenharia de manutenção e a menor acurácia o tornam a opção mais cara no TCO trimestral. É o tipo de dinâmica que a página de pricing esconde e o framework financeiro revela.

O modelo mais caro por token costuma ser o mais barato

Essa afirmação é contraintuitiva. E é verdadeira em condições específicas que valem a pena entender.

O modelo frontier custa mais por token. Mas ele também resolve mais tarefas na primeira tentativa, gera menos tokens de output porque é mais preciso na resposta, e requer menos lógica de fallback e re-tentativa. O custo de engenharia para contornar as limitações de um modelo mais fraco não aparece na fatura da API. Aparece na folha de pagamento.

Empresas que rodam LLMs em produção com margens operacionais apertadas descobrem isso no segundo mês. O CFO aprova o modelo barato baseado no slide de pricing. Trinta dias depois, o custo de engenharia para manter a acurácia acima de 90% consome a economia de API e gera um gasto total maior.

A Nexforce Router resolve parte desse problema com roteamento inteligente: a mesma API distribui cada request para o modelo mais adequado em custo e performance, incluindo fallback automático entre provedores. O custo por token cai sem sacrificar acurácia porque chamadas simples vão para modelos baratos e chamadas complexas vão para modelos capazes. A decisão financeira deixa de ser binária (modelo caro ou barato) e passa a ser granular (cada request no modelo certo).

Quanto custa manter um LLM em produção no Brasil?

A pergunta relevante para o CFO brasileiro inclui uma camada que não aparece nos benchmarks internacionais: a carga tributária e cambial sobre a importação de serviços de IA.

Cada fatura em dólar de API paga spread cambial de 5 a 10%, IOF de 0,38% a 3,5% dependendo da natureza da remessa, IRRF de 15% (podendo chegar a 25% em jurisdições de tributação favorecida), CIDE de 10% sobre serviços técnicos, PIS de 1,65%, COFINS de 7,6% e ISS de 2 a 5%.

O custo efetivo de uma fatura de US$ 100 mil em consumo de API pode chegar a US$ 155 mil depois de impostos, câmbio e encargos. Uma diferença de 55% entre o preço que o provedor publica e o valor que sai da conta bancária brasileira.

Parte dessa carga é recuperável. Empresas no Lucro Real podem tomar crédito de PIS e COFINS (9,25% de alíquota combinada) sobre a importação, e o valor pago de IRRF é compensável no ajuste anual. Mas o fluxo de caixa sofre: o imposto sai no momento da remessa e o crédito entra no fechamento do período fiscal seguinte. O CFO que modela TCO de LLMs precisa incluir o efeito de descasamento de caixa no custo financeiro da operação.

Como reduzir o custo de LLMs sem trocar de modelo

Trocar de modelo é caro: reintegrar APIs, reescrever prompts, reavaliar acurácia, recalibrar o sistema de fallback. A decisão de troca é trimestral ou semestral. Mas a otimização de custo é diária.

As cinco alavancas que reduzem o custo de LLMs sem mudar o modelo escolhido:

1. Roteamento por complexidade. Nem todo request precisa do modelo mais caro. Classificação de texto, análise de sentimento e respostas triviais rodam em modelos 10 a 50 vezes mais baratos com acurácia equivalente. Um middleware de roteamento direciona cada chamada ao modelo adequado com base na complexidade inferida.

2. Cache de prompts e respostas. Requests repetidos ou semanticamente similares não precisam ser reprocessados. Um sistema de cache reduz o volume de chamadas à API em 20 a 40% em aplicações com alta recorrência de prompts (suporte ao cliente, busca interna, chatbots). O cache tem custo de armazenamento, que é uma fração do custo de inferência.

3. Otimização de prompts. A diferença entre um prompt de 500 tokens e um de 200 tokens, quando ambos produzem o mesmo resultado, é um multiplicador direto no custo. Cada token de input economizado reduz a fatura em duas dimensões: menos tokens processados e menos tokens de output gerados (modelos tendem a responder na proporção do input). A disciplina de engenharia de prompts paga o próprio salário.

4. Fallback automático entre provedores. Quando a API primária sofre degradação de latência ou disponibilidade, o sistema reencaminha as chamadas para um provedor alternativo em milissegundos. O custo de downtime (tarefas não processadas, retrabalho, fila de requests acumulada) supera o custo do fallback em ordens de grandeza.

5. Consolidação de provedores em uma única API. Empresas que contratam diretamente múltiplos provedores pagam o preço de varejo em cada um, arcam com o câmbio em cada fatura, e gastam tempo de engenharia mantendo múltiplas integrações. O Nexforce Router consolida mais de 300 modelos em uma única API com faturamento local em reais e nota fiscal. A economia reportada chega a 50% por token comparado à contratação direta, com o adicional de eliminar o spread cambial e os encargos de importação de cada fatura individual.

Perguntas que o CFO deve fazer antes de aprovar o budget de IA

O custo está sendo medido por tarefa ou por token?

Por token é a métrica do provedor. Por tarefa é a métrica do negócio. A resposta correta revela se o time técnico entende a diferença.

Qual a taxa de sucesso do modelo na tarefa-alvo da empresa?

Um modelo com 99% de acurácia no benchmark e 72% na tarefa específica da empresa é uma má alocação de capital. O número que interessa é o da tarefa real, medido em produção.

Qual o custo de fallback e downtime por hora de interrupção?

APIs de LLM falham. O custo financeiro da interrupção depende do volume de tarefas não processadas, do custo de retrabalho e do impacto em SLAs com clientes. O CFO deve exigir esse número modelado, não estimado.

O budget inclui os custos indiretos de engenharia e manutenção?

Integração, monitoramento, reescrita de prompts, atualização de modelos, ajuste de parâmetros. Esses custos frequentemente superam o custo de API nos primeiros meses. Se não estão no spreadsheet, o TCO está subestimado.

A empresa está comprando modelos diretamente dos provedores ou usando uma camada de roteamento?

A resposta define se a empresa paga preço de varejo, arca com múltiplas integrações e absorve cada falha de API individualmente, ou se opera com uma camada de otimização que reduz custo, risco e complexidade operacional.

Referências e Leitura Complementar

• Benchmark LLM: como avaliar e escolher o modelo certo: abordagem técnica de avaliação (MMLU, HumanEval, throughput)
• DeepSeek V4: a guerra pelo share de tokens nos agentes de IA: a compressão de preços no mercado de LLMs
• Model Router: o middleware que falta na sua stack de IA: roteamento inteligente e otimização de custo de inferência
• Artificial Analysis: Model Pricing & Cost Benchmarks: dados independentes de custo, velocidade e inteligência por modelo
• OpenAI Pricing: preços oficiais atualizados dos modelos OpenAI
• Anthropic API Pricing: preços oficiais dos modelos Claude