Qwen3.8-Omni-Flash 对比 Qwen2.5-Omni：18个月后，升级版失去了声音

下面这个事实，让这场对比比一次常规的代际更新有意思得多：老模型能说话，新模型却不能。Qwen2.5-Omni于 2025 年 3 月发布，可接收文本、图像、音频和视频输入，并以文本或流式自然语音作答，全部集成在一个可下载的端到端模型中。Qwen3.8-Omni-Flash于 2026 年 9 月 18 日发布，同样支持这四种模态，但上下文窗口扩大了三十倍，能吞下一小时连续的音视频内容，而其前辈只能处理几秒钟，且只返回文本。十八个月的研发换来了大幅拓宽的输入能力，却舍弃了输出通道。这究竟是进步还是取舍，完全取决于你当初用老模型做什么——而答案清晰地分成两派。

这些数据属于Qwen2.5-Omni的厂商，出自其 2025 年 3 月的发布材料，而历经十八个月的大规模部署，这些数据已得到部分验证。Qwen3.8-Omni-Flash的数据同样来自阿里巴巴，出自本文撰写前数小时发布的发布材料，其中没有任何内容经过独立复现。凡某项说法出自批评者而非厂商，均按此注明出处。有一个无需验证的结构性事实，同时也是最关键的：Qwen2.5-Omni是开放权重、可供下载的，而Qwen3.8-Omni-Flash则不是。

Qwen2.5-Omni 曾是什么，以及它为何重要

当它于2025年3月26日发布时，Qwen2.5-Omni是该系列中首个端到端全模态模型——发布时将其定位为解决“专家模型动物园”问题的答案，即转录、视觉和语音各自都需要单独的模型和单独的黏合层。7B 模型处理全部四种输入模态以及文本和语音输出，声称在 OmniBench 融合基准上取得了领先于 Gemini-1.5-Pro 的最先进结果，并报告了 4.51 的语音生成质量分数，阿里巴巴称其达到人类水平。一个 3B 变体采用了相同架构。

让它奏效的工程技术值得一提，因为新模型并未采用它。Thinker-Talker将工作一分为二：Thinker transformer 融合音频与图像编码器，生成语义与文本，而 Talker 则从 Thinker 的隐藏状态中流式输出语音 token，并共享完整的对话历史。时间对齐的多模态 RoPE（TMRoPE）将视频与音频位置交错排列，使两路流保持同步。分块流式处理让编码器负责感知，语言模型处理长序列，这正是实现低延迟语音回复的关键。随模型一同发布的有两个固定声音：Chelsie 和 Ethan。

这些约束同样真实。上下文是 32,768 个 token。内存远比算力更是硬性限制：阿里巴巴自家的表格显示，使用 FlashAttention-2 进行 BF16 推理，处理一段 15 秒的视频大约需要 31GB 的 GPU 显存，30 秒需要 42GB，完整一分钟则需要 60GB。一分钟的视频，跑在 7B 模型上，用的是你能租到的最大的单块 GPU 之一。这个数字必须始终放在眼前，因为 2026 年的模型就是为了摧毁这个数字而构建的。

Qwen3.8-Omni-Flash 是什么

新模型是原生全模态，而非拼装而成——它直接构建在Qwen3.8-Flash架构系列之上，而不是一个外挂了感知编码器的文本 LLM，这是结构性的差异，而不只是一个代际标签。它接受文本、图像、音频和视频输入，包括立体声和四声道空间音频，并在一百万 token 上下文中返回文本，最大输入约 991K，最大输出 131K，推理预算 262K。它每次调用可处理长达一小时的连续音视频。语音识别覆盖 74 种语言，语音生成覆盖 29 种语言，后者由周边工具链而非模型本身完成。它已在通义千问 AI 平台和阿里云百炼（Model Studio）上线，ID 为 qwen3-8-omni-flash，每百万输入 token 0.15 美元，每百万输出 token 0.47 美元，缓存输入为 0.016 美元。

十八个月，逐个维度

• 上下文——Qwen2.5-Omni 的 32,768 个 token 相较于 Qwen3.8-Omni-Flash 的一百万个，大约增加了三十倍。

• 媒体时长 — 视频秒数，受 GPU 内存限制；而在单次托管通话中，则为一小时的连续音视频。

• 输出 — 旧模型上为文本加流式自然语音；新模型上仅有文本。

• 部署 — Qwen2.5-Omni 以开放权重形式发布，采用 Apache-2.0 许可，可从 Hugging Face 和 ModelScope 下载；Qwen3.8-Omni-Flash 仅提供 API，未公布权重发布计划。

• 硬件 — 处理一分钟视频，7B 参数最多需要约 60GB 的 GPU 显存，而托管端点则完全无需你自行配置。

• 价格——旧模型会占用你一块 GPU；新模型每百万输入 token 仅需 $0.15，而阿里巴巴声称，其每小时音频输入成本比它所替代的 Qwen3.5-Omni-Plus 一代便宜 98%。

• 语音生成——2025 年只有两种固定音色，而 2026 年的工具则支持 29 种语言的语音生成，且这些语音没有一条是模型自身生成的。

无人宣传的交易

把这两份规格表放在一起读，过去十八个月的脉络就清晰了。阿里巴巴在这段时间里解决的是摄入——一个模型能吸收多少媒体、成本能压到多低，以及有多少决策它可以自己拿主意。Qwen3.8-Omni-Flash在这条轴线上是一场胜利。在 Agentic Understanding 模式下，模型自行选择采样对象，而不是逐帧处理，使每次查询的 token 数从 145,736 降到 79,117，同时把 OmniVideoBench 准确率从 63.4 提升到 67.8；厂商还报告 AliMeeting 上的说话人分离错误率从 88.11 骤降至 3.35。

这一间隔期没有优先考虑的，是输出。2025款模型的标志性绝技——一个模型就能听见你说话并大声作答，端到端，无需单独的语音合成器——在这里没有后继者。如果你曾在 Qwen2.5-Omni 的 Talker 之上构建过语音代理、配音流水线或无障碍工具，那么2026款模型并不是它的升级；它只是一个组件，你得额外为它加装一个新的文本转语音阶段，为原本两者皆无的流水线增添延迟和供应商依赖。如果你仔细阅读模态那一行，会发现发布材料对此是坦承的，但这并非宣传重点，而任何以为“omni”在两次发布中含义相同、据此迁移的人，都会在生产环境中发现差异。

为什么 2025 年的模型仍然有工作

三个理由，而且都不是怀旧。第一是音色，如上所述。第二是开放权重：32K 上下文和 7B 的体量，可以运行在你自己掌控的硬件上，离线运行，数据不出楼，也没有按 token 计费的电表——如果你的音频受数据驻留规定约束，或者你的延迟预算不允许一次往返，这就是唯一的选择。第三是极低用量下的成本。你自己已经拥有的 GPU 边际成本为零；托管模型每百万 token 0.15 美元确实便宜，但并非免费，而对于每周只运行两次的工作负载来说，为使用它所做配置的固定成本是实实在在的。

反方观点是，旧模型的限制一年比一年更致命。一分钟视频、32K 上下文，而且在智能体已成为默认部署形态的世界里既不支持工具调用也不支持结构化输出，这样的能力范围太窄了。对于必须摄取录制会议内容的流水线而言，Qwen3.8-Omni-Flash不只是更好——它决定了事情可行还是根本不可行，因为 2025 年的那个模型在物理上就无法容纳这些输入。

值得具体说明这些旧权重还有多少生命力，因为“legacy”这个说法低估了它们。该Qwen2.5-Omni-7B仓库记录了过去一个月 343,676 次下载——这是我们在 2026 年 9 月 18 日查看它时看到的情况，其上还构建了约一百个社区 Spaces 以及数十个微调模型、适配器和量化版本。无论旗舰模型如何，仍有大量用户继续基于 2025 年的模型发布成果——而且值得注意的是，Hugging Face 没有列出任何部署它的推理提供商，这意味着几乎所有这些使用都是自托管的。

新模型改进了旧模型。

这次发布中最奇怪也最有说服力的细节，藏在材料的末尾附近。在一项阿里巴巴称之为"模型优化模型"的实验中，Qwen3.8-Omni-Flash自主提升了Qwen2.5-Omni-3B的四川方言语音识别能力——后者正是它名义上所要取代的那个模型的小号同胞——将字符错误率从25.79% 降至 15.30%，整个过程在十二小时内完成，并在四轮迭代中构建了 3,413 个训练样本。

对于新模型而言，这一论据比发布中的任何基准测试都更有说服力，并且它重新定义了两者之间的关系。2026模型不仅是对2025模型的替代，更是一种能让2025权重变得更好的工具。如果你在生产环境中运行Qwen2.5-Omni，而它对你需要处理的语言或方言表现不佳，实际可行的路径或许是保留现有部署，并用新模型来构建训练数据，而不是迁移工作负载。不过请注意，这是供应商报告的演示，没有公开的方法论，应将其视为一个令人鼓舞的轶事，而非可复现的方法。

如果你正在迁移

决定很少只取决于一个模型。一个要离开自托管全能模型的团队，实际上是在三种形态之间做选择：继续留在开放权重上并维持资源调配，转向厂商 API 并放弃控制权，或者拆分工作负载，只把需要百万级 token 输入的那部分交给托管模型。第三种选择通常才是对的，也恰恰是人们会跳过的那一种，因为它听起来比实际工作量更大——你花了一个月做的方言微调，不必因为会议摘要阶段迁移了就被丢掉。

路由真正能帮上忙的地方，正是那些衔接的“接缝”处。OrcaRouter 为你提供一把密钥即可访问 200 多个模型，按提供商标价零加价，并在端点性能下降时自动故障转移，这意味着，在你弄清某项工作负载是否值得投入这一切之前，拆分式流水线中托管的那一半不必先有自己的合同、自己的客户端代码和自己的监控。有一点要说明清楚，即我们不做什么：两款 omni 模型都不在我们的目录中——它们都运行在阿里巴巴的平台上，或你自己的硬件上——所以这是你围绕这些模型做出的路由决策，而不是通过我们做出的决策。

谁应该移动，谁不应该移动

如果你的工作负载是长音频或长视频，如果 32K 上下文正是让某条流水线无法成立的关键，如果你需要对媒体进行智能体式操作，或者如果你面临的问题是大规模说话人分离，那就迁移。如果你需要模型开口说话，如果你的音频不能离开你的基础设施，如果你依赖已经调好的特定 Qwen2.5-Omni 权重，或者如果你的调用量低到自有 GPU 比按量计费更划算，那就留下。

令人不安的总结是，这与其说是一次替代，不如说是产品线上的一次分叉。Alibaba 花了十八个月打造出它能做到的最好的输入模型，却没有为输出那一半打造出继任者。如果你的工作处在输入这一侧，这次升级几乎是强制性的。如果你的工作处在输出这一侧，2025 版模型仍然是能满足你需求的最新东西——而在你规划一次会悄然删除你所依赖能力的迁移之前，这一点值得了解。