O que é uma calculadora de preço por consulta? Guia de custos de API LLM

Uma calculadora de preço por consulta é uma ferramenta que estima o custo de API de uma única chamada a um modelo de linguagem de grande porte (LLM). Você informa o número de tokens de entrada (seu prompt, o contexto e os documentos recuperados), o número esperado de tokens de saída (a resposta do modelo) e o modelo desejado. A calculadora multiplica cada um pela tarifa por token publicada pelo provedor e retorna o custo por consulta, além de um total mensal projetado conforme o volume de chamadas esperado.

O objetivo central é tornar os custos de IA previsíveis. Sem uma calculadora, é fácil subestimar a velocidade com que os tokens se acumulam em escala. Uma consulta de US$ 0,012 parece insignificante, mas com 10.000 chamadas por dia isso dá US$ 120 por dia, ou US$ 3.600 por mês, saindo de um único endpoint. As calculadoras de preço por consulta revelam isso antes do deploy, não depois.

O que uma calculadora de preço por consulta mostra

• Custo por consulta - o valor exato de uma chamada de API com seus números de tokens e seu modelo.
• Projeções diárias e mensais - aplica o custo por consulta ao volume de chamadas esperado.
• Detalhamento de entrada e saída - mostra quanto do custo vem do prompt e quanto vem da resposta, já que tokens de saída são mais caros.
• Comparação de modelos - algumas calculadoras permitem comparar ao mesmo tempo o custo da mesma consulta em vários modelos.

Os provedores de LLM cobram por token: uma unidade de texto equivalente a cerca de 0,75 palavra em inglês (ou aproximadamente 4 caracteres). Os preços são por milhão de tokens ($/M), separadamente para entrada e saída. Os tokens de entrada incluem tudo o que você envia: o prompt de sistema, o histórico de conversa, a mensagem do usuário, os trechos de documentos recuperados por pipelines RAG e os esquemas de funções ou ferramentas. Os tokens de saída são a resposta gerada pelo modelo.

Tokens de entrada e de saída são cobrados separadamente. Os de saída custam de 3 a 5 vezes mais que os de entrada porque gerar texto é computacionalmente mais caro que processar contexto.

Por que tokens de saída custam mais

Durante a inferência, processar os tokens de entrada exige uma única passagem direta pelo modelo. Gerar tokens de saída exige um loop autorregressivo: o modelo produz um token por vez, e cada passo depende do anterior. Esse processo sequencial é muito mais intensivo em GPU por token, e é por isso que os provedores cobram um prêmio significativo na saída. Nos preços do GPT-4o, a entrada custa US$ 2,50/M e a saída US$ 10,00/M - um múltiplo de 4. Isso tem uma implicação prática direta: respostas longas e prolixas custam desproporcionalmente mais que as concisas.

Como os tokens se traduzem em tamanhos reais de prompt

• Prompt curto + resposta curta (ex.: "Classifique este texto"): ~50-200 tokens no total.
• Mensagem de sistema + consulta com contexto: ~500-2.000 tokens de entrada, 100-500 de saída.
• Consulta RAG com trechos de documentos: ~2.000-8.000 tokens de entrada, 300-1.000 de saída.
• Fluxo agêntico com resultados de ferramentas e histórico: ~8.000-32.000 tokens de entrada por chamada.
• Geração longa (artigo, código): ~1.000-4.000 tokens de entrada, 1.000-4.000 de saída.

Estimar custos por consulta com precisão exige conhecer três números: o número médio de tokens de entrada por chamada, o número médio de tokens de saída por chamada e seu volume diário de chamadas. Os dois primeiros são melhores medidos empiricamente com o contador de tokens do provedor ou com o campo `usage` nas respostas da API, e não estimados a partir de contagem de palavras.

Passo 1 - Meça o uso real de tokens em desenvolvimento

Toda resposta de API de LLM inclui um objeto `usage` com `prompt_tokens`, `completion_tokens` e `total_tokens`. Registre esses dados durante o desenvolvimento em uma amostra representativa de 50-100 consultas reais. Calcule a média e o percentil 95 tanto da entrada quanto da saída. Para planejar custos, use o percentil 95 da entrada e a média da saída: isso considera contextos grandes atípicos sem superestimar a chamada típica.

Passo 2 - Estime o volume mensal

Para aplicações em produção, estime usuários ativos diários × consultas médias por sessão × chamadas de API por consulta. Um chatbot com 1.000 usuários diários, 5 mensagens por sessão e 1 chamada de API por mensagem gera 5.000 chamadas por dia. Multiplique o custo por chamada pelo volume diário e depois por 30 para a projeção mensal. Inclua uma margem de 30-50 % para picos de tráfego e iterações de engenharia de prompt.

Passo 3 - Compare entre níveis de modelo

Rode os mesmos números de tokens em vários níveis de modelo para identificar onde os requisitos de qualidade permitem um modelo mais barato. Muitas tarefas - classificação, extração de entidades, resumo simples, respostas de FAQ - alcançam qualidade aceitável com um modelo menor e mais barato. Reservar modelos de fronteira (classe GPT-4, classe Claude 3.5 Sonnet) para o subconjunto de tarefas que realmente os exige e encaminhar tarefas simples para modelos mais baratos costuma ser a redução de custo mais rentável.

Os preços dos modelos mudam com frequência: os provedores os reduziram bastante conforme a concorrência aumentou. A tabela abaixo mostra faixas de preço representativas de meados de 2026 para ilustrar a estrutura de custos. Sempre confirme os preços atuais na página oficial de cada provedor antes de montar projeções de custo para produção.

A diferença de custo entre o nível mais barato e o mais caro abrange duas ordens de magnitude. Uma aplicação com 10.000 consultas por dia usando um modelo classe o1 custa cerca de US$ 60-240 por dia; a mesma aplicação com GPT-4o Mini custa US$ 1,50-20 por dia. Decisões de roteamento baseadas na complexidade da tarefa - usar um classificador de consultas para direcionar cada chamada ao nível de modelo adequado - podem reduzir o gasto total de API em 60-80 % em pipelines com complexidade mista.

Janela de contexto versus custo

Janelas de contexto maiores permitem incluir mais informação por consulta, mas mais tokens no prompt significa custo de entrada maior. Uma janela de 100 mil tokens só vale a pena se o contexto adicional realmente melhorar a qualidade da resposta para aquela tarefa. Na maioria das aplicações de geração aumentada por recuperação (RAG), 2.000-4.000 tokens de contexto recuperado produzem resultados quase tão bons quanto 20.000 tokens, com custo de entrada de 5 a 10 vezes menor. Sempre compare qualidade e tamanho de contexto antes de fixar prompts grandes em produção.

A otimização de custo por consulta tem duas alavancas: reduzir os tokens por consulta e reduzir o preço por token. As estratégias a seguir atacam as duas e estão ordenadas, de forma aproximada, do menor para o maior esforço de implementação.

• Comprima os dados de entrada antes de injetá-los - converta payloads JSON, CSV ou YAML para o formato TOON antes de incluí-los nos prompts. O Conversor JSON para TOON reduz a contagem de tokens em 30-60 % sem perda de informação.
• Use o modelo mais barato que atenda aos requisitos - teste cada tipo de tarefa em níveis de modelo menores antes de presumir que precisa de um modelo de fronteira. Muitas tarefas de extração, classificação e resumo funcionam bem com GPT-4o Mini ou Gemini Flash.
• Encurte e enxugue os prompts de sistema - audite seu prompt de sistema em busca de instruções redundantes, exemplos de formatação longos e ressalvas repetidas. Cada token removido economiza dinheiro em todas as chamadas de API.
• Limite o tamanho da saída com max_tokens - peça respostas concisas e defina um teto rígido de max_tokens. Tokens de saída custam de 3 a 5 vezes os de entrada, então reduzir respostas prolixas corta direto a parte mais cara da conta.
• Ative o cache de prompt - use o cache nativo do provedor para prompts de sistema estáticos e exemplos few-shot. Tokens em cache custam de 50 a 90 % menos que tokens sem cache na OpenAI e na Anthropic.
• Cacheie respostas de consultas frequentes - para consultas determinísticas ou quase determinísticas, guarde a resposta do LLM em cache e sirva-a para entradas idênticas repetidas sem fazer chamada de API.

Compressão de tokens: o caminho mais rápido para economizar

Em aplicações que enviam dados estruturados a LLMs - catálogos de produtos, cadastros de usuários, exportações analíticas, respostas de API -, a compressão de tokens de entrada oferece a redução de custo mais rápida e consistente. Converter um payload JSON de 2.000 tokens para o formato TOON o reduz a cerca de 800-1.400 tokens. A US$ 3,00/M de tokens de entrada e 50.000 consultas diárias, essa única mudança economiza US$ 0,09-0,18 por dia: cerca de US$ 33-66 por mês sem impacto na qualidade. Para dados CSV, o Conversor CSV para TOON alcança 40-60 % de economia de tokens em conjuntos tabulares, e o Conversor YAML para TOON cuida de configurações e dados estruturados em YAML.

Para desenvolvedores solo e projetos pequenos, os custos de tokens raramente são relevantes: US$ 5-20 por mês para experimentação e desenvolvimento. O problema aparece quando um recurso escala para volume de produção, quando os prompts incluem payloads de contexto grandes ou quando um pipeline encadeia várias chamadas de API por interação do usuário. Esses são os cenários em que os cálculos de preço por consulta se tornam críticos.

Pipelines agênticos e de várias etapas

Fluxos agênticos que encadeiam várias chamadas ao LLM - planejamento, uso de ferramentas, reflexão, resumo - podem acumular 10.000-100.000 tokens em uma única requisição do usuário que parece uma só interação. Cada resultado de ferramenta e cada turno de conversa é reinjetado como contexto para a chamada seguinte, fazendo a contagem de tokens crescer de forma quadrática com o número de etapas. Nesses pipelines, estimar o custo por requisição exige multiplicar o custo por consulta pelo número médio de chamadas ao LLM por execução.

Aplicações RAG com trechos de documento grandes

Pipelines de geração aumentada por recuperação injetam os trechos recuperados em cada prompt. Se a estratégia de divisão produz trechos grandes (1.000-4.000 tokens cada) e recupera de três a cinco trechos por consulta, a contagem de tokens de entrada pode chegar a 5.000-20.000 por chamada antes mesmo de incluir a pergunta do usuário. Comprimir os trechos recuperados em um formato como TOON - ou reduzir o tamanho dos trechos no pipeline de embeddings - baixa diretamente o custo por consulta sem mudar a qualidade da recuperação. Para entender onde a validação de saída estruturada se encaixa nesse tipo de pipeline, o guia do Guardrails AI cobre a camada de validação que vem depois da recuperação.