A fatura da DeepSeek API não é simplesmente "número de chamadas vezes preço unitário": ela é determinada por tokens de entrada, tokens de saída e acertos de cache. Muitas equipes fazem o orçamento pelo preço de tabela e, depois de entrar em produção, descobrem um custo bem maior; a causa geralmente não é uma mudança de preço, mas uma estrutura de entrada, uma taxa de acerto de cache e um número de tentativas diferentes do estimado.

Este artigo divide a cobrança da DeepSeek API em partes calculáveis: quais tokens são cobrados, por que o cache às vezes funciona e às vezes não, como estimar com o campo usage da resposta e em que ordem reduzir custos. Os preços unitários específicos seguem a página de preços e a documentação oficial da DeepSeek.

Nota: DeepSeek é marca de seu titular. Este artigo usa como exemplo o formato comum das interfaces em outubro de 2026; preços, nomes de modelos e regras de cobrança podem mudar, então confirme novamente nas páginas oficiais antes de comprar.

1. Divida a fatura em quatro itens

Item Quando ocorre Principal fator Direção de otimização
Entrada (cache miss) Conteúdo novo entra no contexto pela primeira vez Tamanho do documento, histórico, definição de ferramentas Recuperação, resumo, corte
Entrada (cache hit) A requisição reutiliza um prefixo já armazenado Estabilidade do prefixo, taxa de acerto Prefixo fixo, menos conteúdo aleatório
Saída O modelo gera texto e resultados estruturados Tamanho da saída, restrições de formato max_tokens, restrição JSON
Conteúdo de raciocínio Modelos de raciocínio produzem o processo de pensamento Dificuldade da pergunta, nível de raciocínio Tarefas simples sem modelo de raciocínio

O cache de contexto da DeepSeek normalmente aparece no lado da entrada: o prefixo que acerta é cobrado a um preço de entrada menor, e a parte que não acerta segue o preço padrão de entrada. Se há cobrança de armazenamento de cache e por quanto tempo ele é retido dependem da documentação oficial atual; não use regras de artigos antigos.

Uma requisição pode ser escrita como uma fórmula de custo:

Custo por requisição =
   tokens de entrada com cache hit × preço do hit
+  tokens de entrada com cache miss × preço de entrada
+  tokens de saída × preço de saída

Só levando essa fórmula para os logs é possível responder "quanto esta funcionalidade custa por mês". Olhando apenas a fatura total do console, é difícil saber qual projeto ou tipo de requisição está inflando o custo.

2. Por que o cache economiza e por que muitas vezes não funciona

A lógica básica do cache de contexto: se o início de duas requisições for idêntico, o servidor pode reutilizar o cálculo anterior e recalcular apenas a parte nova. Por isso, o cache é mais eficaz para:

  1. System prompt e definição de papel fixos.
  2. Definições de ferramentas e schemas de funções estáveis.
  3. Trechos de base de conhecimento, manuais de produto e modelos de contrato reaproveitados.
  4. A primeira metade de conversas de vários turnos que não muda.

Por outro lado, estas práticas invalidam o cache com frequência:

  • Inserir hora atual, ID aleatório ou apelido do usuário no início do system prompt.
  • Reordenar ferramentas ou documentos a cada requisição.
  • Colocar o documento inteiro no começo e a pergunta do usuário só depois.
  • Alternar o mesmo negócio entre modelos e entradas diferentes.
  • Usar prefixo curto demais, que não atinge o tamanho reutilizável.

Colocar o conteúdo variável no fim da requisição e o estável no começo é a prática mais simples e eficaz. O cache geralmente é "best effort" e não promete acerto; portanto, o orçamento deve assumir acerto parcial, não total.

3. Faça uma estimativa real com o campo usage

Não adivinhe tokens pela contagem de caracteres. Registre o campo usage de cada resposta e observe por uma semana para obter a estrutura real do seu negócio.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

resp = client.chat.completions.create(
    model="deepseek-chat",  # nome do modelo conforme a página de preços
    messages=[
        {"role": "system", "content": "Você é um assistente de atendimento. Responda em no máximo três frases."},
        {"role": "user", "content": "Depois que o pedido é enviado, ainda posso alterar o endereço?"},
    ],
    max_tokens=256,
)

usage = resp.usage
hit = getattr(usage, "prompt_cache_hit_tokens", 0) or 0
miss = getattr(usage, "prompt_cache_miss_tokens", 0) or 0

print("entrada", usage.prompt_tokens)
print("cache hit", hit, "cache miss", miss)
print("saída", usage.completion_tokens)

Se a resposta não trouxer os campos detalhados de cache, registre entrada e saída totais e faça a engenharia reversa pela fatura ou pela página de uso. O importante é manter o critério dos campos consistente e não comparar dados de datas ou entradas diferentes misturados.

Na estimativa, registre pelo menos: horário, projeto, modelo, tokens de entrada, tokens de saída, acerto de cache, número de tentativas e se a chamada foi em streaming. O valor em dinheiro fica para o fim do mês, multiplicado pelo preço unitário; os indicadores de processo devem ser vistos todos os dias.

4. Por que a fatura varia tanto com o mesmo volume

Cenário Estrutura típica de tokens Ponto de amplificação Foco da otimização
Atendimento Entrada grande, saída curta Histórico repetido a cada turno Resumo, cache, apenas os últimos turnos
Extração de documentos Entrada média, saída estruturada O mesmo documento é lido várias vezes Cache de prefixo, processamento em lote
Assistente de código Entrada e saída grandes Resultados de ferramentas e arquivos longos Recuperação, chunking, limite de saída
Geração de textos longos Entrada curta, saída longa Acúmulo de tokens de saída Geração por partes, max_tokens
Tarefas de raciocínio Entrada média, saída com raciocínio O raciocínio entra na saída Modelo não raciocinante para tarefas simples

As diferenças costumam vir de cinco pontos:

  1. Proporção entrada/saída: atendimento e redação longa têm estruturas de custo opostas; não use a mesma média para os dois.
  2. Taxa de acerto de cache: prefixo fixo é reutilizável; conteúdo dinâmico invalida o cache.
  3. Tamanho do contexto: enviar o documento inteiro a cada turno faz o custo de entrada crescer com o número de turnos.
  4. Número de tentativas: reenvios após 429 ou timeout aumentam o volume; se requisições com falha são cobradas depende da fatura.
  5. Faixa de modelo: modelos de raciocínio e não raciocinantes têm preços e tamanhos de saída diferentes; um encaixe errado amplia o orçamento.

5. A ordem da redução de custos não deve ser invertida

  1. Primeiro quantifique: use usage e logs para calcular a estrutura real de tokens de cada funcionalidade, sem achismo.
  2. Depois aumente o acerto de cache: fixe system prompt, definição de ferramentas e prefixo de conhecimento, e reduza o conteúdo dinâmico no início.
  3. Depois reduza a entrada: no RAG, recupere só trechos relevantes; resuma o histórico; mantenha apenas os campos necessários na saída das ferramentas.
  4. Limite a saída: defina max_tokens razoável, exija JSON ou campos fixos e reduza explicações repetidas.
  5. Faça roteamento de modelos: classificação, extração e reescrita em modelos leves; raciocínio complexo sobe de faixa.
  6. Assíncrono e em lote: anotação, resumo e análise offline que não exigem resposta em tempo real vão para filas.
  7. Monitoramento e alertas: acompanhe uso por projeto, modelo e cenário e defina teto de orçamento.

Inverter a ordem costuma terminar assim: troca-se por um modelo mais barato, mas a entrada não foi tratada, o cache não acerta, a fatura não cai e a qualidade piora.

6. Como administrar orçamento e fatura

  • Uma Key por projeto, com teste e produção separados, para não disputarem a mesma cota.
  • Limite de gasto e alertas por Key, para conter chamadas anômalas automaticamente.
  • Conciliação semanal por "projeto, modelo e cenário", identificando as chamadas que mais crescem.
  • Registrar separadamente a economia obtida com cache e roteamento; caso contrário, não é possível provar que a otimização funcionou.
  • Equipes que precisam de pagamento em yuan e nota fiscal podem unificar a fatura em um gateway de IA local; preços, câmbio e regras de nota fiscal seguem a página de preços.

Perguntas frequentes

O cache da DeepSeek precisa ser ativado manualmente?

Normalmente não é preciso marcar explicitamente o trecho de cache; o servidor decide automaticamente pelo prefixo se pode reutilizar. O mecanismo e o tempo de retenção seguem a documentação oficial. O que você deve fazer é manter o prefixo estável, não adicionar mais configuração.

Por que a taxa de acerto de cache oscila?

As causas comuns são timestamp, ID aleatório ou dados do usuário misturados ao prefixo, ou alternância entre modelos e entradas diferentes. Mova primeiro o conteúdo variável para o fim e observe por uma semana.

O raciocínio dos modelos de raciocínio é cobrado?

Os tokens de raciocínio normalmente entram na saída; o critério exato segue a documentação oficial e a fatura. Para classificação e extração simples, não use modelos de raciocínio por padrão.

Entrada ou saída é mais cara?

Na maioria dos modelos, o preço de saída é maior que o de entrada, mas a entrada com cache hit costuma ser mais barata. Não compare apenas os dois preços: calcule o custo por requisição com a sua proporção de entrada e saída.

Por que a estimativa não bate com a fatura?

Itens frequentemente esquecidos incluem histórico, definição de ferramentas, reenvios, cache miss e saídas longas. Cruze o request ID com os logs de uso para localizar a diferença.

Próximo passo

Crie uma Key de teste no ZSQH AI Gateway, rode uma semana com tarefas reais registrando entrada, saída e acerto de cache, e depois converta o orçamento pela página de preços. Disponibilidade e preços dos modelos seguem a página de preços.

Leituras relacionadas: