Tokens per word in German, French, Polish and other EU languages: LLM server sizing

How many tokens per word European languages produce

Most LLM tokenizers split German, French or Polish text into more tokens per word than English. A preprint of May 2026 that ran six public tokenizers, from Llama 3.3, Llama 4 Maverick, Qwen3, Gemma 2, DeepSeek V3 and GPT-4o, on the same parallel text reports a mean of 1.23 tokens per word for English, 1.52 for French, 1.76 for German, 2.25 for Polish and 2.99 for Finnish. Context windows, KV cache, users per GPU and generation speed are all counted in tokens, so a German assistant needs about 40 per cent more of each than an English one for the same number of words, and a Polish one about 80 per cent more.

The figures below are published counts; we did not run the tokenizers ourselves. Where we convert them into sizing numbers, the arithmetic is ours and is labelled as an estimate. Our guide to open LLMs for European languages covers which models name which languages; this article covers what the language does to the hardware once the model is chosen.

Published tokens-per-word figures by language

The preprint (arXiv 2605.24718, May 2026) measured fertility, the number of tokens per whitespace-delimited word, for 25 European languages on SIB-200, a parallel topic-classification set in which every language carries the same content. Its Table 4 gives the mean over the six tokenizers and the lowest and highest value among them.

arXiv 2605.24718 (May 2026), Table 4: mean tokenizer fertility across six models (Llama 4 Maverick, Llama 3.3 70B, Qwen3 32B, Gemma 2 27B, GPT-4o, DeepSeek V3) on SIB-200 parallel text, read on 24 October 2026. "Vs English" is our division of the means. The same table lists Danish 1.87, Croatian 2.31, Slovenian 2.28, Slovak 2.45, Estonian 2.78, Lithuanian 2.86, Latvian 2.97 and Maltese 3.10.

Three patterns stand out. The Romance languages sit closest to English. German and the other Germanic languages need roughly 35 to 55 per cent more tokens per word; by our reading, long German compounds count as one word and are split into several tokens. The Slavic, Baltic and Finno-Ugric languages, Greek and Maltese need about 1.8 to 2.5 times the English rate, with Greek showing the widest spread between tokenizers.

Two caveats apply to all of these numbers. They are one preprint's measurements on short general-domain sentences, and your contracts, tickets or manuals use other vocabulary. And fertility is per word of the same language: a German translation does not have the same number of words as its English original, so the figure to use is the one for the language your word count comes from.

Tokenizer fertility: why the model's tokenizer matters

The range column is the tokenizer at work. A vocabulary with more non-English pieces splits European words less often, and size alone does not decide: in the table below, EuroLLM's 128,000 entries give 2.21 tokens per word on FLORES-200 and Llama 3.1's 128,256 give 2.78. A tokenizer card from the EU-funded OpenEuroLLM project publishes a comparison on its own multi-domain test suite, again in tokens per whitespace word, with the vocabulary size of each tokenizer.

OpenEuroLLM tokenizer card openeurollm/tokenizer-256k-v2 on Hugging Face, multi-domain table, read on 24 October 2026: FLORES-200 is the mean over 36 languages of parallel sentences, PDFs a set of documents in five languages, code Python files. The card's own 256k tokenizer reaches 1.79 on FLORES-200. The gpt-oss-120b config.json lists a vocab_size of 201,088.

On the multilingual FLORES-200 average, the Llama 3.1 and Qwen3 tokenizers produce about a third more tokens per word than the gpt-oss and Gemma 3 tokenizers. On the five-language PDF set the gap nearly closes: Llama 3.1 reaches 2.18, behind only gpt-oss at 2.01, which shows how much the text itself matters. The figures belong to the tokenizer, not to the model size, so check which tokenizer the checkpoint you plan to run carries.

The conclusion for sizing is practical. Two models of the same size can need different amounts of KV cache for the same German document, and a model with a European-focused tokenizer can fit more of your text into the same context. Count with the tokenizer of each candidate. We build AI servers for multilingual assistants; ask us to size one for your languages and models, and our team replies with a configuration.

Context length in words for each language

A context window is a token budget shared by the system prompt, the retrieved passages or documents, the conversation and the answer. Divided by the fertility, it becomes a word budget.

Our arithmetic: tokens ÷ mean fertility from arXiv 2605.24718, rounded. With the highest of the six tokenizers, German drops to 66,200 words in 131,072 tokens and Polish to 50,400.

For a RAG assistant this decides how many passages fit beside the question. With 8,192 tokens and a 1,000-token system prompt and answer reserve, an English context leaves room for about 5,800 words of retrieved text, a German one for about 4,100 and a Polish one for about 3,200, by the same arithmetic. Our article on RAG on company data covers chunk sizes and retrieval.

KV cache and users per GPU in German, French or Polish

The KV cache grows with every token a conversation holds, so the fertility multiplies directly into GPU memory. Our guide to long-context LLM hardware derives 320 KiB per token for Llama 3.3 70B with a 16-bit cache, 160 KiB with FP8, and 36 KiB for gpt-oss-120b with its 18 full-attention layers in 16-bit.

Our arithmetic: words × mean fertility (arXiv 2605.24718) × KV cache per token from our long-context guide; one conversation holding the document, prompt and answer not counted.

Users per card follow the same way. Our users-per-card rule takes 90 per cent of the memory the driver reports, less 3 GiB of overhead and the weights: on one RTX PRO 6000 Server Edition with 95.6 GiB, Llama 3.3 70B in FP8 at 67.7 GiB leaves 15.3 GiB for the cache, which our guide to how much VRAM an LLM needs sizes as 12 sessions of 8,192 tokens with an FP8 cache. Sized in words instead, conversations of 5,000 words fit 16 times in English (6,150 tokens each), 11 times in German (8,800), 8 times in Polish (11,250) and 6 times in Finnish (14,950), by our estimate.

The same ratio carries over to every configuration. A four-card server with RTX PRO 6000 Server Edition, 332.2 GiB by our rule, holds about 30 per cent fewer German conversations of a given word length than English ones, and about 45 per cent fewer Polish ones. Our guide to how many users an RTX PRO 6000 serves has the token-based figures to start from.

Worked example: long contracts in German and Polish

A legal or procurement team that puts whole contracts into the context shows the effect most clearly. Take Llama 3.3 70B in FP8 on a server with four RTX PRO 6000 Server Edition cards, split over the four cards with tensor parallelism. By our rule the four cards offer 332.2 GiB, and after the 67.7 GiB of weights about 264.5 GiB remain for the FP8 cache. A contract of 30,000 words, with the question and the answer on top, then takes:

Our estimate: 30,000 words × mean fertility (arXiv 2605.24718) × 160 KiB per token (Llama 3.3 70B, FP8 cache); 264.5 GiB of cache room on four RTX PRO 6000 Server Edition by our users-per-card rule; all within Llama 3.3 70B's stated 128K context.

Memory sets the upper limit here; how fast the server processes 50,000-token prompts on four cards without NVLink is not published, so plan a load test with your own documents. The comparison still holds: the same server serves about 30 per cent fewer German contract sessions than English ones, and a Polish contract needs about 80 per cent more cache than an English one of the same length. Our guide to RTX PRO 6000 without NVLink covers the four-card layouts.

We size AI servers from the models, languages and conversation lengths you plan; send us a sample of your documents and the number of users, and our team replies with a configuration.

Generation speed in words per second

Engines report generation speed in tokens per second, and users read words. At the same token rate, a German answer appears more slowly than an English one. At 40 tokens per second per user, for example, an English answer runs at about 32 words per second, a German one at about 23, a Polish one at about 18 and a Finnish one at about 13, if the generated text has the same fertility as the test text, which is our assumption.

The effect counts most in two places. A long answer in Polish takes about 80 per cent longer to finish than the same answer in English, which matters for agents and tools that wait for the whole output. And batch jobs, such as summarising an archive overnight, finish later in the same proportion; our guide to batch LLM inference on-premise converts published throughput into GPU-hours, and its output lengths in tokens grow by the fertility ratio for each language. Our article on LLM latency targets sets the token rates for chat, RAG and agents.

Prefill grows as well. A German prompt of 10,000 words is about 17,600 tokens to process before the first token of the answer, against about 12,300 in English, so the time to first token for long documents rises roughly in proportion.

Counting tokens on your own documents

Published fertility is a starting point. Your own count, made once on a sample, replaces it.

1. Pick a sample. Take 50 to 100 documents that represent what the assistant will read and write: contracts, tickets, manuals, e-mails, in every language your users work in.
2. Count the words the way the published figures do, split on whitespace, or with the word count your document system reports.
3. Count the tokens with the tokenizer of each candidate model, loaded from the files in its Hugging Face repository, or through the /tokenize endpoint that vLLM's online serving documentation lists for a running server.
4. Divide tokens by words per language and per model, and keep the highest value per language as your planning figure.
5. Add the fixed parts: the system prompt, the chat template and any tool definitions are tokens in every request, independent of the language of the documents.
6. Repeat on a model change, since a new model family can bring a new tokenizer.

Mixed-language requests are common in European companies: an English system prompt, German documents and a question in French. Count each part with the figure for its own language and add them up, and size the server for the language mix of the peak hour. Where one team works in Polish and another in English on the same assistant, the Polish sessions set the memory budget per conversation. For translation the model reads the source text in one language and writes the target text in another, so input and output follow different fertility figures; our translation guide counts the two separately.

With these figures, the server is sized in the same unit the engine uses. Our machine translation guide applies the same preprint to translation throughput, with a planning margin of 2.5 to 3 tokens per word for Polish, Czech or Hungarian targets.

Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up models and retrieval for multilingual teams on your own servers, and the token counts of your languages go into the sizing.

FAQ