Die Rechnung der OpenAI API ist nicht deshalb schwer zu verstehen, weil der Stückpreis versteckt wäre, sondern weil ein einzelner Request oft mehrere Abrechnungsdimensionen gleichzeitig auslöst: normaler Input, Cache-Treffer, Output, Reasoning-Token, Bilder, Langkontext-Multiplikatoren und Batch-Rabatte. Wer nur „wie viel pro Million Token“ betrachtet, unterschätzt die tatsächlichen Kosten leicht.
Dieser Artikel gliedert das Thema in „Abrechnungseinheit – drei Hauptposten – Zusatzregeln – Schätzformel – Reihenfolge der Kostensenkung“. Alle Stückpreise, Rabatte und Schwellenwerte richten sich nach den Modellpreisen und der offiziellen OpenAI-Dokumentation; feste Zahlen nennt dieser Artikel nicht.
Hinweis: OpenAI, GPT und ChatGPT sind Marken ihrer jeweiligen Inhaber; dieser Artikel dient der technischen Erklärung. Preise ändern sich mit Modell und Abrechnungszeitraum; ziehen Sie vor der Budgetplanung die Modellpreise auf dieser Website heran.
1. Zuerst die Einheit: Token sind keine Zeichen
Ein Token ist die kleinste Einheit, die das Modell für Text verarbeitet. Ein Schriftzeichen, ein englisches Wort oder ein Satzzeichen kann einem oder mehreren Token entsprechen; auch Bilder, Tool-Definitionen und strukturierte Schemata werden in Token umgerechnet. Schätzen Sie das Budget nicht mit „Zeichenzahl × Stückpreis“, sondern verwenden Sie das Feld usage aus der API-Antwort.
Der Input eines Requests umfasst üblicherweise:
- System-Prompt und Entwickleranweisungen;
- bisherige Nachrichten des Gesprächs;
- Definitionen von Tools (Funktionen) und Parameterschemata;
- abgerufene Dokumente, Webseitentexte und Codeausschnitte;
- in Token umgerechnete nicht-textuelle Eingaben wie Bilder oder Audio.
Der Output umfasst den vom Modell erzeugten Text. Bei Reasoning-Modellen werden auch interne Reasoning-Token als Output abgerechnet, selbst wenn die vollständige Denkweise in der Oberfläche nicht sichtbar ist.
| Abrechnungsposten | In der Rechnung | Erläuterung |
|---|---|---|
| Normaler Input-Token | Ja | System-Prompt, Verlauf und Tool-Definitionen zählen mit |
| Cache-Treffer im Input | Ja, zum Cache-Preis | Nur stabile Präfixe treffen zuverlässig |
| Output-Token | Ja | Stückpreis meist höher als beim Input |
| Reasoning-Token | Ja, zum Output-Preis | Bei Reasoning-Modellen üblich, eventuell ohne vollständige Anzeige |
| Bild-Input | Ja | Umrechnung nach Bildgröße und Detailstufe |
| Fehlgeschlagene Requests | Situationsabhängig | Viele 400er zählen nicht, bereits erzeugte Teile eventuell schon |
2. Input, Output, Cache: die drei Hauptposten
Der Input-Posten zeigt, „was bei jedem Request mitgeschickt wird“. Viele Teams verlieren nicht wegen der eigentlichen Frage Geld, sondern weil sie bei jedem Aufruf das ganze Dokument, alle Tool-Definitionen und den vollständigen Verlauf erneut übertragen. Ein noch so niedriger Input-Preis wird durch die Request-Menge zum Hauptkostenfaktor.
Der Output-Posten zeigt, „wie viel das Modell geschrieben hat“. Der Output-Preis liegt meist über dem Input-Preis; lange Berichte, langer Code und ausführliche Erklärungen vervielfachen die Kosten. Ein sinnvolles max_tokens-Limit und strukturierte Ausgaben sind wirksamer als nachträgliches Kürzen.
Der Cache-Posten zeigt, „welche Inhalte wiederverwendet werden“. Das Prompt-Caching von OpenAI arbeitet mit Präfixabgleich: Nur wenn der Anfang des Requests exakt übereinstimmt, kann der folgende Teil treffen. Platzieren Sie unveränderliche System-Prompts, Tool-Definitionen und Wissensbasis-Hinweise am Anfang und die wechselnde Nutzerfrage am Ende, damit die Trefferquote stabil bleibt. Caching hat eine Mindestpräfixlänge und eine Lebensdauer; es ist kein dauerhafter Speicher, und aktiviertes Caching bedeutet nicht automatisch einen Treffer.
Ein häufiges Missverständnis: Caching bedeute „der zweite Request ist kostenlos“. Tatsächlich wird der getroffene Teil zu einem niedrigeren Cache-Lesepreis abgerechnet, der nicht getroffene Teil weiterhin zum normalen Input-Preis. In der Abrechnung sind cached_tokens und normale Input-Token getrennt zu betrachten.
3. Zusatzregeln: langer Kontext, Batch, Reasoning-Modelle
Neben den drei Hauptposten verändern einige Regeln den Endbetrag.
| Regel | Auslöser | Wirkung auf die Rechnung |
|---|---|---|
| Langkontext-Multiplikator | Einzelner Input überschreitet die modellspezifische Schwelle | Der gesamte Request wird höher multipliziert, nicht nur der überschrittene Teil |
| Batch | Nutzung der Batch-Schnittstelle, asynchrone Rückgabe akzeptiert | Meist eigener Rabatt, geeignet für Offline-Aufgaben |
| Reasoning-Tiefe | Höherer reasoning_effort |
Mehr Reasoning-Token, höhere Output-Kosten |
| Bilddetailstufe | Eingabe mit hoher Detailstufe | Mehr in Token umgerechnete Bildanteile |
| Wiederholung | Erneutes Senden nach 429 oder 5xx | Jeder Versuch ist ein neuer Request und kann erneut kosten |
Im Material zum GPT-5.5 auf dieser Website löst ein einzelner Input über 272K Token einen Multiplikator auf Input und Output des gesamten Requests aus. Solche Schwellen gehören ins Budgetmodell, nicht erst in die Analyse nach der Rechnung.
4. Kosten eines Requests schätzen
Setzen Sie die Stückpreise als Variablen:
Kosten pro Request =
nicht gecachte Input-Token × Input-Preis
+ Cache-Treffer-Token × Cache-Lesepreis
+ Output-Token (inkl. Reasoning-Token) × Output-Preis
+ Bild-/Tool-Zusatz-Token × jeweiliger Preis
Endbetrag = Kosten pro Request × Langkontext-Multiplikator × Batch-Rabatt
Für die Monatsplanung nehmen Sie die echten Logs der letzten Woche, ermitteln die Anteile der vier Token-Kategorien und multiplizieren mit den Preisen. Rechnen Sie nicht rückwärts über „durchschnittliche Kosten pro Aufruf“, denn lange und kurze Requests verteilen sich sehr unterschiedlich; ein Mittelwert verdeckt Ausreißer.
5. Welche Felder das Usage-Log enthalten sollte
Antworten OpenAI-kompatibler Schnittstellen enthalten üblicherweise ein usage-Objekt. Nehmen Sie die folgenden Felder ins Log auf, das spart bei der Abstimmung viel Zeit:
import json
from openai import OpenAI
client = OpenAI(
api_key="sk-dein-schluessel",
base_url="https://api.zhongshangqihang.com/v1",
)
resp = client.chat.completions.create(
model="gpt-5.5",
messages=[{"role": "user", "content": "Fasse die Risiken dieses Vertrags in drei Sätzen zusammen."}],
max_tokens=800,
)
u = resp.usage
prompt_details = getattr(u, "prompt_tokens_details", None)
completion_details = getattr(u, "completion_tokens_details", None)
record = {
"request_id": resp.id,
"model": resp.model,
"prompt_tokens": u.prompt_tokens,
"cached_tokens": getattr(prompt_details, "cached_tokens", 0) or 0,
"completion_tokens": u.completion_tokens,
"reasoning_tokens": getattr(completion_details, "reasoning_tokens", 0) or 0,
"total_tokens": u.total_tokens,
}
print(json.dumps(record, ensure_ascii=False))
Fehlt ein Detailfeld, weil Gateway oder SDK-Version es nicht liefern, fangen Sie es mit getattr ab; der Logging-Code darf den Hauptablauf nicht unterbrechen.
6. Reihenfolge der Kostensenkung: zuerst die kostenlosen Maßnahmen
Nach Aufwand und Wirkung sortiert:
- Zuerst messen: Token-Anteile von Input, Output, Cache und Wiederholungen je Geschäftsbereich ermitteln und den größten Posten finden.
- Input reduzieren: Statt ganzer Dokumente Retrieval, Zusammenfassungen und abschnittsweise Verarbeitung nutzen, um den Langkontext-Multiplikator zu vermeiden.
- Präfix stabilisieren: System-Prompt, Tool-Definitionen und feste Wissensbasis nach vorn legen, damit der Cache seltener verfällt.
- Output begrenzen:
max_tokenssetzen, JSON oder feste Felder verlangen und unnötig lange Antworten vermeiden. - Routing einführen: Einfache Klassifikation, Extraktion und Umformulierung über leichte Modelle, komplexes Reasoning über das Flaggschiff.
- Batch nutzen: Offline-Aufgaben über die Batch-Schnittstelle mit höherer Latenz gegen Rabatt laufen lassen.
- Budget setzen: Obergrenzen und Warnungen je Projekt und Key, damit auffällige Aufrufe früh gestoppt werden.
- Wiederholungen prüfen: Bei 429 und 5xx exponentielles Backoff und maximale Versuche setzen, um doppelte Abrechnung zu vermeiden.
7. Häufige Fragen
Warum ist Output teurer als Input?
Die Erzeugung jedes Tokens erfordert schrittweise Berechnung durch das Modell; der Rechenaufwand liegt über dem Lesen vorhandenen Kontexts, daher ist der Output-Preis meist höher. Lange Antworten, langer Code und Reasoning-Prozesse vergrößern diesen Anteil.
Greift Caching automatisch?
Viele OpenAI-kompatible Schnittstellen versuchen automatisch Präfix-Caching, aber ein Treffer hängt davon ab, ob das Präfix exakt übereinstimmt, die Mindestlänge erreicht ist und der Cache noch gültig ist. Stabile Präfixe sind die Voraussetzung für hohe Trefferquoten.
Werden Denkprozesse bei Reasoning-Modellen berechnet?
Ja. Reasoning-Token werden üblicherweise als Output-Token abgerechnet, auch wenn der Client den vollständigen Denkprozess nicht sieht. Eine höhere Reasoning-Tiefe erhöht Latenz und Kosten zugleich.
Warum unterscheiden sich zwei Abrechnungen für denselben Request?
Input-Länge, Output-Länge, Cache-Treffer, Modell-Snapshot und Anzahl der Wiederholungen können abweichen. Nur mit Request-ID und usage-Log lässt sich die Differenz zuordnen.
Sind Gateway-Preise identisch mit den offiziellen OpenAI-Preisen?
Nicht zwingend. Ein Gateway kann Wechselkurs, Zahlungsweg und Servicekosten enthalten und auch Aktionsrabatte bieten. Maßgeblich sind die Modellpreise auf dieser Website; verwenden Sie keine alten Screenshots für die Budgetplanung.
Nächster Schritt
Registrieren Sie sich zunächst beim ZSQH AI Gateway, testen Sie mit einem Test-Key einen minimalen Request, binden Sie das usage-Log an und teilen Sie anschließend das Budget nach Geschäftsbereich auf. Modelle, Kontext und Preise richten sich nach den Modellpreisen.
Weiterlesen:
