Chamada de ferramentas do DeepSeek V4.1 Flash chega ao vLLM: o que as tags espaçadas quebraram

DeepSeek V4.1 Flash está disponível em geral desde 10 de setembro de 2026 e, durante os primeiros doze dias de sua existência, o modelo teve uma lacuna sobre a qual ninguém escreveu: conseguia raciocinar, conseguia ver imagens, conseguia manter um milhão de tokens de contexto, mas não conseguia chamar uma ferramenta de forma confiável pela pilha de serving aberta mais amplamente utilizada. Essa lacuna agora está fechada no vLLM — não com uma flag de configuração, mas com uma reescrita do parser. Dois pull requests carregam o trabalho, e o motivo pelo qual eram necessários é a parte interessante.

A versão curta: o DeepSeek V4.1 Flash emite suas chamadas de ferramenta em um formato de tag que o detector existente do DeepSeek V4 não reconhece, então, em uma implantação padrão do vLLM, a marcação da chamada de ferramenta chega como texto comum em vez de saída estruturada. Nada dá erro. O modelo parece simplesmente ter se recusado a chamar a função. Se você vem testando loops de agente com um DeepSeek V4.1 Flash auto-hospedado e concluindo que o modelo é ruim com ferramentas, é muito provavelmente isso que você estava vendo.

O que realmente mudou na stack de serving

A análise de chamadas de ferramentas do vLLM para modelos DeepSeek existe em dois lugares há algum tempo: um frontend Python e um frontend Rust mais recente, com o trabalho em nível de gramática delegado ao projeto XGrammar. Trazer o suporte ao V4.1 Flash significou portar a conversão C++ deepseek_xml dentro do XGrammar para o construtor Rust e, em seguida, integrar a codificação do próprio modelo ao diretório de tokenizer do vLLM.

• O trabalho de frontend em Rust é o PR #56235, que faz a portabilidade da conversão de XGrammar C++ deepseek_xml para o builder Rust. Ele inclui 18 novos testes especificamente para V4.1, e todas as suítes existentes — 472 testes em vllm-parser e 326 em vllm-chat — permanecem verdes.

• O trabalho de frontend em Python é o PR #56408, que ainda é um rascunho. Ele depende de uma alteração upstream do XGrammar (mlc-ai/xgrammar#885) ser integrada primeiro e relata 110 testes passando com essa dependência aplicada.

• O novo módulo de codificação é vllm/tokenizers/deepseek_v41_encoding.py — um arquivo separado, em vez de um ramo dentro da codificação V4, o que indica que a gramática das tags difere genuinamente, em vez de apenas ser estendida.

• A invocação é explícita: --tool-parser deepseek_v41. Não há fallback de detecção automática que faça a coisa certa silenciosamente.

As tags espaçadas contam toda a história.

O motivo pelo qual existe um novo analisador em vez de uma expressão regular ampliada é o espaço em branco. O DeepSeek V4.1 Flash escreve suas tags de ferramenta DSML com espaços entre os tokens. O padrão do detector V4 espera a forma sem espaços, então ele não consegue corresponder, e uma correspondência malsucedida em um analisador de chamadas de ferramenta é silenciosa por projeto — o texto é repassado como conteúdo em vez de gerar um erro.

Esse modo de falha vale a pena ser analisado com calma, porque é o tipo mais caro. Um parser que lança uma exceção é corrigido em uma tarde. Um parser que retorna uma string bem formada contendo marcação que quem o chamou nunca pediu parece um problema de qualidade do modelo, e as equipes reagem a ele como reagiriam a um problema de qualidade do modelo: tentam prompts diferentes, adicionam exemplos, trocam de modelo. Doze dias é tempo suficiente para que muita coisa disso tenha acontecido nos bastidores.

Isso também significa que a correção não é um botão de ajuste. Você não pode resolver na base de prompt um detector que não corresponde ao formato de saída do seu modelo, e não pode corrigi-lo no cliente por pós-processamento, porque quando o texto chega ao seu cliente a estrutura já se perdeu. Isso tem que acontecer na stack de serving, que é exatamente onde ela está agora.

Por que isso importa mais para o V4.1 Flash do que importava para o V4

A chamada de ferramentas não é um mero extra para este modelo em particular. O DeepSeek V4.1 Flash é um modelo de mistura de especialistas com 552 bilhões de parâmetros, com 8 bilhões de parâmetros ativos na entrada e 16 bilhões ativos na saída, uma janela de contexto de 1M tokens e uma saída máxima de 384K tokens. A divisão de ativação é reveladora: o modelo foi construído para receber uma entrada grande — um repositório, um conjunto de documentos, um longo rastro de ferramentas — e emitir uma resposta longa e estruturada. Esse é o formato de um agente, não o formato de um chat.

O restante da especificação de lançamento aponta na mesma direção. Pesos licenciados sob MIT, 890 bytes de cache KV por token, 45 trilhões de tokens de pré-treinamento, visão nativa. O número do cache KV é o que importa operacionalmente em contexto de 1M: é o que torna viável manter residente uma longa transcrição de agente, e é por isso que o modelo é plausível como o trabalhador barato em um loop supervisionado por um modelo mais caro.

O que faz da lacuna de doze dias em tool-calling um custo real, e não uma nota de rodapé. Um modelo cujo argumento econômico se baseia em ser o executor de alto volume em um pipeline de agentes vale muito pouco se o pipeline não conseguir extrair dele uma chamada estruturada.

O que ainda está em aberto?

O ponto de situação honesto, em 22 de setembro de 2026:

• O caminho do frontend em Rust (PR #56235) é o que tem cobertura de testes completa tanto nos novos casos da V4.1 quanto nas suítes pré-existentes. Se você estiver em uma build do vLLM que o inclui, o parser está disponível para você hoje.

• O caminho do frontend Python (PR #56408) é um rascunho e tem uma dependência externa. Se você estiver fixado em uma compilação anterior à alteração do XGrammar, o frontend Python ainda não fornecerá o parsing de ferramentas V4.1.

• Como a invocação é explícita, uma implantação que atualize o vLLM mas não altere suas flags de inicialização manterá o comportamento antigo. O fato de o parser existir e o parser ser usado são duas coisas diferentes.

• Ainda não há evidências públicas de um benchmark independente de chamada de ferramentas executado contra o V4.1 Flash com o novo parser implementado. O que sabemos é que a infraestrutura funciona e os testes passam. Se a qualidade de chamada de ferramentas do modelo é boa é uma questão separada que o merge não responde.

Esse último ponto é o que devemos reter. Uma correção no parser leva o modelo de "não pode ser avaliado" para "pode ser avaliado". É um pré-requisito para um veredito, não o veredito.

Se você não quiser executar a stack de serving por conta própria

Há um caminho mais curto. O DeepSeek V4.1 Flash está disponível através do endpoint do OrcaRouter para ele, o que significa que o comportamento de chamada de ferramentas chega como uma chamada de API normal, e não como um problema de build — sem versão do XGrammar para combinar, sem frontend para escolher, sem flag de lançamento para lembrar. A razão pela qual isso importa aqui especificamente é que a correção chegou em dois lugares com maturidades diferentes, e um endpoint hospedado reduz essa decisão a nada.

A mesma chave também alcança o restante dos modelos com os quais você estaria comparando, o que é a propriedade útil quando a pergunta não é "este parser está correto", mas "este modelo é bom o suficiente para o meu loop". Você pode colocar o DeepSeek V4.1 Flash atrás de uma regra de roteamento como o executor barato e fazer failover para um modelo mais forte quando a chamada falhar, sem um segundo contrato ou um segundo SDK. Testar um modelo cujo suporte a chamadas de ferramentas tem duas semanas de existência é exatamente a situação para a qual o failover automático existe.

O que assistir em seguida

Três coisas transformariam isto de uma história de encanamento em um veredito:

• PR #56408 saindo do rascunho, o que tornaria real o caminho do frontend Python e acabaria com a situação de suporte em dois níveis.

• Uma avaliação independente de agente ou de chamada de ferramentas executada contra o V4.1 Flash numa pilha de serving fixa. O modelo foi lançado há doze dias e o parser está utilizável há menos tempo do que isso, por isso qualquer pontuação de chamada de ferramentas que veja citada para ele neste momento merece ser questionada — a configuração importa tanto quanto o modelo.

• Se outros stacks de serving seguem. O vLLM é o que tem PRs públicos; o problema da tag com espaços não é específico do vLLM, então qualquer stack que tenha adotado o detector V4 sem rededuzi-lo a partir da saída do V4.1 carrega a mesma falha silenciosa.

Até que o primeiro desses chegue, o resumo preciso é restrito e vale a pena dizer com clareza: o DeepSeek V4.1 Flash é um modelo GA com pesos MIT, um contexto de 1M e um teto de saída de 384K, e a chamada de ferramentas dele agora funciona no caminho Rust do vLLM com uma flag explícita de parser. Isso é um passo real e ainda não é um resultado.