Pesquisadores da ByteDance encontram ponto fraco na economia de memória da DeepSeek

O artigo, publicado no fim de setembro de 2026, questiona um dos principais pilares de engenharia da DeepSeek. O trabalho foi liderado por pesquisadores da ByteDance. Entre os coautores há cientistas de Princeton, Stanford e da Universidade da Califórnia em Berkeley. Segundo o SCMP, eles descreveram uma possível falha na tecnologia de economia de memória que sustenta os modelos do laboratório chinês. Essa tecnologia ajudou a DeepSeek a reduzir a distância para OpenAI e Anthropic gastando bem menos. A conclusão dos autores: a economia pode ser paga com respostas menos precisas.

O que se sabe sobre o trabalho

O resumo público ainda é curto, e isso precisa ser levado em conta. No trecho disponível da fonte, não aparece o nome do mecanismo específico, nem percentuais de perda de qualidade, nem a lista de benchmarks. Também não há dados sobre em quais versões dos modelos da DeepSeek os testes foram feitos. Diz-se apenas que a pesquisa identificou uma fragilidade na abordagem de economia de memória e que essa fragilidade pode reduzir a precisão.

A própria composição dos autores diz muito. A ByteDance desenvolve seus próprios modelos grandes e paga pela própria inferência, então sabe quanto custa cada gigabyte de cache. Os coautores de três das principais universidades americanas dão peso acadêmico ao trabalho. Não se trata de um post no blog de um concorrente, mas de um preprint assinado por uma ampla coalizão. É provável que ele seja dissecado e que tentem reproduzir seus resultados.

Por que isso incomoda a DeepSeek

Para a DeepSeek, a economia de memória não é uma otimização pontual, e sim a base do seu modelo econômico. A memória que o modelo mantém durante a geração, principalmente o cache de chaves e valores da atenção, determina quantas requisições um único acelerador aguenta e que tamanho de contexto ele consegue sustentar. Quanto mais compacto o cache, mais barato o token. Para um laboratório que trabalha com acesso limitado aos chips de ponta e compete por preço, isso é crítico.

Para contextualizar: na publicação sobre o DeepSeek-V2, o laboratório declarou uma redução de 93,3% no KV-cache graças ao mecanismo Multi-head Latent Attention. O DeepSeek-V3 tem 671 bilhões de parâmetros, dos quais 37 bilhões ativos por token, e foi treinado em cerca de 2,788 milhões de horas de GPU em H800. No texto disponível, a ligação do novo artigo com esse mecanismo específico não é confirmada; esse é um contexto nosso, não uma citação da pesquisa. Mas ele mostra a dimensão do que está em jogo. Se a compressão de memória derruba a precisão de forma sistemática, a conta barata da DeepSeek precisa de ajuste.

Fatos principais

• Autores: equipe da ByteDance, com coautores de Princeton, Stanford e UC Berkeley.
• Publicação: fim de setembro de 2026.
• Alvo da crítica: a tecnologia de economia de memória nos modelos da DeepSeek.
• Risco apontado: queda na precisão do modelo.
• As métricas de degradação e a lista de modelos testados não aparecem no trecho disponível da fonte.
• Contexto: o V2 declarou redução de 93,3% no tamanho do KV-cache; o V3 tem 671 bilhões de parâmetros, com 37 bilhões ativos.

O que ainda falta

A principal pergunta é onde exatamente a degradação aparece. A compressão de memória costuma prejudicar tarefas que exigem extrair um detalhe preciso de um contexto longo. É o caso de buscar um fato em um documento grande, trabalhar com um repositório de código e fazer raciocínios em várias etapas que voltam a tokens iniciais. Benchmarks médios podem não mostrar isso. Se os autores encontraram justamente um cenário desse tipo, o problema é mais sério do que uma queda de alguns pontos em um ranking geral.

A segunda pergunta diz respeito à resposta da DeepSeek. O laboratório pode demonstrar que o efeito só aparece em certas configurações, que ele é corrigido com ajuste fino ou que as versões mais novas já o contornaram. Enquanto não houver resposta, é prematuro avaliar a dimensão do problema.

Como lidar com isso

Equipes que já usam modelos da DeepSeek em produção não precisam migrar às pressas para outra stack. Vale, porém, validar com os próprios dados.

• Rode seus cenários longos: extração de fatos de documentos grandes, análise de código, cadeias de raciocínio. Compare com uma referência, por exemplo outro modelo, e registre as divergências.
• Acompanhe o preprint e as replicações. A confirmação independente importa mais que a primeira publicação, sobretudo quando o autor trabalha em uma empresa concorrente.
• Calcule o custo ajustado pela qualidade. Se o token barato exige novas requisições ou revisão manual, o ganho de preço diminui.
• Em tarefas críticas, mantenha um modelo reserva e uma comparação automática de respostas.

Para o mercado em geral, a história mostra algo mais amplo. A eficiência obtida por um truque de arquitetura deve ser verificada com o mesmo rigor que a obtida por escala. A primeira auditoria séria da abordagem da DeepSeek veio de colegas de setor e, muito provavelmente, não será a última.