DeepSeek V4.1 Flash Tool Calling landar i vLLM: Vad de mellanrumsseparerade taggarna förstörde

DeepSeek V4.1 Flash har varit allmänt tillgänglig sedan den 10 september 2026, och under de första tolv dagarna av sin livstid hade modellen en lucka som ingen skrev om: den kunde resonera, den kunde se bilder, den kunde hålla en miljon tokens i kontext, men den kunde inte på ett tillförlitligt sätt anropa ett verktyg genom den mest använda öppna serveringsstacken. Den luckan är nu stängd i vLLM – inte med en konfigurationsflagga, utan med en omskrivning av parsern. Två pull requests bär arbetet, och anledningen till att de behövdes är det intressanta.

Den korta versionen: DeepSeek V4.1 Flash skickar sina verktygsanrop i ett taggformat som den befintliga DeepSeek V4-detektorn inte känner igen, så i en standarddistribution av vLLM kommer verktygsanropsmarkeringen fram som vanlig text i stället för strukturerad utdata. Inget fel uppstår. Det ser ut som att modellen helt enkelt lät bli att anropa funktionen. Om du har testat agentloopar mot en egenhostad DeepSeek V4.1 Flash och dragit slutsatsen att modellen är dålig på verktyg, är det här med stor sannolikhet det du tittade på.

Vad förändrades egentligen i serving-stacken?

vLLMs verktygsanropsparsning för DeepSeek-modeller har länge funnits på två ställen: en Python-frontend och en nyare Rust-frontend, med arbetet på grammatiknivå delegerat till XGrammar-projektet. Att få in stödet för V4.1 Flash innebar att porta C++ deepseek_xml-konverteringen inuti XGrammar till Rust-byggaren och sedan koppla in modellens egen kodning i vLLMs tokenizer-katalog.

• Rust-frontendarbetet är PR #56235, som porterar XGrammar C++ deepseek_xml-konverteringen till Rust-byggaren. Det levererar 18 nya tester specifikt för V4.1, och de befintliga testsviterna i sin helhet – 472 tester i vllm-parser och 326 i vllm-chat – förblir gröna.

• Arbetet med Python-frontend är PR #56408, som fortfarande är ett utkast. Det är beroende av att en uppströmsändring i XGrammar (mlc-ai/xgrammar#885) landar först, och rapporterar 110 godkända tester med det beroendet tillämpat.

• Den nya kodningsmodulen är vllm/tokenizers/deepseek_v41_encoding.py — en separat fil snarare än en gren inuti V4-kodningen, vilket visar att tagggrammatiken verkligen skiljer sig i stället för att bara utökas.

• Anropet är explicit: --tool-parser deepseek_v41. Det finns ingen automatisk detekteringsfallback som i tysthet gör det rätta.

De åtskilda taggarna är hela historien.

Anledningen till att en ny parser finns i stället för ett utökat reguljärt uttryck är blanksteg. DeepSeek V4.1 Flash skriver sina DSML-verktygstaggar med blanksteg mellan tokenarna. V4-detektorns mönster förväntar sig formen utan blanksteg, så det matchar inte, och en misslyckad matchning i en parser för verktygsanrop är avsiktligt tyst — texten skickas vidare som innehåll i stället för att kasta ett fel.

Det felläget är värt att uppehålla sig vid, eftersom det är den mest kostsamma sorten. En parser som kastar ett undantag åtgärdas på en eftermiddag. En parser som returnerar en välformad sträng med markup som anroparen aldrig bad om ser ut som ett modellkvalitetsproblem, och team svarar på det så som man skulle svara på ett modellkvalitetsproblem: de provar olika promptar, de lägger till exempel, de byter modeller. Tolv dagar är tillräckligt länge för att en hel del av det ska ha kunnat hända i det tysta.

Det betyder också att lösningen inte är en justeringsratt. Du kan inte prompta dig ur en detektor som inte matchar din modells utdataformat, och du kan inte åtgärda det i klienten genom efterbearbetning, eftersom strukturen redan är borta när texten når din klient. Det måste ske i serveringsstacken, vilket är precis där den nu finns.

Varför detta är viktigare för V4.1 Flash än det var för V4

Verktygsanrop är inte enbart en trevlig bonus för just den här modellen. DeepSeek V4.1 Flash är en mixture-of-experts-modell med 552 miljarder parametrar, varav 8 miljarder är aktiva vid indata och 16 miljarder aktiva vid utdata, ett kontextfönster på 1M tokens och en maximal utdata på 384K tokens. Aktiveringsfördelningen är ledtråden: modellen är byggd för att ta en stor indata — ett kodförråd, en dokumentuppsättning, ett långt verktygsspår — och avge ett långt strukturerat svar. Det är en agentform, inte en chattform.

Resten av lanseringsspecifikationen pekar åt samma håll. MIT-licensierade vikter, 890 byte KV-cache per token, 45 biljoner förträningstokens, inbyggd vision. KV-cache-siffran är den som spelar roll operativt vid 1M kontext: det är vad som gör en lång agenttranskription överkomlig att hålla resident, och det är därför modellen är rimlig som den billiga arbetaren i en loop som en dyrare modell övervakar.

Vilket gör tolvdagarsgapet i verktygsanrop till en verklig kostnad snarare än en fotnot. En modell vars ekonomiska kalkyl bygger på att vara högvolymsexekutor i en agentpipeline är värd väldigt lite om pipelinen inte kan få ut ett strukturerat anrop från den.

Vad är fortfarande öppet?

Det ärliga läget per den 22 september 2026:

• Rust-frontend-sökvägen (PR #56235) är den som har fullständig testtäckning för både de nya V4.1-fallen och de befintliga testsviterna. Om du kör en vLLM-version som innehåller den är parsern tillgänglig för dig redan idag.

• Python-frontend-vägen (PR #56408) är ett utkast och har ett externt beroende. Om du är låst till en build som föregår XGrammar-ändringen kommer Python-frontenden ännu inte att ge dig V4.1-verktygsparsning.

Eftersom anropet är explicit kommer en driftsättning som uppgraderar vLLM men inte ändrar sina startflaggor att behålla det gamla beteendet. Att parsern finns och att parsern används är två olika saker.

• Det finns ännu inga offentliga bevis på att en oberoende benchmark för verktygsanrop har körts mot V4.1 Flash med den nya parsern på plats. Vad vi vet är att infrastrukturen fungerar och att testerna passerar. Huruvida modellens kvalitet på verktygsanrop är bra är en separat fråga som sammanslagningen inte besvarar.

Den sista punkten är den man ska hålla fast vid. En parserfix flyttar modellen från "kan inte utvärderas" till "kan utvärderas". Det är en förutsättning för ett utlåtande, inte utlåtandet.

Om du inte vill köra serving-stacken själv

Det finns en kortare väg. DeepSeek V4.1 Flash är tillgänglig via OrcaRouters slutpunkt för den, vilket innebär att verktygsanropsbeteendet kommer som ett vanligt API-anrop i stället för som ett byggproblem – ingen XGrammar-version att matcha, ingen frontend att välja, ingen startflagga att komma ihåg. Anledningen till att det spelar roll just här är att rättningen landade på två ställen med olika mognad, och en hostad slutpunkt reducerar det beslutet till ingenting.

Samma nyckel når också resten av modellerna som du skulle jämföra med, vilket är den användbara egenskapen när frågan inte är "är den här parsern korrekt" utan "är den här modellen tillräckligt bra för min loop". Du kan sätta DeepSeek V4.1 Flash bakom en routingregel som den billiga exekutorn och växla över den till en starkare modell när anropet misslyckas, utan ett andra kontrakt eller ett andra SDK. Att prova en modell vars stöd för verktygsanrop är två veckor gammalt är precis den situation som automatisk failover finns till för.

Vad du ska titta på härnäst

Tre saker skulle förvandla detta från en historia om rörsystem till en dom:

• PR #56408 lämnar draft, vilket skulle göra Python-frontendvägen verklig och sätta stopp för situationen med två nivåer av stöd.

• En oberoende agent- eller verktygsanropande utvärderingskörning mot V4.1 Flash på en fast serving-stack. Modellen har funnits ute i tolv dagar och parsern har varit användbar kortare tid än så, så varje poäng för verktygsanrop som du ser citerad för den just nu är värd att ställa frågor om — uppsättningen spelar lika stor roll som modellen.

• Huruvida andra serving-stackar följer efter. vLLM är den med offentliga PR:er; problemet med taggar med mellanslag är inte specifikt för vLLM, så varje stack som antog V4-detektorn utan att härleda den på nytt från V4.1-utdata har samma tysta fel liggande i sig.

Fram till dess att det första av dessa har landat är den korrekta sammanfattningen snäv och värd att sägas rakt ut: DeepSeek V4.1 Flash är en GA-modell med MIT-vikter, en kontext på 1M och ett utdatatak på 384K, och dess verktygsanrop fungerar nu på Rust-vägen i vLLM med en explicit parserflagga. Det är ett verkligt steg och det är ännu inte ett resultat.