Abrechnungsbeispiele

Diese Seite führt durch reale Abrechnungsberechnungen für einige typische Modelle, eines pro Preismodell. Die Mechanik hinter jedem Preismodell wird unter So werden Modelle abgerechnet erklärt.

LLM-Tokens — zai-org/glm-5.2

LLM-Modelle werden pro Million Tokens abgerechnet, mit separaten Tarifen für Eingabe-Tokens (Prompt), gecachte Eingabe-Tokens und Ausgabe-Tokens (Completion) (siehe LLM-Modelle):

$Cost = \frac{Fresh\ Input}{1M} \times \$1.40 + \frac{Cached\ Input}{1M} \times \$0.26 + \frac{Output}{1M} \times \$4.40$

Die Berechnung erfolgt nach Abschluss der Anfrage, basierend auf den im usage-Feld der Antwort gemeldeten Token-Anzahlen — Streaming- und Nicht-Streaming-Anfragen werden identisch abgerechnet, und fehlgeschlagene Anfragen werden nicht berechnet.

Beispiel — eine Chat-Anfrage mit 12,000 Prompt-Tokens (davon 10,000 aus dem Prompt-Cache bedient) und 1,500 Ausgabe-Tokens:

1. Frische Eingabe: 2,000 × 1.40 $÷ 1M = 0.0028$
2. Gecachte Eingabe: 10,000 × 0.26 $÷ 1M = 0.0026$
3. Ausgabe: 1,500 × 4.40 $÷ 1M = 0.0066$
4. Gesamt: 0.0120 $

Ohne Prompt-Caching würde dieselbe Anfrage alle 12,000 Eingabe-Tokens zum vollen Eingabetarif abrechnen — 0.0168 $+ 0.0066$ = 0.0234 $, fast doppelt so viel. Wenn Sie den System-Prompt über Anfragen hinweg stabil halten, kann der Cache-Tarif auf den wiederholten Teil angewendet werden.

Token-basiert abgerechnetes Video — bytedance/seedance-2.0/reference-to-video

Seedance 2.0 reference-to-video wird beim Abschluss der Aufgabe nach Ausgabe-Video-Tokens abgerechnet (siehe token-basiert abgerechnete Videomodelle). Je nach Ihren Eingaben gelten zwei Token-Tarife:

Auflösungsmultiplikatoren: 480p / 720p / 1080p × 1.0, 4k × 0.57, 720p-sr / 1080p-sr × 1.8, 1440p-sr × 3.2. Die abgerechneten Tokens werden am generierten Ergebnis gemessen (und schließen bei Anfragen mit Referenzvideos den Anteil des Eingabevideos ein) — verwenden Sie daher /calculate für ein exaktes Angebot in den 4K- und SR-Stufen.

Die Token-Anzahl skaliert mit Auflösung, Bildrate und Dauer:

$Video\ Tokens \approx \frac{Width \times Height \times FPS \times Duration(seconds)}{1024}$

Bei 1080p (1920 × 1080, 24 fps) ergibt das 48,600 Tokens pro Sekunde Video.

Beispiel A — nur Referenzbilder, 10 s bei 1080p:

1. Ausgabe-Tokens: 48,600 × 10 s = 486,000 Tokens
2. Listenpreis: 486,000 ÷ 1,000,000 × 11.20 $× 1.0 = **5.44$**

Beispiel B — mit einem 8-sekündigen Referenzvideo, 10 s Ausgabe bei 1080p:

1. Die abgerechneten Tokens zählen das Eingabevideo plus die Ausgabe: (10 s + 8 s) × 48,600 = 874,800 Tokens
2. Es gilt der niedrigere Tarif mit Video: 874,800 ÷ 1,000,000 × 6.88 $× 1.0 = **6.02$**

Beim Einreichen wird eine kleine temporäre Sperre gesetzt und wieder freigegeben, sobald die Aufgabe abgerechnet ist; fehlgeschlagene Aufgaben werden nicht berechnet.

Video pro Sekunde — alibaba/wan-2.7/image-to-video

Wan 2.7 image-to-video verwendet klassische Sekundenpreise: einen Basistarif von 0.10 $ pro Sekunde, skaliert nach der Ausgabeauflösung, mit einem Minimum von 5 Sekunden:

$Cost = \$0.10 \times max(5,\ Duration) \times Resolution\ Multiplier$

Beispiel — 8 s bei 1080p:

0.10 $× 8 × 1.5 = **1.20$**, beim Einreichen von Ihrem Guthaben reserviert und eingezogen, sobald das Video geliefert ist.

Beispiel — 3 s bei 720p:

Die Dauer liegt unter dem Minimum, daher werden 5 Sekunden berechnet: 0.10 $× 5 × 1.0 = **0.50$**.

Pro Bild mit Optionen — google/nano-banana-pro/edit

Nano Banana Pro (Edit-Variante) wird pro Ausgabebild bepreist, mit einer Auflösungsstufe und einem optionalen Websuche-Aufpreis:

$Cost = Images \times Tier\ Price\ (+\ \$0.014\ if\ web\ search)$

Beispiel — 2 Bilder in 4K mit aktivierter Websuche:

1. Bilder: 2 × 0.24 $= 0.48$
2. Websuche: + 0.014 $ (einmal pro Anfrage hinzugefügt)
3. Listenpreis gesamt: 0.494 $

Der Betrag wird beim Einreichen reserviert und automatisch freigegeben, wenn die Aufgabe fehlschlägt.

Token-basiert abgerechnetes Bild — openai/gpt-image-2/edit

GPT Image 2 wird wie ein LLM abgerechnet — nach Tokens —, aber die Token-Anzahlen werden beim Einreichen aus Ihren Anfrageparametern berechnet:

Ausgabe-Token-Anzahlen für ein 1024×1024-Bild: 196 (low), 1,756 (medium), 7,024 (high). Größere Formate erzeugen proportional mehr Tokens; Eingabebilder verwenden unabhängig von quality immer die Medium-Token-Basis.

Beispiel — ein 1024×1024-Bild bearbeiten, quality: medium, size: 1024x1024, n: 1:

1. Eingabetext: 1,000 Tokens × 5 $/1M = 0.0050$
2. Eingabebild: 1,756 Tokens × 8 $/1M = 0.0140$
3. Ausgabebild: 1,756 Tokens × 30 $/1M = 0.0527$
4. Gesamt: ≈ 0.072 $ pro Bild

Werden n Bilder angefordert, multipliziert sich der Gesamtbetrag mit n.

Zeichenbasiert abgerechnetes Audio (TTS) — xai/tts-v1 und bytedance/seed-audio-1.0

Beide Text-zu-Sprache-Modelle werden nach der Länge des Eingabetexts bepreist, zu 0.015 $ pro 1,000 Zeichen:

$Cost = \frac{Characters(text)}{1{,}000} \times \$0.015$

Zeichen werden als Unicode-Zeichen gezählt, ein CJK-Zeichen zählt also als ein Zeichen, genau wie ein lateinischer Buchstabe.

Beispiel — ein Skript mit 1,200 Zeichen:

1,200 ÷ 1,000 × 0.015 $= **0.018$**, berechnet beim Einreichen.

Beispiel — ein kurzer Prompt mit 300 Zeichen:

300 ÷ 1,000 × 0.015 $= **0.0045$**.

Jedes Modell selbst prüfen

Jedes der obigen Beispiele lässt sich mit der Kostenschätzungs-API reproduzieren — senden Sie Ihren exakten Request-Body an /api/v1/model/calculate und Sie erhalten den Listenpreis, Ihren effektiven Preis und den angewendeten Rabatt zurück, ohne dass eine Aufgabe erstellt wird.