Qu'est-ce que Qwen3.5-Omni : Capacités, Variantes et Accès à l'API

Bonjour à tous ! C’est Dora qui revient ! J’étais en plein montage vidéo quand la notification est tombée : Qwen3.5-Omni vient de sortir. J’utilise la famille Qwen3-Omni dans quelques workflows de production depuis des mois, donc j’ai immédiatement compris que ce n’était pas une mise à jour mineure. Une fenêtre de contexte de 256K, le clonage vocal, l’interruption sémantique et 113 langues pour la reconnaissance vocale — le tout dans un seul modèle. J’ai dû arrêter ce que je faisais.

Si vous construisez des agents vocaux, des pipelines de sous-titrage, ou quoi que ce soit qui doit traiter conjointement de l’audio et de la vidéo humains réels, cette version vous concerne directement. Laissez-moi vous expliquer ce qu’elle fait concrètement, ce que signifient les trois variantes en pratique, et comment y accéder — y compris ce qui reste flou à ce jour.

Ce que fait réellement Qwen3.5-Omni

Texte, image, audio et vidéo en un seul appel d’inférence

Voici ce qui est systématiquement sous-estimé dans les annonces d’IA : le traitement multimodal natif et le traitement multimodal par pipeline assemblé ne sont pas la même chose.

Quand un modèle non-omnimodal comme ChatGPT 5.4 reçoit une vidéo, il doit extraire les images via un modèle de vision, faire passer l’audio par quelque chose comme Whisper pour la transcription, et appliquer l’OCR pour lire les sous-titres incrustés — trois processus distincts assemblés pour approximer ce qu’un vrai modèle omni fait en un seul passage. Dans des conditions idéales, avec un clip bien éclairé et un audio propre, cela a pris neuf minutes dans un test réel.

Qwen3.5-Omni traite la même entrée en un seul appel. Vous envoyez la vidéo. Vous obtenez une réponse. Pas de pipeline intermédiaire. Pas de surcharge de conversion de format. Pas de modèle audio qui ne sait pas ce qui se passe à l’écran ni de modèle de vision qui n’entend rien.

Le modèle prend en charge la compréhension du texte, de l’image, de l’audio et de l’audio-vidéo, avec les composants Thinker et Talker utilisant tous deux une architecture Hybrid-Attention MoE. Ce dernier point compte plus qu’il n’y paraît, j’y reviendrai dans la section architecture ci-dessous.

Ce que signifie “omnimodal” en pratique par rapport aux pipelines assemblés

La différence apparaît dans des scénarios genuinement difficiles pour les systèmes assemblés. Pensez : un enregistrement d’écran où quelqu’un code et commente en même temps. Ou un appel de service client où le contexte est à moitié verbal et à moitié à l’écran. Ou un workflow de sous-titrage pour l’accessibilité où l’audio ambiant et l’action visuelle portent tous deux du sens indépendamment.

L’équipe Qwen a démontré ce qu’elle appelle l‘“Audio-Visual Vibe Coding” — le modèle peut regarder un enregistrement d’écran d’une tâche de codage et écrire du code fonctionnel uniquement sur la base de ce qu’il voit et entend, sans prompt textuel requis.

C’est un nom de démo bizarre, mais c’est un vrai manque de capacité par rapport aux modèles text-first avec audio rajouté à la va-vite. Quand le raisonnement et la perception se produisent à l’intérieur du même modèle en même temps, les choses qui nécessitent un contexte cross-modal fonctionnent vraiment.

Trois variantes : Plus, Flash et Light

Plus — Leader des benchmarks, quand le coût en vaut la peine

Qwen3.5-Omni-Plus a atteint 215 résultats SOTA dans les tâches de compréhension audio et audio-vidéo, de raisonnement et d’interaction. C’est un grand nombre, et les benchmarks d’Alibaba ont tendance à compter de façon agressive — mais les comparaisons indépendantes le confirment dans les catégories qui comptent.

Sur les benchmarks standards, Qwen3.5-Omni Plus a surpassé Gemini 3.1 Pro sur la compréhension audio générale, le raisonnement et les tâches de traduction, et l’a égalé sur la compréhension audio-visuelle. Sur la stabilité vocale multilingue dans 20 langues, il a battu ElevenLabs, GPT-Audio et Minimax.

Le clonage vocal est disponible sur Plus et Flash via l’API — vous envoyez un échantillon vocal de 10 à 30 secondes, et le modèle le clone pour la sortie.

Quand payer pour Plus ? Quand la qualité de sortie est ce que vos utilisateurs remarquent vraiment. Les produits d’agents vocaux où le naturel de la voix est une proposition de valeur centrale. La transcription à forts enjeux où la précision sur les langues rares compte. Tout ce qui vous oppose à Gemini ou GPT-Audio directement et où vous devez gagner sur la qualité.

Flash — Compromis débit et latence

Flash est la recommandation par défaut pour la production selon la documentation de l’API. Les identifiants de modèle sont qwen3.5-omni-flash pour la variante standard, et Flash est décrit comme le défaut lors de l’équilibre entre latence, qualité et réponse pour la plupart des scénarios de production.

Pour les créateurs qui construisent des workflows assistés par IA — pipelines de sous-titrage automatique, transcription d’interview en temps réel, résumé de vidéos à grande échelle — Flash est presque certainement votre point de départ. Vous testez en lot contre Plus pour voir si le delta de qualité vaut la différence de coût pour votre cas d’usage spécifique.

Le prédécesseur Qwen3-Omni Flash avait déjà des réponses vocales en streaming avec une latence aussi basse que 234 millisecondes. Attendez-vous à ce que Qwen3.5-Omni Flash soit dans une plage similaire, bien que les benchmarks de latence publiés exacts pour la 3.5 spécifiquement ne soient pas confirmés dans les notes de version initiales.

Light — Cas d’usage en périphérie et économiques

Light est la plus petite variante de la famille. Le nombre de paramètres pour la série 3.5-Omni n’a pas été entièrement confirmé au moment de la rédaction, mais le modèle 30B-A3B du prédécesseur fonctionnait raisonnablement bien sur du matériel grand public avec la bonne quantification, et la variante Light ici pourrait suivre un schéma similaire.

Si vous prototypez, construisez quelque chose pour un client avec des coûts d’inférence serrés, ou si vous fonctionnez vraiment en périphérie, Light est là où vous commencez. Ne le rayez pas d’un trait comme “le mauvais” — pour de nombreux workflows d’outils créatifs (pensez : sous-titrage automatisé de vignettes, questions-réponses simples sur de l’audio uploadé), c’est très probablement plus que suffisant.

Ce qui est nouveau par rapport à Qwen3-Omni

Fenêtre de contexte : 256K tokens, plus de 10 heures d’audio

C’est le changement qui m’importe le plus d’un point de vue pratique de production.

La fenêtre de contexte de 256K tokens se traduit par plus de 10 heures d’audio, ou environ 400 secondes de vidéo 720p avec audio. C’est un saut significatif. Le mode de réflexion de Qwen3-Omni, le prédécesseur, plafonnait à 65 536 tokens avec des chaînes de raisonnement de 32 768 tokens — utile, mais limité aux médias de longue durée.

Pour l’analyse de podcasts, le traitement d’interviews longue forme, la synthèse étendue d’appels clients — cette fenêtre de contexte change ce qui est réellement faisable en un seul appel API.

Couverture linguistique : 113 en reconnaissance, 36 en génération

La reconnaissance vocale couvre désormais 113 langues et dialectes, contre 19 pour le prédécesseur. La génération vocale est passée de 10 langues à 36.

Note honnête ici : Alibaba compte les dialectes régionaux d’une manière qui gonfle ces chiffres par rapport à la façon dont, disons, OpenAI compterait la même couverture. Même en tenant compte de cela, le saut est réel. Si vous construisez pour les marchés d’Asie du Sud-Est, le contenu arabe, ou tout workflow vocal multilingue, c’est une amélioration pratique significative.

Thinker-Talker avec Hybrid-Attention MoE

L’architecture Thinker-Talker a été introduite pour la première fois dans Qwen2.5-Omni. L’amélioration importante dans 3.5-Omni est que les deux composants utilisent désormais une conception Hybrid-Attention MoE (Mixture-of-Experts), correspondant au passage de la famille Qwen3.5 plus large vers des architectures creuses.

Pourquoi cela compte pour les développeurs : la séparation Thinker-Talker permet aux systèmes externes — pipelines RAG, filtres de sécurité, appels de fonctions — d’intervenir entre les deux étapes avant que la synthèse vocale ne commence. Ce n’est pas juste un détail architectural. Cela signifie que vous pouvez brancher votre propre logique entre ce que le modèle raisonne et ce qu’il dit à voix haute. Pour les agents vocaux de production, c’est genuinement utile.

Interruption sémantique et clonage vocal

Quiconque a déployé un bot vocal connaît la douleur : l’utilisateur tousse, le chien aboie, quelqu’un dit “mm-hmm”, et le bot s’arrête en plein milieu de sa réponse en pensant qu’il est interrompu.

Qwen3.5-Omni ajoute l’interruption sémantique, qui tente de distinguer entre un utilisateur voulant genuinement intervenir et le bruit de fond ambiant ou les commentaires passagers. C’est l’une de ces fonctionnalités qui semble mineure dans un changelog mais qui fait réellement la différence entre un assistant vocal que les gens trouvent frustrant et un qu’ils continuent d’utiliser.

Le clonage vocal et le contrôle vocal en temps réel pour la vitesse, le volume et l’émotion sont également nouveaux. L’équipe mentionne une fonctionnalité appelée ARIA qui améliore la stabilité et le naturel de la sortie vocale — les spécificités techniques de ce que fait ARIA en interne n’ont pas été détaillées dans la version initiale.

Comment accéder à Qwen3.5-Omni

API DashScope (Alibaba Cloud)

Le chemin d’accès principal à la production est via l’API DashScope d’Alibaba Cloud. Elle utilise une interface compatible OpenAI, ce qui signifie que si vous utilisez déjà GPT-4o ou Claude via le SDK OpenAI, la migration est simple.

DashScope prend en charge plusieurs régions : Singapour (international), Virginie (États-Unis), Pékin (Chine) et Hong Kong, avec des URLs de points de terminaison différents pour chacune. Pour la plupart des équipes hors Chine, le point de terminaison international de Singapour est votre défaut : dashscope-intl.aliyuncs.com.

Les identifiants de modèle pour les trois variantes suivent le schéma qwen3.5-omni-plus, qwen3.5-omni-flash et qwen3.5-omni-light. La structure de l’API suit le format standard /v1/chat/completions avec un paramètre modalities pour spécifier si vous voulez du texte, de l’audio, ou les deux dans la réponse.

Option d’auto-hébergement vLLM

L’équipe Qwen recommande fortement vLLM pour l’inférence et le déploiement des modèles de la série Qwen-Omni, fournissant une image Docker qui inclut un environnement d’exécution complet pour HuggingFace Transformers et vLLM.

La mise en garde est que la vitesse d’inférence avec HuggingFace Transformers sur les modèles MoE peut être très lente, donc pour les exigences à grande échelle ou à faible latence, vLLM ou l’API DashScope est le chemin recommandé.

Si vous vous auto-hébergez, planifiez autour de vLLM 0.13.0 spécifiquement — c’est la version référencée dans la documentation officielle de configuration. L’architecture MoE signifie que les besoins en mémoire sont inférieurs à ceux d’un modèle dense comparable au même niveau de qualité, mais vous voudrez quand même valider l’allocation GPU avant de lancer un déploiement de production.

Statut open-weight : ce qui est confirmé vs. en attente

C’est là où je veux être prudent et ne pas spéculer au-delà de ce qui est confirmé.

Qwen3-Omni (le prédécesseur) a été publié sous Apache 2.0 sur GitHub et HuggingFace. Si les poids de Qwen3.5-Omni suivront le même chemin de licence Apache 2.0 n’a pas été confirmé dans l’annonce initiale. Les poids du prédécesseur sont disponibles publiquement — les poids de la 3.5 pourraient suivre, mais à la date de publication du 30 mars, cette confirmation est en attente.

Ne construisez pas vos plans de déploiement open-weight autour de cela jusqu’à ce que le dépôt GitHub officiel ou la fiche de modèle HuggingFace confirme la licence. Vérifiez QwenLM GitHub pour les mises à jour.

Qui devrait prêter attention à cette version

Constructeurs d’agents vocaux et de conversations en temps réel

Si vous construisez des applications vocal-first — bots de service client, compagnons IA, outils vocaux interactifs — Qwen3.5-Omni mérite une évaluation sérieuse. L’interruption sémantique à elle seule adresse un point de douleur connu que chaque développeur d’agents vocaux a rencontré. Ajoutez les appels de fonctions natifs et la recherche web, et cela commence à ressembler à une vraie infrastructure plutôt qu’à une version de recherche.

Le billet de blog Qwen souligne la prise en charge native de la recherche web et des appels de fonctions directement intégrés dans le modèle omni, ce qui le positionne moins comme un artefact de recherche et plus comme une infrastructure pour les applications vocal-first.

Workflows de production audio-visuelle et de sous-titrage

Pour les outils créatifs, l’automatisation de la production vidéo et le sous-titrage à grande échelle — c’est la version la plus convaincante dans l’espace multimodal open-weight en ce moment. Le contexte audio de 10+ heures signifie que vous pouvez traiter du contenu pleine longueur en un seul appel. La couverture linguistique étendue signifie que le contenu multilingue n’est plus un cas particulier.

La combinaison de la compréhension audio et de l’analyse de frames vidéo en un seul appel d’inférence rend également cela genuinement utile pour des choses comme : l’extraction automatisée de moments forts, le sous-titrage de B-roll, la transcription de voix off avec corrélation de texte à l’écran.

Équipes exécutant déjà Qwen3-Omni en production

Si Qwen3-Omni est déjà dans votre stack, la mise à niveau vers Qwen3.5-Omni est simple. La structure de l’API est cohérente. L’amélioration de la fenêtre de contexte à elle seule vaut la peine d’être testée sur vos charges de travail existantes — surtout tout ce qui atteignait le plafond de 65K tokens.

Ce qu’il ne couvre pas

Pas un modèle de génération d’images

Cela vaut la peine d’être dit clairement car “omnimodal” crée une certaine confusion : Qwen3.5-Omni génère du texte et de la parole. Il ne génère pas d’images ni de vidéos. Il comprend les images et les vidéos en entrée — c’est une capacité complètement différente. Si la génération d’images est ce dont vous avez besoin, regardez les lignes de modèles VL et de génération d’images séparées de Qwen, ou le modèle qwen-image-plus dans le catalogue DashScope.

Vitesse d’inférence sur MoE : vLLM vs. HuggingFace Transformers

Cela a piégé beaucoup de gens avec Qwen3-Omni et cela piégera des gens avec la 3.5-Omni aussi. Puisque Qwen3-Omni emploie une architecture MoE, la vitesse d’inférence avec HuggingFace Transformers sur les modèles MoE peut être très lente. Pour les invocations à grande échelle ou les exigences à faible latence, vLLM ou l’API DashScope est fortement recommandé.

Ne faites pas de benchmark sur HuggingFace Transformers et ne concluez pas que le modèle est lent. Testez sur vLLM ou l’API gérée avant de vous forger une opinion sur la viabilité en production.

FAQ

Qwen3.5-Omni est-il open source ou open weight ?

À la date de publication du 30 mars 2026, le statut open-weight de Qwen3.5-Omni n’a pas été officiellement confirmé. Le prédécesseur Qwen3-Omni était open-weight Apache 2.0 et disponible sur HuggingFace. Attendez-vous à une cadence de publication similaire pour la 3.5-Omni, mais vérifiez sur le GitHub officiel QwenLM avant d’en dépendre.

Puis-je auto-héberger Qwen3.5-Omni-Plus ?

L’API DashScope est le chemin de production confirmé aujourd’hui. L’auto-hébergement via vLLM est pris en charge pour Qwen3-Omni et sera probablement pris en charge pour la 3.5-Omni une fois les poids publiés. L’architecture MoE de la variante Plus signifie que les besoins en paramètres actifs sont inférieurs à ceux d’un modèle dense comparable, mais vous aurez besoin d’une configuration multi-GPU pour la variante Plus complète.

Prend-il en charge nativement les appels de fonctions et la recherche web ?

Oui. Le billet de blog Qwen souligne explicitement la prise en charge native de la recherche web et des appels de fonctions intégrés dans le modèle omni. Les appels de fonctions suivent le format standard des outils OpenAI via l’API DashScope. C’est un différenciateur significatif — vous pouvez construire des agents vocaux qui interrogent des données en direct sans passer par une couche d’orchestration séparée.

Articles précédents :