Calcular custo de tokens LLM por requisição

Guia de produção: Calcular custo de tokens LLM por requisição. Inclui artefato determinístico, limites de falha, controles de rollout e fontes verificadas.

Decisão primeiro

Calcular custo de tokens LLM por requisição é um contrato explícito de produção, não uma mudança isolada. Defina sucesso, falha terminal e rollback antes de mover tráfego; o artefato separa evidência de suposição.

Comece por usage_source, prove input com um caso determinístico e transforme settlement em gate de release.

Artefato reutilizável

Uma linha só passa quando a evidência vem da mesma requisição, janela de teste ou versão de configuração.

Checkpoint	Evidência	Condição de aprovação
usage_source	provider_usage_or_named_normalization_rule	Owner, fonte, data e limitação ficam registrados.
input	uncached_input_tokens_after_category_separation	O valor é preservado e comparado exatamente na fronteira do protocolo.
cache	cache_read_and_cache_write_token_categories	O valor é preservado e comparado exatamente na fronteira do protocolo.
output	visible_and_reasoning_output_under_the_owned_price_rule	O valor é preservado e comparado exatamente na fronteira do protocolo.
formula	versioned_coefficients_in_currency_per_one_million_tokens	Owner, fonte, data e limitação ficam registrados.
settlement	reserve->actual_usage->idempotent_final_charge/refund	Reserva, observação e valor final conciliam no ledger durável.

Exemplo resolvido

O exemplo é sintético e determinístico. Use valores revisados do seu workload; nunca inclua segredos ou dados de clientes.

input_tokens = 1200
cache_read_tokens = 800
cache_write_tokens = 0
output_tokens = 300

cost = (input_tokens * input_rate
      + cache_read_tokens * cache_read_rate
      + cache_write_tokens * cache_write_rate
      + output_tokens * output_rate) / 1_000_000

round_at = owned_currency_or_quota_boundary

Procedimento de implementação

1. Congele requisição, resposta, configuração e baseline observável.
2. Execute um caso positivo determinístico e preserve o resultado completo.
3. Execute o caso negativo ou limite correspondente.
4. Una tentativas por um request ID lógico e registre tempo, estado final e uso sem conteúdo sensível.
5. Faça rollout em coorte limitada com critérios de parada.
6. Releia estado durável e comportamento público; reverta se uma invariante falhar.

Modos de falha

Estas falhas invalidam o resultado mesmo quando o HTTP externo parece correto:

• Preço ou contrato volátil não é revalidado.
• Sem reserva atômica, requisições concorrentes excedem o limite.
• Um campo conveniente é lido e outputs tipados, tools, recusas ou resultados parciais são perdidos.
• Custo compartilhado é alocado de modo que o total não concilia.

Limite do Modelflare

Modelflare centraliza routing compatível com OpenAI, chaves, grupos, uso e falhas, mas uma rota configurada não prova capacidades opcionais. Verifique modelo e canal pelo protocolo nativo, preserve zeros explícitos e use a liquidação durável como verdade de billing.

Use o guia principal para a decisão mais ampla e a documentação para a configuração atual.

Checklist de publicação

• Responder primeiro à pergunta principal.
• Definir owner para cada campo, estado, métrica e fórmula.
• Usar apenas identificadores sintéticos.
• Preservar estrutura, código, limites e avisos em todos os idiomas.
• Revalidar contratos, suporte e preços em T-1; mover a data se algo mudar.
• Antes do horário, excluir de API pública, rotas e sitemap.

Fontes e data de verificação

Fontes verificadas em 2026-08-07; elas não provam uma rota não testada.

• OpenAI: API pricing
• OpenAI: Prompt caching