IT EN
Start a trial

Operational notes Observatory

DeepSeek-V4-Flash-Vision-Exp: Italian Costs 41% More Tokens

7 min read

An abacus with rows of white beads on a red background, some rows more filled than others, close-up black and white photograph
On the same frame, some rows carry more beads than others: the same sentence, in different languages, never fills the same number of slots.

On 31 August 2026 deepseek-ai published DeepSeek-V4-Flash-Vision-Exp on Hugging Face: the first multimodal model in the V4 family, MIT licence, weights included. It is not built for chat, but for agents that read documents, charts and screenshots — exactly the kind of task an Italian office would hand it. The model card lists eleven benchmarks against its predecessor and against a competing model, split between text and multimodal tasks. None of those benchmarks answers a simpler, more concrete question for whoever pays the bill or sizes the hardware: how much does the same document actually cost to run through the tokenizer, in Italian rather than in English? We did not find that number declared anywhere. We measured it ourselves.

The facts, in order

  • 31 August 2026, 06:16 UTC — the createdAt field of the Hugging Face API records the publication of deepseek-ai/DeepSeek-V4-Flash-Vision-Exp. At the time of verification, 2 September 2026, the repository shows 17,893 downloads and 446 likes.
  • Licence and weights: a single LICENSE file, standard MIT text with no revenue threshold and no separate usage policy; 48 .safetensors files totalling roughly 168 GB in fp8 — the weights sit in the repository, not just the code.
  • Architecture, from the config.json file: 43 layers, 256 routed experts plus one shared, six active per token, a context window of 1,048,576 tokens — the same figure already measured on DeepSeek-V4-Flash-0731, whose base architecture this model inherits, adding a vision encoder.
  • What it is, in the card’s own words: “our first experimental multimodal model in the DeepSeek-V4 family”, built “by incorporating visual modules and undergoing continued training to unlock visual understanding capabilities.”
  • Declared hardware: the official vLLM recipe serves it, the card says, “on a single 4×GB300 node” — enterprise-class infrastructure, not a desktop.
  • Benchmarks, the vendor’s own figures: an improvement on multimodal agent tasks over DeepSeek-V4-Flash-0731 (ApexBench Pass@1 from 26.2 to 36.5), comparable results on text-only tasks, a comparison that includes a model listed as “Opus-4.8”. We have not run the model ourselves: these are declared numbers, not ones we verified.

The measurement: the same article, two languages, three tokenizers

The method, in full, so that anyone can redo it. The text is Article 5 of Regulation (EU) 2016/679, the GDPR — principles relating to processing of personal data — downloaded from EUR-Lex in both official versions, Italian and English (CELEX 32016R0679, both pages returned HTTP 200). It is the same legal act, with the same legal force in both languages: not a courtesy translation, but the most honest comparison available, because the content is identical by definition. The Italian text runs to 2,020 characters and 280 words; the English text to 2,025 characters and 295 words — almost the same length in characters, which shows that the gap that follows does not come from the length of the text, but from how each tokenizer splits it.

For each of the three models we downloaded tokenizer.json from its Hugging Face repository with curl -L on the resolve/main/tokenizer.json URL — the first attempt, on raw/main/, returned only the Git LFS pointer, 133 bytes, not the real file — and used the tokenizers 0.23.1 library, already installed, with Tokenizer.from_file(path) and tokenizer.encode(text).ids; no transformers, which is not present on this environment. The DeepSeek-V4-Flash-Vision-Exp file weighs 6,367,257 bytes, consistent with the size reported by the tree/main?recursive=1 API.

The result on Article 5, in number of tokens:

ModelITENIT/EN ratio
DeepSeek-V4-Flash-Vision-Exp5253731.41 (+40.8%)
Mistral Medium 3.54943771.31 (+31.0%)
Qwen3.8-Flash-Next4303841.12 (+12.0%)

For the model in this note, that is 1.88 tokens per Italian word against 1.26 per English word. To check the sample was not a one-off, we repeated the measurement on Article 6 of the same regulation — longer, 655 words in Italian and 671 in English — and the ordering holds: DeepSeek at 1,060 against 779 tokens (ratio 1.36), Mistral at 1,043 against 792 (1.32), Qwen at 896 against 783 (1.14). Then on two entire acts, far longer and on different subject matter: the consolidated text of the Machinery Regulation (EU) 2023/1230, close to fifty thousand words per language, and that of CBAM, Regulation (EU) 2023/956. On the first the gap widens: DeepSeek 85,136 tokens in Italian against 57,646 in English, that is +47.7%; Mistral +35.6%; Qwen +21.8%. On the second, +40.5%, +28.8% and +19.6% respectively. Across three independent texts, from 280 to 48,000 words, the ordering between the three models never changes — and on a whole act the penalty is higher than the one measured on a single article. None of the three tokenizers treats Italian the way it treats English; the model in this note is the least efficient of the three on Italian, in both texts tried.

What the measurement does not tell you

A tokenizer that is more efficient on Italian is not a tokenizer that understands Italian better: these are two different axes, and this measurement touches only one of them. Counting tokens does not require running the model — encoding is deterministic, independent of the weights — which is exactly why our test says nothing about answer quality, real-world latency or behaviour under load: only about how much of the context window, and how much of the bill if the service is metered, the same content occupies once written in one language rather than another. Two legal texts of a few hundred words each, however carefully chosen for the legal equivalence of their two versions, remain a small sample: a commercial contract, an email or a site log could show a different ratio, and anyone deciding on a real case should repeat this same measurement on their own documents.

What to do, in practice

  • Before choosing a model for a use case that is mostly Italian — case files, tender specifications, minutes — measure the token cost on your own real texts; do not trust the vendor’s benchmark, which is almost always in English and Chinese.
  • Treat the 40% surcharge as a line item in your context budget, not a rounding error: a context window advertised at a million tokens buys fewer Italian pages than English ones, and on a metered service the bill grows in the same proportion.
  • If you have to choose between two or three open-weight models, run this same comparison before you sign: the tokenizer.json file is public, and the method needs a laptop, not a cluster.
  • Do not mistake tokenizer efficiency for linguistic quality: these are separate tests, and the second one has to be verified on its own, on the actual tasks the model will have to perform.
  • If your use case includes scanned documents or images — the very reason this model exists — check the token cost of visual prompts too: the card treats that channel separately, and this measurement does not cover it.

The two axes, applied to the cost of language

Compliance. When a public body or a company evaluates an open-weight model to read documents in Italian — tender files, case records, administrative acts — the token cost is not a technical footnote: it decides whether a whole case file fits in one analysis session or has to be split, and how much each pass costs if the service is metered. In our system, tokenising a real sample in the working language before choosing a model becomes a line written into the tender specification, not an assumption left to the vendor.

Decision-making. The same system holds the choice of model, its measured limits and the real use case together in a single operating model, on which AI agents execute decisions with a human operator in command — for large enterprises, government and defence. Always in two modes: on-premises, on autonomous machines without deep integration into the client’s network, or on a dedicated cloud with a VPN and a data centre in Italy, always with shared management: no one is left alone to choose between three tokenizers without ever having counted a single token.

Do you have to choose between two or three open-weight models for a use case in Italian, and no data sheet tells you the real cost? Talk it through in a thirty-minute session: we bring your own real texts, not an English-language benchmark, and we measure the cost together before you discover it in production.

Sources