O Framework Definitivo para Escolher seu LLM: Latência, Custo por Resultado e o Mito do "Melhor Modelo"

O Framework Definitivo para Escolher seu LLM: Latência, Custo por Resultado e o Mito do "Melhor Modelo"

Se você lidera um projeto de IA no Brasil em 2026, provavelmente já viveu essa cena: a equipe testa cinco modelos, cada um vence em um benchmark diferente, e a decisão final acaba sendo tomada por afinidade pessoal ou pelo que o fornecedor mais insistente recomendou.

Eu acompanho esse ciclo há anos, e ele raramente produz a escolha certa.

O problema não é falta de informação. É excesso dela, sem um critério de decisão. Benchmarks de raciocínio, tabelas de preços por token, rankings de ELO — tudo isso existe em abundância.

O que falta é um framework que traduza esses números em uma decisão prática para o seu caso de uso específico.

Meu argumento central é simples: o melhor LLM para o seu projeto raramente é o modelo mais inteligente disponível. É o modelo cujo custo por resultado — não por token — se alinha com a natureza da sua tarefa, sua latência aceitável e sua tolerância a controle técnico.

Por que isso importa agora, em outubro de 2026? Porque o mercado amadureceu a ponto de a diferença de inteligência entre os modelos de ponta ter encolhido drasticamente, enquanto as diferenças de preço, latência e flexibilidade de implantação continuam enormes.

Em outras palavras, a escolha deixou de ser sobre qualidade bruta e passou a ser sobre engenharia de decisão.

Nesta coluna, eu construo com você um framework em três eixos — latência versus inteligência, custo por token versus custo por resultado, open source versus proprietário. E o aplico a quatro casos de uso brasileiros: jurídico, saúde, marketing e engenharia de software.

Ao final, você terá um roteiro concreto, não uma opinião vaga.

Latência versus Inteligência: O Trade-off Que Ninguém Quer Assumir

Todo projeto de LLM começa com uma pergunta que quase ninguém faz explicitamente: quanto tempo o usuário pode esperar por uma resposta melhor? Essa é, na minha avaliação, a pergunta mais negligenciada da indústria.

Pense comigo. Um chatbot de atendimento que responde em 8 segundos com 94% de precisão pode ser pior para o negócio do que um que responde em 1,5 segundo com 91%. O usuário não percebe a diferença de precisão em uma interação isolada.

Mas percebe — e abandona — a diferença de latência em todas elas.

Na prática, eu divido qualquer workload em três classes de tolerância. A primeira é interativa de alto volume: atendimento, classificação de tickets, roteamento de intenções. Aqui, latência abaixo de 2 segundos é requisito, e inteligência de fronteira é desperdício.

Modelos menores e mais rápidos — como as variantes mini e flash das principais famílias — resolvem 80% desses casos a uma fração do custo.

A segunda classe é analítica assíncrona: análise de contratos, sumarização de prontuários, geração de relatórios. Se o processo roda em batch e o resultado chega em minutos, latência deixa de ser critério.

Você pode — e deve — usar o modelo mais capaz disponível, porque cada ponto percentual de precisão se multiplica por milhares de execuções.

A terceira classe é agente em tempo real: sistemas que encadeiam múltiplas chamadas para completar uma tarefa. Aqui está a armadilha mais sutil do mercado.

Um agente que faz dez chamadas com um modelo de raciocínio pesado pode levar dois minutos e custar dez vezes mais que um agente com modelo intermediário que entrega o mesmo resultado. Eu vi equipes queimarem orçamento inteiro nisso.

O dado que eu gostaria que mais gestores internalizassem: em benchmarks de raciocínio como o MMLU e avaliações de ELO em arenas de comparação, os modelos de ponta das três grandes famílias — OpenAI, Anthropic e Google — convergiram para margens de poucos pontos percentuais entre si.

A distância real entre o primeiro e o terceiro lugar em tarefa genérica é frequentemente menor que a variação de desempenho do mesmo modelo entre prompts bem e mal escritos.

Isso significa que a conversa sobre "qual modelo é o mais inteligente" virou, na maior parte dos casos, uma discussão de nicho. O que separa projetos bem-sucedidos de projetos malsucedidos não é o modelo escolhido — é a adequação do modelo à classe de tolerância da tarefa.

Minha recomendação operacional: antes de escolher qualquer modelo, meça a distribuição de latência aceitável do seu caso de uso em três números — p50, p95 e o limite de abandono do usuário.

Se você não tem esses números, você não tem um requisito de latência; você tem uma suposição disfarçada de decisão técnica.

E há um detalhe brasileiro que agrava tudo isso: latência de rede. Servir modelos a partir de regiões da AWS em Virgínia ou Oregon adiciona 120 a 200 milissegundos de round-trip para usuários em São Paulo.

Com modelos de raciocínio que geram milhares de tokens de cadeia de pensamento, esse overhead é irrelevante. Com modelos rápidos em chat interativo, ele é perceptível e mensurável.

Por isso, eu insisto: o trade-off latência versus inteligência não é uma escolha filosófica. É uma planilha com três colunas — tempo aceitável, ganho de precisão e custo marginal — que qualquer equipe consegue preencher em uma tarde.

Custo por Token versus Custo por Resultado: A Métrica Que Muda Tudo

Aqui está o primeiro insight que você não encontrará facilmente em outro lugar: custo por token é a métrica mais enganosa da indústria de IA. Ela é útil para comparar fornecedores entre si, mas é quase inútil para decidir qual modelo usar em um projeto.

O que importa é o custo por resultado correto — e resultado correto significa uma resposta que não precisa de revisão humana, não gera retrabalho e não quebra um processo downstream.

Um modelo barato que acerta 85% das vezes pode custar mais que um modelo caro que acerta 99%, assim que você precifica o erro.

Vamos fazer a conta juntos, porque ela é simples e reveladora. 000 documentos por mês. dev/gemini-api/docs/pricing).

Um documento de 20 páginas pode representar 30.000 tokens de entrada e 3.000 de saída.

000 documentos. Parece barato. Mas se a taxa de erro relevante — alucinação de citação, interpretação errada de cláusula — for de 5%, você tem 500 documentos errados por mês exigindo revisão humana.

Agora compare com um modelo de fronteira. com/api/pricing/), os modelos de raciocínio de ponta operam em faixas substancialmente maiores — na casa de dezenas de dólares por milhão de tokens de saída, dependendo da configuração.

Digamos que o custo por documento triplique ou quadruplique, chegando a US$ 0,06 ou US$ 0,07. O mês inteiro custa US$ 600 ou US$ 700.

Se a taxa de erro cai para 0,5%, você tem 50 documentos problemáticos em vez de 500. 000 mensais. Se cada erro exigir apenas dez minutos de revisão, os 450 erros evitados já pagam a diferença de custo com folga.

Esse é o cálculo que quase nenhum time faz: o custo do erro humano embutido na escolha do modelo barato. Eu chamo isso de custo oculto da economia — e ele é, com frequência, dez vezes maior que a economia aparente.

Por outro lado, o raciocínio inverso também vale. Em um pipeline de marketing que gera centenas de variações de anúncio por dia, o erro é barato — um copy ruim é descartado em segundos pelo próprio time.

Aqui, o modelo econômico vence esmagadoramente, porque o custo por resultado aceitável é mínimo e o volume é alto.

Em outras palavras, a pergunta correta não é "quanto custa o token". É "quanto custa quando o modelo erra, com que frequência ele erra nessa tarefa específica, e quem paga a conta do erro".

Uma técnica que eu recomendo para todos os meus clientes: rode uma avaliação com 200 a 500 casos reais do seu domínio, meça a taxa de sucesso de cada modelo candidato, e calcule o custo total por resultado correto — incluindo o custo horário de quem revisa.

Essa tabela de duas colunas vale mais que qualquer benchmark público.

E atenção a um detalhe de precificação que muda contas grandes: os modelos de raciocínio cobram pelos tokens de pensamento intermediário, não apenas pela resposta final. 000 tokens antes de responder pode custar mais que um modelo sem raciocínio explícito com preço nominal superior.

Leia as tabelas de preços da Anthropic e da OpenAI com esse olhar — a coluna de entrada e a de saída contam histórias diferentes dependendo da arquitetura do modelo.

Open Source versus Proprietário: Soberania, Controle e o Custo Real da Liberdade

A terceira dimensão do framework é a mais ideologizada — e por isso a que mais exige frieza analítica. A pergunta não é "open source ou proprietário?", mas "quem precisa controlar o quê no seu stack?".

Eu começo pelo caso a favor do open source, porque ele é genuinamente forte. Modelos abertos — Llama, Qwen, Mistral e a crescente família de modelos brasileiros e chineses de peso aberto — oferecem três vantagens estruturais.

Primeiro, controle total sobre a implantação: o modelo roda onde você quiser, incluindo infraestrutura nacional, o que importa para conformidade com a LGPD.

Segundo, ausência de mudança unilateral de comportamento. Quando um fornecedor proprietário atualiza um modelo de API, seu produto pode mudar de comportamento da noite para o dia — eu já vi sistemas inteiros de prompt engineering quebrarem com um push de versão.

Com open source, a versão que você validou é a versão que fica em produção.

Terceiro, custo marginal em escala extrema. Depois de amortizado o custo de infraestrutura, cada token adicional custa apenas eletricidade e GPU.

Para workloads acima de certo volume — eu coloco o ponto de equilíbrio prático em torno de centenas de milhões de tokens mensais — open source tende a vencer em custo.

Agora, o outro lado da moeda, que os entusiastas raramente mencionam. Rodar um modelo aberto de qualidade exige engenharia de infraestrutura real: GPUs, serving otimizado, quantização, observabilidade.

O custo de manter isso no Brasil — onde GPUs de ponta custam mais e escassez é maior — frequentemente apaga a economia de tokens abaixo do volume de equilíbrio.

Além disso, a fronteira da inteligência continua nos modelos proprietários. Em outubro de 2026, os modelos abertos alcançaram os proprietários em tarefas genéricas de linguagem.

Mas em raciocínio profundo, janelas de contexto longas com precisão sustentada e capacidades multimodais de ponta, a diferença ainda existe — e em domínios sensíveis, ela importa.

Meu posicionamento, depois de acompanhar dezenas de implementações: open source é a escolha certa quando o requisito é controle, não quando o requisito é economia. Se sua motivação é LGPD ou estabilidade de versão, vá de modelo aberto com convicção.

Se sua motivação é reduzir a fatura mensal, faça a conta completa antes — incluindo salário do time de infraestrutura.

E existe um caminho híbrido que eu defendo cada vez mais: roteamento por sensibilidade. Dados sensíveis — prontuários, peças processuais sob sigilo, dados pessoais — vão para um modelo aberto em infraestrutura própria. Dados públicos e tarefas genéricas vão para APIs proprietárias.

É mais complexo de operar, mas resolve a tensão regulatória sem sacrificar a fronteira de qualidade onde ela importa.

Um ponto que quase ninguém discute no Brasil: o custo de saída. Alguns fornecedores cobram egresso de dados ao mover workloads entre nuvens, e o câmbio dólar-real adiciona volatilidade de 10 a 15% ao orçamento anual de qualquer API cobrada em USD.

Eu recomendo contratar crédito consolidado ou planos com desconto por volume quando o workload justificar — as três grandes oferecem mecanismos de reserva de capacidade que reduzem o custo unitário de forma significativa.

A pergunta que fecha esta seção é a que você deve levar para a próxima reunião de arquitetura: qual parte do seu dado, de fato, precisa ficar sob seu controle? Raramente é toda ela.

Quatro Casos Brasileiros: Jurídico, Saúde, Marketing e Código

Agora eu aplico o framework aos quatro domínios que mais aparecem no meu consultório — e que revelam como a mesma lógica produz respostas diferentes.

Jurídico. O litígio brasileiro é um deserto de volume e um oceano de risco. Petições, contratos e jurisprudência geram milhões de tokens mensais, mas um único erro — uma citação alucinada de julgado — pode custar reputação e sanção.

Minha recomendação é estratificada: triagem e classificação de documentos com modelo econômico; análise substantiva de peças com modelo de fronteira; e, para escritórios com volume acima de 50 milhões de tokens mensais, avaliação séria de um modelo aberto em infraestrutura nacional, com dados sensíveis nunca saindo do perímetro.

O custo por resultado aqui é dominado pelo custo do erro — revisão jurídica é caríssima.

Saúde. Este é o domínio onde eu sou mais conservador. Prontuários contêm dado sensível por definição, e a ANPD e o CFM ainda estão construindo o arcabouço regulatório específico para IA clínica.

Eu não recomendo, em 2026, nenhum workload de decisão clínica em API proprietária internacional sem contrato de tratamento de dados robusto. Sumarização administrativa, agendamento e estruturação de texto livre em campos estruturados? Sim, com modelo aberto local ou API com garantias contratuais. Suporte à decisão clínica?

Apenas com validação clínica própria, independente do modelo.

Marketing. Aqui a lógica se inverte completamente: volume alto, erro barato, sensibilidade de dado baixa. Geração de variações criativas, adaptação de tom de voz, tradução e localização para o português brasileiro — tudo isso pertence à classe de modelos econômicos e rápidos.

O único ponto de nuance é a avaliação de qualidade de marca, que ainda exige curadoria humana. O erro aqui não é o copy ruim; é o copy ruim que passa sem revisão.

Código. A engenharia de software brasileira vive um momento peculiar: assistentes de código proprietários dominam a experiência de desenvolvedor individual, mas empresas com propriedade intelectual sensível hesitam em enviar repositórios para APIs externas.

Minha posição: para o desenvolvedor individual e a startup, os assistentes proprietários de ponta pagam-se em semanas de produtividade.

Para empresas com código estratégico, o movimento de 2026 é o modelo aberto de código em infraestrutura própria — os modelos abertos já entregam 90% da experiência para tarefas de completar e refatorar código.

Repare no padrão que emerge dos quatro casos: a escolha ideal varia menos pelo setor e mais pela assimetria entre custo do erro e volume de execução. Jurídico e saúde têm erro caro e volume moderado — favorecem fronteira e controle.

Marketing tem erro barato e volume alto — favorece economia e velocidade. Código é o caso híbrido mais interessante, onde a sensibilidade do dado decide mais que a qualidade do modelo.

Se a mesma lógica funciona em quatro setores tão distintos, por que escolher por manchete?

O Framework em Uma Página: Como Decidir na Prática

Vou condensar tudo em um roteiro de cinco passos que você pode aplicar na próxima segunda-feira, sem depender de consultoria externa.

Passo 1 — Classifique a tarefa por tolerância. Interativa de alto volume, analítica assíncrona ou agente encadeado? Isso define sua faixa de latência e, de quebra, elimina metade dos candidatos antes de qualquer teste.

Passo 2 — Precifique o erro. Estime a taxa de erro aceitável do seu processo e o custo humano de cada erro. Multiplique. Esse número, e não o preço do token, define quanto você pode gastar por execução.

Passo 3 — Rode a avaliação própria. 200 a 500 casos reais, medidos com a métrica que importa para o seu negócio. Benchmarks públicos servem para eliminar candidatos, nunca para escolher o vencedor.

Passo 4 — Decida a arquitetura de dados. Alguma parte do dado precisa ficar sob seu controle por LGPD, contrato ou estratégia? Se sim, o roteamento híbrido — sensível no open source, genérico na API — é o caminho de menor risco.

Passo 5 — Reavalie a cada trimestre. O mercado muda em ciclos de semanas. O modelo que venceu em janeiro pode ser superado em custo por resultado em julho. Eu mantenho a avaliação do passo 3 como suíte de regressão permanente.

Uma última observação de quem já viu muitos projetos morrerem: o framework não substitui julgamento — ele organiza as informações para que o julgamento seja sobre o que realmente importa.

A decisão final sempre envolverá contexto que nenhuma tabela captura: cultura do time, apetite de risco do jurídico interno, relação com fornecedores.

O Que Eu Faria Se Começasse Hoje

Vou fechar com a perspectiva que eu assumiria se estivesse começando um projeto do zero, em outubro de 2026, com orçamento enxuto e pressão por resultado.

Eu começaria com um modelo econômico de API — não por modéstia, mas porque ele me daria um baseline barato e mensurável.

Só subiria para modelo de fronteira onde a taxa de erro do baseline doesse de verdade, e só consideraria open source quando o volume justificasse a infraestrutura.

A maioria dos projetos faz o caminho inverso — começa pelo modelo mais caro e depois tenta cortar custo — e eu acho isso um erro de sequência, não de escolha.

Meu próximo passo concreto para você: escolha um único caso de uso do seu negócio, rode a avaliação de 200 casos com três modelos candidatos, e calcule o custo por resultado correto de cada um. Uma semana de trabalho.

É o investimento com melhor retorno que conheço em engenharia de IA hoje.

O mercado de LLMs vai continuar lançando modelos todos os meses, e a ansiedade de ficar para trás é real.

Mas eu acredito que a vantagem competitiva em 2026 não está em ter o modelo mais novo — está em ter o processo de decisão mais rápido e mais honesto. Quem tem framework decide em dias; quem não tem, decide por manchete.

E você, qual decisão de modelo está adiando por falta de um critério claro?

Fontes verificadas

• Preços da API da OpenAI
• Preços da API Claude — Anthropic
• Preços da API Gemini — Google AI