Wan-Streamer v0.1：端到端实时交互基础模型 Wan-Streamer v0.1: End-to-end Real-time Interactive Foundation Models
首个支持文本、音频、视频全双工实时交互的端到端基础模型
前置知识
因果注意力
因果注意力是指在序列建模中，每个位置只能关注之前的位置，不能看到未来的信息。在自回归生成中，这是保证生成顺序正确性的关键机制。Block-causal attention是因果注意力的扩展，将序列分成不同的块，块内部可以全连接，但块之间保持因果关系，这使得模型能够在保持因果性的同时提高并行度和计算效率。
本文中的流式交互必须在实时环境下进行，模型不能利用未来信息，因果注意力是实现这一约束的核心技术，理解它对于掌握Wan-Streamer的流式生成机制至关重要。
Flow Matching
Flow Matching是一种生成建模方法，通过学习从噪声分布到目标分布的速度场来生成样本。与传统扩散模型不同，Flow Matching使用ODE（常微分方程）路径而不是随机的扩散过程，训练目标是预测给定噪声水平下的速度场。在时间步，构建噪声潜变量，其中z0是干净目标，epsilon是高斯噪声，然后学习预测速度场。
本文使用Flow Matching来联合生成音频和视频潜变量，这是实现低延迟生成的关键技术。理解Flow Matching有助于理解Wan-Streamer如何在保持音频-视觉同步的同时实现快速推理。
全双工交互
全双工交互是指在通信过程中，双方可以同时发送和接收信息，而不需要等待对方完成。在对话场景中，这意味着当一方说话时，另一方仍在持续听和观察，并可以适时产生响应行为（如点头、微笑等），而不是轮流说话的半双工模式。这种模式更接近人类的自然交流方式。
本文的核心创新就是实现真正的全双工音频-视频交互，理解这个概念才能明白为什么传统级联系统无法满足需求，以及Wan-Streamer的统一因果流设计为什么重要。
研究动机
现有的交互式AI系统通常采用级联架构，将语音活动检测(VAD)、自动语音识别(ASR)、语言模型、语音合成(TTS)、音频驱动动画和视频生成等模块串联在一起。这种架构存在三个核心问题：首先是模块边界处的等待时间累积，每个模块需要等待上游完成后才能开始，导致整体延迟无法降到足够低；其次是误差传播，每个模块的识别或生成错误会在链路上逐级放大，最终影响交互质量；最后是响应时序和话语权管理难以端到端学习，因为这些行为被分割在多个独立优化的模块中，无法在统一的交互上下文中协调。例如，当一个模块在处理语言理解时，另一个模块正在生成语音，但它们之间的同步只能通过后处理实现，这天然限制了系统的响应自然度。
本文的目标是本文的目标是构建一个从零开始为实时、低延迟、全双工音频-视频交互设计的原生流式端到端交互基础模型。这个模型需要在一个统一的Transformer框架内同时处理语言、音频和视频作为输入和输出，能够连续消耗音频-视觉观测，维护持久的世界和对话状态，决定何时以及如何响应，并通过同步的语言、语音和视频以极低延迟表达响应。具体性能目标是实现约200ms的模型端响应延迟，加上网络延迟后总交互延迟控制在亚秒级（约550ms），支持25 FPS的视频输出，流式处理单元可短至160ms。
与已有工作不同的是，本文的独特切入角度是将流式性视为建模约束而非服务优化。现有工作大多试图通过工程手段加速级联系统，或者在模块间加入更复杂的同步逻辑。但Wan-Streamer从第一性原理出发，认为实时音频-视频交互本质上必须是全双工的流式过程，每个组件必须严格因果运行，每个新观测单元必须立即可用，每个生成单元必须立即发出并提交回交互历史。这意味着传统的离线编码器、双向视频解码器、基于轮次的对话或后置音频-视觉同步等设计都无法通过单纯的工程优化恢复真正低延迟的全双工行为。因此，本文重新设计了整个技术栈，包括严格因果的音频和视频VAEs、因果编码器和解码器、块因果注意力以及低延迟多模态token调度，将感知、推理、生成、响应时序、话语权管理和跨模态同步在一个统一的模型中联合优化。
核心方法
Wan-Streamer将交互建模为连续的因果流，其中用户观测和代理响应共同更新 ongoing 上下文。在第k个流式单元，用户观测包含文本、音频和视频，代理响应同样包含三个模态。模型编码当前可用的用户观测，并从双方交互的完整因果历史预测下一个响应。语言响应表示为离散token序列，使用交叉熵损失优化；音频和视频响应在连续潜变量空间中联合生成，使用条件Flow Matching。整个架构围绕一个Transformer展开，输入和输出token按视觉、音频、文本的顺序交错排列，通过块因果注意力协调增量流式生成。
核心创新点是实现了真正的端到端全双工多模态交互，且不依赖任何外部的语言、语音、头像或视频生成模块。与现有方法的本质区别在于：首先，Wan-Streamer将文本、音频、视频同时作为输入和输出，在一个统一的因果序列中建模，而不是将某些模态作为隐藏的中间表示；其次，音频-视觉感知、语义推理、响应规划、语音生成、视觉生成、响应时序和话语权行为都在一个持久交互状态中联合优化，而不是分割在独立优化的模块中；最后，整个技术栈从设计之初就是为因果流式处理服务的，包括严格因果的VAEs、因果编解码器和块因果Transformer，而不是在现有离线模型基础上做工程加速。这种设计使得感知和表达在音频-视觉时间尺度上重叠，能够学习自然的响应时序、主动倾听行为、中断处理和长上下文一致性。
方法步骤详情
训练分为三个阶段。第一阶段是独立任务预训练：从语言模型初始化Transformer，然后用理解任务（图像、音频、视频理解、文本对话、ASR、TTS、音频对话）和生成任务（图像生成、音频生成、视频生成、联合音频-视频生成）的混合数据训练多模态接口。这一阶段确保因果音频-视频编码器与Transformer一起训练，使理解指标接近专用多模态模型，对话能力与相似规模的基于轮次的对话模型相当。第二阶段是端到端交互训练：在全双工交互数据上训练，用户和代理的文本/音频/视频输入输出在同一个因果流中交错。这一阶段将预训练模型从独立任务调整到目标实时设置，模型必须从当前用户观测更新状态、生成同步的语言-音频-视频响应，并将生成的干净潜变量提交回历史作为后续流式单元的上下文。第三阶段是低延迟流式蒸馏：使用classifier-free guidance (CFG) 和更多Flow Matching求解步骤的强教师模型蒸馏到高效的学生模型。蒸馏吸收CFG效果并减少求解步骤，同时保持音频-视觉质量。还使用rolling distillation缓解长视界退化：学生模型在连续流式单元上rollout，并在自己生成的历史上训练，使用self-forcing策略和distribution matching对齐学生轨迹与教师轨迹。
技术新颖性
技术新颖性体现在多个层面。在架构层面，提出了块因果多模态注意力机制，使得不同token速率、表示、目标和延迟约束的模态能够在单一持续过程中因果对齐。在训练层面，设计了三阶段训练流程，特别是端到端交互训练和rolling distillation，前者让模型学习响应时序、主动倾听、中断处理等行为，后者缓解训练-测试不匹配并改善长形式生成质量。在推理层面，提出了thinker-performer流水线，通过KV-cache交换保持统一模型状态，同时重叠理解与生成。在每个流式单元k，thinker消耗当前用户音频-视觉观测，应用因果编码器，运行token因果解码产生当前KV-cache切片；同时接收performer在上一步生成的音频-视频潜变量，发送新产生的KV切片给performer，并解码返回的潜变量为音频-视觉输出立即发出。performer将接收的KV切片追加到自己的全历史缓存，只运行Flow Matching求解器生成下一个音频-视觉潜变量单元。这种调度将当前帧感知和状态更新、上一帧音频-视觉解码、KV/潜变量通信、下一帧潜变量去噪在相邻流式单元间流水线化。
实验结果
延迟和运行时比较实验是本文的核心评估。对于实时交互，最相关的延迟是用户最新信号到第一个可感知助手响应的延迟。Wan-Streamer在两GPU thinker-performer服务路径下，当160ms用户流式单元对thinker可用时，到对应音频-视频响应单元解码为25 FPS可发出为止，达到约200ms模型端延迟；加上350ms双向网络预算，远程用户总交互延迟约550ms。与公开系统比较时需要注意测量边界的差异：Doubao Realtime Voice报告约1秒整体延迟和约700ms纯模型延迟，但没有视觉代理输出；GPT-4o Realtime API报告232/320ms官方音频响应，但数字混合了模型响应、API TTFB、endpointing和网络延迟；Moshi是原生全双工语音模型，报告160ms理论延迟和200ms实际模型延迟，但没有视觉代理；Qwen3/3.5-Omni接受音频-视频-文本输入，但只输出语音/文本，报告first-packet延迟234/547ms，没有同步视觉头像生成。Wan-Streamer的550ms总延迟覆盖了完整的远程音频-视觉响应路径，并且是在一个端到端模型内实现的文本I/O、语音和同步视觉响应共享一个因果流。在自然性方面，Wan-Streamer通过在非说话区间持续生成可见行为改善交互自然性：在空闲状态保持身份、注视、姿态、呼吸和微妙的面部运动；在倾听状态产生响应的非语言反馈如注视转移、点头、微表情和姿态变化，这些反馈与用户语音和视觉提示时间耦合。由于语音和视频潜变量在解码前从同一因果上下文预测，唇部运动、面部动态和韵律原生同步而非后置对齐修复。在中断和主动说话方面，全双工行为是从交错交互数据学习的而非仅作为手工规则实现。训练时用户输入和代理输出从文本、音频、视频放在同一因果时间线上，模型观察到人类何时继续、暂停、重叠、中断、让步或恢复。推理时模型即使在生成自己的响应时仍消耗用户音频-视觉观测，允许在用户自然中断时停止、缩短或重定向其语音。同一统一上下文还启用主动说话：当显著视觉事件、物体、表情或用户动作出现在输入流中时，模型可以基于看到的内容发起相关评论或问题，而不是等待明确的口语请求。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 实时语音和全模态交互 | 用户可见响应延迟 | 约550ms总交互延迟（包含350ms网络） | Doubao Realtime Voice约1秒整体延迟 | 约450ms降低，且同步生成视觉响应 |
| 端到端模型内部延迟 | 模型端流式延迟 | 约200ms | GPT-4o Realtime约232/320ms音频响应 | 相当，但覆盖完整音频-视觉路径而非仅音频 |
| 视频输出帧率 | FPS | 25 FPS | VASA-1 40 FPS（仅音频驱动） | 包含完整对话感知和响应生成，非仅渲染 |
| 流式处理单元 | 单元时长 | 160ms | Moshi 200ms实际模型延迟 | 更短流式单元，支持更细粒度交互 |
局限与改进
作者明确指出的局限性是当前v0.1结果在初步的192p输出分辨率下验证，这作为端到端流式设计的概念验证，扩展到更高分辨率是直接的并留给未来工作。从独立观察来看，系统依赖于两GPU部署（thinker和performer各占一个GPU），这增加了硬件成本和部署复杂度。虽然thinker-performer流水线提高了硬件利用率，但对于资源受限的场景可能不够友好。此外，论文报告的延迟主要在理想网络条件下测量，实际部署中的网络抖动、丢包等可能影响总交互延迟。训练数据方面，虽然提到使用了理解、生成和端到端交互数据的广泛混合，但具体数据集规模、构成和质量细节披露有限，这可能影响复现和进一步研究。最后，虽然模型学习了中断和主动说话行为，但没有量化评估这些能力，更多依赖定性描述，可能需要更系统的评估框架。
独立分析的弱点
第一个弱点是当前192p输出分辨率限制了视觉细节和真实感，对于需要精细面部表情或肢体语言的应用场景可能不足。改进方向是扩展模型到更高分辨率（如720p或1080p），这需要增加音频-视频VAEs的容量和计算资源，但架构设计支持直接扩展。第二个弱点是双GPU部署要求，对于边缘设备或移动端部署不友好。改进方向是探索模型压缩、量化和蒸馏技术，将thinker和performer合并到单GPU甚至CPU上运行，可能牺牲部分延迟或质量以换取可部署性。第三个弱点是缺乏系统的行为评估，尤其是中断处理、主动说话、长上下文一致性等交互能力。改进方向是设计专门的评估协议和指标，如中断成功率、主动说话相关性、长对话一致性分数等，并构建标准测试集。第四个弱点是论文主要关注延迟和自然性，但对准确性和语义能力的评估有限。改进方向是在标准多模态理解基准（如VQA、视觉推理）和对话评估基准（如DSTC）上评估模型，确保不牺牲核心能力。第五个弱点是训练数据细节披露不足，影响透明度和可复现性。改进方向是更详细地披露数据集来源、规模、标注流程和数据去重策略，并可能开源部分训练数据或数据生成脚本。
未来方向
作者提出的未来工作方向是扩展到更高输出分辨率，这是直接的下一步。基于论文成果可延伸的方向包括：多语言和多说话人支持，当前模型主要针对中英文交互，可以扩展到更多语言并学习不同的说话人风格；多用户交互场景，当前模型专注于单用户-代理交互，可以扩展到多用户会议或群组对话，学习轮流发言、并行说话等更复杂的交互模式；具身交互集成，将视觉代理与机器人控制结合，在说话时同步执行手势或动作，实现更自然的具身对话；个性化学习，通过持续学习用户偏好、说话风格和交互模式，为每个用户提供定制化的体验；情感和个性建模，在统一框架内显式建模情感状态和个性特质，使代理响应更符合场景和用户期望；跨模态对齐研究，深入研究如何在统一因果流中更好地对齐不同模态的语义和时序，特别是处理模态间冲突或不一致的情况；安全性和可控性，在端到端框架内加入安全约束和可控生成机制，防止有害输出并允许用户调整代理行为。
复现评估
论文提供了网站https://wan-streamer.com/，但未在正文中披露代码、数据或模型权重开源计划。从技术细节披露程度看，论文描述了架构设计、训练流程和推理系统的主要组件，包括块因果注意力、Flow Matching训练、三阶段训练和thinker-performer流水线，但没有提供足够的实现细节（如具体的网络层数、隐藏维度、注意力头数、VAE架构细节等）。论文报告了详细的延迟测量方法和比较数据，但没有披露评估脚本或测试数据。算力要求方面，两GPU部署意味着至少需要两个高性能GPU（可能是A100或类似），这对大多数研究者来说门槛较高。总体而言，当前复现难度较高，需要更多实现细节和资源才能复现结果。如果作者后续开源代码、模型和训练脚本，将大大降低复现门槛并促进社区研究。
论文图表