← Blog

Was ist Qwen3.5-Omni: Fähigkeiten, Varianten und API-Zugang

Qwen3.5-Omni wurde gerade mit den Varianten Plus, Flash und Light veröffentlicht. Das müssen Entwickler über Fähigkeiten, API-Zugang und den produktiven Einsatz wissen.

11 min read
Was ist Qwen3.5-Omni: Fähigkeiten, Varianten und API-Zugang

Hallo zusammen! Hier ist wieder Dora! Ich war mitten in einem Video-Projekt am Schneiden, als die Benachrichtigung eintraf: Qwen3.5-Omni ist soeben erschienen. Ich nutze die Qwen3-Omni-Familie seit Monaten in einigen Produktions-Workflows, daher wusste ich sofort, dass das kein kleiner Patch ist. Ein 256K-Kontextfenster, Stimmenklonen, semantische Unterbrechung und 113 Sprachen für die Spracherkennung — alles in einem Modell. Ich musste aufhören, was ich gerade tat.

Wenn du Sprach-Agenten, Untertitel-Pipelines oder irgendetwas baust, das echtes menschliches Audio und Video gemeinsam verarbeiten muss, ist dieses Release direkt relevant für dich. Ich erkläre, was es tatsächlich leistet, was die drei Varianten in der Praxis bedeuten und wie du Zugang bekommst — einschließlich dessen, was heute noch unklar ist.

Was Qwen3.5-Omni tatsächlich leistet

Text, Bild, Audio und Video in einem einzigen Inferenz-Aufruf

Hier ist das, was in KI-Ankündigungen immer wieder unterschätzt wird: Native multimodale Verarbeitung und zusammengestückte multimodale Pipeline-Verarbeitung sind nicht dasselbe.

Wenn ein nicht-omnimodales Modell wie ChatGPT 5.4​ ​ein Video erhält, muss es Frames über ein Vision-Modell extrahieren, Audio durch etwas wie Whisper zur Transkription laufen lassen und OCR anwenden, um eingebettete Untertitel zu lesen — drei separate Prozesse, die zusammengeflickt werden, um das anzunähern, was ein echtes Omni-Modell in einem einzigen Durchlauf erledigt. Unter idealen Bedingungen, mit einem gut beleuchteten Clip und sauberem Audio, dauerte das in einem realen Test neun Minuten.

Qwen3.5-Omni verarbeitet dieselbe Eingabe in einem Aufruf. Du sendest das Video. Du erhältst eine Antwort. Keine Zwischenpipeline. Kein Format-Konvertierungs-Overhead. Kein Audio-Modell, das nicht weiß, was auf dem Bildschirm passiert, und kein Vision-Modell, das nichts hören kann.

Das Modell unterstützt Text-, Bild-, Audio- und Audio-Video-Verständnis, wobei sowohl die Thinker- als auch die Talker-Komponenten eine Hybrid-Attention-MoE-Architektur verwenden. Dieser letzte Punkt ist wichtiger, als er klingt — dazu komme ich im Architekturabschnitt weiter unten.

Was “Omnimodal” in der Praxis vs. zusammengeflickte Pipelines bedeutet

Der Unterschied zeigt sich in Szenarien, die für zusammengeflickte Systeme wirklich schwierig sind. Denk an: eine Bildschirmaufnahme, bei der jemand gleichzeitig programmiert und kommentiert. Oder ein Kundenservice-Gespräch, bei dem der Kontext halb verbal und halb auf dem Bildschirm ist. Oder ein Barrierefreiheits-Untertitelungs-Workflow, bei dem das Umgebungsaudio und die visuelle Aktion beide unabhängig voneinander Bedeutung tragen.

Das Qwen-Team demonstrierte, was sie “Audio-Visual Vibe Coding” nennen — das Modell kann eine Bildschirmaufnahme einer Programmieraufgabe ansehen und funktionsfähigen Code allein auf Basis dessen schreiben, was es sieht und hört, ohne eine Textaufforderung zu benötigen.

Das ist ein seltsamer Demo-Name, aber es ist eine echte Fähigkeitslücke gegenüber textorientierten Modellen mit nachträglich hinzugefügtem Audio. Wenn das Denken und die Wahrnehmung gleichzeitig im selben Modell stattfinden, funktionieren Dinge, die modalitätsübergreifenden Kontext erfordern, tatsächlich.

Drei Varianten: Plus, Flash und Light

Plus — Benchmark-Anführer, wenn es den Preis wert ist

Qwen3.5-Omni-Plus erzielte 215 SOTA-Ergebnisse in den Bereichen Audio- und Audio-Video-Verständnis, Schlussfolgerung und Interaktionsaufgaben. Das ist eine große Zahl, und Alibaba-Benchmarks neigen dazu, aggressiv zu zählen — aber die unabhängigen Vergleiche bestätigen es in den relevanten Kategorien.

Auf Standard-Benchmarks übertraf Qwen3.5-Omni Plus Gemini 3.1 Pro bei allgemeinen Audio-Verständnis-, Schlussfolgerungs- und Übersetzungsaufgaben und erreichte es beim Audio-visuellen Verständnis. Bei der mehrsprachigen Sprach-Stabilität über 20 Sprachen hinweg übertraf es ElevenLabs, GPT-Audio und Minimax.

Stimmenklonen ist über die API sowohl bei Plus als auch bei Flash verfügbar — du sendest eine 10–30-Sekunden-Stimmprobe, und das Modell klont sie für die Ausgabe.

Wann zahlst du für Plus? Wenn die Ausgabequalität das ist, was deine Nutzer tatsächlich wahrnehmen. Sprach-Agenten-Produkte, bei denen die Natürlichkeit der Stimme ein zentrales Wertversprechen ist. Hochwertige Transkription, bei der Genauigkeit über seltenen Sprachen wichtig ist. Alles, bei dem du direkt mit Gemini oder GPT-Audio verglichst und bei der Qualität gewinnen musst.

Flash — Kompromisse bei Durchsatz und Latenz

Flash ist laut API-Dokumentation die Standardempfehlung für den Produktionseinsatz. Die Modell-IDs sind qwen3.5-omni-flash für die Standardvariante, und Flash wird als Standard beschrieben, wenn Latenz, Qualität und Reaktion für die meisten Produktionsszenarien ausgewogen werden sollen.

Für Creator, die KI-gestützte Workflows aufbauen — automatische Untertitelungspipelines, Echtzeit-Interview-Transkription, Videozusammenfassung in großem Maßstab — ist Flash fast sicher dein Ausgangspunkt. Du führst Batch-Tests gegen Plus durch, um zu sehen, ob das Qualitätsgefälle den Kostenunterschied für deinen spezifischen Anwendungsfall rechtfertigt.

Der Vorgänger Qwen3-Omni Flash hatte bereits gestreamte Sprachantworten mit einer Latenz von nur 234 Millisekunden. Erwarte, dass Qwen3.5-Omni Flash in einem ähnlichen Bereich liegt, obwohl genaue veröffentlichte Latenz-Benchmarks speziell für 3.5 in den ursprünglichen Release-Notes nicht bestätigt sind.

Light — Edge- und Budget-Anwendungsfälle

Light ist die kleinste Variante der Familie. Parameteranzahlen für die 3.5-Omni-Serie wurden zum Zeitpunkt des Schreibens nicht vollständig bestätigt, aber das 30B-A3B-Modell des Vorgängers lief mit der richtigen Quantisierung recht gut auf Consumer-Hardware, und die Light-Variante hier könnte einem ähnlichen Muster folgen.

Wenn du prototypisierst, etwas für einen Kunden mit engen Inferenzkosten baust oder tatsächlich am Edge betreibst, fängst du mit Light an. Schreib es nicht als “das schlechte” ab — für viele Creator-Tools-Workflows (denk an: automatisierte Thumbnail-Untertitelung, einfaches Q&A über hochgeladenes Audio) ist es wahrscheinlich mehr als ausreichend.

Was neu ist im Vergleich zu Qwen3-Omni

Kontextfenster: 256K Token, 10+ Stunden Audio

Das ist die Änderung, die mich aus praktischer Produktionsperspektive am meisten interessiert.

Das 256K-Token-Kontextfenster entspricht über 10 Stunden Audio oder etwa 400 Sekunden 720p-Video mit Audio. Das ist ein bedeutender Sprung. Der Vorgänger Qwen3-Omni’s Denkmode war bei 65.536 Tokens mit 32.768-Token-Reasoning-Chains begrenzt — nützlich, aber auf längere Medien beschränkt.

Für Podcast-Analysen, die Verarbeitung langer Interviews, die erweiterte Zusammenfassung von Kundengesprächen — dieses Kontextfenster verändert, was in einem einzigen API-Aufruf tatsächlich möglich ist.

Sprachabdeckung: 113 Erkennung, 36 Generierung

Die Spracherkennung deckt jetzt 113 Sprachen und Dialekte ab, gegenüber 19 beim Vorgänger. Die Sprachgenerierung wurde von 10 auf 36 Sprachen erweitert.

Ehrliche Anmerkung: Alibaba zählt regionale Dialekte auf eine Weise, die diese Zahlen im Vergleich dazu, wie etwa OpenAI dieselbe Abdeckung zählen würde, aufbläht. Auch wenn man das berücksichtigt, ist der Sprung real. Wenn du für südostasiatische Märkte, arabische Inhalte oder einen mehrsprachigen Sprach-Workflow baust, ist das eine erhebliche praktische Verbesserung.

Thinker-Talker mit Hybrid-Attention-MoE

Die Thinker-Talker-Architektur wurde erstmals in Qwen2.5-Omni eingeführt. Das wichtige Upgrade in 3.5-Omni ist, dass beide Komponenten jetzt ein Hybrid-Attention-MoE-Design (Mixture-of-Experts) verwenden, das der Verlagerung der breiteren Qwen3.5-Familie hin zu spärlichen Architekturen entspricht.

Warum das für Entwickler wichtig ist: Die Thinker-Talker-Aufteilung ermöglicht es externen Systemen — RAG-Pipelines, Sicherheitsfiltern, Funktionsaufrufen — zwischen den beiden Phasen einzugreifen, bevor die Sprachsynthese beginnt. Das ist nicht nur ein architektonisches Detail. Es bedeutet, dass du deine eigene Logik zwischen das, was das Modell denkt, und das, was es laut sagt, einfügen kannst. Für Produktions-Sprach-Agenten ist das wirklich nützlich.

Semantische Unterbrechung und Stimmenklonen

Jeder, der schon einmal einen Sprach-Bot eingesetzt hat, kennt den Schmerz: Der Nutzer hustet, ein Hund bellt, jemand sagt “mhm”, und der Bot stoppt mitten in der Antwort, weil er denkt, er wird unterbrochen.

Qwen3.5-Omni fügt semantische Unterbrechung hinzu, die versucht, zwischen einem Nutzer, der wirklich etwas einwerfen möchte, und Umgebungsgeräuschen oder beiläufigen Kommentaren zu unterscheiden. Das ist eine jener Funktionen, die im Changelog geringfügig klingt, aber tatsächlich den Unterschied ausmacht zwischen einem Sprachassistenten, den Menschen frustrierend finden, und einem, den sie weiterhin verwenden.

Stimmenklonen und Echtzeit-Sprachsteuerung für Geschwindigkeit, Lautstärke und Emotion sind ebenfalls neu. Das Team erwähnt eine Funktion namens ARIA, die die Stabilität und Natürlichkeit der Sprachausgabe verbessert — die technischen Details, was ARIA intern tut, wurden in der ersten Veröffentlichung nicht näher erläutert.

Wie man auf Qwen3.5-Omni zugreift

DashScope API (Alibaba Cloud)

Der primäre Produktionszugang erfolgt über die DashScope API von Alibaba Cloud. Sie verwendet eine OpenAI-kompatible Schnittstelle, was bedeutet: Wenn du bereits GPT-4o oder Claude über das OpenAI SDK verwendest, ist die Migration unkompliziert.

DashScope unterstützt mehrere Regionen: Singapur (international), US Virginia, China Peking und Hongkong, mit unterschiedlichen Endpunkt-URLs für jede Region. Für die meisten nicht-China-basierten Teams ist der internationale Singapur-Endpunkt dein Standard: dashscope-intl.aliyuncs.com.

Modell-IDs für die drei Varianten folgen dem Muster qwen3.5-omni-plus, qwen3.5-omni-flash und qwen3.5-omni-light. Die API-Struktur folgt dem Standard-/v1/chat/completions-Format mit einem modalities-Parameter, um anzugeben, ob du Text, Audio oder beides in der Antwort möchtest.

vLLM Self-Hosting-Option

Das Qwen-Team empfiehlt vLLM ausdrücklich für Inferenz und Deployment der Qwen-Omni-Serienmodelle und stellt ein Docker-Image bereit, das eine vollständige Laufzeitumgebung für sowohl HuggingFace Transformers als auch vLLM enthält.

Der Vorbehalt ist, dass die Inferenzgeschwindigkeit mit HuggingFace Transformers bei MoE-Modellen sehr langsam sein kann. Für Anforderungen an große Skalierung oder geringe Latenz ist daher vLLM oder die DashScope API der empfohlene Weg.

Wenn du selbst hostest, plane um vLLM 0.13.0 herum — das ist die Version, auf die in der offiziellen Setup-Dokumentation verwiesen wird. Die MoE-Architektur bedeutet, dass die Speicheranforderungen niedriger sind als bei einem vergleichbaren dichten Modell bei gleichem Qualitätsniveau, aber du solltest die GPU-Zuweisung trotzdem validieren, bevor du ein Produktions-Deployment hochfährst.

Open-Weight-Status: Was bestätigt ist vs. was aussteht

Hier möchte ich vorsichtig sein und nicht über das Bestätigte hinaus spekulieren.

Qwen3-Omni (der Vorgänger) wurde unter Apache 2.0 auf GitHub und HuggingFace veröffentlicht. Ob die Gewichte von Qwen3.5-Omni denselben Apache-2.0-Lizenzierungsweg nehmen werden, wurde in der ersten Ankündigung nicht bestätigt. Die Gewichte des Vorgängers sind öffentlich verfügbar — die 3.5-Gewichte könnten folgen, aber zum Veröffentlichungsdatum am 30. März steht diese Bestätigung noch aus.

Baue deine Open-Weight-Deployment-Pläne nicht darauf auf, bis das offizielle GitHub-Repo oder die HuggingFace-Modellkarte die Lizenzierung bestätigt. Prüfe QwenLM GitHub auf Updates.

Wer auf dieses Release achten sollte

Entwickler von Sprach-Agenten und Echtzeit-Konversationen

Wenn du sprach-orientierte Anwendungen baust — Kundenservice-Bots, KI-Begleiter, interaktive Sprachtools — ist Qwen3.5-Omni eine ernsthafte Evaluierung wert. Die semantische Unterbrechung allein adressiert einen bekannten Schmerzpunkt, den jeder Sprach-Agenten-Entwickler getroffen hat. Ergänze das um nativen Funktionsaufruf und Websuche, und das beginnt wie echte Infrastruktur auszusehen und nicht wie ein Forschungsrelease.

Der Qwen-Blogbeitrag hebt native Websuche und Funktionsaufruf-Unterstützung hervor, die direkt in das Omni-Modell eingebaut sind, was es weniger als Forschungsartefakt und mehr als Infrastruktur für sprach-orientierte Anwendungen positioniert.

Audio-visuelle Produktion und Untertitelungs-Workflows

Für Creator-Tools, Video-Produktionsautomatisierung und Untertitelung in großem Maßstab — das ist das überzeugendste Release im Open-Weight-Multimodal-Bereich gerade. Der 10+ Stunden-Audio-Kontext bedeutet, dass du vollständige Inhalte in einem Aufruf verarbeiten kannst. Die erweiterte Sprachabdeckung bedeutet, dass mehrsprachige Inhalte kein Sonderfall mehr sind.

Die Kombination aus Audio-Verständnis und Video-Frame-Analyse in einem einzigen Inferenz-Aufruf macht das auch wirklich nützlich für Dinge wie: automatisierte Highlight-Extraktion, B-Roll-Untertitelung, Voice-Over-Transkription mit Korrelation von On-Screen-Text.

Teams, die bereits Qwen3-Omni in der Produktion betreiben

Wenn Qwen3-Omni bereits in deinem Stack ist, ist das Upgrade auf Qwen3.5-Omni unkompliziert. Die API-Struktur ist konsistent. Das Kontextfenster-Upgrade allein macht es lohnenswert, auf deinen bestehenden Workloads zu testen — insbesondere bei allem, was an die 65K-Token-Grenze gestoßen ist.

Was es nicht abdeckt

Kein Bildgenerierungsmodell

Es lohnt sich, das klar zu sagen, weil “omnimodal” etwas Verwirrung stiftet: Qwen3.5-Omni generiert Text und Sprache. Es generiert keine Bilder oder Videos. Es versteht Bilder und Videos als Eingabe — das ist eine völlig andere Fähigkeit. Wenn du Bildgenerierung brauchst, schau dir Qwens separate VL- und Bildgenerierungs-Modelllinien an oder das qwen-image-plus-Modell im DashScope-Katalog.

Inferenzgeschwindigkeit bei MoE: vLLM vs. HuggingFace Transformers

Das hat viele Menschen mit Qwen3-Omni überrascht, und es wird auch Menschen mit 3.5-Omni überraschen. Da Qwen3-Omni eine MoE-Architektur verwendet, kann die Inferenzgeschwindigkeit mit HuggingFace Transformers bei MoE-Modellen sehr langsam sein. Für groß angelegte Aufrufe oder Anforderungen mit geringer Latenz wird vLLM oder die DashScope API ausdrücklich empfohlen.

Führe keine Benchmarks mit HuggingFace Transformers durch und komme zu dem Schluss, das Modell sei langsam. Teste auf vLLM oder der verwalteten API, bevor du eine Meinung zur Produktionstauglichkeit bildest.

FAQ

Ist Qwen3.5-Omni Open Source oder Open Weight?

Stand des Releases vom 30. März 2026 wurde der Open-Weight-Status von Qwen3.5-Omni nicht offiziell bestätigt. Der Vorgänger Qwen3-Omni war Apache-2.0-Open-Weight und auf HuggingFace verfügbar. Erwarte einen ähnlichen Release-Rhythmus für 3.5-Omni, aber verifiziere das auf dem offiziellen QwenLM GitHub, bevor du davon abhängig bist.

Kann ich Qwen3.5-Omni-Plus selbst hosten?

Die DashScope API ist heute der bestätigte Produktionsweg. Self-Hosting über vLLM wird für Qwen3-Omni unterstützt und wird wahrscheinlich auch für 3.5-Omni unterstützt, sobald die Gewichte veröffentlicht werden. Die MoE-Architektur der Plus-Variante bedeutet, dass die aktiven Parameteranforderungen niedriger sind als bei einem vergleichbaren dichten Modell, aber du benötigst ein Multi-GPU-Setup für die vollständige Plus-Variante.

Unterstützt es nativ Funktionsaufrufe und Websuche?

Ja. Der Qwen-Blogbeitrag hebt ausdrücklich native Websuche und Funktionsaufruf-Unterstützung hervor, die in das Omni-Modell integriert sind. Funktionsaufrufe folgen dem Standard-OpenAI-Tools-Format über die DashScope API. Das ist ein bedeutender Differenzierungsfaktor — du kannst Sprach-Agenten erstellen, die Live-Daten abfragen, ohne eine separate Orchestrierungsschicht zu durchlaufen.

Frühere Beiträge: