Custos de API de LLM São CPV, Não Despesas Gerais: Um Guia de Margem Bruta para Wrappers de IA

Um fundador que dirige um assistente de escrita com IA disse-me que os seus "custos de software" eram $40,000 por mês. Quando dividimos o número, $34,000 disso eram faturas de API da OpenAI e da Anthropic — e nada disso estava no seu custo dos produtos vendidos. Estava sentado numa linha genérica de "Software e Assinaturas", logo ao lado da sua ferramenta de gestão de projetos de $19 por mês. A margem bruta reportada era de 91%. A margem bruta real, uma vez que a inferência foi movida para onde pertencia, era de 58%.

Isso não é um detalhe técnico de contabilidade. É a diferença entre um negócio que se parece com software e um negócio que se comporta como uma fábrica — um onde cada unidade vendida consome um insumo real e variável. Se está a construir em cima do GPT-5, Claude, Gemini ou qualquer modelo hospedado, a sua fatura de LLM não é despesa geral. É custo dos produtos vendidos, e tratá-la de outra forma significa que não sabe, na verdade, quanto dinheiro ganha.

Por Que Este Erro É Tão Fácil de Cometer​

O SaaS tradicional treinou uma geração de fundadores a pensar nos custos de software como fixos. Paga-se pela hospedagem, paga-se pelo CRM, paga-se pelo Slack — e nenhuma dessas faturas se move em sincronia com o quanto o produto é usado por um único cliente. Por isso, quando a primeira fatura de API da OpenAI chega, é natural arquivá-la no mesmo compartimento mental: "ferramentas que pagamos para gerir o negócio."

O problema é que uma fatura de API de LLM não se comporta como uma assinatura de SaaS. Comporta-se como uma matéria-prima. Sempre que um cliente envia um prompt, consome tokens, e cada token tem um preço. Um cliente que faz 50 solicitações por dia custa-lhe significativamente mais para servir do que um que faz 2. Essa é a definição de manual do custo dos produtos vendidos: um custo que escala diretamente com a entrega do seu produto a um cliente específico, em oposição a um custo que pagaria apenas para manter as luzes acesas, independentemente do uso.

Os dados da indústria confirmam o quão material isto se tornou. O relatório State of AI da ICONIQ, de janeiro de 2026, constatou que a inferência agora representa em média 23% da receita total em empresas de IA B2B em fase de escala, e 84% dessas empresas reportaram uma erosão da margem bruta de seis pontos percentuais ou mais, diretamente atribuível aos custos de infraestrutura de IA. Isto não é um erro de arredondamento que se possa absorver em "despesas operacionais diversas." É, muitas vezes, o maior fator de custo isolado do negócio, e merece ser tratado como tal.

A Linha Entre CPV e Despesas Operacionais, Traçada Corretamente​

A regra que separa o CPV das despesas operacionais não mudou apenas porque o insumo agora é uma API de modelo em vez de um armazém cheio de peças: os custos para entregar o seu produto a um cliente pagante pertencem ao CPV; os custos para construir o seu produto pertencem a P&D, sob despesas operacionais. Aplicada a um wrapper de IA, essa divisão fica assim:

Pertence ao CPV:

• Custos de inferência de produção — cada chamada de API que o seu produto em funcionamento faz em nome de um cliente pagante, seja uma conclusão de chat, uma chamada de embedding, uma passagem de classificação ou um ciclo de chamadas de ferramentas de um agente
• Hospedagem de modelo / computação em GPU — se está a executar um modelo de peso aberto em infraestrutura própria ou alugada em vez de chamar uma API hospedada, o tempo de computação atribuível ao atendimento de solicitações de clientes
• Infraestrutura de inferência de suporte — consultas a bases de dados vetoriais, execuções do pipeline de embeddings e sobrecarga de orquestração que existem especificamente para servir solicitações de produção
• Custos de suporte específicos de IA — um engenheiro de suporte cujo trabalho é triar problemas de resultados do modelo para os clientes é um custo de entrega do produto, não uma despesa geral de SG&A

Pertence às Despesas Operacionais (geralmente P&D):

• Inferência de desenvolvimento e teste — cada prompt que um engenheiro envia enquanto itera numa funcionalidade, depura uma regressão ou avalia uma nova versão de modelo
• Execuções de fine-tuning e avaliação — construir ou melhorar o modelo é P&D, não entrega
• Ferramentas internas de IA — as licenças do ChatGPT Enterprise ou do GitHub Copilot da sua equipa são uma despesa de produtividade, não um custo de atendimento a clientes

O passo prático que torna esta divisão possível é banal mas essencial: use chaves de API ou projetos de faturação separados para o tráfego de produção e de desenvolvimento desde o primeiro dia. Se os seus engenheiros estão a testar prompts com a mesma chave que o seu produto usa em produção, não tem forma de alocar corretamente a fatura depois do facto, e acabará por sobrestimar ou subestimar a sua margem real todos os meses.

Como É a Margem Bruta "Real" para Produtos de IA​

Depois de fazer essa divisão, espere que o número resultante pareça diferente do que está habituado. Os negócios de SaaS tradicionais visam margens brutas de 70–80% quase como algo natural. Os produtos nativos de IA não chegam lá da mesma forma. O guia de preços de fevereiro de 2026 da Bessemer Venture Partners coloca as margens brutas típicas de produtos de IA entre 50–60%, bem abaixo da faixa de 80–90% do SaaS tradicional, e os dados da ICONIQ mostram a margem bruta média da indústria em produtos de IA a subir — mas apenas para 52%, face aos 41% em 2024 e 45% em 2025.

Uma regra prática útil, surgida entre operadores que gerem isto de perto: mantenha os custos de LLM abaixo de cerca de 20% do CPV total se quiser um modelo de negócio durável e escalável. Ao ultrapassar esse limiar, a compressão de margem tende a acelerar à medida que cresce, em vez de aliviar, porque os clientes maiores usam mais o produto, não menos. Algumas categorias intensivas em IA — assistentes de programação, agentes de processamento de documentos — operam com rácios de custo de LLM de 30–40% do CPV e continuam viáveis, mas apenas porque precificaram deliberadamente em função dessa realidade, em vez de a descobrir depois.

O número que realmente importa não é a sua margem bruta combinada, ao nível da empresa — é o custo por cliente. Utilizadores intensivos de uma funcionalidade de IA podem custar 50 a 100 vezes mais para servir em inferência bruta do que utilizadores leves no mesmo nível de subscrição. Se não estiver a acompanhar isso, não sabe quais clientes são rentáveis e quais está silenciosamente a subsidiar todos os meses. Um plano de tarifa fixa que parecia bem para os seus primeiros dez clientes pode começar a perder dinheiro no momento em que um deles leva um fluxo de trabalho para produção e multiplica o seu volume de solicitações por 20x.

Construir o Modelo de Custo por Solicitação​

Não precisa de ferramentas elaboradas para começar — precisa de disciplina para registar os números certos em cada solicitação. A fórmula principal é simples:

request_cost = (input_tokens / 1,000,000) × input_price_per_million
             + (output_tokens / 1,000,000) × output_price_per_million

Os tokens de saída custam tipicamente 2–5x mais do que os tokens de entrada por unidade, porque a geração é mais intensiva em computação do que ler um prompt — por isso, um modelo de custo por solicitação que só acompanha o total de tokens sem separar entrada de saída irá sistematicamente sub ou sobreavaliar tudo o que tenha conclusões longas. Como exemplo prático, a preços de meados de 2026: uma solicitação com 2,000 tokens de entrada e uma resposta de 500 tokens contra um modelo de nível médio mainstream (cerca de $3 de entrada / $15 de saída por milhão de tokens) custa cerca de $0.0135. Execute essa mesma forma de solicitação 50,000 vezes por mês e está a olhar para cerca de $675 em custo de inferência só para essa funcionalidade — um número que é invisível se estiver enterrado numa linha de "custos de cloud" de cinco dígitos, mas muito visível assim que for atribuído à funcionalidade e ao segmento de clientes que o gerou.

Para tornar isto acionável:

1. Registe as contagens de tokens em cada solicitação, não apenas o custo — a maioria dos fornecedores de modelos devolve as contagens de tokens de entrada/saída na própria resposta da API, por isso isto é uma alteração de registo, não uma nova fonte de dados.
2. Marque cada solicitação com um ID de cliente e um identificador de funcionalidade para poder agregar os custos por conta e por superfície de produto, não apenas por mês.
3. Calcule o custo por cliente por período de faturação e compare-o com o que esse cliente lhe paga. Este é o número que lhe diz se os seus níveis de preços realmente correspondem ao seu custo de entrega, não a sua margem média combinada.
4. Encaminhe para modelos mais baratos onde a qualidade o permita. Nem toda solicitação precisa do seu modelo mais capaz (e mais caro) — tarefas de classificação, extração e formatação simples frequentemente têm desempenho aceitável num modelo mais pequeno e barato, e o encaminhamento de modelos é uma das poucas alavancas de margem que controla totalmente, ao contrário do preço do fornecedor.

Precificar para Proteger a Margem que Acabou de Encontrar​

Depois de a inferência ser corretamente classificada como CPV, a sua conversa sobre preços muda. Uma âncora comum usada pelos operadores é cobrar cerca de 3–5x o seu custo de token por unidade, de forma que uma tarefa de $0.30 seja precificada a $1.00 ou mais — não porque esse múltiplo seja mágico, mas porque deixa margem para absorver a variância de uso, a volatilidade dos preços dos modelos e os custos de suporte e infraestrutura que acompanham a inferência bruta.

A faturação baseada em uso tornou-se a forma padrão das empresas de IA manterem os preços e o CPV a mover-se juntos: cobre por token, por solicitação ou por tarefa concluída, e a sua receita escala com a mesma variável que impulsiona o seu custo, em vez de se afastar dela como acontece com uma assinatura fixa quando o uso dispara. Se ainda não está pronto para mudar totalmente para preços baseados em uso, no mínimo construa níveis de mínimo comprometido mais excedente, para que um cliente que ultrapasse o uso típico não se torne silenciosamente um prejuízo para o resto do mês.

Mantenha a Sua Estrutura de Custos Tão Auditável Quanto o Seu Código​

Nada disto é higiene contabilística opcional — é a diferença entre saber que o seu modelo de negócio funciona e descobrir que não funciona durante uma chamada de due diligence de captação de fundos, quando o associado de um investidor constrói o modelo de custo por cliente que devia ter construído seis meses antes. Os fundadores que evitam essa conversa são os que atribuem custos de inferência a clientes e funcionalidades desde a primeira chamada de API, não os que esperam até a fatura da OpenAI se tornar grande demais para ignorar.

O Beancount.io oferece-lhe contabilidade em texto simples, com controlo de versões, que torna simples atribuir os gastos de inferência à conta certa, separar o uso de API de produção do de desenvolvimento, e reconciliar o seu CPV real com a receita todos os meses — sem categorização de caixa preta, sem aprisionamento a fornecedores. Comece gratuitamente e veja porque desenvolvedores e fundadores nativos de IA estão a mudar para a contabilidade em texto simples.