O modelo mais barato é aquele cujos erros você consegue capturar. Como precificar IA por onde os erros caem
Três formas de cortar custo de inferência: especializar um modelo pequeno, servir pesos abertos melhor e concluir tarefas de agente em menos etapas. Nenhuma precifica os erros. Um framework para isso.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.

“Qual modelo é o mais barato para este workflow?” não tem resposta até alguém dizer onde os erros do modelo vão cair.
Nos últimos dias surgiram três bons exemplos de como baixar o custo de rodar IA. A Microsoft treinou um modelo aberto pequeno com 17 documentos e elevou o F1 de extração de 0.44 para 0.81, a um preço por token de cerca de um trigésimo da referência de fronteira mais barata. O Google mostrou que os mesmos pesos do Beam podem servir várias vezes mais tráfego com roteamento ciente de cache. A DeepSeek afirma que sua atualização conclui tarefas de agente com menos etapas e saídas mais curtas. As três são alavancas reais. Nenhuma delas diz quanto custa uma resposta errada, e, para a maioria dos workloads enterprise, esse é o maior número da conta.
O termo que falta na maioria dos business cases
Já defendemos precificar a inferência por tarefa concluída, não por token. Isso é necessário e não suficiente, porque “concluída” esconde uma distinção: concluída corretamente, concluída errada e capturada, concluída errada e não capturada.
Uma unidade mais completa é o custo por saída aceita: o que você paga pela inferência, mais o que você paga para verificar, mais o que os erros que escapam custam a você, dividido pelas saídas que você realmente usa. O modelo pequeno ajustado no teste da Microsoft e as referências de fronteira diferem em cerca de 29 vezes no preço de entrada e em aproximadamente oito vezes na taxa de erro. Qual deles é mais barato depende do preço do terceiro termo, e esse preço é definido por onde, no seu processo, um erro é capturado.
Onde um erro é capturado define seu preço
Capturado por códigoNunca capturado
- Checagem determinísticaSchema, totais, dados mestre: frações de centavo
- Revisor no workflowMinutos de uma pessoa que ia olhar de qualquer forma
- Sistema a jusante ou clienteRetrabalho, notas de crédito, um caso de suporte
- Auditor ou reguladorAchados, programas de remediação, pedidos de evidência
- NinguémDecisões tomadas com dados errados
Cinco regras para precificar um workload
1. Precifique o erro que escapa antes de comparar tokens. Para cada workflow, anote quanto custa uma saída errada se ela chega à próxima etapa, e quem paga: um revisor, um cliente, um time de compliance. Se ninguém consegue nomear o número, a escolha do modelo ainda não está pronta para ser feita.
2. Compre verificação antes de capacidade onde as checagens são baratas. Um modelo com F1 de 0.81 e validade de JSON quase perfeita é uma resposta final ruim e uma boa primeira passada, se checagens determinísticas capturam a maioria de seus erros: totais que precisam fechar, IDs que precisam existir, datas que precisam ser interpretadas. Os agentes de vendas da AWS mostram o mesmo padrão em produção: checagens determinísticas para toda resposta conhecida, juízes de modelo só para o resto. A verificação move os erros para a esquerda do espectro, onde eles são baratos.
3. Gaste tokens de fronteira onde os erros escapam longe. Saídas que vão direto para clientes, contrapartes ou reguladores ficam à direita do espectro. Ali, um preço por token mais alto costuma ser o controle mais barato que você pode comprar. Roteie por consequência, não por tipo de tarefa.
4. Meça a taxa de saída aceita, não o benchmark. Benchmarks medem um modelo no harness de outra pessoa. O que você paga é a fatia de saídas que seu processo aceita sem correção, medida nos seus documentos, nas suas ferramentas e no seu setup de serving, que, como as receitas do Beam mostram, pode mudar a economia tanto quanto o modelo.
5. Reprecifique quando qualquer coisa mudar. Um novo modelo atrás de um alias, uma nova precisão, um novo prompt ou uma nova fonte de dados move a taxa de erro. O preço por saída aceita é uma medição com data, não uma propriedade de um fornecedor.
Em trabalho regulado, o lado direito do espectro é mais longo
Para um banco ou uma farmacêutica, a ponta direita do espectro inclui achados, programas de remediação e, no pior caso, decisões tomadas com dados errados de um jeito que ninguém detectou. Isso muda a aritmética mais do que qualquer preço por token consegue. Também muda o que conta como verificação: uma checagem documentada e versionada que produz evidência vale mais do que o olhar não registrado de um revisor. Isso é consistente com o que chamamos de capacidade de verificação, o novo gargalo.
Nossa visão, e é uma visão, não um fato medido: a maioria dos estouros de custo de IA enterprise que são atribuídos a preços de modelo vai se revelar, quando examinada, como custos de verificação e de erro que nunca foram precificados. Os times que controlam o gasto com IA não serão os que têm o modelo mais barato. Serão os que sabem, para cada workflow, onde seus erros caem e quanto custa capturá-los.