Tokenizer Playground — drei Familien live im Vergleich

Warum überhaupt einen Tokenizer-Playground?

Wer mit Sprachmodellen arbeitet, stößt früher oder später auf eine Zahl, die wichtiger ist als die Wortzahl: die Token-Anzahl. Tokens sind die Einheiten, in denen Modelle Text wahrnehmen — meistens kleiner als ein Wort, aber größer als ein Buchstabe. Der Tokenizer Playground zerlegt deinen Text live in genau diese Einheiten und zeigt jeden Token als farbcodierte Kachel mit Token-ID, Byte-Länge und Byte-Offset. Hover über jeden Token, und du siehst genau, welcher Eintrag aus dem Vokabular hier passt.

Anders als ein klassischer Wortzähler beleuchtet ein Tokenizer den eigenen Algorithmus mit. Drei Familien sind im Playground vertreten: Byte-Pair-Encoding, WordPiece und Unigram. Sie sind die drei dominanten Schulen, aus denen alle heutigen mehrsprachigen Sprachmodelle ihre Tokenizer ableiten. Der Playground zeigt sie nicht als Black Box, sondern als nachvollziehbaren Schritt-für-Schritt-Algorithmus.

Drei Familien, drei Strategien — was unterscheidet sie?

BPE-Familie (Byte-Pair-Encoding) startet jeden Tokenisierungs-Lauf bei Einzelzeichen. Dann werden Paare nach einer trainierten Häufigkeits-Reihenfolge zusammengefügt, bis keine Regel mehr passt. Das Markenzeichen: ein Leerzeichen vor jedem Wort-Anfang wird als spezielles Zeichen (Ġ in der Anzeige) erhalten — das macht aus „the” und „ the” zwei verschiedene Tokens. Diese Familie ist die häufigste Wahl bei Decoder-only-Modellen für Textgenerierung. Algorithmus-Quelle: Sennrich, Haddow, Birch 2016.

WordPiece-Familie wählt von links das längste Sub-Wort aus, das im Vokabular passt. Folge-Stücke innerhalb desselben Worts bekommen das Continuation-Markenzeichen „##” — daraus wird play + ##ing. Sie kleinschreibt typischerweise vorher den Input. Diese Familie sieht man bei klassischen bidirektionalen Encoder-Modellen für Klassifikation und Verständnis. Konsequenz: dieselbe Wortform in unterschiedlicher Groß-/Kleinschreibung ergibt identische Tokens.

Unigram-Familie (SentencePiece-Style) behandelt die Tokenisierung als Optimierungsproblem. Jeder Vokabular-Eintrag hat eine log-Wahrscheinlichkeit; Viterbi findet die Segmentierung mit der höchsten Gesamtsumme. Wort-Anfänge tragen ein Unicode-Markenzeichen (▁). Diese Familie ist die Standardwahl mehrsprachiger Encoder-Decoder-Modelle und dort beliebt, wo Mischung aus lateinischen Skripten, asiatischen Schriften und Sonderzeichen die Regel ist. Algorithmus-Quelle: Kudo 2018.

Was zeigt mir die mehrsprachige Heatmap?

Der Heatmap-Tab nimmt einen identischen Inhalt — den klassischen Pangram „der schnelle braune Fuchs springt über den faulen Hund” — und übersetzt ihn in sechs Sprachen: Englisch, Deutsch, Französisch, Spanisch, Japanisch und Arabisch. Für jede Sprache zählt der Playground die Wörter (anhand einer Unicode-Wortgrenze) und die Tokens (anhand der aktuell gewählten Familie) und berechnet das Verhältnis Tokens pro Wort. Über 2 wird teuer; über 4 wird die Sprache strukturell benachteiligt.

Das Phänomen ist gut dokumentiert. Eine Studie aus 2023 hat gezeigt, dass dieselbe Übersetzung in 22 Sprachen 1,5- bis 14-fache Token-Unterschiede produziert — mit Englisch immer am günstigeren Ende. Die Heatmap im Playground zeigt diesen Effekt sofort: Englisch landet typischerweise bei 1,0–1,3 Tokens pro Wort, Deutsch wegen der Komposita bei 1,5–2,0, Japanisch wegen Wortgrenzen-Mehrdeutigkeit bei 2,5 und mehr. Sichtbar wird, warum mehrsprachige Anwendungen ein Kostenproblem haben, das bei reiner Wortzählung unsichtbar bliebe.

Wie zeigt der Algorithmus-Trace die Tokenisierung Schritt für Schritt?

Eine Black Box ist schwer zu lernen. Deswegen zeigt der Algorithmus-Schritte-Tab den vollständigen Ablauf der Tokenisierung auf deinem aktuellen Input. Bei BPE wird zunächst die Eingabe in einzelne Zeichen zerlegt. Dann wird in jedem Schritt das Paar mit dem höchsten Merge-Rang zusammengefügt und das Zwischen-Ergebnis angezeigt. Du siehst etwa: „merge ‘t’ + ‘h’ → ‘th’ (Regel #1)”, dann „merge ‘th’ + ‘e’ → ‘the’ (Regel #22)”, dann „kein weiterer Merge möglich — fertig”.

Bei WordPiece sieht jeder Schritt anders aus. Der Trace zeigt den linken Cursor und den Sub-Wort-Match: „passt ‘play’ (4 Zeichen)”, dann „passt ‘##ing’ (3 Zeichen)”. Wenn kein Sub-Wort gefunden wird, kommt „kein Match an Position N — [UNK]” und der Lauf endet. Bei Unigram zeigt der Trace den Viterbi-Backtrack: jede Position bekommt eine log-Wahrscheinlichkeit, der Pfad mit der höchsten Summe wird ausgewählt und in der Reihenfolge angezeigt, in der die Tokens auftreten.

Was bedeutet die Token-ID neben jedem Stück?

Jeder Tokenizer hat eine fixe Mapping-Tabelle: Token-String → Token-ID. Die ID ist die Zahl, die das Modell tatsächlich erhält — der String ist nur die menschenlesbare Form. Im Playground wird die ID neben jeder Token-Kachel angezeigt. Token-ID = -1 bedeutet: dieses Stück ist im mitgelieferten Sample-Vokabular nicht enthalten. Der Tokenizer fällt dann auf einzelne Zeichen zurück, was die Token-Anzahl in die Höhe treibt.

Das ist exakt das Out-of-Vocabulary-Verhalten echter Tokenizer in der Praxis. Sichtbar wird es bei seltenen Eigennamen, technischen Begriffen, fremdsprachigen Einsprengseln oder Emoji. Wer einen Prompt mit „Mädchen-Geburtsname Đorđević” testet, wird sehen, dass dieser eine Name 8–12 Tokens kostet — während ein häufiger englischer Vorname mit ein bis zwei Tokens auskommt.

Wozu der Drei-Familien-Vergleich?

Im Vergleichs-Tab läuft dein Input parallel durch alle drei Familien. Direkt darüber stehen drei Token-Counter und ein Δ-Wert — die Differenz zur effizientesten Familie. Das ist die Antwort auf eine wiederkehrende Frage in der Praxis: „Spar ich Tokens, wenn ich auf eine andere Familie wechsle?” Die Antwort hängt vom Input ab. Englischer Klartext ist bei allen drei Familien sehr ähnlich. Quellcode ist bei BPE deutlich kompakter, weil die Merge-Regeln häufige Code-Sequenzen lernen. CJK-Text ist bei Unigram (mit gutem Sentence-Piece-Vokabular) effizienter, weil dort multi-Charakter-Tokens für häufige Silben existieren.

Der Vergleich zeigt auch eine zweite Dimension: nicht nur die Anzahl, sondern auch die Grenzen-Setzung. Bei BPE bekommt jedes Wort einen Space-Marker als Anfang, bei WordPiece ein Continuation-##-Suffix für jedes Folge-Stück, bei Unigram ein Unicode-▁ als Wort-Marker. Diese drei Markierungen sehen unterschiedlich aus, kosten aber konzeptionell das Gleiche.

Was ist bewusst nicht im Playground?

Drei Funktionen sitzen außerhalb des Scopes. Erstens: kein Cost-Calculator mit Euro- oder Dollar-Preisen — die ändern sich häufig und sind Vendor-spezifisch. Zweitens: kein Chat-Template-Builder (System-Message + User-Message + Assistant-Tags). Verschiedene Modelle nutzen verschiedene Konventionen, und ein Template-Builder verwöhnt zu schnell zu einem Modell. Drittens: keine Vokabular-Uploads — das wäre ein Sicherheits-Risiko (manipulierte Vokabular-Files könnten unsichere Pieces enthalten).

Diese Lücken sind Absicht. Sie halten den Playground schlank, schnell und vendor-neutral. Wer eine exakte Token-Kostenschätzung für ein bestimmtes Modell braucht, nutzt dessen offiziellen Tokenizer. Wer den Algorithmus verstehen und drei Familien parallel vergleichen will — dafür ist der Playground gebaut.

Wie sieht es mit Privacy und DSGVO aus?

Dein Text bleibt im Browser-Speicher. Es gibt keinen Server, kein localStorage, keine Cookies, keine Analytics, kein Network-Request. Im Devtools-Network-Tab erscheint nach dem Laden der Seite nichts mehr. Schließe den Tab, und alles ist gelöscht — das ist Absicht. Auch der „Statistik kopieren”-Button setzt nur einen lokalen Clipboard-Aufruf ab, kein Netzwerk-Verkehr.

Aus DSGVO-Sicht werden keine personenbezogenen Daten im Sinne von Art. 4 verarbeitet, weil die Verarbeitung lokal auf deinem Gerät stattfindet. Selbst sensitive Prompts (Code-Snippets, persönliche Notizen, juristische Texte) bleiben im Tab. Diese Architektur macht den Playground in Enterprise-Umgebungen mit strenger Compliance einsetzbar.