As especificações, lado a lado
Esses dois modelos saíram com menos de três semanas de diferença entre si. Ambos de laboratórios chineses, ambos com pesos publicados, e ambos com uma janela de contexto de um milhão de tokens. É mais ou menos aí que a semelhança termina. Para contexto sobre cada um separadamente, tem minha análise do Kimi K3, e também um panorama do DeepSeek V3.2, a geração da qual o Flash veio.
| DeepSeek V4 Flash | Kimi K3 | |
|---|---|---|
| Lançamento | build 0731, 31 de julho de 2026 | 16 de julho de 2026 |
| Entrada, cache miss | $0.14 / 1M | $3.00 / 1M |
| Entrada, cache hit | $0.0028 / 1M | $0.30 / 1M |
| Saída | $0.28 / 1M | $15.00 / 1M |
| Janela de contexto | 1M | 1.048.576 |
| Saída máxima | 384K | 131.072 por padrão, ajustável para 1.048.576 |
| Parâmetros | 284B no total, 13B ativos | 2,8T no total, 104B ativos |
| Modalidades de entrada | Apenas texto | Texto, imagem, vídeo |
| Controle de raciocínio | Sem pensar ou pensando, pensando é o padrão | low / high / max, nunca desligável |
| Licença | MIT | Licença Kimi K3, com cláusula comercial |
| Limite de concorrência | 2.500 | Limitado pelo nível da conta, não publicado |
| AA Intelligence Index | 50 | 57 |
| Custo por tarefa | $0.03 | $0.86 |
| Velocidade de saída mediana | 113 tok/s | 35 tok/s |
| Tempo total de resposta | 23,36s | 73,88s |
| Alucinação AA-Omniscience | 84% | 51% |
Uma linha ali merece destaque antes de eu continuar. A taxa de cache hit da DeepSeek fica em $0.0028 por milhão, cem vezes mais barata que o já descontado $0.30 da Kimi. O cache é ativado por padrão sem que você precise mudar nada no código. A DeepSeek deixa claro, porém, que é best-effort, e as entradas expiram "geralmente em algumas horas a alguns dias", então é um desconto real que você não deveria tratar como algo constante.
Preço por token é o número errado
Eis a armadilha de uma comparação como essa. A tabela de preços diz que o Flash é 54 vezes mais barato na saída. A tabela de preços não é a sua fatura.
A Artificial Analysis publica uma métrica muito mais próxima da realidade, o custo por tarefa, que é a média ponderada do que custa de fato terminar um trabalho no índice deles. Nessa medida, o Flash fica em $0.03 e o K3 em $0.86. Ainda uma diferença enorme, mas de 29x e não 54x, e o motivo é que o Flash consome mais tokens para chegar a qualquer lugar. Ele produziu 210M de tokens de saída ao rodar o índice completo, contra 130M do K3, com ambos medidos sobre uma mediana de classe de 100M. A AA chama o Flash de "muito verboso". Chama o K3 de verboso também. Os dois são falantes, o Flash só que mais.
Rodar o índice inteiro custou $72,02 no Flash e $2.437,41 no K3. As mesmas nove avaliações, o mesmo trabalho. Se você tem o hábito de pensar no gasto com IA como um custo de serviço mensal em vez de uma tarifa por token, essa proporção é a que vale a pena guardar.
Tokens de raciocínio são o que abre a diferença entre o preço de tabela e a fatura, e essa é a parte que a maioria das comparações de preço pula. Simon Willison rodou seu prompt padrão do pelicano no K3 e depois publicou o recibo:
"95 input, 16,658 output = 25 cents! [...] (13,241 of those were reasoning tokens.) I think that's the most expensive pelican I've rendered through a Chinese model so far."
Noventa e cinco tokens de entrada, vinte e cinco centavos de saída, e 79% do que ele pagou foi por um raciocínio que ele nunca leu.
Os dois modelos cobram o raciocínio na tarifa de saída, e nos dois o pensamento vem ativado por padrão, então isso se aplica igualmente. Só que custa 54 vezes mais por token em um deles.
Vale sinalizar aqui uma complicação honesta em vez de fingir que a medição está resolvida. Um desenvolvedor que rodou prompts idênticos nos dois encontrou a comparação de verbosidade indo na direção oposta:
"It says there that "Kimi K3 (Max)" would think/reason less than than deepseek-v4-flash, and a whole bunch of other models [...] but in my experience, K3 is probably the model that thinks/reasons the longest of all of these."
As duas coisas podem ser verdadeiras ao mesmo tempo. O índice da AA é uma mistura particular de tarefas de avaliação curtas, e a sua carga de trabalho não é essa mistura. O que é a lição real aqui: rode seus próprios prompts nos dois e conte os tokens, já que os números de verbosidade publicados não vão se transferir de forma limpa para o seu caso de uso.
No argumento do cache, porém, é aqui que o Flash fica difícil de superar:
"I don't understand how DeepSeek can be so cheap with their cache pricing - ~0.003 usd / 1Mtok. 100x less than Kimi K3, or similar numbers against pretty much any other decently sized model to my knowledge. I've been using it whenever possible as even longer agent sessions cost few cents."
A opção intermediária que não é
Essa é a descoberta que eu gostaria de ter se fosse eu quem estivesse comprando, e ela não está na página de nenhum dos dois fornecedores.
A Kimi lançou os níveis de raciocínio low e high algum tempo depois do lançamento, então o K3 não é mais apenas de esforço máximo. O movimento óbvio é recorrer ao low e manter a maior parte da qualidade do K3 por uma fração da conta. A Artificial Analysis mediu essa configuração separadamente, e ela não funciona.
O Kimi K3 no low pontua 47 no Intelligence Index, a $0.24 por tarefa. O DeepSeek V4 Flash pontua 50 a $0.03. O K3 reduzido custa oito vezes mais que o Flash e pontua três pontos a menos. Nem sequer é mais rápido, 34 tokens por segundo contra 35 do K3-max, com um tempo total de resposta um pouco pior.
Também não há alívio no preço, porque os níveis são cobrados na mesma tarifa. O guia rápido do Kimi K3 é direto sobre o que aquele controle faz, ao responder se dá para desligar o raciocínio: "Não dá, o K3 sempre pensa. Se o raciocínio demorar demais, defina reasoning_effort como low." É um controle de latência, não um nível de custo. A economia é apenas o quanto de tokens de raciocínio você evitar.
Então a escolha é binária. Pagar $0.03 ou pagar $0.86. Veja como isso fica em volume:
O que cada um cobra no seu volume
Custo por tarefa da Artificial Analysis, multiplicado. Escolha um número de tarefas mensais.
Uma "tarefa" aqui é uma tarefa do Artificial Analysis Intelligence Index, que é uma aproximação da sua carga de trabalho, não uma correspondência exata dela. Use isso para comparar as três opções entre si, não para prever uma fatura.
Onde cada um realmente vence
Em inteligência bruta medida, o K3 está à frente, e no ranking não é por pouco. 57 contra 50, sétima posição no geral, e o modelo de pesos abertos mais bem classificado entre os 99 que a Artificial Analysis acompanha. O Flash fica em terceiro entre os de pesos abertos, atrás do K3 e do GLM-5.2.
Os próprios gráficos de lançamento da Moonshot contam uma história consistente, e valem a pena ser lidos com uma ressalva em mente.
A ressalva é que a DeepSeek não aparece naquele gráfico de jeito nenhum. A Moonshot comparou o K3 com Fable 5, GPT-5.6 Sol, Opus 4.8, GLM-5.2 e GPT-5.5, deixando de fora o concorrente sério de pesos abertos mais barato. A DeepSeek retribui o favor, o K3 também não aparece nos gráficos dela. É o estado normal das coisas com um benchmark de fornecedor, e é por isso que o índice independente faz a maior parte do trabalho neste artigo.
Velocidade e vazão é onde o Flash vence de forma clara. Ele roda a 113 tokens por segundo contra 35 do K3, primeiro trecho em 1,33 segundos contra 2,78, resposta completa em 23,36 segundos contra 73,88. Ele também tem um limite de concorrência de 2.500. Para qualquer coisa interativa, essa diferença deixa de ser uma nota de rodapé e vira o produto em si:
"Faster iterations are way better for me, I hate waiting for 5-10 minutes on small changes. I tried to use recent versions of Kimi and GLM, but they use too much thinking for no reason and are pretty slow because of it."
E a lentidão se mantém mesmo para quem paga o nível de consumidor mais alto:
"I'm still considering pulling the trigger on the annual subscription of Kimi for K3 but it's sometimes slower than I'd like (at least when compared to Anthropic) even on their Vivace plan"
Do lado do Flash, o relato prático mais útil que encontrei rodou dezesseis tarefas reais de trabalho ao longo de quatro dias contra um modelo bem mais caro. O resultado deveria moderar qualquer suposição de que barato significa fraco:
"I benched DS4 flash and Pro vs opus 4.8 xhigh on 16 work-related tasks a month ago across 4 days. Opus 4.8 came out as a winner by 1 task only [...] But flash performed as well or better (as in being more thorough) in 13 out if 16."
Uma diferença funcional clara para anotar antes de seguir em frente. O K3 aceita entrada de imagem e vídeo, enquanto o Flash é apenas texto, sem entrada de imagem documentada. Se sua carga de trabalho envolve capturas de tela, isso decide tudo sozinho, porque a entrada multimodal não é algo que se adicione depois. Também vale saber, o K3 também não aceita URL de imagem pública. Base64 ou um id de arquivo enviado, mais nada.
Precisão é a diferença que importa
Tudo acima é discutível dependendo da carga de trabalho que você tem. Esta parte, menos.
O AA-Omniscience mede se um modelo sabe o que não sabe. Recompensa uma resposta correta, penaliza as respostas erradas dadas com confiança, e não penaliza dizer "não sei". Nesse índice, o Flash pontua −16 e o K3 pontua 18. Traduzido em taxa de alucinação, o Flash inventa uma resposta em 84% das vezes em que está além do seu alcance. O K3 faz isso em 51% das vezes.
Nenhum dos dois números é bom. Um é muito pior. E alucinação nesse tipo de taxa não é uma mania que se resolve com um bom prompt, é uma propriedade do modelo de fundação que você precisa projetar em torno dela ou vai ser mordido por ela.
Quem usa o Flash relata mais ou menos exatamente o que você previria a partir de um número desses:
"DeepSeek V4 hallucinates like crazy and often forgets explicitly mentioned parts of the context. I guess compressing tokens and cherry-picking attention comes at a cost."
A versão mais justa veio de um dos usuários mais intensos do modelo, que não está tanto defendendo ele quanto descrevendo a estrutura que construiu para sobreviver a ele:
"It hallucinates plenty, about the same as Codex models and all other LLMs! I review all code it writes, thoroughly, check the test coverage, write tests myself, have other models/chats cross-check the work with a review skill"
Essa é a leitura honesta. O Flash funciona bem quando um humano competente revisa toda saída, e um fluxo de trabalho de código já tem um compilador, uma bateria de testes e uma revisão de código, tudo isso se interpondo entre o modelo e o que realmente importa. O modelo barato funciona porque a estrutura de apoio o pega. Tire essa estrutura e você está confiando no próprio julgamento do modelo base, que é exatamente o que um número de 84% está dizendo para você não fazer. É também o argumento a favor de RAG em vez de um LLM puro em qualquer cenário onde a resposta precisa estar certa e não apenas parecer plausível.
É aqui que eu apontaria a coisa que continuo encontrando neste trabalho. Eu construo agentes de IA na eesel, e já faz anos que colocamos eles em filas de suporte reais. O modo de falha nunca é o modelo ser burro. É o modelo estar confiante. Um comprador colocou isso melhor do que eu conseguiria, numa ligação sobre encaminhar tickets para a IA:
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Esse era um líder de CX numa marca de suplementos DTC, rodando cerca de 7.000 tickets por mês no Gorgias e no Shopify. Não fechamos aquele negócio, e a objeção acima é o motivo. Repare que ele nunca perguntou qual era a pontuação do modelo. Ele perguntou se o modelo saberia se manter fora do caminho quando não soubesse. Uma taxa de alucinação de ranking não responde a essa pergunta, e nenhuma página de fornecedor vai responder também.
Para sermos justos, também já vimos nossos próprios agentes fazerem essa coisa de errar com confiança. O pior padrão que já registramos em produção foi um agente narrando "executando buscas no Zendesk" por cerca de dez turnos sem nunca de fato chamar a API. Nada mata a confiança em um colega de equipe mais rápido do que ele mentir sobre o que fez, por isso agora simulamos cada implantação contra o histórico de tickets real de um cliente antes que ela toque numa fila em produção.
"Pesos abertos" significa duas coisas bem diferentes aqui
Ambos os modelos publicam seus pesos. Mas a expressão faz um trabalho bem diferente em cada caso.
O Flash tem 284B no total com 13B ativos, cerca de 167GB de pesos, sob uma simples licença MIT, e existem 57 quantizações feitas pela comunidade. Isso o coloca em um território diferente da maioria dos agentes open source desse nível de qualidade, e ele é pequeno o suficiente para que o fine-tuning se torne uma opção real em vez de um exercício mental.
Os pesos do K3 foram publicados no Hugging Face em 27 de julho, exatamente na data que a Moonshot havia prometido, e o índice safetensors confirma 2.779.931.837.184 parâmetros, independente do comunicado de imprensa. São também 1.561 GB distribuídos em 96 shards, com 104B de parâmetros ativos.
A pessoa que calculou essa dimensão adicionou a parte que importa:
"Most importantly, we now know that the model has 104B active parameters, which is quite a lot and will make it difficult to self-host efficiently."
A linha prática entre esses dois foi traçada com bastante clareza no fórum de lançamento do V4 Flash:
"And, at least flash can be ran "at home" with <10k in hardware, which isn't really possible / feasible with glm/k3 larger models."
E a conta de autohospedar o K3 para economizar dinheiro não sobrevive ao contato com a planilha:
"At 5 tok/second, you're talking about around $195 worth of output tokens per month. There is no way I can run a usable K3 model for $195 a month of capex, opex, or any-kind-of-ex."
As licenças também diferem, e essa aqui tem consequências reais. O Flash é MIT, ponto final. O K3 é distribuído sob uma Licença Kimi K3 personalizada com duas cláusulas adicionais. Operadores de serviço gerenciado com mais de $20M em receita ao longo de doze meses precisam de um acordo separado, e produtos com mais de 100M de usuários mensais ou $20M de receita mensal têm que exibir "Kimi K3" na interface. A maioria dos leitores nunca vai esbarrar em nenhuma das duas. Mas se você estiver construindo um produto em cima, leia a licença antes de presumir uma liberdade estilo MIT, e considere isso em qualquer decisão de construir ou comprar que você esteja tomando.
O que cada fornecedor faz com o que você envia
Se o texto que você está enviando é seu, pule esta parte. Se é texto dos seus clientes, esta é a seção que decide tudo, e os dois fornecedores estão em posições bem diferentes.
A Moonshot publica uma posição, e ela é permissiva por padrão. Seus termos de serviço, atualizados pela última vez em 27 de maio de 2026, dizem que um cliente que queira limites sobre o uso para treinamento "pode entrar em contato com a Moonshot AI para discutir acordos empresariais disponíveis ou contratos escritos separados", e depois isto: "Salvo acordo expresso por escrito em contrário, o Conteúdo do Cliente pode ser usado para os fins acima mencionados." Claro o suficiente, e a saída é um contrato que você mesmo precisa negociar. Os dados ficam em Singapura.
A DeepSeek é o caso mais interessante, já que publica um acordo separado para a API paga e esse acordo não diz absolutamente nada. Os termos da Open Platform, em vigor desde 29 de abril de 2026, trazem uma seção "Inputs and Outputs" que vai até o §4.2 e para por aí. Os Termos de Uso para consumidores têm uma cláusula de treinamento no §4.3 da mesma seção numerada, e o documento da API simplesmente a omite. Essa cláusula para consumidores é explícita ao dizer que a DeepSeek "pode, em medida mínima, usar os Inputs e Outputs para fornecer, manter, operar, desenvolver ou melhorar os Serviços", com uma opção de exclusão chamada "Melhorar o modelo para todos".
Então a afirmação precisa sobre a API da DeepSeek é que ela fica em silêncio, não que ela é segura. Os termos da API se descrevem como um acordo específico sob os Termos de Uso gerais, e um termo específico prevalece apenas onde há conflito. Silêncio não é conflito. Nenhum dos dois documentos publica uma opção de exclusão para desenvolvedores, um acordo de tratamento de dados, ou uma opção de retenção zero, e os dados armazenados ficam na República Popular da China sob a lei da RPC.
Na prática, isso significa que nenhum dos dois é uma solução própria pronta para uso com dados regulados ou que identifiquem clientes sem que você tenha antes uma conversa com um vendedor, o que para duas APIs self-service é uma fricção real. É o mesmo tipo de problema que equipes enfrentaram com a mudança na política de IA do Slack, e se você está sujeito a SOC 2 ou GDPR, é a primeira coisa que o seu revisor vai perguntar. Passar por um provedor que publica termos de retenção zero é o contorno usual, e isso custa mais do que as tabelas de preços acima.
Então, qual você deveria escolher?
Eu enquadraria essa decisão em torno de uma única pergunta, e não é orçamento.
Escolha o DeepSeek V4 Flash quando um humano ou uma máquina verifica a saída antes que ela conte de verdade. Código com testes e revisão, classificação em lote, redação em massa, ferramentas internas, qualquer coisa que você possa reexecutar barato quando sair errada. A $0.03 por tarefa com uma taxa de cache hit de $0.0028, ele é quase de graça, em volumes onde o K3 vira uma linha de custo que alguém questiona. É também o modelo mais rápido, por um fator de três, o que importa mais do que as pessoas esperam em trabalho interativo. Essa é também a escolha quando autohospedar é uma exigência real e não apenas uma ideia legal.
Escolha o Kimi K3 em esforço máximo quando a saída é o entregável e ninguém a verifica linha por linha. Execuções de agentes de longo prazo, síntese de pesquisa, situações em que errar sai caro e você não vai perceber de qualquer jeito. Uma taxa de alucinação de 51% ainda não é um número sobre o qual eu construiria fluxos de trabalho sem supervisão, mas é uma categoria de risco diferente de 84%. Também é o único dos dois que lê imagens.
Evite o Kimi K3 em esforço low. Ele custa oito vezes mais que o Flash e pontua mais baixo. Essa opção existe para encurtar a sua espera, não a sua fatura. Se o K3-max está fora do orçamento, a resposta é um modelo diferente, e não um K3 mais silencioso, e o apanhado de alternativas ao Kimi K3 é o lugar para começar.
Uma última coisa vale a pena dizer, porque "laboratório chinês" e "barato" viraram praticamente a mesma palavra em boa parte da cobertura, e para o K3 isso não é verdade. Seu $0.86 por tarefa fica a um passo da fronteira ocidental, e alguém fez essa conta no fórum de lançamento:
"According to artificialanalysis, cost per task is $0.94, which is almost the same as $1.04 of gpt 5.6 sol max [...] The model certainly sounds extremely impressive for something not from openai/antrophic, but the price makes it a mediocre product."
O número do K3 se estabilizou desde então em $0.86, então a diferença é um pouco maior do que ele tinha calculado, mas a essência do argumento dele ainda se sustenta. O Claude Sonnet 5 está exatamente na mesma tabela de $3/$15, e o GPT-5.6 Sol está na mesma vizinhança por tarefa. A ponta barata desse mercado é o Flash e seus semelhantes. Não os carros-chefe de 2,8T.
Para o resto do campo, minha comparação de Qwen 3.8 Max cobre o terceiro laboratório dessa corrida, enquanto o artigo sobre o V4 Pro explica por que o nível barato da DeepSeek está atualmente superando o caro.
Colocando qualquer um dos dois na frente de um cliente
Tudo acima é uma decisão de desenvolvedor. Mas se você chegou aqui se perguntando se algum dos dois consegue responder tickets de suporte, a resposta honesta é que o modelo é a parte menos importante desse sistema.
Digo isso como alguém que constrói os agentes de IA na eesel. Um modelo puro com taxa de alucinação de 84% e um modelo puro com 51% falham da mesma forma numa fila de suporte: eles respondem coisas que não deveriam ter respondido. O que corrige isso não é um modelo base melhor. É fazer grounding de cada resposta no seu conhecimento verificado, colocar uma trava por score de confiança para que a coisa fique quieta abaixo do limite, e saber o que vai acontecer antes de acontecer.
Essa é a diferença entre um agente de suporte com IA e uma caixa de chat ligada a uma chave de API. É também boa parte do motivo pelo qual construir isso você mesmo demora mais do que qualquer um orçamenta.
Essa última parte vale a pena tomar emprestada quer você use a gente ou não. A eesel roda simulações contra os seus tickets passados reais antes de qualquer coisa ir ao ar, então o que você vê é a precisão real sobre os seus próprios dados, e não a de um ranking, e você só implanta depois que ela ultrapassa o seu limite. Encaminhar uma fatia primeiro também funciona. Lide com 1.000 tickets por mês, envie 200 deles para a IA, você paga por 200. A cobrança é de 40 centavos por ticket resolvido, não há taxas por assento, e você nunca é cobrado pelos tickets que os seus humanos atendem. $50 de uso grátis para começar, e sem necessidade de cartão de crédito.
Ela se conecta ao Zendesk e a outras centrais de atendimento, e lê de onde quer que suas respostas já estejam, seja no Confluence, num espaço do Notion, ou simplesmente na sua central de ajuda pública.
Escolha o modelo que preferir por baixo dos panos. Só não deixe uma pontuação de benchmark ser o motivo pelo qual você confia nele com um cliente.
Perguntas frequentes
DeepSeek V4 Flash ou Kimi K3, qual é mais barato?
O Kimi K3 é melhor que o DeepSeek V4 Flash?
Posso rodar o DeepSeek V4 Flash ou o Kimi K3 localmente?
Devo usar o DeepSeek V4 Flash para atendimento ao cliente?
Qual é o preço da API do Kimi K3 para uma equipe pequena?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
