🌐 Nolife Langage – Sag nicht „Kosten“, sag „Investition“.

vom 6. September 2026

🌐 Nolife Langage – Sag nicht „Kosten“, sag „Investition“.

Die Zahl ändert sich nicht. Der Rahmen schon.

Kosten klingt nach etwas, das man verliert. Investition klingt nach etwas, das man ohnehin vorhatte, mit einer Rendite obendrein. Basic klingt nach der abgespeckten Variante. Essential klingt nach dem, was man braucht. Standard ist generisch. Maßgeschneidert wurde speziell für dich angefertigt.

Ich habe den Verkaufs-Slogan in einem Werbevideo gehört:

Sag nicht „1.000 $“, sag „999 $“, das wirkt günstiger. Sag nicht „Jetzt kaufen“, sag „Es sind nur noch drei Stück verfügbar“. Sag niemals das Wort „Basic“, sag „Essential“. Sag niemals „Standard“, sag immer „maßgeschneidert“. Das Wort „wenige“ – sag das nicht, sag immer „limitiert“. Und verwende niemals das Wort „Kosten“, sag immer „Investition“.

Worte sind wichtig, wenn man versucht, Menschen zum Kauf zu bewegen. Ich wollte wissen, was passiert, wenn der Leser nicht nur ein Mensch, sondern auch ein Tokenizer ist.

Die erste Überraschung betraf Deutsch. In diesem Korpus mit der Kodierung o200k_base benötigte das kommerziell stärkere Wort maßgeschneidert fünf Token. Standard benötigte einen. Das sind +400 %. Unverzichtbar für Basis stieg von 1 auf 4. Die Verkaufstöne wurden lauter. Der Token-Zähler lief in die andere Richtung.

 Bedeutung
 |
 |
Token-Kosten ----+---- Überzeugungskraft

Das sind drei verschiedene Achsen. Eine Phrase kann auf einer gewinnen und auf einer anderen verlieren. Dieser Artikel ist das kleine Darkwood-Experiment, das versucht hat, sie voneinander zu trennen.

Wörter haben bereits einen Preis

Die sechs englischen Austausche sind kein Kopier-Deck. Sie sind ein Labor: klein genug, um sie in Token zu zerlegen, semantisch interessant genug, um darüber zu diskutieren.

Ich habe keinen A/B-Test zur Konversionsrate durchgeführt. Ich behaupte nicht, dass die Psychologie dahinter endgültig geklärt ist. Ich behaupte, dass es sich lohnt, die Ersetzungen zu berücksichtigen.

Englisch „Kosten“ → „Investition“ ist das deutlichste Beispiel: gleiche Idee, anderer Rahmen. Bei „o200k_base“ ist es für den Tokenizer ebenfalls ein Nullsummenspiel. Beide Seiten ergaben 1 Token. Die Zahl hat sich nicht verändert. Die Geschichte hat sich dennoch geändert.

„$1.000“ → „$999“ wirkte sich gleichzeitig in beide Richtungen aus: attraktive Preisgestaltung und weniger Token (4 → 2). Die Knappheit entwickelte sich in die entgegengesetzte Richtung. „Jetzt kaufen“ entspricht 2 Token; „Nur noch drei verfügbar“ entspricht 3.

Das ist bereits das Dreieck. Die Bedeutung kann ähnlich bleiben. Die Überzeugungskraft kann zunehmen. Die Anzahl der Token kann steigen, sinken oder unverändert bleiben.

Dann weist das Modell den Wörtern einen weiteren Preis zu

APIs und Kontextfenster rechnen nicht in Wörtern ab. Sie berechnen nach Token: Textabschnitte, nachdem ein Tokenizer die Zeichenkette aufgeteilt hat. Ein Tokenizer ist kein Wörterbuch. Er ist eine Komprimierung von Byte-Sequenzen, die er häufig gesehen hat. Englisch ist in dieser Historie überrepräsentiert. Andere Sprachen und sogar andere englische Schreibweisen desselben Begriffs können auf mehr Teile aufgeteilt werden.

Damian Zygmuntowicz’ Beitrag über die versteckten Token-Kosten von Sprachen – das polnische przedsiębiorstwo als Provokation – war der Grund, warum ich mich damit beschäftigt habe. Ich habe die polnischen Zahlen nicht reproduziert. Darkwood wird auf Englisch, Französisch und Deutsch ausgeliefert. Das sind die Sprachen, die ich gemessen habe.

Die Maßeinheit ist entscheidend. Zeichen sind keine Token. Wörter sind keine Token. Eingabe-Token sind keine Ausgabe-Token. Cache-Treffer sind keine Rechnungen. Eine Heuristik von Bytes / 4 ist eine Schätzung, keine Messung. Ich habe das eigentliche OpenAI-BPE lokal mit yethee/tiktoken ausgeführt:

• Primär: o200k_base (GPT-4o-Familie)
• Sekundär: cl100k_base (GPT-4-/3.5-Turbo-Familie)

Das sind keine Claude-Token, keine Gemini-Token und keine „universellen LLM-Token“. Die Kodierung ist Teil des Ergebnisses.

Drei Sprachen, eine Idee

Ich habe zwei kurze, parallele Passagen – ein Workshop-Angebot und eine Preisangabe – auf Englisch, Französisch und Deutsch verfasst. Absichtlich mit derselben Bedeutung. Winziger Korpus: Version 1.0.2, Hash 7510f01cf7c3…. Keine statistische Studie über „Französisch“ oder „Deutsch“. Ein deterministisches Labor.

Dann habe ich gezählt.

In diesem Korpus mit o200k_base verwendete die englische Version 46 Token, die französische 58 (+26,09 % gegenüber Englisch), die deutsche 63 (+36,96 % gegenüber Englisch).

Diese Prozentsätze beziehen sich auf dieses Korpus und diesen Tokenizer. Sie stellen keine Benachteiligung des Französischen oder des Deutschen dar.

Deutsch verwendete dieselbe Wortanzahl wie Englisch und mehr Zeichen. Es verwendete zudem mehr Token pro Wort. Die Heuristik Bytes / 4 schätzte 60 / 71 / 76 und überschätzte jede Sprache. Dennoch verschleierte sie, wie groß die Lücke in der Rangfolge ist.

Ich habe sogar versucht, das Deutsche natürlicher zu gestalten. Das Ersetzen des Calques aufgezeichnete Führung durch gefilmten Rundgang reduzierte die Zeichenanzahl von 301 auf 298 und erhöhte die o200k_base-Token von 62 auf 63. Weniger Zeichen. Ein Token mehr. Es geht nicht um den kürzeren Text.

Es hängt vom Tokenizer ab

Gleiche Texte, zweite Kodierung.

Englisch blieb bei 46. Französisch stieg von +26,09 % auf +54,35 %. Deutsch von +36,96 % auf +58,70 %. Die ältere Kodierung war für Französisch und Deutsch ungünstiger. Der Sprachbonus ist keine Eigenschaft des Französischen. Er ist eine Eigenschaft von diesem Korpus × dieser Kodierung.

Genau darum geht es beim Einsatz von zwei Tokenizern. Hätte ich nur o200k_base veröffentlicht, hätte ich unterschätzt, wie „teuer“ derselbe französische Text unter cl100k_base erscheinen kann.

Nun die Wörter ändern

Ich habe die sechs Verkaufsargumente genommen, idiomatische französische und deutsche Entsprechungen verfasst und zwei Absichten gekennzeichnet:

• Überzeugungsversuch – den Rahmen des Käufers verändern (kann mehr Token kosten)
• token_opt – eine ähnliche Idee mit weniger Token ausdrücken (kann den Rahmen schwächen)

Wähle niemals stillschweigend die kostengünstigste Formulierung aus und bezeichne sie als die beste. Überzeugungsarbeit wird hier gekennzeichnet, nicht gemessen. Die token_opt-Zeilen sind theoretische Annahmen. Die FR/DE-Phrasen sind Entwürfe, keine Übersetzungsstudie.

Einige Zeilen aus o200k_base:

Die vier Ecken des Dreiecks in diesem Durchgang:

• Stärkere Verkaufstonalität, mehr Tokens: Standard → maßgeschneidert; Deutsch maßgeschneidert (+400 %).
• Gleiche Tokens, anderer Rahmen: Englisch cost → investment (1 → 1).
• Schwächerer Verkaufston, weniger Tokens: maßgeschneidert → passend (5 → 2).
• Charm-Pricing, das auch den BPE senkt: $1.000 → $999 (4 → 2).

Knappheit kostet oft Token. Französisch achetez maintenant → plus que trois en stock stieg von 3 auf 5. Dann komprimierte token_opt dies zu 3 restants (5 → 3). Günstigere Token. Weniger Verkaufstone. Beide Messwerte sind echt. Nur eine davon ist „besser“, und es hängt davon ab, welche Achse für Sie wichtig ist.

Die roten Zeilen sind die interessanten

Neun von siebenundzwanzig Paarzeilen verwendeten nach der Überarbeitung mehr Token. Alle neun sind persuasion. Keine ist token_opt.

Im Deutschen wird es laut:

Das ist kein gescheiterter Benchmark. Überzeugungsoptimierung ist keine Token-Optimierung. Ein kommerziell stärkeres Wort kann für den Tokenizer ungünstig sein. Hätte ich die roten Zeilen verworfen, hätte ich ein Märchen über Formulierungen veröffentlicht, die immer Geld sparen.

Als Block stieg die Überzeugungskraft in diesem Korpus von 36 auf 45 Token (−25 % „Einsparung“, d. h., es kostet mehr). Allein die deutsche Überzeugungskraft: 12 → 20 (−66,67 %). Die englische Überzeugungskraft blieb unverändert (10 → 10). token_opt hat dann Tokens wiederhergestellt, darunter auch deutsche (+45,45 % insgesamt). Mehrere token_opt-Zeilen verbilligen dieselbe Idee, die die Überzeugungszeile gerade verteuert hat. Das ist die Kontrolle: gleiche Ideen, gegensätzliche Absicht.

62 → 62

Wenn ich alle Paare zu einer Gesamtsumme zusammenfasse, erhalte ich Folgendes:

62 rein. 62 raus. Es sieht so aus, als hätte die Formulierung nichts bewirkt.

Das tat sie auch nicht. Einzelne Ersetzungen gingen in beide Richtungen. Das gemischte Gesamtergebnis hat sie aufgehoben. „Mixed German“ liegt immer noch bei −13,04 % (23 → 26). „Mixed English“ „spart“ immer noch 2 Token. Der sprachübergreifende Nullwert ergibt sich aus „Persuasion“ −9 plus „token_opt“ +9.

Dies ist eine Warnung vor Benchmark-Zusammenfassungen. Ein Gesamtwert kann das Phänomen auslöschen, das man zu verstehen versucht. Ich hätte beinahe 62 → 62 als Überschrift veröffentlicht. Das wäre unehrlich gewesen.

Was kostet das in Geld?

Ich habe die Paar-Token – nicht die Passagen – bei einer Million Anfragen hochgerechnet, unter Verwendung eines veralteten gpt-4o-mini-Snapshots (2. August 2026): 0,15 $ / 0,60 $ pro Million Eingabe-/Ausgabe-Token. Das ist eine Schätzung, keine Rechnung. Dieser Korpus ist winzig. Eine Anfrage kostet nur Bruchteile eines Cent. Ich werde nicht so tun, als wäre es anders.

Bei 1.000.000 Anfragen, alle Sprachen:

Der gemischte Wert von 0,00 $ entspricht dem gleichen Ausgleich in Dollar. Bei dieser Größenordnung von einer Million Anfragen steigt allein die Eingabe für „Überzeugungsarbeit“ auf Deutsch von 1,80 $ auf 3,00 $ (Einsparung: −1,20 $). Skaleneffekte können eine Gewohnheit greifbar machen. Dieses spezielle Labor ist an sich keine Rechnungssimulation.

Die unsichtbare Kontextgebühr

Das Modell verfügt nach wie vor über dasselbe Kontextfenster in Tokens. Was sich ändert, ist, wie viel von diesem Inhalt in natürlicher Sprache darin Platz findet.

Ich habe ein hypothetisches Fenster mit 100.000 Token mit Kopien des parallelen Angebots gefüllt. Nenner: gemessene Passagetoken, nicht Paarsummen. Das ist kein Produktkontextfenster. Französisch erhält kein kleineres Fenster; das gleiche Token-Budget fasst einfach weniger Kopien dieses französischen Textes.

Bei o200k_base:

Das gleiche Token-Fenster passt auf weniger Elemente dieses französischen Korpus und noch weniger auf dieses deutsche Korpus. Wechselt man zu cl100k_base, beträgt der Wert für Französisch vs. Englisch −35,21 % Kopien. Die Kodierung beeinflusst, wie viele Kopien passen. Überprüft: 100.000 / 63 = 1.587,30; 2.173,91 − 1.587,30 = 586,61.

Die Einsparungen bei den Kosten für das Paar-Korpus waren verschwindend gering. Der Kapazitätsunterschied ist bereits erkennbar.

Caveman und die Kosten der Optimierung selbst

Für dieses Experiment habe ich mir Caveman angesehen – ein Open-Source-Projekt zur Komprimierung der Schreibweise von Codierungsagenten, nicht einen zweiten Benchmark, den ich auf diesem Korpus durchgeführt habe. Ich habe es nicht portiert. Der nützliche Aspekt ist methodischer Natur.

Caveman berichtet über echte Komprimierung und veröffentlicht auch Fälle, in denen der Overhead die Einsparungen zunichte macht oder umkehrt. Eine kürzere Ausgabe bedeutet nicht automatisch geringere Gesamtkosten. Eine Reduzierung der Ausgabe ist keine Rechnung. Eine ehrliche Differenz erfordert eine Kontrollgruppe: Man vergleicht mit einer knappen Eingabeaufforderung, nicht mit Stille.

Deshalb habe ich persuasion von token_opt getrennt, und deshalb bleiben die neun roten Zeilen im Artikel. Wenn der „optimierte“ Pfad mehr kostet, sollte man das zeigen. Ein Benchmark, der nur die grünen Zeilen ausgibt, ist eine Werbebroschüre.

Das lokale o200k_base ist nach wie vor OpenAI BPE, das auf meinem Rechner ausgeführt wird. Es handelt sich nicht um eine Claude-Abrechnung, auch wenn die Offline-Auswertungen von Caveman dieselbe Kodierung verwenden. Ein anderes Produkt. Gleiche Vorgehensweise: Den Zähler kennzeichnen, die Regression beibehalten.

Entwicklung mit Symfony und Darkwood Flow

Das Experiment ist eine kleine Symfony-8.1-Konsolenanwendung unter PHP 8.5.4. Keine Datenbank, keine HTTP-API, kein Frontend. Tokenizer: yethee/tiktoken 1.1.1. Orchestrierung: darkwood/flow 8.1.6, tatsächlich im Einsatz – der Befehl kann keine Tabellen ausgeben, solange Flow nicht läuft.

Die Pipeline besteht aus sieben Jobs:

LoadCorpus
    → TokenizeBefore
    → ApplyCandidates
    → TokenizeAfter
    → Compare
    → EstimateCost
    → Report

Jeder Schritt bleibt explizit. Laden der beiden Textpassagen und der 27 Paare. Tokenisierung des parallelen Angebots. Erfassung der bereits im Korpus vorhandenen, gekennzeichneten Ersetzungen. Jedes Paar wird tokenisiert. Vergleichen, Selbstprüfung, Aggregate nach Intention aufteilen. Kosten schätzen. Bericht erstellen. Der ausgegebene Trace ist der Beweis: COMPARE: self-check PASS.

php bin/console app:language:benchmark
php bin/console app:language:benchmark --format=json

Die JSON-Datei wird in var/benchmark/ gespeichert. Ich wollte eine Messung, die ich weiterentwickeln kann, ohne die einzelnen Schritte in einem Skript namens run.php zu verbergen.

PHP 8.6: Readonly-Standardwerte

PHP 8.6 erlaubt es, dass eine gewöhnliche Instanz-Eigenschaft einen Standardwert hat:

public readonly string $evidence = 'ESTIMATED';

Auf diesem Rechner führt dies zu einem Kompilierungsfehler: Die schreibgeschützte Eigenschaft Demo::$evidence darf keinen Standardwert haben. Die Laufzeitumgebung ist PHP 8.5.4. Ich habe die 8.6-Funktion nicht aktiviert.

Ein Standardwert für einen heraufgestuften Konstruktorparameter funktionierte bereits ab Version 8.1. Der 8.6-RFC listet dies als Nicht-Ziel auf: Es handelt sich um einen Parameterstandardwert, nicht um einen Eigenschaftsstandardwert. PricingAssumptions nutzt diesen älteren Weg. Der Preis-Snapshot bleibt in beiden Fällen ein unveränderliches Konfigurationsobjekt. Dieser Exkurs hat keinen Einfluss auf die Token-Anzahl.

PHP verfügt über Referenzen, nicht über C-Zeiger

Ein zval besteht aus einem Typ-Tag und einem Wert. Strings und Arrays werden beim Schreiben kopiert. $alias = $state kopiert einen Objekt-Handle (spl_object_id gleich: true; beide Namen wiesen Spuren von 7 → 8 auf). PHP & verpackt ein zval in IS_REFERENCE / zend_reference. $ref++ inkrementierte die Ganzzahl ($n wurde zu 3). Es wurde kein Speicher durchlaufen.

Eine PHP-Referenz ist nicht einfach ein C-Zeiger, der dem PHP-Code zur Verfügung gestellt wird. Flow verpackt jeden Job-Rückgabewert in ein neues Ip mit schreibgeschütztem $data; die Rückgabe von BenchmarkState verwendet das Handle erneut. Zend verwendet intern C-Zeiger. Userland-PHP stellt dir keinen zur Verfügung. php bin/console app:language:benchmark --explain-values gibt diese Tabelle aus. Keine FFI. Auch diese Seitenleiste verändert die Tokenanzahl nicht.

Was ich gelernt habe

Natürliche Sprachen sind hinsichtlich der Tokenisierung nicht gleichwertig. In diesem Korpus mit o200k_base verwendete Französisch 58 Token, während Englisch 46 und Deutsch 63 verwendeten. Ändert man die Kodierung, verschiebt sich auch der Premium-Wert.

Überzeugungskraft und Token-Effizienz können im Konflikt stehen. Maßgeschneidert ist ein besseres Verkaufswort, aber ein schlechterer BPE-Wert. Das englische investment ist ein Nullsummenspiel. Charm-Pricing kann versehentlich beiden Achsen helfen. Knappheitsargumente tun dies oft nicht.

Die Zeichenanzahl ist ein schlechter Ersatz für einen echten Tokenizer. Die natürlichere deutsche Formulierung war kürzer in Zeichen und länger in Token. bytes / 4 überschätzte jede Sprache und glich den Unterschied aus.

Aggregate können gegensätzliche Entwicklungen verbergen. 62 → 62 ist eine Aufhebung, nicht „die Wortwahl spielt keine Rolle“. Trenne die Absichten, sonst optimierst du eine Null.

Kontexteffizienz ist wichtig, selbst wenn der Paar-Korpus winzig ist. Das gleiche Token-Fenster passt für weniger Kopien dieses Französischen und noch weniger für dieses Deutsche.

Optimierung hat ihren eigenen Overhead. Veröffentliche die rote Zeile.

Ich habe weder die Nutzung des Live-Anbieters noch die Konversion oder eine professionelle Übersetzung gemessen. Das nächste ehrliche Experiment, falls ich eines durchführe, ist ein einzelnes, vom Anbieter gemeldetes EN/FR/DE-Paar für dieselben Passagen.

Bis dahin: Messen Sie die tatsächliche Arbeitslast, bevor Sie sie optimieren. Und wenn das gemischte Gesamtergebnis unverändert bleibt, schauen Sie sich die Zeilen an.

Quellen

• 3 LinkedIn-Beiträge
• tiktoken-php
• Caveman
• Quellcode: https://github.com/matyo91/nolife-language
• Folien: https://github.com/matyo91/slidewire