Il tool calling di DeepSeek V4.1 Flash sbarca in vLLM: cosa hanno rotto i tag spaziati

DeepSeek V4.1 Flash è generalmente disponibile dal 10 settembre 2026 e, nei primi dodici giorni della sua esistenza, il modello presentava una lacuna di cui nessuno ha scritto: era in grado di ragionare, di vedere immagini, di gestire un milione di token di contesto, ma non riusciva a chiamare in modo affidabile uno strumento attraverso lo stack di serving aperto più largamente utilizzato. Questa lacuna ora è colmata in vLLM — non con un flag di configurazione, ma con una riscrittura del parser. Due pull request contengono il lavoro, e il motivo per cui erano necessarie è la parte interessante.

La versione breve: DeepSeek V4.1 Flash emette le sue chiamate agli strumenti in un formato di tag che il rilevatore DeepSeek V4 esistente non riconosce, quindi su un deployment vLLM standard il markup delle chiamate agli strumenti arriva come testo normale invece che come output strutturato. Niente genera errori. Il modello sembra essersi semplicemente rifiutato di chiamare la funzione. Se hai testato loop di agenti con un DeepSeek V4.1 Flash self-hosted e hai concluso che il modello è scarso nell'uso degli strumenti, questo è molto probabilmente quello che stavi guardando.

Che cosa è effettivamente cambiato nello stack di serving

Il parsing delle tool-call di vLLM per i modelli DeepSeek vive in due posti già da un po': un frontend Python e un frontend Rust più recente, con il lavoro a livello di grammatica delegato al progetto XGrammar. Portare il supporto a V4.1 Flash in entrambi ha significato trasferire nel builder Rust la conversione C++ deepseek_xml presente in XGrammar, quindi collegare la codifica propria del modello alla directory del tokenizer di vLLM.

• Il lavoro sul frontend Rust è la PR #56235, che porta la conversione di XGrammar C++ deepseek_xml nel builder Rust. Include 18 nuovi test specificamente per V4.1, e tutte le suite esistenti — 472 test in vllm-parser e 326 in vllm-chat — rimangono verdi.

• Il lavoro sul frontend Python è la PR #56408, che è ancora una bozza. Dipende dall'integrazione preliminare di una modifica upstream a XGrammar (mlc-ai/xgrammar#885) e riporta 110 test superati con tale dipendenza applicata.

• Il nuovo modulo di codifica è vllm/tokenizers/deepseek_v41_encoding.py — un file separato anziché un ramo all'interno della codifica V4, il che indica che la grammatica dei tag differisce realmente anziché essere semplicemente estesa.

• L'invocazione è esplicita: --tool-parser deepseek_v41. Non esiste alcun fallback di rilevamento automatico che faccia silenziosamente la cosa giusta.

I tag separati da spazi sono tutto.

Il motivo per cui esiste un nuovo parser invece di un'espressione regolare ampliata sono gli spazi bianchi. DeepSeek V4.1 Flash scrive i suoi tag degli strumenti DSML con spazi tra i token. Il pattern del rilevatore V4 si aspetta la forma senza spazi, quindi non riesce a trovare una corrispondenza, e una corrispondenza mancata in un parser delle chiamate agli strumenti è silenziosa per progettazione — il testo viene passato come contenuto invece di sollevare un'eccezione.

Vale la pena soffermarsi su quella modalità di guasto perché è quella più costosa. Un parser che solleva un'eccezione si corregge in un pomeriggio. Un parser che restituisce una stringa ben formata contenente markup che il chiamante non ha mai richiesto sembra un problema di qualità del modello, e i team vi reagiscono come reagirebbero a un problema di qualità del modello: provano prompt diversi, aggiungono esempi, cambiano modello. Dodici giorni sono abbastanza perché molto di tutto ciò sia accaduto in privato.

Significa anche che la soluzione non è una manopola di regolazione. Non puoi uscire con un prompt da un rilevatore che non corrisponde al formato di output del tuo modello, e non puoi sistemarlo nel client con la post-elaborazione, perché quando il testo raggiunge il tuo client la struttura è già scomparsa. Deve avvenire nello stack di serving, che è esattamente dove si trova ora.

Perché questo è più importante per V4.1 Flash di quanto lo fosse per V4

La chiamata di strumenti non è un optional per questo particolare modello. DeepSeek V4.1 Flash è un modello mixture-of-experts da 552 miliardi di parametri, con 8 miliardi di parametri attivi in input e 16 miliardi attivi in output, una finestra di contesto da 1M token e un output massimo di 384K token. La suddivisione delle attivazioni è l'indizio: il modello è progettato per ricevere un input di grandi dimensioni — un repository, un insieme di documenti, una lunga traccia di strumenti — e produrre una lunga risposta strutturata. Questa è una forma da agente, non da chat.

Il resto della specifica di lancio punta nella stessa direzione. Pesi con licenza MIT, 890 byte di KV cache per token, 45 trilioni di token di pre-addestramento, visione nativa. Il dato sulla KV cache è quello che conta a livello operativo con un contesto di 1M: è ciò che rende sostenibile mantenere residente una lunga trascrizione di agente, ed è il motivo per cui il modello è plausibile come worker economico in un ciclo supervisionato da un modello più costoso.

Il che rende il divario di dodici giorni nel tool calling un costo reale anziché una nota a piè di pagina. Un modello il cui caso economico si basa sull’essere l’esecutore ad alto volume in una pipeline di agenti vale ben poco se la pipeline non riesce a ottenere da esso una chiamata strutturata.

Cosa è ancora aperto?

Lo stato reale delle cose, al 22 settembre 2026:

• Il percorso del frontend Rust (PR #56235) è quello con copertura completa dei test sia sui nuovi casi V4.1 sia sulle suite preesistenti. Se utilizzi una build di vLLM che lo include, il parser è già disponibile per te oggi.

• Il percorso del frontend Python (PR #56408) è una bozza e ha una dipendenza esterna. Se sei vincolato a una build precedente alla modifica di XGrammar, il frontend Python non ti fornirà ancora il parsing degli strumenti di V4.1.

• Poiché l'invocazione è esplicita, un deployment che aggiorna vLLM ma non modifica i suoi flag di avvio manterrà il vecchio comportamento. Che il parser esista e che il parser venga usato sono due cose diverse.

• Non esiste ancora alcuna prova pubblica di un benchmark indipendente di tool calling eseguito su V4.1 Flash con il nuovo parser in uso. Quello che sappiamo è che l'infrastruttura funziona e i test passano. Se la qualità del tool calling del modello sia buona è una questione separata a cui il merge non risponde.

Quell'ultimo punto è quello a cui aggrapparsi. Una correzione del parser fa passare il modello da «non può essere valutato» a «può essere valutato». È un prerequisito per un verdetto, non il verdetto.

Se non vuoi eseguire tu stesso lo stack di serving

Esiste un percorso più breve. DeepSeek V4.1 Flash è disponibile tramite l'endpoint di OrcaRouter ad esso dedicato, il che significa che il comportamento di chiamata degli strumenti arriva come una normale chiamata API anziché come un problema di build — nessuna versione di XGrammar da abbinare, nessun frontend da scegliere, nessun flag di avvio da ricordare. Il motivo per cui questo conta qui in particolare è che la correzione è arrivata in due punti con maturità diversa, e un endpoint ospitato riduce quella decisione a nulla.

La stessa chiave raggiunge anche il resto dei modelli con cui ti troveresti a confrontarti, ovvero la proprietà utile quando la domanda non è "questo parser è corretto" ma "questo modello è abbastanza buono per il mio loop". Puoi mettere DeepSeek V4.1 Flash dietro una regola di routing come esecutore economico e passare a un modello più potente quando la chiamata fallisce, senza un secondo contratto o un secondo SDK. Provare un modello il cui supporto per il tool calling ha due settimane di vita è esattamente la situazione per cui esiste il failover automatico.

Cosa guardare dopo

Tre cose trasformerebbero questa da una storia di idraulica in un verdetto:

• La PR #56408 esce dalla bozza, il che renderebbe reale il percorso del frontend Python e porrebbe fine alla situazione di supporto a due livelli.

• Una valutazione indipendente di agenti o di chiamata di strumenti eseguita su V4.1 Flash su uno stack di serving fisso. Il modello è disponibile da dodici giorni e il parser è utilizzabile da meno tempo, quindi qualsiasi punteggio di chiamata di strumenti che vedi citato per esso in questo momento è qualcosa su cui vale la pena chiedere — la configurazione conta quanto il modello.

• Se altri stack di serving seguiranno. vLLM è quello con PR pubbliche; il problema del tag spaziato non è specifico di vLLM, quindi qualsiasi stack che abbia adottato il rilevatore V4 senza ricavarlo di nuovo dall'output V4.1 ha lo stesso guasto silenzioso al suo interno.

Finché il primo di questi non si concretizza, il riassunto accurato è limitato e vale la pena affermarlo chiaramente: DeepSeek V4.1 Flash è un modello GA con pesi MIT, un contesto da 1M e un tetto di output di 384K, e il suo tool calling ora funziona sul percorso Rust in vLLM con un flag esplicito del parser. Questo è un vero passo avanti e non è ancora un risultato.