Lance uma funcionalidade de IA e a primeira fatura do fornecedor do modelo não lhe diz quase nada sobre o que custa realmente servi-la. O preço por token é a décima parte visível do icebergue. Por baixo está a recuperação de contexto, a orquestração, os registos técnicos, a revisão humana para os casos em que o modelo erra, e os pedidos de suporte que a funcionalidade gera quando está errada com toda a confiança. A maioria das equipas define o preço da funcionalidade, ou decide se a mantém, usando apenas a parte que consegue ver.
Quanto custa realmente servir uma funcionalidade de IA?
A fatura da API do modelo é apenas uma linha do custo real. Uma cifra completa soma a recuperação de contexto e o armazenamento vetorial, a infraestrutura de orquestração e registos, a revisão humana ou moderação de uma parte das respostas, e o custo de suporte de tratar os erros. Na maioria das funcionalidades de IA, estes custos à volta são comparáveis, e por vezes maiores, do que a própria fatura de inferência - por isso tratar a fatura da API como o custo de servir subestima-o gravemente.
A fatura que vê, e a que não vê
A fatura de inferência é fácil de acompanhar porque chega como uma única fatura discriminada: tokens de entrada, tokens de saída, um preço por milhão. Essa visibilidade é exatamente a razão por que é tratada como o custo total. Tudo o resto que faz a funcionalidade funcionar - o passo de recuperação que vai buscar contexto antes de o modelo sequer correr, a camada de orquestração que chama o modelo, verifica a resposta e por vezes repete a chamada, os registos que lhe permitem depurar uma resposta má seis semanas depois - é despesa de infraestrutura que aparece na fatura da cloud sob uma dúzia de rubricas sem relação aparente, não na fatura do fornecedor do modelo.
Recuperação de contexto e orquestração não são grátis
Uma funcionalidade com recuperação aumentada faz uma pesquisa antes de correr um modelo: uma chamada de embedding, uma consulta a uma base de dados vetorial, por vezes um passo de reordenação. Cada uma destas tem o seu próprio custo, escala com o uso da mesma forma que a chamada ao modelo escala, e é muitas vezes deixada de fora da economia unitária por completo, porque vive numa parte diferente da arquitetura, é faturada por um fornecedor diferente e é acompanhada por uma equipa diferente. A orquestração acrescenta repetições, alternativas para um modelo mais barato quando o principal não está disponível, e a computação para as verificações que decidem qual modelo chamar. Nada disto é exótico. Tudo isto é um custo real por pedido que um modelo de custo de servir tem de incluir.
O custo que ninguém põe na folha de cálculo: estar errado
Toda a funcionalidade de IA erra uma parte das respostas, e as respostas erradas têm um custo real mesmo quando nunca aparece numa fatura: um pedido de suporte, o tempo de um revisor humano, um reembolso, um cliente que sai. Uma funcionalidade com uma taxa de erro de 3% e outra com uma taxa de erro de 15% podem ter uma fatura de inferência idêntica e um custo total completamente diferente, porque a segunda gera muito mais trabalho a jusante. Tratar a fatura da API como o custo da funcionalidade faz o modelo barato e pouco fiável parecer a melhor escolha, até a fila de suporte dizer o contrário.
Construir um custo de servir real para uma funcionalidade de IA
O método não muda só porque o custo envolve um modelo: defina a atividade - responder a uma pergunta, redigir um documento, classificar um pedido de suporte - e siga cada cost pool que uma unidade dessa atividade consome. A inferência é um driver. As chamadas de recuperação são outro. Os minutos de revisão humana, quando uma parte das respostas precisa disso, são um terceiro, custeados da mesma forma que qualquer atividade intensiva em mão de obra é custeada num modelo TDABC. Some-os por unidade do trabalho realmente realizado, não por euro de despesa em modelo, e a margem real da funcionalidade - e se vale a pena mantê-la na forma atual - torna-se visível pela primeira vez.
A fatura do fornecedor do modelo é o custo dos tokens. Não é o custo da funcionalidade.
O que verificar antes de confiar na economia unitária de uma funcionalidade de IA
Antes de indicar um custo por pedido ou uma margem para uma funcionalidade de IA, confirme que a infraestrutura de recuperação e orquestração lhe foi alocada, e não ficou dentro de um custo de plataforma partilhada que ninguém segue até à origem. Confirme que foi estimada uma taxa de erro realista e incluída no modelo, usando dados reais de revisão ou de suporte, não a precisão prometida no benchmark de um fornecedor. E confirme que a comparação entre um modelo mais barato e menos preciso e um mais caro e mais preciso inclui o custo a jusante de estar errado, não apenas as duas faturas lado a lado.
Marque uma demonstração ao vivo do CostCtrl e veja como os custos de inferência, recuperação, revisão e suporte se juntam num único número real por funcionalidade.
Leitura relacionada: custo de servir para funcionalidades de IA e onde os LLMs erram na alocação de overhead.