Qwen 3.8 Omni Flash来了

阿里千问近日发布 Qwen 3.8 Omni Flash，把 Qwen 3.8 系列进一步扩展到面向实时交互的全模态场景。新模型的定位很明确：不只处理文字和图片，而是围绕音频、视频、视觉与文本的连续输入，服务语音助手、视频理解、实时客服和具身智能等对延迟敏感的应用。

截至 2026 年 9 月 18 日，这次更新最值得关注的不是“Omni”这个后缀本身，而是阿里正在尝试把旗舰模型能力压进一条足够快、足够便宜的在线推理链路。对于开发者来说，Qwen 3.8 Omni Flash 的价值最终不会由静态跑分决定，而会由首包延迟、语音打断、长会话稳定性和单位会话成本决定。

Qwen 3.8 Omni Flash 是什么

Qwen 3.8 Omni Flash 是阿里千问面向低延迟应用推出的新一代全模态模型。“全模态”意味着模型可以在同一套交互流程中处理文本、图像、音频和视频等信息，而不是要求开发者先用语音识别模型转文字、再调用语言模型、最后接入语音合成模型。

**Flash 是一类优先优化推理速度、吞吐量和成本的模型定位。**它通常不会单纯追求参数规模最大或所有排行榜第一，而是强调在在线产品中持续处理高并发请求，尤其适合实时客服、智能座舱、数字人和端云协同助手。

**低延迟全模态模型是能够边接收多媒体输入、边理解上下文并流式返回结果的统一模型。**传统多模型串联方案像一条依次运行的流水线：先完成 ASR，再让大模型推理，最后由 TTS 合成声音；全模态流式模型则试图让多个步骤重叠执行，把等待完整输入的“批处理”改成持续收发的“实时通话”。

这一区别直接决定了产品体验。用户对文字聊天延迟的容忍度可以达到数秒，但在语音对话中，停顿超过约一秒就容易产生明显的“机器感”；如果模型还需要理解摄像头画面、共享屏幕或视频流，系统延迟会进一步叠加。

这次升级的核心，不是再加一个输入框

**Qwen 3.8 Omni Flash 的产品目标是把多模态理解变成可连续运行的交互能力。**能够上传一段音频并得到摘要，和能够在会议进行过程中实时识别发言者、观察共享屏幕、理解指代关系并随时回答问题，是两种完全不同的系统难度。

一个典型的实时视频助手需要同时完成至少五件事：

• 持续接收音频流，并判断哪些片段包含有效语音；
• 从视频流中选择有信息量的帧，而不是逐帧重复计算；
• 将“这个按钮”“刚才那张图”等指代映射到视觉上下文；
• 在用户说完之前预测任务意图，提前准备回答；
• 在用户插话时中止当前输出，保留上下文并重新规划。

**实时性不是单个模型指标，而是一整条系统链路的结果。**模型生成速度很快，不代表用户听到第一句话也快；首个文本 Token、首个音频包、网络传输、音频编码和客户端播放缓冲，都会影响最终体验。

因此，判断 Qwen 3.8 Omni Flash 是否真正适合低延迟应用，至少要看以下四项数据：

| 指标 | 定义 | 对产品体验的影响 | |---|---|---| | 首 Token 延迟（TTFT） | 从请求开始到返回第一个文本 Token 的时间 | 决定文字助手是否“立即有反应” | | 首音频包延迟 | 从用户停止或暂停说话到客户端收到首段语音的时间 | 决定语音通话的自然程度 | | 实时因子（RTF） | 处理音频或视频所需时间与素材时长之比 | RTF 低于 1 才能稳定追上实时输入 | | 打断恢复时间 | 用户插话后，模型停止旧回复并开始新回复所需时间 | 决定模型能否用于自然双向对话 |

**阿里目前公开材料强调了低延迟定位，但尚不足以完整量化端到端体验。**在官方给出统一硬件、相同输入长度和固定并发条件下的 TTFT、首音频包延迟及 RTF 之前，“低延迟”更适合作为产品方向，而不是已经被充分验证的性能结论。

Qwen 3.8 架构提供了效率基础，但不能直接等同于 Omni 规格

**Qwen 3.8-Flash 是 Qwen 3.8 Omni Flash 最重要的同系列技术参照。**此前发布的 Qwen 3.8-Flash 采用混合专家模型，即 MoE 架构；MoE 是把模型参数分成多个专家模块、每次推理只激活其中一部分的模型结构。

公开资料显示，Qwen 3.8-Flash 拥有约 125B Transformer 参数，单次推理仅激活约 6B 参数。这种设计类似于一家公司拥有大量专业团队，但每次任务只召集最相关的少数团队参与，理论上能够以更低计算量获得接近更大稠密模型的能力。

**Qwen Sparse Attention 是 Qwen 3.8 系列用于降低长上下文计算开销的稀疏注意力机制。**标准注意力需要让大量 Token 两两建立关系，输入越长，计算与显存压力越明显；稀疏注意力则优先保留重要连接，减少大量价值有限的重复计算。

公开资料还显示，Qwen 3.8-Flash 将 QSA 与 GDN 高效结构结合，在高缓存命中的百万 Token 场景中，速度可达到此前方案的 8 倍以上。这一能力对 Omni 模型尤其重要，因为视频帧、音频片段和文字转录会迅速消耗上下文预算。

**Gated Residual 是一种允许模型动态控制信息写入与传递的门控残差机制。**Qwen 3.8-Flash 将传统 Transformer 的单条信息主通道扩展为四条，使模型可以根据当前任务决定读取、保留或更新哪些信息，目标是提高训练稳定性和信息传递效率。

**N-gram Embedding 是通过词片段查表提供额外记忆信息的嵌入机制。**Qwen 3.8-Flash 引入约 51B N-gram Embedding 参数，这些参数不需要像 Transformer 主干参数那样在每个 Token 上完整参与计算，更像一本按需查询的“外置索引手册”。

不过，**Qwen 3.8-Flash 的公开架构不能被直接视为 Qwen 3.8 Omni Flash 的完整规格。**全模态模型还需要处理音频编码、视觉帧压缩、跨模态对齐和语音解码，是否沿用相同的 125B 总参数、6B 激活参数、QSA 配置及 N-gram Embedding 规模，需要以 Omni 版本的模型卡或技术报告为准。

与 Qwen 3.8-Flash、上一代 Omni 有什么区别

**Qwen 3.8 Omni Flash 与 Qwen 3.8-Flash 的核心区别是输出形态和实时交互目标。**前者面向持续音视频交互，后者更像高性价比的多模态推理与 Agent 模型，适合代码、文档、图片、视频分析以及工具调用。

| 产品 | 主要定位 | 输入形态 | 主要输出 | 实时语音交互 | 已公开上下文信息 | 价格状态 | |---|---|---|---|---|---|---| | Qwen 3.8 Omni Flash | 低延迟全模态交互 | 文本、图像、音频、视频 | 文本与实时交互结果，具体语音规格以模型页为准 | 核心目标 | 尚待独立模型页确认 | 所给发布材料未明确完整计费表 | | Qwen 3.8-Flash | 高性价比多模态推理与 Agent | 文本、图像、视频 | 文本 | 非核心定位 | 1M 上下文，最大输入 991K、最大输出 131K | 输入 0.8 元/百万 Token，输出 2.7 元/百万 Token | | Qwen3-Omni-Flash 旧版本 | 实时全模态交互 | 文本、图像、音频、视频 | 文本、语音 | 支持 | 依具体版本而定 | 依部署平台和版本而定 |

**Qwen 3.8-Flash 的价格不能直接套用到 Qwen 3.8 Omni Flash。**Qwen 3.8-Flash 当前公开价格为输入 0.8 元/百万 Token、输出 2.7 元/百万 Token，缓存命中输入为 0.1 元/百万 Token；批处理输入和输出分别为 0.4 元与 1.35 元/百万 Token。音频和视频往往采用不同的计量或折算方式，Omni 模型的真实成本必须结合媒体时长、采样率、视频帧率及语音输出时长计算。

**缓存能力对全模态模型的成本影响会比普通聊天模型更大。**同一场会议、监控视频或远程协作会话中，大量背景信息不会频繁变化；如果系统可以复用视觉特征和历史上下文，就没有必要在每轮对话中重新处理全部内容。

真正适合它的，是四类低延迟应用

**实时语音助手是 Qwen 3.8 Omni Flash 最直接的落地场景。**模型需要识别语气、停顿和上下文，在用户结束一句话前开始规划答案，并支持自然打断；相比“语音转文字加聊天机器人”，统一模型有机会减少语义在多级转换中的损失。

**屏幕与视频协作助手是更能体现全模态价值的场景。**例如用户一边共享 IDE，一边描述编译错误，模型需要同时理解终端日志、代码窗口和口头问题；如果仍把截图、语音和文本拆成多个孤立请求，模型很容易丢失时间顺序和指代关系。

**智能座舱与具身设备是对延迟和环境理解要求最高的场景。**用户说“前面那个路口右转后找个有停车{"title":"千问3.8 Omni Flash上新","summary":"阿里发布 Qwen 3.8 Omni Flash，以文本、图像、音频和视频统一理解及流式语音输出，瞄准实时助手、会议、直播和端侧智能体。真正的看点不是多一种输入，而是全模态交互能否稳定跑进低延迟生产环境。","content":"# 千问3.8 Omni Flash上新

**9 月 18 日，阿里 Qwen 团队发布 Qwen 3.8 Omni Flash，将新一代千问能力推进到强调实时响应的全模态交互场景。**新模型面向文本、图像、音频和视频的统一理解，并支持以文本和自然语音进行流式反馈，目标不是再做一个“能看图的大语言模型”，而是进入语音助手、视频分析、实时会议和具身智能等对延迟更敏感的产品环节。

**Qwen 3.8 Omni Flash 是一款面向低延迟应用的全模态模型。**这里的“全模态”不是简单地在语言模型前面拼接语音识别和图像识别模块，而是让文本、画面、环境声音、说话内容和时间顺序进入同一套理解链路，再由模型直接组织文本或语音回复。

“Omni”与“Flash”分别意味着什么

**Omni 代表统一处理多种模态，Flash 则代表产品设计优先照顾响应速度、吞吐量和部署成本。**这两个标签组合在一起，意味着 Qwen 3.8 Omni Flash 不以单项推理跑分或最大参数规模为唯一目标，而是要在用户开口、摄像头持续输入、模型理解和语音回复之间，尽量缩短整条链路。

传统实时语音助手通常由自动语音识别、语言模型和语音合成三个独立系统串联。用户说一句话，系统先将音频转换成文字，再把文字交给大模型，最后把回复文本送入语音合成器；如果还需要理解摄像头画面，则要额外加入视觉模型。这类级联系统容易调试，但每增加一层，都会增加排队、网络传输和推理时间，也会损失语气、停顿、背景声音等非文本信息。

**原生全模态模型的价值在于减少模态转换造成的信息损耗和系统延迟。**例如，用户拿手机对准一台发出异响的设备并询问故障原因，模型需要同时理解画面中的指示灯、设备结构、声音节奏和用户问题；如果先把声音压缩成文字，“每隔两秒一次的短促蜂鸣”这类信息很可能直接消失。

**流式输出也不等于真正的实时对话。**模型能够一边生成一边播放语音，只说明系统不必等完整答案生成完毕；真正影响体验的指标还包括语音活动检测时间、首个音频分片延迟、用户插话后的中断速度、长对话中的上下文保持能力，以及高并发下的 P95 和 P99 延迟。

Qwen 3.8 Omni Flash与普通Flash不是同一个模型

**Qwen 3.8 Omni Flash 不应与 8 月发布的 Qwen 3.8-Flash 混为一谈。**后者主要输出文本，侧重点是长上下文、智能体、编程和视觉理解；前者进一步覆盖音频输入与语音输出，服务对象更接近实时交互产品。

| 模型 | 主要输入 | 主要输出 | 核心定位 | 已公开的关键指标 | |---|---|---|---|---| | Qwen 3.8 Omni Flash | 文本、图像、音频、视频 | 文本、流式语音 | 实时全模态交互、低延迟应用 | 官方此次重点强调实时流式交互；完整延迟数据仍需结合部署环境验证 | | Qwen 3.8-Flash | 文本、图像、视频 | 文本 | 编程、智能体、长文档和高并发推理 | 1M 上下文，最大输入 991K Token，最大输出 131K Token | | Qwen3-Omni-Flash-2025-12-01 | 文本、图像、音频、视频 | 文本、语音 | 上一代实时全模态服务 | 支持 119 种文本语言、19 种语音识别语言和 10 种语音合成语言 |

**Qwen 3.8-Flash 的公开参数可以帮助理解“Flash”路线，但不能直接套用到 Omni 版本。**Qwen 3.8-Flash 是多模态混合专家模型，Transformer 参数规模为 125B，每个 Token 仅激活约 6B 参数，并额外引入 51B N-gram Embedding 参数；其公开服务价格为每百万 Token 输入 0.8 元、输出 2.7 元，缓存命中输入为每百万 Token 0.1 元。

**混合专家模型是每次推理只调用部分专家参数、以较低计算量承载更大模型容量的架构。**125B 参数不代表每生成一个 Token 都要完整计算 125B 参数，约 6B 的激活规模才更接近单步推理的主要计算负担，这也是 Flash 型号能够兼顾能力和速度的重要原因。

不过，Qwen 3.8 Omni Flash 是否完整沿用 Qwen 3.8-Flash 的 QSA、GDN、Gated Residual 和 N-gram Embedding 组合，仍应以 Omni 模型技术报告和模型卡为准。全模态版本还要处理音频编码、视频时间轴、跨模态对齐和语音解码，不能因为名字里同样包含“3.8”和“Flash”，就默认两者拥有完全相同的内部结构、上下文规格或计费方式。

低延迟不是一个数字，而是一条链路

**Qwen 3.8 Omni Flash 最值得关注的变化，是阿里开始把全模态能力从演示项目推向可持续交互的基础模型。**对于实时产品，用户感受到的不是模型在某块 GPU 上每秒生成多少 Token，而是从自己说完半句话到系统给出第一段有效回应，需要等待多久。

一个完整的实时交互链路至少包括以下五段：

1. 输入采集延迟：麦克风和摄像头需要积累足够的音视频帧；
2. 编码与上传延迟：音视频要被压缩、切片并发送到推理服务；
3. 多模态理解延迟：模型需要对齐画面、声音、字幕和历史上下文；
4. 首包生成延迟：系统生成第一段可展示文本或可播放语音；
5. 连续生成延迟：后续语音必须稳定输出，不能频繁卡顿或突然加速。

**真正好用的语音模型必须同时控制首包延迟和持续播放速度。**首包很快但后续生成跟不上，语音就会断断续续；持续吞吐很高但必须等待完整输入结束，用户仍会觉得它像语音留言系统，而不是可以自然插话的助手。

**截至 9 月 18 日，公开发布信息还不足以给出统一硬件和统一并发条件下的首音频延迟、实时率 RTF、P95 延迟及打断响应时间。**因此，“低延迟”目前更准确地说是 Qwen 3.8 Omni Flash 的产品定位，而不是已经完成第三方复现的性能结论。开发者在选型时，应该重点等待或自行测试这些数字，而不是只看官方演示中一次成功的实时对话。

这次升级最适合四类应用

**实时视觉语音助手是 Qwen 3.8 Omni Flash 最直接的落地场景。**用户可以持续打开摄像头，让模型观察设备、商品、道路或操作界面，再用自然语言追问；模型不必将每一帧孤立分析，而可以结合视频前后变化给出解释。

**会议和客服系统会从统一的音视频上下文中获益。**普通会议转写只能记录“说了什么”，全模态模型还可以理解屏幕共享中的图表、发言者指向的页面区域以及语气变化，从而生成更可靠的行动项。不过，企业部署仍需处理说话人分离、专有名词、权限隔离和录音合规，这些问题不会因为底层模型升级而自动消失。

**直播与数字人应用需要的正是可控且连续的语音生成。**模型如果能够根据内容动态调整语速、停顿和韵律，就可以减少传统“语言模型生成文案，再交给 TTS 配音”的割裂感；但商业直播还要求稳定的人设、敏感词控制和数小时连续运行，这些指标通常比单轮语音自然度更难。

**机器人和具身智能则需要更严格的实时性与可靠性。**机器人面对的是连续变化的物理环境，视频与声音必须按时间顺序对齐，模型还要判断什么时候应该回答、什么时候应该执行动作、什么时候必须停下来请求人工确认。对这类场景而言，错误动作的代价远高于聊天机器人答错一道题，因此 Omni 模型仍需要外部安全策略和确定性控制系统兜底。

阿里的优势是模型、云和应用可以一起压延迟

**阿里做 Omni Flash 的现实优势并不只在模型架构，而在于能够同时优化推理服务、音视频传输和上层应用。**低延迟是一项系统工程，模型即使在单卡测试中足够快，如果在线服务存在排队、跨地域传输或频繁冷启动，最终体验仍然会变差。

Qwen 3.8-Flash 已经展示了这一代模型对效率的重视。公开资料显示，其训练成本较 Qwen 3.7-Plus 降低近 90%；在缓存命中的 1M Token 长上下文场景中，新注意力设计可实现超过 8 倍的加速。Qwen 3.8-Flash 在 SWE-bench Pro 上领先 Claude Opus 4.6 最多 9.1 分，在 AndroidWorld、MathVision 和 ERQA 上分别领先 22.5 分、25.1 分和 31.5 分。

**这些成绩能证明 Qwen 3.8 系列在智能体与视觉推理上的基础能力，但不能直接证明 Omni Flash 的实时语音体验。**智能体基准通常衡量任务完成率，实时语音则更看重首包时间、打断恢复、声音稳定性和噪声环境鲁棒性，两者的评测目标并不相同。

开发者选型时应重点测试什么

**开发者不应只用一段安静环境下的普通话对话判断 Qwen 3.8 Omni Flash 是否可用。**更有效的测试集应该覆盖真实产品最容易失败的边界条件。

• 首包延迟：分别记录纯文本、纯语音、带图片和持续视频输入下的首个有效响应时间；
• 打断能力：测试用户在模型说话期间插话，系统需要多久停止旧回复并处理新问题；
• 噪声鲁棒性：加入键盘声、街道声、多人交谈和远场回声；
• 音画同步：检查模型能否正确引用几秒前出现、随后离开画面的对象；
• 长时稳定性：连续运行 30 分钟至 2 小时，观察上下文漂移、声音变化和延迟累积；
• 工具调用：让模型在语音对话中查询数据库、操作软件或调用搜索工具，检查失败后的恢复能力；
• 成本曲线：分别计算空闲监听、连续视频输入、长语音输出和高并发条件下的实际费用。

**隐私边界也是全模态产品必须提前解决的问题。**持续开启麦克风和摄像头意味着系统会接触比文本聊天更多的个人信息，企业需要明确音视频是否保存、保存多久、是否用于训练，以及敏感内容能否在本地完成过滤。

判断：方向正确，但还需要可复现的延迟成绩

**Qwen 3.8 Omni Flash 的方向是对的，因为下一阶段的 AI 入口很可能不是聊天框，而是持续存在的音视频交互界面。**当模型能够同时看见屏幕、听见环境并以自然语音回应，AI 助手才有机会从“问一句答一句”升级为理解现场状态的协作者。

**这次发布的真正价值，是把 Qwen 3.8 系列的智能体和多模态能力带进对实时性更敏感的产品赛道。**相比单纯扩大参数规模，降低端到端延迟、提升打断能力和压低持续音视频处理成本，更能决定模型是否进入客服、会议、直播、智能眼镜和机器人等高频场景。

**Qwen 3.8 Omni Flash 目前仍需要更透明的工程数据来完成说服。**如果后续模型卡能够公布统一硬件下的首音频延迟、RTF、并发吞吐、长视频规格、语言覆盖和价格，并允许社区在公开权重或标准服务上复现，那么它才有资格成为新一代实时全模态应用的默认底座；在此之前，开发者应该把它视为一个值得测试的新选项，而不是仅凭“Omni”和“Flash”两个标签直接替换现有生产链路。

参考来源

• QwenLM / Qwen3-Omni GitHub 仓库：用于了解 Qwen Omni 系列的模型架构、部署方式与开源进展。
• Qwen Hugging Face 官方主页：用于核对 Qwen 团队公开模型、模型卡、权重及许可证信息。
• QwenLM / Qwen3 GitHub 仓库：用于了解 Qwen3 系列基础架构、推理支持与社区生态。