Custos de API de IA: tokens e grupos

O controlo de custos de uma API de IA é realmente útil quando cada débito pode ser associado a um pedido, um modelo, um grupo e uma unidade de trabalho medida. O total mensal mostra que a despesa mudou; o registo por pedido explica porquê.

A Modelflare combina preços de modelos, utilização medida, política de grupo e registos de pedidos, permitindo rever custos sem os estimar apenas pelo texto visível.

As quatro camadas do custo de um pedido

1. Preço do modelo

Cada modelo tem a sua base de preços. Muitos modelos de texto distinguem tokens de entrada e de saída; APIs de imagem, áudio, reordenação e outras podem utilizar unidades diferentes. Algumas funcionalidades usam ainda regras de preços avançadas e versionadas, que não cabem numa tarifa plana por token.

Consulte Modelos e preços para o contrato atual do modelo e do formato da API, em vez de copiar um preço para o código da aplicação.

2. Utilização medida

O gateway regista a utilização devolvida ou calculada para o pedido concluído. Nos modelos de texto cobrados por token, entrada e saída são mantidas separadas porque as tarifas podem diferir.

O texto visível durante o streaming não é uma referência fiável para faturação. Itens de ferramentas, raciocínio, entrada em cache, tokens normalizados ou campos específicos do fornecedor podem contar mesmo sem aparecerem como texto normal do assistente.

3. Multiplicador do grupo

O grupo selecionado pode aplicar um multiplicador comercial à utilização base. Por exemplo, um rácio de 0.9 aplica 90% do custo base do modelo a esse pedido.

O multiplicador afeta a utilização. Não altera o crédito que um carregamento acrescenta à carteira.

4. Registo final do pedido

O registo de utilização liga o montante calculado ao modelo, grupo, estado, tokens, tempos e outros metadados operacionais seguros. Pedidos falhados ou cancelados podem seguir processos de liquidação diferentes; o resultado persistido é mais fiável do que uma estimativa do cliente.

O que comparar nos registos de utilização

Quando a despesa muda, compare:

• Modelo: o tráfego passou para um modelo com outro preço de entrada, saída ou funcionalidade?
• Grupo: o grupo principal ou de contingência aplicou outro multiplicador?
• Protocolo: a passagem entre Chat Completions e Responses alterou a estrutura da utilização?
• Tamanho da entrada: cresceram os prompts, o contexto recuperado, os ficheiros ou os resultados de ferramentas?
• Tamanho da saída: limites maiores ou ciclos do agente produziram mais conteúdo?
• Estado e repetições: as falhas originaram tentativas adicionais concluídas?
• Tempos: a geração mais longa correspondeu a mais saída ou apenas a mais espera?

Isole a carga por um ID estável ou por uma chave própria da aplicação, em vez de comparar tráfego de conta sem relação.

Definir limites de custo práticos

Separar chaves por carga de trabalho

Utilize chaves distintas para produção, desenvolvimento, automatização e ferramentas pessoais. Cada chave pode ter nome, validade, política de grupo e quota finita ou ilimitada.

Escolher grupos conscientemente

Não decida apenas pelo nome. Verifique disponibilidade real, multiplicador, requisito de acesso, RPM e política de contingência. Um grupo principal mais económico com uma alternativa aceitável pode ser mais previsível do que uma escolha implícita difícil de justificar.

Reduzir a entrada antes de limitar a saída

Prompts de sistema extensos, histórico repetido, documentos recuperados e resultados de ferramentas dominam frequentemente a utilização de entrada. Remova contexto que já não influencia a resposta e evite reenviar dados inalterados quando o cliente os puder referenciar ou colocar em cache em segurança.

Rever ciclos de agentes

Uma ação do utilizador pode gerar vários pedidos ao modelo. Registe cada ronda de ferramentas e cada repetição; a resposta final visível não equivale necessariamente a uma única chamada API.

Porque divergem as estimativas do cliente

Um tokenizer local ou uma contagem de caracteres ajuda a planear, mas pode diferir da utilização faturada porque:

• os fornecedores normalizam ou contam conteúdo de forma diferente;
• cache, raciocínio, imagem, áudio e ferramentas podem ter tarifas próprias;
• a liquidação usa o modelo e o grupo realmente selecionados;
• falhas e reembolsos dependem do ciclo real do pedido;
• os preços podem mudar enquanto pedidos antigos mantêm o resultado gravado.

Numa revisão financeira, reconcilie os registos persistidos de utilização e carteira. Não reconstrua o saldo a partir de um único campo visível.

Processo de revisão repetível

1. Filtre os registos por uma chave API e um intervalo de tempo.
2. Agrupe pedidos por modelo e grupo selecionado.
3. Compare entrada, saída, estado e custo por pedido.
4. Analise valores anómalos: repetições, contexto extenso, ciclos de ferramentas ou contingências.
5. Confirme o preço e a política atuais antes de alterar o encaminhamento.
6. Defina uma quota finita se a carga precisar de um limite rígido de despesa.
7. Volte a medir os mesmos indicadores após a mudança.

Um bom controlo começa pela atribuição. Quando modelo, grupo, utilização e resultado permanecem ligados, a equipa consegue otimizar a verdadeira origem da despesa em vez de adivinhar a partir de totais agregados.