Tokens e cobrança na API de LLM: estimativa, leitura, orçamento e exemplos

O que é token e como calcular

Token é a menor unidade de texto que o modelo processa: nem caractere, nem palavra, mas um "fragmento" intermediário. Pense nos tokens como as marcações de um hidrômetro: quanto mais você usa, mais rápido as marcações avançam. A cobrança é dividida em:

Atenção: o preço de saída é quatro vezes o de entrada, então fazer o modelo "falar menos" costuma ser mais econômico do que enviar menos contexto. No entanto, o input cresce com o histórico, exigindo controle em ambas as pontas. O pagamento é feito com crédito pré-pago, não por assinatura, e o saldo nunca expira. Novas contas recebem US$ 0,50 de crédito de teste, válido por 7 dias.

Um ponto que gera confusão: tokens de saída são os gerados pelo modelo, não o max_tokens definido. max_tokens é apenas o limite; se o modelo responder com 200 tokens, você paga por 200. Para estimativas de orçamento, use o limite para prever o pior caso e evitar surpresas com respostas longas.

Estimativa prévia: como estimar chinês e inglês

Antes de enviar a requisição, só é possível estimar.Os valores abaixo são aproximados e variam conforme o conteúdo:

O uso correto da estimativa é fazer uma "análise de magnitude": este texto tem cerca de 10 mil ou 100 mil tokens? Vai estourar a janela de 100.000 tokens? Quanto custa uma chamada? Para precisão, leia o usage. Uma boa prática é rodar dezenas de vezes cada cenário de negócio e usar a média do usage como valor, substituindo a intuição.

Veja um exemplo que combina estimativa e medição real. Suponha que você processe 2.000 caracteres de feedback de clientes em chinês. Estimando 1,3 token por caractere, o texto tem ~2.600 tokens. Com 200 tokens de prompt, o input total é ~2.800. Execute 30 vezes, leia o usage e calcule a média. Se a média for 2.500, ajuste seu coeficiente para ~1,15. Use esse coeficiente corrigido para orçar o lote inteiro. Estes são apenas pressupostos de demonstração; seus dados reais podem variar.

Lendo usage: a leitura real do medidor

Cada resposta bem-sucedida traz usage com prompt_tokens, completion_tokens e total_tokens. Streaming não precisa de parâmetro extra; o último bloco inclui usage automaticamente. O código abaixo mostra como ler ambos e converter para dólares:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

Em streaming, só o último bloco tem usage; os anteriores são vazios. Use if chunk.usage para verificar. Registre cada leitura no log ou banco de dados para conciliação mensal, detecção de anomalias e cálculo de custo por usuário.

Outro hábito útil: etiquete cada função de negócio e registre os custos por etiqueta. Exemplos: "resumo", "atendimento", "tradução". No fim do mês, você verá exatamente qual função consome mais e se deve otimizar o prompt, reduzir o histórico ou ajustar o max_tokens. Sem etiquetas, você só vê um total único e não sabe por onde começar a otimizar.

Três exemplos (com as premissas indicadas)

Exemplo 1: Atendimento ao cliente

Premissa: cada requisição tem entrada de 800 tokens (incluindo system e fragmentos de conhecimento) e saída de 200 tokens; 10.000 requisições por dia.

Custo único: 800 × 0,25 ÷ 1.000.000 = $0,0002; saída 200 × 1,00 ÷ 1.000.000 = $0,0002; total $0,0004. Diário $4,00; 30 dias $120. Com crédito de $0,50, suporta 1250 chamadas.

Exemplo 2: Resumo de artigos longos

Premissa: entrada de 20.000 tokens por artigo, saída de 600 tokens para o resumo; total de 500 artigos.

Por artigo: entrada 20.000 × 0,25 ÷ 1.000.000 = $0,005; saída 600 × 1,00 ÷ 1.000.000 = $0,0006; total $0,0056. Para 500 artigos: $2,80. Tarefas com entrada longa e saída curta são muito econômicas.

Exemplo 3: Chat multi-turno com corte de histórico

Premissa: system com 100 tokens; por turno, entrada do usuário de 60 tokens e resposta de 150 tokens; uma conversa tem 20 turnos.

A entrada do histórico completo é: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. As três primeiras rodadas do método otimizado são 160, 370 e 580; das rodadas 4 a 20, cada uma custa 790, totalizando 14.540. O custo é cerca de metade menor, e a diferença aumenta com mais rodadas, pois a entrada do histórico completo cresce quadraticamente.

Desses três exemplos, extraímos uma fórmula prática: o custo é determinado principalmente por “número de requisições × volume de entrada e saída por chamada”. O volume de entrada é onde você mais pode atuar (histórico e contexto anexado). Reduzir fragmentos de conhecimento no atendimento, cortar histórico no chat e dividir em blocos paralelos no resumo seguem a mesma lógica: não pague tokens desnecessários. Lembre-se: os números são baseados nas premissas acima; seus dados reais devem ser conferidos no usage.

Cálculo reverso: se seu orçamento mensal for US$ 30, quantas conversas de 20 rodadas você consegue? Com o cenário "apenas últimas 3 rodadas", cada conversa custa ~US$ 0,0066. US$ 30 ÷ 0,0066 ≈ 4.545 conversas. Com o cenário de histórico completo (US$ 0,0138/conversa), o mesmo orçamento sustenta apenas ~2.174 conversas. Essa é a diferença prática de cortar o histórico.

Controle de orçamento: instale um limite no programa

A estimativa é apenas uma previsão; o limite é o seguro. Abaixo está um exemplo de classe de orçamento diário em dólares: use o "pior caso" (saída no max_tokens) para prever antes da requisição e registre o usage real depois.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Além do limite no código, há três configurações adicionais:

1. Defina o max_tokens conforme a tarefa, não puxe até o limite máximo. O padrão é 2048 e o máximo é 32.000;
2. Defina um limite de comprimento para o histórico de conversas, conforme a prática descrita em Construção de chatbots;
3. Recarregue apenas o valor que planeja usar na conta; o modelo de crédito pré-pago já impõe um limite natural.

Os preços e regras de saldo seguem apágina de preços. Detalhes da interface estão emdetalhes dos parâmetros.

Resumo final em checklist: antes, estime a magnitude, defina o max_tokens e verifique o tamanho do histórico; durante, monitore o usage no último bloco do streaming; depois, registre os custos por função e compare com o orçamento. Com esses três passos, as contas ficam claras.