DeepSeek V4-Flash-Vision-Exp: preço, visão e roteamento

O lançamento registrado em 21 de agosto de 2026 colocou o DeepSeek-V4-Flash-Vision-Exp na documentação oficial da DeepSeek como um modelo experimental que aceita entrada de imagem além de texto. A tabela de preços publicada mostra US$ 0,22 por milhão de tokens de input em cache miss fora do pico. A consequência para o comprador é direta: a rota multimodal precisa ser medida por requisição, não escolhida por um preço isolado. A página oficial de preços é a fonte consultada em 25 de agosto de 2026.

O que foi lançado e o que a documentação confirma?

A documentação oficial confirma que o DeepSeek-V4-Flash-Vision-Exp é experimental, usa deepseek-v4-flash-vision-exp na chamada da API e aceita entrada de imagem adicionalmente ao texto. A mesma página publica seis valores por milhão de tokens, divididos entre input em cache hit, input em cache miss e output, sempre em duas janelas de cobrança. Fato central, sem extrapolação.

Fato confirmado: a página Your First API Call lista deepseek-v4-flash-vision-exp como identificador de API e informa que a versão experimental aceita imagens. A página de preços nomeia a versão como DeepSeek-V4-Flash-Vision-Exp. A documentação também informa que a conversão da imagem em tokens depende das dimensões da imagem. Este texto não reproduz benchmarks nem declara liderança, superioridade ou equivalência.

Os seis preços publicados são estes:

Cache hit e cache miss são as duas categorias de cobrança de input publicadas pelo provedor. O comprador deve usar o uso registrado pelo provedor e o status de cache de cada requisição para classificar a chamada. Se explicar mecanismos de prefixo ou cache de contexto, precisa consultar a documentação específica, porque a tabela de preços não define essa semântica.

A documentação define como horário de pico os períodos de 01:00 a 04:00 UTC e de 06:00 a 10:00 UTC, de segunda a sexta-feira. Todos os demais horários são classificados na própria nota da tabela como fora do pico. Uma equipe que opera no Brasil precisa registrar o horário em UTC, e não inferir a faixa a partir do relógio local do serviço. Horário muda a conta.

A página oficial ainda avisa que os preços podem variar e que o provedor pode ajustá-los. Por isso, os seis valores acima são o registro datado da tabela oficial consultada em 25 de agosto de 2026. Eles não são promessa de custo efetivo para uma aplicação específica, nem substituem a leitura periódica da documentação oficial.

Inferência operacional: o comprador deve guardar a data de leitura da tabela junto com o relatório de consumo. Sem essa data, uma comparação feita semanas depois mistura preço de referência e preço vigente.

Por que o preço por token não basta em uma requisição multimodal?

O preço por token não basta porque a imagem enviada ao DeepSeek-V4-Flash-Vision-Exp é convertida em tokens conforme suas dimensões e cobrada junto com os tokens de input do texto. O custo da requisição depende, portanto, da imagem, do texto, do cache, do horário e da quantidade de saída consumida. A medição muda tudo.

A fórmula publicada pela documentação é simples: a despesa resulta do número de tokens multiplicado pelo preço correspondente. A parte difícil está em identificar corretamente o número e a categoria de cada token. Em uma requisição multimodal, os tokens da imagem entram no input. Não existe uma cobrança separada de imagem apresentada na tabela consultada.

A documentação oficial de Vision, consultada em 25 de agosto de 2026, informa que as imagens são redimensionadas antes da inferência. Imagens maiores são reduzidas para um orçamento aproximado de 800 x 800 pixels totais, imagens pequenas são ampliadas, e cada imagem tem um limite superior documentado de 384 tokens sob essa regra de processamento. Em uma requisição com várias imagens, cada imagem é contada de forma independente. O limite de 384 tokens é condicional a essa mecânica documentada, não uma propriedade geral de modelos multimodais.

As dimensões da imagem permitem estimar a tokenização, e a página de uso de tokens oferece uma calculadora para tamanhos específicos. Essa estimativa não substitui os tokens de imagem efetivamente registrados na resposta de uso da API, que devem ser separados da estimativa ao comparar a cobrança. Sem nomear e citar o campo de uso correspondente na documentação da API, o artigo não trata esse registro como definitivo. Não existe custo universal para uma foto, captura de tela, página digitalizada ou quadro técnico. Estimativa não é fatura.

Esse ponto muda a unidade de análise. “US$ 0,22 por milhão” descreve o preço do input em cache miss fora do pico. Não descreve o custo de uma requisição que combina imagem, instrução textual e resposta. Da mesma forma, “US$ 0,007 por milhão” vale para input em cache hit fora do pico, não para qualquer entrada enviada ao modelo.

O output também merece uma linha própria. A tabela publica US$ 0,66 por milhão de tokens fora do pico e US$ 1,32 por milhão de tokens no pico. Uma tarefa com pouco input e resposta extensa não deve ser comparada apenas pela linha de input. O campo de saída precisa permanecer separado no relatório.

O erro mais comum é somar tokens de entrada e de saída como se fossem uma mesma categoria. Isso apaga a distinção entre input cache hit, input cache miss e output. O segundo erro é tratar a imagem como um anexo sem peso econômico. A documentação oficial diz o contrário: a imagem convertida entra na cobrança de input.

Ponto ainda não verificado: a documentação consultada não permite afirmar um custo universal por classe de imagem. As dimensões permitem uma estimativa, mas os tokens e o uso efetivamente registrados em cada chamada definem a referência da API. Também não cabe converter os preços publicados em percentual de economia sem dados de uso comparáveis. A medição encerra a dúvida.

O que muda para o comprador de IA em produção?

Para o comprador de IA em produção, a entrada de imagem amplia o conjunto de tarefas que pode entrar em avaliação, mas eleva o número de variáveis que precisam ser observadas. A decisão correta não é adotar o modelo por parecer barato. É testar custo por tarefa concluída, qualidade da resposta, latência, comportamento do cache e disponibilidade no fluxo que será roteado. Preço não decide sozinho.

Fato confirmado: a DeepSeek descreve o modelo como experimental. A documentação consultada não sustenta uma recomendação universal, disponibilidade geral, SLA ou liderança de desempenho. O texto da tabela também não serve como benchmark de qualidade visual ou textual.

Inferência operacional: o CTO precisa tratar o modelo como uma rota candidata, não como destino padrão. O líder de plataforma deve separar tarefas que usam imagem de tarefas textuais e registrar se a resposta atende ao critério de negócio. O responsável por FinOps precisa olhar custo por tarefa concluída, porque tokens baratos não garantem uma resposta útil na primeira tentativa.

A documentação oficial de preços, consultada em 25 de agosto de 2026, lista 1 milhão de tokens de contexto, máximo de 384 mil tokens de saída e limite de concorrência de 2.500 para deepseek-v4-flash-vision-exp. O guia oficial de Vision, consultado na mesma data, documenta formatos de imagem suportados, limite de 48 MiB para o corpo da requisição, 32 MiB para imagens em base64 ou URL externa, 64 MiB para IDs da Files API e até 600 imagens por requisição. O limite máximo é de 8.192 pixels por lado, reduzido para 4.096 pixels quando a requisição contém 15 ou mais imagens. São valores de documentação acessados em 25 de agosto de 2026, não SLA nem garantia de disponibilidade.

Uma classificação de qualidade deve ser definida antes do teste. Em leitura de documentos, por exemplo, o time pode verificar campos extraídos corretamente, omissões e necessidade de revisão humana. Em análise de imagem, pode verificar se a resposta identifica os elementos exigidos pela tarefa. O artigo não atribui ao modelo uma capacidade que a fonte oficial não descreveu. O teste é quem deve responder à pergunta de adequação.

Latência e horário entram na mesma decisão. Uma janela fora do pico pode apresentar preço publicado menor, mas o comprador não deve deslocar tráfego sensível sem medir o efeito sobre o tempo de resposta e a operação. O pico tem duas faixas em UTC. A política precisa transformar essa informação em um campo observável, não em uma regra escondida no código.

O modo de falha também precisa ser nomeado. Um fluxo pode enviar uma imagem grande, receber uma resposta incompleta, repetir a requisição e pagar novamente tokens de input e output. Pode ainda encaminhar a mesma tarefa para outra rota sem registrar a causa. Quando isso acontece, o custo por tarefa fica invisível e a equipe conclui que o modelo é caro, quando o problema real foi uma política de retry sem rastreabilidade.

Esse é o tipo de medição tratado em como medir o desempenho de provedores de LLM antes de definir uma política de roteamento. A diferença aqui é que a entrada de imagem adiciona uma variável de tokens que precisa aparecer no baseline desde o primeiro teste.

Como comparar o custo antes de mudar a rota?

A comparação precisa sair do preço unitário e chegar a uma política de requisição. Antes, uma equipe poderia olhar a linha de input e escolher a rota por intuição. Depois, deve registrar imagem, texto, saída, cache, horário UTC, qualidade e custo por tarefa, além de manter um fallback quando a resposta ou a disponibilidade não atenderem ao critério definido. A planilha precisa de contexto.

A coluna da direita não afirma que o modelo terá determinado custo efetivo. Ela descreve o que o comprador precisa medir para chegar a esse custo. A tabela oficial é o ponto de partida. O resultado de produção só aparece depois que a equipe observa seu próprio tráfego.

Não há base para calcular economia percentual a partir dos seis números. O preço fora do pico é publicado em uma faixa, o preço no pico em outra, e a requisição pode combinar cache miss, imagem e output. Sem volume, dimensões, distribuição de cache, horários e qualidade, qualquer percentual seria uma fabricação.

A mudança de rota também deve considerar a estabilidade do resultado. Se a resposta falha no critério da tarefa, um segundo processamento pode consumir mais tokens do que a primeira chamada. Se a equipe não registra retrabalho, a planilha apresenta um preço baixo e uma operação cara.

O comprador que já acompanha a economia de modelos em roteamento pode reutilizar a disciplina de break-even, mas não deve importar uma conclusão de uma versão para outra. O evento atual tem entrada de imagem e uma composição de cobrança específica. A unidade correta continua sendo a tarefa observada.

O que medir no teste do DeepSeek V4-Flash-Vision-Exp?

O teste deve responder cinco decisões antes de qualquer mudança de rota padrão: quais tarefas entram, que imagens serão medidas, como cache e horário serão comparados, qual qualidade aprova a resposta e quando o fallback será acionado. Cada decisão precisa de registro por requisição e de um baseline anterior à adoção. Teste começa pequeno.

1. Definir o baseline textual e multimodal. O time deve separar tarefas que já usam texto das tarefas que enviarão imagem, registrar volume, tokens de texto, tokens de output e resultado operacional. Sem esse corte, uma variação de custo pode vir da mistura de tarefas, e não do modelo.

2. Montar um corpus representativo e anonimizado. A amostra fixa deve conter as classes de imagem que a operação realmente recebe, como capturas, documentos digitalizados, imagens de produto e quadros técnicos, com dimensões registradas e dados pessoais removidos. O mesmo corpus deve ser executado no DeepSeek e na rota incumbente, em comparação pareada.

3. Fixar a rubrica e medir a qualidade. Antes de olhar o preço, o time deve definir critérios de aprovação por tarefa, como campos corretos, ausência de omissões, identificação dos elementos exigidos e necessidade de revisão humana. A rubrica não muda durante o ciclo. O relatório deve trazer sucesso na primeira passagem, taxa de revisão humana, retries, latência e custo por tarefa aceita, além de tokens e cache.

4. Separar cache e horário. Cada chamada precisa carregar cache_status e horario_utc. A equipe deve comparar input cache hit com input cache miss e distinguir as faixas de 01:00 a 04:00 UTC e 06:00 a 10:00 UTC, de segunda a sexta, dos demais períodos. A tabela publicada orienta o teste, não promete o resultado.

5. Decidir fallback e limite de exposição. O time deve fixar quando a resposta será encaminhada para outra rota, qual limite de gasto será aceito por chave ou projeto e como cada troca será auditada. A política precisa usar backoff exponencial limitado por um teto, circuit breaker e um orçamento máximo conjunto de retries e fallbacks por tarefa. Erros transitórios de transporte ou do provedor podem entrar na política; requisições inválidas, como formato, tamanho, dimensão ou contagem de imagem não suportados, e seleção de modelo sem Vision devem ser filtradas e não repetidas. O trace deve registrar se uma segunda chamada ao provedor ocorreu, para tornar visível a cobrança duplicada quando a primeira tentativa já foi aceita ou parcialmente processada.

O teste precisa sobreviver a uma auditoria. Um relatório que contém apenas o total gasto não mostra o que aconteceu com a imagem. Um relatório que contém tokens, mas não mostra o cache, não explica a escolha do preço. Um painel que mostra custo, mas omite qualidade, não informa se a economia foi obtida com mais retrabalho.

O model router como middleware da stack de IA ajuda a enquadrar a decisão no lugar certo: a aplicação não deveria carregar uma regra de preço isolada enquanto os dados de rota ficam espalhados em integrações diferentes.

Onde o Nexforce Router entra nessa decisão?

O Nexforce Router entra como gateway e camada de decisão para comparar rotas de modelos, sem prometer integração específica com o identificador deepseek-v4-flash-vision-exp. A conexão honesta é operacional: uma API, seleção por custo, performance, latência e contexto, fallback configurável, limites, rastreabilidade, observabilidade e analytics para a política que o comprador realmente testar. Governança vem antes.

A referência do produto descreve o Router como um gateway LLM com uma API para modelos e inteligência de roteamento. Entre as capacidades documentadas estão seleção por custo, performance, latência e contexto, fallback de modelo, ranking de preço e performance, limites por chave, agente ou projeto, logs, métricas, tracing, dashboards, cache e analytics de economia e performance. O Nexforce Router é a página institucional que sustenta esse mapeamento.

Isso não significa que a Nexforce tenha confirmado, para este artigo, uma integração pronta com o identificador da DeepSeek. A documentação oficial consultada confirma o identificador no endpoint do provedor. O Router é apresentado aqui como camada de governança capaz de receber uma política de decisão, não como prova de compatibilidade já validada com esse modelo experimental.

Na prática, a aplicação pode enviar a requisição para uma camada única, enquanto a política decide se o tráfego deve seguir por uma rota multimodal, por outra rota disponível ou por um fallback. Isso é uma inferência arquitetural, não uma propriedade verificada desta integração. Um teste real do Router precisa validar a preservação do payload multimodal, a normalização dos erros específicos do provedor, o tratamento das imagens e a telemetria de cobrança antes de concluir que a troca de rota funciona como esperado.

Os limites por chave ou projeto ajudam a impedir que um teste experimental consuma o orçamento inteiro. A rastreabilidade preserva a relação entre requisição, tokens, horário e resposta. A observabilidade mostra latência e erro. O analytics organiza custo e desempenho. Nenhuma dessas funções transforma o preço publicado em economia garantida.

Fato confirmado: o produto Nexforce Router documenta essas capacidades de gateway, roteamento, fallback, limites e observabilidade. Inferência operacional: elas são adequadas para estruturar o teste do custo multimodal. Ponto ainda não verificado: a compatibilidade específica com deepseek-v4-flash-vision-exp e o comportamento do modelo dentro de uma rota do Router não foram confirmados pelas fontes oficiais usadas neste artigo; preservação do payload multimodal, normalização de erros, tratamento de imagens e telemetria de cobrança exigem teste de integração.

Perguntas frequentes sobre o DeepSeek V4-Flash-Vision-Exp

O DeepSeek-V4-Flash-Vision-Exp é um modelo experimental com entrada de imagem, e a documentação oficial publica preços distintos para input cache hit, input cache miss e output, em horários de pico e fora do pico. As respostas abaixo mantêm a fronteira entre o que a tabela confirma, o que o comprador precisa medir e o que continua sem verificação. A tabela não é benchmark.

Quanto custa o DeepSeek V4-Flash-Vision-Exp por milhão de tokens?

Fora do pico, a tabela publica US$ 0,007 por milhão de tokens para input cache hit, US$ 0,22 para input cache miss e US$ 0,66 para output. No pico, publica US$ 0,014, US$ 0,44 e US$ 1,32, respectivamente. Esses valores são preços de tabela consultados em 25 de agosto de 2026.

Como a imagem é cobrada?

A documentação oficial informa que as imagens enviadas ao DeepSeek-V4-Flash-Vision-Exp são convertidas em tokens conforme suas dimensões e cobradas como tokens de input junto com o texto. As dimensões permitem estimar a tokenização segundo a documentação, mas o uso registrado na resposta da API é a referência operacional, sem que este artigo nomeie um campo específico como definitivo. Não existe custo universal para qualquer imagem. Registro vence estimativa.

Quais são os horários de pico?

Os horários de pico publicados são 01:00 a 04:00 UTC e 06:00 a 10:00 UTC, de segunda a sexta-feira. Os demais horários são classificados como fora do pico na nota da tabela. O sistema de medição deve registrar UTC, porque o fuso local pode deslocar a chamada para uma faixa diferente da política esperada.

O preço menor justifica colocar o modelo na rota padrão?

Não. O modelo é experimental, e a documentação consultada não confirma recomendação universal, SLA, disponibilidade geral ou benchmark de superioridade. O comprador deve medir qualidade, latência, tokens de imagem, cache, horário, output, falhas e fallback. A rota padrão só faz sentido depois que a tarefa concluída, e não apenas o token, tiver um custo conhecido.

O Nexforce Router já integra esse identificador?

As fontes usadas nesta análise não confirmam uma integração específica do Nexforce Router com deepseek-v4-flash-vision-exp. O Router pode ser conectado à decisão como gateway e camada de roteamento, com seleção, fallback, limites, rastreabilidade e observabilidade documentados no produto. A compatibilidade concreta com o identificador precisa ser verificada antes de qualquer promessa técnica.

Referências e Leitura Complementar

• DeepSeek API Docs, Models & Pricing, documentação oficial de preços consultada em 25 de agosto de 2026.
• DeepSeek API Docs, Your First API Call, documentação oficial que lista o identificador deepseek-v4-flash-vision-exp e aponta para o guia de Vision, consultada em 25 de agosto de 2026.
• DeepSeek API Docs, Vision, guia oficial sobre redimensionamento, tokens de imagem, formatos, limites de requisição e múltiplas imagens, consultado em 25 de agosto de 2026.
• Nexforce Router, página oficial do produto e de suas capacidades de gateway e roteamento.

A decisão de rota começa depois da tabela

O preço publicado abre uma oportunidade de teste, mas não fecha uma decisão de produção. Para o comprador B2B, a pergunta correta é quanto custa concluir uma tarefa multimodal com a qualidade necessária, no horário real, com o cache observado e um fallback capaz de absorver a falha. O Nexforce Router é a camada de governança para medir essa escolha. A rota só deve mudar depois dos dados. O próximo passo é medir.