Um pipeline de texto pode precisar de extração, revisão de documentos ou roleplay, cada um com um orçamento de saída diferente. Para uma integração nova, comece com deepseek/v4.1-flash/chat: $0,30 de entrada e $1,20 de saída por milhão, com limite de resposta de 384.000 tokens. Se a sua integração estiver fixada em um ID V4, use o V4 Flash para o trabalho de rotina; escolha o Pro pelo controle explícito de chamadas paralelas de tools, para uma resposta acima de 65.536 tokens ou para uma tarefa específica em que o resultado justifique pagar três vezes mais por token. Os dois IDs V4 leem 1.048.576 tokens, então uma entrada longa, por si só, não é motivo para pagar pelo Pro.
O guia de migração para o V4.1 Flash cobre o caminho para projetos novos. As comparações abaixo valem para os dois IDs V4 hospedados.
Qual modelo para qual trabalho
| Seu trabalho | Escolha | Por quê |
|---|---|---|
| Extração, classificação, saída em JSON, chat de rotina | V4 Flash | Mesma janela de entrada, um terço do preço por token |
| Primeira passada de revisão de código ou documentos que uma pessoa ou um segundo modelo confere | V4 Flash | O jeito mais barato de varrer; encaminhe só os achados incertos |
| Uma única resposta com mais de 65.536 tokens (plano de migração completo, transformação de um conjunto inteiro) | V4 Pro | Limite de 384.000 tokens contra 65.536 |
Workflow que precisa definir parallel_tool_calls na requisição | V4 Pro | O Flash não aceita o campo |
| Passada final de verificação sobre o rascunho de um modelo mais barato | V4 Pro | Mantenha a passada mais cara focada em um subconjunto pequeno e embasado em evidências |
| Revisão de arquitetura, planos de refatoração, documentação | Teste o Pro após uma varredura com o Flash | Cobertura mais ampla no benchmark de uma única base de código abaixo; útil quando o detalhe perdido importa |
| Edições de código guiadas por referências exatas de linha | Flash mais verificação do código-fonte; adicione o Pro se necessário | Os dois modelos fizeram algumas afirmações incorretas no benchmark; a inspeção do código-fonte e os testes da aplicação decidem a correção |
| Roleplay ou ficção em volume | V4 Flash | Cerca de $0,57 contra $1,72 por 100 turnos de roleplay |
As diferenças de contrato
| Contrato atual | V4 Flash | V4 Pro | V4.1 Flash (para referência) |
|---|---|---|---|
| ID do modelo | deepseek/v4-flash/chat | deepseek/v4-pro/chat | deepseek/v4.1-flash/chat |
| Limite de entrada | 1.048.576 tokens | 1.048.576 tokens | 1.048.576 tokens |
| Limite máximo de saída | 65.536 tokens | 384.000 tokens | 384.000 tokens |
| Limite de saída padrão | 32.768 tokens | 32.768 tokens | 32.768 tokens |
reasoning_effort | none, low, high (padrão high) | none, low, high (padrão high) | none, low, high (padrão high) |
| Entrada usada neste guia | Mensagens de texto | Mensagens de texto | Mensagens de texto |
| Saída em objeto JSON | Compatível | Compatível | Compatível |
parallel_tool_calls | Não aceito | Aceito; padrão true | Não aceito |
| USD por milhão de entrada / em cache / saída | $0,44 / $0,014 / $1,32 | $1,32 / $0,044 / $3,96 | $0,30 / $0,006 / $1,20 |
| Velocidade de saída na avaliação da SpicyAPI | 40 tokens/s | 46 tokens/s | Não informada |
As páginas do V4 Flash e do V4 Pro mostram os campos hospedados atuais. Ambos permitem até 256 mensagens e 128 definições de tools, com até 60 minutos por requisição, e nenhum expõe temperature ou top_p. A página de comparação da SpicyAPI mostra os mesmos campos a partir do esquema ao vivo.
Os dois endpoints rejeitam campos que não listam. Um corpo copiado do endpoint do Pro com parallel_tool_calls falha na validação no Flash em vez de ser ignorado, então mantenha separados os campos específicos de cada modelo em vez de enviar a união.
Onde esses IDs estão na origem. O registro de alterações atual da DeepSeek aposenta o V4 Flash e redireciona temporariamente o alias antigo para o V4.1 Flash, enquanto o serviço do V4 Pro continua com a cobrança inalterada. A SpicyAPI lista os IDs separados acima; ao manter uma integração V4, fixe o ID hospedado completo, não um alias da origem. O anúncio de 10 de setembro da DeepSeek descreve os redirecionamentos dos aliases nativos, então um resultado de fórum que usou aliases nativos pode nem comparar as versões V4 originais; diferencie nomes de modelos, IDs com versão e resultados observados antes de confiar em qualquer página de «Flash vs Pro». Para um projeto novo, o preço mais baixo e o limite de resposta maior do V4.1 Flash são o motivo prático para começar por ele.
O que outros desenvolvedores encontraram com a dupla
Um benchmark de revisão de código com 18 execuções em uma base de código Python, com os snapshots datados 0731 do Flash e 0813 do Pro, encontrou uma diferença útil:
- Cobertura: o Pro produziu 169 afirmações verificáveis contra 70 do Flash. A precisão das afirmações ficou próxima: 95,9% contra 95,7%.
- Detecção de bugs: o Flash encontrou os três bugs latentes conhecidos; o Pro encontrou um. O Flash também inventou um caso extremo, então verifique as correções propostas no código-fonte.
- Consistência: a profundidade dos relatórios do Pro variou 2,7 vezes entre execuções repetidas. Uma varredura com o Flash seguida de uma verificação focada com o Pro teve o melhor desempenho nesse arranjo.
Use o Flash para a primeira passada barata e envie ao Pro um achado incerto, sua fonte e uma pergunta precisa. O relatório de nenhum dos modelos substitui a verificação do código-fonte nem os testes da aplicação.
Experimente primeiro no Playground
- Abra o DeepSeek V4 Flash e mude para o Playground.
- Cole o registro de aprovação do catálogo e de timeout do inventário do exemplo. Pergunte se o job E42 pode ser exportado.
- Repita no V4 Pro com a mesma entrada. As duas respostas devem bloquear a exportação, porque a consulta atual do inventário falhou.
Teste os dois em uma decisão com uma única resposta certa
Suponha que a exportação da vitrine de um creator dependa de um catálogo aprovado e de uma consulta atual do inventário. O modelo precisa apontar o que bloqueia a exportação sem tratar uma etapa pendente como concluída. O caso de teste é barato o bastante para rodar nos dois modelos antes de você enviar uma transcrição grande.
Defina SPICY_API_KEY usando uma chave de API Keys. A requisição usa a interface Chat Completions da SpicyAPI.
cat > request.json <<'JSON'
{
"model": "deepseek/v4-flash/chat",
"messages": [
{
"role": "system",
"content": "Return JSON with can_export (boolean), blockers (array of strings), and evidence (array of exact source quotes). Use only the supplied record. Every required dependency must be complete before export."
},
{
"role": "user",
"content": "Job E42 requires catalog approval and a current inventory lookup. Record: \"Catalog approved at 10:00. Inventory lookup timed out at 10:03. The last inventory snapshot is from yesterday.\" Can this job be exported now?"
}
],
"max_tokens": 2048,
"reasoning_effort": "low",
"response_format": {
"type": "json_object"
}
}
JSON
curl --fail-with-body https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
--data-binary @request.json --output response.json
python3 - <<'PY'
import json
from pathlib import Path
response = json.loads(Path("response.json").read_text())
choice = response["choices"][0]
if choice.get("finish_reason") != "stop":
raise SystemExit("FAIL: reply did not finish normally")
answer = json.loads(choice["message"]["content"])
quotes = {"Catalog approved at 10:00.",
"Inventory lookup timed out at 10:03.",
"The last inventory snapshot is from yesterday."}
blockers = answer.get("blockers")
evidence = answer.get("evidence")
valid = (
answer.get("can_export") is False
and isinstance(blockers, list) and bool(blockers)
and all(isinstance(item, str) and item.strip() for item in blockers)
and any("inventory" in item.lower() for item in blockers)
and isinstance(evidence, list) and bool(evidence)
and all(isinstance(item, str) and item in quotes for item in evidence)
and "Inventory lookup timed out at 10:03." in evidence
)
if not valid:
raise SystemExit("FAIL: decision, blocker or source evidence is incorrect")
print("PASS: export is blocked by the timed-out inventory lookup")
PYA decisão correta é can_export: false, com a falta do inventário atual como bloqueio. O snapshot de ontem não é a consulta atual exigida, e o array evidence deve citar a linha do timeout.
Isto é uma verificação de caso de teste, não um validador de negócio geral: exportações reais devem usar os status de dependência reais da sua aplicação. Um modelo pode citar uma frase verdadeira e ainda assim chegar à conclusão errada, e é por isso que aqui se verificam tanto a decisão quanto a evidência.
Para rodar o Pro com a mesma entrada, troque apenas o ID do modelo. Mantenha idênticos a fonte, as instruções, o effort e o limite de saída, e avalie cada resposta em dois pontos: ela apontou o bloqueio e as citações aparecem no registro? Uma explicação mais longa não é uma decisão melhor.
Se o Flash passar, este caso de teste não lhe dá motivo para pagar pelo Pro nessa tarefa. Se qualquer um dos modelos inventar um sucesso do inventário, não repasse a resposta adiante só porque o JSON foi analisado. Se os dois falharem, confira se o requisito foi enunciado com clareza antes de tratar um preço maior como a solução.
Deixe um Agent preparar a chamada
Para verificações repetidas de decisão de exportação, peça ao seu Agent de código que use a Skill da SpicyAPI: «Read deepseek/v4-flash/chat, then adapt the example to my input; show the request before running it.» A consulta pela CLI é spicyapi models get deepseek/v4-flash/chat --json; pelo MCP, spicyapi_model_get com model: "deepseek/v4-flash/chat". As chamadas de chat usam um cliente compatível ou a API de chat; os comandos de tasks de mídia não geram respostas de chat.
Qual workflow merece a tarifa mais alta?
Para extrair a data de lançamento, os nomes dos personagens e a quantidade de imagens pedida por um creator a partir de um briefing completo, o Flash tem os controles comuns e folga de capacidade de saída. O limite de saída maior do Pro não traz benefício para um objeto JSON curto. Comece com o Flash e use valores ausentes explícitos, para que «no release date supplied» não vire uma data inventada.
Para uma revisão de dependências com vários registros, torne concretas as regras do job. Uma referência de personagem aprovada não basta quando o plano precisa de um segundo personagem aprovado e de um asset de inventário atual. Um modelo deve identificar a aprovação faltante do segundo personagem mesmo que a transcrição de produção ao redor repita que o plano está pronto. O caso de teste acima verifica essa distinção usando o inventário. Pode valer a pena comparar com o Pro em um job complexo que falhou.
Para uma transformação muito grande, o requisito de saída pode decidir a escolha sem qualquer afirmação sobre qualidade. Se o documento realmente devolvido precisar passar de 65.536 tokens em uma única resposta, o limite do Flash não comporta e o Pro permite mais saída. Se registros independentes puderem ser devolvidos em grupos menores, o processamento em lotes pode manter o Flash utilizável e facilitar a repetição de um grupo que falhou. Não divida uma tarefa cuja resposta dependa das relações entre esses grupos sem levar essas relações de um grupo para o outro.
Uma escalada seletiva só é econômica enquanto continuar seletiva. Sob as premissas de 50.000 tokens de entrada e 3.000 de saída abaixo, 900 chamadas ao Flash mais 100 ao Pro custam $31,152, contra $77,88 para todas as 1.000 no Pro. Se todo job passar primeiro pelo Flash e 100 precisarem depois do Pro, o total combinado é $33,748. São totais hipotéticos que explicam o equilíbrio das novas tentativas; o uso real de tokens vai variar.
Quanto custa uma requisição com o mesmo uso
Para uma requisição com 50.000 tokens de entrada sem cache e 3.000 tokens de saída cobrados:
- Flash: 50.000 × $0,44/M + 3.000 × $1,32/M = $0,02596.
- Pro: 50.000 × $1,32/M + 3.000 × $3,96/M = $0,07788.
Mil requisições assim custam $25,96 e $77,88. Se 40.000 dos tokens de entrada forem leituras de cache e 10.000 não, os valores por requisição passam a $0,00892 para o Flash e $0,02684 para o Pro. As tarifas de cache não guardam uma proporção exata de três para um, então calcule os totais em vez de arredondar a partir do preço de tabela.
Duas coisas pesam mais na conta do que a escolha do modelo:
- O raciocínio é cobrado como saída. O effort padrão é
high. Para extração e classificação, testelow, ounonepara pular a etapa de raciocínio, e compare os resultados aceitos além dos tokens. - As novas tentativas contam. O que importa é o custo por resposta aceita, não por chamada.
A escalada seletiva preserva a maior parte da economia. Mande tudo para o Flash e envie ao Pro um resultado falho ou ambíguo, junto com a evidência de por que falhou. Se uma em cada dez requisições escalar com o uso acima, e uma requisição escalada pagar tanto a chamada ao Flash quanto a ao Pro, a média é de cerca de $0,03375 por requisição, contra $0,0779 com tudo no Pro. Um segundo modelo pode repetir o mesmo erro, então mantenha a verificação real de correção da tarefa.
Quando a saída maior do Pro importa
O limite de 384.000 tokens só importa quando a resposta necessária realmente passa de 65.536 tokens, por exemplo um plano de migração ordenado com o SQL e o rollback de cada etapa que precise voltar junto. Um relatório curto sobre uma entrada longa não se enquadra: a capacidade de entrada é idêntica.
Antes de pedir uma resposta enorme, confirme que o seu consumidor consegue validá-la e armazená-la. Uma edição capítulo por capítulo, ou registros divididos em grupos independentes, é mais fácil de recuperar depois de uma interrupção. Mantenha uma única resposta apenas quando as partes dependerem de uma estrutura compartilhada.
Não confunda o máximo com o padrão. Ambos têm padrão de 32.768 tokens de saída, e uma resposta que atinge o limite é cortada sem erro. Defina um valor explícito pequeno para tarefas curtas, como o caso de teste acima, e um maior só onde a entrega exigir.
Quando as chamadas paralelas de tools importam
O Pro aceita parallel_tool_calls; o Flash não. Isso diz qual corpo de requisição você pode enviar, não que o Flash não consiga usar tools: ambos aceitam definições de tools e tool_choice.
Leituras independentes são candidatas a chamadas paralelas, como buscar ao mesmo tempo um catálogo aprovado e um registro de inventário. A ação de exportar depende dos dois resultados e precisa esperar. Imponha essa dependência na sua aplicação em vez de tratar uma sequência de tools proposta como permissão para agir. Definir parallel_tool_calls como false no Pro dá no máximo uma chamada por turno quando cada chamada precisa do resultado anterior.
Se o seu loop exige esse controle explícito, é um motivo concreto para o Pro. Se ele executa consultas sequenciais e devolve uma resposta curta, comece no Flash e acrescente concorrência só depois que o loop básico funcionar.
Escrita e roleplay sem censura
Os dois modelos têm o nível «Uncensored» na SpicyAPI: sem filtro de conteúdo da plataforma, e o que resta é o comportamento próprio de cada modelo. Em nossos testes da escada de conteúdo de setembro de 2026, ambos recusaram um pedido direto da categoria de cena adulta de maior intensidade (L4 nas avaliações) quando chegava sem contexto, e ambos o escreveram quando um prompt de sistema estabelecia um enquadramento de escrita de ficção:
| Cena adulta de maior intensidade (L4) | V4 Flash | V4 Pro |
|---|---|---|
| Pedido direto, sem enquadramento | Recusado (3 de 3) | Recusado (3 de 3) |
| Apresentado como história | 2 escritos, 1 suavizado | 1 tentativa, recusada |
| O prompt de sistema define o contexto de ficção | Escrito (3 de 3) | Escrito (3 de 3) |
No L5, cada modelo concluiu três formulações do briefing de ficção adulta e três de um briefing separado de ficção gráfica não adulta. O Flash suavizou uma execução na categoria sugestiva mais leve; as demais sondas de níveis mais baixos foram concluídas. Portanto, para ficção adulta, enquadre o job no prompt de sistema em qualquer um dos modelos, e não pague pelo Pro na esperança de que ele recuse menos. Nossas avaliações do V4 Flash e do V4 Pro listam cada execução.
O roleplay gera muita saída, e é aí que a proporção de preço de três para um aparece: cerca de $0,57 por 100 turnos no Flash contra $1,72 no Pro, supondo 10.000 tokens de entrada sem cache e 1.000 tokens de saída cobrados por turno, incluindo qualquer raciocínio.
FAQ
O V4 Flash basta para programar?
É o ponto de partida mais barato, e o benchmark de uma única base de código encontrou os três bugs conhecidos com o Flash. Antes de uma edição sugerida, verifique o código-fonte citado e rode os testes afetados. Uma passada focada com o Pro é uma opção de escalada, não um substituto para essas verificações.
O Flash é lento?
A avaliação da SpicyAPI registrou 40 tokens de saída por segundo para o Flash e 46 para o Pro. Essa diferença modesta não é, por si só, motivo para triplicar o orçamento de tokens, e a latência real depende do raciocínio e da resposta. Reduza o effort em tarefas curtas em vez de tratar esse instantâneo como garantia de velocidade atual.
Por que escolher o Flash se o Pro é o modelo maior?
Os dois IDs hospedados aceitam a mesma entrada longa, enquanto o Flash custa cerca de um terço nas tarifas de tokens sem cache. Para respostas curtas de extração ou classificação, o limite de saída maior do Pro não traz nada por si só. Escale um resultado ambíguo quando você tiver uma pergunta concreta para a passada mais cara.
Devo começar uma integração nova no V4 ou no V4.1 Flash?
Comece com o V4.1 Flash, a menos que precise de um contrato V4 específico ou tenha uma integração fixada para manter. Só o alias aposentado do V4 Flash é redirecionado para o V4.1; o V4 Pro continua, e esses contratos hospedados seguem listados separadamente. Verifique de novo qualquer comportamento do qual a sua aplicação dependa antes de migrar o tráfego de produção.







