Wan-Streamer v0.2：更高分辨率，相同延迟 Wan-Streamer v0.2: Higher Resolution, Same Latency
在保持约200ms延迟的同时将实时音视频交互模型输出分辨率从192×336提升至640×368
前置知识
流式因果建模
一种将用户和代理的文本、音频、视频表示在同一因果时间线上的建模方法。所有模态共享一个因果交互状态，感知、响应时序、语音、可见的倾听行为和同步视频响应都在这个单一状态内协调。这种方法与级联系统不同，它将整个交互闭环保持在单个Transformer模型中，使得下一轮响应可以同时依赖于用户最近的行为和代理自身的先前表达。
本文完全继承并保持v0.1的流式因果公式不变，这是理解v0.2升级设计的基础。所有延迟测量和架构优化都是在这个统一的因果时间线框架下进行的。
Ulysses上下文并行
一种序列并行的分布式推理策略，通过将长序列沿序列维度切分到多个GPU上处理。每个GPU负责处理序列的一部分，通过all-to-all和gather通信机制在注意力计算时交换信息。对于自回归生成，Ulysses允许不同GPU并行生成序列的不同片段，通过同步激活值来保持一致性。这种并行方式特别适合处理高分辨率视频这样的长序列，因为序列长度远大于序列维度，序列并行可以更好地平衡计算和通信开销。
这是v0.2的核心技术创新。长高分辨率潜在视频序列需要大量计算，单GPU无法在160ms内完成。Ulysses并行让多个GPU协同去噪，而thinker保持单GPU低延迟路径，这是实现'更高分辨率、相同延迟'目标的关键。
K/V缓存预分片
在分布式推理中，注意力机制的Key和Value张量预先按照GPU的序列分片方案进行切分和存储。当thinker广播新的K/V切片时，每个performer rank直接将其写入本地对应的预分片缓存位置，而不是维护完整的历史缓存后再分发。这种方式避免了在performer组内部传输完整的K/V张量，通信量仅限于thinker到performer的单次广播，后续的注意力计算直接使用本地缓存。
这是v0.2服务拓扑的重要优化。预分片缓存确保thinker-performer通信保持紧凑，将序列并行通信限制在performer组内部，避免了将语言状态序列在performer组内传输的开销。这是保持低延迟的关键设计。
Thinker-Performer架构
将推理模型分离为两个角色的服务拓扑。Thinker是单GPU路径，负责流式感知、语言和状态更新、K/V缓存构建和最终因果解码，这是延迟关键的控制路径。Performer是多GPU组，负责昂贵的流匹配潜在生成路径，通过Ulysses上下文并行处理高分辨率视频。Thinker生成紧凑的performer兼容K/V切片广播给所有performer rank，每个rank更新本地分片缓存并协同去噪下一单元。
这是v0.2与v0.1的核心架构差异。这种分离将额外的高分辨率生成成本集中在performer组，而thinker保持紧凑低延迟的交互路径，使得吞吐量可以从多GPU获得，而响应延迟仍由单GPUthinker决定。
研究动机
Wan-Streamer v0.1建立了原生流式音视频交互模型，但其192×336的初步输出分辨率严重限制了视觉范围。虽然特写视频通话构图可以保留面部响应和说话行为，但更宽的构图使得身体姿态、附近物体和场景背景过于压缩，无法支持场景感知的交互。在实际对话中，代理需要展示姿态、视线、手部、躯干姿态、局部物体和场景布局等多层次的视觉信息，192p分辨率无法满足这些需求。每个160毫秒的流式单元必须处理当前用户观察、更新共享交互状态、生成同步的语音和视频潜在表示、解码前一个单元并发出响应，这个严格的延迟约束使得直接提升分辨率变得极其困难。
本文的目标是本文的目标是将Wan-Streamer的交互输出流从192×336提升到640×368（25FPS），同时保持约200毫秒的模型端信号到信号延迟不变。在350毫秒双向网络预算下，总远程交互延迟仍应保持约550毫秒。除了提高特写视频通话的保真度外，还需要支持场景感知的中景代理，使姿态、视线、手部、附近物体和局部场景布局在实时对话中保持可读性。这要求在不拉伸交互节奏的情况下，完成更大分辨率视频的编码、潜在生成和解码。
与已有工作不同的是，本文的独特切入点是通过改变服务拓扑而非重新设计模型公式来解决这个问题。与v0.1使用单GPUthinker和单GPUperformer不同，v0.2保持thinker为单GPU低延迟路径，将performer扩展为Ulysses风格的上下文并行多GPU组。关键创新是使用预分片的performer侧K/V缓存和针对高分辨率潜在视频去噪的序列并行，而音频潜在序列由于token数较少则不进行序列分片。这种设计将额外的视觉生成硬件集中在performer组，同时保持紧凑的thinker-performer边界，使得延迟由单GPUthinker决定，而吞吐量可以从多GPUperformer获得。
核心方法
v0.2的核心思路是保持v0.1的端到端流式公式完全不变，通过重新设计服务拓扑来分配额外的640×368生成成本。模型仍作为一个端到端因果流进行训练：用户文本、音频和视频观察更新同一历史，该历史调节代理文本、语音和视频响应。生成的音频视频潜在表示在每个单元后提交回历史，因此下一响应可以同时依赖于用户最近的行为和代理自身的先前表达。v0.2的升级仅在于服务部署阶段：thinker保留在单个GPU上，负责感知、语言和状态更新、K/V缓存构建和解码；performer扩展为Ulysses风格上下文并行GPU组，负责昂贵的流匹配潜在生成。这种分离使得延迟关键的控制路径保持紧凑，而高吞吐的生成路径可以并行化。
核心创新点在于预分片K/V缓存和选择性序列并行的结合。Thinker生成performer兼容的K/V切片并广播给所有performer rank，每个rank将其写入预分片的本地缓存而不是维护完整历史。长高分辨率潜在视频序列跨rank分片去噪，通过Ulysses all-to-all和gather通信协调；而短音频潜在序列由于分片会增加通信开销而非有用并行性，因此不分片生成。关键洞察是语言/状态计算仅以K/V调节形式到达performer，因此不需要在performer组内传输单独的语言序列。这种设计将序列并行通信限制在performer组内部，thinker-performer边界保持紧凑，使得额外的高分辨率生成成本被隔离在performer中而不影响延迟。
方法步骤详情
在流式单元k，thinker消费当前用户观察（文本、音频、视频），通过因果音频/视频编码器编码，运行语言/状态Transformer路径更新共享交互状态，构建新的performer兼容K/V切片。同时，thinker接收前一个单元生成的潜在表示，通过因果解码器解码为输出音频和视频，并发出响应。Thinker将K/V切片广播给所有performer rank。每个performer rank接收K/V切片，更新其本地分片的完整历史缓存，并为下一单元运行Ulysses上下文并行去噪。高分辨率潜在视频是主要的序列并行路径，序列在rank间分片，注意力计算时通过Ulysses通信同步激活值。音频潜在序列不分片，在每个rank上独立生成。这个流水线要求performer组时间加上thinker-performer K/V和潜在传输加上performer内部Ulysses通信必须适应一个160毫秒单元。
技术新颖性
v0.2的技术新颖性在于将多GPU并行策略精心设计以适应流式交互的延迟约束。与一般的模型并行不同，这里不是均匀分片整个模型，而是按照延迟关键性分离角色：延迟关键路径（感知、状态更新、解码）保留单GPU以保证紧凑性，而高吞吐路径（潜在生成）使用多GPUUlysses并行。预分片K/V缓存的创新避免了performer组内的语言序列通信，选择性序列并行（视频分片、音频不分片）优化了通信与计算的平衡。这种拓扑设计使得吞吐量可以从多GPU获得而响应延迟仍由单GPU决定，突破了传统模型并行难以同时优化延迟和吞吐量的限制。
实验结果
v0.2成功实现了设计目标：在25FPS下产生640×368视频，同时保持约200毫秒模型端信号到信号延迟。在与v0.1相同的350毫秒双向网络预算下，总远程交互延迟保持约550毫秒。这意味着分辨率从192p提升到640×368（约3.7倍像素增加）没有引入用户可见的延迟。定性观察显示v0.2输出格式支持更清晰的特写视频通话和场景感知的中景代理，在倾听和说话间隔内保持视觉稳定性和可读性，包括面部细节、视线、嘴部动作、手部、姿态、附近物体和局部场景布局。实验采用了与v0.1相同的响应边界：模型端信号到信号延迟从160毫秒用户流式单元对thinker可用时开始，到对应音频视频响应单元已解码可供发出时结束。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 输出分辨率 | 视频分辨率 | 640×368 | 192×336 | 约3.7倍像素增加 |
| 模型端延迟 | 信号到信号延迟 | 约200毫秒 | 约200毫秒 | 保持不变 |
| 总交互延迟 | 远程端到端延迟（含350ms网络） | 约550毫秒 | 约550毫秒 | 保持不变 |
| 帧率 | 输出帧率 | 25 FPS | 25 FPS | 保持不变 |
局限与改进
作者承认网络延迟项（350毫秒双向网络预算）是外部部署假设，带宽受限传输效应不在本文报告的模型端延迟测量范围内。这意味着在带宽受限的实际部署环境中，总交互延迟可能会更长。v0.2主要集中在技术架构和服务拓扑的创新，缺乏与其他实时音视频交互系统的定量比较。公共实时系统报告不同的端点，包括首个数据包语音延迟、首帧延迟、FPS、音频到视觉延迟或产品级响应时间，这使得直接比较变得困难。此外，论文未提供生成视频的客观质量指标（如FID、FVD等），主要依赖定性观察来评估视觉稳定性和可读性。
独立分析的弱点
v0.2的一个独立分析弱点是缺乏与其他实时数字人系统的全面基准测试。虽然保持了与v0.1相同的延迟测量约定，但未与当前最先进的实时数字人系统进行定量比较，这使得难以评估v0.2在更广泛生态系统中的相对性能。另一个弱点是定性观察的主观性：论文依赖视觉检查来评估面部细节、视线、嘴部动作、手部、姿态、物体和场景布局的可读性，缺乏标准化的客观评估指标。此外，论文未提供不同网络条件下的性能分析，实际部署中的网络抖动、丢包和带宽变化可能对总交互延迟产生显著影响。最后，多GPU部署的硬件成本和复杂性是实际部署的考虑因素，论文未讨论成本效益分析。
未来方向
作者未明确列出未来工作方向，但基于v0.2的成果可以延伸多个研究方向。一个自然方向是进一步提高输出分辨率（如1080p）同时保持或降低延迟，这可能需要更激进的并行策略或更高效的潜在生成方法。另一个方向是扩展视觉交互范围，支持从中景到全景的多尺度构图，使代理能够在更大场景中展示更丰富的空间关系。在架构方面，可以探索动态并行策略，根据当前场景复杂性和计算负载动态调整performer的GPU数量，以在延迟和成本之间取得平衡。跨模态注意力优化也是潜在方向，例如设计更高效的音频-视频交叉注意力机制，减少模态间融合的计算开销。此外，可以研究自适应码率策略，根据网络条件和设备能力动态调整输出质量和帧率。
复现评估
作为阿里巴巴团队的工作，论文提供了项目网站https://wan-streamer.com/，但未在论文中明确说明代码和模型的开源状态。复现v0.2需要理解并实现其特定的服务拓扑：单GPUthinker与多GPUUlysses并行performer的协同，包括预分片K/V缓存管理、选择性序列并行策略和精确的流水线调度。硬件需求是多GPU集群（至少一个GPU用于thinker，多个GPU用于performer），具体GPU数量取决于延迟约束和并行效率。实现Ulysses上下文并行需要自定义分布式推理框架，这可能依赖于特定的深度学习库和通信后端。由于论文缺乏详细的超参数设置和训练数据描述，完整复现模型训练可能较为困难，但服务部署的架构创新可以在现有开源推理框架基础上参考实现。
论文图表