Tokens pro Wort auf Deutsch, Französisch, Polnisch und in anderen EU-Sprachen: LLM-Server

Wie viele Tokens pro Wort europäische Sprachen ergeben

Die meisten LLM-Tokenizer zerlegen deutsche, französische oder polnische Texte in mehr Tokens pro Wort als englische. Ein Preprint vom Mai 2026, der sechs öffentliche Tokenizer, von Llama 3.3, Llama 4 Maverick, Qwen3, Gemma 2, DeepSeek V3 und GPT-4o, auf denselben Paralleltext angewendet hat, meldet im Mittel 1,23 Tokens pro Wort für Englisch, 1,52 für Französisch, 1,76 für Deutsch, 2,25 für Polnisch und 2,99 für Finnisch. Kontextfenster, KV-Cache, Nutzer pro GPU und Generierungs­geschwindigkeit werden alle in Tokens gezählt; ein deutscher Assistent braucht daher für dieselbe Zahl an Wörtern rund 40 Prozent mehr von allem als ein englischer, ein polnischer rund 80 Prozent mehr.

Die folgenden Werte sind veröffentlichte Zählungen; die Tokenizer haben wir nicht selbst ausgeführt. Wo wir sie in Dimensionierungswerte umrechnen, ist die Rechnung unsere eigene und als Schätzung gekennzeichnet. Unser Leitfaden zu offenen LLMs für europäische Sprachen zeigt, welche Modelle welche Sprachen nennen; dieser Artikel zeigt, was die Sprache an der Hardware ändert, wenn das Modell gewählt ist.

Veröffentlichte Werte für Tokens pro Wort nach Sprache

Der Preprint (arXiv 2605.24718, Mai 2026) hat die Fertilität, also die Zahl der Tokens pro durch Leerzeichen getrenntem Wort, für 25 europäische Sprachen auf SIB-200 gemessen, einem parallelen Datensatz zur Themenklassifikation, in dem jede Sprache denselben Inhalt trägt. Seine Tabelle 4 nennt den Mittelwert der sechs Tokenizer und den niedrigsten und höchsten Wert unter ihnen.

arXiv 2605.24718 (Mai 2026), Tabelle 4: mittlere Tokenizer-Fertilität über sechs Modelle (Llama 4 Maverick, Llama 3.3 70B, Qwen3 32B, Gemma 2 27B, GPT-4o, DeepSeek V3) auf dem Paralleltext SIB-200, gelesen am 24. Oktober 2026. „Zu Englisch“ ist unsere Division der Mittelwerte. Dieselbe Tabelle nennt Dänisch 1,87, Kroatisch 2,31, Slowenisch 2,28, Slowakisch 2,45, Estnisch 2,78, Litauisch 2,86, Lettisch 2,97 und Maltesisch 3,10.

Drei Muster fallen auf. Die romanischen Sprachen liegen am nächsten bei Englisch. Deutsch und die anderen germanischen Sprachen brauchen rund 35 bis 55 Prozent mehr Tokens pro Wort; nach unserer Lesart zählen lange deutsche Komposita als ein Wort und werden in mehrere Tokens zerlegt. Die slawischen, baltischen und finno-ugrischen Sprachen, Griechisch und Maltesisch brauchen etwa das 1,8- bis 2,5-Fache des englischen Werts, wobei Griechisch die größte Spanne zwischen den Tokenizern zeigt.

Für alle diese Zahlen gelten zwei Vorbehalte. Es sind die Messungen eines Preprints an kurzen Sätzen allgemeinen Inhalts, und Ihre Verträge, Tickets oder Handbücher haben ein anderes Vokabular. Und die Fertilität gilt pro Wort derselben Sprache: Eine deutsche Übersetzung hat nicht dieselbe Zahl an Wörtern wie ihr englisches Original, also nehmen Sie den Wert der Sprache, aus der Ihre Wortzahl stammt.

Tokenizer-Fertilität: warum es auf den Tokenizer des Modells ankommt

In der Spalte mit der Spanne zeigt sich der Tokenizer. Ein Vokabular mit mehr nicht englischen Teilen zerlegt europäische Wörter seltener, und die Größe allein entscheidet nicht: In der Tabelle unten ergeben die 128.000 Einträge von EuroLLM auf FLORES-200 2,21 Tokens pro Wort, die 128.256 von Llama 3.1 dagegen 2,78. Eine Tokenizer-Karte des EU-geförderten Projekts OpenEuroLLM veröffentlicht einen Vergleich auf einer eigenen Testsammlung aus mehreren Bereichen, ebenfalls in Tokens pro durch Leerzeichen getrenntem Wort, mit der Vokabulargröße jedes Tokenizers.

Tokenizer-Karte openeurollm/tokenizer-256k-v2 von OpenEuroLLM auf Hugging Face, Tabelle nach Bereichen, gelesen am 24. Oktober 2026: FLORES-200 ist der Mittelwert über 36 Sprachen paralleler Sätze, PDFs eine Dokumentsammlung in fünf Sprachen, Code Python-Dateien. Der eigene 256k-Tokenizer der Karte erreicht 1,79 auf FLORES-200. Die config.json von gpt-oss-120b nennt eine vocab_size von 201.088.

Im mehrsprachigen Mittel von FLORES-200 erzeugen die Tokenizer von Llama 3.1 und Qwen3 rund ein Drittel mehr Tokens pro Wort als die von gpt-oss und Gemma 3. Auf der PDF-Sammlung in fünf Sprachen schließt sich der Abstand fast: Llama 3.1 erreicht 2,18, hinter gpt-oss mit 2,01, was zeigt, wie viel der Text selbst ausmacht. Die Werte gehören zum Tokenizer, nicht zur Modellgröße; prüfen Sie also, welchen Tokenizer der Checkpoint mitbringt, den Sie betreiben wollen.

Für die Dimensionierung heißt das konkret: Zwei gleich große Modelle können für dasselbe deutsche Dokument unterschiedlich viel KV-Cache brauchen, und ein Modell mit einem auf Europa ausgerichteten Tokenizer bringt mehr Ihres Textes in denselben Kontext. Zählen Sie mit dem Tokenizer jedes Kandidaten. Wir bauen KI-Server für mehrsprachige Assistenten; lassen Sie uns einen für Ihre Sprachen und Modelle auslegen, und unser Team antwortet mit einer Konfiguration.

Kontextlänge in Wörtern je Sprache

Ein Kontextfenster ist ein Token-Budget, das sich Systemprompt, abgerufene Passagen oder Dokumente, Gesprächsverlauf und Antwort teilen. Geteilt durch die Fertilität wird daraus ein Wort-Budget.

Unsere Rechnung: Tokens ÷ mittlere Fertilität aus arXiv 2605.24718, gerundet. Mit dem ungünstigsten der sechs Tokenizer sinkt Deutsch auf 66.200 Wörter in 131.072 Tokens und Polnisch auf 50.400.

Für einen RAG-Assistenten entscheidet das, wie viele Passagen neben die Frage passen. Bei 8.192 Tokens und einer Reserve von 1.000 Tokens für Systemprompt und Antwort bleibt auf Englisch Platz für rund 5.800 Wörter abgerufenen Text, auf Deutsch für rund 4.100 und auf Polnisch für rund 3.200, nach derselben Rechnung. Unser Artikel zu RAG auf Unternehmensdaten behandelt Chunk-Größen und Retrieval.

KV-Cache und Nutzer pro GPU auf Deutsch, Französisch oder Polnisch

Der KV-Cache wächst mit jedem Token, das ein Gespräch hält, also geht die Fertilität direkt in den GPU-Speicher ein. Unser Leitfaden zur Hardware für lange Kontexte leitet für Llama 3.3 70B 320 KiB pro Token mit 16-Bit-Cache ab, 160 KiB mit FP8, und für gpt-oss-120b mit seinen 18 Schichten mit voller Attention 36 KiB in 16 Bit.

Unsere Rechnung: Wörter × mittlere Fertilität (arXiv 2605.24718) × KV-Cache pro Token aus unserem Leitfaden zu langen Kontexten; ein Gespräch, das das Dokument hält, ohne Prompt und Antwort.

Ebenso verhält es sich mit den Nutzern pro Karte. Unsere Nutzer-pro-Karte-Regel nimmt 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB Overhead und der Gewichte: Auf einer RTX PRO 6000 Server Edition mit 95,6 GiB lässt Llama 3.3 70B in FP8 mit 67,7 GiB rund 15,3 GiB für den Cache, die unser Leitfaden Wie viel VRAM ein LLM braucht als 12 Sitzungen zu 8.192 Tokens mit FP8-Cache rechnet. In Wörtern gerechnet passen Gespräche von 5.000 Wörtern 16-mal auf Englisch (je 6.150 Tokens), 11-mal auf Deutsch (8.800), 8-mal auf Polnisch (11.250) und 6-mal auf Finnisch (14.950), nach unserer Schätzung.

Das Verhältnis überträgt sich auf jede Konfiguration. Ein Server mit vier RTX PRO 6000 Server Edition, nach unserer Regel 332,2 GiB, hält rund 30 Prozent weniger deutsche Gespräche einer bestimmten Wortlänge als englische und rund 45 Prozent weniger polnische. Unser Leitfaden dazu, wie viele Nutzer eine RTX PRO 6000 bedient, hat die Werte in Tokens als Ausgangspunkt.

Rechenbeispiel: lange Verträge auf Deutsch und Polnisch

Ein Rechts- oder Einkaufsteam, das ganze Verträge in den Kontext gibt, zeigt den Effekt am deutlichsten. Nehmen wir Llama 3.3 70B in FP8 auf einem Server mit vier RTX PRO 6000 Server Edition, per Tensor-Parallelität über die vier Karten verteilt. Nach unserer Regel bieten die vier Karten 332,2 GiB, und nach den 67,7 GiB Gewichten bleiben rund 264,5 GiB für den FP8-Cache. Ein Vertrag mit 30.000 Wörtern, dazu Frage und Antwort, braucht dann:

Unsere Schätzung: 30.000 Wörter × mittlere Fertilität (arXiv 2605.24718) × 160 KiB pro Token (Llama 3.3 70B, FP8-Cache); 264,5 GiB Cache-Raum auf vier RTX PRO 6000 Server Edition nach unserer Nutzer-pro-Karte-Regel; alles innerhalb des angegebenen 128K-Kontexts von Llama 3.3 70B.

Der Speicher setzt hier die Obergrenze; wie schnell der Server Prompts mit 50.000 Tokens auf vier Karten ohne NVLink verarbeitet, ist nicht veröffentlicht, planen Sie also einen Lasttest mit Ihren eigenen Dokumenten. Der Vergleich bleibt gültig: Derselbe Server bedient rund 30 Prozent weniger deutsche Vertragssitzungen als englische, und ein polnischer Vertrag braucht rund 80 Prozent mehr Cache als ein englischer gleicher Länge. Unser Leitfaden zur RTX PRO 6000 ohne NVLink behandelt die Aufteilungen auf vier Karten.

Wir dimensionieren KI-Server nach den geplanten Modellen, Sprachen und Gesprächslängen; schicken Sie uns eine Stichprobe Ihrer Dokumente und die Zahl der Nutzer, und unser Team antwortet mit einer Konfiguration.

Generierungs­geschwindigkeit in Wörtern pro Sekunde

Engines melden die Geschwindigkeit in Tokens pro Sekunde, und Nutzer lesen Wörter. Bei gleicher Token-Rate erscheint eine deutsche Antwort langsamer als eine englische. Bei 40 Tokens pro Sekunde und Nutzer etwa läuft eine englische Antwort mit rund 32 Wörtern pro Sekunde, eine deutsche mit rund 23, eine polnische mit rund 18 und eine finnische mit rund 13, sofern der erzeugte Text dieselbe Fertilität hat wie der Testtext, was unsere Annahme ist.

Der Effekt macht sich vor allem an zwei Stellen bemerkbar. Eine lange Antwort auf Polnisch braucht rund 80 Prozent länger als dieselbe Antwort auf Englisch, was für Agenten und Werkzeuge wichtig ist, die auf die ganze Ausgabe warten. Und Batch-Aufträge, etwa die nächtliche Zusammenfassung eines Archivs, sind im selben Verhältnis später fertig; unser Leitfaden zur Batch-Inferenz on-premise rechnet veröffentlichten Durchsatz in GPU-Stunden um, und seine Ausgabelängen in Tokens wachsen mit dem Fertilitätsverhältnis jeder Sprache. Unser Artikel zu Latenzzielen für LLMs legt die Token-Raten für Chat, RAG und Agenten fest.

Auch der Prefill wächst. Ein deutscher Prompt mit 10.000 Wörtern ergibt rund 17.600 Tokens, die vor dem ersten Token der Antwort verarbeitet werden, gegenüber rund 12.300 auf Englisch; die Zeit bis zum ersten Token steigt bei langen Dokumenten also ungefähr im selben Verhältnis.

Tokens an den eigenen Dokumenten zählen

Die veröffentlichte Fertilität ist ein Ausgangspunkt. Ihre eigene Zählung, einmal an einer Stichprobe gemacht, ersetzt sie.

1. Stichprobe wählen. Nehmen Sie 50 bis 100 Dokumente, die zeigen, was der Assistent lesen und schreiben wird: Verträge, Tickets, Handbücher, E-Mails, in jeder Sprache, in der Ihre Nutzer arbeiten.
2. Wörter zählen, so wie die veröffentlichten Werte es tun, getrennt an Leerzeichen, oder mit der Wortzahl Ihres Dokumentensystems.
3. Tokens zählen mit dem Tokenizer jedes Kandidaten, geladen aus den Dateien seines Hugging-Face-Repositorys, oder über den Endpunkt /tokenize, den die Dokumentation von vLLM für einen laufenden Server aufführt.
4. Teilen Sie Tokens durch Wörter je Sprache und Modell, und nehmen Sie den höchsten Wert je Sprache als Planungswert.
5. Feste Anteile addieren: Systemprompt, Chat-Template und Tool-Definitionen sind in jeder Anfrage Tokens, unabhängig von der Sprache der Dokumente.
6. Bei einem Modellwechsel wiederholen, denn eine neue Modellfamilie kann einen neuen Tokenizer mitbringen.

Gemischtsprachige Anfragen sind in europäischen Unternehmen üblich: ein englischer Systemprompt, deutsche Dokumente und eine Frage auf Französisch. Zählen Sie jeden Teil mit dem Wert seiner Sprache, addieren Sie, und dimensionieren Sie den Server für die Sprachmischung der Spitzenstunde. Arbeitet ein Team auf Polnisch und ein anderes auf Englisch mit demselben Assistenten, setzen die polnischen Sitzungen das Speicherbudget pro Gespräch. Bei Übersetzungen liest das Modell den Ausgangstext in einer Sprache und schreibt den Zieltext in einer anderen, also folgen Eingabe und Ausgabe unterschiedlichen Fertilitätswerten; unser Übersetzungsleitfaden zählt beide getrennt.

Mit diesen Werten wird der Server in derselben Einheit dimensioniert, die die Engine verwendet. Unser Leitfaden zur maschinellen Übersetzung wendet denselben Preprint auf den Übersetzungsdurchsatz an, mit einer Planungsreserve von 2,5 bis 3 Tokens pro Wort für polnische, tschechische oder ungarische Zieltexte.

Unser Service Private AI/ML richtet mit unserem Engineering-Partner Vixen.UNO Modelle und Retrieval für mehrsprachige Teams auf Ihren eigenen Servern ein, und die Token-Zahlen Ihrer Sprachen gehen in die Dimensionierung ein.

FAQ