Die Grok API wird von xAI bereitgestellt und nach Tokens abgerechnet, wobei Eingabe und Ausgabe getrennt bepreist werden. Viele Teams achten bei der Budgetplanung nur auf den Modellpreis und stellen nach dem Start fest, dass die Rechnung deutlich von der Schätzung abweicht: Jede Runde überträgt den Verlauf erneut, Ausgaben werden zu lang, Retries laufen ohne Backoff, lange Dokumente werden wiederholt geladen – all das vervielfacht die Kosten.
Dieser Beitrag nennt keine konkreten Stückpreise, sondern zerlegt die Abrechnungsstruktur der Grok API und liefert eine reproduzierbare Kalkulationsmethode sowie eine Reihenfolge zur Kostenkontrolle. Konkrete Preise, verfügbare Modelle und Kontextlängen richten sich nach der offiziellen xAI-Dokumentation und den Modellpreisen auf dieser Website.
Hinweis: xAI und Grok sind Marken der jeweiligen Inhaber; dieser Beitrag dient der technischen Vorstellung. Modellnamen, Schnittstellen und Preise können sich ändern; vor der Beschaffung die offiziellen Seiten und die Modellpreise prüfen.
1. Woraus sich die Rechnung der Grok API zusammensetzt
Die Grok API nutzt die OpenAI-kompatible Chat-Completions-Form; die Rechnung besteht üblicherweise überwiegend aus Eingabe- und Ausgabe-Tokens. In realen Projekten sind zusätzlich Cache, Tool-Aufrufe, langer Kontext und fehlgeschlagene Retries zu berücksichtigen.
| Abrechnungsposten | Wann er entsteht | Häufige Kostentreiber | Kontrollmittel |
|---|---|---|---|
| Eingabe-Tokens | System-Prompt, Verlauf, Tool-Definitionen, Dokumente | Vollständiger Verlauf wird jede Runde erneut übertragen | Zusammenfassung, Kürzung, Retrieval |
| Cache-Eingabe | Wiederverwendung desselben Präfixes | Instabiles Präfix verhindert Treffer | System- und Tool-Reihenfolge fixieren |
| Ausgabe-Tokens | Vom Modell generierter Inhalt | Weitschweifige Antworten, unkontrolliertes Format | max_tokens setzen, strukturierte Ausgabe |
| Tool-Aufrufe | Funktionsaufrufe, Suche und weitere Fähigkeiten | Mehrere Schleifen, wiederholte Abfragen | Runden begrenzen, Ergebnisse cachen |
| Langer Kontext | Lange Dokumente, lange Dialoge | Gesamte Sammlung einfügen, wiederholtes Lesen | Abschnittweise Verarbeitung, nur relevante Teile |
| Retries | Erneutes Senden nach 429 oder Timeout | Kein Backoff, zu hohe Parallelität | Exponentielles Backoff, Idempotenzprüfung |
Verschiedene Modelle und Fähigkeiten können eigene Abrechnungsregeln haben, etwa ob Cache-Eingabe bepreist oder ein Tool-Aufruf separat berechnet wird. Maßgeblich ist die offizielle Abrechnungsbeschreibung von xAI. Für das Budget zuerst klären, welche Posten man tatsächlich nutzt, und dann über den Stückpreis sprechen.
2. Warum die Rechnung bei gleicher Aufrufzahl um ein Vielfaches abweicht
Gleiche Aufrufzahl kann völlig unterschiedliche Rechnungen erzeugen. Die Unterschiede stammen meist aus sechs Bereichen:
- Verhältnis Eingabe zu Ausgabe: Ein Kundenservice-Bot hat viel Eingabe und mittlere Ausgabe; Content-Generierung hat kurze Eingabe und lange Ausgabe. Beide Kostenstrukturen lassen sich nicht mit demselben Durchschnitt schätzen.
- Kontextakkumulation: In mehrstufigen Dialogen wird jede Runde der vollständige Verlauf mitgesendet; die Eingabe-Tokens steigen schnell mit der Rundenzahl.
- Cache-Trefferquote: Ein festes Präfix lässt sich wiederverwenden; Zeitstempel, zufällige IDs und dynamische Tool-Listen machen den Cache ungültig.
- Modellstufe: Verschiedene Grok-Modelle haben unterschiedliche Fähigkeiten und Preise; ein High-End-Modell für einfache Aufgaben bläht das Budget auf.
- Retry-Anzahl: Jeder Retry ist eine neue Anfrage; sofortiges erneutes Senden nach 429 erzeugt leicht einen Retry-Sturm.
- Ausgabelänge: Der Ausgabepreis liegt meist über dem Eingabepreis; lange Antworten, Wiederholungen und unkontrollierte Formate erhöhen die Kosten.
| Szenario | Token-Struktur | Hauptkosten | Optimierungsrichtung |
|---|---|---|---|
| Kundenservice-Bot | Viel Eingabe, mittlere Ausgabe | Verlauf wird wiederholt übertragen | Zusammenfassung plus Cache |
| Dokumentenextraktion | Lange Eingabe, kurze Ausgabe | Dokument wird wiederholt gelesen | Retrieval plus kleines Modell |
| Code-Assistent | Ein- und Ausgabe groß | Tool-Ergebnisse und Denkprozess | Tool-Ausgabe kürzen, Modell-Routing |
| Content-Generierung | Kurze Eingabe, lange Ausgabe | Ausgabe-Tokens | Abschnittweise Generierung, Länge begrenzen |
3. Die Kosten einer Anfrage sauber berechnen
Zerlegt man eine Anfrage, lassen sich die Kosten so ausdrücken:
Kosten je Anfrage =
Eingabe-Tokens ohne Cache × Eingabepreis
+ Cache-Eingabe-Tokens × Cache-Preis
+ Ausgabe-Tokens × Ausgabepreis
+ Zusatzkosten für Tools oder Suche
Die Formel ist einfach; schwierig ist die Ermittlung der tatsächlichen Tokenzahl. Nicht nach Zeichenzahl raten, sondern das usage-Feld der Antwort lesen:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["GROK_API_KEY"],
base_url=os.environ.get("GROK_BASE_URL", "https://ai.zhongshangqihang.com/v1"),
)
resp = client.chat.completions.create(
model="grok-4",
messages=[{"role": "user", "content": "Zerlege diese Anforderung in fünf Entwicklungsaufgaben."}],
max_tokens=512,
)
usage = resp.usage
print("Eingabe-Tokens: ", usage.prompt_tokens)
print("Ausgabe-Tokens: ", usage.completion_tokens)
print("Tokens gesamt: ", usage.total_tokens)
Der Betrag ergibt sich aus dem tatsächlichen Stückpreis des eigenen Kontos; den Preis aus den Modellpreisen lesen und keine Monate alten Screenshots verwenden. Das Statistikfeld für Cache-Treffer kann in verschiedenen kompatiblen Implementierungen anders heißen; maßgeblich ist die tatsächliche Antwort.
4. Die Reihenfolge, in der Kosten gesenkt werden
Kostensenkung hat eine Reihenfolge; wer sie umkehrt, arbeitet oft vergeblich. Empfohlen sind sieben Schritte:
- Zuerst die Baseline quantifizieren: die realen Anfrage-Logs der letzten Woche exportieren und Eingabe-/Ausgabe-Tokens nach Projekt, Modell und Szenario auswerten, um zu wissen, wohin das Geld fließt.
- Dann Modell-Routing: Klassifikation, Extraktion und Umschreiben mit kleinen Modellen, komplexe Inferenz mit High-End-Modellen – nach Aufgabenschwierigkeit verteilen, nicht nach Teamgewohnheit.
- Eingabe reduzieren: RAG nur relevante Passagen zurückgeben lassen, Verlauf zusammenfassen, von Tool-Rückgaben nur notwendige Felder behalten.
- Ausgabe begrenzen: angemessenes
max_tokenssetzen, JSON oder feste Felder verlangen, Höflichkeitsfloskeln und Wiederholungen reduzieren. - Cache nutzen: System-Prompt, Tool-Definitionen und Wissensdatenbank-Präfix fixieren und prüfen, ob der Cache tatsächlich trifft.
- Retries steuern: bei 429 und Timeouts exponentielles Backoff mit zufälligem Jitter, maximale Retry-Zahl und keine hektischen Wiederholungen in festem Intervall.
- Budget und Alarme: Obergrenzen pro Projekt setzen, wöchentlich die Verbrauchsrangliste prüfen und anomalies Wachstum zeitnah lokalisieren.
Zuerst Eingabesteuerung und Cache, dann über ein günstigeres Modell nachdenken. Sonst werden nur instabile Ausgaben billiger, und die Nacharbeitskosten kommen zurück.
5. Wie Budget und Rechnung verwaltet werden
- Ein Key pro Projekt und eine Budgetobergrenze pro Projekt, damit mehrere Dienste nicht gegenseitig das Kontingent verdrängen.
- Logs erfassen mindestens Zeitpunkt, Modell, Ein-/Ausgabe-Tokens, Statuscode und Request-ID; vollständige Keys und sensible Inhalte nicht protokollieren.
- Monatlich nach „Projekt, Modell, Szenario“ abgleichen und die am schnellsten wachsenden Aufrufe finden.
- Einsparungen durch Cache, Modell-Routing und Ausgabebegrenzung separat festhalten, sonst lässt sich der Optimierungserfolg nicht belegen.
- Teams, die Zahlung in RMB und Rechnungen benötigen, können ein inländisches AI-Gateway für eine einheitliche Abrechnung nutzen; Preise, Wechselkurse und Rechnungsregeln richten sich nach den Modellpreisen.
Häufig gestellte Fragen
Hat die Grok API nur Kosten für Eingabe und Ausgabe?
Die übliche Rechnung besteht überwiegend aus Eingabe- und Ausgabe-Tokens, aber Cache-Eingabe, Tool-Aufrufe und Suche können eigene Abrechnungsregeln haben. Welche Posten enthalten sind, steht in der offiziellen Abrechnungsbeschreibung und den Rechnungsdetails.
Warum ist eine Schätzung nach Durchschnitts-Tokens ungenau?
Durchschnittswerte verdecken die lange Verteilung. Wenige sehr lange Kontext-, Ausgabe- oder Retry-Anfragen können den Großteil der Kosten verursachen. Die Verteilung echter Logs ist verlässlicher als ein Durchschnitt mal Aufrufzahl.
Wie viel spart Caching?
Das hängt von der Präfix-Wiederverwendungsrate und der Trefferquote ab. Cache-Lesen ist meist günstiger als normale Eingabe, Cache-Schreiben kann jedoch einen Aufschlag haben; ist das Präfix zu kurz oder ändert es sich jedes Mal, gibt es keinen Treffer. Zuerst per Log den Treffer bestätigen, dann die Ersparnis bewerten.
Wird längere Ausgabe teurer?
In der Regel ja, weil Ausgabe-Tokens separat und oft höher bepreist werden. Die Antwort auf die fachlich nötige Länge begrenzen und strukturierte Ausgabe verwenden wirkt meist schneller als ein Modellwechsel.
Wie können inländische Teams in RMB abrechnen?
Über ein AI-Gateway mit RMB-Aufladung und Rechnungsstellung lässt sich Grok aufrufen und die Abrechnung über mehrere Modelle vereinheitlichen. Verfügbare Modelle, Preise und Rechnungsregeln richten sich nach den Modellpreisen.
Nächster Schritt
Erstellen Sie zunächst im ZSQH AI Gateway einen Test-Key, erfassen Sie mit einer Charge realer Aufgaben die Ein- und Ausgabe-Tokens und kalkulieren Sie dann nach der obigen Formel das Budget. Modellverfügbarkeit und Preise richten sich nach den Modellpreisen.
