Qwen3.8把音视频塞进Agent主链路：1M上下文、四模态输入，实时同传延迟降到2.3秒

9月18日，Qwen团队集中发布了Qwen3.8-Omni-Flash和Qwen3.8-LiveTranslate的技术说明。两款模型此前已陆续进入QwenCloud：qwen3.8-omni-flash在9月17日进入模型列表，qwen3.8-livetranslate-flash-realtime则更早出现在9月13日的更新记录中。

Omni-Flash可以原生接收文本、图片、音频和视频，最高支持1M上下文，并支持Thinking、Function Calling、Web Search和Context Cache；LiveTranslate面向实时同声传译，把流式语音理解、翻译、说话人区分和语音生成放进一条Realtime链路，官方给出的平均滞后指标LAAL从2.8秒降到2.3秒。

两款模型对应的是不同场景。Omni-Flash更偏向音视频理解后继续执行任务，LiveTranslate则直接处理实时跨语言交流。共同变化是，音频和视频开始直接进入模型上下文和Agent流程，不再必须先经过独立ASR、OCR或视频转写服务。

01｜Omni-Flash：四模态输入，文本输出

qwen3.8-omni-flash建立在Qwen3.8-Flash-Next架构之上，官方场景包括Coding、知识工作、GUI交互、视频编辑、影视解说、多媒体摘要和音视频对话，也支持双声道和四声道空间音频理解。

当前公开规格如下：

Omni-Flash当前的API输出仍然以文本为主。图片、音频和视频都可以进入同一套理解和推理链路，但它并不是文本、图片、音频和视频都能直接生成的四模态输出模型。

因此，它更适合用于“理解媒体内容后继续执行任务”。例如读取会议视频后提取Action Item、分析客服录音后调用CRM接口，或者理解产品视频后继续搜索外部资料。

如果业务需要实时语音输出，则需要使用Qwen对应的Realtime或Omni语音模型。

02｜1M上下文放到音视频任务里，成本结构会变

纯文本模型的1M上下文主要意味着可以放进更多文档、代码和历史消息。

Omni模型的输入结构更复杂，一次请求可能同时包含System Prompt、文本、图片、音频、视频、历史工具结果和Agent轨迹。

不同模态会分别转换为Token。当前文档给出的音频换算规则约为：

Audio Tokens = 音频秒数 × 7

一小时纯音频大约对应：

3600 × 7 = 25,200 tokens

按照中国内地当前公开刊例计算：

仅计算音频输入Token，一小时音频约为：

25,200 / 1,000,000 × 0.8 ≈ 0.020元

约2分钱。

这只是输入侧估算，不包含Thinking、输出、工具调用和重试，也不适用于包含大量视频帧的任务，但它可以反映音频理解成本已经下降到什么水平。

如果业务需要处理数百小时客服录音、会议或者播客，输入成本已经很难再成为第一道门槛。

03｜视频成本主要取决于采样方式

视频不能简单按照“分钟数×固定价格”估算。

一段视频至少包含视觉和音频两部分输入：

Video Cost = Visual Tokens + Audio Tokens

视觉Token还会受到分辨率、帧率和采样策略影响。

同一段60分钟视频，如果任务只是会议总结，可以降低视觉采样，把重点放在音频和少量关键画面；如果任务涉及GUI操作、动作顺序或产品细节，则需要更高的视频采样密度。

因此长视频测试至少要记录：

• Input Tokens / minute
• Audio Tokens / minute
• Visual Tokens / minute
• 视频采样率
• 关键事件召回率
• P50 / P95 Latency
• Cost / Successful Task

1M上下文解决的是容量问题，并不保证模型能够稳定利用整段内容。输入越长，噪声、历史信息干扰和首Token延迟也会同步增加。

生产系统更需要判断：多放进来的那些Token，有没有真正提高任务成功率。

04｜Omni-Flash已经可以进入Agent工具链

QwenCloud当前可以确认的能力包括：

• Function Calling
• Thinking
• Context Cache
• Web Search
• Chat Completions
• Responses API

当前明确支持的内置工具主要是web_search，搜索策略设置为agent。

一个音视频Agent可以按照下面的链路运行：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line音频 / 视频 / 图片 / 文本          ↓Qwen3.8-Omni-Flash          ↓理解 + Reasoning          ↓Function Calling / Web Search          ↓外部工具          ↓Tool Result          ↓最终文本输出

传统方案往往需要单独维护：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineVideo↓抽帧 / ASR / OCR↓Caption / Transcript↓拼接Prompt↓LLM↓Agent

原生多模态可以减少中间组件，但错误传播的问题仍然存在。如果模型先判断错了视频中的时间点，后面的搜索、工具调用和最终报告都会建立在错误输入上。

因此生产环境最好同时保存原始媒体、实际输入、Tool Call、Tool Result、时间戳和最终输出，方便后续定位问题来自感知、推理还是工具执行。

05｜官方Benchmark重点测“看完以后能不能继续做事”

Qwen此次发布的数据不只包含静态图像问答，也增加了更多音视频Agent和长程任务。

公开资料整理的官方结果显示，相比Qwen3.5-Omni-Plus，在约30项评测上平均得分提升超过26%。

部分指标如下：

这些数据来自Qwen官方，不等同于第三方独立复测，也不能直接外推到所有任务。

从指标方向来看，这一代重点明显从“识别图片里有什么”转向“处理完多模态输入后继续完成任务”。

生产测试可以进一步拆成：

• 视频关键事件召回率
• 时间戳准确率
• Tool Call成功率
• 长任务完成率
• Retry次数
• 人工返工率
• Cost / Successful Task

如果Benchmark上涨，但工具调用失败率没有下降，Agent侧的实际价值仍然有限。

06｜多人会议可能是更适合先落地的场景

多人会议对多模态模型要求比普通ASR高很多。

系统不仅要识别说了什么，还要判断是谁说的。只要Speaker Diarization出错，后续的会议摘要、Action Item和责任人识别都会跟着错。

公开的官方测试数据中，AliMeeting相关指标变化比较明显：

• DER：88.11 → 3.35
• cpWER：89.61 → 17.18

DER是Diarization Error Rate，主要衡量说话人区分错误率；cpWER更接近多人场景下的语音识别质量。

这个提升幅度很大，生产应用应使用自己的会议素材重新测试。测试集最好覆盖：

• 两人 / 四人 / 八人会议
• 同时说话
• 远场麦克风
• 环境噪声
• 方言
• 中英文混说
• 不同音量
• Speaker快速切换

如果真实会议里的DER也能明显降低，会议纪要、客服质检和访谈整理的处理链会比单纯提高ASR准确率更有价值。

07｜LiveTranslate采用Thinker–Talker两模块

qwen3.8-livetranslate-flash-realtime针对的是实时翻译场景。

当前公开能力包括：

• Audio + Image输入
• Text + Audio输出
• 60种源语言
• 29种语音输出语言
• 实时Speaker Diarization
• ASR转写
• WebSocket Realtime API

它采用基于Hybrid-MoE的Thinker–Talker双模块。

Thinker负责流式理解和翻译，把视觉信息、音频、源文本和翻译文本按照时间顺序交错进同一条因果序列。

Talker根据译文和源音频生成目标语音，并尝试保留原说话人的音色特征。

传统实时翻译系统一般是：

ounter(lineounter(lineounter(lineounter(lineounter(lineStreaming ASR↓Machine Translation↓TTS

三段式方案的问题在于，第一步ASR一旦识别人名、数字或者专业术语错误，后续翻译只能继续处理错误文本；另外还需要额外处理模块之间的时间轴和Speaker信息。

Thinker–Talker把更多原始信息保留在一条流式链路里，目标是减少模块之间的信息损失。

08｜2.3秒对应实时翻译的平均滞后

Qwen研究页给出的指标是Average Lagging（LAAL）。

上一代约为2.8秒，新版下降到2.3秒。QwenCloud产品资料则将其概括为端到端延迟约2.3秒。

因此2.3秒不应理解为“用户一句话说完以后，完整译文固定在2.3秒后返回”。

实时翻译至少涉及：

• 音频采集
• 语音分段
• ASR
• 语义判断
• 翻译
• 首包输出
• 语音生成
• 网络传输

而且同传天然需要在准确率和延迟之间做取舍。

系统等待更长时间，可以获得更完整的句子信息；输出过早，则可能在后半句出现以后需要修正前面的翻译。

实际产品测试至少要记录：

这些指标一起看，才接近会议、直播和跨语言沟通的真实体验。

09｜60种输入语言需要按语言方向分别测试

LiveTranslate支持60种源语言和29种语音输出语言。

这个数字代表覆盖范围，不代表每一个语言方向都达到相同质量。

中译英、英译中、日译中、粤语转普通话、阿拉伯语转英语，各自的语料规模、语序和口音差异都很大。

企业应用至少需要按照自己的业务方向分别建立测试集，而不是使用一个平均分决定是否上线。

特别是实时会议和客服，除了语言方向，还要加入：

• 方言
• 口音
• 人名
• 公司名称
• 产品型号
• 数字
• 日期
• 行业术语

这些通常比通用句子的翻译准确率更影响实际使用。

10｜音视频输入价格下降后，业务形态会变化

Qwen3.8-Omni-Flash当前国际区域公开价格为：

• Input：$0.15 / 1M tokens
• Cache Hit：$0.016 / 1M tokens
• Output：$0.47 / 1M tokens

中国内地公开刊例为：

• Input：0.8元 / 1M tokens
• Cache Hit：0.1元 / 1M tokens
• Output：2.7元 / 1M tokens

官方发布口径称，相比上一代，音频输入成本下降超过98%，音视频输入成本下降超过93%。

如果实际Token化和业务测试能够维持这个成本水平，一些过去只能抽样处理的音视频数据可以开始考虑全量进入AI管线，例如：

• 客服录音全量分析
• 会议库持续索引
• 视频素材自动打标
• 长视频片段检索
• 跨语种实时翻译
• 音视频内容触发后续工具

但最终仍然要看任务级成本：

Cost per Successful Task

每百万Token价格只是其中一个变量。一次任务跑多少轮、用了多少工具、失败几次、人工还要返工多久，都会影响实际ROI。

11｜接入时建议直接和现有管线做AB Test

Omni-Flash可以和现有多模态流程直接对比。

Baseline：

ounter(lineASR → OCR / 抽帧 → LLM → Tool

新方案：

ounter(lineOmni-Flash → Tool

固定同一批会议、客服录音和视频素材，记录：

• 总Token
• 总Latency
• 关键片段召回率
• Speaker Attribution
• Tool Call成功率
• Retry Rate
• 人工返工时间
• Cost / Successful Task

LiveTranslate则可以和：

ounter(lineStreaming ASR → MT → TTS

做对照。

重点加入：

• 多人切换
• 专有名词
• 音色保持
• 长会话一致性
• 弱网恢复
• 中英文夹杂
• 方言
• 视觉上下文消歧

如果一体化模型可以减少两个中间服务，却在错误定位和调试上增加大量成本，那么整体工程收益未必一定为正。

12｜Qwen3.8这一轮，音视频开始直接进入Agent上下文

Qwen3.8-Omni-Flash当前的产品边界很清楚：文本、图片、音频和视频进入同一模型上下文，输出文本，再通过Function Calling和Web Search继续执行任务。

LiveTranslate走另一条实时链路：音频和视觉上下文输入，翻译文本和语音持续输出。

过去音视频在很多AI系统里只是附件，需要先经过ASR、OCR、Caption或者抽帧转换成文字，再进入LLM。现在这部分中间转换正在缩短。

对于开发团队，下一步更适合围绕四个问题测试：长任务能不能稳定完成，工具调用是否可靠，实时延迟是否满足业务要求，以及完成一次任务到底需要多少钱。

1M上下文、60种语言、2.3秒延迟都只是规格。

真正决定是否上线的还是同一批真实任务跑完以后，减少了多少中间服务、多少人工返工，以及每个成功任务的成本有没有下降。

参考来源

1. Qwen：《Qwen3.8-Omni-Flash: Omni Senses. Agentic Delivery》
2. QwenCloud：《Model releases》
3. Qwen：《Qwen3.8-LiveTranslate》
4. QwenCloud：《Omni-modal models》
5. Alibaba Cloud Model Studio：《Model Pricing》
6. Alibaba Cloud Model Studio：《Qwen Omni Billing》