Qwen3.5-Omni API-Preise, Limits und Bereitstellungsoptionen (2026)

Hey Leute! Hier ist Dora — ich teile mit euch die Überraschung, die ich hatte, als ich den Qwen3.5-Omni-Launch Ende März sah. In diesem Moment war mein erster Instinkt nicht „wow, cooles Modell”, sondern: Was wird mich das eigentlich pro Aufruf kosten?

Denn so ist das — ich habe mich schon früher verbrannt. Ich hatte eine Pipeline auf einem glänzenden neuen multimodalen API gebaut, die Abrechnungsdokumentation nicht sorgfältig genug gelesen, und dann zugeschaut, wie meine monatliche Rechnung sich vervierfachte, sobald die Audioverarbeitung die längeren Kontextbereiche erreichte. Also setzte ich mich diesmal mit der DashScope-Preisdokumentation und der offiziellen API-Referenz hin, bevor ich eine einzige Zeile Integrationscode schrieb.

Wenn du ein Engineering-Lead oder Infrastruktur-Entscheidungsträger bist und evaluierst, ob du auf Qwen3.5-Omni aufbauen oder es selbst hosten sollst, behandelt dieser Artikel die Dinge, die für dein Kostenmodell wirklich wichtig sind — einschließlich einer Preisstruktur, die aufrichtig gesagt wenig intuitiv ist, bis man sich eine Weile damit beschäftigt.

Wie Qwen3.5-Omni berechnet wird

DashScope-Stufenpreisgestaltung: Eingabe-Token-basiertes Modell

Das Wichtigste, was man vorab verstehen muss: DashScope berechnet keinen pauschalen Token-Preis. Bei Qwen3.5-Omni (und mehreren anderen Qwen-Modellen, darunter qwen3.5-plus) ist die Preisgestaltung stufenweise nach der Anzahl der Eingabe-Token in der aktuellen Anfrage gestaffelt. Nicht kumulierte Sitzungs-Token — die Eingabegröße der einzelnen Anfrage bestimmt, in welche Preisklasse du fällst.

Das ist nicht offensichtlich und hat reale Auswirkungen. Eine kurze Anfrage mit 5.000 Token und eine maximal ausgereizte Anfrage mit 240.000 Token werden nicht nur proportional unterschiedlich berechnet — sie fallen in vollständig unterschiedliche Preisklassen. Die Struktur belohnt kurze Anfragen, was direkt im Konflikt mit dem Grund stehen kann, warum man überhaupt zu einem 256K-Kontextmodell greift.

Die offizielle DashScope-Preisseite zeigt diese Stufenstruktur, die auf die Qwen-Plus- und verwandte Modellfamilien angewendet wird. Spezifische Omni-Modalitätspreise pro Audio-Token und Videoframe sind separat im Abschnitt zur multimodalen Abrechnung dokumentiert.

Plus vs. Flash vs. Light: Kosten-Leistungs-Spektrum

Qwen3.5-Omni wird in drei Varianten mit unterschiedlicher Positionierung angeboten:

Plus ist das Benchmark-Hauptmodell — es ist dasjenige, das Gemini 3.1 Pro beim Audio-Verständnis übertroffen hat. Flash tauscht einen Teil dieser Fähigkeit gegen niedrigere Latenz und vermutlich niedrigere Kosten pro Aufruf. Light ist die Open-Weight-Stufe: kostenlos zu betreiben, aber du trägst die Infrastrukturverantwortung.

Für API-Nutzer ist die praktische Entscheidung Plus vs. Flash. Wenn dein Anwendungsfall hochpräzise Transkription langer Aufnahmen oder Sprachklonierung für ein kundenorientiertes Produkt ist, ist Plus die richtige Wahl. Wenn du Echtzeit-Konversation mit engeren Latenzbudgets machst, lohnt es sich, Flash zuerst zu testen.

Freies Kontingent: Was enthalten ist und wann es ausläuft

Neue DashScope-Konten in der internationalen Region (Singapur-Endpunkt) erhalten ein kostenloses Kontingent von 1 Million Eingabe-Token und 1 Million Ausgabe-Token, gültig für 90 Tage nach der Aktivierung von Model Studio. Der globale Bereitstellungsmodus (US Virginia) hat kein kostenloses Kontingent — das ist wichtig, wenn dein Team in den USA ansässig ist und vom nächstgelegenen Endpunkt aus testen möchte.

Das kostenlose Kontingent wird schneller aufgebraucht, als du erwartest, wenn du umfangreiche Audiotests durchführst. Eine einzige 10-stündige Audiodatei trifft die volle 256K-Kontextgrenze, was allein etwa 256K deines 1-Millionen-Eingabe-Token-Kontingents in einer einzigen Anfrage verbraucht.

Kontextfenster-Ökonomie

256K Token in der Praxis: Audiostunden, Videosekunden und was es tatsächlich kostet

Die offizielle Zahl besagt, dass 256K Token „über 10 Stunden kontinuierliches Audio” oder „ungefähr 400 Sekunden 720p-Video mit Audio” verarbeiten kann. Lass uns das in Kostenintuitionen übersetzen.

Audio wird mit ungefähr 25.600 Token pro Stunde tokenisiert (256K ÷ 10 Stunden). Das sind ungefähr 427 Token pro Audiominute. Bei Video mit 1-FPS-Sampling füllen 400 Sekunden 720p-Content den vollen Kontext.

Setzt man dies gegen die gestaffelten Preisklassen, ergeben sich zwei Szenarien:

Kurze Anfrage (z.B. 5-Minuten-Meeting-Clip ≈ ~2.100 Token): Fällt in die niedrigste Preisstufe. Günstig pro Aufruf.

Lange Anfrage (z.B. 3-Stunden-Podcast ≈ ~77.000 Token): Überschreitet die mittlere Preisklasse. Der Token-Preis steigt, sodass die Kosten pro Audiominute erheblich höher sind als im Kurzanfrage-Szenario — nicht weil mehr Token verwendet werden, sondern weil die Stufe anders ist.

Fast-maximale Anfrage (z.B. 8-Stunden-Audiodatei ≈ ~205.000 Token): Du befindest dich in der höchsten Stufe. Ein voller Arbeitstag Audio zum Toppreis kostet erheblich mehr als 40 äquivalente 12-Minuten-Clips, die einzeln verarbeitet werden. Das ist die Architekturentscheidung, die das Stufenmodell erzwingt: lange Eingaben bündeln vs. aufteilen.

Für Entwickler, die hochvolumige Audioverarbeitung betreiben, kann Aufteilen tatsächlich günstiger sein als die Ausnutzung des vollen Kontextfensters — was ironisch ist, da der große Kontext teilweise das Verkaufsargument ist.

Wann lange Kontextaudio-Eingaben teuer werden

Es gibt einen Break-even-Punkt irgendwo zwischen kurzem und langem Kontext, an dem Aufteilen kostenmäßig gewinnt. Genaue Zahlen hängen von deiner spezifischen Modalitätspreisgestaltung ab (Audio-Token-Preise unterscheiden sich von Text-Token-Preisen in der DashScope-Abrechnung), daher empfehle ich, einen schnellen Rechner zu erstellen, bevor du dich auf eine Architektur festlegst: Führe deine erwartete Audiolängenverteilung durch sowohl die gestaffelte Preisformel als auch einen chunk-basierten Ansatz.

Ratenlimits und Durchsatz

Was über QPS-/Parallelitätslimits bekannt ist

Ratenlimit-Details für Qwen3.5-Omni sind nicht im gleichen Detailgrad öffentlich dokumentiert wie bei reinen Textmodellen. Das allgemeine Muster von DashScope für API-Nutzer sind QPS- (Queries per Second) und Parallelitätslimits, die auf Kontoebene angewendet werden und über Kontingenterhöhungsanfragen für Enterprise-Konten angepasst werden können. Wenn du bestätigte Zahlen für die Kapazitätsplanung benötigst, stelle eine Kontingenterhöhungsanfrage beim DashScope-Support — sie antworten mit den tatsächlichen Limits für deine Kontostufe.

DashScope International vs. China-Festland-Endpunkte

Es gibt drei Hauptendpunkt-Regionen für Teams außerhalb Chinas:

International (Singapur): https://dashscope-intl.aliyuncs.com/compatible-mode/v1 — Daten und Endpunkt in Singapur, Inferenz global geplant (außer Festlandchina). Dies ist der Standard für die meisten internationalen Entwickler. Kostenloses Kontingent gilt.
Global (US Virginia / Deutschland Frankfurt): https://dashscope-us.aliyuncs.com/compatible-mode/v1 — Daten und Endpunkt in der Region US Virginia, Compute global geplant. Kein kostenloses Kontingent. Besser für US-basierte Latenzanforderungen.
China-Festland (Peking): https://dashscope.aliyuncs.com/compatible-mode/v1 — beschränkt auf Teams, die in China tätig sind. Erheblich niedrigere Token-Preise.

US-Region-Verfügbarkeit (Virginia-Endpunkt)

Der US-Endpunkt (Virginia) ist für Qwen-Textmodelle verfügbar. Bestätige zum aktuellen Zeitpunkt direkt über die DashScope-API-Referenz, ob die multimodale Inferenz von Qwen3.5-Omni über den US-Endpunkt geroutet wird oder auf Singapur zurückfällt. Das allgemeine multimodale Endpunktmuster ist:

POST https://dashscope-us.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation

Für Teams mit Anforderungen zur Datenhaltung: Kläre mit Alibaba Cloud, ob Audio-/Videoinhalte, die über den US-Endpunkt verarbeitet werden, zu irgendeinem Zeitpunkt in der Inferenz-Pipeline außerhalb der USA gespeichert werden.

Self-Hosting mit vLLM

Warum das Qwen-Team vLLM gegenüber HuggingFace Transformers für MoE empfiehlt

Qwen3.5-Omni-Plus verwendet eine Hybrid-Attention Mixture-of-Experts (MoE)-Architektur. Das Qwen-Team empfiehlt explizit vLLM gegenüber HuggingFace Transformers für jede Produktionsauslastung — und der Grund ist spezifisch für MoE: Expert-Routing in MoE-Modellen verursacht unregelmäßige Speicherzugriffsmuster, die HuggingFace Transformers nicht gut optimiert. vLLMs PagedAttention und MoE-bewusstes Scheduling handhabt dies erheblich besser und führt zu echten Durchsatzunterschieden unter Last. Für groß angelegte Aufrufe oder Niedriglatenz-Anforderungen lautet die offizielle Empfehlung vLLM oder die DashScope-API direkt — nicht rohe Transformers.

Infrastrukturanforderungen für Plus (30B-A3B-Klasse)

Die Plus-Variante (30B Gesamtparameter, 3B aktiv pro Token) benötigt mindestens 40 GB VRAM für komfortable Inferenz in BF16. In der Praxis:

Einzelne A100 80GB: Machbar für Plus in FP8- oder INT8-Quantisierung. BF16 bei vollem Kontext ist eng.
Einzelne H100 80GB: Komfortabel in BF16 mit Puffer für KV-Cache bei kürzeren Kontexten.
RTX 4090 (24 GB): Nicht ausreichend für Plus. Funktioniert für Flash- oder Light-Varianten mit Quantisierung.

Bei den Omni-Modellen musst du speziell auch den Speicher der Talker-Komponente mit ihrem Audio-Codec berücksichtigen — es geht nicht nur um die Sprachmodellgewichte. Die 48-GB-VRAM-RTX-4090D wurde berichtet, dass sie den Qwen3-Omni 30B-A3B bei AWQ-4-Bit-Quantisierung ausführt, allerdings mit minimalem KV-Cache-Spielraum und einem Durchsatz von etwa 64 Token/s Generierung.

Docker-Image-Verfügbarkeit und Einrichtung

Das Qwen-Team stellt ein Docker-Image bereit, das die vollständige Laufzeitumgebung für HuggingFace Transformers und vLLM bündelt. Verwende es — die manuelle Einrichtung des Omni-spezifischen vLLM-Forks (Branch qwen3_omni) ist umständlich. Installation mit dem offiziellen Stack:

# Clone the Omni-specific vLLM fork
git clone -b qwen3_omni https://github.com/wangxiongts/vllm.git
cd vllm

# Install dependencies
pip install -r requirements/build.txt
pip install -r requirements/cuda.txt
VLLM_USE_PRECOMPILED=1 pip install -e . -v --no-build-isolation

# Install required packages
pip install transformers==4.57.3 accelerate
pip install qwen-omni-utils -U
pip install -U flash-attn --no-build-isolation

Dann starten:

vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

Die Begrenzung max-model-len 32768 ist praktisch für Einzelnen-GPU-Setups — das Pushen in Richtung 256K-Kontext auf einer einzelnen 80-GB-Karte erfordert aggressive Quantisierung und begrenzt die Batch-Größe erheblich. Gemäß vLLMs eigener Bereitstellungsdokumentation handhabt PagedAttention den KV-Cache-Speicher effizient, aber Audio-visuelle Modelle mit Multi-Codebook-Talker-Ausgaben haben höheren KV-Cache-Druck als reine Textäquivalente.

DashScope-API vs. Self-Hosting: Entscheidungsrahmen

Wann DashScope sinnvoll ist

Du musst innerhalb von Tagen, nicht Wochen, in Produktion sein
Dein monatliches Token-Volumen liegt unter ~50 Millionen Token (API-Stückkosten noch günstig)
Du hast keine GPU-Infrastruktur und möchtest keine aufbauen
Die Sprachklonierungsfunktion ist wichtig — sie ist nur über die API für Plus und Flash verfügbar; die Open-Weights von Light machen sie nicht zugänglich
Du benötigst Singapur- oder US-regionale Datenrouting mit vertraglichen Garantien

Wann Self-Hosting sinnvoll ist

Monatliches Volumen konstant über 50–100 Millionen Token und Kosten pro Token sind bedeutsam
Anforderungen zur Datenhaltung, die die regionalen Endpunkte von DashScope nicht erfüllen
Latenzsteuerung für Antwortziele unter 200 ms, die von Co-Location abhängen
Du betreibst Flash- oder Light-Tier-Workloads, bei denen die Hardware in deine bestehende Flotte passt
Benutzerdefiniertes Fine-Tuning oder Modifikationen (nur mit Open Weights möglich — Light-Tier)

Der praktische Wendepunkt: Bei hohem Volumen wird der Betrieb von Plus auf einer dedizierten H100 zu ~2–3 $/h Cloud-Kosten günstiger als der DashScope-Per-Call-Preis. Die Rechnung ändert sich je nach Auslastung — eine GPU, die 40 % der Zeit im Leerlauf ist, verändert die Kalkulation erheblich.

Versteckte Kostenüberlegungen

Audio-/Video-Vorverarbeitungsoverhead

Audio, das an Qwen3.5-Omni gesendet wird, muss vor dem API-Aufruf im richtigen Format vorliegen. Die Bibliothek qwen-omni-utils übernimmt Resampling, Kanalnormalisierung und Chunk-Encoding — aber diese Vorverarbeitung fügt auf deiner Seite Latenz und Rechenaufwand hinzu. Bei Video ist 1-FPS-Sampling bei 720p die dokumentierte Referenzrate, aber die tatsächliche Frame-Extraktion aus beliebigen Videoformaten erfordert FFmpeg oder Ähnliches. Berücksichtige dies in deinem Latenzbudget pro Aufruf.

Streaming-Sprachausgabe und Kosten pro Aufruf

Die Thinker-Talker-Architektur streamt die Sprachausgabe in Echtzeit — die ersten Audio-Bytes treffen ein, bevor die vollständige Antwort generiert ist, was Live-Sprachgespräche natürlich wirken lässt. Aber Streaming fügt einen Overhead pro Aufruf hinzu: Verbindungen bleiben länger offen, und der Audio-Codec (Code2Wav-Renderer) generiert Multi-Codebook-Sequenzen, die zur Ausgabe-Token-Anzahl beitragen. Wenn du den Sprachausgabemodus verwendest, ist deine effektive Ausgabe-Token-Anzahl höher als im Nur-Text-Modus bei der gleichen zugrunde liegenden Antwort. Prüfe, ob DashScope Sprachausgabe-Token zum gleichen Preis wie Text-Ausgabe-Token abrechnet — die Abrechnungsdokumentation unterscheidet Modalitäten im Abschnitt zur multimodalen Preisgestaltung.

FAQ

Gibt es eine kostenlose Stufe für Qwen3.5-Omni auf DashScope?

Ja, für die internationale Region (Singapur-Endpunkt). Neue Konten erhalten 1 Million Eingabe-Token und 1 Million Ausgabe-Token kostenlos, gültig für 90 Tage nach der Aktivierung von Model Studio. Der globale Bereitstellungsmodus (US Virginia) hat kein kostenloses Kontingent.

Wie hoch ist das Ratenlimit auf der DashScope-API?

Nicht öffentlich auf einer spezifischen QPS-Zahl für Qwen3.5-Omni dokumentiert, Stand März 2026. Standardlimits gelten bei der Kontoerstellung; wende dich an den DashScope-Support mit deinem erwarteten Durchsatz, um eine Kontingenterhöhung anzufordern, bevor du in Produktion gehst.

Kann ich Qwen3.5-Omni-Plus auf einer einzelnen A100 betreiben?

In FP8- oder INT8-Quantisierung ja — eine A100 80GB kann Plus mit eingeschränktem KV-Cache-Spielraum betreiben. In BF16 bei 256K-Kontext nein. Erwarte, max-model-len auf etwa 32K–64K auf einer einzelnen 80-GB-GPU zu begrenzen, um stabilen Durchsatz aufrechtzuerhalten.

Frühere Beiträge: