Nota do autor: depois que a API DeepSeek passou a usar tarifação de pico e fora de pico e cobrança por chamadas de ferramentas, a antiga estimativa de “preço unitário × Token” deixou de funcionar. Este artigo usa 5 etapas para recalcular o custo real das chamadas da aplicação a partir de quatro dimensões: janela de horário, tipo de Token, cache e chamadas de ferramentas.
Muitos desenvolvedores ainda mantêm planilhas de custo no nível de “preço unitário de entrada × Tokens de entrada + preço unitário de saída × Tokens de saída”. Depois que a API DeepSeek introduziu tarifação de pico e fora de pico e cobrança por chamadas de ferramentas, essa fórmula ficou sem duas variáveis: em que janela de horário a requisição acontece e quantas chamadas de ferramentas foram feitas. Para a mesma aplicação e o mesmo consumo de Tokens, rodar em outro horário pode fazer a fatura variar bastante.
Este não é um artigo para simplesmente repetir preços. O texto não traz nenhum preço unitário não verificado. Para todos os preços, descontos por horário e critérios de cache, use como referência os dados em tempo real da página de preços da APIYI em docs.apiyi.com/models e os anúncios oficiais da DeepSeek. O que este artigo resolve é a questão do método: depois de obter a tabela de preços, como aplicá-la corretamente aos logs da sua própria aplicação.
Valor central: ao terminar a leitura, você terá um framework reutilizável de estimativa de custos da API DeepSeek, conseguirá identificar quais requisições vale a pena mover para o horário fora de pico e quais chamadas de ferramentas vale a pena enxugar, além de saber onde buscar dados de preço precisos.
Principais pontos de custo após a precificação por pico e fora de pico da API DeepSeek
Recentemente, aumentaram bastante as discussões na mídia sobre os rumos comerciais da DeepSeek (por exemplo, a reportagem do 36Kr, “Liang Wenfeng desce a montanha: o que a DeepSeek está buscando?”). A mudança na estrutura de preços também é um ponto de atenção para desenvolvedores. Independentemente da lógica comercial por trás disso, para quem faz as chamadas o impacto mais direto é que o modelo de custos deixou de ser “unidimensional” e passou a ser “multidimensional”. A tabela abaixo detalha a nova composição de custos.
| Dimensão de custo | Descrição | Impacto no cálculo |
|---|---|---|
| Fator de faixa horária | Horário de pico e fora de pico usam critérios de cobrança diferentes | É preciso agrupar as requisições por horário; não dá para usar a média do dia inteiro |
| Token de entrada (cache hit) | Parte da entrada que acerta o cache de contexto | O preço unitário é diferente da parte sem cache e precisa ser contabilizado à parte |
| Token de entrada (cache miss) | Entrada que aparece pela primeira vez ou cujo cache expirou | Em aplicações com prompt de sistema longo, é a maior parcela |
| Token de saída | Inclui os tokens do processo de raciocínio em modelos de raciocínio | O volume de saída de modelos de raciocínio costuma ser subestimado |
| Custo de chamada de ferramentas | Uso de ferramentas cobrado por critérios como número de chamadas | Novo item de custo separado, que também aumenta o consumo de tokens |
Os números concretos de preço não aparecem na tabela de propósito. A política de preços da DeepSeek passou por vários ajustes recentemente; em determinado momento, chegou a lançar um desconto noturno fora de pico e depois mudou a estratégia de novo. Se você fixar no modelo de custos um número visto em um único dia, em alguns meses ele vira dado errado. O caminho certo é tratar o preço unitário como um “parâmetro de entrada” do modelo, lido em tempo real da página de preços.
Detalhes importantes da cobrança por faixa horária da API DeepSeek
A essência da precificação por pico e fora de pico é oferecer condições melhores nos períodos de ociosidade de capacidade computacional para tarefas que podem ser executadas com atraso. Para o cálculo, há três detalhes em que é mais fácil errar. O primeiro é o fuso horário: os horários oficiais costumam ser definidos em horário de Pequim (UTC+8), enquanto muitos logs de servidor registram UTC por padrão. Sem converter, um lote inteiro de requisições vai parar na faixa errada. O segundo são requisições que atravessam faixas: uma requisição com saída em streaming longa pode começar no pico e terminar fora de pico. É preciso consultar a regra oficial para saber se a cobrança usa o horário de início ou de término. O terceiro é a retentativa: uma nova tentativa após falha pode cair em outra faixa horária e deve ser contabilizada pelo horário da requisição que de fato teve sucesso.
Detalhes importantes da cobrança de ferramentas da API DeepSeek
A pegadinha da cobrança de ferramentas está na “cobrança dupla”. No caso de ferramentas como busca na web, uma chamada pode gerar a taxa por uso da ferramenta e, além disso, o resultado retornado é injetado no contexto e cobrado novamente como token de entrada na rodada seguinte. Se o modelo chama a ferramenta três ou quatro vezes seguidas em uma mesma conversa, o custo de tokens cresce à medida que o contexto se acumula. Por isso, ao calcular o custo de ferramentas, é preciso contabilizar ao mesmo tempo o “número de chamadas” e os “tokens de entrada adicionais trazidos pelos resultados da ferramenta”. Um sem o outro não fecha a conta.
Guia rápido de custos de invocação da API DeepSeek: recálculo em 5 etapas
O processo abaixo não exige escrever nenhum código; basta exportar os logs e usar uma planilha. Se você já tem uma plataforma de dados, é só traduzir estas etapas para SQL ou relatórios.
Etapa 1: preparar a tabela de parâmetros de preço
Primeiro, crie uma “tabela de parâmetros de preço”. Cada linha é uma variável de cobrança, e todos os preços unitários devem ser obtidos na página de preços, com a data de consulta registrada. Essa etapa determina a precisão de todos os cálculos seguintes.
| Nome da variável | Significado | Origem dos dados |
|---|---|---|
| Preço unitário de entrada com cache hit no horário de pico | Preço de entrada com cache hit no horário de pico | Página de preços da APIYI docs.apiyi.com/models |
| Preço unitário de entrada com cache miss no horário de pico | Preço de entrada com cache miss no horário de pico | Página de preços da APIYI docs.apiyi.com/models |
| Preço unitário de saída no horário de pico | Preço de token de saída no horário de pico | Página de preços da APIYI docs.apiyi.com/models |
| Preço unitário dos três itens correspondentes no horário de baixa demanda | Preços de entrada, cache e saída no horário de baixa demanda | Página de preços da APIYI e comunicados oficiais |
| Preço unitário de invocação de ferramenta | Critério de cobrança e preço unitário de cada tipo de ferramenta | Página de preços da APIYI e comunicados oficiais |
| Limites de horário | Horários de início e fim de pico/baixa e fuso horário | Comunicados oficiais da DeepSeek |
💡 Sugestão de fonte de dados: Atualize a tabela de parâmetros de preço periodicamente com base na página de preços da APIYI docs.apiyi.com/models e anote a “data de consulta” na tabela. Se os preços oficiais mudarem, basta alterar essa tabela e todo o modelo de custo passa a valer automaticamente.
Etapa 2: Exportar logs de uso com carimbo de tempo
Cada log de requisição precisa conter, no mínimo, estes campos: horário de início da requisição, nome do modelo, número de Tokens de entrada, quantos desses Tokens tiveram cache hit, número de Tokens de saída, quantidade de chamadas de ferramentas e tipo de ferramenta. O campo usage na resposta do DeepSeek retorna as estatísticas de Tokens com e sem cache hit, e os Tokens de raciocínio dos modelos de raciocínio também entram na contagem de saída. Se o seu log registra apenas o total de Tokens, vale a pena completar a instrumentação primeiro; caso contrário, os cálculos seguintes serão apenas estimativas grosseiras.
Etapa 3: Agrupar por faixa horária
Converta todos os carimbos de tempo para o horário de Brasília e depois marque cada requisição com a etiqueta “pico” ou “vale”, conforme as fronteiras de pico e vale. Recomendo também subdividir mais uma camada por hora, assim dá para enxergar a onda de tráfego do negócio e usar isso como base para o escalonamento posterior. Muitas equipes só descobrem depois de fazer essa etapa que uma parcela considerável das requisições vem, na verdade, de tarefas agendadas — que poderiam perfeitamente ser deslocadas para execução nos horários de vale.
Etapa 4: Calcular separadamente o custo de Tokens e o custo de ferramentas
Para cada bucket de período, calcule separadamente: Custo de Tokens = entrada com acerto de cache × preço unitário correspondente + entrada sem acerto de cache × preço unitário correspondente + saída × preço unitário correspondente; Custo de ferramentas = número de chamadas de cada tipo de ferramenta × preço unitário correspondente da ferramenta. Por fim, some os dois buckets, pico e vale, para obter o custo total na nova métrica.
Um exemplo ilustrativo usando apenas volumes de uso, sem preços: suponha que um aplicativo de atendimento ao cliente faça 10,000 solicitações por dia em média, com 3,000 Tokens de entrada por solicitação em média, dos quais cerca de 60% acertam o cache, e 500 Tokens de saída; além disso, a cada 5 solicitações, em média, 1 chamada à ferramenta de busca é acionada. Assim, todos os dias serão gerados cerca de 12 milhões de Tokens de entrada com acerto de cache, cerca de 18 milhões de Tokens de entrada sem acerto de cache, cerca de 5 milhões de Tokens de saída e cerca de 2,000 chamadas de ferramentas, além dos Tokens de entrada extras gerados pelo retorno dos resultados das ferramentas ao contexto. Distribua esses volumes conforme a proporção entre pico e vale e multiplique pelos preços unitários da tabela de parâmetros de preço para obter o custo diário real.
Etapa 5: Comparar com a métrica antiga e identificar oportunidades de otimização
Coloque o resultado da nova métrica lado a lado com a estimativa antiga de “preço médio único”; a parte com a maior diferença é o foco da otimização. Há três tipos comuns de conclusão: proporção de uso em horário de pico muito alta, chamadas de ferramentas com frequência excessiva e taxa de acerto de cache baixa. A próxima seção traz práticas específicas para esses três casos.
🚀 Início rápido: se você quiser testar, com o mesmo conjunto de APIs, a diferença de custo entre DeepSeek e outros modelos, pode chamar via APIYI apiyi.com. A APIYI oferece a API dos modelos DeepSeek abordados neste artigo e também é compatível com os formatos de interface da OpenAI e da Anthropic. O código existente normalmente só precisa alterar
base_urle a chave API para integrar; para endereços e parâmetros específicos, consulte o centro de documentação docs.apiyi.com.
Cenários de aplicação e estratégias de custo sob a precificação de pico e vale da API DeepSeek
Diferentes tipos de aplicação têm sensibilidades muito distintas à precificação de pico e vale e à cobrança por ferramentas. Primeiro identifique a qual categoria você pertence e então defina a direção da otimização; isso é mais eficaz do que simplesmente “mover tudo para rodar à noite”.
| Tipo de aplicação | Flexibilidade de horário | Dependência de ferramentas | Estratégia recomendada | Plataformas disponíveis |
|---|---|---|---|---|
| Atendimento ao cliente online / chatbot | Baixa, precisa responder em tempo real | Média | Aumentar a taxa de acerto do cache e enxugar chamadas de ferramentas | APIYI apiyi.com, DeepSeek oficial |
| Processamento em lote de documentos / anotação de dados | Alta, pode ser executado com atraso | Baixa | Agendar tudo para o horário de vale | APIYI apiyi.com, DeepSeek oficial |
| Busca com IA / assistente de pesquisa | Média | Alta | Controlar o número de rodadas de chamadas de ferramentas e comprimir o conteúdo realimentado | APIYI apiyi.com, DeepSeek oficial |
| Agente de código | Média | Alta | Combinar chamadas de ferramentas e encurtar o contexto | APIYI apiyi.com, DeepSeek oficial |
| Tarefas agendadas de geração de conteúdo | Alta | Média | Gerar em lote no horário de vale; no pico, apenas revisar | APIYI apiyi.com, DeepSeek oficial |
Otimização de custos da API DeepSeek para aplicações em tempo real
Aplicações em tempo real não conseguem evitar o horário de pico; o foco deve estar no cache e nas ferramentas. Coloque o System Prompt fixo, os resumos da base de conhecimento e os exemplos Few-shot no início das mensagens e mantenha-os inalterados em nível de bytes; isso pode aumentar significativamente a taxa de acerto do cache. Do lado das ferramentas, pode-se primeiro fazer uma avaliação leve para decidir “se realmente é necessário pesquisar”, evitando que o modelo faça chamadas repetidas em cenários desnecessários.
Agendamento no horário de vale da API DeepSeek para aplicações offline
Tarefas offline são as maiores beneficiadas pela precificação de pico e vale. A ideia é adicionar uma camada de fila de tarefas entre o sistema de negócio e a invocação do modelo: no pico, apenas enfileirar; no vale, consumidores processam em lote. É preciso observar dois pontos: primeiro, a concorrência se concentra no horário de vale, então avalie previamente os limites de taxa e, se necessário, faça limitação em lotes; segundo, defina um tempo limite de segurança para as tarefas, para evitar que tarefas não processadas no vale avancem para o próximo pico e acabem sendo cobradas pelo preço mais alto.
Comparação de soluções de otimização para a cobrança de ferramentas da API DeepSeek
A cobrança por ferramentas é o item novo e também o mais fácil de sair do controle, porque o consumo é decidido pelo próprio modelo. A tabela abaixo compara algumas formas comuns de contenção.
| Solução de otimização | Origem da economia | Cenário de aplicação | Pontos de atenção |
|---|---|---|---|
| Verificação de intenção prévia | Reduz o número de invocações de ferramentas desnecessárias | Assistentes de busca, atendimento ao cliente | A verificação em si também consome tokens, então use um comando leve |
| Limitar o número máximo de rodadas de invocação | Coloca um teto no custo de ferramentas por requisição | Aplicações do tipo agent | Rodadas de menos podem prejudicar a qualidade da resposta |
| Compactar o resultado retornado pela ferramenta | Reduz os tokens de entrada gerados pelo preenchimento de volta | Ferramentas de busca e recuperação | Mantenha apenas o resumo e os campos-chave |
| Reutilização de cache de resultados | Consultas iguais não são invocadas de novo | Cenários com concentração de perguntas populares | Defina um tempo de expiração razoável para evitar informação desatualizada |
| Substituir por recuperação própria | Usar a base de conhecimento própria no lugar de ferramentas pagas | Negócios com conhecimento de domínio estável | É preciso avaliar o custo de construção e manutenção |
Leitura da comparação
A verificação de intenção prévia tem o efeito mais direto sobre a frequência de invocação e serve para a maioria dos cenários de conversa; porém, ela adiciona um pequeno custo de verificação a cada requisição, o que pode não valer a pena em conversas curtas. Já a compactação do resultado retornado pela ferramenta praticamente não tem efeitos colaterais e é uma prática que toda aplicação com ferramentas deveria ativar por padrão. Limitar o número máximo de rodadas de invocação funciona mais como um fusível, para evitar que requisições isoladas gerem faturas anormais por causa de invocações repetidas do modelo.
💡 Sugestão de escolha: o efeito da otimização de custo com ferramentas varia muito de negócio para negócio, então vale começar com um teste A/B em pouco tráfego. Com o APIYI apiyi.com você pode alternar entre modelos diferentes no mesmo formato de interface para fazer testes comparativos e, combinando com o preço unitário em tempo real da página de preços docs.apiyi.com/models, calcular mais rápido o ganho real de cada solução.
Perguntas Frequentes (FAQ)
Q1: O que é a precificação de pico e vale da API DeepSeek?
A precificação de pico e vale significa que o mesmo modelo tem critérios de cobrança diferentes conforme o horário; normalmente o preço é menor nos horários ociosos (vale), para incentivar que tarefas que podem ser adiadas usem a capacidade computacional fora dos horários de pico. Os limites exatos dos períodos e a magnitude dos descontos devem ser consultados nos anúncios oficiais da DeepSeek e na página de preços da APIYI.
Q2: Comparada à precificação unificada anterior, qual é a diferença no método de cálculo?
Na precificação unificada, basta “Total de Tokens × preço unitário”; na precificação de pico e vale, é preciso primeiro separar as requisições por horário em buckets, aplicar o preço de cada bucket separadamente e então somar a taxa de chamada de ferramentas. Usar a média diária para estimar esconde o desvio causado pela proporção de horário de pico, especialmente em negócios com tráfego concentrado durante o dia.
Q3: Quando uma requisição atravessa os períodos de pico e vale, qual horário é usado para a cobrança?
Isso depende das regras oficiais de cobrança. O critério comum é calcular pelo horário de início da requisição, mas não se pode simplesmente presumir. Recomenda-se tornar o “ponto de referência de cobrança” um parâmetro configurável no modelo de cálculo, preenchê-lo depois de confirmar o critério oficial e marcar separadamente as requisições de streaming longas para fazer verificação por amostragem.
Q4: Por que a cobrança de ferramentas faz o custo “dobrar”?
Porque a chamada de ferramentas costuma gerar duas cobranças: a taxa da própria chamada da ferramenta e a cobrança do resultado da ferramenta, que retorna ao contexto e é cobrado novamente como Tokens de entrada. Em chamadas de ferramentas com múltiplas rodadas, o contexto vai crescendo, e cada rodada posterior paga pelos resultados anteriores; por isso é preciso controlar ao mesmo tempo o número de chamadas e o comprimento do conteúdo de retorno.
Q5: Como chamar o DeepSeek rapidamente via API e verificar o custo?
Siga os passos abaixo:
1. Acesse APIYI apiyi.com, registre uma conta e obtenha a API Key
2. No centro de documentação docs.apiyi.com, consulte o endereço de acesso e escolha o formato compatível com OpenAI ou Anthropic
3. Na página de preços docs.apiyi.com/models, consulte os preços unitários de entrada, saída e cache dos modelos DeepSeek relacionados
4. Rode o cálculo em 5 etapas deste artigo com uma requisição de baixo volume e calibre comparando com o registro de controle da conta
A APIYI oferece a chamada dos modelos DeepSeek abordados neste artigo, com formato de interface compatível com os principais SDKs, o que facilita a substituição direta para validação em projetos existentes.
Q6: Ao chamar por plataformas de terceiros, os critérios de pico/vale e de cobrança de ferramentas são os mesmos?
Plataformas diferentes podem ter critérios de cobrança diferentes dos oficiais, por exemplo, se distinguem horários, como convertem a taxa de ferramentas, etc. Ao chamar via APIYI, use como referência os dados reais indicados na página de preços da APIYI, docs.apiyi.com/models, e não aplique diretamente a tabela oficial de preços; confirmar isso antes do cálculo evita a maior parte dos erros de conciliação.
Q7: Quais são as limitações conhecidas do cálculo de custo da API DeepSeek?
Há três principais. Primeiro, os preços mudam, e o modelo precisa suportar atualização parametrizada; segundo, o comprimento dos Tokens de raciocínio dos modelos de raciocínio varia muito, e estimar pela média tem erro alto — recomenda-se usar quantis; terceiro, o número de chamadas de ferramentas é decidido pelo próprio modelo, e o mesmo comando difere bastante com entradas diferentes, sendo necessário monitoramento contínuo e não apenas uma estimativa pontual.
Pontos-chave do cálculo de custos da precificação por horário de pico e fora de pico da API DeepSeek
- O custo passa a ser multidimensional: faixa de horário, cache, saída e ferramentas determinam juntos a fatura
- O preço unitário precisa ser parametrizado: os preços devem seguir os dados em tempo real da página de preços da APIYI, sem valores fixos no código
- Alinhe o fuso horário primeiro: converta os logs para o horário de Brasília (ou para o fuso de referência) antes de dividir por pico e fora de pico, evitando classificar lotes inteiros errado
- Ferramentas cobram em dobro: taxa de chamada mais Tokens de preenchimento (fill-in); é preciso contabilizar as duas coisas
- Tarefas offline vão para fora de pico: usar uma fila de tarefas para suavizar os picos é a otimização com retorno mais direto
- Tarefas em tempo real dependem do cache: mantenha o prefixo fixo inalterado para aumentar a taxa de acertos do cache
- O cálculo pode ser validado rapidamente: faça um teste com pouco tráfego na interface compatível da APIYI e calibre o modelo comparando com a fatura
Conclusão
Depois que a API DeepSeek introduziu preços por horário de pico e fora de pico e cobrança por ferramentas, as mudanças centrais no cálculo de custos podem ser resumidas em três pontos:
- Do total para a divisão em faixas: divida as requisições por faixa de horário e precifique pico e fora de pico separadamente, para enxergar a real estrutura de custos
- De Tokens para Tokens mais ferramentas: a taxa de ferramentas é um item de custo independente e ainda tende a elevar os Tokens de entrada
- De estimativa estática para monitoramento contínuo: preços mudam e o uso muda, então o modelo de cálculo deve ser parametrizado e recalibrado periodicamente
Sugiro rodar primeiro o fluxo em 5 passos deste artigo sobre os logs da última semana, levantar três indicadores-chave — proporção de requisições em horário de pico, frequência de chamadas de ferramentas e taxa de acerto do cache — e então otimizar de forma direcionada. Se quiser testar o DeepSeek e outros modelos sob uma interface unificada, você pode integrar pela APIYI apiyi.com; o modo de integração está no centro de documentação docs.apiyi.com. Todos os preços unitários devem se basear nos dados reais da página de preços docs.apiyi.com/models.
📚 Referências
- Reportagem do 36Kr: 《Liang Wenfeng desce a montanha: o que a DeepSeek está buscando?》
- Link:
36kr.com/p/4055279154779015 -
Descrição: reportagem do setor sobre os movimentos recentes de comercialização da DeepSeek, útil como referência para entender o contexto do ajuste de preços
-
Página de preços da APIYI: preços unitários de entrada, saída e cache de modelos como o DeepSeek
- Link:
docs.apiyi.com/models -
Descrição: fonte de todos os parâmetros de preço usados neste artigo; recomenda-se conferir antes de fazer os cálculos
-
Central de documentação da APIYI: instruções de integração e formato de interface
- Link:
docs.apiyi.com -
Descrição: inclui instruções de integração nos formatos compatíveis com OpenAI e Anthropic
-
Documentação oficial da API DeepSeek: regras de cobrança e descrição do campo usage
- Link:
api-docs.deepseek.com - Descrição: os limites dos períodos de pico e vale, o mecanismo de cache e os critérios de cobrança de ferramentas seguem a documentação oficial
Autor: Equipe técnica da APIYI
Contato técnico: se você tiver dúvidas durante o cálculo de custos ou a integração, fale conosco pelo site oficial da APIYI, apiyi.com. Mais materiais de integração estão disponíveis na central de documentação em docs.apiyi.com
