AREX Feed Article
550ms 全双工音视频对话：阿里用一个 Transformer 拆掉了实时 AI 的模块墙
第一章：一个 Transformer，200ms 延迟，亚秒级全双工音视频交互
6 月 23 日，阿里巴巴万相（Wan）团队在 arXiv 上投出一篇论文，同步上线了项目页面 wan-streamer.com，发布了一个名为 Wan-Streamer v0.1 的端到端实时交互基础模型。
论文和演示页展示了一组惊人的数字：模型侧响应延迟约 200 毫秒，计入 350 毫秒双向网络延迟后，总交互延迟约 550 毫秒。
这意味着亚秒级的全双工音视频通信。更关键的是，一切发生在一个 Transformer 内部：语言、音频、视频的理解和生成，全部由同一模型完成，没有外挂任何 VAD、ASR、TTS 或动画模块。
截至发稿，AI 论文推手 AK（@_akhaliq）转发的推文已获得 634 次点赞、76 次转发和 559 次书签收藏，浏览量接近 9 万次。
中文和日文社区也出现了热烈讨论。有用户评论"现在视频实时交互已经这么流畅了吗？"日本 VTuber 数据科学家 AIcia Solid 指出："E2E と書いてあるとおり、1 つの Transformer モデルで MM な I/O 全部やってるみたい。すご！"
第二章：五组数字读懂 Wan-Streamer 的真正突破
跳过宣传语言，Wan-Streamer 的核心突破可以用五组数字概括：
-
200ms 模型侧延迟，550ms 总交互延迟。相比之下，GPT-4o Realtime 模型侧约 230ms（仅语音），Doubao Voice 约 700ms（仅语音），Gemini Live 在 1.2-3.6 秒之间。Wan-Streamer 不仅更快，而且输出的是同步音视频，而非纯语音。
-
一个 Transformer 处理全部模态。系统没有外部 VAD、ASR、语言模型、TTS、动画或视频生成模块。感知、推理、响应规划、语音与视觉生成、响应时机和轮次管理在同一个持久状态中联合优化。
-
25fps 下流式单元最短 160ms。这意味着每 160 毫秒就可以输出一个新的音视频片段，使得对话可以像真人一样随时被打断和调整。
-
业内唯一同时满足五项能力的系统：感知视频 ✓、输出同步视频 ✓、全双工 ✓、端到端 ✓、亚秒级响应 ✓。GPT-4o Realtime、Doubao Voice、Gemini Live 均无法同时覆盖这五项。
-
v0.1 仅 192p 分辨率。团队明确表示这是验证端到端设计的概念验证，更高分辨率"可以较容易地扩展到"——这既是诚实，也是留白。
第三章：为什么"全双工实时交互"必须是一个模型？
被忽视的前提：人与世界的交互是全双工的
人在对话时不是先听完、再思考、再回答的线性机器。我们持续地观看、倾听、说话、用手势回应、停顿和打断，感知与表达在音视频时间尺度上重叠发生。
Wan-Streamer 技术报告的开篇就点出了这个被行业长期忽视的事实。
大多数现有实时交互系统是以级联或非对称流水线拼装而成的。有的能感知音视频，却只用文本或语音回应（如 GPT-4o Realtime）；有的能生成音视频行为，却依赖外部语言模型、ASR、TTS、动画或渲染模块（如 LPM、StreamAvatar），并常常把文本作为独立训练组件之间隐藏的中间表示。
这类流水线的代价是系统性的。每个模块边界都带来等待时间，累积识别与同步误差，让响应时机、轮次管理、身份保持与长程一致性难以被统一学习成连贯行为。
更致命的是，建立在离线编码器、双向解码器或回合制对话之上的系统，仅靠工程优化无法获得真正低延迟的全双工能力——因为"可流式性"是一个建模约束，而不是一个部署优化。
这正是 Wan-Streamer 选择从头设计一个端到端模型的根本原因。
全栈因果性：从 VAE 到 Transformer 的流式改造
为了实现"所有组件都因果运行，新观测到的每个单元都能立即使用，生成出的每个单元都会输出并写回交互历史"这一流式契约，Wan-Streamer 对整个技术栈进行了因果化改造。
首先是严格因果的音频和视频 VAE，用于流式 latent 编码。不同于传统 VAE 使用双向编码，因果 VAE 只能看到当前和过去的帧，确保 latent 表示本身不包含未来信息。
然后是因果音视频编码器和解码器，保证编码和解码过程都遵循时间顺序。核心的 Transformer 由 block-causal attention 协调——这是一种介于完全因果注意力和双向注意力之间的注意力机制，在同一时间块内允许跨模态交互，但块之间严格因果。
在推理时，模型将语言、音频和视频——输入侧和输出侧——视为一条交错的因果序列。语言回应由离散 token 表示，用 next-token 预测训练；音频和视频回应位于连续 latent 空间，通过条件 flow matching 联合生成。
关键在于，语音、动作、外观与场景演化是作为一个耦合整体一起去噪的，而不是先生成语音再驱动口型、再渲染画面的分离流程。
Thinker-Performer：两块 GPU 上的流式管线
训练时 Wan-Streamer 是一个端到端模型，但推理部署时，同一个模型被拆分为 thinker-performer 管线，运行在两块 GPU 上以最大化计算重叠。
具体来说，thinker 负责消费当前用户音视频观测、运行因果编码器和短程 token-causal Transformer 来预测语言响应并更新状态，同时解码上一个响应单元的音视频 latent 进行即时输出。
performer 则使用 thinker 传过来的完整历史 KV-cache，仅运行 flow-matching solver 来为下一个音视频单元去噪。下一流式步时，performer 将生成的 latent 回传给 thinker——这个 KV-cache 交换机制保证了统一因果状态在双 GPU 间的一致性。
配合 CUDA graph capture、编译优化和定制 kernel，这套架构将模型侧响应延迟压到了约 200ms。
没有对手的比较：唯一的端到端全双工音视频模型
Wan-Streamer 的技术报告附了一张对比表，将自身与 GPT-4o Realtime、Doubao Voice、Gemini Live、StreamAvatar 和 LPM 1.0 进行了五项能力的逐一对照。结果是：只有 Wan-Streamer 同时满足"感知视频""输出同步视频""全双工""端到端"和"一秒内响应"这五大条件。
GPT-4o Realtime 可以感知视频但不输出视频；Doubao Voice 同此；Gemini Live 延迟远超一秒；StreamAvatar 和 LPM 1.0 可以输出视频但依赖外部语言模型和 TTS，并非端到端，且其公布的延迟仅覆盖渲染阶段，真实用户感受到的延迟更高。
全双工（full-duplex）的定义也值得强调：系统在生成时仍在持续感知，即边理解边回应。这是真人对话的基本特征，但在 AI 系统中实现极为困难，因为模型必须同时维护两条信息流。Wan-Streamer 是目前公开文献中唯一做到这一点的端到端模型。
第四章：GPT-4o 语音先到，但全双工音视频赛道刚刚开跑
Wan-Streamer 不是第一个试图做实时交互的 AI 系统，但它切入的角度与所有先行者不同。
OpenAI 的 GPT-4o Realtime 于 2024 年发布，率先展示了亚秒级语音对话，被广泛视为实时 AI 交互的里程碑。但它只输出语音，不生成视频形象。字节跳动的 Doubao Voice 同样只做语音。Google 的 Gemini Live 支持视频输入但不输出视频。这些系统虽然接口上看起来"多模态"，但本质上仍然是语音助手，而非真正的数字人。
在"有形象的"一端，旷视的 LPM 1.0、微软的 VASA-1、阿里的 Live Avatar 和 Omni-Avatar 等项目都能生成音频驱动的虚拟形象视频。但它们都是渲染层方案——依赖外部 ASR 转写、外部 LLM 生成文本、外部 TTS 合成语音，再将语音输入驱动口型和表情动画。每一个外部模块都是一个延迟来源和一个误差放大器。
Wan-Streamer 的策略是：不修修补补，直接掀桌。它不试图在现有的级联管线中插入更多优化，而是从头设计了一个能同时处理所有模态的大一统模型。
这种"all-in-one Transformer"路线，与 OpenAI 在 GPT-4o 中尝试的原生多模态思路有相似之处，但 Wan-Streamer 把它推到了实时全双工音视频生成的终点。
有意思的是，Wan-Streamer 的论文和项目页面均未明确提及是否开源。HuggingFace 论文页面的评论区中，社区成员已在追问代码和权重发布计划。考虑到阿里万相团队此前 Wan2.1 系列（Apache 2.0）和 Live Avatar（ECCV 2026，代码已开源）的开源传统，Wan-Streamer 后续开源并非没有可能。
第五章：v0.1 只是 192p：Wan-Streamer 的三种可能走向
Wan-Streamer 目前明确标注为 v0.1，分辨率仅为 192p，团队称其为"验证端到端设计的概念验证"。由此出发，至少有三种可能的演进方向。
第一种是工程扩展。将分辨率从 192p 提升到 720p 甚至 1080p，将帧率从 25fps 推向更高，将 GPU 占用从两张 H800 扩展到更多卡或更低配硬件。
这条路相对明确——团队在论文中表示"higher resolution scales readily"——但具体需要多少算力、是否能在消费级 GPU 上运行，目前仍是未知数。
第二种是生态开放。如果 Wan-Streamer 像 Wan2.1 一样开源，将催生大量二次开发——自定义角色、接入游戏引擎、嵌入直播和客服系统。但也存在不开放的可能性，尤其是在全球 AI 出口管制趋紧的背景下。
第三种是场景落地。Wan-Streamer 的技术报告列出了多个应用方向：具身助手、实时数字人、直播、互动娱乐、可在线探索的世界模型。其中直播电商和虚拟客服是阿里生态内最直接的应用场景。
考虑到阿里云已在 Bailian 平台上深度整合通义系列模型，Wan-Streamer 的 API 化可能比开源来得更快。
无论具体走哪条路，Wan-Streamer v0.1 已经完成了一件事：它用一份技术报告和一组 demo，证明了"一个 Transformer 搞定全双工实时音视频交互"不是幻想。剩下的问题是速度、分辨率和可获得性——而这些问题，v0.2 或 v1.0 迟早会回答。
参考链接
- 论文：Wan-Streamer v0.1: End-to-end Real-time Interactive Foundation Models, arXiv:2606.25041
- 项目页面：
- HuggingFace 论文页：
- AK（@_akhaliq）推文：
- Hugging Papers 推文：
本文由机器之心撰写，转载请联系本公众号获得授权。_