DeepSeek V4.1 Flash Tool Calling landt in vLLM: wat de tags met spaties braken

DeepSeek V4.1 Flash is algemeen beschikbaar sinds 10 september 2026, en gedurende de eerste twaalf dagen van zijn bestaan had het model een gat waar niemand over schreef: het kon redeneren, het kon afbeeldingen zien, het kon een miljoen tokens aan context bevatten, en het kon niet betrouwbaar een tool aanroepen via de meest gebruikte open serving-stack. Dat gat is nu gedicht in vLLM — niet met een configuratievlag, maar met een herschreven parser. Twee pull requests dragen het werk, en de reden dat ze nodig waren is het interessante deel.

De korte versie: DeepSeek V4.1 Flash stuurt zijn tool calls uit in een tagformaat dat de bestaande DeepSeek V4-detector niet herkent, dus op een standaard vLLM-implementatie komt de tool-call-markup aan als gewone tekst in plaats van gestructureerde uitvoer. Er gaat niets mis. Het model lijkt gewoon te hebben geweigerd de functie aan te roepen. Als je agent-loops hebt getest tegen een zelfgehoste DeepSeek V4.1 Flash en hebt geconcludeerd dat het model slecht is in tools, is dit hoogstwaarschijnlijk wat je zag.

Wat is er eigenlijk veranderd in de servingstack?

De tool-call-parsing van vLLM voor DeepSeek-modellen is al een tijdje op twee plekken te vinden: een Python-frontend en een nieuwere Rust-frontend, waarbij het werk op grammaticaniveau aan het XGrammar-project is gedelegeerd. Het overbrengen van V4.1 Flash-ondersteuning betekende het porten van de C++ deepseek_xml-conversie binnen XGrammar naar de Rust-builder, en vervolgens het integreren van de eigen encoding van het model in vLLM's tokenizer-map.

• Het Rust-frontendwerk is PR #56235, dat de XGrammar C++ deepseek_xml-conversie naar de Rust-builder porteert. Het levert 18 nieuwe tests, specifiek voor V4.1, en de volledige bestaande suites — 472 tests in vllm-parser en 326 in vllm-chat — blijven groen.

• Het Python-frontendwerk is PR #56408, die nog een concept is. Het is afhankelijk van een upstream XGrammar-wijziging (mlc-ai/xgrammar#885) die eerst moet landen, en rapporteert 110 geslaagde tests wanneer die afhankelijkheid is toegepast.

• De nieuwe encodingmodule is vllm/tokenizers/deepseek_v41_encoding.py — een apart bestand in plaats van een branch binnen de V4-encoding, wat aangeeft dat de taggrammatica werkelijk verschilt en niet slechts een uitbreiding is.

• De aanroep is expliciet: --tool-parser deepseek_v41. Er is geen auto-detectie-fallback die stilletjes het juiste doet.

De gespatieerde tags zijn het hele verhaal

De reden dat er een nieuwe parser is in plaats van een verruimde reguliere expressie, is witruimte. DeepSeek V4.1 Flash schrijft zijn DSML-tooltags met spaties tussen de tokens. Het patroon van de V4-detector verwacht de vorm zonder spaties, dus er wordt geen overeenkomst gevonden, en een mislukte overeenkomst in een parser voor toolaanroepen is bewust stil — de tekst wordt als inhoud doorgegeven in plaats van een fout te genereren.

Het loont de moeite om bij die faalmodus stil te staan, want het is de duurste soort. Een parser die een uitzondering opgooit, is in een middag gerepareerd. Een parser die een welgevormde string teruggeeft met markup waar de aanroeper nooit om heeft gevraagd, ziet eruit als een modelkwaliteitsprobleem, en teams reageren erop zoals je op een modelkwaliteitsprobleem zou reageren: ze proberen andere prompts, ze voegen voorbeelden toe, ze stappen over op andere modellen. Twaalf dagen is lang genoeg voor veel daarvan om zich binnenskamers te hebben afgespeeld.

Het betekent ook dat de oplossing geen afstelknop is. Je kunt je niet uit een detector prompten die niet overeenkomt met het uitvoerformaat van je model, en je kunt het in de client niet oplossen met nabewerking, want tegen de tijd dat de tekst je client bereikt, is de structuur al verdwenen. Het moet in de serving-stack gebeuren, en dat is precies waar het nu zit.

Waarom dit belangrijker is voor V4.1 Flash dan voor V4

Tool calling is voor dit specifieke model geen nice-to-have. DeepSeek V4.1 Flash is een mixture-of-experts-model met 552 miljard parameters, waarvan 8 miljard parameters actief zijn bij input en 16 miljard actief bij output, een contextvenster van 1M tokens en een maximale output van 384K tokens. De activatieverdeling is de aanwijzing: het model is gebouwd om een grote input te verwerken — een repository, een documentenset, een lange tool-trace — en een lang gestructureerd antwoord te produceren. Dat is de vorm van een agent, niet die van een chat.

De rest van de lanceringsspecificatie wijst in dezelfde richting. MIT-gelicentieerde gewichten, 890 bytes KV-cache per token, 45 biljoen pretrainingstokens, native vision. Het KV-cachecijfer is het cijfer dat operationeel van belang is bij 1M context: het is wat het betaalbaar maakt om een lang agenttranscript resident te houden, en het is waarom het model geloofwaardig is als de goedkope werker in een lus die door een duurder model wordt gesuperviseerd.

Daardoor is de twaalfdaagse kloof op het gebied van tool-calling een reële kostenpost in plaats van een voetnoot. Een model waarvan de economische rechtvaardiging erop berust dat het de uitvoerder voor grote volumes in een agent-pijplijn is, is heel weinig waard als de pijplijn er geen gestructureerde aanroep uit kan krijgen.

Wat is er nog open?

De eerlijke stand van zaken, per 22 september 2026:

• Het Rust-frontendpad (PR #56235) is degene met volledige testdekking voor zowel de nieuwe V4.1-cases als de reeds bestaande suites. Als je op een vLLM-build zit die dit bevat, is de parser vandaag al beschikbaar voor je.

• Het Python-frontendpad (PR #56408) is een concept en heeft een externe afhankelijkheid. Als je vastzit aan een build die dateert van vóór de XGrammar-wijziging, geeft de Python-frontend je nog geen V4.1-toolparsing.

• Omdat de aanroep expliciet is, zal een deployment die vLLM upgradet maar de opstartvlaggen niet wijzigt, het oude gedrag behouden. Dat de parser bestaat en dat de parser wordt gebruikt, zijn twee verschillende dingen.

• Er is nog geen openbaar bewijs van een onafhankelijke tool-calling-benchmark die tegen V4.1 Flash is uitgevoerd met de nieuwe parser op zijn plaats. Wat we weten is dat de onderliggende infrastructuur werkt en de tests slagen. Of de tool-calling-kwaliteit van het model goed is, is een aparte vraag die de merge niet beantwoordt.

Dat laatste punt is het punt om aan vast te houden. Een parser-fix brengt het model van "kan niet worden geëvalueerd" naar "kan worden geëvalueerd". Het is een voorwaarde voor een oordeel, niet het oordeel.

Als je de serving-stack niet zelf wilt draaien

Er is een kortere weg. DeepSeek V4.1 Flash is beschikbaar via OrcaRouter's endpoint daarvoor, wat betekent dat het tool-callinggedrag aankomt als een normale API-call in plaats van als een buildprobleem — geen XGrammar-versie om af te stemmen, geen frontend om te kiezen, geen launchflag om te onthouden. De reden dat dit hier specifiek van belang is, is dat de fix op twee plekken is beland met een verschillende mate van volwassenheid, en een gehost endpoint reduceert die beslissing tot niets.

Dezelfde sleutel bereikt ook de rest van de modellen waarmee je zou vergelijken, wat de nuttige eigenschap is wanneer de vraag niet is "is deze parser correct", maar "is dit model goed genoeg voor mijn loop." Je kunt DeepSeek V4.1 Flash achter een routeringsregel zetten als de goedkope uitvoerder en het bij een mislukte aanroep laten overschakelen naar een sterker model, zonder een tweede contract of een tweede SDK. Een model proberen waarvan de tool-calling-ondersteuning twee weken oud is, is precies de situatie waarvoor automatische failover bestaat.

Wat nu te kijken

Drie dingen zouden dit van een loodgietersverhaal in een vonnis veranderen:

• PR #56408 wordt uit concept gehaald, wat het Python-frontendpad echt zou maken en een einde zou maken aan de situatie met ondersteuning in twee lagen.

• Een onafhankelijke agent- of tool-calling-evaluatie uitgevoerd tegen V4.1 Flash op een vaste serving-stack. Het model is twaalf dagen uit, en de parser is nog minder lang bruikbaar, dus elke tool-calling-score die je er nu voor ziet aangehaald, is het waard om navraag naar te doen — de setup is even belangrijk als het model.

• Of andere serving-stacks volgen. vLLM is degene met openbare PR's; het spaced-tag-probleem is niet specifiek voor vLLM, dus elke stack die de V4-detector heeft overgenomen zonder die opnieuw af te leiden uit de V4.1-output, heeft dezelfde stille fout erin zitten.

Totdat de eerste daarvan landt, is de nauwkeurige samenvatting beperkt en het waard om ronduit te stellen: DeepSeek V4.1 Flash is een GA-model met MIT-gewichten, een context van 1M en een outputplafond van 384K, en de tool calling werkt nu op het Rust-pad in vLLM met een expliciete parser-flag. Dat is een echte stap en het is nog geen resultaat.