Was LLM-Token tatsächlich kosten und wie man weniger davon bezahlen kann

Jede API-Rechnung für ein Sprachmodell ist eine Rechnung für Token, und fast niemand hat eine Vorstellung davon, wie viele Token ein bestimmter Text enthält. Das Ergebnis ist zweimal im Monat die gleiche Überraschung: Eine Funktion, die sich beim Testen billig anfühlte, kostet in der Produktion das Vierzigfache, oder ein Kontextfenster, das „passen sollte“, lehnt die Anfrage ab. Beides sind Rechenaufgaben, und es lohnt sich, das Rechnen einmal zu lernen.

Ein Token ist kein Wort

Modelle lesen weder Zeichen noch Wörter. Sie lesen Token – Blöcke, die von einem Bytepaar-Encoder erzeugt werden, der während des Trainings gelernt hat, welche Sequenzen oft genug vorkommen, um ein eigenes Symbol zu verdienen. Gewöhnliche englische Wörter sind ein Zeichen. Seltene spalteten sich. Also token ist eins und tokenization ist drei, während eine zufällige Zeichenfolge wie x7Qp2 kann fünf kosten.

Die Faustregeln, die es wert sind, getragen zu werden:

• Englische Prosa: ungefähr vier Zeichen pro Token oder ungefähr 0,75 Token pro Wort. Ein Artikel mit tausend Wörtern umfasst etwa 1.300 Token.
• Code: deutlich schlimmer. Einrückung, Interpunktion und CamelCase-Kennzeichnungen sind alle fragmentiert. Planen Sie ein Budget von eher drei Zeichen pro Token ein und behandeln Sie minimierten Code als seine eigene Katastrophe – er lässt sich schlecht tokenisieren, gerade weil er ungewöhnlich ist.
• Nicht-lateinische Schriften: wieder viel schlimmer. Chinesisch, Japanisch und Koreanisch landen üblicherweise in der Nähe eines Tokens pro ein oder zwei Zeichen, sodass der gleiche Inhalt auf Japanisch ein Vielfaches dessen kosten kann, was die englische Version kostet. Dazwischen liegen Kyrillisch und Griechisch.
• JSON: Die Interpunktion ist echtes Geld. Jedes Anführungszeichen, jede geschweifte Klammer, jeder Doppelpunkt und jedes Komma ist zumindest Teil eines Tokens, und tief verschachtelte Strukturen mit langen Schlüsselnamen können mehr für die Syntax als für die Werte aufwenden.

Für die Schätzung gelten Faustregeln. Wenn es darauf ankommt, zählen: die LLM-Token und Kostenrechner tokenisiert, was Sie einfügen, und gibt die Anzahl aus. Außerdem kann der Text mit markierten Token-Grenzen angezeigt werden. Dies ist der schnellste Weg, um zu verstehen, warum eine Ihrer Eingabeaufforderungen unerwartet teuer ist. Zu sehen, wie die eigenen Identifikatornamen in jeweils vier Teile zerfallen, erklärt viel.

Der Output ist um ein Vielfaches teurer als der Input

Das Preisdetail, das die Leute vermissen: Anbieter berechnen separat für die von Ihnen gesendeten Token und die vom Modell generierten Token, und der Output beträgt normalerweise das Vier- bis Achtfache des Input-Tarifs. Eine Eingabeaufforderung mit 10.000 Kontexttokens und einer Antwort mit 200 Tokens wird von der Eingabe dominiert. Eine Eingabeaufforderung mit 500 Unterrichtstoken, die einen Aufsatz mit 4.000 Token ergibt, wird – stark – von der Ausgabe dominiert.

Dies kehrt viele Optimierungsinstinkte um. Das Reduzieren einer Systemaufforderung von 900 auf 600 Token spart sehr wenig, wenn das Modell bei jedem Anruf lange Antworten schreibt. Wenn man dem Modell sagt, dass es in drei Sätzen statt in drei Absätzen antworten soll, spart man viel. Fragen Sie, auf welcher Seite der Transaktion Ihre Arbeitsbelastung tatsächlich liegt, bevor Sie die falsche optimieren.

Der Rechner bewertet den gleichen Text für jedes Modell in seiner Tabelle sowohl bei Eingabe- als auch bei Ausgaberaten, sodass Sie ein billiges Modell, das die gesamte Arbeit erledigt, mit einem teuren Modell vergleichen können, das einen Teil davon erledigt. Die Referenzpreise werden lokal gespeichert und in regelmäßigen Abständen anhand der Anbieterseiten überprüft. Behandeln Sie sie als Planungshilfe und bestätigen Sie sie anhand der Preisseite des Anbieters, bevor Sie sich auf ein Budget festlegen, da sich die Preise ändern.

Chat ist quadratisch, und hier sterben die Budgets

Ein einmaliger API-Aufruf kostet, was er kostet. Bei einer Konversation wird der gesamte Verlauf bei jeder Runde neu gesendet, sodass ein Chat über zwanzig Runden nicht das Zwanzigfache einer Runde kostet – es kostet ungefähr die Summe einer wachsenden Serie. Runde zwanzig zahlt sich wieder für die Runden eins bis neunzehn aus.

Zwei Konsequenzen. Erstens sind Agentenschleifen mit langer Laufzeit die teuerste Form der LLM-Nutzung und diejenige, die am wahrscheinlichsten ohne Messung als Prototyp erstellt wird. Zweitens ist das Zwischenspeichern von Eingabeaufforderungen wichtiger als jede Änderung des Wortlauts: Anbieter rabattieren Token, die ein Präfix wiederholen, das sie bereits gesehen haben, was bedeutet, dass Sie Ihren stabilen Inhalt – die Systemeingabeaufforderung, das Schema, die Beispiele – ganz vorne und den variablen Teil am Ende platzieren. Ordnen Sie dieselbe Eingabeaufforderung neu an, sodass oben ein sich ändernder Zeitstempel angezeigt wird, und Sie haben den Cache bei jedem Aufruf ungültig gemacht, ohne sonst etwas zu ändern.

Verkleinern Sie eine Eingabeaufforderung, bevor Sie sie senden

Die meisten übergroßen Eingabeaufforderungen sind aus langweiligen Gründen überdimensioniert: Jemand hat eine ganze Datei eingefügt, obwohl drei Funktionen relevant waren, und die Datei besteht zur Hälfte aus Kommentaren und Leerzeilen. Der LLM-Kontextkompressor zielt genau darauf ab – es entfernt Codekommentare, bricht Leerzeilen zusammen, kürzt ab und entfernt Füllwörter aus der Prosa und meldet dann, wie viele Tokens durch das Trimmen eingespart wurden. Auf einer echten Quelldatei, die routinemäßig 20–40 % ausführt, ohne irgendetwas zu berühren, was das Modell benötigt.

Die manuellen Schnitte, die es wert sind, vorher durchgeführt zu werden:

1. Senden Sie Auszüge, keine Dateien. Auch die Aufmerksamkeit des Models ist nicht umsonst; Ein irrelevanter Kontext verschlechtert die Antworten messbar und kostet Geld.
2. Entfernen Sie Protokolle in die fehlerhafte Region. Zehntausend Zeilen erfolgreicher Startup-Ergebnisse tragen nichts zur Diagnose bei.
3. Lassen Sie wiederholte Boilerplate fallen. Lizenzheader, generierte Importe, der gleiche Haftungsausschluss für jeden Datensatz.
4. Zusammenfassen statt erneut senden. In einem langen Gespräch ist es die größte Ersparnis, die es gibt, wenn man die Wendungen eins bis fünfzehn durch einen Staatsabsatz ersetzt.

Wenn die Eingabe wirklich nicht passt

Kontextfenster sind jetzt groß, aber „groß“ ist immer noch endlich, und ein Buch, ein Jahr Protokolle oder ein vollständiges Transkript werden eins überschreiten. Teilen ist die Standardantwort, und es kommt darauf an, wo man teilt: Das Schneiden in der Mitte des Satzes oder in der Mitte der Funktion erzeugt Teile, die das Modell erraten muss. Der prompter Splitter unterteilt den Text in Abschnitte mit einer von Ihnen gewählten Größe unter Berücksichtigung der Grenzen und nummeriert die Abschnitte, sodass Sie sie der Reihe nach mit jeweils einer einheitlichen Anweisung versehen können.

Ein Hinweis zu Einheiten: Token sind keine Bytes. Der UTF-8-Bytezähler beantwortet eine andere Frage – wie viel Platz der Text auf der Leitung oder in einer Datenbankspalte einnimmt – und die beiden Zahlen weichen bei nicht-lateinischem Text stark voneinander ab, wo die Anzahl der Bytes pro Zeichen gleichzeitig mit der Abnahme der Zeichen pro Token steigt. Verwenden Sie Bytes für Speichergrenzen und Token für Modellgrenzen und ersetzen Sie niemals eines durch das andere.

Ein gelungenes Beispiel

Angenommen, Sie beantworten zwanzig Fragen anhand eines dreißigseitigen Dokuments. Dreißig Seiten entsprechen etwa 15.000 Wörtern, also etwa 20.000 Token. Naiverweise senden Sie das Dokument mit jeder Frage: 20 × 20.000 = 400.000 Eingabe-Tokens, plus vielleicht 20 × 300 Ausgabe-Tokens.

Stellen Sie das Dokument an die erste Stelle und halten Sie es bei allen Aufrufen byteidentisch. Die meisten Anbieter stellen das wiederholte Präfix aus dem Cache zu einem Bruchteil der Rate bereit. Schneiden Sie zuerst die Vorlage ab, dann schrumpft auch die Basis. Stellen Sie pro Anruf fünf Fragen statt einer und Sie versenden das Dokument viermal statt zwanzig. Dieselbe Aufgabe, dasselbe Modell und eine Größenordnung zwischen der nachlässigen und der vorsichtigen Version – und das ist der springende Punkt beim Abzählen vor dem Senden.

Sowohl der Zähler als auch der Kompressor laufen vollständig in Ihrem Browser: Die Aufforderung zur Preisfestsetzung wird nirgendwo hochgeladen, um gemessen zu werden.