WaveSpeedAI

Preços do DeepSeek V4: 20-50x Mais Barato que OpenAI (Análise de Custos)

Preços do DeepSeek V4: 20-50x Mais Barato que OpenAI (Análise de Custos)

Recentemente, fui procurando um modelo mais barato, algo que pudesse usar muito sem ficar de olho no medidor a cada hora. DeepSeek V4 continuava aparecendo em conversas com outros desenvolvedores, geralmente com uma sobrancelha levantada: “É… realmente barato.”

Dora está aqui. Passei a segunda metade de janeiro de 2026 integrando-a em alguns fluxos de trabalho pequenos: um resumidor de pesquisa, um reescritor de notas de produto e um organizador de backlog semanal. Nada sofisticado. O que me importava era como os tokens se traduziam em dólares reais durante uma semana normal. Aqui está o que aprendi sobre custo da API DeepSeek V4, os descontos que importam, e uma forma bem simples de orçar antes de você colocar em produção.

Preços Atuais do DeepSeek

Não vou fingir que os números são estáveis. Os preços se movem, e variam dependendo de onde você compra acesso (direto vs. um intermediário como OpenRouter). Então, dois pontos de referência:

  • Verifique a fonte: a documentação oficial da API do DeepSeek e página de preços. São as taxas canônicas quando você se conecta diretamente.
  • Se você rotear através de um marketplace, abra o cartão do modelo. Por exemplo, os modelos DeepSeek no OpenRouter listam taxas por milhão de tokens e qualquer desconto baseado em tempo. O que vi no final de janeiro de 2026 em todos os provedores era consistente em espírito: DeepSeek V4 fica bem abaixo dos modelos de ponta tanto para tokens de entrada quanto de saída. Os centavos exatos variam. Estou compartilhando como trabalho com os preços em vez de congelá-los no lugar.

Taxas Padrão

Se você é novo em cobrança de modelo baseada em uso, duas linhas importam:

  • Tokens de entrada (o que você envia): cobrados por 1M de tokens.
  • Tokens de saída (o que você recebe): também cobrados por 1M de tokens, geralmente mais alto que entrada.

Em minhas execuções, as taxas brutas do V4 eram baixas o suficiente para que pequenos picos diários não machucassem. Isso aparece mais em trabalhos em lote. Por exemplo, meu organizador de backlog semanal envia ~20 prompts de ~3–5K tokens de entrada cada um e recebe ~1–2K tokens de saída. Mesmo com taxas de amostra conservadoras, o total para a execução inteira permanecia na zona de “dinheiro de café”.

Duas notas práticas:

  • A inflação de saída rouba sua atenção. Se seus prompts encorajam pensamentos longos, a linha de saída pode dobrar sua conta. Coloquei um limite em max_tokens e ajustei o estilo para ser mais conciso. Economizei dinheiro, melhores resultados.
  • O tamanho do chunk importa. Se você está resumindo documentos longos, pagará por cada token sobreposto. Passei de sobreposição de 1.600 tokens para 400 e não perdi qualidade.

Descontos de Cache Hit (90% de desconto)

Este mudou minha lógica mental. Algumas plataformas e fornecedores de modelos suportam cache de prompt para prefixos repetidos. Se seus primeiros N tokens do prompt não mudam (mensagem do sistema, instruções compartilhadas, schema), cache hits podem ser faturados com um desconto acentuado. 90% de desconto é a figura que documentei em algumas implementações de cache de fornecedores (a disponibilidade varia: confirme na página de preços do seu provedor).

Como isso se parecia na prática:

  • Meu resumidor de pesquisa compartilha um prompt de sistema longo e fixo e um schema de ferramenta estável. Apenas o texto de origem muda.
  • Após a primeira chamada, chamadas subsequentes acertam o cache para esse prefixo compartilhado.
  • Em plataformas que honram cobrança por cache, aqueles tokens reutilizados caíram para a taxa com desconto.

Duas ressalvas de testes:

  • “Próximo” não é cached. Mude uma linha no prefixo compartilhado e você perderá o hit.
  • Schemas grandes e fixos se pagam. Se você pode consolidar instruções e ferramentas em um prefixo estável, faça uma vez e aproveite o cache.

Se seu provedor não expõe cache, você ainda pode simular algumas das economias movendo orientação repetida para um prompt de sistema mais curto e consistente e aparando redundância de mensagens de usuário.

Descontos Off-Peak (75% de desconto)

Alguns marketplaces começaram a oferecer descontos baseados em tempo para suavizar a demanda. Vi janelas fora do horário de pico com cortes acentuados (números como 50–75% de desconto aparecem, mas depende do revendedor e do modelo). Os modelos DeepSeek tendem a participar porque sua economia já é eficiente.

Duas formas como isso me ajudou:

  • Agendei meu trabalho de backlog semanal para a janela fora do horário de pico. Mesmo workload, item de linha menor.
  • Agrupei resumos de pesquisa durante a noite. A latência não importava, e o desconto importava.

Isso não é universal. Se você se conectar ao DeepSeek diretamente, verifique se eles publicam qualquer preço por hora do dia. Se você passar por um intermediário, leia a letra miúda do cartão do modelo. A diferença pode ser grande o suficiente para mudar quando você executa as coisas.

Por que DeepSeek é tão barato

Queria entender se o preço baixo era uma coisa promocional, ou se a arquitetura realmente suporta. Pelo que é público, dois pontos se destacaram.

Arquitetura MoE

Os modelos grandes mais recentes do DeepSeek dependem de Mixture-of-Experts (MoE). Em palavras simples: em vez de acordar o cérebro inteiro para cada token, o roteador escolhe alguns sub-redes de especialistas para lidar com isso. Você ainda tem um modelo capaz, mas apenas uma fração dos parâmetros funciona por passo, o que reduz computação e custo.

Por que isso importa na prática:

  • A taxa de transferência escala melhor. Do meu lado, a latência p95 permaneceu razoável mesmo quando empurrei trabalhos paralelos.
  • Os custos não aumentam linearmente com a complexidade. Prompts longos não punem tão duramente quanto em modelos densos e sempre ligados.

Usei outros modelos MoE que pareciam frágeis em tarefas de nicho: V4 lidou com prompts pesados em estrutura (saídas JSON, uso de ferramentas) sem vacilar. Essa estabilidade é parte da história de custo também: menos tentativas, menos refazer.

Eficiência Engram

A documentação do DeepSeek menciona trabalho em manipulação de contexto e eficiência de memória (eles chamam a atenção para coisas como roteamento de atenção melhorado e tratamento de cache KV em algumas versões). Não posso verificar os internos, mas posso compartilhar o que observei:

  • Prompts de contexto longo não prejudicaram a taxa de transferência em meus testes em janeiro de 2026. Executei contextos de 32K tokens sem a sensação de “tudo fica lento”.
  • Formatação determinística se manteve em temperatura mais alta do que esperava, o que significava que eu poderia manter saídas mais curtas sem prejudicar a qualidade.

Minha leitura: o preço não é uma manobra de marketing. É o resultado de uma arquitetura construída para manter computação por token baixa, mais uma vontade de passar isso adiante no preço de etiqueta. Se você estiver curioso sobre as notas técnicas, comece com a documentação oficial do DeepSeek e qualquer papel vinculado de seus cartões de modelo.

Modelo de Calculadora de Custo

Não bloquei orçamentos em centavos exatos mais. Planejarei ranges e ajustarei uma vez que o uso real se estabilize. Aqui está o modelo que usei para DeepSeek V4. É simples o suficiente para recriar em uma planilha.

Entradas que você preencherá por workload:

  • Chamadas por dia (ou por lote)
  • Tokens de entrada médios por chamada
  • Tokens de saída médios por chamada
  • Taxa de entrada por 1M de tokens (do seu provedor)
  • Taxa de saída por 1M de tokens (do seu provedor)
  • Tokens de prefixo cacheable por chamada (0 se nenhum)
  • Desconto de cache hit (ex., 0.90 para 90% de desconto)
  • Multiplicador fora do pico (ex., 0.25 se 75% de desconto, senão 1)

Passos:

  1. Divida tokens de entrada cacheáveis e não-cacheáveis.

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)

  2. Precifique a porção cacheável na taxa com desconto.

    • cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)

  3. Precifique a entrada variável na taxa de entrada completa.

    • variable_input_cost = (variable_input / 1,000,000) × input_rate

  4. Precifique a saída na taxa de saída.

    • output_cost = (avg_output_tokens / 1,000,000) × output_rate

  5. Some-os por chamada, depois aplique qualquer multiplicador fora do pico.

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier

  6. Escale por volume.

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

Um pequeno exemplo real da minha semana de testes (23–30 de janeiro de 2026):

  • 120 chamadas/dia
  • 3.200 tokens de entrada/chamada, dos quais 1.800 são um prefixo fixo e cacheável
  • 1.100 tokens de saída/chamada
  • Taxas de exemplo: $0.40 por 1M de entrada, $1.60 por 1M de saída (substitua pelos seus valores reais)
  • Desconto de cache hit: 90%
  • Multiplicador fora do pico: 0.5 (janela de 50% de desconto usada via revendedor)

Matemática (arredondada):

  • Custo cacheável por chamada = (1.800/1.000.000) × $0.40 × (1 − 0.90) ≈ $0.0000072
  • Custo de entrada variável por chamada = (1.400/1.000.000) × $0.40 ≈ $0.00056
  • Custo de saída por chamada = (1.100/1.000.000) × $1.60 ≈ $0.00176
  • Custo bruto por chamada ≈ $0.0023272
  • Ajustado para fora do pico ≈ $0.0011636
  • Diário ≈ $0.14
  • Mensal ≈ $4.20

Isso não é um erro de digitação. As taxas baixas por milhão mais cache e fora do pico transformaram um serviço “de olho no medidor” em algo que posso esquecer. Não economizou tempo no início, passei uma hora tornando o prefixo cacheável realmente fixo, mas cada chamada depois ficou mais barata.

Alguns limitadores que mantenho na planilha:

  • Coloque limites rígidos em max_tokens. O inchaço de saída é o assassino silencioso do orçamento.
  • Rastreie tentativas separadamente. Tentativas são gastos reais.
  • Registre tokens médios semanalmente. O desvio de tokens acontece conforme os prompts evoluem.

A quem isso serve:

  • Equipes executando muitas chamadas pequenas e semelhantes (ETL, resumo, QA).
  • Criadores com trabalhos em lote que podem se mover para fora do pico.

A quem pode não amar:

  • Apps que precisam de saídas longas e em streaming o dia todo, no pico. As economias se estreitam.
  • Configurações sem suporte a cache. Você ainda pagará taxas baixas, mas não as absurdamente baixas.

Se você quer um ponto de partida, reconstrua o modelo acima na ferramenta de sua escolha. São 10 minutos de configuração e economizam horas de adivinhação depois.

Uma última nota: se você estiver misturando provedores, normalize tudo para “custo por 1K tokens” em sua planilha também. Torna comparações rápidas lado a lado mais fáceis quando você está decidindo se mantém V4 no loop ou muda uma tarefa para um modelo de ponta por motivos de qualidade.

Ainda estou observando como as janelas fora do pico mudam. Ultimamente elas se moveram mais cedo à noite. Não é um problema para trabalhos em lote, apenas algo que fico de olho.