Sua IA respondeu certo. E custou dez vezes mais do que precisava.

Duas empresas lançam o mesmo assistente de IA. Mesmo modelo, mesma função, respostas de qualidade parecida. No fim do mês, a fatura de uma é dez vezes maior que a da outra. Nenhum cliente percebeu diferença no atendimento. A diferença estava inteira em lugares que ninguém vê: quanto de informação cada sistema arrastava a cada resposta, qual modelo era chamado para qual tarefa, e o que era reaproveitado em vez de recalculado. Uma das empresas tem um produto de IA sustentável. A outra tem um protótipo caro disfarçado de produto — e ainda não sabe.

Custo é a dimensão mais ignorada de um projeto de IA e uma das que mais separam quem brinca de quem constrói para valer. Vale entender de onde ele vem, porque é ali que a viabilidade de um produto se decide.

A unidade invisível: o token

Modelos de linguagem não cobram por resposta nem por pergunta. Cobram por token — pedaços de palavra, mais ou menos quatro caracteres cada. E cobram duas vezes: pelos tokens que entram (tudo que você manda ao modelo) e pelos que saem (tudo que ele gera). Uma resposta curta pode parecer barata olhando só para o texto que o cliente recebe. Mas o texto que o cliente recebe é a menor parte da conta.

Porque para gerar aquela resposta, o modelo recebeu muito mais do que a pergunta. Recebeu as instruções de comportamento, o histórico recente da conversa, os trechos da base de conhecimento recuperados para dar contexto, as regras de tom e escopo. Tudo isso são tokens de entrada, cobrados a cada mensagem. O cliente vê três linhas de resposta; o sistema, por baixo, processou o equivalente a duas páginas. É aí que o custo mora — e é aí que ele se controla ou se descontrola.

Alavanca 1: quanto contexto você carrega

A decisão mais cara de todas costuma ser a mais silenciosa: quanto de histórico o sistema arrasta a cada resposta. Um sistema ingênuo, querendo "não esquecer nada", reenvia a conversa inteira ao modelo a cada nova mensagem. Numa conversa de trinta trocas, isso significa que a última resposta pagou pela reciclagem de todas as vinte e nove anteriores — de novo. O custo de uma conversa cresce de forma quadrática quando deveria crescer de forma linear.

Um sistema bem projetado carrega só o necessário: uma janela de contexto dimensionada, resumos das partes antigas em vez do texto integral, e recuperação seletiva do que de fato importa para a pergunta atual. A resposta ao cliente é idêntica. A conta, não.

Alavanca 2: qual modelo para qual tarefa

Existe uma tentação de usar o modelo mais capaz — e mais caro — para tudo. É como contratar um especialista sênior para atender o telefone e também para anotar o recado. Nem toda tarefa dentro de uma conversa exige o mesmo poder de fogo.

Classificar a intenção de uma mensagem ("isso é uma dúvida de preço ou de suporte?") é uma tarefa simples que um modelo pequeno e barato resolve com folga. Redigir a resposta final, com nuance e tom, pode justificar um modelo maior. Sistemas maduros fazem roteamento: usam o modelo certo para cada etapa, reservando o caro para quando ele realmente agrega. A diferença de preço entre um modelo leve e um de ponta é de ordens de grandeza — e boa parte do trabalho de uma conversa não precisa do topo de linha.

Alavanca 3: o que você recalcula versus o que você reaproveita

Há partes de cada requisição que quase não mudam: as instruções de comportamento, as regras da marca, a estrutura fixa do sistema. Reenviá-las e reprocessá-las do zero a cada mensagem é pagar repetidamente pela mesma coisa. Técnicas de cache permitem que essas porções estáveis sejam reaproveitadas entre chamadas, cobradas a uma fração do preço em vez de integralmente.

O mesmo vale para a indexação da base de conhecimento: converter documentos em vetores custa, mas é um custo pago uma vez, não a cada pergunta. Confundir o que precisa ser calculado a cada interação com o que pode ser preparado antes e reutilizado é uma das fontes mais comuns de desperdício — e uma das mais fáceis de corrigir quando alguém sabe onde olhar.

"O preço de um modelo de IA está na tabela pública, igual para todos. O custo de um sistema de IA está na engenharia, e varia em ordens de grandeza para o mesmo resultado. Confundir os dois é como julgar o consumo de um carro pelo preço da gasolina, ignorando que um faz cinco quilômetros por litro e o outro faz vinte."

Por que a demo esconde tudo isso

Nada disso aparece numa demonstração, e por um motivo simples: escala. Uma demo tem dez conversas. A conta é irrelevante em dez conversas — o desperdício de contexto, o modelo caro usado para tudo, a ausência de cache, nada disso pesa quando o volume é mínimo. O sistema parece perfeito porque a ineficiência ainda não teve com o que se multiplicar.

Produção é onde a matemática vira. Dez conversas viram dez mil, e cada pequena decisão de arquitetura passa a ser multiplicada por esse número. Um desperdício de frações de centavo por resposta, invisível na demo, vira uma fatura que corrói a margem do produto inteiro. É exatamente no momento em que o sistema começa a dar certo — quando o volume cresce — que a conta mal projetada começa a doer.

Eficiência é design, não sorte

O ponto não é que IA é cara. É que o custo de uma IA é uma decisão de projeto, não uma constante. O mesmo assistente, com a mesma qualidade de resposta, pode custar dez vezes mais ou dez vezes menos dependendo de escolhas que o cliente nunca vê e que a maioria dos fornecedores nunca menciona — porque exigem um cuidado de engenharia que dá trabalho.

Construir IA que seja boa é uma coisa. Construir IA que seja boa e sustentável em escala é outra disciplina, e é a que decide se um produto sobrevive ao próprio sucesso. Cuidar do custo por resposta não é economia mesquinha; é o que transforma uma boa ideia em um produto que fecha a conta. E esse é, precisamente, o tipo de detalhe invisível que a gente trata como parte do trabalho.