Qwen3.5-Omni 是什么：功能、版本与 API 访问指南

大家好！我是 Dora，又回来了！我正在剪辑一个视频项目，这时通知弹出来了：Qwen3.5-Omni 正式发布。我已经在几个生产工作流中运行 Qwen3-Omni 系列好几个月了，所以我立刻意识到这不是一次小更新。256K 上下文窗口、语音克隆、语义打断、以及 113 种语言的语音识别——全都集成在一个模型里。我不得不放下手头的工作。

如果你正在构建语音智能体、字幕生成流水线，或者任何需要同时处理真实人声和视频的应用，这次发布与你直接相关。让我带你了解它的实际功能、三个变体在实践中意味着什么，以及如何获取访问权限——包括截至今日仍不明确的内容。

Qwen3.5-Omni 的实际功能

文本、图像、音频和视频在单次推理调用中一并处理

有一件事在 AI 公告中总是被低估：原生多模态处理与拼接式多模态处理并不是一回事。

当非全模态模型如 ChatGPT 5.4 被输入视频时，它必须通过视觉模型提取帧，通过 Whisper 之类的模型进行音频转录，并通过 OCR 读取内嵌字幕——三个独立流程拼接在一起，才能近似实现真正全模态模型在单次传递中所完成的工作。在理想条件下，对于一段画面清晰、音频干净的片段，一次真实测试耗时九分钟。

Qwen3.5-Omni 在一次调用中处理相同的输入。你发送视频，你得到响应。没有中间流水线，没有格式转换开销，没有不知道屏幕上发生了什么的音频模型，也没有什么都听不见的视觉模型。

该模型支持文本、图像、音频以及音视频理解，Thinker 和 Talker 组件均采用混合注意力 MoE 架构。最后这一点比听起来更重要，我将在下面的架构部分详细介绍。

“全模态”在实践中与拼接式流水线的区别

这种差异在拼接式系统真正难以应对的场景中会显现出来。想象一下：一段屏幕录像，某人边编码边解说。或者一个客服电话，其中一半上下文是口头的，另一半在屏幕上。或者一个无障碍字幕工作流，其中环境音频和视觉动作各自独立地承载着意义。

Qwen 团队展示了他们所谓的”音视频氛围编程”——该模型可以观看编码任务的屏幕录像，并纯粹根据其所见所闻编写可运行的代码，无需任何文本提示。

这个演示名字有点奇怪，但它代表了与以音频为附加功能的文本优先模型相比真实存在的能力差距。当推理和感知在同一个模型中同时发生时，需要跨模态上下文的任务才能真正奏效。

三个变体：Plus、Flash 和 Light

Plus——性能标杆，当它值得付出成本时

Qwen3.5-Omni-Plus 在音频和音视频理解、推理和交互任务中取得了 215 项 SOTA 成绩。这是一个很大的数字，阿里巴巴的基准测试统计往往比较激进——但独立对比在重要的类别中正在证实这一点。

在标准基准测试中，Qwen3.5-Omni Plus 在通用音频理解、推理和翻译任务上超越了 Gemini 3.1 Pro，在音视频理解上与其持平。在 20 种语言的多语言语音稳定性测试中，它击败了 ElevenLabs、GPT-Audio 和 Minimax。

语音克隆在 Plus 和 Flash 上均可通过 API 使用——你发送一段 10-30 秒的声音样本，模型就会克隆它用于输出。

什么时候值得为 Plus 付费？当输出质量是用户真正能感受到的东西时。语音自然度是核心价值主张的语音智能体产品。稀有语言准确性至关重要的高价值转录场景。任何需要与 Gemini 或 GPT-Audio 直接比较并需要在质量上胜出的场景。

Flash——吞吐量与延迟的权衡

Flash 是 API 文档中推荐用于生产环境的默认选择。模型 ID 为 qwen3.5-omni-flash，Flash 被描述为在大多数生产场景中平衡延迟、质量和响应的默认选项。

对于构建 AI 辅助工作流的创作者——自动字幕流水线、实时采访转录、大规模视频摘要——Flash 几乎肯定是你的起点。你可以对 Plus 进行批量测试，看看质量差异对于你的特定用例是否值得付出成本差异。

前代 Qwen3-Omni Flash 已经实现了延迟低至 234 毫秒的流式语音响应。预计 Qwen3.5-Omni Flash 会在类似范围内，不过 3.5 版本具体的已发布延迟基准在初始发布说明中尚未确认。

Light——边缘计算和预算受限场景

Light 是该系列中最小的变体。3.5-Omni 系列的参数量在撰写本文时尚未完全确认，但前代 30B-A3B 模型在合适的量化方案下在消费级硬件上运行得相当好，Light 变体可能遵循类似的模式。

如果你在做原型开发、为推理成本紧张的客户构建应用，或者真的在边缘部署，Light 是你的起点。不要把它当作”差版本”——对于许多创作者工具工作流（比如：自动缩略图字幕、上传音频上的简单问答），它可能已经绰绰有余。

相比 Qwen3-Omni 的新变化

上下文窗口：256K Token，超过 10 小时音频

从实际生产角度来看，这是我最关心的变化。

256K token 上下文窗口相当于超过 10 小时的音频，或大约 400 秒带音频的 720p 视频。这是一个有意义的飞跃。前代 Qwen3-Omni 的思考模式最多支持 65,536 个 token，推理链为 32,768 个 token——有用，但对于较长形式的媒体内容来说受到限制。

对于播客分析、长篇采访处理、延长客户通话摘要——这个上下文窗口改变了在单次 API 调用中实际可行的事情。

语言覆盖：113 种识别语言，36 种生成语言

语音识别现在覆盖 113 种语言和方言，相比前代的 19 种有所提升。语音生成从 10 种语言扩展到 36 种。

坦诚说明一点：阿里巴巴统计地区方言的方式会让这些数字相比 OpenAI 统计同等覆盖范围的方式显得虚高。即便考虑到这一点，这个飞跃也是真实的。如果你在为东南亚市场、阿拉伯语内容或任何多语言语音工作流构建应用，这是一个显著的实质性改进。

带混合注意力 MoE 的 Thinker-Talker 架构

Thinker-Talker 架构首次在 Qwen2.5-Omni 中引入。3.5-Omni 的重要升级是两个组件现在都使用混合注意力 MoE（混合专家）设计，与更广泛的 Qwen3.5 系列向稀疏架构的转变保持一致。

对开发者来说这意味着什么：Thinker-Talker 的分离让外部系统——RAG 流水线、安全过滤器、函数调用——能够在语音合成开始之前介入两个阶段之间。这不仅仅是架构细节。这意味着你可以在模型推理的内容和它说出口的内容之间插入自己的逻辑。对于生产语音智能体来说，这真的很有用。

语义打断和语音克隆

部署过语音机器人的人都知道那种痛苦：用户咳嗽、狗吠叫、有人说”嗯嗯”，机器人就中途停止响应，以为自己被打断了。

Qwen3.5-Omni 添加了语义打断功能，它尝试区分用户真正想要插话和环境背景噪音或随口评论之间的差别。这是那些在更新日志中听起来微不足道但实际上决定了语音助手是令人沮丧还是让人愿意持续使用的功能之一。

语音克隆以及对速度、音量和情感的实时语音控制也是新功能。团队提到了一个名为 ARIA 的功能，它改善了语音输出的稳定性和自然度——ARIA 内部具体做了什么在初始发布中尚未详细说明。

如何访问 Qwen3.5-Omni

DashScope API（阿里云）

主要的生产访问路径是通过阿里云的 DashScope API。它使用与 OpenAI 兼容的接口，这意味着如果你已经在通过 OpenAI SDK 调用 GPT-4o 或 Claude，迁移过程将非常简单。

DashScope 支持多个地区：新加坡（国际）、美国弗吉尼亚、中国北京和香港，每个地区有不同的端点 URL。对于大多数非中国地区的团队，新加坡国际端点是默认选项：dashscope-intl.aliyuncs.com。

三个变体的模型 ID 遵循 qwen3.5-omni-plus、qwen3.5-omni-flash 和 qwen3.5-omni-light 的格式。API 结构遵循标准的 /v1/chat/completions 格式，带有 modalities 参数来指定响应中是否需要文本、音频或两者兼有。

vLLM 自托管选项

Qwen 团队强烈推荐使用 vLLM 进行 Qwen-Omni 系列模型的推理和部署，并提供了一个包含 HuggingFace Transformers 和 vLLM 完整运行时环境的 Docker 镜像。

需要注意的是，使用 HuggingFace Transformers 在 MoE 模型上进行推理速度可能非常慢，因此对于大规模或低延迟需求，vLLM 或 DashScope API 是推荐路径。

如果你在自托管，请围绕 vLLM 0.13.0 进行规划——这是官方设置文档中引用的版本。MoE 架构意味着内存需求低于同等质量水平的可比稠密模型，但在启动生产部署之前，你仍需要验证 GPU 分配情况。

开放权重状态：已确认与待确认

这里我想谨慎一些，不做超出已确认内容的推测。

Qwen3-Omni（前代）以 Apache 2.0 协议在 GitHub 和 HuggingFace 上发布。Qwen3.5-Omni 的权重是否会遵循相同的 Apache 2.0 许可路径，在初始公告中尚未确认。前代权重是公开可用的——3.5 版本的权重可能会跟进，但截至 3 月 30 日发布日期，该确认尚待发布。

在官方 GitHub 仓库或 HuggingFace 模型卡确认许可之前，不要围绕此构建你的开放权重部署计划。关注 QwenLM GitHub 的更新。

谁应该关注这次发布

语音智能体和实时对话构建者

如果你正在构建语音优先应用——客服机器人、AI 伴侣、交互式语音工具——Qwen3.5-Omni 值得认真评估。仅语义打断功能就解决了每个语音智能体开发者都遇到过的已知痛点。加上原生函数调用和网络搜索，这开始看起来像是真正的基础设施，而不是一个研究发布版本。

Qwen 博客文章强调了原生网络搜索和函数调用支持直接内置在全模态模型中，这将其定位为更接近语音优先应用基础设施，而非研究产物。

音视频制作和字幕工作流

对于创作者工具、视频制作自动化和大规模字幕生成——这是目前开放权重多模态领域最引人注目的发布。超过 10 小时的音频上下文意味着你可以在一次调用中处理完整时长的内容。扩展的语言覆盖意味着多语言内容不再是特殊情况。

单次推理调用中音频理解和视频帧分析的结合，也使其对以下场景真正有用：自动精彩片段提取、B-roll 字幕生成、带屏幕文字关联的配音转录。

已在生产中运行 Qwen3-Omni 的团队

如果 Qwen3-Omni 已经在你的技术栈中，升级到 Qwen3.5-Omni 非常直接。API 结构保持一致。仅上下文窗口升级就值得在现有工作负载上进行测试——尤其是任何之前碰到 65K token 上限的场景。

它不涵盖的内容

不是图像生成模型

值得明确说明，因为”全模态”会造成一些混淆：Qwen3.5-Omni 生成文本和语音。它不生成图像或视频。它将图像和视频作为输入来理解——这是完全不同的能力。如果图像生成是你的需求，请查看 Qwen 独立的 VL 和图像生成模型系列，或者 DashScope 目录中的 qwen-image-plus 模型。

MoE 上的推理速度：vLLM 与 HuggingFace Transformers

这个问题让很多人在 Qwen3-Omni 上栽了跟头，在 3.5-Omni 上也会如此。由于 Qwen3-Omni 采用 MoE 架构，使用 HuggingFace Transformers 在 MoE 模型上的推理速度可能非常慢。对于大规模调用或低延迟需求，强烈推荐使用 vLLM 或 DashScope API。

不要在 HuggingFace Transformers 上进行基准测试后得出模型很慢的结论。在对生产可行性形成看法之前，先在 vLLM 或托管 API 上进行测试。

常见问题

Qwen3.5-Omni 是开源的还是开放权重的？

截至 2026 年 3 月 30 日发布时，Qwen3.5-Omni 的开放权重状态尚未官方确认。前代 Qwen3-Omni 以 Apache 2.0 开放权重形式发布，并在 HuggingFace 上可用。预计 3.5-Omni 会遵循类似的发布节奏，但在正式依赖之前，请在官方 QwenLM GitHub 上进行验证。

我可以自托管 Qwen3.5-Omni-Plus 吗？

DashScope API 是目前已确认的生产路径。通过 vLLM 自托管对 Qwen3-Omni 已受支持，一旦权重发布，对 3.5-Omni 也可能受支持。Plus 变体的 MoE 架构意味着活跃参数需求低于可比稠密模型，但完整 Plus 变体仍需要多 GPU 配置。

它是否原生支持函数调用和网络搜索？

是的。Qwen 博客文章明确强调了内置于全模态模型中的原生网络搜索和函数调用支持。函数调用通过 DashScope API 遵循标准 OpenAI tools 格式。这是一个有意义的差异化因素——你可以构建查询实时数据的语音智能体，而无需通过独立的编排层进行路由。

往期文章：