L'appel d'outils de DeepSeek V4.1 Flash arrive dans vLLM : ce que les balises espacées ont cassé

DeepSeek V4.1 Flash est en disponibilité générale depuis le 10 septembre 2026, et pendant les douze premiers jours de son existence, le modèle présentait une lacune dont personne n'a parlé : il savait raisonner, il pouvait voir des images, il pouvait contenir un million de jetons de contexte, et il ne pouvait pas appeler un outil de manière fiable à travers la pile de service ouverte la plus largement utilisée. Cette lacune est désormais comblée dans vLLM — non pas au moyen d'un indicateur de configuration, mais par une réécriture du parseur. Deux pull requests portent le travail, et la raison pour laquelle elles étaient nécessaires est la partie intéressante.

En bref : DeepSeek V4.1 Flash émet ses appels d’outils dans un format de balise que le détecteur DeepSeek V4 existant ne reconnaît pas ; ainsi, sur un déploiement vLLM standard, le balisage d’appel d’outil arrive sous forme de texte ordinaire au lieu d’une sortie structurée. Aucune erreur ne se produit. Le modèle donne l’impression d’avoir simplement refusé d’appeler la fonction. Si vous testiez des boucles d’agents avec un DeepSeek V4.1 Flash auto-hébergé et concluiez que le modèle est mauvais avec les outils, c’est très probablement ce que vous observiez.

Qu'est-ce qui a réellement changé dans la pile de service

L'analyse des appels d'outils de vLLM pour les modèles DeepSeek a longtemps été répartie sur deux endroits : un frontend Python et un frontend Rust plus récent, le travail au niveau de la grammaire étant délégué au projet XGrammar. Assurer la prise en charge de V4.1 Flash impliquait de porter la conversion C++ deepseek_xml au sein de XGrammar vers le constructeur Rust, puis de raccorder l'encodage propre du modèle au répertoire de tokenizer de vLLM.

• Le travail sur le frontend Rust est la PR #56235, qui transpose la conversion XGrammar C++ deepseek_xml dans le builder Rust. Il livre 18 nouveaux tests spécifiquement pour V4.1, et les suites existantes complètes — 472 tests dans vllm-parser et 326 dans vllm-chat — restent vertes.

• Le travail sur le frontend Python correspond à la PR #56408, qui est encore à l'état de brouillon. Il dépend de l'intégration préalable d'une modification en amont de XGrammar (mlc-ai/xgrammar#885), et fait état de 110 tests réussis une fois cette dépendance appliquée.

• Le nouveau module d'encodage est vllm/tokenizers/deepseek_v41_encoding.py — un fichier séparé plutôt qu'une branche à l'intérieur de l'encodage V4, ce qui vous indique que la grammaire des balises diffère réellement plutôt que de simplement s'étendre.

• L'invocation est explicite : --tool-parser deepseek_v41. Il n'existe aucun mécanisme de repli de détection automatique qui fasse discrètement ce qu'il faut.

Les balises espacées sont toute l'histoire

La raison pour laquelle un nouveau parseur existe au lieu d’une expression régulière élargie tient aux espaces. DeepSeek V4.1 Flash écrit ses balises d’outil DSML avec des espaces entre les jetons. Le motif du détecteur V4 attend la forme sans espaces, donc il ne correspond pas, et une non-correspondance dans un parseur d’appels d’outils est silencieuse par conception — le texte est transmis comme contenu plutôt que de lever une erreur.

Ce mode de défaillance mérite qu’on s’y attarde, car c’est le plus coûteux. Un parseur qui lève une exception se corrige en un après-midi. Un parseur qui renvoie une chaîne bien formée contenant du balisage que l’appelant n’a jamais demandé ressemble à un problème de qualité de modèle, et les équipes y réagissent comme on réagirait à un problème de qualité de modèle : elles essaient différents prompts, ajoutent des exemples, changent de modèle. Douze jours, c’est assez long pour qu’une bonne partie de cela se soit produite en privé.

Cela signifie aussi que le correctif n'est pas un simple bouton de réglage. Vous ne pouvez pas vous en sortir à coups de prompts face à un détecteur qui ne correspond pas au format de sortie de votre modèle, et vous ne pouvez pas le corriger côté client par post-traitement, car le temps que le texte atteigne votre client, la structure a déjà disparu. Cela doit se faire dans la pile de service, qui est exactement là où cela se trouve désormais.

Pourquoi cela compte davantage pour V4.1 Flash que pour V4

L'appel d'outils n'est pas un simple bonus pour ce modèle particulier. DeepSeek V4.1 Flash est un modèle de mélange d'experts de 552 milliards de paramètres, avec 8 milliards de paramètres actifs en entrée et 16 milliards actifs en sortie, une fenêtre de contexte de 1M de tokens et une sortie maximale de 384K tokens. La répartition des activations est révélatrice : le modèle est conçu pour prendre une grande entrée — un dépôt, un ensemble de documents, une longue trace d'outils — et émettre une longue réponse structurée. C'est une forme d'agent, pas une forme de chat.

Le reste des spécifications de lancement va dans la même direction. Des poids sous licence MIT, 890 octets de cache KV par token, 45 billions de tokens de pré-entraînement, une vision native. Le chiffre du cache KV est celui qui compte sur le plan opérationnel à un contexte de 1 M : c'est ce qui rend abordable le maintien en résidence d'une longue transcription d'agent, et c'est pourquoi le modèle est crédible comme travailleur bon marché dans une boucle supervisée par un modèle plus coûteux.

Ce qui transforme l'écart de douze jours dans l'appel d'outils en un coût bien réel plutôt qu'en une simple note de bas de page. Un modèle dont la justification économique repose sur son rôle d'exécuteur à grand volume dans un pipeline d'agents ne vaut pas grand-chose si le pipeline ne parvient pas à en obtenir un appel structuré.

Qu'est-ce qui est encore ouvert ?

L’état des lieux honnête, au 22 septembre 2026 :

• Le chemin du frontend Rust (PR #56235) est celui qui dispose d’une couverture de tests complète à la fois sur les nouveaux cas V4.1 et sur les suites préexistantes. Si vous utilisez une version de vLLM qui l’inclut, le parseur est à votre disposition dès aujourd’hui.

• Le chemin du frontend Python (PR #56408) est un brouillon et a une dépendance externe. Si vous êtes épinglé à une build antérieure au changement XGrammar, le frontend Python ne vous donnera pas encore le parsing d’outils V4.1.

• Comme l'invocation est explicite, un déploiement qui met à jour vLLM sans modifier ses options de lancement conservera l'ancien comportement. Le fait que le parseur existe et le fait qu'il soit utilisé sont deux choses différentes.

• Il n'existe pas encore de preuve publique d'un benchmark indépendant d'appel d'outils exécuté sur V4.1 Flash avec le nouveau parseur en place. Ce que nous savons, c'est que la mécanique fonctionne et que les tests passent. La qualité d'appel d'outils du modèle est une question distincte, à laquelle la fusion ne répond pas.

Ce dernier point est celui qu’il faut retenir. Une correction du parseur fait passer le modèle de « ne peut pas être évalué » à « peut être évalué ». C’est un prérequis pour un verdict, pas le verdict.

Si vous ne souhaitez pas exécuter vous-même la pile de serving

Il existe un chemin plus court. DeepSeek V4.1 Flash est disponible via l’endpoint d’OrcaRouter qui lui est dédié, ce qui signifie que le comportement d’appel d’outils arrive sous la forme d’un appel API normal plutôt que d’un problème de compilation — aucune version de XGrammar à faire correspondre, aucun frontend à choisir, aucun indicateur de lancement à retenir. La raison pour laquelle cela compte ici précisément, c’est que le correctif a été intégré à deux endroits avec une maturité différente, et un endpoint hébergé réduit ce choix à néant.

La même clé atteint aussi le reste des modèles auxquels vous vous compareriez, ce qui est la propriété utile lorsque la question n'est pas « ce parseur est-il correct » mais « ce modèle est-il suffisamment bon pour ma boucle ». Vous pouvez placer DeepSeek V4.1 Flash derrière une règle de routage comme exécuteur bon marché et le basculer vers un modèle plus puissant en cas d'échec de l'appel, sans second contrat ni second SDK. Essayer un modèle dont la prise en charge de l'appel d'outils date de deux semaines est exactement la situation pour laquelle le basculement automatique existe.

Que regarder ensuite

Trois choses transformeraient cela d’une histoire de plomberie en un verdict :

• La PR #56408 qui sort du brouillon, ce qui rendrait réel le chemin du frontend Python et mettrait fin à la situation de support à deux niveaux.

• Une évaluation indépendante d’agent ou d’appel d’outils menée sur V4.1 Flash avec une pile de service fixe. Le modèle est disponible depuis douze jours et le parseur n’est utilisable que depuis moins longtemps, donc tout score d’appel d’outils que vous voyez cité pour lui en ce moment mérite que l’on s’interroge — la configuration compte autant que le modèle.

• Reste à savoir si d’autres stacks de serving suivront. vLLM est celui qui a des PR publiques ; le problème des balises espacées n’est pas propre à vLLM, donc toute stack qui a adopté le détecteur V4 sans le redériver à partir de la sortie V4.1 a la même défaillance silencieuse qui y sommeille.

Jusqu’à ce que le premier de ces éléments se concrétise, le résumé exact est limité et mérite d’être énoncé sans détour : DeepSeek V4.1 Flash est un modèle GA avec des poids MIT, un contexte de 1 M et un plafond de sortie de 384 K, et son appel d’outils fonctionne désormais sur le chemin Rust dans vLLM avec un indicateur de parseur explicite. C’est une véritable étape, et ce n’est pas encore un résultat.