Ein Sprachmodell erhält einen Satz wie:
Wie funktioniert eigentlich eine WordPress-Website?
Für uns Menschen besteht dieser Satz aus Wörtern.
Ein Sprachmodell verarbeitet ihn jedoch nicht zwangsläufig als:
Wie
funktioniert
eigentlich
eine
WordPress-Website
Stattdessen wird der Text zunächst in kleinere Verarbeitungseinheiten zerlegt.
Diese Einheiten heißen Tokens.
Ein Token kann ein vollständiges Wort sein.
Es kann aber genauso gut:
ein Wortteil,
eine Zahl,
ein Satzzeichen,
ein Leerzeichen zusammen mit einem Wortbestandteil
oder eine andere Zeichenfolge
repräsentieren.
Erst nachdem der Text in Tokens zerlegt wurde, kann das eigentliche Sprachmodell damit arbeiten.
Vereinfacht:
Text
↓
Tokenizer
↓
Tokens
↓
Sprachmodell
↓
neue Tokens
↓
Text
Tokens bilden damit die Verbindung zwischen menschlicher Sprache und der mathematischen Verarbeitung innerhalb eines Sprachmodells.
Ein Token ist nicht dasselbe wie ein Wort
Das ist die wichtigste Grundlage.
Nehmen wir den einfachen Satz:
Der Hund schläft.
Ein bestimmter Tokenizer könnte daraus möglicherweise Einheiten bilden wie:
Der
Hund
schläft
.
Ein anderer Tokenizer könnte:
Der
Hund
schlä
ft
.
erzeugen.
Beides wäre technisch möglich.
Die tatsächliche Zerlegung hängt vom jeweiligen Modell beziehungsweise dem dazugehörigen Tokenizer ab.
Deshalb gibt es keine universelle Regel:
Ein Wort entspricht einem Token.
Das stimmt nur manchmal.
Manche Wörter bestehen aus mehreren Tokens
Besonders häufig passiert das bei:
langen Wörtern,
ungewöhnlichen Begriffen,
Fachausdrücken,
Eigennamen,
seltenen Schreibweisen.
Ein deutsches Wort wie:
Donaudampfschifffahrtsgesellschaft
wird ein Sprachmodell normalerweise nicht zwingend als eine einzige Einheit behandeln.
Es könnte daraus mehrere wiederverwendbare Bestandteile erzeugen.
Zum Beispiel schematisch:
Donau
dampf
schiff
fahrts
gesellschaft
Die reale Zerlegung kann anders aussehen.
Das Prinzip ist jedoch dasselbe:
Der Tokenizer versucht sinnvolle und häufig vorkommende Zeichenfolgen wiederzuverwenden.
Warum arbeiten Sprachmodelle überhaupt mit Tokens?
Man könnte zunächst fragen:
Warum verarbeitet ein Modell nicht einfach jedes Wort als eigene Einheit?
Das klingt schließlich viel natürlicher.
Das Problem beginnt bei der enormen Anzahl möglicher Wörter.
Eine Sprache besitzt:
Grundformen,
Mehrzahlformen,
Beugungen,
Zusammensetzungen,
Eigennamen,
Fachbegriffe,
Abkürzungen,
neue Wörter.
Dazu kommen viele Sprachen.
Programmiercode.
Zahlen.
URLs.
Emojis.
Schreibfehler.
Ein Sprachmodell müsste eine gigantische Liste möglicher vollständiger Wörter kennen.
Wörter können jederzeit neu entstehen
Stell dir vor, jemand erfindet den Begriff:
Superhyperwordpressoptimierungsmaschine
Ein Mensch kann das Wort trotzdem teilweise verstehen.
Wir erkennen bekannte Bestandteile:
Super.
Hyper.
WordPress.
Optimierung.
Maschine.
Ein Tokenizer kann ähnlich vorgehen.
Auch wenn das vollständige Wort niemals im Training vorkam, lassen sich bekannte Zeichenfolgen kombinieren.
Das macht das System flexibler.
Die andere Extremvariante wären einzelne Zeichen
Man könnte Sprache auch vollständig in einzelne Buchstaben zerlegen.
Zum Beispiel:
H
u
n
d
Dann könnte jedes denkbare Wort dargestellt werden.
Das Problem:
Ein Text würde aus enorm vielen einzelnen Einheiten bestehen.
Das Modell müsste sehr lange Sequenzen verarbeiten.
Der Satz:
Der Hund schläft.
würde aus vielen Einzelzeichen bestehen, obwohl die Wörter selbst bekannte Strukturen besitzen.
Das wäre ineffizient.
Tokens sind deshalb ein Kompromiss
Ein modernes Tokenisierungssystem versucht vereinfacht einen Mittelweg:
nicht jedes komplette Wort
aber auch nicht zwingend:
jedes einzelne Zeichen
sondern:
häufige sinnvolle Zeichenfolgen
Dadurch kann Sprache relativ kompakt dargestellt werden und trotzdem mit unbekannten Wörtern umgehen.
Was macht ein Tokenizer?
Der Tokenizer ist die Komponente, die Text in Tokens zerlegt.
Aus:
Ich betreibe eine WordPress-Seite.
entsteht intern beispielsweise schematisch:
[Ich]
[ betreibe]
[ eine]
[ Word]
[Press]
[-]
[Seite]
[.]
Die tatsächliche Tokenisierung hängt vom Modell ab.
Anschließend erhält jedes Token eine numerische Kennung.
Zum Beispiel rein schematisch:
"Ich" → 1843
" betreibe" → 28197
" eine" → 731
" Word" → 9421
"Press" → 6527
Das Modell arbeitet anschließend nicht direkt mit sichtbaren Buchstaben.
Es arbeitet mit numerischen Repräsentationen dieser Tokenfolge.
Token und Token-ID sind nicht dasselbe
Ein Token ist die Text- beziehungsweise Symboleinheit.
Die Token-ID ist ihre Nummer im Vokabular des Modells.
Beispielsweise:
Token:
"WordPress"
Token-ID:
12345
Diese Zahl besitzt nicht automatisch eine semantische Bedeutung.
Token 12.345 ist nicht „mehr WordPress“ als Token 12.344.
Die ID sagt lediglich:
Verwende den Eintrag Nummer 12.345 aus dem Tokenvokabular.
Erst weitere mathematische Repräsentationen des Modells bilden Bedeutungsbeziehungen ab.
Was ist das Token-Vokabular?
Ein Tokenizer besitzt eine definierte Menge möglicher Tokens.
Dieses Vokabular kann beispielsweise enthalten:
häufige Wörter,
Wortteile,
Zeichen,
Sonderzeichen,
Codebestandteile.
Das Vokabular wird während der Entwicklung eines Modells beziehungsweise seiner Tokenisierung festgelegt.
Sehr häufig vorkommende Zeichenfolgen können als eigene Tokens vertreten sein.
Seltene Kombinationen werden aus kleineren Bestandteilen zusammengesetzt.
Häufige Wörter können dadurch sehr effizient sein
Ein sehr häufiges Wort wie:
und
kann möglicherweise ein einzelnes Token sein.
Ein ungewöhnlicher Fachbegriff könnte aus mehreren Tokens bestehen.
Das bedeutet:
Zwei Texte mit derselben Wortzahl können vollkommen unterschiedliche Tokenzahlen besitzen.
1.000 Wörter sind nicht automatisch 1.000 Tokens
Das ist besonders wichtig, wenn Anbieter Modellgrenzen oder Kosten in Tokens angeben.
Ein Text mit:
1.000 Wörtern
kann vielleicht:
1.300 Tokens
haben.
Ein anderer Text gleicher Wortzahl vielleicht:
1.700 Tokens
oder mehr.
Eine allgemeingültige Umrechnung gibt es nicht.
Die tatsächliche Zahl hängt unter anderem ab von:
Sprache,
Wortwahl,
Satzzeichen,
Formatierung,
Code,
verwendetem Tokenizer.
Deshalb sind Faustregeln nur Näherungen
Man findet häufig Aussagen wie:
Ein Token entspricht ungefähr drei Viertel eines englischen Wortes.
Solche Faustregeln können zur groben Orientierung dienen.
Für konkrete Berechnungen sollte man sie aber nicht als feste mathematische Beziehung betrachten.
Die korrekte Tokenzahl entsteht erst durch den Tokenizer des tatsächlich verwendeten Modells.
Unterschiedliche Modelle können denselben Text unterschiedlich zerlegen
Ein besonders wichtiger Punkt:
Tokenisierung ist modellabhängig.
Nehmen wir:
WordPress-Performance
Modell A könnte daraus bilden:
Word
Press
-
Performance
Modell B vielleicht:
WordPress
-
Performance
Modell C:
Word
Press
-
Per
formance
Dadurch besitzt derselbe Text bei verschiedenen Modellen unterschiedliche Tokenzahlen.
Das ist einer der Gründe, warum Tokenkosten verschiedener Modelle nicht ausschließlich anhand der Textlänge verglichen werden sollten.
Warum unterscheidet sich die Tokenisierung?
Tokenizer werden anhand unterschiedlicher:
Trainingsdaten,
Algorithmen,
Vokabulargrößen,
Sprachmischungen
entwickelt.
Ein Modell, das sehr viele deutsche Texte berücksichtigt, kann bestimmte deutsche Wortbestandteile effizienter repräsentieren als ein anderes.
Ein stark auf Programmcode abgestimmtes Modell kann häufige Codestrukturen besonders günstig tokenisieren.
Die Tokenisierung spiegelt damit teilweise wider, welche Arten von Text für ein Modell bei seiner Entwicklung besonders wichtig waren.
Deutsche Sprache kann tokenintensiv sein
Deutsch besitzt viele zusammengesetzte Wörter.
Zum Beispiel:
Datenschutzgrundverordnung
oder:
Suchmaschinenoptimierung
Solche Wörter können in mehrere Tokens zerfallen.
Das bedeutet nicht automatisch, dass Sprachmodelle schlecht Deutsch können.
Es bedeutet lediglich, dass derselbe Informationsgehalt je nach Sprache und Tokenizer unterschiedlich viele Verarbeitungseinheiten benötigen kann.
Kürzer formulieren kann Token sparen – muss aber nicht immer sinnvoll sein
Man könnte theoretisch Texte extrem verkürzen, um Tokens zu sparen.
Beispielsweise:
Analysiere Text. Ausgabe JSON. Keine Erklärung.
statt:
Bitte analysiere den folgenden Text und gib mir das Ergebnis ausschließlich als JSON-Datei zurück. Zusätzliche Erklärungen benötige ich nicht.
Das kann weniger Tokens verbrauchen.
Aber:
Ein kürzerer Prompt ist nicht automatisch besser.
Wenn wichtige Anweisungen fehlen, können Fehler entstehen.
Tokenoptimierung sollte nie wichtiger werden als klare Kommunikation.
Leerzeichen können Teil eines Tokens sein
Das wirkt zunächst ungewöhnlich.
Viele Tokenizer behandeln häufige Kombinationen aus:
Leerzeichen + Wort
als gemeinsame Einheit.
Zum Beispiel vereinfacht:
" Hund"
statt:
" "
+
"Hund"
Das kann die Verarbeitung natürlicher Sprache effizienter machen.
Deshalb kann derselbe sichtbare Begriff an:
Satzanfang
und
innerhalb eines Satzes
technisch unterschiedlich tokenisiert werden.
Groß- und Kleinschreibung kann einen Unterschied machen
Beispielsweise:
WordPress
und:
wordpress
können unterschiedliche Tokenfolgen erzeugen.
Dasselbe gilt für:
SERVER
Server
server
Ob und wie stark das passiert, hängt wieder vom verwendeten Tokenizer ab.
Damit kann sogar reine Schreibweise Einfluss auf die Tokenzahl besitzen.
Satzzeichen sind ebenfalls Tokens oder Tokenbestandteile
Ein Satz wie:
Hallo!
kann beispielsweise aus:
Hallo
!
bestehen.
Oder die Kombination könnte anders codiert sein.
Kommas, Punkte, Klammern und andere Symbole gehören zum Sprachmuster.
Das Modell muss sie deshalb ebenfalls repräsentieren.
Das ist besonders wichtig bei:
Programmcode,
JSON,
Markdown,
mathematischen Ausdrücken.
Programmcode kann sehr tokenintensiv sein
Code enthält zahlreiche:
Sonderzeichen,
Variablennamen,
Einrückungen,
Klammern,
Operatoren,
Dateipfade.
Zum Beispiel:
if ($user->is_logged_in() && $user->can('edit_posts')) {
update_post_meta($id, '_status', 'approved');
}
Für einen Menschen sind das wenige Zeilen.
Für einen Tokenizer kann daraus eine relativ große Zahl einzelner Einheiten entstehen.
Deshalb kann das Arbeiten mit großen Codebasen sehr viel Kontext verbrauchen.
Lange Variablennamen können mehrere Tokens ergeben
Zum Beispiel:
calculate_customer_lifetime_value
kann in verschiedene Wortbestandteile zerlegt werden.
Das ist grundsätzlich kein Problem.
Aber tausende Zeilen solchen Codes ergeben entsprechend viele Tokens.
Deshalb spielt Kontextmanagement bei KI-gestützter Softwareentwicklung eine wichtige Rolle.
JSON kann ebenfalls zusätzliche Tokens erzeugen
Nehmen wir:
{
"name": "Anna",
"age": 42
}
Der eigentliche Informationsgehalt ist klein.
Trotzdem müssen verarbeitet werden:
geschweifte Klammern,
Anführungszeichen,
Schlüssel,
Doppelpunkt,
Komma,
Zahlen.
Struktur hat also ebenfalls einen Tokenpreis.
Das bedeutet nicht, dass JSON vermieden werden sollte.
Strukturierte Ausgaben sind für Automatisierungen häufig enorm wertvoll.
Markdown kostet ebenfalls Tokens
Überschriften:
## Überschrift
Listen:
- Punkt
Links:
[Text](URL)
enthalten zusätzliche Zeichen.
Diese werden ebenfalls verarbeitet.
Bei einem einzelnen Artikel spielt das kaum eine Rolle.
Bei hunderttausenden automatisierten Anfragen können kleine Unterschiede relevant werden.
URLs können erstaunlich viele Tokens benötigen
Eine kurze Domain:
casiopeya.de
ist relativ kompakt.
Eine sehr lange URL wie:
https://example.com/category/product?id=372819&tracking=abc123
kann in viele Tokenbestandteile zerfallen.
Das ist besonders relevant, wenn große Mengen:
URLs,
Logs,
Trackingparameter
in einen Modellkontext gegeben werden.
Manchmal ist es sinnvoller, Informationen vor der KI-Verarbeitung zu bereinigen.
Tokens sind die eigentliche Größenordnung des Kontextfensters
Wenn ein Modell ein Kontextfenster von beispielsweise:
128.000 Tokens
besitzt, bedeutet das nicht:
128.000 Wörter
Es bedeutet:
Eingabe und relevante Kontextbestandteile dürfen zusammen innerhalb dieser Tokenkapazität liegen.
Je nach System kann dabei auch die geplante beziehungsweise bereits erzeugte Ausgabe Teil derselben Begrenzung sein.
Darum ist die Tokenzahl praktisch wichtiger als Seitenzahl oder Wortzahl.
Was befindet sich alles im Kontext?
Ein typischer KI-Chat kann wesentlich mehr enthalten als deine letzte sichtbare Frage.
Zum Beispiel:
Systemanweisungen
+
Entwickleranweisungen
+
bisheriger Gesprächsverlauf
+
Dokumente
+
Tool-Ergebnisse
+
aktuelle Nachricht
+
Antwort
All diese Informationen können Tokens verbrauchen.
Deshalb ist eine kurze Nutzerfrage nicht zwangsläufig eine kurze Modellanfrage.
Lange Gespräche werden dadurch immer größer
Angenommen, du führst einen langen Chat.
Nachricht 1.
Antwort 1.
Nachricht 2.
Antwort 2.
Und so weiter.
Wenn der vollständige Verlauf jedes Mal erneut bereitgestellt wird, wächst die Menge der zu verarbeitenden Tokens.
Vereinfacht:
Runde 1:
Frage
↓
Antwort
Runde 2:
Frage 1
Antwort 1
Frage 2
↓
Antwort 2
Runde 3:
Frage 1
Antwort 1
Frage 2
Antwort 2
Frage 3
↓
Antwort 3
Das kann Auswirkungen auf:
Geschwindigkeit,
Kosten,
Kontextgrenzen
haben.
Deshalb werden lange Gespräche manchmal zusammengefasst
Ein KI-System kann ältere Informationen beispielsweise komprimieren.
Statt 30.000 Tokens Gesprächsverlauf erneut mitzugeben, entsteht eine Zusammenfassung von vielleicht:
2.000 Tokens
Darin bleiben die wichtigsten Informationen erhalten.
Dann könnte der Kontext aussehen:
Zusammenfassung alter Verlauf
+
letzte Nachrichten vollständig
+
aktuelle Frage
Das spart Platz.
Der Nachteil:
Bei jeder Zusammenfassung können Details verloren gehen.
Tokens erklären, warum KI sich manchmal an Details nicht erinnert
Ein Nutzer sagt ganz am Anfang eines riesigen Chats:
Meine Website verwendet PHP-Version X.
Sehr viel später fragt er danach.
Wenn die Information:
nicht mehr im aktuellen Kontext,
nicht in einer gespeicherten Erinnerung
und nicht anderweitig verfügbar
ist, kann das Modell sie nicht zuverlässig berücksichtigen.
Das ist kein menschliches Vergessen.
Es ist eine Eigenschaft des Kontextmanagements.
Tokenlimits setzen die Größe verarbeitbarer Dokumente
Ein PDF besitzt beispielsweise:
300 Seiten.
Das Dokument enthält vielleicht weit mehr Tokens, als ein Modell gleichzeitig aufnehmen kann.
Dann muss das System entscheiden:
Welche Teile werden benötigt?
Mögliche Strategien:
Dokument
↓
in Abschnitte teilen
↓
relevante Abschnitte suchen
↓
nur diese an Modell geben
oder:
Dokument
↓
Abschnitte zusammenfassen
↓
Zusammenfassungen verbinden
Diese Techniken werden für RAG und Dokumentenanalyse wichtig.
Ein großes Kontextfenster ist deshalb sehr nützlich
Mehr Kontext ermöglicht:
längere Dokumente,
mehr Gesprächsverlauf,
größere Codeausschnitte,
mehr Quellen.
Das kann die Qualität komplexer Aufgaben deutlich verbessern.
Aber:
Großes Kontextfenster bedeutet nicht automatisch perfekte Nutzung jedes einzelnen Tokens.
Ein Modell kann auch in einem riesigen Kontext wichtige Informationen übersehen oder falsch gewichten.
Kontextkapazität und Kontextqualität sind verschiedene Dinge
Stell dir einen Schreibtisch vor.
Ein kleiner Schreibtisch:
wenige Dokumente
Ein riesiger Schreibtisch:
500 Dokumente
Der zweite bietet mehr Platz.
Aber wenn alle 500 Dokumente unsortiert herumliegen, wird die Arbeit nicht automatisch leichter.
Dasselbe gilt für Sprachmodelle.
Ein guter KI-Workflow versucht nicht nur:
möglichst viel Kontext.
Sondern:
möglichst relevanten Kontext.
Tokens besitzen auch wirtschaftliche Bedeutung
Viele KI-APIs berechnen Nutzung anhand der verarbeiteten Tokenmenge.
Dabei kann beispielsweise unterschieden werden zwischen:
Eingabetokens
und
Ausgabetokens.
Ein einfaches Modell:
Kosten
=
Input-Tokens
+
Output-Tokens
mit unterschiedlichen Preisen pro Tokenkategorie.
Die genauen Tarife hängen vom jeweiligen Anbieter und Modell ab und können sich ändern.
Das Grundprinzip bleibt jedoch wichtig.
Ein langer Systemprompt wird immer wieder teuer
Angenommen, ein automatisierter Workflow verwendet einen Systemprompt mit:
5.000 Tokens
und läuft:
100.000-mal pro Monat
Dann werden allein dadurch theoretisch:
500.000.000 Input-Tokens
verarbeitet.
Kleine Verbesserungen können bei großer Skalierung deshalb erhebliche Auswirkungen besitzen.
Bei zehn Anfragen spielt Optimierung kaum eine Rolle
Man sollte trotzdem nicht in Token-Paranoia verfallen.
Wenn du privat fünf Fragen am Tag stellst, ist es meist unsinnig, jeden Satz aggressiv zu verkürzen.
Zeit und Qualität sind dann wichtiger.
Tokenoptimierung wird besonders relevant bei:
großen automatisierten Workflows,
sehr langen Dokumenten,
vielen Nutzern,
lokalen Modellen mit begrenzter Hardware.
Ausgabetokens sind ebenfalls relevant
Wenn du sagst:
Schreib mir einen ausführlichen Artikel.
muss das Modell viele Tokens erzeugen.
Die Ausgabe entsteht Token für Token.
Deshalb dauert ein sehr langer Text länger als:
Ja.
Die reine Rechenzeit steigt mit der Ausgabelänge.
Lange Antworten kosten nicht nur mehr
Sie können auch:
mehr Fehler enthalten,
Wiederholungen entwickeln,
vom Thema abschweifen.
Deshalb ist die gewünschte Ausgabelänge eine echte technische und redaktionelle Entscheidung.
Nicht:
Immer maximal lang.
Sondern:
So lang, wie die Aufgabe es benötigt.
Tokens erklären die sichtbare Schreibgeschwindigkeit einer KI
Bei vielen Sprachmodellen sieht man die Antwort scheinbar Wort für Wort erscheinen.
Tatsächlich entsteht sie tokenweise.
Ein System produziert beispielsweise:
Token 1
Token 2
Token 3
...
Die Oberfläche verbindet diese Tokens anschließend wieder zu lesbarem Text.
Daher wirkt es, als würde das Modell in Echtzeit schreiben.
Was bedeutet Tokens pro Sekunde?
Bei lokalen Sprachmodellen ist eine häufig verwendete Leistungskennzahl:
Tokens pro Sekunde
kurz beispielsweise:
25 tok/s
Das bedeutet, dass ungefähr 25 neue Tokens pro Sekunde generiert werden.
Das sind nicht zwingend 25 Wörter.
Ein Wort kann:
ein Token,
mehrere Tokens
oder Teil eines größeren Tokens
sein.
Trotzdem eignet sich die Kennzahl gut, um Generationsgeschwindigkeit grob zu vergleichen.
10 Tokens pro Sekunde können durchaus schnell wirken
Wenn ein durchschnittliches Wort ungefähr etwas mehr als ein Token benötigt, können bereits:
10 Tokens/Sekunde
eine angenehm lesbare Ausgabe ergeben.
Bei:
50 Tokens/Sekunde
entsteht Text schneller, als ein Mensch ihn normalerweise lesen kann.
Für einen interaktiven Chat ist deshalb nicht immer maximale Geschwindigkeit notwendig.
Batch-Verarbeitung hat andere Anforderungen
Wenn ein System nicht mit Menschen chattet, sondern nachts:
100.000 Texte
klassifiziert, sieht die Situation anders aus.
Dann ist Durchsatz entscheidend.
Beispielsweise:
Anfragen pro Sekunde
oder:
Tokens pro Sekunde über alle Jobs
Die optimale Hardware für einen Chatassistenten kann deshalb anders aussehen als für einen Massenworkflow.
Eingabetokens und Ausgabetokens benötigen unterschiedliche Arbeit
Bei einem autoregressiven Sprachmodell muss zunächst der Prompt beziehungsweise Kontext verarbeitet werden.
Danach werden neue Tokens Schritt für Schritt erzeugt.
Man kann grob unterscheiden:
Prompt
↓
Prompt-Verarbeitung
↓
erstes Token
↓
nächstes Token
↓
nächstes Token
Die erste Phase und die Generationsphase besitzen unterschiedliche technische Eigenschaften.
Deshalb gibt es Time to First Token
Eine wichtige praktische Kennzahl lautet:
Time to First Token.
Also:
Wie lange dauert es von der Anfrage bis zum Beginn der sichtbaren Antwort?
Ein System kann danach sehr schnell generieren und sich trotzdem langsam anfühlen, wenn das erste Token erst nach zehn Sekunden erscheint.
Bei interaktiven Anwendungen ist diese wahrgenommene Verzögerung sehr wichtig.
Lange Kontexte erhöhen die Anfangsarbeit
Wenn ein Modell vor der Antwort:
100 Seiten Text
verarbeiten muss, dauert die Vorbereitung möglicherweise länger als bei einer einfachen Frage.
Deshalb kann folgende Anfrage:
Analysiere diese 300-seitige Dokumentation.
deutlich mehr Rechenarbeit verursachen als:
Was bedeutet DNS?
auch wenn die endgültige Antwort jeweils nur zwei Absätze lang ist.
Warum brauchen Tokens Speicher?
Während der Verarbeitung eines Sprachmodells werden nicht nur die Modellparameter benötigt.
Auch Zwischeninformationen zum aktuellen Kontext müssen gespeichert werden.
Bei Transformer-Modellen spielt dabei unter anderem ein Zwischenspeicher für bereits verarbeitete Informationen eine Rolle.
Je länger der Kontext, desto größer kann dieser zusätzliche Speicherbedarf werden.
Das ist bei lokaler KI besonders relevant.
Lange Kontexte kosten also nicht nur API-Geld
Sie können auch lokal beeinflussen:
VRAM-Verbrauch,
RAM-Verbrauch,
Geschwindigkeit.
Ein Modell, das mit kurzem Kontext problemlos auf einer Grafikkarte läuft, kann bei sehr großen Kontexten erheblich mehr Speicher benötigen.
Damit verbinden Tokens direkt:
Sprache
↓
Kontext
↓
Hardware
Tokens beeinflussen lokale KI stärker, als man zunächst denkt
Bei der Auswahl eines lokalen Modells schaut man oft zuerst auf:
Parameterzahl.
Quantisierung.
VRAM.
Das ist sinnvoll.
Aber ein reales System muss außerdem berücksichtigen:
gewünschte Kontextlänge
und:
Anzahl paralleler Nutzer
Denn beide können zusätzlichen Speicherbedarf erzeugen.
Zwei Nutzer können zwei Kontexte bedeuten
Wenn zwei Menschen gleichzeitig mit einem lokalen Modell chatten, verarbeitet der Server zwei unterschiedliche Gesprächszustände.
Bei:
1 Nutzer
ist der Speicherbedarf anders als bei:
50 parallelen Nutzern.
Deshalb sollte Hardware nicht ausschließlich anhand der Größe der Modelldatei ausgewählt werden.
Tokenverbrauch kann gemessen werden
Viele Modell-APIs liefern nach einer Anfrage Informationen wie:
Input Tokens
Output Tokens
Total Tokens
Damit können Anwendungen Kosten und Nutzung protokollieren.
Für produktive Systeme ist das ausgesprochen sinnvoll.
Dann kann beispielsweise erkannt werden:
Workflow A
→ durchschnittlich 3.000 Tokens
Workflow B
→ durchschnittlich 25.000 Tokens
Vielleicht ist Workflow B unnötig teuer.
Tokenmetriken helfen bei Optimierung
Ein Monitoring könnte zeigen:
Anfragen: 20.000
Input-Tokens: 80 Mio.
Output-Tokens: 12 Mio.
Kosten: X
Dann kann untersucht werden:
Warum ist der Input so groß?
Möglicherweise wird jedes Mal eine riesige Dokumentation vollständig übertragen.
Ein Retrievalsystem könnte stattdessen nur relevante Abschnitte laden.
Tokenmessung macht solche Architekturprobleme sichtbar.
Prompt Caching kann Tokenkosten verändern
Manche KI-Systeme können wiederkehrende Teile eines Prompts effizienter verarbeiten.
Beispielsweise:
immer gleiche Systemanweisung
+
immer gleiche Dokumentation
+
jeweils neue Frage
Wenn ein Anbieter beziehungsweise die lokale Inference-Engine solche wiederkehrenden Präfixe cachen kann, muss nicht jedes Mal alles vollständig neu berechnet werden.
Das erinnert stark an unseren allgemeinen Artikel Caching einfach erklärt.
Das Grundprinzip bleibt:
bereits berechnete Information
↓
wiederverwenden
Tokenzahl und Informationsgehalt sind nicht dasselbe
Ein 5.000-Token-Text kann extrem informationsreich sein.
Ein anderer 5.000-Token-Text kann aus Wiederholungen bestehen.
Das Sprachmodell sieht in beiden Fällen ungefähr dieselbe Anzahl Verarbeitungseinheiten.
Deshalb sollte Kontext nicht nur nach Länge bewertet werden.
Qualität zählt.
Ein kürzerer präziser Kontext kann besser sein
Beispiel A:
50 Seiten komplette Serverdokumentation
Beispiel B:
2 Seiten exakt relevante Konfiguration
Für die konkrete Fehleranalyse kann B wesentlich besser sein.
Das ist ein fundamentales Prinzip guter KI-Systeme:
Relevanz schlägt rohe Kontextmenge.
RAG ist deshalb auch Tokenmanagement
Retrieval-Augmented Generation wird häufig als Methode beschrieben, eigenes Wissen an ein Sprachmodell anzubinden.
Gleichzeitig löst RAG ein Tokenproblem.
Statt:
10.000 Dokumente
↓
alle in Prompt
wird:
Frage
↓
relevante Dokumente suchen
↓
5 passende Abschnitte
↓
Prompt
Dadurch sinkt der Kontext drastisch.
Das kann:
Kosten reduzieren,
Geschwindigkeit verbessern,
Antwortqualität erhöhen.
Chunking zerlegt große Dokumente
Damit Dokumente durchsucht werden können, werden sie häufig in kleinere Abschnitte zerlegt.
Diese Abschnitte nennt man oft Chunks.
Zum Beispiel:
Dokument
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
└── ...
Die Chunkgröße wird häufig ebenfalls in Tokens gemessen.
Warum?
Weil letztlich das Sprachmodell diese Textmenge verarbeiten muss.
Zu kleine Chunks verlieren Zusammenhang
Nehmen wir einen Vertrag.
Chunk 1 enthält:
Der Auftragnehmer ist verpflichtet …
Chunk 2 enthält:
… innerhalb von 14 Tagen nach Eingang …
Wenn die Trennung ungünstig erfolgt, fehlt jedem Abschnitt ein Teil der Bedeutung.
Ein Retrievalsystem findet möglicherweise nur einen davon.
Deshalb sollte Chunking Kontextgrenzen berücksichtigen.
Zu große Chunks verschwenden dagegen Kontext
Ein Abschnitt von:
10.000 Tokens
enthält vielleicht nur drei relevante Sätze.
Wird der gesamte Chunk in den Modellkontext geladen, entsteht unnötiger Tokenverbrauch.
Die optimale Chunkgröße ist deshalb ein Kompromiss zwischen:
Zusammenhang
und
Präzision.
Chunk Overlap kann Zusammenhänge erhalten
Ein häufiges Verfahren lässt benachbarte Chunks teilweise überlappen.
Beispielsweise:
Chunk 1:
Absatz A
Absatz B
Absatz C
Chunk 2:
Absatz C
Absatz D
Absatz E
Absatz C erscheint in beiden.
Dadurch gehen Informationen an einer harten Grenze weniger leicht verloren.
Der Preis:
mehr gespeicherte beziehungsweise verarbeitete Tokens.
Tokens spielen auch bei Embeddings eine Rolle
Bevor ein Textabschnitt in ein Embedding umgewandelt wird, muss auch er tokenisiert werden.
Embeddingmodelle besitzen ebenfalls:
Tokenizer,
Kontextgrenzen.
Ein riesiges Dokument kann deshalb nicht zwangsläufig als einzelnes Embedding verarbeitet werden.
Auch hier wird Chunking notwendig.
Übersetzen verändert die Tokenzahl
Angenommen, derselbe Inhalt wird auf:
Deutsch,
Englisch,
Spanisch
formuliert.
Die Texte können:
unterschiedlich viele Wörter
und
unterschiedlich viele Tokens
haben.
Deshalb kann Mehrsprachigkeit Auswirkungen auf:
API-Kosten,
Kontextverbrauch,
Geschwindigkeit
haben.
Die Unterschiede hängen stark vom jeweiligen Modell ab.
Eine Übersetzung kann trotz gleicher Bedeutung länger sein
Zum Beispiel kann eine englische Formulierung sehr kompakt sein.
Die deutsche Übersetzung benötigt längere zusammengesetzte Wörter oder mehr Satzstruktur.
Oder umgekehrt.
Informationsgehalt und Tokenzahl stehen nicht in einem festen Verhältnis.
Emojis sind ebenfalls tokenisierbar
Ein Emoji wie:
😀
muss intern ebenfalls repräsentiert werden.
Je nach Tokenizer kann ein einzelnes Emoji:
ein Token
oder mehrere Verarbeitungseinheiten
benötigen.
Komplexe Emoji-Kombinationen können noch aufwendiger sein.
Für normale Chats spielt das kaum eine Rolle.
Für große Social-Media-Datensätze kann es relevant werden.
Unsichtbare Zeichen können Tokens beeinflussen
Texte können enthalten:
mehrfache Leerzeichen,
Tabs,
Zeilenumbrüche,
Sonderzeichen.
Bei riesigen automatisierten Eingaben kann unnötige Formatierung zusätzlichen Tokenverbrauch verursachen.
Ein normaler redaktioneller Text muss deshalb nicht „minifiziert“ werden.
Maschinell erzeugte Daten sollten aber sauber strukturiert sein.
HTML kann sehr tokenintensiv sein
Eine Website enthält nicht nur sichtbaren Text.
Rohes HTML kann aussehen wie:
<div class="container">
<section id="content">
<p>Hallo Welt</p>
</section>
</div>
Die Information:
Hallo Welt
ist winzig.
Der strukturelle Overhead ist viel größer.
Wenn ein KI-System ausschließlich den Inhalt analysieren soll, kann es daher sinnvoll sein, unnötiges HTML vorher zu entfernen.
Webseiten sollten für KI-Aufgaben vorverarbeitet werden
Statt kompletten Quellcode:
Navigation.
CSS-Klassen.
Trackingcode.
Footer.
Cookiebanner.
kann ein Extraktionsschritt nur den relevanten Artikeltext bereitstellen.
Dann wird aus:
40.000 Tokens HTML
vielleicht:
8.000 Tokens Nutzinhalt
Das spart Kontext und reduziert Ablenkung.
PDF-Extraktion kann ebenfalls Tokenmüll erzeugen
Ein schlecht extrahiertes PDF kann enthalten:
Seitenzahlen.
wiederholte Kopfzeilen.
Fußzeilen.
abgebrochene Wörter.
OCR-Fehler.
Diese Informationen verbrauchen Tokens, ohne der Analyse zu helfen.
Deshalb ist Datenvorbereitung bei KI-Systemen so wichtig.
Gute Daten sparen Tokens und verbessern Qualität
Das lässt sich als allgemeine Pipeline darstellen:
Rohdaten
↓
bereinigen
↓
strukturieren
↓
relevante Inhalte auswählen
↓
tokenisieren
↓
Modell
Nicht:
alles irgendwie in Prompt
↓
hoffen
Tokens erklären auch, warum manche Prompts ineffizient sind
Angenommen, ein System verwendet bei jeder Anfrage folgenden langen Einführungstext:
Du bist ein professioneller, hochqualifizierter, extrem erfahrener und außergewöhnlich kompetenter Assistent, der stets mit höchster Präzision …
Vielleicht sind davon nur wenige Sätze wirklich funktional notwendig.
Der Rest verbraucht Tokens.
Gute Prompts sollten klar sein.
Nicht künstlich aufgebläht.
Höflichkeit ist trotzdem kein Problem
Man muss nicht anfangen, mit einer KI nur noch Telegrammstil zu schreiben:
TEXT ANALYSE NOW JSON
Nur um vier Tokens zu sparen.
Bei normaler Nutzung ist klare natürliche Sprache meist die bessere Wahl.
Optimierung wird erst sinnvoll, wenn eine tatsächliche Ressourcengrenze existiert.
Wiederholte Anweisungen können unnötig sein
Ein Prompt sagt:
Keine Listen.
Später:
Verwende wirklich keine Listen.
Und:
Wie gesagt, keine Aufzählungen.
Vielleicht reicht eine eindeutige Regel.
Solche Wiederholungen können sogar verwirren.
Ein guter Prompt besitzt:
klare Prioritäten,
möglichst wenig Widersprüche,
keine unnötige Redundanz.
Beispiele kosten Tokens – sind aber oft extrem wertvoll
Ein Prompt könnte sagen:
Gib das Ergebnis als JSON zurück.
Oder zusätzlich ein Beispiel geben:
{
"kategorie": "support",
"prioritaet": 3
}
Das Beispiel verbraucht mehr Tokens.
Es kann jedoch die Zuverlässigkeit deutlich erhöhen.
Deshalb lautet die Optimierungsfrage nicht:
Wie wenig Tokens sind möglich?
Sondern:
Welche Tokens verbessern das Ergebnis ausreichend, um ihren Aufwand zu rechtfertigen?
Few-Shot-Prompting nutzt Beispiele im Kontext
Ein Modell erhält beispielsweise:
Eingabe:
"Meine Rechnung stimmt nicht."
Ausgabe:
Buchhaltung
und:
Eingabe:
"Das Plugin verursacht einen Fehler."
Ausgabe:
Support
Dann:
Eingabe:
"Ich möchte ein Angebot."
Ausgabe:
?
Das Modell erkennt aus den Beispielen das gewünschte Muster.
Diese zusätzlichen Beispiele verbrauchen Tokens.
Sie können aber die Aufgabe klarer machen.
Viele Beispiele können irgendwann schaden
Hundert Beispiele verbrauchen vielleicht enorm viel Kontext.
Manchmal reichen:
drei
oder:
fünf
gute repräsentative Beispiele.
Dann bleibt mehr Platz für die eigentliche Aufgabe.
Auch hier ist Auswahl wichtiger als Menge.
Systemprompts können beträchtlichen Kontext belegen
Ein komplexer KI-Assistent kann interne Regeln besitzen zu:
Verhalten,
Sicherheit,
Werkzeugen,
Ausgabeformaten,
Rollen.
Diese Regeln sind für den Nutzer möglicherweise unsichtbar.
Trotzdem können sie Teil des Modellkontextes sein.
Das erklärt, warum ein KI-Produkt bei derselben sichtbaren Nutzerfrage mehr Tokens verarbeitet, als man selbst zählen würde.
Tool-Ergebnisse verbrauchen ebenfalls Tokens
Eine Websuche liefert:
fünf Artikel.
Ein Datenbanktool:
100 Datensätze.
Ein Dateitool:
mehrere Dokumentabschnitte.
Diese Ergebnisse müssen dem Sprachmodell zumindest teilweise zur Verfügung gestellt werden.
Damit wachsen die Eingabetokens.
Werkzeuge machen KI leistungsfähiger.
Sie machen Kontextmanagement aber anspruchsvoller.
Ein Tool sollte deshalb möglichst relevante Daten liefern
Schlecht:
SELECT * FROM customers;
und anschließend 500.000 Datensätze an das Modell.
Besser:
SELECT relevante Spalten
WHERE relevante Bedingung
LIMIT sinnvolle Menge
Klassische Software sollte Daten so stark wie möglich vorfiltern.
Das Modell bekommt nur, was es wirklich benötigt.
Tokenlimits sind ein Architekturproblem
Bei kleinen Chatfragen merkt man kaum etwas davon.
Bei großen KI-Systemen bestimmen Tokenlimits jedoch:
wie Dokumente gespeichert werden,
wie Retrieval funktioniert,
wie Gespräche zusammengefasst werden,
wie lange Prompts sein dürfen,
wie Workflows aufgebaut werden.
Tokens sind deshalb keine nebensächliche Abrechnungseinheit.
Sie sind eine zentrale technische Dimension von Sprachmodellen.
Warum kann ein Modell nicht einfach unbegrenzt viele Tokens lesen?
Mehr Kontext erfordert mehr:
Speicher,
Rechenaufwand,
Architekturleistung.
Transformer-Verarbeitung besitzt technische Kosten, die mit zunehmender Sequenzlänge relevant werden.
Moderne Modelle und Inference-Systeme verwenden verschiedene Optimierungen.
Trotzdem bleibt unbegrenzter Kontext praktisch nicht kostenlos.
Mehr Kontext bedeutet nicht automatisch mehr Wissen
Ein Modell mit einem riesigen Kontextfenster hat nicht automatisch mehr gelernt.
Das müssen wir klar unterscheiden.
Modellwissen
→ während Training in Parametern gelernt
gegen:
Kontext
→ Informationen für aktuelle Anfrage
Ein Modell mit kleinerem Kontext kann grundsätzlich umfangreiches gelerntes Wissen besitzen.
Ein Modell mit riesigem Kontextfenster kann zusätzliche Dokumente gleichzeitig verarbeiten.
Das sind zwei verschiedene Fähigkeiten.
Kontextfenster und Parameterzahl sind nicht dasselbe
Beispielsweise könnten zwei Modelle besitzen:
Modell A:
größere Parameterzahl
kleineres Kontextfenster
Modell B:
kleinere Parameterzahl
größeres Kontextfenster
Welches besser ist, hängt von der Aufgabe ab.
Für eine komplizierte kurze Analyse könnte A stärker sein.
Für die Verarbeitung eines langen Dokuments könnte B Vorteile haben.
Modellwahl ist mehrdimensional.
Tokens werden auch ausgegeben
Das Modell erhält nicht nur Input-Tokens.
Es produziert Output-Tokens.
Der vollständige Vorgang lautet:
Input Tokens
↓
Modell
↓
Output Token 1
↓
Output Token 2
↓
Output Token 3
↓
...
Während neue Tokens entstehen, werden diese selbst wiederum Teil der Folge, auf deren Grundlage das nächste Token berechnet wird.
Das Modell kennt seine fertige Antwort nicht im Voraus
Das ist eine interessante Konsequenz der schrittweisen Generierung.
Es erstellt nicht zuerst intern den kompletten 2.000-Wörter-Artikel und zeigt ihn anschließend an.
Die Ausgabe entsteht fortlaufend.
Das bedeutet:
Ein früher Generationsschritt beeinflusst spätere Teile.
Wenn das Modell am Anfang eine falsche Richtung einschlägt, kann sich diese durch die restliche Antwort ziehen.
Planung kann deshalb helfen
Für komplexe Aufgaben kann ein System zunächst eine Struktur erzeugen.
Dann einzelne Abschnitte.
Beispielsweise:
Thema
↓
Gliederung
↓
Abschnitt 1
↓
Abschnitt 2
↓
Abschnitt 3
Dadurch wird die Aufgabe in kleinere Kontexte zerlegt.
Das kann bei sehr langen Ausgaben robuster sein als eine einzige riesige Generierung.
Lange Artikel können abschnittsweise erzeugt werden
Ein Artikel mit 20.000 Wörtern ist für ein Sprachmodell nicht nur eine Frage der maximalen Ausgabelänge.
Es geht auch um:
Kohärenz,
Wiederholungen,
Strukturerhalt.
Eine produktive Pipeline könnte deshalb arbeiten:
Briefing
↓
Gliederung
↓
Artikelabschnitt
↓
Zwischenzusammenfassung
↓
nächster Abschnitt
↓
Gesamtprüfung
Damit muss nicht der komplette Artikel permanent vollständig im Kontext stehen.
Tokens beeinflussen somit Content-Automatisierung
Bei automatisierter Contentproduktion entstehen Fragen:
Wie groß ist das Briefing?
Wie viele Quellen werden eingebunden?
Wie lang ist der Artikel?
Wird der gesamte bestehende Content zum Vergleich mitgegeben?
Wie viele interne Linkziele werden bereitgestellt?
All das hat Tokenkosten.
Eine gute Contentpipeline sollte deshalb Informationen intelligent auswählen.
Für Duplicate-Checks muss nicht jeder Artikel komplett in den Prompt
Angenommen, eine Website besitzt:
10.000 Artikel.
Man könnte versuchen, alle Texte bei jedem neuen Artikel an das Modell zu schicken.
Das wäre absurd.
Besser:
neuer Artikel
↓
semantisch ähnliche bestehende Artikel suchen
↓
nur relevanteste Kandidaten
↓
Vergleich
Auch hier helfen Embeddings und Retrieval.
Tokenisierung beeinflusst SEO nicht direkt
Ein wichtiger Punkt:
Wie ein Sprachmodell einen Text tokenisiert, ist nicht dasselbe wie die Art, wie eine Suchmaschine Wörter für Ranking verarbeitet.
Man sollte also nicht anfangen, Webseiten für bestimmte LLM-Tokens zu schreiben.
Für normale Webinhalte gilt weiterhin:
für Menschen verständlich schreiben.
Tokenisierung wird wichtig, wenn Inhalte von Sprachmodellen verarbeitet werden.
Nicht als neues SEO-Keywordverfahren.
Es gibt keinen Grund, Texte künstlich für weniger Tokens zu verstümmeln
Beispielsweise:
WP perf opt img CDN cache.
ist vielleicht kürzer.
Für Menschen ist es schlechter.
Möglicherweise sogar für das Modell.
Wenn Content veröffentlicht wird, sollte er zuerst seine kommunikative Aufgabe erfüllen.
Tokenoptimierung ist eine Systemfrage im Hintergrund.
Bei maschinellen Prompts sieht es anders aus
Ein interner Workflowprompt muss niemandem Freude beim Lesen bereiten.
Er soll:
präzise,
stabil,
effizient
sein.
Dort kann es sinnvoll sein, unnötige Wiederholungen zu entfernen.
Deshalb unterscheiden wir:
Content für Menschen
von:
Instruktionen für Maschinen
Beides besitzt unterschiedliche Optimierungsziele.
Tokens können Sicherheitsprobleme indirekt beeinflussen
Ein Angreifer könnte beispielsweise versuchen, einen KI-Kontext mit sehr viel irrelevanter Information zu füllen.
Dadurch können:
Kosten steigen,
relevante Anweisungen verdrängt,
Kontextgrenzen erreicht
werden.
Bei öffentlich verfügbaren KI-Systemen sollten deshalb Eingabelimits existieren.
Extrem lange Nutzertexte sollten nicht ungeprüft übernommen werden
Eine Anwendung erlaubt:
beliebig große Datei hochladen.
Dann wird der gesamte Inhalt automatisch an ein teures Modell geschickt.
Das kann:
Kosten explodieren lassen,
Systemleistung beeinträchtigen.
Besser kann sein:
Dateigröße prüfen.
Textmenge begrenzen.
Dokument aufteilen.
Retrieval einsetzen.
Tokenbudgets sind deshalb sinnvoll
Ein Workflow kann definieren:
maximaler Input:
20.000 Tokens
maximale Ausgabe:
2.000 Tokens
Wenn mehr Daten vorhanden sind:
zusammenfassen
oder
retrieven
Dadurch werden Kosten und Laufzeit besser kontrollierbar.
Unterschiedliche Aufgaben brauchen unterschiedliche Budgets
Eine E-Mail-Klassifikation benötigt vielleicht:
500 Tokens
Ein umfangreicher Vertragsvergleich:
50.000 Tokens
Ein KI-System sollte nicht jede Aufgabe mit derselben maximalen Kontextgröße betreiben.
Ein bewusstes Tokenbudget kann Teil des Workflowdesigns sein.
Tokenlimits können auch Produktentscheidungen beeinflussen
Ein KI-Produkt könnte erlauben:
eine PDF-Datei.
Ein anderes:
hundert Dateien.
Das hängt nicht nur von Marketingentscheidungen ab.
Im Hintergrund müssen:
Text extrahiert,
indexiert,
ausgewählt,
in Kontext eingebracht
werden.
Tokenmanagement ist daher Teil vieler sichtbarer KI-Produkte.
Warum zeigen manche Dienste Zeichenlimits statt Tokenlimits?
Für normale Nutzer sind Tokens abstrakt.
Deshalb kann eine Oberfläche lieber sagen:
maximal 20 MB
oder:
maximal 50.000 Zeichen
Im Hintergrund wird trotzdem irgendwann tokenisiert.
Eine Zeichenbegrenzung ist für Nutzer leichter verständlich, bildet aber die tatsächliche Modellgrenze nur indirekt ab.
Seitenzahl ist noch ungenauer
Eine PDF-Seite kann enthalten:
50 Wörter.
Oder:
1.000 Wörter.
Oder:
nur ein Bild.
Deshalb sagt:
100 Seiten
sehr wenig über die Tokenzahl aus.
Für KI-Verarbeitung sind Seitenzahlen nur eine grobe menschliche Orientierung.
Bilder besitzen in multimodalen Modellen ein eigenes Tokenkonzept
Bei Modellen, die Bilder verarbeiten, können visuelle Informationen ebenfalls in interne Verarbeitungseinheiten umgewandelt werden.
Diese funktionieren nicht zwangsläufig genauso wie Texttokens.
Ein Bild kann beispielsweise in Bereiche beziehungsweise visuelle Repräsentationen zerlegt werden.
Für Abrechnung oder Kontextgrenzen können solche Inputs ebenfalls eine bestimmte rechnerische Größe besitzen.
Ein Bild ist also nicht einfach „null Tokens“
Wenn ein multimodales Modell:
Text
und
Bild
verarbeitet, benötigt auch die Bildverarbeitung Rechenressourcen.
Wie genau diese gezählt oder abgerechnet werden, hängt vom jeweiligen System ab.
Für das Grundverständnis reicht:
Text
→ Textrepräsentationen
Bild
→ visuelle Repräsentationen
beides
→ gemeinsamer Modellkontext
Audio und Video besitzen ebenfalls eigene Verarbeitungsschritte
Ein Audiosystem kann Sprache beispielsweise zunächst in:
akustische Einheiten
oder
Text
umwandeln.
Video besteht aus:
vielen Bildern
plus möglicherweise:
Audio.
Dadurch kann multimodale Verarbeitung sehr ressourcenintensiv werden.
Der allgemeine Begriff Token wird in unterschiedlichen Modellarchitekturen teilweise weiter gefasst.
In diesem Artikel konzentrieren wir uns hauptsächlich auf Texttokens bei Sprachmodellen.
Sondertokens steuern Modelle
Neben normalen Texttokens können Modelle interne besondere Tokens besitzen.
Zum Beispiel für:
Beginn eines Textes,
Ende,
Trennung verschiedener Nachrichten,
Rollen.
Ein Chat könnte intern schematisch eher aussehen wie:
[System]
Du bist ein Assistent.
[User]
Was ist DNS?
[Assistant]
DNS ist ...
Diese Struktur muss ebenfalls irgendwie repräsentiert werden.
Deshalb sind Chatnachrichten technisch mehr als nur der sichtbare Text.
Rolleninformationen beeinflussen das Modell
Moderne Chatprotokolle unterscheiden häufig:
System.
User.
Assistant.
Tool.
Dadurch kann das Modell verstehen:
Wer hat welche Information geliefert?
Was ist eine Anweisung?
Was ist eine vorherige Antwort?
Auch solche strukturellen Informationen können in tokenisierter Form verarbeitet werden.
Tool Calls können spezielle Tokenstrukturen besitzen
Ein Sprachmodell soll beispielsweise keinen normalen Satz erzeugen, sondern:
Wettertool verwenden
Ort = Wien
Intern kann das über strukturierte Modellausgaben beziehungsweise spezielle Protokolle abgebildet werden.
Das ist ein weiteres Beispiel dafür, dass Tokens nicht ausschließlich normale Wörter repräsentieren müssen.
Tokenizer und Modell gehören zusammen
Man sollte nicht einfach beliebig irgendeinen Tokenizer verwenden und dessen IDs an ein anderes Modell schicken.
Das Modell wurde mit einer bestimmten Tokenisierung trainiert.
Es erwartet genau diese Zuordnung.
Wenn:
Token-ID 1234
im Training:
Haus
bedeutete, kann man später nicht einfach definieren:
Token-ID 1234 = Auto.
Das würde die erlernten Modellstrukturen zerstören.
Tokenizerwechsel ist deshalb keine Kleinigkeit
Ein neues Modell kann einen verbesserten Tokenizer verwenden.
Aber dann wird es entsprechend mit dieser Repräsentation entwickelt beziehungsweise angepasst.
Tokenizer und Modellarchitektur bilden zusammen ein System.
Warum sind größere Token-Vokabulare nicht immer besser?
Ein sehr großes Vokabular könnte mehr vollständige Wörter abbilden.
Dann werden Texte eventuell kürzer.
Aber:
mehr Tokens im Vokabular
bedeutet auch größere Tabellen beziehungsweise Modellkomponenten.
Es entstehen technische Kompromisse.
Tokenizerdesign versucht daher eine sinnvolle Balance zwischen:
Vokabulargröße
und
Sequenzlänge.
Tokenisierung ist also eine Form von Kompression – aber nicht klassische Dateikompression
Häufige Zeichenfolgen werden gemeinsam repräsentiert.
Das erinnert ein wenig an Kompression.
Trotzdem ist ein Tokenizer kein ZIP-Programm.
Sein Ziel ist nicht einfach:
maximal kleine Datei.
Es geht darum, Text in Einheiten zu zerlegen, mit denen ein neuronales Modell gut lernen und arbeiten kann.
Tokenisierung ist Teil der Sprache des Modells
Für Menschen besteht dieser Satz aus Buchstaben und Wörtern.
Für das Modell beginnt die eigentliche Repräsentation mit Tokens.
Man kann deshalb bildlich sagen:
Tokens sind das Alphabet auf einer höheren Ebene, mit dem ein Sprachmodell arbeitet.
Die Analogie ist nicht perfekt.
Sie macht aber verständlich, warum Tokens so grundlegend sind.
Tokens werden anschließend zu Embeddings
Nach der Tokenisierung haben wir beispielsweise:
Token-ID 154
Token-ID 8291
Token-ID 71
Diese IDs allein tragen kaum Bedeutung.
Das Modell wandelt sie in mathematische Vektoren um.
Vereinfacht:
Token
↓
Token-ID
↓
Embedding
↓
Transformer
Damit gelangen wir zum nächsten wichtigen Konzept.
Ein Embedding ist viel reichhaltiger als eine Token-ID
Token-ID:
731
sagt nur:
Eintrag 731.
Embedding:
[0.14, -0.72, 1.08, ...]
repräsentiert das Token in einem hochdimensionalen mathematischen Raum.
Dadurch können Beziehungen gelernt werden.
Tokens zerlegen Sprache.
Embeddings machen daraus mathematisch nutzbare Repräsentationen.
Kontext verändert die Bedeutung eines Tokens
Das Wort:
Bank
kann bedeuten:
Geldinstitut
oder:
Sitzbank.
Der Token allein ist also mehrdeutig.
Erst der Kontext hilft.
Zum Beispiel:
Ich überweise Geld an die Bank.
gegen:
Wir sitzen auf der Bank im Park.
Transformer-Schichten erzeugen kontextabhängige Repräsentationen.
Dadurch kann dasselbe Token abhängig von seiner Umgebung unterschiedlich verarbeitet werden.
Das ist ein großer Unterschied zu einem normalen Wörterbuch
Ein Wörterbuch besitzt möglicherweise zwei Definitionen unter:
Bank
Das Sprachmodell verarbeitet die konkrete Verwendung im Satz.
Aus:
Sparkonto
Zinsen
Überweisung
entsteht ein anderer Kontext als aus:
Park
Holz
sitzen
Genau daraus entsteht die Fähigkeit moderner Modelle, Mehrdeutigkeit erstaunlich gut zu behandeln.
Tokens sind daher nur der erste Schritt
Es wäre falsch zu sagen:
Ein LLM versteht lediglich Tokens.
Tokens sind zunächst die Eingangseinheiten.
Die eigentliche Leistung entsteht durch die komplexe Verarbeitung ihrer Beziehungen.
Die Pipeline lautet:
Text
↓
Tokens
↓
Embeddings
↓
viele Transformer-Schichten
↓
kontextabhängige Repräsentationen
↓
Wahrscheinlichkeiten
↓
neues Token
Das neue Token wird wieder Teil des Kontextes
Angenommen, das Modell beginnt:
DNS ist
Nun wird das nächste Token erzeugt:
das
Danach basiert die nächste Berechnung bereits auf:
DNS ist das
Dann:
Domain
und so weiter.
Die eigene Ausgabe beeinflusst also fortlaufend die weitere Generierung.
Fehler können sich dadurch fortsetzen
Wenn das Modell früh behauptet:
Das Produkt wurde 2017 veröffentlicht.
obwohl 2019 richtig wäre, kann der restliche Absatz auf:
2017
aufbauen.
Die Generierung bleibt intern konsistent mit einem falschen Ausgangspunkt.
Das ist ein weiterer Grund, warum frühzeitige Faktenfehler problematisch sind.
Strukturierte Generierung kann den Tokenraum einschränken
Wenn eine Anwendung nur folgende Kategorien erlaubt:
Support
Verkauf
Buchhaltung
muss das Modell theoretisch nicht jeden denkbaren Text erzeugen.
Moderne Systeme können strukturierte Ausgaben stärker begrenzen.
Das erhöht die Zuverlässigkeit.
Statt:
Ich würde diese Anfrage vermutlich dem Support zuordnen.
entsteht:
{
"category": "support"
}
Auch hier arbeitet das Modell mit Tokens.
Der erlaubte Ausgaberaum wird jedoch stärker kontrolliert.
Weniger mögliche Ausgaben können bessere Automatisierung bedeuten
Für kreative Texte möchte man Freiheit.
Für eine Datenbankschnittstelle nicht.
Dort lautet das Ziel:
genau dieses Schema
Deshalb wird Tokensteuerung in Produktionssystemen nicht nur über Prompts, sondern teilweise technisch umgesetzt.
Stop-Sequenzen können Generierung begrenzen
Ein System kann definieren:
Wenn eine bestimmte Tokenfolge erscheint:
Generierung beenden.
Das kann nützlich sein bei:
festen Datenformaten,
bestimmten Protokollen.
Damit lässt sich verhindern, dass ein Modell nach dem eigentlich gewünschten Ergebnis noch lange Erklärungen erzeugt.
Maximale Ausgabetokens schützen vor Endlosschleifen
Ein Workflow kann beispielsweise sagen:
maximal 500 Output-Tokens
Dann endet die Generierung spätestens dort.
Das schützt vor:
unnötig langen Antworten,
unerwarteten Kosten,
bestimmten Fehlerzuständen.
Die Begrenzung muss aber zur Aufgabe passen.
Zu knappes Output-Limit kann Antworten abschneiden
Wenn ein Artikel:
2.000 Tokens
benötigen würde, das Limit aber:
500 Tokens
beträgt, kann die Ausgabe mitten im Satz enden.
Ein sinnvolles Tokenbudget muss deshalb genügend Reserve besitzen.
Kontextfenster ist Input plus benötigter Output
Bei vielen Modellen muss man praktisch berücksichtigen:
Input
+
mögliche Ausgabe
≤
verfügbares Kontextfenster
Wenn nahezu der komplette Kontext bereits mit Dokumenten gefüllt ist, bleibt möglicherweise zu wenig Platz für eine längere Antwort.
Das ist ein häufiger Architekturfehler.
Man sollte deshalb Antwortreserve einplanen
Beispielsweise:
Kontextfenster:
100.000 Tokens
Dokumente:
99.500 Tokens
gewünschte Antwort:
5.000 Tokens
Das passt offensichtlich nicht.
Ein System muss vorher kürzen beziehungsweise selektieren.
Tokenbudgetierung gehört deshalb zum Dokumentenworkflow.
Zusammenfassungen können Tokenbudgets retten
Statt zehn lange Quellen vollständig einzubinden:
Quelle 1
Quelle 2
...
Quelle 10
kann das System jede Quelle zunächst verdichten.
Danach werden die Zusammenfassungen gemeinsam analysiert.
Der Nachteil:
Jede Zusammenfassung kann Details verlieren.
Deshalb müssen Architektur und Aufgabe zusammenpassen.
Hierarchische Zusammenfassung ist ein möglicher Ansatz
Beispiel:
100 Dokumente
↓
je Dokument Zusammenfassung
↓
10 Gruppen-Zusammenfassungen
↓
Gesamtanalyse
So lässt sich eine Informationsmenge verarbeiten, die niemals vollständig gleichzeitig ins Kontextfenster passen würde.
Die Qualität hängt allerdings stark von der jeweiligen Aufgabe ab.
Bei Recherche sollten Quellen nicht vollständig verschwinden
Eine Zusammenfassung sollte idealerweise weiterhin auf die Originalquelle verweisen.
Sonst entsteht eine Kette:
Original
↓
Zusammenfassung
↓
Zusammenfassung der Zusammenfassung
↓
noch eine Zusammenfassung
Mit jedem Schritt kann Information verloren gehen.
Das ist besonders bei wissenschaftlichen oder rechtlichen Themen problematisch.
Tokens sind deshalb ein Informationsbudget
Man kann sich das Kontextfenster wie ein begrenztes Budget vorstellen.
Jeder Teil konkurriert um Platz:
Regeln
+
Frage
+
Quellen
+
Gespräch
+
Beispiele
+
Antwort
Die Architektur entscheidet:
Wofür verwenden wir dieses Budget?
Diese Sichtweise ist enorm hilfreich beim Bau guter KI-Systeme.
Mehr Systemprompt bedeutet weniger Platz für Nutzdaten
Ein Systemprompt mit:
20.000 Tokens
kann sehr detailliert sein.
Aber diese 20.000 Tokens stehen dann möglicherweise nicht mehr für:
Dokumente,
Gespräch,
Antwort
zur Verfügung.
Deshalb sollten Regeln präzise statt endlos sein.
Mehr Beispiele bedeuten weniger Platz für Aufgabeninhalt
Few-Shot-Beispiele können Qualität verbessern.
Aber hundert Beispiele können das Kontextfenster auffressen.
Vielleicht wäre ein Fine-Tuning oder ein kleiner spezialisiertes Modell irgendwann sinnvoller.
Tokens helfen dadurch sogar bei der Entscheidung:
Prompting
oder
Modellanpassung?
Wiederkehrendes Wissen gehört möglicherweise nicht immer in jeden Prompt
Angenommen, ein Modell muss bei jeder Anfrage eine 100-seitige Unternehmensrichtlinie erhalten.
Das ist teuer und ineffizient.
Alternativen können sein:
RAG.
Fine-Tuning bei geeigneten Verhaltensmustern.
ein Tool.
eine Datenbank.
Tokenverbrauch kann damit auf ein Architekturproblem hinweisen.
Tokens machen KI skalierbar messbar
Ein einzelner Chat fühlt sich qualitativ an.
Eine Plattform mit einer Million Anfragen braucht Kennzahlen.
Tokens liefern dafür eine wichtige Maßeinheit.
Man kann messen:
durchschnittlicher Input.
durchschnittlicher Output.
Kosten pro Vorgang.
Antwortdauer.
Tokenverbrauch je Funktion.
Dadurch wird KI vom Experiment zum steuerbaren IT-System.
Ein einfacher Workflow kann ein Tokenbudget besitzen
Zum Beispiel:
E-Mail-Klassifikation
Systemprompt:
300 Tokens
E-Mail:
durchschnittlich 500 Tokens
Ausgabe:
maximal 50 Tokens
Gesamt:
ca. 850 Tokens
Bei:
1.000.000 E-Mails
wird daraus eine planbare Größenordnung.
Dann lohnt sich Optimierung.
Ein redaktioneller Workflow braucht deutlich mehr Kontext
Zum Beispiel:
Artikelbriefing:
2.000 Tokens
Quellen:
8.000 Tokens
bestehende ähnliche Artikel:
4.000 Tokens
Anweisungen:
1.000 Tokens
Ausgabe:
6.000 Tokens
Nun liegen wir grob bei:
21.000 Tokens
pro Durchlauf.
Mit mehreren Prüfschritten kann sich der Verbrauch vervielfachen.
Tokenkosten gehören deshalb in die Planung automatisierter Contentproduktion.
Lokale KI besitzt keine Tokenrechnung pro API – aber Tokens kosten trotzdem
Ein lokales Modell sendet keine Rechnung:
35.217 Tokens = 0,13 Euro
Trotzdem benötigt jeder Token:
Rechenzeit,
Strom,
Hardwarekapazität.
Bei hoher Auslastung kann man auch lokal berechnen:
GPU-Stunden
oder:
Energie pro Million Tokens
Tokens bleiben also eine nützliche Leistungsgröße.
Ein schneller Tokenizer macht noch kein schnelles Modell
Tokenisierung selbst ist meist nicht der größte Rechenaufwand.
Der wesentlich aufwendigere Teil ist die Verarbeitung innerhalb des neuronalen Netzes.
Deshalb sollte man unterscheiden:
Tokenizer
→ Text zerlegen
LLM
→ Tokens verarbeiten
Der Name klingt ähnlich.
Die Rechenarbeit ist völlig unterschiedlich.
Was passiert nach der Antwort?
Die erzeugten Token-IDs werden wieder in sichtbaren Text umgewandelt.
Das nennt man vereinfacht Decoding beziehungsweise Detokenisierung.
Also:
Token-IDs
↓
Tokenizer
↓
Text
Das ist der umgekehrte Weg zur Eingabe.
Für den Nutzer erscheint am Ende wieder ganz normale Sprache.
Man sieht dem Text seine Tokens nicht an
Ein Wort könnte intern aus drei Tokens bestehen.
Du siehst trotzdem nur:
Suchmaschinenoptimierung
Das Tokenformat ist eine interne technische Repräsentation.
Der Mensch muss sich beim Lesen nicht darum kümmern.
Warum sollte ein normaler KI-Nutzer Tokens trotzdem verstehen?
Weil sie viele scheinbar merkwürdige Eigenschaften moderner KI erklären.
Zum Beispiel:
Warum besitzt ein Modell ein Kontextlimit?
Warum kosten lange Dokumente mehr?
Warum sind lange Chats irgendwann schwieriger?
Warum brauchen lokale Modelle bei langem Kontext mehr Speicher?
Warum sind tausend Wörter nicht gleich tausend Tokens?
Warum kann Code besonders viel Kontext verbrauchen?
Warum verwendet RAG nur bestimmte Dokumentabschnitte?
Tokens sind damit eines der wichtigsten Bindeglieder zwischen:
Sprachmodelltheorie
und
praktischer KI-Nutzung.
Für normale Nutzung muss niemand Tokens manuell zählen
Du musst nicht vor jeder Frage rechnen:
Dieser Prompt hat vermutlich 372 Tokens.
Das wäre unnötig.
Relevant wird es, wenn du:
API-Anwendungen entwickelst,
große Dokumente verarbeitest,
lokale Modelle betreibst,
Workflows automatisierst,
Kosten kontrollierst.
Dann sollte Tokenverbrauch gemessen statt geschätzt werden.
Tokenzähler können präzise Werte liefern
Da der Tokenizer bekannt ist, kann Software einen Text durch genau denselben Tokenizer schicken und die Einheiten zählen.
Dann erhält man:
12.834 Tokens
statt einer groben Wortschätzung.
Für produktive Anwendungen ist das die richtige Methode.
Der Tokenzähler muss zum Modell passen
Ein Tokenzähler für Modell A kann für Modell B eine falsche Zahl liefern.
Wenn die Tokenizer verschieden sind.
Deshalb sollte immer der Tokenizer des tatsächlich verwendeten Modells beziehungsweise eine kompatible Bibliothek genutzt werden.
Tokens sind kein Qualitätsmaß
Ein 10.000-Token-Prompt ist nicht automatisch besser als ein 500-Token-Prompt.
Ein Modell mit 200.000 Kontexttokens ist nicht automatisch intelligenter als eines mit 100.000.
Ein Text mit 5.000 Ausgabetokens ist nicht automatisch ausführlicher im sinnvollen Sinn.
Tokens messen Menge der Modellrepräsentation.
Nicht Qualität.
Auch „Token-Effizienz“ sollte nicht überbewertet werden
Modell A benötigt für einen deutschen Text:
1.000 Tokens.
Modell B:
1.200 Tokens.
Daraus folgt nicht automatisch:
A ist besser.
Vielleicht besitzt B:
bessere Antwortqualität,
günstigere Tokenpreise,
höhere Geschwindigkeit,
bessere deutsche Fähigkeiten.
Tokenisierung ist nur eine Dimension.
Was du dir über Tokens merken solltest
Ein Token ist eine grundlegende Verarbeitungseinheit moderner Sprachmodelle.
Ein Token kann sein:
ein Wort
ein Wortteil
ein Satzzeichen
eine Zahl
eine Zeichenfolge
Ein Wort entspricht nicht automatisch einem Token.
Der Text wird zunächst durch einen Tokenizer zerlegt.
Text
↓
Tokenizer
↓
Tokens
Jedes Token erhält eine numerische Identität.
Danach wird es in mathematische Repräsentationen überführt und vom Sprachmodell verarbeitet.
Token
↓
Token-ID
↓
Embedding
↓
Transformer
Unterschiedliche Modelle können denselben Text unterschiedlich tokenisieren.
Deshalb gibt es keine universelle feste Beziehung zwischen:
Wörtern
und
Tokens.
Tokens bestimmen wesentliche praktische Eigenschaften von LLMs:
Kontextgröße
Kosten
Geschwindigkeit
Speicherbedarf
Dokumentgröße
Ausgabelänge
Ein Kontextfenster von:
100.000 Tokens
bedeutet nicht:
100.000 Wörter.
Es bedeutet, dass das Modell innerhalb einer bestimmten Tokenkapazität arbeiten kann.
Dabei können unter anderem konkurrieren:
Systemanweisungen,
Gesprächsverlauf,
Dokumente,
Tool-Ergebnisse,
aktuelle Frage,
Antwort.
Tokens sind deshalb ein begrenztes Informationsbudget.
Das wichtigste praktische Prinzip lautet:
Nicht möglichst viele Informationen
in den Kontext packen.
Sondern die richtigen Informationen.
Genau deshalb werden Techniken wie:
Retrieval,
RAG,
Chunking,
Zusammenfassungen,
Prompt Caching
so wichtig.
Für lokale KI verbinden Tokens außerdem Sprache unmittelbar mit Hardware.
Längere Kontexte können:
mehr VRAM,
mehr RAM,
mehr Rechenzeit
benötigen.
Und bei Cloud-APIs bestimmen Input- und Output-Tokens häufig einen wesentlichen Teil der Nutzungskosten.
Tokens sind damit nicht nur eine abstrakte technische Besonderheit.
Sie erklären einen großen Teil davon, wie Sprachmodelle praktisch arbeiten, wo ihre Grenzen liegen und wie KI-Systeme effizient gebaut werden können.