IT EN
Avvia una prova

Note operative Osservatorio

DeepSeek-V4-Flash-Vision-Exp: l’italiano pesa il 41% di token in più

7 min di lettura

Pallottoliere con file di perline bianche su sfondo rosso, alcune file più cariche di altre, fotografia in bianco e nero ravvicinata
Sullo stesso telaio, alcune file portano più perline di altre: la stessa frase, in lingue diverse, non riempie mai lo stesso numero di caselle.

Il 31 agosto 2026 deepseek-ai ha pubblicato su Hugging Face DeepSeek-V4-Flash-Vision-Exp: primo modello multimodale della famiglia V4, licenza MIT, pesi inclusi. Non è pensato per una chat, ma per agenti che leggono documenti, grafici e schermate — esattamente il genere di compito che un ufficio italiano gli affiderebbe. La scheda tecnica riporta undici benchmark contro il predecessore e contro un modello concorrente, divisi fra compiti testuali e multimodali. Nessuno di questi benchmark risponde a una domanda più semplice, e più concreta per chi paga la fattura o dimensiona l’hardware: lo stesso documento, in italiano invece che in inglese, quanto costa davvero attraversare il tokenizer? Non l’abbiamo letta da nessuna parte dichiarata. L’abbiamo misurata noi.

I fatti, in ordine

  • 31 agosto 2026, ore 06:16 UTC — il campo createdAt dell’API di Hugging Face registra la pubblicazione di deepseek-ai/DeepSeek-V4-Flash-Vision-Exp. Al momento della verifica, il 2 settembre 2026, il repository segna 17.893 download e 446 like.
  • Licenza e pesi: un solo file LICENSE, testo MIT standard senza soglie di fatturato né usage policy separata; 48 file .safetensors per circa 168 GB in fp8 — i pesi sono nel repository, non solo il codice.
  • Architettura, dal file config.json: 43 strati, 256 esperti instradati più uno condiviso, sei attivi per ogni token, finestra di contesto 1.048.576 token — la stessa cifra già misurata su DeepSeek-V4-Flash-0731, di cui questo modello eredita l’architettura di base aggiungendo un encoder visivo.
  • Che cos’è, nelle parole della scheda: «our first experimental multimodal model in the DeepSeek-V4 family» — il nostro primo modello multimodale sperimentale della famiglia DeepSeek-V4 — costruito «by incorporating visual modules and undergoing continued training to unlock visual understanding capabilities» — incorporando moduli visivi e proseguendo l’addestramento per sbloccare capacità di comprensione visiva.
  • Hardware dichiarato: la ricetta ufficiale per vLLM lo serve, dice la scheda, «on a single 4×GB300 node» — su un singolo nodo a quattro GPU GB300 — infrastruttura di classe enterprise, non un desktop.
  • Benchmark, cifre del produttore: miglioramento sui compiti agentici multimodali rispetto a DeepSeek-V4-Flash-0731 (ApexBench Pass@1 da 26,2 a 36,5), risultati comparabili sui compiti solo testuali, confronto incluso con un modello indicato come «Opus-4.8». Non abbiamo eseguito il modello: sono numeri dichiarati, non verificati da noi.

La misura: lo stesso articolo, due lingue, tre tokenizer

Il metodo, per intero, così chiunque possa rifarlo. Il testo è l’articolo 5 del Regolamento (UE) 2016/679, il GDPR — principi sul trattamento dei dati personali — scaricato da EUR-Lex nelle due versioni ufficiali, italiana e inglese (CELEX 32016R0679, entrambe le pagine hanno risposto HTTP 200). È lo stesso atto giuridico, con lo stesso valore legale nelle due lingue: non una traduzione di cortesia, ma il confronto più onesto possibile perché il contenuto è identico per definizione. Il testo italiano conta 2.020 caratteri e 280 parole; quello inglese 2.025 caratteri e 295 parole — quasi la stessa lunghezza misurata in caratteri, a riprova che la differenza che segue non nasce dalla lunghezza del testo, ma da come ciascun tokenizer lo spezza.

Per ognuno dei tre modelli abbiamo scaricato tokenizer.json dal repository Hugging Face con curl -L sull’URL resolve/main/tokenizer.json — il primo tentativo, su raw/main/, restituiva solo il puntatore Git LFS, 133 byte, non il file vero — e usato la libreria tokenizers 0.23.1, già installata, con Tokenizer.from_file(path) e tokenizer.encode(testo).ids; niente transformers, che sull’ambiente non c’è. Il file di DeepSeek-V4-Flash-Vision-Exp pesa 6.367.257 byte, coerente con la dimensione riportata dall’API tree/main?recursive=1.

Il risultato sull’articolo 5, in numero di token:

ModelloITENRapporto IT/EN
DeepSeek-V4-Flash-Vision-Exp5253731,41 (+40,8%)
Mistral Medium 3.54943771,31 (+31,0%)
Qwen3.8-Flash-Next4303841,12 (+12,0%)

Per il modello di questa nota, 1,88 token per parola italiana contro 1,26 per parola inglese. Per controllare che il campione non fosse un caso isolato, abbiamo ripetuto la misura sull’articolo 6 dello stesso regolamento — più lungo, 655 parole in italiano e 671 in inglese — e l’ordine si conferma: DeepSeek 1.060 contro 779 token (rapporto 1,36), Mistral 1.043 contro 792 (1,32), Qwen 896 contro 783 (1,14). Poi su due atti interi, molto più lunghi e di materia diversa: il testo consolidato del regolamento macchine (UE) 2023/1230, quasi cinquantamila parole per lingua, e quello del CBAM, il regolamento (UE) 2023/956. Sul primo il divario cresce: DeepSeek 85.136 token in italiano contro 57.646 in inglese, cioè +47,7%; Mistral +35,6%; Qwen +21,8%. Sul secondo, rispettivamente +40,5%, +28,8% e +19,6%. Su tre testi indipendenti, di lunghezza fra le 280 e le 48.000 parole, l’ordine fra i tre modelli non cambia mai — e su un atto intero la penalità è più alta di quella misurata su un solo articolo. Nessuno dei tre tokenizer tratta l’italiano come l’inglese; quello di questa nota è il meno efficiente dei tre sull’italiano, in entrambi i testi provati.

Quello che la misura non dice

Un tokenizer più efficiente sull’italiano non è un tokenizer che capisce meglio l’italiano: sono due assi diversi, e questa misura ne tocca uno solo. Contare i token non richiede eseguire il modello — l’incapsulamento è deterministico, indipendente dai pesi — e per questo la nostra prova non dice nulla sulla qualità delle risposte, sulla latenza reale o sul comportamento sotto carico: solo su quanto spazio nella finestra di contesto e quanto conto, se il servizio è a consumo, occupa lo stesso contenuto scritto in una lingua piuttosto che in un’altra. Due testi giuridici di poche centinaia di parole, per quanto scelti per l’equivalenza legale delle due versioni, restano un campione piccolo: un contratto commerciale, una email o un verbale di cantiere potrebbero avere un rapporto diverso, e chi decide su un caso reale dovrebbe ripetere la stessa misura sui propri documenti.

Cosa fare, in pratica

  • Prima di scegliere un modello per un caso d’uso a maggioranza italiana — fascicoli, capitolati, verbali — misurate il costo in token sui vostri testi reali, non fidatevi del benchmark del produttore, quasi sempre in inglese e cinese.
  • Trattate il 40% in più come una voce di budget del contesto, non un arrotondamento: una finestra dichiarata da un milione di token vale meno pagine italiane che pagine inglesi, e in un servizio a consumo il conto cresce nella stessa proporzione.
  • Se dovete scegliere fra due o tre modelli a pesi aperti, ripetete questo confronto prima di firmare: il file tokenizer.json è pubblico, il metodo richiede un laptop, non un cluster.
  • Non scambiate l’efficienza del tokenizzatore per qualità linguistica: sono prove distinte, e la seconda va verificata separatamente, sui compiti veri che il modello dovrà svolgere.
  • Se il caso d’uso include documenti scannerizzati o immagini — la ragione stessa per cui questo modello esiste — verificate anche il costo in token dei prompt visivi: la scheda tratta quel canale a parte, e questa misura non lo copre.

I due assi, applicati al costo della lingua

Adempiere. Quando un ente o un’impresa valuta un modello a pesi aperti per leggere documenti in italiano — capitolati, fascicoli, atti amministrativi — il costo in token non è un dettaglio tecnico: decide se un fascicolo intero entra in una sessione di analisi o va spezzato, e quanto pesa ogni passaggio se il servizio è a consumo. Nel nostro impianto, tokenizzare un campione reale nella lingua di lavoro prima di scegliere il modello diventa un passaggio scritto nel capitolato, non un’ipotesi lasciata al fornitore.

Decidere. Lo stesso impianto tiene insieme la scelta del modello, i suoi limiti misurati e il caso d’uso reale in un modello operativo unico, su cui agenti AI eseguono decisioni con un operatore al comando — per grandi imprese, pubblica amministrazione e difesa. Sempre in due modalità: on-premise, su macchine autonome senza integrazione profonda nella rete del cliente, oppure cloud dedicato con VPN e data center in Italia, sempre con gestione condivisa: nessuno resta solo a scegliere fra tre tokenizer senza averne mai contato un token.

Dovete scegliere fra due o tre modelli a pesi aperti per un caso d’uso in italiano, e nessuna scheda tecnica ve lo dice? Parliamone in una sessione di trenta minuti: portiamo i vostri testi reali, non un benchmark in inglese, e misuriamo insieme il costo prima che lo scopriate in produzione.

Fonti