Quanto um recurso de IA realmente custa: a unit economics da inferência

O recurso de fim de semana e a fatura no fim do mês

Construir um recurso de IA hoje é trabalho de um fim de semana. Algumas chamadas de API, um prompt, um pouco de código de integração – e de repente o chatbot responde dúvidas de suporte, o assistente resume documentos, a ferramenta escreve descrições de produto. O protótipo parece mágica, e isso induz a uma conclusão perigosa: a de que o mais difícil já passou.

Não passou. Construir nunca foi a parte cara. A parte cara é rodar esse recurso para cada usuário, todo dia, para sempre. E essa é a conta que quase ninguém faz antes de lançar. Fazem a conta quando a primeira fatura de nuvem de verdade chega – e a essa altura o produto já está no ar, já está precificado, já foi prometido ao cliente.

A verdade incômoda por trás de todo produto de IA: cada token custa dinheiro. E, ao contrário do software tradicional, isso não soma zero. Soma a cada clique.

A quebra no modelo de custos

Para entender por que a IA se comporta de outro jeito aqui, vale lembrar por que o SaaS clássico era um negócio dos sonhos antes de mais nada.

No software comum, o custo marginal do próximo usuário é próximo de zero. O código já está escrito, os servidores já estão rodando – seja o décimo ou o décimo milésimo usuário que carrega uma página, o custo é praticamente o mesmo, ou seja, quase nada. É por isso que crescimento em SaaS é só ganho: cada cliente novo traz receita, mas quase nenhum custo extra. Quanto maior você fica, mais gorda a margem.

A IA inverte esse princípio. Cada interação chama um modelo, e cada chamada de modelo custa dinheiro – por token, em cada requisição. O décimo milésimo usuário não é de graça. Ele custa exatamente o que o primeiro custou, multiplicado pelo número de requisições que faz. Aqui, escalar não multiplica só a receita, multiplica o custo. Quem leva o instinto de SaaS – "mais usuários = mais lucro" – para um produto de IA está deixando metade da equação de fora.

A conta que ninguém faz

A aritmética não é complicada. É justamente isso que torna tão impressionante como raramente alguém a escreve. O custo de um recurso de IA vem, grosso modo, de:

(tokens de entrada + tokens de saída) × preço por token × chamadas por tarefa × tarefas por usuário × usuários.

Vamos rodar isso com números redondos e ilustrativos. Pegue uma requisição simples: 2.000 tokens entram (a pergunta mais um pouco de contexto), 500 saem. Num modelo que custa, digamos, US$ 3 por milhão de tokens de entrada e US$ 15 por milhão de tokens de saída, uma única requisição fica em torno de 1,5 centavo. Ridiculamente pouco. É aqui que a maioria dos times para de fazer a conta de cabeça – e é exatamente aqui que o problema começa.

Agora coloque a realidade por cima:

• Contexto longo e RAG. Para obter boas respostas, você enfia documentos relevantes em cada chamada. Aqueles 2.000 tokens de entrada viram rapidamente 20.000. A requisição agora custa mais perto de 7 centavos em vez de 1,5 – um salto de cinco vezes, só pelo contexto.
• Laços agênticos. Recursos de IA modernos raramente são uma única chamada. O agente planeja, chama uma ferramenta, avalia o resultado, se corrige, chama a próxima ferramenta. Vinte chamadas de modelo para uma tarefa não têm nada de incomum. De repente essa única tarefa custa não 7 centavos, mas US$ 1,40 – vinte vezes a estimativa ingênua.
• Retentativas. Um timeout, uma resposta cortada, uma chamada de ferramenta que falhou – cada retentativa custa de novo. Em sistemas mal protegidos, tempestades de retry dobram a fatura em silêncio.

Agora multiplique para cima. Um usuário ativo pode disparar 10 tarefas dessas por dia, em 20 dias úteis por mês – são 200 tarefas a US$ 1,40 cada, ou seja, US$ 280 por usuário por mês. Se o produto é vendido por US$ 29 por mês, você perde cerca de US$ 250 com cada usuário ativo. Não por abuso. Por uso normal.

Isso não é um extremo forçado. É a escalada perfeitamente comum de "funciona no protótipo" para "roda em produção" – e ela acontece em silêncio, camada por camada, até a fatura chegar.

O problema do rodízio à vontade

Mesmo que o seu custo médio feche, a próxima armadilha se esconde na distribuição. Porque usuários não são iguais. Em quase todo produto, o uso segue uma assimetria brutal: uma pequena porcentagem de power users gera a maior parte da carga.

No SaaS clássico isso não importa – o usuário pesado não custa nada a mais. Na IA é fatal. Venda uma tarifa fixa e encontre power users, e você abriu um rodízio à vontade em que um punhado de clientes esvazia o buffet inteiro. Os 5% de usuários mais pesados podem acumular mais custo de inferência do que os outros 95% somados.

A média não dilui isso. Ela é dominada pelo usuário pesado. E o cliente mais caro não é o que paga menos – muitas vezes é o que mais ama o produto, que o usa o dia inteiro justamente porque é tão bom. Num preço fixo, o seu fã mais leal custa mais do que rende. Você acaba punido pelo próprio sucesso.

Onde os custos se escondem

A maioria das explosões de custo não é lei da natureza; são decisões evitáveis. Os suspeitos de sempre:

• Inchaço de contexto. Cada chamada reenvia o histórico inteiro da conversa ou metade da base de conhecimento. Você paga pelo contexto todo em cada requisição – inclusive a parte que não muda há dez mensagens.
• Sem cache. O mesmo system prompt, os mesmos documentos, as mesmas instruções passam pela linha sem mudar mil vezes e são cobrados por inteiro toda vez, mesmo que o resultado fosse idêntico.
• Modelo de fronteira para trivialidades. O modelo maior e mais caro classifica um e-mail como "urgente / não urgente" ou extrai uma data de uma frase. Tarefas que um modelo dez vezes mais barato resolveria igualmente bem.
• Sem limite de saída. Sem teto, o modelo escreve três parágrafos onde um bastaria – e tokens de saída costumam ser os mais caros.
• Laços agênticos sem teto de orçamento. Um agente que se enrosca continua chamando o modelo até terminar – ou até nunca terminar. Sem um limite duro de chamadas por tarefa, isso é uma torneira aberta.
• Tempestades de retentativa. Quando uma chamada falha e o sistema tenta de novo de forma agressiva, sem backoff e sem teto, os custos se multiplicam exatamente no momento em que algo já está dando errado.

Nenhum desses pontos aparece no protótipo. Cada um deles vira uma linha na fatura em produção.

As alavancas

A boa notícia: cada um desses geradores de custo tem uma alavanca contrária. Times que levam unit economics a sério as embutem desde o começo – não como cirurgia de emergência quando a fatura já dói.

1. Dimensionar o modelo para a tarefa. Nem toda tarefa precisa do carro-chefe. Um modelo pequeno e barato para classificação, extração e respostas simples; o modelo de fronteira só onde ele justifica o preço. Só esse escalonamento costuma cortar o custo em uma ordem de grandeza.
2. Usar cache. Cache de prompt para system prompts e documentos estáveis, cache de resultado para requisições recorrentes. O que não muda não deve ser pago toda vez.
3. Limitar contexto e saída. Passar só as partes de fato relevantes para a chamada, não o histórico inteiro. Definir um teto duro para o tamanho da resposta.
4. Limites de orçamento por usuário e por tarefa. Um número máximo de chamadas por tarefa, um orçamento máximo de tokens por usuário por dia. Isso transforma a fatura de pior caso de infinita em calculável.
5. Processar em lote onde der. Tudo o que não precisa acontecer em tempo real pode ser processado em bloco, muitas vezes bem mais barato.
6. Em volume alto e estável, avaliar self-hosting. A partir de certa carga sustentada, um modelo open-weight rodado por você pode ficar abaixo do contador da API – desde que você conte o custo operacional com honestidade.
7. Atrelar o preço ao consumo. Baseado em uso ou em faixas, em vez de fixo. Quando a receita cresce junto com o custo, o power user não consegue mais virar fonte de prejuízo.

A ressalva honesta: não otimize cedo demais

Até aqui o sermão sobre custo – agora o contraponto, senão você tira as conclusões erradas.

Otimizar custo num produto que ainda não tem usuários é tempo desperdiçado. Na fase inicial, duas coisas importam: ele funciona, afinal, e alguém quer? Correção e product-market fit ganham da eficiência. Um protótipo caro que prova que as pessoas amam o recurso vale infinitamente mais do que um barato que ninguém quer. Quebrar a cabeça com cache de token na semana um, em vez de afinar o produto, é otimizar a variável errada.

Há ainda um consolo estrutural: o preço por token cai de forma confiável ao longo do tempo. O que é "caro demais para este caso de uso" hoje pode ser banal daqui a um ano. Alguma ideia que fracassa na conta de inferência hoje simplesmente vira viável esperando. Isso é real, e não deveria tirar a sua coragem.

Mas – e este é o ponto decisivo – isso não é licença para ignorar a unit economics. É um argumento a favor da ordem certa: primeiro provar que funciona e é desejado, depois entender o custo antes de escalar. O desastre não acontece com o protótipo caro. Acontece quando você sobe um produto de margem negativa para dez mil usuários sem nunca ter calculado o custo unitário. Escala torna um bom negócio melhor e um quebrado quebrado mais rápido.

As perguntas incômodas

Antes de um recurso de IA ir para a largura, faça um check sóbrio. Cinco perguntas que merecem respostas honestas:

1. Você conhece seu custo por requisição e por usuário ativo? Medido, não chutado. Se você não consegue dizer esse número, está voando às cegas.
2. Quanto custa seu usuário de pior caso? Pegue os 5% mais pesados e faça a conta. Esse é o seu número de risco de verdade, não a média.
3. Seu preço cobre esse usuário? Se o cliente mais caro custa mais do que paga, o modelo de preço está quebrado – não o cliente.
4. Onde está escondido o inchaço de contexto? Você reenvia o histórico inteiro e metade da base de conhecimento a cada chamada? Você faz cache do que não muda?
5. Você paga por um modelo de fronteira onde um pequeno bastaria? Percorra cada chamada de modelo e pergunte se ela precisa mesmo da ferramenta mais cara da caixa.

Quem responde as cinco com clareza tem um produto que fica mais lucrativo à medida que cresce, em vez de bater numa parede de custo.

Conclusão

O software clássico ficava mais barato por cabeça a cada usuário. A IA não vai – cada usuário, cada requisição, cada token carrega um preço real e recorrente. Isso não é motivo para não construir produtos de IA. É motivo para construí-los de olhos abertos.

A unit economics não é tarefa para depois, quando o crescimento chegar. É uma decisão no primeiro dia do design: qual modelo, quanto contexto, qual teto, qual modelo de preço. Pense nisso desde a frente e você constrói um produto que ganha ao escalar. Ignore e você constrói um que sangra ao escalar – e só descobre quando a fatura chega.

É exatamente aqui que entramos na nh labs: desenhar produtos de IA desde o dia um para que a unit economics feche. Não para o recurso deslumbrar na demo, mas para que ele ainda ganhe dinheiro com dez mil usuários. Construir ficou barato. Operar com juízo é onde mora o verdadeiro ofício.