Qwen3.8-Omni: Towards Native Omni-Modal Agents
在解决如何使全能模型能够执行诸如视频剪辑和分析等长周期多模态生产力任务，而不会因处理完整长度的视频而产生高昂的 Token 成本。
结论证明了将全能模型封装在原生智能体框架中可以大幅降低长视频的 Token 消耗并提高推理能力，尽管该模型在几项智能体和视频推理任务上仍落后于 Gemini 3.8 Flash，并且部分核心的多语言翻译能力略有倒退。
AgentInference
发表Not reported · arXiv 2609.25611 · 代码
精读于2026-09-23
可信度对机制和基准测试的胜利置信度高；由于缺乏硬件和服务的消融实验，对确切的成本降低声明置信度中等。
阅读范围Full LaTeX source, all 24 files incl. appendix given in full; 0 of 7 figures viewed by the reader
精读Gemini 3.1 Pro · 经独立审校
1. 任务
这篇论文解决的是什么问题：现有的全能模型难以支持复杂、长周期的多模态生产力工作流（如视频剪辑和电影生成），因为原生处理长视频输入的 Token 成本过高，并且现有的智能体框架缺乏对流式输入的支持。 为什么重要且困难：长视频包含海量的 Token。将完整视频直接输入模型上下文中会把 Token 浪费在无关帧上。此外，实时的多模态交互需要在严格控制延迟的同时，协调内存、工具和子智能体。 现有方法的不足：此前的智能体系统主要专注于基于文本的软件工程或 GUI 交互，仅将视觉/音频用作静态的一次性感知。它们无法动态浏览视频的时间轴或按需选择性地收集音视频证据。
2. 核心思路
Qwen3.8-Omni-Flash 不再是在单次 prompt 中被动输入完整的长视频和音频（这会导致 Token 爆炸），而是作为一个活跃的原生多模态智能体。它利用专用插件首先将长音视频输入抽象为文本摘要，然后根据需要延迟加载或检索特定的细粒度片段，从而在 100 万 Token 的上下文中高效地实现复杂的视频推理。
3. 机制 + 心智模型
- 架构： “Thinker” LLM（基于具有 1M 上下文的 Qwen3.8-Next 稀疏 MoE 架构）处理来自三个并行编码器的统一 Token：视觉（Vision）、通用音频 AuT（以 6.25 Hz 提取声学/语言特征）和空间音频 AuT（用于多通道空间线索）。
- 训练： 模型经过四个阶段的预训练流水线以对齐编码器并适应 QSA（Qwen Sparse Attention）。后训练阶段依赖多教师蒸馏（Multi-Teacher Distillation）来整合特定领域的能力（推理、编码、音频），随后进行统一的强化学习，以优化多轮任务结果和交互稳定性。
- Agentic 执行： 给定一个长视频，智能体调用
Qwen-MM-Plugins生成粗略的摘要（通过Omni-Caption或Omni-Video2Note）。然后，它制定计划并使用Omni-Memory选择性地查询和加载必要的音视频片段以进行详细分析，从静态处理转向主动的证据收集。 - 实时流式传输： “Talker” 模块接收来自 Thinker 的高层表征，并通过多 Token 预测（MTP）模块自回归地预测多码本序列（RVQ）。随后由因果 Code2Wav 解码器将其增量合成为 48kHz 音频，从而在完整文本生成前实现超低延迟响应。 心智模型： 长多模态上下文的 Token 过于密集，无法进行密集处理；因此，全能模型必须扮演“调查员”的角色，抽象完整的视频时间轴，并按需延迟加载特定的证据片段。
4. 指标 / 数据集
- 数据集：
- 文本：SWE-bench Pro, DeepSWE 1.1, LiveCodeBench v6, GPQA 等。
- 视觉：MathVision, LVBench, AndroidWorld, ClawEval-MM, CharXiv (RQ) 等。
- 音频：AliMeeting Test, FLEURS, OmniLingua, WenetSpeech 等。
- 音视频：Video-MME-v2, LVOmniBench, OmniVChat-Bench, DailyOmni 等。
- 智能体：WildClawBench-MM, AgenticVBench, OmniGAIA。
- 指标： Accuracy, Pass@3, WER/CER/DER/cpWER ($\downarrow$), Token 消耗量 ($\downarrow$), 首次音频块延迟 (TTFC), 实时率 (RTF)。
- 模型与规模： Qwen3.8-Omni-Flash（未报告参数量）, Qwen3.5-Omni-Plus, Qwen3.8-Flash, Qwen3.8-27B, Gemini 3.8 Flash, Seed 2.0 Lite, Muse Spark 1.2, Claude-Opus-4.6 (Max), DeepSeek-V4-Flash-0731。
- 硬件配置： 未报告。
- 服务栈/框架： Qwen-MM-Plugins, Qwen-Live-Harness, Claude Code, mini-SWE-agent, OpenClaw。
- Workload： 除标准基准测试任务外未作报告。
5. 对比 baseline
- 核心提升： 摘要声称，与前代 Qwen3.5-Omni-Plus 相比，在 29 项评估中的平均得分提高了 25% 以上，且 API 输入成本降低了 93% 以上。
- Agentic 音视频理解： 从静态处理转向基于智能体（Qwen Code）的执行，使 LVOmniBench 准确率从 63.3 提升至 73.6，超越了此前领先的 Gemini 3.8 Flash (70.7)。
- 对比是否公平？ 总体公平。大多数智能体基准测试由作者使用相同的框架（如 Claude Code, mini-SWE-agent）运行，文中也明确指出了例外情况（例如 SWE-bench Pro 上的 Claude-Opus-4.6 使用了官方公布的分数）。
6. 开源
- 代码： 开源了
Qwen-MM-Plugins（多模态生产力工具）和Qwen-Live-Harness（实时智能体框架），提供了 GitHub 链接。 - 权重 / 数据： 论文中未提及开源。
7. 关键数字核实
| 说法 | 出处 | 实际条件 | 成立? | 备注 |
|---|---|---|---|---|
| 较 Qwen3.5-Omni-Plus 平均分提升 >25% | 摘要 | 跨 29 项评估 | ⚠️ | 单项提升确实极大，但表格中并未直接计算/展示确切的 25% 平均值。 |
| API 输入成本降低 >98% (音频), 93% (视频) | 摘要 / §1 | 对比 Qwen3.5-Omni-Plus | ⚠️ | 正文中有提及，但未提供具体的成本/定价测量表格。 |
| 强大的编码和智能体文本能力 | 表 1 | SWE-bench Pro | ✅ | 得分 63.3，击败了 Qwen3.8-Flash (62.5) 和 Claude-Opus (53.4)。 |
| 长视频理解表现最佳 | 表 2 | LVBench | ✅ | 得分 76.9，击败 Qwen3.8-Flash 和 Claude-Opus-4.6 (Max)。(论文中并未提供 Gemini 3.8 Flash 在该测试中的成绩)。 |
| 多说话人 ASR 巨大提升 | 表 3 | AliMeeting Test (DER) | ✅ | DER 降至 3.4，相较于 Qwen3.5-Omni-Plus (88.1) 是质的飞跃。 |
| 多模态工具调用表现优异 | 表 5 | WildClawBench-MM | ⚠️ | 得分为 71.0，超越 Gemini 3.8 Flash (58.9)，但在同一表格的其他智能体任务（AgenticVBench, OmniGAIA）中均不敌 Gemini。 |
| 智能体执行提升音视频理解 | 表 6 | LVOmniBench (Qwen Code vs Static) | ✅ | 得分从 63.3 跃升至 73.6，在该特定数据集上反超 Gemini，但在 OmniVideoBench 和 Video-MME-v2 上仍落后于 Gemini。 |
| 降低长视频的 Token 消耗 | 表 7 | OmniVideoBench | ✅ | 每次查询的 Token 从 145,736 降至 79,117，同时准确率提高。（作者注明这不代表端到端延迟或成本必定下降）。 |
| 实时交互的超低延迟 | 表 8 | 音频输入的 TTFC | ✅ | 音频 TTFC 约 1 秒，RTF 约 0.15。若是音视频输入，TTFC 增加至 1.21-1.35 秒。 |
8. 摘要没说的
- 性能边界 (Regime boundaries)： 在基于智能体的设置 (Qwen Code) 下，Gemini 3.8 Flash 在部分视频推理任务上依然略胜 Qwen3.8-Omni-Flash，例如 OmniVideoBench (70.1 vs 67.8) 和 Video-MME-v2 (72.7 vs 71.3)。
- 准确度代价 / Trade-offs： 多语言 ASR 和翻译出现了轻微倒退。在 FLEURS-ASR 上，错误率上升到了 9.3（前代为 7.2），FLEURS-S2TT 也略微下降（31.8 vs 32.2）。这表明多说话人和智能体能力的提升在纯转录/翻译的基准准确度上付出了一些代价。
- 硬件与服务混淆因素 (Confounds)： 完全省略。论文没有报告所需的 GPU 型号、互联方式，也没有提及运行多智能体实时框架的额外计算开销。
- 成本： 所谓的 98% 成本削减完全依赖于理论上密集 Token 消耗量的减少，而没有对服务端的实际计算开销或确切 API 定价进行明确的评估。
9. 可达性与启发
- 可达性： 中等。开源的
Qwen-MM-Plugins和Qwen-Live-Harness使得基于智能体的视频检索工作流具备可复现性。然而，模型权重并未明确开源，这意味着研究人员可能需要依赖 API，或者用其他开源模型作为替代。 - 启发 (Your inference)： 从“静态一次性处理”转变为“智能体主动收集证据”，是视频 LLM 的一次巨大解锁。正如 RAG 解决了文本的上下文限制一样，利用工具将视频抽象为文本摘要，并按需提取特定的空间/时间片段，能够有效解决长视频带来的 Token 爆炸问题。此外，自动研究（Autoresearch）工作流（使用全能模型训练较小的 3B 模型）也是一种高度可迁移的自我改进系统模式。
10. 置信度与下一步
- 置信度：
- 机制：高。架构和智能体执行循环解释得非常清晰。
- 报告收益：中等。基准测试的胜利是稳健的，但摘要中关于“成本降低”的百分比缺乏详细的消融实验支持。
- 泛化性：高。在文本、视觉、音频、音视频和智能体能力上进行了极其全面的评估。
- 下一步： 值得尝试使用现有的开源视觉语言模型（如 LLaVA）封装在自定义的智能体框架中，来复现这种“智能体证据收集”模式。推荐阅读：Qwen3.5-Omni Thinker 论文（了解基础架构），或近期关于多模态智能体框架的研究。开放问题：在 100 万 Token LLM 上下文的同时，运行 6.25 Hz 音频编码器的实际硬件服务成本究竟是多少？
11. 审校记录
- 第1节 (任务): 进行了重写，明确指出了长视频处理中的 Token 成本问题以及智能体框架缺乏流式支持的问题，而不仅仅是总结解决方案。
- 第7节 (LVBench): 修正了原笔记中称其击败 Gemini 3.8 Flash 的事实错误（该表格中并没有 Gemini），更正为击败 Claude-Opus-4.6 (Max)。
- 第7节 (WildClawBench-MM): 降级为 ⚠️。虽然在 WildClawBench-MM 上获胜，但在同一表格的其他智能体基准测试（AgenticVBench, OmniGAIA）中均不敌 Gemini 3.8 Flash。
- 第7节 (LVOmniBench): 补充了说明：尽管在智能体设置下 Qwen 在 LVOmniBench 上反超，但在同一设置下的 OmniVideoBench 和 Video-MME-v2 中 Gemini 3.8 Flash 依然领先。
- 第7节 (OmniVideoBench): 补充了论文中的免责声明：Token 消耗的降低并不一定意味着端到端延迟或财务成本的下降。
- 第7节 (实时延迟): 补充说明音视频输入的 TTFC (1.21-1.35秒) 要高于纯音频输入 (约1秒)。
- 无法验证的内容: 文本中声称的 29 项评估平均得分提高 25% 以及 98%/93% 的 API 输入成本降低，在表格中并没有给出明确的推导或细目数据。