O custo dos tokens é uma linha em sete no custo total de propriedade de uma funcionalidade LLM. Uma conta completa inclui tokens de entrada e de saída, repetições, retrieval e embeddings, uma camada de avaliação, monitorização, supervisão humana e infraestrutura. O preço publicado da API explica normalmente menos de metade do que a funcionalidade custa de facto em produção, e é por isso que as margens brutas SaaS tradicionais de 80-90% se comprimem para 50-60% assim que chamadas ao modelo entram no produto. A pergunta certa não é quanto custa um milhão de tokens, mas quanto custa uma unidade de trabalho que um cliente esteja disposto a pagar.
As sete linhas de custo de uma funcionalidade assente num modelo
A maioria das equipas define o preço de uma funcionalidade de IA diretamente a partir da tabela do fornecedor: tantos dólares por milhão de tokens de entrada, tantos para a saída. Isso é uma linha. A produção faz emergir mais seis, e várias delas são fixas em vez de ligadas ao volume, o que as torna especialmente pesadas no arranque.
| Linha de custo | O que cobre | Comportamento |
|---|---|---|
| Tokens de entrada e de saída | O prompt, o contexto recuperado e a resposta do modelo | Variável, linear com o volume |
| Repetições e falhas | Timeouts, limites de débito, saídas rejeitadas pela validação e reenviadas | Variável, com picos sob carga |
| Retrieval e embeddings | Geração de embeddings, armazenamento vetorial, consultas de pesquisa, reindexação | Misto: indexação fixa, consulta variável |
| Camada de avaliação | Conjuntos de testes, execuções de avaliação antes de cada alteração de prompt ou de modelo | Fixo por ciclo de desenvolvimento |
| Monitorização e registo | Captura de entradas e saídas, métricas de qualidade, alertas, retenção | Fixo com uma componente de volume |
| Supervisão humana | Revisão por amostragem, tratamento de escalamentos, etiquetagem de casos limite | Variável em horas-pessoa |
| Infraestrutura e integração | Camada de abstração sobre fornecedores, filas, cache, segurança e permissões | Fixo, dilui-se à medida que crescem |
Porque é que o preço publicado dos tokens induz em erro
Três desvios sistemáticos separam a tabela de preços da fatura.
A saída custa muito mais do que a entrada. Na maioria dos fornecedores um token de saída é cobrado cinco a oito vezes mais do que um token de entrada. Uma funcionalidade que gera respostas longas paga essa extensão a dobrar, o que faz do limite ao comprimento da saída a poupança mais barata disponível em qualquer dia.
O contexto cresce em silêncio. A partir do momento em que entra o retrieval, cada chamada transporta fragmentos de documentos, histórico de conversa e instruções de sistema. Um prompt que ocupa três linhas no código são vários milhares de tokens em trânsito, e essa diferença multiplica-se em cada chamada.
As repetições nunca aparecem no plano. Uma chamada que falha na validação, na formatação ou por timeout é reenviada e faturada duas vezes. Sob carga real, a taxa de repetição é normalmente a diferença entre a previsão e a fatura.
A fórmula: o custo por unidade de trabalho
Em vez de seguir o consumo total de tokens, defina uma unidade de trabalho com significado de negócio: um ticket resolvido, um documento resumido, uma lead enriquecida, uma linha classificada. A aritmética passa então a ser esta.
| Componente | Como calcular | Nota |
|---|---|---|
| Custo médio por chamada | (tokens de entrada × preço de entrada) + (tokens de saída × preço de saída) | Meça, não estime |
| Chamadas por unidade | Incluindo as etapas de retrieval, encaminhamento, classificação e verificação | Um agente típico faz 3 a 8 chamadas por unidade |
| Multiplicador de repetição | 1 a dividir pela taxa de sucesso à primeira tentativa | 85% de sucesso equivale a um multiplicador de 1,18 |
| Custo da supervisão humana | Taxa de escalamento × custo horário carregado × tempo de tratamento | Normalmente a linha mais pesada |
| Imputação dos custos fixos | Custo fixo total a dividir pelas unidades mensais | Desce à medida que o volume sobe |
Os valores de referência publicados até 2026 no apoio ao cliente situam um ticket resolvido por IA entre meio dólar e dois dólares ao nível da unidade, contra seis a doze dólares para um contacto tratado por uma pessoa. A diferença parece decisiva, mas estreita-se consideravelmente depois de reintroduzidas a supervisão, a avaliação e a infraestrutura, e alguns números publicados colocam o custo totalmente carregado de uma resolução automatizada mais perto dos cinco dólares. A distância entre estas duas leituras é exatamente a distância entre custo dos tokens e custo de propriedade.
As três alavancas que mexem mesmo na fatura
Antes de mudar a arquitetura, há três descontos que os fornecedores já oferecem e que a maioria das equipas não explora por completo.
| Alavanca | Ordem de grandeza | Quando se aplica |
|---|---|---|
| Cache de prompts | Leituras em cache cobradas a cerca de um décimo do preço de entrada padrão | Instruções de sistema estáveis, documentos de base recorrentes |
| Processamento em lote | Cerca de metade do preço | Tudo o que não exige resposta em tempo real |
| Escolha do modelo por tarefa | Dezenas de vezes de diferença entre gamas de modelos | Classificação, extração e encaminhamento não precisam de um modelo frontier |
O que isto faz à demonstração de resultados
O software tradicional vive com 80-90% de margem bruta porque o custo de servir mais um utilizador tende para zero. Uma funcionalidade assente num modelo quebra esse pressuposto: cada utilização traz um custo de computação real. As publicações até 2026 colocam a margem bruta destas funcionalidades na faixa dos 50-60%.
A implicação prática não é que a funcionalidade não valha a pena, mas que o modelo de preço tem de acompanhá-la. Um preço por posto, insensível ao uso, transforma os utilizadores intensivos num défice silencioso: quando cinco por cento dos utilizadores geram a maior parte do custo de computação, um preço fixo limita-se a subsidiá-los. Tratamos disto em separado no artigo sobre o preço de um produto assente num modelo, e a ligação entre custo unitário e rentabilidade global no modelo unitário de um negócio digital.
Como medir na prática
- Marque cada chamada à API com o identificador da unidade de trabalho que serve, e não apenas com um ID de utilizador. Sem isso não conseguirá reconstruir o custo por unidade depois.
- Guarde separadamente tokens de entrada, tokens de saída e número de tentativas. Um total de custo único esconde tudo o que poderia ser corrigido.
- Trate a taxa de sucesso à primeira tentativa como uma métrica de produto, não de infraestrutura. Multiplica o custo diretamente.
- Impute os custos fixos às unidades todos os meses, ou uma funcionalidade em crescimento parecerá pior do que é.
- Defina um teto de custo por unidade como critério de lançamento, com o mesmo peso de um critério de qualidade. Uma funcionalidade que ultrapassa o teto não sai.
Este último ponto liga-se a uma questão mais ampla: como definir condições de aceitação para um sistema cuja saída é probabilística. Explicamo-lo no artigo sobre critérios de aceitação de uma funcionalidade de IA, e a vertente comercial mais ampla insere-se nas nossas áreas de especialização.
Perguntas frequentes
Que parte do custo total de propriedade é a fatura da API?
Não há um número único, mas em implementações com supervisão humana, camada de avaliação e monitorização, a linha da API é normalmente minoritária no custo total. Quanto mais automatizado e menos supervisionado for o produto, maior se torna a sua quota. É por isso que as sete linhas têm de ser calculadas e não deduzidas de uma tabela de preços.
Como estimar o custo antes de existir produção?
Faça passar uma amostra representativa de várias centenas de unidades de trabalho reais por todo o pipeline e meça tokens, chamadas e repetições tal como ocorrem. Estimar apenas a partir do prompt subavalia quase sempre, porque ignora o contexto recuperado e as falhas.
Um modelo mais pequeno é sempre mais barato?
Não. Um modelo barato que falha mais vezes produz repetições, saídas mais longas e escalamentos para pessoas, que custam todos mais do que a diferença de preço dos tokens. A comparação correta é o custo por unidade de trabalho concluída com sucesso, não o preço por milhão de tokens.
Quando vale a pena passar para um modelo autoalojado?
Quando a carga é estreita, repetitiva e de volume elevado, e quando o custo ou a latência da API se tornou a restrição determinante. Com pouco volume ou numa tarefa ampla, o custo de engenharia e manutenção de um modelo próprio ultrapassa normalmente a poupança.
Se seguir apenas uma métrica, qual deve ser?
O custo por unidade de trabalho concluída com sucesso, revisto mensalmente. Absorve o preço dos tokens, a taxa de falha, os escalamentos e a eficiência do retrieval, e é o único número diretamente comparável com o vosso preço e com o custo da alternativa humana.