Die Rechnung der Mistral API entsteht nicht nach dem Motto „ein Aufruf, ein Preis“, sondern aus Eingabe-Token, Ausgabe-Token, Cache-Treffern und bei Spezialmodellen für OCR oder Sprache aus eigenen Einheiten. Viele Teams kalkulieren mit einer Zahl von der Preisseite und stellen nach dem Start fest, dass die Rechnung höher ausfällt. Ursache ist meist nicht ein geänderter Stückpreis, sondern eine andere Eingabestruktur, Kontextlänge oder Anzahl Wiederholungen als bei der Schätzung.

Dieser Artikel zerlegt die Abrechnung der Mistral API in berechenbare Teile: welche Einheiten zählen, wie sich Eingabe und Ausgabe addieren, warum Kontext die Kosten mit jeder Runde wachsen lässt, wie Cache und Wiederholungen die Rechnung beeinflussen und wie man mit echten Protokollen ein Budget erstellt und gegen die Rechnung abgleicht. Konkrete Stückpreise richten sich nach der offiziellen Mistral-Preisseite und Modellpreise; dieser Artikel nennt keine festen Stückpreise.

Hinweis: Mistral und Mistral AI sind Marken ihrer jeweiligen Inhaber. Dieser Artikel stützt sich auf öffentliche Dokumentation vom Oktober 2026; Modellnamen, Abrechnungseinheiten und Preise können sich ändern. Vor der Beschaffung die offizielle Mistral-Dokumentation und Modellpreise erneut prüfen.

1. Zuerst die Abrechnungseinheiten trennen: nicht alle Modelle rechnen in Token

Die Sprachmodelle von Mistral werden nach Token abgerechnet, OCR-, Sprach- und Embedding-Modelle haben jedoch eigene Einheiten. Die Kosten unterschiedlicher Einheiten direkt zu addieren ist die erste Quelle verfälschter Budgets.

Abrechnungsobjekt Einheit Typisches Szenario Beim Budget beachten
Sprachmodell Eingabe- und Ausgabe-Token Dialog, Extraktion, Code, Agenten Ausgabe meist teurer als Eingabe, gecachte Eingabe vergünstigt
OCR Seiten, inklusive gecachter Seiten Scans, PDF zu Text Getrennt von Token-Rechnungen erfassen
Spracherkennung Minuten, inklusive gecachter Dauer Meeting- und Kundendienstaufnahmen Nach Dauer, nicht nach Zeichen
Sprachsynthese Zeichen Ansagen, Vertonung Eingabe und Ausgabe getrennt ausweisen
Embedding Eingabe-Token Suche, Clustering, Deduplizierung Üblicherweise nur die Eingabeseite
Inhaltsprüfung Token Inhaltssicherheit, Risikokontrolle Ob Kosten anfallen, steht auf der aktuellen Preisseite

Die Preisseite unterscheidet zudem häufig Stufen wie Standard, Batch und Priority. Sie richten sich an unterschiedliche Zeitvorgaben; ob Batch infrage kommt, hängt davon ab, ob die Aufgabe warten kann.

2. Eingabe und Ausgabe: in einem Dialog wird beides berechnet

Bei einer Anfrage zählt alles, was in den Modellkontext gelangt, als Eingabe: System-Prompt, bisherige Nachrichten, Nutzerfrage, Tool-Definitionen, abgerufene Dokumente und der umgerechnete Anteil multimodaler Eingaben. Vom Modell erzeugte Inhalte sind Ausgabe, einschließlich Text, strukturierter Felder und Denkprozess, falls das Modell Denkinhalte zurückgibt.

Daraus entstehen zwei häufige Fehleinschätzungen:

  • Nur die Nutzerfrage zählen, nicht den Kontext. Der Nutzer schreibt zwanzig Wörter, aber System-Prompt, Tool-Schema und die letzten fünf Runden machen den Großteil aus.
  • Nur den Eingabepreis vergleichen, nicht das Ausgabeverhältnis. Im Kundenservice gibt es viel Eingabe und kurze Ausgabe; bei langen Texten ist es umgekehrt. Die Kosten pro Aufruf lassen sich nicht mit demselben Durchschnitt schätzen.

Wie multimodale Eingaben umgerechnet werden und ob Denkinhalte zur Ausgabe zählen, richtet sich nach offizieller Dokumentation und Rechnungslogik; Erfahrungen anderer Anbieter nicht unverändert übertragen.

3. Kontextlänge: jede Runde zahlt für „das Gesagte davor“

Ein Sprachmodell speichert kein Gesprächsgedächtnis. Mehrrundendialoge funktionieren, weil der Client die bisherigen Nachrichten bei jeder Runde erneut sendet. Je länger der Kontext, desto mehr Eingabe-Token enthält jede Anfrage; die Kosten wachsen mit der Rundenzahl und nicht nur mit dem neu hinzugefügten Satz.

Ein anschauliches Beispiel: Runde eins sendet nur System-Prompt und Frage; Runde fünf enthält die vier vorherigen Frage-Antwort-Paare; Runde zwanzig enthält alles davor. Selbst wenn pro Runde nur wenig hinzukommt, kann die Eingabe in Runde zwanzig ein Vielfaches der ersten Runde betragen.

Die Gegenmaßnahmen sind überschaubar:

  • nur die letzten Runden im Original behalten und ältere Inhalte zusammenfassen;
  • bei der Suche nur relevante Ausschnitte abrufen und nicht das gesamte Handbuch in den Kontext legen;
  • stabile Inhalte vorn und veränderliche Inhalte hinten platzieren, um Caching zu ermöglichen;
  • lange Dokumente abschnittsweise verarbeiten und dann zusammenführen, statt den Volltext in jeder Runde zu wiederholen.

4. Cache, Batch und Wiederholungen: drei unterschätzte Variablen

Gecachte Eingabe. Mistral bietet für Textmodelle einen Preis für gecachte Eingaben, der üblicherweise deutlich unter der normalen Eingabe liegt. Ob der Cache greift, hängt von einem stabilen Anfragepräfix ab. Zeitstempel, Zufalls-IDs oder Benutzernamen am Anfang des System-Prompts oder eine neu sortierte Tool-Definition bei jeder Anfrage machen den Cache ungültig. Caching ist meist Best-Effort; das Budget sollte mit teilweisen Treffern rechnen, nicht mit vollständigen.

Batch-Stufe. Aufgaben ohne Echtzeitanforderung wie Annotation, Zusammenfassung, Offline-Klassifikation oder Massenübersetzung können die Batch-Stufe prüfen. Sie opfert Wartezeit gegen eine andere Preisstufe; Rabatte und Grenzen stehen auf der Preisseite.

Wiederholungen. Erneutes Senden nach 429, Timeout oder Verbindungsabbruch erhöht die tatsächliche Anfragemenge. Ob fehlgeschlagene Anfragen berechnet werden und ob Wiederholungen doppelt zählen, richtet sich nach Rechnung und offizieller Erläuterung. Technisch sollten exponentieller Backoff, eine maximale Wiederholungszahl und Idempotenz bei erzeugenden Operationen eingesetzt werden, damit nicht „zweimal bezahlt, einmal erfolgreich“ passiert.

5. Mit usage und Protokollen eine echte Schätzung erstellen

Token nicht nach Zeichenzahl raten. Nach jedem Aufruf usage aus der Antwort lesen und eine Woche lang erfassen; so entsteht die reale Struktur des eigenen Geschäfts. Der folgende Code nutzt den OpenAI-kompatiblen Zugang; der Modellname kommt aus einer Umgebungsvariable, damit kein veränderlicher Name festgeschrieben wird.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url="https://ai.zhongshangqihang.com/v1",
)

resp = client.chat.completions.create(
    model=os.environ["MISTRAL_MODEL"],  # Modellname laut Preisseite
    messages=[
        {"role": "system", "content": "Du bist ein Kundendienstassistent und antwortest in höchstens drei Sätzen."},
        {"role": "user", "content": "Kann die Lieferadresse nach dem Versand noch geändert werden?"},
    ],
    max_tokens=256,
)

u = resp.usage
print("Eingabe", u.prompt_tokens)
print("Ausgabe", u.completion_tokens)
print("Gesamt", u.total_tokens)

Mindestens diese Felder erfassen: Zeit, Projekt, Modell, Eingabe-Token, Ausgabe-Token, Cache-Treffer, Wiederholungszahl und ob Streaming verwendet wurde. Beträge erst am Monatsende mit dem Stückpreis der Preisseite multiplizieren; Prozesskennzahlen täglich ansehen.

6. Von der Schätzung zur Rechnung: welche Reserven das Budget braucht

Für das Budget vier Blöcke getrennt schätzen und dann addieren: Grundverbrauch, Spitzenverbrauch, Wiederholungen und Fehler, Cache-Fehltreffer.

Beim Abgleich auf drei Unterschiede achten:

  • Vorausbezahltes Guthaben wird üblicherweise um den Betrag inklusive Steuern reduziert, während das Ausgabenlimit oft vor Steuern rechnet; beide können auseinanderlaufen.
  • Ein monatliches Ausgabenlimit auf Organisationsebene gilt für alle Workspaces; das Limit eines einzelnen Workspace darf das Organisationslimit nicht überschreiten.
  • Bei zu geringem Guthaben können Anfragen oberhalb des Tarifvolumens HTTP 402 zurückgeben; das ist kein Modellfehler, sondern ein Rechnungsstatus.

Das Mistral-Abrechnungsbackend bietet Rechnungslisten und PDF-Downloads; vorausbezahlte Aufladung, Tarifgebühren und Verbrauchsgebühren erscheinen getrennt. Für die Erstattung im Unternehmen Rechnung, Bestellnummer, Zahlungsbeleg und Verbrauchsdetails gemeinsam archivieren. Der konkrete Rechnungsablauf ist im Mistral API Auflade-Tutorial beschrieben.

7. Reihenfolge der Kostensenkung nicht umdrehen

  1. Zuerst messen: mit usage und Protokollen Eingabe- und Ausgabestruktur jeder Funktion klären, nicht nach Gefühl.
  2. Dann Cache-Treffer erhöhen: System-Prompt, Tool-Definitionen und Wissenspräfix stabil halten, dynamische Inhalte ans Ende verschieben.
  3. Dann Eingabe reduzieren: Verlauf zusammenfassen, nur relevante Suchausschnitte mitgeben, Tool-Ausgaben auf nötige Felder begrenzen.
  4. Ausgabe begrenzen: sinnvolle max_tokens, feste Felder oder JSON verlangen, wiederholte Erklärungen vermeiden.
  5. Modellrouting einführen: Klassifikation, Extraktion und Umschreibung mit leichten Modellen, komplexe Schlussfolgerungen mit größeren.
  6. Batch prüfen: Aufgaben ohne Echtzeitanforderung in die Warteschlange geben und eine andere Preisstufe nutzen.
  7. Überwachen und warnen: Verbrauch nach Projekt, Modell und Szenario betrachten, Budgetgrenzen und Guthabenwarnungen setzen.

Bei umgekehrter Reihenfolge ist das häufige Ergebnis: ein günstigeres Modell gewählt, aber Eingabe nicht bereinigt, Cache nicht getroffen, die Rechnung kaum gesenkt und die Qualität zuerst gesunken.

Häufige Fragen

Wird die Mistral API nach Aufrufen oder nach Token abgerechnet?

Sprachmodelle werden nach Eingabe- und Ausgabe-Token abgerechnet, nicht nach Aufrufen. Spezialmodelle für OCR, Spracherkennung und Sprachsynthese nutzen Seiten, Minuten oder Zeichen; maßgeblich ist die offizielle Preisseite.

Warum steigt die Rechnung mit längerem Kontext schneller?

Weil bei jeder Runde der bisherige Inhalt erneut gesendet wird und die Eingabe-Token mit der Rundenzahl akkumulieren. Selbst wenn die neue Frage kurz ist, steigen die Kosten ohne Kürzung des Verlaufs weiter.

Warum greift die gecachte Eingabe nicht?

Häufige Ursache ist ein instabiles Präfix: Zeitstempel, Zufalls-IDs oder Nutzerinformationen am Anfang oder eine jedes Mal neu sortierte Reihenfolge von Tools und Dokumenten. Zuerst veränderliche Inhalte ans Ende der Anfrage verschieben und dann erneut beobachten.

Werden wiederholte Anfragen berechnet?

Das hängt davon ab, ob der Fehler vor oder nach der Abrechnung auftritt, und von der aktuellen Rechnungslogik. Technisch Wiederholungszahl begrenzen, Backoff verwenden und Schreiboperationen idempotent gestalten, um doppelten Verbrauch zu vermeiden.

Was tun, wenn Schätzung und Rechnung nicht übereinstimmen?

Zuerst prüfen, ob Verlauf, Tool-Definitionen, Wiederholungen, Cache-Fehltreffer und Batch-Stufenunterschiede übersehen wurden, dann Anfrage-IDs gegen das Verbrauchsprotokoll halten. Bleibt die Abweichung unerklärt, Rechnungsdetails und Verbrauchsaufzeichnungen gemeinsam prüfen.

Nächster Schritt

Zuerst bei ZSQH AI Gateway einen Test-Key anlegen, eine Woche mit echten Aufgaben Eingabe, Ausgabe und Cache-Treffer erfassen und dann anhand von Modellpreise das Budget berechnen. Modellverfügbarkeit und Preise richten sich nach der Preisseite.

Weiterlesen: