Die GLM-API ist kein Produkt mit „monatlicher Pauschale und unbegrenzter Nutzung“, sondern wird nach dem tatsächlichen Verbrauch abgerechnet. Viele Teams wundern sich bei der ersten Rechnung: Die Zahl der Anfragen ist niedrig, die Kosten liegen trotzdem über den Erwartungen. Die Ursache ist meist nicht der Stückpreis, sondern eine zu lange Eingabe, eine unkontrollierte Ausgabe, ein verfehlter Cache-Treffer oder ein fehlgeschlagener Request, der beim Retry denselben Inhalt erneut erzeugt hat.
Dieser Artikel nennt keine konkreten Stückpreise, weil sie sich mit Modell, Kontextstufe und Rabattaktionen ändern. Wir erklären die Abrechnungsstruktur, wo Kosten entstehen, wie man sie schätzt und senkt, und schließen mit einer umsetzbaren Kontrollliste. Aktuelle Preise entnehmen Sie bitte der Seite Modellpreise und der Preisliste von Zhipu.
Hinweis: Zhipu, GLM und BigModel sind Marken der jeweiligen Rechteinhaber. Dieser Artikel dient ausschließlich der technischen Erläuterung; es besteht weder eine Zugehörigkeit noch ein Vertretungsverhältnis zu Zhipu. Abrechnungsregeln und Preise können sich ändern; prüfen Sie vor einer Bestellung die Anbieterdokumentation und die Rechnungsseite.
1. Die grundlegende Abrechnungseinheit
Textmodelle verwenden Token als grundlegende Einheit. Die Dokumentation von Zhipu nennt als Faustregel etwa 1 Token pro 1,6 chinesischen Schriftzeichen. Die tatsächliche Anzahl hängt jedoch vom Tokenizer und vom Inhalt ab; maßgeblich ist das usage-Feld der API-Antwort. Eine Schätzung taugt daher für das Budget, ersetzt aber nicht die Rechnung.
Nicht alle Modelle rechnen nach Token ab. Bildgenerierung, Videogenerierung, Sprachsynthese, Stimmklonen, Echtzeit-Audio und -Video sowie die Analyse von Wissensdatenbanken können pro Aufruf, pro Minute, pro Zeichen oder pro Seite abgerechnet werden. Wer ein multimodales Produkt baut, sollte zuerst die Abrechnungseinheit klären und erst danach über den Stückpreis sprechen.
2. Warum Eingabe und Ausgabe getrennt berechnet werden
Eine Anfrage enthält in der Regel Eingabe-Tokens und Ausgabe-Tokens, die getrennt berechnet werden; die Ausgabe ist meist teurer. Modelle mit langem Kontext können die Eingabe zusätzlich nach Länge staffeln, beispielsweise mit einer Grenze bei 32K, oberhalb derer eine höhere Stufe gilt. Bei einigen Modellen wird auch die Ausgabelänge gestaffelt. Das bedeutet: Dasselbe Modell kann je nach Nutzung unterschiedliche Stückkosten verursachen.
Kostentreiber ist weniger die Zahl der Anfragen als der Kontext, den jede Anfrage mitführt. Wer eine komplette Wissensdatenbank, den gesamten Gesprächsverlauf und Dutzende Tool-Definitionen in den Prompt packt, lässt die Eingabe schnell anschwellen. Häufiger noch wird bei der Ausgabe verschwendet: Ohne maximale Ausgabelänge redet das Modell ohne Ende, und die Rechnung steigt entsprechend.
| Kostenposition | Abrechnungsgrundlage | Typischer Auslöser | Kontrollmaßnahme |
|---|---|---|---|
| Eingabe-Tokens | Eingabe ohne Cache-Treffer | Lange Prompts, mehrstufiger Verlauf, Tool-Definitionen | Kontext kürzen, zusammenfassen |
| Ausgabe-Tokens | Erzeugter Inhalt | Lange Texte, Codegenerierung | Maximale Ausgabelänge setzen |
| Cache-Treffer | Rabattpreis für Treffer | Feste System-Prompts, Wissensdatenbank-Präfixe | Präfix stabil halten |
| Lange-Kontext-Stufe | Preis ändert sich oberhalb der Schwelle | Lange Dokumente, Codebase-Analyse | Aufteilen, zusammenfassen, bei Bedarf laden |
| Retries und Fehler | Bereits erzeugter Teil kann berechnet werden | Timeouts, Stream-Abbrüche, doppelte Übermittlung | Idempotenz, Backoff, Deduplizierung |
| Multimodalität und Tools | Pro Aufruf, Minute, Seite usw. | Bildgenerierung, Sprache, Suche, Parsing | Separat kalkulieren, Aufrufe begrenzen |
3. Cache-Treffer: gespart wird beim wiederholten Präfix
Zhipu bietet Context-Caching; die Dokumentation beschreibt vor allem den impliziten Cache. Das System erkennt wiederkehrende Inhalte automatisch, ohne dass Cache-Punkte manuell markiert werden müssen. Das eignet sich für Szenarien wie „fester System-Prompt + feste Wissensdatenbank + wechselnde Frage“.
Für eine höhere Trefferquote müssen mindestens drei Bedingungen erfüllt sein: Das wiederholte Präfix ist lang genug, laut Dokumentation mindestens 500 Token; der Präfix ist exakt identisch, schon ein zusätzliches Leerzeichen kann einen Treffer verhindern; und der Cache wird asynchron aufgebaut, sodass Folgeanfragen mit kurzem Abstand nach der ersten Anfrage bessere Ergebnisse liefern. Treffer lassen sich im Feld usage.prompt_tokens_details.cached_tokens prüfen.
Caching ist kein Allheilmittel. Kurze Prompts, Inhalte, die sich bei jedem Aufruf ändern, und häufig bearbeitete Wissensdatenbanken erzielen kaum Treffer. Ob die Cache-Speicherung separat berechnet wird und wie hoch der Rabatt ausfällt, steht in der Anbieter-Preisliste. Behandeln Sie Caching als Optimierung, nicht als Standardannahme im Kostenmodell.
4. Langer Kontext, Batch und Multimodalität
Langer Kontext ist praktisch, aber der Bereich, in dem Budgets am leichtesten überschritten werden. Bei Verträgen, wissenschaftlichen Arbeiten oder Codebasen sollten Sie zuerst drei Fragen stellen: Muss wirklich der gesamte Inhalt auf einmal hinein? Lässt sich zuerst suchen und dann zusammenfügen? Kann man abschnittsweise verarbeiten und anschließend zusammenfassen? Viele Aufgaben lassen sich mit „Retrieval + Zusammenfassung“ lösen, deutlich günstiger als das direkte Einfüllen der gesamten Datenbank.
Für Stapelverarbeitung lohnt ein Blick auf die Batch-Schnittstelle. Laut Dokumentation gewähren unterstützte Modelle bei Nutzung der Batch-API in der Regel einen Rabatt. Das eignet sich für Offline-Kennzeichnung, Massenzusammenfassungen und Datenbereinigung, also Aufgaben ohne Echtzeit-Anforderung. Der Preis dafür sind höhere Latenz und ein komplexeres Task-Management; sinnvoll für Teams mit Warteschlange und Ergebniskontrolle.
Multimodale Fähigkeiten müssen separat kalkuliert werden. Bildgenerierung wird pro Bild abgerechnet, Bildverständnis meist pro Token; Sprachsynthese pro Zeichen oder Minute, Wissensdatenbank-Parsing pro Seite. Wer diese Kosten in das Textbudget mischt, bekommt am Monatsende keine stimmige Abrechnung.
5. Retries, Stream-Abbrüche und versteckte Kosten
Fehlgeschlagene Anfragen sind nicht zwangsläufig kostenlos. Wenn der Server bereits einen Teil des Inhalts erzeugt hat und dann in einen Timeout läuft, kann dieser Verbrauch dennoch berechnet werden; bei einem abgebrochenen Stream kann der bereits erzeugte Teil ebenfalls in die Rechnung einfließen. Die Retry-Strategie sollte daher zurückhaltend sein: nur bei Rate-Limits, 5xx-Fehlern und Netzwerk-Timeouts wiederholen, exponentiellen Backoff verwenden und eine Obergrenze setzen.
Eine weitere versteckte Kostenquelle sind doppelte Übermittlungen. Nutzer, die mehrfach auf eine Schaltfläche klicken, Frontends, die nach einem Timeout automatisch erneut senden, und Warteschlangen, die Nachrichten doppelt verarbeiten, erzeugen zusätzliche Anfragen. Idempotenz über eine Request-ID oder Deduplizierung auf Gateway-Ebene ist wesentlich wirksamer als die nachträgliche Abstimmung der Rechnung.
Dazu kommen Engineering-Kosten: Logging, Monitoring, Evaluation und manuelle Prüfung. Die Modellgebühr ist nur ein Teil der Gesamtkosten. Sparen Sie nicht an der API und investieren Sie dann ein Vielfaches an Personal in manuelle Nacharbeit.
6. Wie man ein Monatsbudget schätzt
Die Schätzung erfolgt in vier Schritten: monatliches Aufrufvolumen erfassen, durchschnittliche Ein- und Ausgabe schätzen, Cache-Trefferquote schätzen und den aktuellen Stückpreis einsetzen. Wer die Guthaben und den Verbrauch mehrerer Modelle an einer Stelle verwalten möchte, kann sich bei ZSQH AI Gateway registrieren und alles zentral einsehen; maßgeblich bleiben die Preise auf der Seite Modellpreise. Der folgende Code ist nur ein Berechnungsrahmen; die Stückpreise müssen aus der Anbieter-Preisliste übernommen werden.
# Budgetmodell: Alle Stückpreise sind Platzhalter und müssen durch aktuelle Anbieterpreise ersetzt werden
monthly_calls = 300_000
avg_input_tokens = 1_200
avg_output_tokens = 300
cache_hit_rate = 0.35
input_rate = 0.0 # Eingabepreis laut Anbieter-Preisliste
output_rate = 0.0 # Ausgabepreis
cache_rate = 0.0 # Preis für Cache-Treffer
uncached_input = avg_input_tokens * (1 - cache_hit_rate)
cached_input = avg_input_tokens * cache_hit_rate
per_call = (
uncached_input * input_rate
+ cached_input * cache_rate
+ avg_output_tokens * output_rate
)
print(f"Geschätzte Monatskosten: {monthly_calls * per_call:.2f} CNY")
Kalkulieren Sie mit Reserve. In neuen Geschäftsfeldern ist die tatsächliche Eingabe oft länger als geplant, und Retries sowie Fehler erhöhen den Verbrauch zusätzlich. Empfehlenswert ist ein Testlauf mit kleinem Volumen über zwei Wochen; ersetzen Sie danach die Annahmen durch echte usage-Daten und legen Sie das Budget fest.
7. Checkliste zur Budgetkontrolle
- Für jede Umgebung und jeden Dienst ein eigenes Ausgabenlimit festlegen.
- Für alle Anfragen eine maximale Ausgabelänge und ein Timeout setzen.
- Die Reihenfolge der System-Prompts fixieren, um die Cache-Trefferquote zu erhöhen.
- Lange Dokumente zuerst durchsuchen und zusammenfassen, dann über den langen Kontext entscheiden.
- Nur wiederholbare Fehler erneut senden, mit Backoff und Obergrenze.
- Täglich den Verbrauch prüfen, wöchentlich die Rechnung; bei auffälligem Wachstum sofort nachforschen.
- Offline-Aufgaben bevorzugt über Batch abwickeln, Echtzeit-Aufgaben über die Online-Schnittstelle.
8. Häufige Fragen (FAQ)
1. Was kostet die GLM-API konkret?
Die Preise ändern sich mit Modell, Kontextstufe und Rabattaktionen; dieser Artikel nennt keine festen Zahlen. Sehen Sie auf der Seite Modellpreise oder in der Preisliste von Zhipu nach; maßgeblich ist die Rechnung in der Konsole.
2. Wie werden Cache-Treffer abgerechnet?
Der vom Cache abgedeckte Teil wird zum Rabattpreis berechnet, die übrige Eingabe zum Standard-Eingabepreis. Konkrete Rabatte und Speicherkosten stehen in der Anbieter-Preisliste; die Treffermenge lässt sich im usage-Feld ablesen.
3. Wird ein fehlgeschlagener Request berechnet?
Das hängt von der Fehlerphase ab. Wenn bereits ein Teil des Inhalts erzeugt wurde, kann der tatsächliche Verbrauch berechnet werden; bei Parameterfehlern und fehlgeschlagener Authentifizierung entstehen in der Regel keine Generierungskosten. Maßgeblich ist die Rechnungsaufstellung.
4. Ist langer Kontext immer teurer?
Meistens ja. Viele Modelle staffeln nach Eingabelänge, und oberhalb der Schwelle steigt der Stückpreis. Aufgaben, die sich durch Aufteilen oder Retrieval lösen lassen, müssen nicht zwingend in den langen Kontext gezwungen werden.
5. Wie senkt man bestehende Kosten schnell?
Drei Maßnahmen zuerst: maximale Ausgabelänge begrenzen, System-Prompts straffen und die Cache-Trefferquote erhöhen. Diese drei wirken meist schneller und kontrollierter als ein Modellwechsel.
