Cobrar por token parece resolver o problema dos preços: o uso sobe, a receita sobe, em sincronia perfeita com o custo. Na prática essa sincronia quebra quase de imediato, porque o custo por token não é um número só. Uma pergunta curta e factual e um rascunho de documento longo podem ter a mesma etiqueta de “pedido” e um custo completamente diferente, e uma página de preços construída à volta de uma única taxa por token perde dinheiro silenciosamente no segundo caso, sempre.
Como devem os produtos de IA definir preços por token de forma rentável?
Uma taxa fixa por token ignora que os tokens de entrada, os tokens de saída, o contexto em cache e as chamadas de recuperação têm custos diferentes, e que os utilizadores intensivos se concentram desproporcionalmente nos pedidos de custo mais elevado. Um preço rentável separa estes drivers de custo, cobra mais pelos tokens de saída do que pelos de entrada onde a diferença é real, e verifica a margem bruta por escalão de plano contra os dados reais de uso - não contra o pedido médio que o modelo de preços assumiu.
Porque é que “por token” não é um preço só
Os fornecedores de modelos já cobram de forma diferente os tokens de entrada e de saída, muitas vezes por um fator de três a cinco, porque gerar um token custa mais computação do que ler um. Os produtos que revendem o acesso a uma única taxa combinada herdam essa assimetria sem a precificar: um utilizador que faz perguntas curtas e recebe respostas longas custa mais por pedido do que a média em que a taxa foi construída, e um utilizador que cola um documento longo e pede uma resposta de uma palavra custa menos. Sem acompanhar a divisão entrada/saída por cliente, o modelo de preços está a assumir uma média que poucos utilizadores reais correspondem de facto.
O contexto e a recuperação fazem parte da fatura, não são custos indiretos
Cada token de contexto enviado ao modelo - histórico da conversa, documentos recuperados, instruções de sistema - é faturado como token de entrada, mesmo que o utilizador nunca o tenha escrito. Uma funcionalidade que mantém um histórico de conversa longo ou recupera vários documentos por pedido pode gastar mais tokens em contexto do que nas próprias palavras do utilizador, e esse custo escala com decisões de desenho do produto, não com nada que o cliente controle. O cache de contexto repetido reduz-o, mas o cache tem o seu próprio custo de infraestrutura que uma taxa por token raramente contabiliza em separado.
Os utilizadores intensivos não são só mais uso, são um uso diferente
Os preços fixos por utilizador ou por token assumem que o uso escala de forma uniforme na base de clientes, e isso nunca acontece. Uma pequena parte das contas tipicamente gera uma parte desproporcional dos tokens, e essas contas costumam correr os tipos de pedido mais caros: janelas de contexto longas, cadeias de agentes com vários passos, tarefas com muitos tokens de saída. Um modelo de preços que era rentável no cliente médio pode estar em prejuízo acentuado no decil mais intensivo, e esse decil é normalmente aquele de que um produto em crescimento depende para reter.
Construir uma margem bruta que consiga defender
Definir o preço de um produto de IA com base na economia unitária real começa da mesma forma que qualquer exercício TDABC: defina a atividade - um turno de chat, um resumo de documento, uma tarefa de agente - e siga os drivers de custo que uma unidade dessa atividade consome de facto, em separado para tokens de entrada, tokens de saída, chamadas de recuperação e qualquer desconto de contexto em cache. Depois de separados, a margem bruta pode ser testada por escalão de plano contra a mistura de uso que os clientes reais geram, não a mistura que a lista de preços assumiu. É isso que transforma “cobramos por token” num número que a direção financeira consegue defender.
Uma única taxa por token cobra pelo pedido médio. A sua margem é decidida pelos pedidos que não são médios.
O que verificar antes da próxima atualização de preços
Antes de ajustar um preço por token ou por utilizador, confirme que a divisão entre tokens de entrada e de saída é medida por segmento de cliente, não assumida. Confirme que os custos de contexto e recuperação são atribuídos à funcionalidade que os causa, em vez de ficarem diluídos numa rubrica de infraestrutura partilhada. E confirme que a margem bruta é verificada tanto contra o decil de maior uso como contra a média - um preço que funciona em média e falha nos seus melhores clientes é um preço que vai precisar de mudar outra vez em breve.
Marque uma demonstração ao vivo do CostCtrl e veja como os custos de tokens de entrada, tokens de saída, recuperação e revisão se juntam numa única margem real por plano.
Leitura relacionada: margem bruta de IA e quanto custa realmente servir uma funcionalidade de IA.