DeepSeek-V4: contexto de 1 milhão de tokens que agentes conseguem usar de verdade

A DeepSeek lançou o V4, com dois checkpoints MoE (Mixture of Experts) no Hub: DeepSeek-V4-Pro com 1.6T de parâmetros totais e 49B ativos, e DeepSeek-V4-Flash com 284B totais e 13B ativos. Os dois vêm com janela de contexto de 1M tokens.

Os números de benchmark são competitivos, mas não SOTA (state-of-the-art). E não importa. A inovação real é como o V4 foi desenhado pra aguentar contexto longo de forma eficiente, o que faz dele um dos melhores candidatos pra tarefas agênticas.

O problema do KV cache em agentes

Rodar modelo open frontier como agente hoje quebra de formas previsíveis. O modelo trava. Você repromta. O trace estoura o orçamento de contexto, o KV cache enche a GPU, ou as rodadas de tool-call degradam no meio de uma task longa.

Janela de 1M é só capacidade, não performance. Se você consegue usar ou não depende do custo de cada forward pass naquela profundidade. Pra um agente rodando trajetória longa de uso de ferramentas (task do SWE-bench, sessão de browsing multi-step, sessão de terminal com centenas de comandos), cada resultado de tool é anexado ao contexto, e todo token seguinte paga o custo total de atenção contra tudo que veio antes.

Dois números importam: FLOPs de inferência por token e tamanho do KV cache. Os dois crescem com o comprimento da sequência. Em 1M tokens:

• V4-Pro roda com 27% dos FLOPs de inferência do V3.2 e usa 10% da memória de KV cache.
• V4-Flash derruba mais ainda: 10% dos FLOPs e 7% do KV cache.

Comparando contra uma arquitetura consolidada como grouped query attention com 8 heads em bfloat16, o V4 precisa de aproximadamente 2% do tamanho de cache. Isso muda o jogo pra deploy de contexto muito longo.

Atenção híbrida: CSA e HCA

O ganho vem de dividir atenção em dois mecanismos e intercalar entre camadas.

Compressed Sparse Attention (CSA) comprime entradas do KV em 4x ao longo da dimensão de sequência via pooling com softmax-gated e bias posicional aprendido. Um lightning indexer (FP4, dot product multi-head scored via ReLU) seleciona os top-k blocos comprimidos por query. Herda a ideia de seleção esparsa do DeepSeek Sparse Attention do V3.2, mas roda em blocos que já são 4x mais curtos que a sequência original.

Heavily Compressed Attention (HCA) comprime em 128x e abandona a seleção esparsa. Toda query atende densamente a todo bloco comprimido. A sequência comprimida fica curta o suficiente pra atenção densa sair barata.

As camadas alternam entre CSA e HCA. No stack de 61 camadas do V4-Pro: camadas 0 a 1 são HCA, camadas 2 a 60 alternam CSA e HCA, e o bloco MTP no final roda só sliding-window.

Ambos os caminhos usam armazenamento FP8 pra maioria das entradas de KV, e BF16 só pras dimensões RoPE. O lightning indexer do CSA roda em FP4. Essas escolhas de storage se compõem com as razões de compressão pra chegar nos 2% de KV cache.

Na prática, o que isso significa: quem opera inferência de contexto longo em GPU própria finalmente tem um modelo open que não exige comprar mais VRAM pra cada rodada de tool-call.

O que muda pra agentes

Atenção eficiente em contexto longo é necessária mas não suficiente. O paper descreve três escolhas de pós-treino e infra que miram casos agênticos diretamente.

Pensamento intercalado entre tool calls

O V3.2 mantinha traces de reasoning entre rodadas de tool-result, mas jogava fora sempre que chegava mensagem nova do usuário. Pra agente atendendo um único turno, tranquilo. Pra workflow agêntico multi-turno, onde o user manda follow-up depois do agente ter encadeado várias tool calls, o modelo perdia o raciocínio acumulado e precisava reconstruir estado.

O V4 preserva reasoning entre fronteiras de mensagem do usuário quando a conversa tem tool calls. O modelo retém o histórico completo de reasoning em todas as rodadas, incluindo entre turnos do user. Pra uso conversacional sem ferramentas, comportamento antigo é mantido: reasoning é descartado a cada turno.

Schema de tool-call com tokens dedicados

V4 introduz um token especial |DSML| e formato de tool-call baseado em XML. O XML reduz falhas de escaping comparado a tool calls com JSON-em-string, modo de falha comum quando modelo emite conteúdo aninhado com aspas.

O schema separa parâmetros string (passados direto com string="true") de parâmetros estruturados (passados como JSON com string="false"). Tira uma classe inteira de erros de parsing em números e booleanos que formatos JSON de tool-call pegam direto.

DSec: sandbox pra rollouts de RL

O comportamento agêntico foi treinado com RL contra ambientes reais de ferramenta. O DeepSeek Elastic Compute (DSec) é uma plataforma em Rust que expõe quatro substratos de execução atrás de um SDK único em Python: function calls, containers, microVMs (Firecracker) e VMs completas (QEMU). Um único cluster roda centenas de milhares de sandboxes concorrentes.

Três features do DSec importam pra treino de agente:

• Carregamento rápido de imagem via storage 3FS em camadas (rollouts de RL não esperam startup de container).
• Replay de trajetória seguro contra preempção (steps de treino interrompidos retomam sem re-rodar tool calls).
• API uniforme entre substratos (harnesses de treino miram function calls ou VMs completas sem reescrever).

Resultados nos benchmarks de agente

Números de conhecimento e raciocínio são competitivos mas não lideram. Os de agente é onde o V4-Pro-Max se separa do resto.

Dados específicos da Tabela 6 do paper:

• Terminal Bench 2.0: V4-Pro-Max faz 67.9, à frente de GLM-5.1 (63.5) e K2.6 (66.7), atrás de GPT-5.4-xHigh (75.1) e Gemini-3.1-Pro (68.5).
• SWE Verified: 80.6 resolvidos, a menos de um ponto de Opus-4.6-Max (80.8) e Gemini-3.1-Pro (80.6).
• MCPAtlas Public: 73.6, segundo só pro Opus-4.6-Max (73.8).
• Toolathlon: 51.8, à frente de K2.6 (50.0), GLM-5.1 (40.7) e Gemini-3.1-Pro (48.8).

No benchmark interno de R&D coding (30 tasks em PyTorch, CUDA, Rust e C++), V4-Pro-Max pega 67% de pass rate, contra 47% do Sonnet 4.5 e 70% do Opus 4.5. Em uma pesquisa com 85 devs da DeepSeek usando V4-Pro como daily driver, 52% disseram que ele já substitui o modelo primário de coding, e 39% inclinaram pra sim.

No retrieval de contexto longo (Figura 9), MRCR 8-needle fica acima de 0.82 até 256K tokens e segura 0.59 em 1M.

Usando os modelos

Quatro checkpoints no Hub. Os instruct usam FP4 pros pesos dos experts do MoE e FP8 pra todo o resto. Os base são FP8 integral.

• deepseek-ai/DeepSeek-V4-Pro (1.6T / 49B ativos, instruct)
• deepseek-ai/DeepSeek-V4-Flash (284B / 13B ativos, instruct)
• deepseek-ai/DeepSeek-V4-Pro-Base (base)
• deepseek-ai/DeepSeek-V4-Flash-Base (base)

Os dois instruct suportam três modos de reasoning: Non-think (rápido, sem chain of thought), Think High (reasoning explícito em blocos <think>) e Think Max (esforço máximo com system prompt dedicado). Think Max exige janela de contexto de pelo menos 384K tokens. Parâmetros de sampling recomendados: temperature=1.0, top_p=1.0.

V4-Pro nos números de SWE Verified, MCPAtlas e no benchmark interno de R&D coloca ele em paridade com modelos closed frontier em tarefas de agente. A questão em aberto é como as harnesses de ferramenta da comunidade adaptam ao schema |DSML| e se os ganhos do thinking intercalado transferem pra frameworks de agente fora do domínio de treino.