Token- und Abrechnung für LLM-APIs: Schätzung, Ablesung, Budget und Beispiele

Was sind Token und wie wird berechnet?

Token sind die kleinste Maßeinheit, mit der das Modell Text verarbeitet. Sie sind weder Zeichen noch Wörter, sondern „Bruchstücke“ dazwischen. Stell dir Token wie Skalenstriche auf einem Wasserzähler vor: Je mehr du nutzt, desto schneller laufen die Striche durch. Die Abrechnung gliedert sich in zwei Bereiche:

Hinweis: Der Output-Preis ist viermal so hoch wie der Input-Preis. Daher spart es oft mehr Geld, das Modell „weniger reden“ zu lassen, als weniger Kontext zu senden. Im Chat-Kontext wächst der Input jedoch durch den historischen Kontext, sodass beide Seiten zu beachten sind. Die Bezahlung erfolgt über Prepaid-Guthaben, kein Abo. Das Guthaben verfällt nie. Neue Konten erhalten $0,50 Testguthaben, gültig für 7 Tage.

Ein häufiger Irrtum: Output-Token sind die tatsächlich vom Modell generierte Menge, nicht dein eingestelltes max_tokens. max_tokens ist nur eine Obergrenze. Wenn das Modell nach 200 Zeichen fertig ist, werden nur die Token für diese 200 Zeichen berechnet. Für die Budgetplanung solltest du jedoch die Obergrenze ansetzen, um das Worst-Case-Szenario abzudecken und von langen Ausgaben überrascht zu werden.

Vorausschätzung: Schätzung für Chinesisch und Englisch

Vor der Anfrage ist nur eine Schätzung möglich. Alle Werte unten sind Näherungen und können je nach Inhalt schwanken:

Die richtige Verwendung der Schätzung besteht darin, eine Größenordnung zu bestimmen: Ist dieser Artikel etwa 10.000 oder 100.000 Token lang, wird das Kontextfenster von 100.000 Tokens gesprengt, und wie viel kostet eine einzelne Anfrage ungefähr? Für Präzision liest du die usage. Eine gute Gewohnheit ist, in jedem Anwendungsszenario mehrere Dutzend Durchläufe zu testen, den Durchschnitt der usage zu ermitteln und ihn anstelle von Erfahrungswerten zu verwenden.

Ein Beispiel, das Schätzung und Messung kombiniert: Angenommen, du verarbeitest einen Satz von etwa 2.000 chinesischen Kundenfeedbacks. Grob geschätzt sind das 1,3 Token pro Zeichen, also etwa 2.600 Token pro Anfrage, zuzüglich 200 Token für deine Anweisungen, was Eingaben von ca. 2.800 Token ergibt. Teste zunächst 30 Anfragen, lies die usage und bilde den Durchschnitt. Wenn der gemessene Durchschnitt 2.500 beträgt, korrigiere deinen Faktor auf ca. 1,15. Berechne danach das Budget für den gesamten Satz basierend auf dem korrigierten Faktor, was die Fehlerquote deutlich verringert. Diese Messzahl ist nur ein hypothetisches Beispiel zur Veranschaulichung der Methode; deine eigenen Daten werden andere Werte aufweisen.

usage ablesen: Der echte „Zählerstand“

Jede erfolgreiche Antwort enthält usage mit den Feldern prompt_tokens, completion_tokens und total_tokens. Für Streaming-Antworten wird kein zusätzlicher Parameter benötigt; am Ende wird automatisch ein Datenblock mit usage angehängt. Der folgende Code zeigt beide Lesearten und rechnet die Werte in USD um:

复制import os
from openai import OpenAI

client = OpenAI(base_url="https://api.apidamoxing.com/v1", api_key=os.environ["API_KEY"])
PRICE_IN, PRICE_OUT = 0.25, 1.00     # 美元 / 百万 token

def cost(u):
    return (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1_000_000

# 非流式：usage 在响应对象上
r = client.chat.completions.create(
    model="uncensored", max_tokens=200,
    messages=[{"role": "user", "content": "用三句话解释什么是通货膨胀。"}],
)
print(r.usage.prompt_tokens, r.usage.completion_tokens, f"${cost(r.usage):.6f}")

# 流式：最后一个数据块带 usage，其余块的 usage 为空
usage_last = None
stream = client.chat.completions.create(
    model="uncensored", max_tokens=200, stream=True,
    messages=[{"role": "user", "content": "再用三句话解释什么是通货紧缩。"}],
)
for chunk in stream:
    if chunk.usage:
        usage_last = chunk.usage
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)
print()
if usage_last:
    print(usage_last.prompt_tokens, usage_last.completion_tokens, f"${cost(usage_last):.6f}")

Beim Streaming ist zu beachten: Nur der letzte Datenblock enthält usage; in den vorherigen Blöcken ist es null. Eine Prüfung mit if chunk.usage reicht also aus. Speichere jeden Zählerstand in Logs oder der Datenbank. Für die Monatsabrechnung, die Fehleranalyse und die Berechnung der Kosten pro Nutzer ist diese Aufzeichnung unerlässlich.

Eine weitere gute Praxis: Markiere jede Geschäftsfunktion mit einem Label und speichere die Kosten entsprechend. Trenne z. B. „Zusammenfassung“, „Kundenservice“ und „Übersetzung“. Bei der Monatsabrechnung siehst du sofort, welche Funktion am teuer ist und ob der Prompt optimiert, der Kontext gekürzt oder max_tokens gesenkt werden sollte. Ohne Labels hast du nur eine Gesamtsumme und weißt nicht, wo du ansetzen sollst.

Drei Beispiele (Annahmen angegeben)

Beispiel 1: Kundenservice-Fragen und -Antworten

Annahme: 800 Token Eingabe pro Anfrage (inkl. System-Prompt und Wissenssegment), 200 Token Ausgabe; 10.000 Anfragen pro Tag.

Kosten pro Anfrage: 800 × 0,25 ÷ 1.000.000 = $0,0002, Ausgabe 200 × 1,00 ÷ 1.000.000 = $0,0002, gesamt $0,0004. Täglich $4,00, 30 Tage $120. Bei dieser Geschwindigkeit reicht das Testguthaben von $0,50 für etwa 1.250 solcher Anfragen.

Beispiel 2: Zusammenfassung langer Texte

Annahme: 20.000 Token Eingabe pro Artikel, 600 Token Ausgabe für die Zusammenfassung; insgesamt 500 Artikel.

Pro Artikel: 20.000 × 0,25 ÷ 1.000.000 = 0,005 $, plus 600 × 1,00 ÷ 1.000.000 = 0,0006 $, insgesamt 0,0056 $. Für 500 Artikel insgesamt 2,80 $. Wie man sieht, sind Aufgaben mit langer Eingabe und kurzer Ausgabe sehr günstig.

Beispiel 3: Mehrstufige Chats und Beschneiden des Verlaufs

Annahme: System-Prompt 100 Token; pro Runde 60 Token Eingabe des Nutzers, 150 Token Antwort; ein Gespräch mit 20 Runden.

Die Eingabe der Vollverlauf-Lösung beträgt: 20 × (100 + 60) + 210 × (0 + 1 + … + 19) = 3.200 + 39.900 = 43.100. Die Beschneidungslösung hat in den ersten drei Runden jeweils 160, 370, 580 Token, ab der 4. bis zur 20. Runde jeweils 790 Token, insgesamt 14.540. Die Kosten unterscheiden sich um etwa die Hälfte, und je mehr Runden es gibt, desto größer ist der Unterschied, da die Eingabe bei der Vollverlauf-Lösung quadratisch mit der Anzahl der Runden wächst.

Aus diesen drei Beispielen lässt sich eine Faustformel ableiten: Die Kosten werden hauptsächlich durch „Anzahl der Anfragen × Eingabe- und Ausgabetoken pro Anfrage“ bestimmt. Der Eingabeteil pro Anfrage ist der Bereich, an dem man am meisten schrauben kann. Im Kundenservice-Szenario verkürzt man die Wissenssegmente, im Chat-Szenario beschneidet man den Verlauf, im Zusammenfassungsszenario arbeitet man in Blöcken parallel. Es geht immer um dasselbe Prinzip: Bezahle nicht für unnötige Token. Wichtig ist, dass die Zahlen in diesen Beispielen ausschließlich auf den oben genannten Annahmen beruhen. Deine tatsächlichen Daten basieren bitte auf den usage-Daten.

Betrachten wir nun eine umgekehrte Berechnung: Wenn dein monatliches Budget 30 $ beträgt, wie viele 20-Runden-Chats kannst du monatlich abdecken? Bei der Lösung „Nur die letzten 3 Runden“ aus Beispiel 3 kostet jede Sitzung ca. 0,0066 $, also reichen 30 $ ÷ 0,0066 für etwa 4.545 Sitzungen. Bei gleichem Budget und der Vollverlauf-Lösung (0,0138 $ pro Sitzung) reichen die Mittel nur für etwa 2.174 Sitzungen. Das ist der praktische Unterschied, den das Beschneiden des Verlaufs bringt.

Budgetkontrolle: Baue eine Sperrklappe in dein Programm

Die Schätzung ist nur eine Vorhersage, die Begrenzung ist die Versicherung. Im Folgenden eine Klasse für das tagesbasierte Budget in US-Dollar: Vor der Anfrage eine „Worst-Case“-Abschätzung vornehmen (Ausgabe nutzt max_tokens aus), nach der Anfrage die tatsächliche usage verbuchen.

复制class Budget:
    """按美元计的日预算。超出时拒绝新请求。"""
    def __init__(self, daily_usd):
        self.limit = daily_usd
        self.spent = 0.0

    def check(self, est_prompt_tokens, max_tokens):
        # 最坏情况：输出用满 max_tokens
        worst = (est_prompt_tokens * 0.25 + max_tokens * 1.00) / 1_000_000
        if self.spent + worst > self.limit:
            raise RuntimeError(f"预算不足：已用 ${self.spent:.4f}，本次最坏 ${worst:.4f}，上限 ${self.limit}")

    def record(self, usage):
        self.spent += (usage.prompt_tokens * 0.25 + usage.completion_tokens * 1.00) / 1_000_000

budget = Budget(daily_usd=5.0)
budget.check(est_prompt_tokens=1200, max_tokens=500)   # 请求前
# ……发请求……
# budget.record(response.usage)                        # 请求后

Neben dem Ventil im Programm gibt es drei weitere Maßnahmen auf Konfigurationsebene:

1. Setze max_tokens aufgabenspezifisch, nicht immer auf das Maximum. Standardwert 2048, Maximum 32.000;
2. Setze eine Längengrenze für den Chat-Verlauf, siehe die Vorgehensweise in Chatbot-Bau;
3. Lade nur die Menge auf dein Konto auf, die du tatsächlich verwenden möchtest. Nach dem Verbrauch wird nachgeladen. Das Prepaid-Modell ist von Natur aus eine harte Obergrenze.

Die Einheitspreise und Regeln zum Guthaben gelten gemäß Preisseite, Details zu den Schnittstellen findest du in Parameter-Erklärung.

Fasse die Schritte in einer Checkliste zusammen: Vorher, die Größenordnung schätzen, max_tokens festlegen, die Länge der Historie prüfen; währenddessen, bei Streaming-Ausgaben auf die usage im letzten Block achten; nachher, verbuchen und nach Funktion kategorisieren, dann mit dem Budget vergleichen. Nach diesen drei Schritten ist die Übersicht klar.