Hauptgedanke

Zwei Ströme laufen durch einen Skill, und sie haben nicht denselben Tarif. Was man dem Modell zu lesen gibt — Dateien, Datenbanken, Anweisungen —, zählt einfach. Was es erzeugt — ausformulierte Analysen, Profile, Zusammenfassungen —, zählt etwa fünfmal so viel.

Ein Skill, der 100 000 Tokens liest und 20 000 erzeugt, verbraucht also nicht 120 000 Einheiten, sondern 200 000: Die Hälfte seines Verbrauchs geht auf die 20 000 zurück, die er geschrieben hat. Das Audit von competitor_analyze zeigt dieselbe Umkehrung im realen Maßstab — 206 000 gelesene gegen 38 000 erzeugte Tokens, und doch macht die Generierung fast die Hälfte der insgesamt 478 000 Einheiten aus.

Rohes Token-Volumen und Kosten bringen die Schritte also nicht in dieselbe Reihenfolge.

Warum das wichtig ist

Das ändert die Reihenfolge des Verdachts, wenn man sucht, wohin ein Kontingent verschwindet: Man schaut zuerst auf das, was der Agent schreibt, und erst danach auf das, was man ihn lesen lässt. Ein kurzer Generierungsschritt kann mehr kosten als ein massiver Lesevorgang.

Außerdem macht es Vorgänge unterschiedlicher Art — Dateien öffnen, einen Bericht schreiben, ein Skript aufrufen — in einer einzigen Einheit vergleichbar.

Nuancen und Grenzen

Der Faktor fünf ist ein Tarifdurchschnitt, der für bestimmte Modelle zu einem bestimmten Zeitpunkt stimmt. Die Preislisten ändern sich, und ein einzelner Vertrag kann eine andere vorsehen.

Und die Gewichtung sagt nichts über die Latenz: Der teuerste Schritt ist nicht unbedingt der, auf den man wartet.

Offene Fragen

• Wie gewichtet man einen Input, von dem ein Teil im Cache liegt und günstiger abgerechnet wird als der Rest?