Claude Sonnet 5: So messen Sie vor der Migration die Auswirkungen des neuen Tokenizers

Was sich ändert – und was sich aus den Tokenzahlen nicht ableiten lässt

Anthropics Migrationsdokumentation zufolge verwendet Claude Sonnet 5 einen neuen Tokenizer. Für denselben Eingabetext kann die Tokenzahl ungefähr 30 Prozent höher liegen als bei Claude Sonnet 4.6; der konkrete Anstieg hängt jedoch vom Inhalt ab. In der Modellankündigung wird die Veränderung als ungefährer Faktor zwischen 1,0 und 1,35 beschrieben, ebenfalls abhängig von der Art des Textes. Das sind zwei allgemeine Beschreibungen derselben Änderung – keine Zusage, dass jeder Prompt im gleichen Verhältnis wächst.

Die erste Folge ist buchhalterischer Art: Ein Text, der zuvor eine bestimmte Anzahl Tokens ergab, kann bei Sonnet 5 mehr Einheiten zählen. Die zweite Folge betrifft den Betrieb: Wenn eine Anwendung ihr Kontextfenster fast vollständig ausnutzt, kann derselbe Inhalt einen größeren Anteil des verfügbaren Budgets beanspruchen. Der Migrationsleitfaden weist außerdem darauf hin, dass ein für Sonnet 4.6 eingestellter max_tokens-Wert eine vergleichbare Antwort bei Sonnet 5 abschneiden kann. Es genügt daher nicht, nur die Modellkennung auszutauschen und anzunehmen, frühere Messwerte beschrieben weiterhin das neue Verhalten.

Aus der Tokenzahl allein folgt nicht, dass die Kosten im selben Verhältnis steigen, dass alle Eingaben um 30 Prozent wachsen, dass das Modell schlechter arbeitet oder dass das angekündigte maximale Kontextfenster kleiner wird. Die Kosten hängen von den geltenden Preisen, den abgerechneten Eingabe- und Ausgabetokens sowie einer möglichen Cache-Nutzung ab. Ob eine Antwort nützlich ist, muss separat bewertet werden. Mehr gezählte Tokens beschreiben zunächst einen Unterschied in der Darstellung, nicht die Qualität des Ergebnisses.

Die Dokumentation zu den Neuerungen nennt für Sonnet 5 ein Kontextfenster von einer Million Tokens und eine maximale Ausgabe von 128.000 Tokens. Selbst wenn die nominelle Kontextgrenze höher liegt als bei einer früheren Konfiguration, hängt die Textmenge, die unter diese Grenze passt, davon ab, wie der Inhalt tokenisiert wird. Deshalb sollte man die Modellgrenze von der effektiven Fähigkeit einer Anwendung unterscheiden, Dokumente, Anweisungen, Verlauf und Werkzeuge innerhalb dieser Grenze unterzubringen.

Was Sie in einer realen Integration messen sollten

Ein aussagekräftiger Vergleich beschränkt sich nicht darauf, zwei Eingabe-Tokenzahlen gegenüberzustellen. Er sollte untersuchen, was mit dem gesamten Budget einer Anfrage geschieht: Systemanweisungen, Frage, abgerufene Dokumente, Verlauf, Werkzeugdefinitionen und generierte Antwort. Bei einer Aufgabe mit umfangreichem Kontext kann der Anstieg bei den Dokumenten wichtiger sein als der einer kurzen Frage. In Anwendungen mit langen Ausgaben sollten außerdem die Generierungsgrenzen und der Wert von max_tokens gezielt geprüft werden.

Die Tokenzahl ist eine Zwischenmetrik. Um festzustellen, ob sich die Änderung auf das Produkt auswirkt, sollten mindestens Anfragen erfasst werden, die das vorgesehene Budget überschreiten, abgeschnittene Antworten, Grenzwertfehler, Wiederholungsversuche, verworfene Antworten und akzeptierte Ergebnisse. Definieren Sie vor dem Test, was als akzeptierte Aufgabe gilt – zum Beispiel eine Antwort, die die vom Team festgelegten Anforderungen an Gültigkeit, Format und Qualität erfüllt. Ohne eine vorherige Definition lässt sich eine billigere Ausführung leicht als Einsparung darstellen, obwohl sie die Aufgabe schlicht nicht abgeschlossen hat.

Die Kosten pro akzeptierter Aufgabe lassen sich als Gesamtkosten aller einbezogenen Ausführungen geteilt durch die Zahl der Aufgaben berechnen, die das Akzeptanzkriterium erfüllen. Im Zähler müssen fehlgeschlagene Antworten, Wiederholungsversuche und verworfene Generierungen enthalten sein, sofern sie abrechenbaren Verbrauch verursacht haben. Außerdem ist festzuhalten, wie der Cache berücksichtigt wird, welcher Tarif gilt und über welchen Zugangskanal die Ausführung erfolgte. Diese Kennzahl ist kein offizieller Tarif, sondern eine vorgeschlagene betriebliche Messgröße für den Integrationsvergleich.

Unterscheiden Sie auch zwischen wiederverwendeten und neuen Prompts. Wenn ein Teil des Kontexts über einen Cache wiederverwendet wird, können sich die Kosten von einer unveränderten Eingabe ohne diese Behandlung unterscheiden. Die offiziellen Preisseiten erläutern Tarife und Cache-Multiplikatoren. Das Team muss jedoch für die Messung die Werte prüfen, die für sein Modell, seine Region und seine Plattform aktuell gelten. Historische Zahlen oder Preise einer anderen Plattform sollten nicht ungeprüft in eine aktuelle Prognose einfließen.

Ein Testkorpus entwerfen, mit dem sich die Änderung zuordnen lässt

Das Testkorpus sollte die reale Nutzung abbilden und während des Vergleichs unverändert bleiben. Eine geschichtete Stichprobe kann Spanisch, weitere vom Produkt verwendete Sprachen, Code, umfangreiche Dokumente, kurze Texte und wiederkehrende Inhalte getrennt erfassen. Die Aufteilung bedeutet nicht, dass sich die Tokenzahlen in diesen Kategorien immer in dieselbe Richtung verändern. Sie dient gerade dazu, Unterschiede aufzudecken. Arbeitet das Produkt mit Gesprächen, sollten auch repräsentative Verläufe enthalten sein. Werden Dokumente abgerufen, müssen die tatsächlichen Suchanfragen und Textabschnitte erhalten bleiben, die das Modell erhält.

Speichern Sie den exakten Text jeder Eingabe, ihre Zusammensetzung, die für jedes Modell ermittelte Tokenzahl und das Aufgabenergebnis. Normalisieren Sie keine Leerzeichen, ändern Sie keine Anweisungen und aktualisieren Sie keine Dokumente zwischen den Durchläufen – außer eine solche Änderung ist ausdrücklich Teil des Tests. Halten Sie außerdem Konfiguration, Datum und Zugangskanal fest. So lässt sich ein Unterschied in den Tokenzahlen untersuchen, statt ihn vage der Migration zuzuschreiben.

Für den Qualitätsvergleich braucht es identische Kriterien und eine konsistente Prüfung. Wenn möglich, sollten die Ergebnisse bewertet werden, ohne den Prüfenden mitzuteilen, welches Modell sie erzeugt hat. Ziel ist nicht, eine Version allgemein zum Sieger zu erklären, sondern festzustellen, ob der Wechsel die für die Aufgaben des jeweiligen Teams erforderlichen Ergebnisse bewahrt. Eine höhere Tokenzahl kann mit gleicher oder besserer Qualität einhergehen; geringere Kosten können zugleich mit mehr Fehlern verbunden sein. Verbrauch und Akzeptanz sollten deshalb gemeinsam betrachtet werden.

Ein reproduzierbares Verfahren für den Vergleich von Sonnet 5 und Sonnet 4.6

Legen Sie vor dem Test fest, welche Frage beantwortet werden soll. Es kann darum gehen, ob die bestehenden Prompts weiterhin mit genügend Reserve in den Kontext passen, ob Ausgabelimits neu eingestellt werden müssen oder ob sich die Kosten pro akzeptierter Aufgabe merklich verändern. Fassen Sie diese Fragen nicht zu einer einzigen Schlussfolgerung zusammen: Jede benötigt eine eigene Messgröße. Definieren Sie ebenfalls, was für das Produkt als relevant gilt – etwa eine so stark geschrumpfte Kontextreserve, dass erforderliche Inhalte entfernt werden müssten, oder eine Kostenänderung oberhalb des internen Schwellenwerts.

Führen Sie dieselben Eingaben mit beiden Versionen aus und halten Sie Anweisungen, Werkzeuge, Generierungsparameter und Akzeptanzregeln so weit wie der Zugang es erlaubt gleich. Falls eine Funktion in den Versionen kein direktes Gegenstück hat, dokumentieren Sie diesen Unterschied und schreiben Sie seine Wirkung nicht automatisch dem Tokenizer zu. Erfassen Sie Eingabe- und Ausgabe-Tokenzahlen, Beendigungsstatus, Fehler und Cache-Nutzung getrennt. Berechnen Sie für jede Ausführung die Kosten anhand des für den jeweiligen Zugangskanal geltenden Tarifs.

Vergleichen Sie die Ergebnisse anschließend nach Kategorie und nicht nur anhand eines Gesamtmittelwerts. Ein Durchschnitt kann verbergen, dass Spanisch nur geringfügig wächst, während bestimmte umfangreiche Dokumente deutlich stärker betroffen sind – oder dass ein Problem ausschließlich bei Anfragen nahe der Grenze auftritt. Prüfen Sie auch Extremfälle und fehlgeschlagene Aufgaben. Ändert sich die Akzeptanzquote, untersuchen Sie konkrete Beispiele. So lässt sich unterscheiden, ob inhaltliche Fehler, Grenzwert-Abschneidungen, ungültige Formate oder Konfigurationsänderungen vorliegen.

Wiederholen Sie den Test, wenn sich eine relevante Variable ändert. Werden Tarife, Dokumentation, Korpus oder Caching-System angepasst, beschreibt eine ältere Zahl die neuen Bedingungen nicht mehr exakt. Eine datierte Version des Testsatzes und der Berechnung macht Vergleiche über die Zeit möglich, ohne Änderungen des Modells mit Änderungen der Umgebung zu vermischen.

Tokenizer, Tarife und Zugangskanal auseinanderhalten

Um eine Veränderung dem Tokenizer zuzuordnen, genügt es nicht, eine Rechnung vor und nach der Migration zu vergleichen. Der Preis kann sich geändert haben, die Cache-Nutzung kann anders ausfallen, der Prompt kann überarbeitet worden sein und die Antworten können eine andere Länge haben. Der klarste Vergleich trennt drei Fragen: Wie viele Tokens zählt derselbe Inhalt? Was wird unter den aktuellen Bedingungen abgerechnet? Und wie viele akzeptierte Aufgaben liefert jede Konfiguration? Ein Unterschied bei einer dieser Messgrößen erklärt die anderen nicht automatisch.

Gehen Sie auch nicht davon aus, dass alle Zugangskanäle identische Bedingungen bieten. Die Dokumentation von Amazon Bedrock enthält dienstspezifische Angaben zu Verfügbarkeit, Endpoints, Regionen, APIs und Abrechnung des Modells. Für den direkten API-Zugang ist die Dokumentation der Anthropic-Plattform maßgeblich. Die geprüften Quellen erlauben nicht die Aussage, dass Zählweise, Cache, Grenzen oder Abrechnung über alle Kanäle hinweg identisch sind. Greift die Anwendung über einen Drittanbieter zu, messen Sie deshalb dort und konsultieren Sie dessen aktuelle Dokumentation und Bedingungen, statt Ergebnisse der direkten API zu übertragen.

Dieselbe Vorsicht gilt für Preisvergleiche in Modellankündigungen. Ein angekündigter Preis oder ein historischer Vergleich muss nicht dem entsprechen, was heute auf jeder Plattform und in jeder Region berechnet wird. Verwenden Sie die aktuelle Preisdokumentation, um gemessene Nutzung in Kosten umzurechnen, und speichern Sie Datum sowie Zugangskanal des verwendeten Tarifs. Lassen sich die Bedingungen nicht gleich halten, beschreiben Sie den Test als Evaluation des Gesamtsystems und nicht als isolierte Messung des Tokenizers.

Entscheiden: migrieren, anpassen oder die ältere Version vorerst beibehalten

Eine Migration ist besser begründet, wenn der Test zeigt, dass die erforderlichen Aufgaben weiterhin die Akzeptanzkriterien erfüllen, die Prompts mit ausreichender Reserve in den Kontext passen und die Kosten pro akzeptierter Aufgabe innerhalb des vom Team festgelegten Rahmens bleiben. Steigen die Tokenzahlen, ohne dass es zu Abschneidungen oder einer relevanten Veränderung des Budgets kommt, kann das eine buchhalterische Abweichung sein, die keine neue Architektur erfordert. Prognosen und Dashboards, die auf früheren Tokenzahlen beruhen, sollten dennoch aktualisiert werden.

Tritt das Problem nur bei Anfragen nahe der Grenze auf, kann es genügen, diese Fälle gezielt zu überprüfen: redundanten Kontext reduzieren, die Auswahl von Dokumenten anpassen oder max_tokens neu kalibrieren, wenn die Anwendung längere Antworten benötigt. Solche Änderungen müssen mit denselben Testaufgaben validiert werden, denn veränderte Prompts oder Inhalte führen eine neue Variable ein. Wichtiger Kontext sollte nicht allein deshalb entfernt werden, um eine höhere Tokenzahl auszugleichen; das Ergebnis muss weiterhin akzeptabel sein.

Zeigt der Vergleich häufige Fehler, höhere Kosten pro akzeptierter Aufgabe oder wegen unterschiedlicher Kanäle keine eindeutigen Ergebnisse, kann es sinnvoll sein, die Migration dieser Integration aufzuschieben, sie nach Aufgabentyp aufzuteilen oder einen kontrollierten Rollout durchzuführen. Sonnet 4.6 vorerst beizubehalten, bedeutet nicht, dass Sonnet 5 allgemein schlechter ist. Es bedeutet, dass die eigenen Belege einen Wechsel für diesen konkreten Anwendungsfall noch nicht stützen. Auch Verfügbarkeit und aktuell geltende Bedingungen beider Versionen sollten in die Entscheidung einfließen.

Dokumentieren Sie neben der Entscheidung auch die Bedingungen, unter denen sie ihre Gültigkeit verlieren könnte. Eine Aussage wie „migrieren“ ist nur dann nützlich, wenn Version, Korpus, Zugangskanal, Tarif und Datum angegeben werden. Ohne diese Angaben sind die Zahlen nicht reproduzierbar; eine spätere Preis- oder Dokumentationsänderung kann einen zuvor sinnvollen Vergleich veralten lassen.

Grenzen der Schlussfolgerung

Anthropics veröffentlichte Angaben sind ein Ausgangspunkt für den Test, ersetzen aber nicht das Korpus einer Organisation. Die ungefähre Tokenabweichung hängt vom Inhalt ab. Eine Stichprobe, die überwiegend kurze Texte enthält, muss daher nicht umfangreiche Dokumente, Code, Spanisch oder andere Materialien aus der Produktion repräsentieren. Ebenso lässt sich aus dem angegebenen Bereich der endgültige Preis einer Aufgabe nicht ableiten: Dafür fehlen die Mischung aus Ein- und Ausgaben, der geltende Tarif und die Cache-Behandlung der jeweiligen Integration.

Die Bedingungen können sich mit der Zeit ändern. Eine Modellankündigung, eine Migrationsseite und eine Preisseite können zu unterschiedlichen Zeitpunkten aktualisiert werden. Prüfen Sie vor dem Rollout die aktuelle offizielle Dokumentation und notieren Sie, welche Version und welcher Zugangskanal evaluiert wurden. Die konsultierten Quellen begründen keine allgemeingültige Gleichheit bei Tokenzählung, Grenzen und Abrechnung zwischen Anthropics API und Drittanbieterdiensten. Schlussfolgerungen dazu erfordern eine Prüfung des konkreten Kanals.

Die hilfreiche Frage lautet deshalb nicht, ob Sonnet 5 immer einen festen Prozentsatz mehr Tokens verbraucht. Entscheidend ist, wie sich der Ressourcenverbrauch bei der zu migrierenden Arbeitslast verändert und ob das wiederum das akzeptable Ergebnis beeinflusst. Ein kontrollierter Versuch beantwortet diese Frage mit geringerem Risiko, als eine allgemeine Zahl hochzurechnen. Für den Überblick über weitere Modelle im Katalog kann der Modellindex als Einstieg dienen; bei einer Migration müssen Vergleichsbedingungen und Kriterien jedoch für jeden konkreten Fall gleich bleiben.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.