A API GLM não é um produto de "mensalidade com uso ilimitado": a cobrança acompanha o uso real. Muitas equipes olham a primeira fatura e ficam em dúvida: o volume de requisições não era alto, então por que o custo passou do previsto? Normalmente a explicação não está no preço unitário, mas em entradas longas, saídas sem limite, cache que não acerta ou retentativas que geram o mesmo conteúdo outra vez.

Este artigo não traz preços unitários, porque os valores mudam conforme o modelo, a faixa de contexto e as promoções. Vamos explicar a estrutura de cobrança, de onde os custos nascem, como estimar e reduzir o gasto e, no fim, oferecer uma lista de controle executável. Para os preços atuais, consulte a tabela de preços dos modelos e a página oficial de preços da Zhipu.

Nota: Zhipu, GLM e BigModel são marcas de seus respectivos titulares. Este texto é apenas uma explicação técnica e não implica vínculo, representação ou endosso da Zhipu. As regras e os preços podem ser alterados; antes de contratar, confira a documentação oficial e a página de faturamento.

1. A unidade básica de cobrança

Modelos de texto usam o token como unidade básica. A documentação da Zhipu apresenta como referência aproximada 1 token para 1,6 caractere chinês, mas o número real depende do tokenizador e do conteúdo, e o campo usage retornado pela API é a referência final. Em outras palavras, a estimativa serve para o orçamento, mas não substitui a fatura.

Nem todo modelo cobra por token. Geração de imagens, geração de vídeo, síntese de voz, clonagem de voz, áudio e vídeo em tempo real e análise de bases de conhecimento podem ser cobrados por chamada, por minuto, por caractere ou por página. Em produtos multimodais, primeiro confirme a unidade de cobrança e só depois compare preços unitários.

2. Por que entrada e saída são cobradas separadamente

Uma requisição normalmente inclui tokens de entrada e tokens de saída, com preços separados; a saída costuma custar mais. Modelos de contexto longo também podem ter faixas por tamanho da entrada, por exemplo com limite em 32K e uma faixa mais cara acima disso; alguns modelos ainda dividem por tamanho da saída. Ou seja, o "mesmo modelo" pode ter custo unitário diferente conforme o uso.

O que mais pesa no custo não é o número de requisições, mas o contexto levado em cada uma. Colocar a base de conhecimento inteira, todo o histórico e dezenas de definições de ferramentas no prompt faz a entrada crescer rapidamente. O desperdício mais comum está na saída: sem limite máximo, o modelo se estende e o custo sobe.

Item de custo Base de cobrança Quando costuma ocorrer Como controlar
Tokens de entrada Entrada sem acerto de cache Prompts longos, histórico de várias rodadas, definições de ferramentas Enxugar o contexto, gerar resumos
Tokens de saída Conteúdo gerado Textos longos, geração de código Definir limite máximo de saída
Acerto de cache Parte com desconto Prompt de sistema fixo, prefixo de base de conhecimento Manter o prefixo estável
Faixa de contexto longo Preço muda acima do limite Documentos longos, análise de repositórios Dividir, resumir, carregar sob demanda
Retentativas e falhas Parte gerada pode ser cobrada Timeout, interrupção de streaming, envio duplicado Idempotência, backoff, deduplicação
Multimodal e ferramentas Por chamada, minuto, página etc. Geração de imagens, voz, busca, análise Calcular à parte, limitar chamadas

3. Acerto de cache: economia no prefixo repetido

A Zhipu oferece cache de contexto, e a documentação oficial descreve principalmente o cache implícito: o sistema identifica conteúdo repetido automaticamente, sem marcadores manuais. Ele é adequado a cenários como "prompt de sistema fixo + base de conhecimento fixa + pergunta variável".

Para aumentar a taxa de acerto, três condições costumam ser necessárias: prefixo repetido suficientemente longo, com recomendação oficial de pelo menos 500 tokens; conteúdo idêntico, já que até um espaço extra pode impedir o acerto; e geração assíncrona do cache, que costuma funcionar melhor quando a primeira requisição é seguida de uma pequena pausa antes das próximas. O acerto pode ser consultado em usage.prompt_tokens_details.cached_tokens.

Cache não é solução universal. Prompts curtos, conteúdo que muda a cada chamada e bases editadas com frequência raramente acertam. Se o armazenamento de cache é cobrado à parte e qual é o desconto, confirme na página oficial de preços. Trate o cache como otimização, não como premissa padrão do modelo de custos.

4. Contexto longo, lote e multimodal

Contexto longo é útil, mas também é o ponto em que o orçamento estoura com mais facilidade. Ao lidar com contratos, artigos científicos ou repositórios, faça três perguntas: é realmente necessário enviar tudo de uma vez? É possível recuperar primeiro e montar o contexto depois? É possível processar por partes e consolidar? Muitas tarefas se resolvem com "recuperação + resumo", com custo muito menor do que despejar a base inteira no prompt.

Para tarefas em lote, vale examinar a interface Batch. A documentação oficial indica que modelos compatíveis costumam ter desconto no Batch, o que serve para rotulagem offline, resumos em massa e limpeza de dados, sem exigência de resposta em tempo real. O preço é maior latência e orquestração mais complexa, adequada a equipes com fila e validação de resultados.

Capacidades multimodais exigem cálculo separado. Geração de imagens costuma ser cobrada por imagem; compreensão de imagens, por token; síntese de voz, por caractere ou minuto; análise de base de conhecimento, por página. Misturar esses custos ao orçamento de texto garante diferença no fechamento do mês.

5. Retentativas, interrupções de streaming e custos ocultos

Requisições com falha não são necessariamente gratuitas. Se o servidor já gerou parte do conteúdo e depois deu timeout, esse uso pode continuar sendo cobrado; quando a conexão de streaming cai, a parte já gerada também pode entrar na fatura. Por isso, a política de retentativa deve ser contida: repetir apenas em limite de taxa, erros 5xx e timeout de rede, com backoff exponencial e número máximo de tentativas.

Outro custo oculto é o envio duplicado. Cliques repetidos do usuário, reenvio automático por timeout no front-end e consumo duplicado de filas geram requisições extras. Usar um ID de requisição para idempotência ou deduplicar no gateway é bem mais eficaz do que reconciliar a fatura depois.

Some também o custo de engenharia: logs, monitoramento, avaliação e revisão humana. A chamada ao modelo é só parte do custo total; não vale gastar várias vezes mais mão de obra em correções manuais para economizar um pouco na chamada.

6. Como estimar o orçamento mensal

A estimativa tem quatro passos: contar o volume mensal de chamadas, estimar entrada e saída médias, estimar a taxa de acerto de cache e aplicar os preços unitários atuais. Para administrar saldo e uso de vários modelos em um só lugar, registre-se no ZSQH AI Gateway e acompanhe tudo no painel; os preços continuam sendo os da página tabela de preços dos modelos. O código abaixo é apenas um esqueleto de cálculo: leia os preços unitários na página oficial e preencha.

# Modelo de orçamento: todos os preços são placeholders; substitua pelos valores oficiais atuais
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0       # preço de entrada, consulte a página oficial
output_rate = 0.0      # preço de saída
cache_rate = 0.0       # preço com acerto de cache

uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
    uncached_input * input_rate
    + cached_input * cache_rate
    + avg_output_tokens * output_rate
)
print(f"Custo mensal estimado: {monthly_calls * per_call:.2f}")

Deixe margem na estimativa. Em operações novas, a entrada real costuma ser maior que a projetada, e retentativas e falhas também aumentam o uso. Rode duas semanas com tráfego pequeno, substitua as hipóteses pelos dados reais de usage e só então fixe o orçamento.

7. Lista de controle do orçamento

  1. Defina um teto de gastos para cada ambiente e cada serviço.
  2. Configure limite máximo de saída e timeout em todas as requisições.
  3. Mantenha a ordem do prompt de sistema fixa para elevar o acerto de cache.
  4. Em documentos longos, recupere e resuma antes de decidir enviar ao contexto longo.
  5. Repita apenas erros retentáveis, com backoff e limite de tentativas.
  6. Acompanhe o uso diariamente e a fatura semanalmente; investigue crescimentos anormais na hora.
  7. Para tarefas offline, prefira Batch; para tempo real, use a interface online.

8. Perguntas frequentes (FAQ)

1. Quanto custa exatamente a API GLM?

O preço varia com o modelo, a faixa de contexto e as promoções, por isso este artigo não fixa números. Consulte a tabela de preços dos modelos ou a página oficial de preços da Zhipu e use a fatura do painel como referência.

2. Como o acerto de cache é cobrado?

A parte que acerta o cache é cobrada com desconto; a entrada sem acerto usa o preço padrão. O desconto e a eventual cobrança de armazenamento estão na página oficial de preços, e o volume de acerto pode ser visto no campo usage.

3. Requisições com falha geram cobrança?

Depende da etapa da falha. Se parte do conteúdo já foi gerada, pode haver cobrança pelo uso real; erros de parâmetro e falhas de autenticação normalmente não geram custo de geração. A referência é o detalhamento da fatura.

4. Contexto longo é sempre mais caro?

Em geral, sim. Muitos modelos usam faixas por tamanho de entrada, com preço maior acima do limite. Se a tarefa pode ser resolvida com divisão ou recuperação, não force o contexto longo.

5. Como reduzir rapidamente o custo atual?

Comece por três ações: limitar a saída máxima, enxugar o prompt de sistema e elevar o acerto de cache. Em geral, elas dão resultado mais rápido e são mais controláveis do que trocar de modelo.

Leitura relacionada