如果您开发语音代理、字幕生成流程，或者任何需要同时处理真人音频和视频的项目，那么此次发布与您息息相关。接下来，我将详细介绍它的功能、三种变体的实际意义，以及如何获取访问权限——包括目前仍存在一些疑问的地方。
Qwen3.5-Omni 的实际功能
将文本、图像、音频和视频作为单个推理调用
在人工智能公告中，有一点经常被低估：原生多模态处理和拼接管道多模态处理并不是一回事。
当像 ChatGPT 5.4 这样的非全模态模型接收到一段视频时，它需要先通过视觉模型提取帧，再通过类似 Whisper 的工具进行音频转录，最后应用 OCR 技术读取嵌入的字幕——这三个独立的过程需要拼接在一起，才能勉强达到全模态模型一次处理就能完成的效果。在理想条件下，例如光线充足、音频清晰的视频片段，一次实际测试耗时九分钟。
Qwen3.5-Omni 在一次调用中处理所有输入。发送视频，即可获得响应。无需中间流程，无需格式转换开销，也无需使用无法感知屏幕内容的音频模型或无法听到声音的视觉模型。
该模型支持文本、图像、音频和音视频理解，其中“思考者”和“谈话者”组件均采用混合注意力模型（Hybrid-Attention MoE）架构。最后一点比听起来更重要，我将在下面的架构部分详细介绍。
“全模式”在实践中的含义与拼接式管道的区别
这种差异在一些拼接系统难以应对的场景中尤为明显。例如：屏幕录制过程中，有人同时进行编码和解说；客服电话中，对话内容一半是语音，一半是屏幕显示；或者辅助功能字幕工作流程中，环境音频和视觉动作各自独立地承载着意义。
Qwen 团队展示了他们所谓的“视听感知编码”——该模型可以观看编码任务的屏幕录像，并完全根据所见所闻编写功能性代码，而无需任何文本提示。
这个演示名称有点奇怪，但它确实反映了与以文本为先导、音频后附加的模型相比，能力上的差距。当推理和感知同时在同一个模型中完成时，那些需要跨模态上下文的功能才能真正发挥作用。
三种版本：Plus、Flash 和 Light
此外——标杆领导者，物有所值
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 等平台竞争，并在质量上取胜的应用场景。
闪存——吞吐量和延迟之间的权衡
根据 API 文档，Flash 是生产环境的默认推荐方案。此处列出的型号 ID 指的是qwen3.5-omni-flash标准版本，Flash 在大多数生产场景下，兼顾延迟、质量和响应速度时，被描述为首选方案。
对于构建 AI 辅助工作流程（例如自动字幕生成流程、实时访谈转录、大规模视频摘要）的创作者来说，Flash 几乎肯定是他们的起点。您可以进行批量测试，对比 Plus 版本，以确定在您的特定应用场景下，质量提升是否值得付出相应的成本。
前代产品 Qwen3-Omni Flash 的语音响应延迟已低至 234 毫秒。预计 Qwen3.5-Omni Flash 的延迟表现也将与之相近，但初始发布说明中并未明确列出 3.5 版本的具体延迟基准测试数据。
轻量级——边缘计算和预算型应用场景
Light 是该系列中最小的型号。截至撰写本文时，3.5-Omni 系列的参数数量尚未完全确认，但其前代产品 30B-A3B 在消费级硬件上配合合适的量化设置运行良好，而 Light 型号可能也遵循类似的规律。
如果你正在进行原型设计、为客户构建对推理成本要求严格的产品，或者真正追求极致性能，那么 Light 就是你的起点。不要把它简单地归为“差劲的版本”——对于许多创作工具的工作流程（例如：自动生成缩略图字幕、基于上传音频的简单问答），它的功能可能绰绰有余。
What’s New vs. Qwen3-Omni
上下文窗口：25.6万个令牌，超过10小时的音频
从实际生产角度来看，这是我最关心的变化。
256K 个令牌的上下文窗口相当于超过 10 小时的音频，或者大约 400 秒的 720p 视频（含音频）。这是一个显著的提升。其前代产品 Qwen3-Omni 的思考模式最大只能处理 65,536 个令牌，最多支持 32,768 个令牌推理链——虽然实用，但仅限于较长的媒体内容。
对于播客分析、长篇采访处理、扩展客户通话摘要——此上下文窗口改变了单个 API 调用中实际可行的操作。
语言覆盖范围：113 种识别，36 种生成
语音识别功能现已支持 113 种语言和方言，比上一代产品的 19 种有所提升。语音生成功能也从 10 种语言扩展到 36 种。
坦白说，阿里巴巴对区域方言的统计方式会夸大其词，相比之下，OpenAI 等其他平台对相同覆盖范围的统计方式则更为严谨。即便忽略这一点，提升幅度依然显著。如果您面向东南亚市场、阿拉伯语内容或任何多语言语音工作流程进行开发，这将是一项意义重大的实用改进。
具有混合注意力模式的思考型谈话者
Thinker-Talker 架构最初是在 Qwen2.5-Omni 中引入的。3.5-Omni 的重要升级在于，这两个组件现在都采用了混合注意力 MoE（专家混合）设计，与 Qwen3.5 系列向稀疏架构的转变相一致。
对开发者而言，这至关重要：思考者-说话者分离机制允许外部系统（例如 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 镜像。
需要注意的是，在 MoE 模型上使用 HuggingFace Transformers 进行推理的速度可能非常慢，因此对于大规模或低延迟要求，建议使用 vLLM 或 DashScope API。
如果您选择自托管，请重点关注 vLLM 0.13.0 版本——这是官方安装文档中提到的版本。MoE 架构意味着其内存需求低于同等质量级别的同类密集型模型，但您仍然需要在启动生产部署之前验证 GPU 分配情况。
无差别级赛事状态：已确认与待定事项
这一点我需要谨慎，不要妄加猜测，以免超出已确认的事实。
Qwen3-Omni（前身）已在 GitHub 和 HuggingFace 上以 Apache 2.0 许可发布。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 令牌上限的工作负载。
它不涵盖的内容
并非图像生成模型
需要明确说明的是，“全模态”一词容易引起混淆：Qwen3.5-Omni 生成文本和语音，但并不生成图像或视频。它能够识别图像和视频作为输入——这是完全不同的功能。如果您需要生成图像，请查看 Qwen 的独立 VL 和图像生成产品线，或者qwen-image-plusDashScope 产品目录中的相关型号。
MoE上的推理速度：vLLM vs. HuggingFace Transformers
这个问题让很多使用 Qwen3-Omni 的用户感到困惑，也会让很多使用 3.5-Omni 的用户感到困惑。由于 Qwen3-Omni 采用的是 MoE 架构，因此在 MoE 模型上使用 HuggingFace Transformer 进行推理的速度可能会非常慢。对于大规模调用或低延迟要求，强烈建议使用 vLLM 或 DashScope API。
不要仅凭 HuggingFace Transformer 模型的基准测试就断定模型速度慢。在评估其生产可行性之前，应先在 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 目前已确认为正式版路径。Qwen3-Omni 支持通过 vLLM 进行自托管，权重发布后，3.5-Omni 也可能支持此功能。Plus 版本采用 MoE 架构，这意味着其活动参数需求低于同等密集模型，但完整版 Plus 需要多 GPU 配置。
它是否原生支持函数调用和网页搜索？
是的。Qwen 的博客文章明确强调了全渠道模型内置的原生网页搜索和函数调用支持。函数调用遵循标准的 OpenAI 工具格式，通过 DashScope API 实现。这是一个重要的差异化优势——您可以构建无需通过单独的编排层即可查询实时数据的语音代理。