Die Qwen-API ist die Aufrufschnittstelle für die Tongyi-Qianwen-Modelle von Alibaba Cloud Bailian (Alibaba Cloud Model Studio). Der von Entwicklern oft verwendete Name DashScope bezeichnet die API- und SDK-Schicht dieses Dienstes. Drei Namen, aber nur eine Abrechnungslogik: nach tatsächlichem Verbrauch, Eingabe und Ausgabe getrennt.
Dieser Artikel schreibt keine Stückpreise fest, weil sich Modellversionen, Kontextstufen und Rabattaktionen ändern. Wir erklären, wohin das Geld fließt, warum langer Kontext das Budget leicht sprengt, wie man Cache und Batch einsetzt und wie man mit echten Logs eine Monatsschätzung erstellt. Aktuelle Preise entnehmen Sie der Seite Modellpreise und der Preisliste von Alibaba Cloud Bailian.
Hinweis: Qwen, Tongyi Qianwen, Alibaba Cloud, Bailian, Model Studio und DashScope 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 Alibaba Cloud. Abrechnungsregeln und Preise können sich ändern; prüfen Sie vor einer Bestellung die Anbieterdokumentation.
1. Zuerst die Namen: Bailian, Model Studio und DashScope
Diese drei Namen werden häufig vermischt, bezeichnen aber nicht dieselbe Ebene:
- Alibaba Cloud Bailian: chinesische Konsole und Produktname; Modellfreischaltung, API-Key, Verbrauch und Rechnung laufen hier zusammen.
- Alibaba Cloud Model Studio: englischer Produktname für den internationalen Markt; die Funktionen entsprechen Bailian, Regionen und Abrechnungswährung können abweichen.
- DashScope: Name der API- und SDK-Schicht, zu finden in Base-URLs, der Umgebungsvariable
DASHSCOPE_API_KEYund älteren Dokumenten.
Beim Aufruf sind drei Dinge zu klären: Region (etwa Peking oder Singapur), Base-URL und Modell-ID. Passen sie nicht zusammen, lautet der häufigste Fehler nicht „Guthaben aufgebraucht“, sondern Authentifizierungsfehler oder Modell nicht gefunden.
2. Die Modellstufe bestimmt die Kostenobergrenze
Qwen-Textmodelle sind üblicherweise in drei Stufen unterteilt; typische Vertreter im Jahr 2026 sind Qwen-Max, Qwen-Plus und Qwen-Flash:
| Stufe | Beispiel-Modell-ID | Ausrichtung | Geeignete Aufgaben | Kostenordnung |
|---|---|---|---|---|
| Max | qwen3.8-max | Komplexe Schlussfolgerungen und mehrstufige Aufgaben | Code, Agenten, tiefe Analyse | Hoch |
| Plus | qwen3.7-plus | Balance aus Leistung, Geschwindigkeit und Kosten | Kundenservice, Textarbeit, Dokumentverarbeitung | Mittel |
| Flash | qwen3.8-flash | Niedrige Latenz, niedrige Kosten | Klassifikation, Extraktion, Umschreiben, Routing | Niedrig |
Modell-IDs werden weiterentwickelt; verlassen Sie sich beim Einkauf nicht auf feste Namen. Stabiler ist es, „Aufgabentyp“ und „Stufe“ zu verbinden: einfache Aufgaben standardmäßig mit Flash, Alltagsaufgaben mit Plus, und nur wenn wirklich mehrstufiges Schlussfolgern nötig ist, auf Max wechseln. Max für die gesamte Anwendung ist nicht zwangsläufig besser, aber die Rechnung fällt sicher höher aus.
3. Abrechnungseinheit: Eingabe, Ausgabe und Multimodalität
Textmodelle werden nach Eingabe-Tokens und Ausgabe-Tokens getrennt abgerechnet; die Preisliste zeigt üblicherweise „CNY pro Million Tokens“. Die Kosten einer Anfrage lassen sich so schreiben:
Kosten pro Aufruf =
Eingabe-Tokens ohne Cache-Treffer × Eingabepreis
+ Tokens mit Cache-Treffer × Cache-Preis
+ Ausgabe-Tokens × Ausgabepreis
Multimodalität ist separat zu betrachten: Bildgenerierung wird oft nach erfolgreich ausgegebenen Bildern abgerechnet, Sprache nach Audiodauer, und Omni- sowie Realtime-Modelle haben eigene Preise für Text, Bild und Audio. Wer diese Kosten in das Textbudget mischt, bekommt am Monatsende keine stimmige Abrechnung.
Übersetzungsmodelle wie Qwen-MT-Uni berechnen außerdem nur Eingabe-Tokens; bei manchen Modellen unterscheidet sich im Denkmodus die Abrechnung der Ausgabe-Tokens von einer normalen Antwort. Sehen Sie für jedes Modell zuerst die Spalte „Abrechnungsposition“ in der Preisliste an und übertragen Sie nicht die Preise eines anderen Modells.
4. Langer Kontext: Die Stufe gilt für die gesamte Anfrage
Dies ist der am leichtesten übersehene Punkt in der Qwen-Abrechnung. Die Preisliste staffelt nach der gesamten Eingabe-Token-Menge einer Anfrage; übliche Stufen sind:
- 0 < Token ≤ 32K
- 32K < Token ≤ 128K
- 128K < Token ≤ 256K
- 256K < Token ≤ 1M
Entscheidend ist, dass die Stufe „für die gesamte Anfrage“ gilt: In welche Stufe eine Anfrage fällt, danach werden alle Tokens dieser Anfrage – einschließlich der Ausgabe – abgerechnet. Es wird nicht etwa für die ersten 32K der niedrige Preis und für den Rest der höhere Preis segmentweise summiert. Steigt die Eingabe von 31K auf 33K, kostet das also möglicherweise nicht nur 2K mehr, sondern die ganze Anfrage wechselt die Preisstufe.
Langer Kontext sollte daher gezielt eingesetzt werden. Bei Verträgen, wissenschaftlichen Arbeiten oder Codebasen stellen Sie zuerst drei Fragen: 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. Wenn langer Kontext wirklich nötig ist, wählen Sie bevorzugt ein Modell mit passender Stufe und prüfen Sie die Rechnung mit einer echten Anfrage.
5. Cache und Batch: Ersparnis möglich, aber nicht kombinierbar
Context-Caching rabattiert nur Eingabe-Tokens. Es gibt expliziten und impliziten Cache: Der explizite Cache erfordert manuell angelegte Cache-Punkte; das Anlegen selbst kann zu einem Preis über dem Standard-Eingabepreis abgerechnet werden, Treffer danach zum Rabattpreis. Der implizite Cache erkennt wiederkehrende Präfixe automatisch und ist bei einigen Modellen standardmäßig aktiv. In den Beispielen der Dokumentation kostet das Anlegen etwa 125 % des Standard-Eingabepreises und ein Treffer etwa 10 %; die Verhältnisse unterscheiden sich jedoch je nach Modell und richten sich nach der Cache-Dokumentation.
Batch eignet sich für Offline-Aufgaben. Bei unterstützten Modellen werden Ein- und Ausgabepreis bei Batch-Aufrufen üblicherweise mit 50 % des Echtzeitpreises berechnet; der Preis dafür sind höhere Latenz und zusätzlicher Aufwand für die Aufgabensteuerung. Beachten Sie: Cache-Rabatt und Batch-Rabatt gelten in der Regel nicht gleichzeitig; addieren Sie beide nicht im selben Budgetmodell.
Ob ein Cache-Treffer gelingt, hängt von der Stabilität des Präfixes ab. Wenn sich System-Prompt, Tool-Definitionen und Wissensdatenbank-Fragmente bei jedem Aufruf in ihrer Reihenfolge ändern, sinkt die Trefferquote. Stabile Inhalte nach vorn und veränderliche Inhalte nach hinten zu stellen, ist die grundlegendste Optimierung.
6. Retries, Fehler und versteckte Kosten
Laut Abrechnungsseite werden fehlgeschlagene Anfragen nicht berechnet. „Fehlgeschlagen“ meint jedoch eine eindeutige Fehlerantwort des Servers und nicht eine neue Anfrage, die der Client nach einem Timeout selbst auslöst. Zeitüberschreitungen mit erneutem Senden, mehrfaches Klicken von Nutzern und doppelt verarbeitete Warteschlangen erzeugen neue, kostenpflichtige Anfragen.
Bei Rate-Limits und 5xx-Fehlern sollte man zurückhaltend wiederholen: nur wiederholbare Fehler erneut senden, exponentiellen Backoff verwenden, eine Obergrenze setzen und über eine Request-ID Idempotenz herstellen. Ob bei einem abgebrochenen Stream der bereits erzeugte Teil berechnet wird, richtet sich nach Rechnung und Anbieterdokumentation; „Fehler sind kostenlos“ ist kein Grund für unbegrenzte Retries.
Eine weitere oft übersehene Kostenposition ist der Personalaufwand, der für die Einsparung von Aufrufgebühren entsteht. Logging, Monitoring, Evaluation und manuelle Prüfung sind ebenfalls Kosten. Kostenoptimierung muss die Gesamtkosten betrachten, nicht nur den Stückpreis.
7. Monatsbudget mit echten Logs schätzen
Das Budget sollte nicht aus dem Bauch heraus entstehen. Gehen Sie in dieser Reihenfolge vor:
- Exportieren Sie aus dem Gateway oder der Bailian-Rechnung die Anfrage-Logs der letzten 7 Tage, mindestens mit Modell-ID, Eingabe-Tokens, Ausgabe-Tokens, Cache-Treffer und Batch-Kennzeichen.
- Gruppieren Sie nach Modell und Kontextstufe und berechnen Sie pro Gruppe Anfragezahl und durchschnittliche Tokens.
- Setzen Sie die Preise der aktuellen Preisliste in die Formel ein; beachten Sie, dass langer Kontext für die gesamte Anfrage gilt.
- Multiplizieren Sie mit 30 Tagen und addieren Sie 10 %–20 % Reserve für Retries und Schwankungen.
- Prüfen Sie monatlich nach und schätzen Sie nach Modell-Upgrades oder Prompt-Änderungen neu.
Wenn das Team mehrere Modellanbieter nutzt, kann es sich bei ZSQH AI Gateway registrieren und Guthaben sowie Verbrauch zentral einsehen; maßgeblich bleiben die Stückpreise auf der Seite Modellpreise.
8. Reihenfolge der Kostensenkung
Nach Aufwand und Wirkung sortiert sieht die Reihenfolge meist so aus:
- Zuerst messen: Ohne Logs auf Anfrageebene ist jede Optimierung Spekulation.
- Die richtige Stufe wählen: Einfache Aufgaben auf Flash verlagern, nicht mit Max klassifizieren.
- Eingabe straffen: Retrieval, Zusammenfassung und Kürzung des Verlaufs wirken besser als ein Modellwechsel.
- Ausgabe begrenzen:
max_tokenssetzen und strukturierte Ausgabe verlangen. - Präfix stabilisieren: Cache-Trefferquote erhöhen, aber zuerst die Kosten der Cache-Erstellung prüfen.
- Offline über Batch: Kennzeichnung, Zusammenfassung und Bereinigung sind nicht eilig und eignen sich für Batch.
- Retries kontrollieren: Backoff, Idempotenz und Deduplizierung, damit eine Störung nicht zur doppelten Rechnung wird.
- Budgetwarnungen einrichten: Schwellenwerte je Projekt, Key und Modell.
9. Häufige Fragen
Wie hängen Qwen API, Bailian und DashScope zusammen?
Bailian ist die Plattform von Alibaba Cloud für große Modelle, Model Studio ist der internationale Produktname, und DashScope ist die API-/SDK-Schicht. Wenn man im Alltag von „Qwen API aufrufen“ spricht, meint man meist den Aufruf über die DashScope-kompatible oder OpenAI-kompatible Schnittstelle von Bailian.
Warum wird die gesamte Anfrage durch langen Kontext teurer?
Weil die Preisstufe durch die gesamte Eingabe-Token-Menge einer Anfrage bestimmt wird. Fällt die Anfrage in eine höhere Stufe, werden Eingabe und Ausgabe der gesamten Anfrage zu diesem Stufenpreis abgerechnet; nur der überschreitende Teil wird nicht separat verteuert. Eine Eingabe von 33K in zwei Anfragen zu je 16K aufzuteilen kann günstiger sein als eine 33K-Anfrage, sofern die Aufteilung die Qualität nicht beeinträchtigt.
Lassen sich Cache und Batch gleichzeitig nutzen?
In der Regel nicht. Die Preisliste beschreibt sie als Alternative. Bei Offline-Aufgaben hat Batch Vorrang, bei häufigen Online-Aufgaben mit stabilem Präfix der Cache.
Werden fehlgeschlagene Anfragen berechnet?
Laut Anbieterdokumentation werden fehlgeschlagene Anfragen nicht berechnet. Ein erneutes Senden nach Client-Timeout, doppelte Übermittlung oder die Fortsetzung nach einem Stream-Abbruch können jedoch neue kostenpflichtige Anfragen erzeugen. Unterscheiden Sie mit Request-ID und Idempotenzschlüssel zwischen „Retry“ und „neuer Anfrage“.
Warum stimmen Konsolenrechnung und lokale Schätzung nicht überein?
Vier häufige Ursachen: Die Kontextstufe wurde nicht berücksichtigt, die Kosten der Cache-Erstellung fehlen, Batch und Cache wurden addiert, oder Retry-Anfragen sind nicht erfasst. Mit dem usage-Feld und Request-IDs lässt sich die Abweichung meist bis zur konkreten Anfrage zurückverfolgen.
Nächste Schritte
Exportieren Sie zuerst den tatsächlichen Verbrauch der letzten Woche, gruppieren Sie ihn nach Modell und Stufe und setzen Sie die aktuellen Preise ein. Wer Yuan-Guthaben benötigt und den Verbrauch mehrerer Modelle zentral sehen möchte, kann sich bei ZSQH AI Gateway registrieren; maßgeblich sind die Preise auf der Seite Modellpreise.
Verwandte Artikel:
