一句话定位
Wan-Streamer v0.2 是阿里 Wan 团队做的实时全双工音视频交互基础模型的一次”只提分辨率、不涨延迟”的小版本升级：把交互输出流从 v0.1 的 192×336 提到 640×368（25 FPS 不变），模型侧信号到信号延迟仍约 200 ms、含 350 ms 网络往返的端到端约 550 ms 不变；靠把昂贵的 latent 生成路径从单卡挪进 Ulysses 式上下文并行的多卡 performer 组，让更大的画面塞进同一个 160 ms 流式单元里，从而支持”看得清身体、手、周围物体和场景布局”的中景实时数字人，而不只是近景视频通话头像。
背景与定位
这条线要放到两个脉络里看。一是实时数字人/说话头像：过去的做法多是级联管线（VAD → ASR → LLM → TTS → 音频驱动动画 → 视频生成），每一段都有延迟和误差累积。二是流式视频生成：Wan 系列的文生视频底座（Wan 2.1/2.2）加上 Diffusion Forcing、Self-Forcing 这类因果 rollout 方法，为”边生成边输出”打了基础。Wan-Streamer 的思路是把这两条合并成一个原生流式的端到端模型。
前作 Wan-Streamer v0.1（arXiv:2606.25041，2026-06-23）确立了核心范式：用户和智能体的文本、音频、视频都摆在同一条因果时间线上，由单个 Transformer 用 block-causal attention 统一建模——感知、推理、生成、应答时机、话轮管理、跨模态同步全在一个模型里学，不依赖外部的语音、头像或视频生成模块。它把流式单元压到 160 ms、25 FPS，拿到约 200 ms 模型侧延迟、约 550 ms 端到端延迟，实现了亚秒级双工音视频通话。但 v0.1 的输出只有 192p，画面范围受限：近景通话能保住表情和口型，一旦想拉远到能看清身体姿态、周围物体和场景，画面就糊得没法用。
v0.2 就是专门补这个短板的一次”保延迟涨分辨率”升级（arXiv:2607.04443，2026-07-05 提交；项目页 wan-streamer.com 同日上线）。作者把它明确定位为”latency-preserving upgrade”：建模范式一个字不改，只在三条轴上动——输出分辨率提到 640×368、高成本 latent 生成路径迁到 Ulysses 上下文并行、可用视觉构图从近景通话扩到”有场景感的中景智能体”。这份报告很短（正文五节，无实验数值表），本质是一份工程升级说明，重点全在推理拓扑怎么改才能在同一个延迟预算下扛住更大的画面。注意 Wan-Streamer 至今只放了论文和项目页，没有开源权重、没有推理代码、没有 ModelScope model card（HF 上 ali-vilab 的 “Wan-Streamer” collection 里只有两篇 paper）。
模型架构
v0.2 沿用 v0.1 的原生流式建模，模型结构本身没披露改动。要点：
- 单 Transformer、共享因果时间线：用户与智能体的文本、音频、视频输入输出被表示成交错的 token 序列，摆在同一条因果时间线上，用 block-causal attention 协同增量流式解码。
- 围绕可流式性重新设计的整套栈（来自 v0.1）：因果编码器（causal encoders）、因果解码器（causal decoders）、block-causal attention、低延迟多模态 token 调度，使流式单元短到 160 ms、25 FPS。
- 生成侧是 flow-matching 的 latent 生成路径（v0.2 报告 Sec.3 明确写 “expensive flow-matching latent generation path”）。生成的音视频 latent 在每个单元结束后被写回历史，所以下一次应答既能依赖用户刚才的行为、也能依赖智能体自己上一刻的表现，这对”一边听一边自然地做出倾听/说话表情”很关键。
- v0.2 的变化只在输出规格与数据侧重：视觉目标从 192p 抬到 640×368，数据侧重从”以近景通话取景为主”转向”更宽、有场景感的对话设定”。中景构图下，模型要在持续听说的同时保住身份、视线、手与躯干姿态、局部物体和场景布局。
一个值得点出的产品性细节（来自项目页）：每个场景都从一句自然语言 prompt 起手（如”烛光书房里的白发导师""会议室里的喷火龙”），约 0.5 秒内 prompt 生效、thinker 与 performer 都完成 prefill、新场景进入用户可见的实时会话。也就是说智能体的形象和场景是由文本 prompt 现场生成的，不是绑定某张驱动图。
模型规模、层数、注意力头等结构超参:未披露。报告和项目页都没给参数量。
数据
这是这份报告最薄的一维。没有披露训练数据的来源、规模、配比或处理流程的任何数字。唯一能说的是方向性描述：v0.2 把数据侧重从”以近景通话取景为主”移到”更宽、有场景感的对话设定”，以支撑中景构图下对身体姿态、局部物体和场景布局的建模（arXiv Sec.2.1、项目页 Overview）。v0.1 报告同样没有公开数据细节。凡涉及数据规模/配比/采集：未披露。
训练方法
v0.2 强调”训练时是单个端到端因果模型”（“trained as one end-to-end causal stream”），拆分只发生在部署阶段（见下节 Infra）。除此之外，这份升级报告没有披露 v0.2 的训练配方：没有损失函数细节、没有训练步数/batch/学习率课程、没有分辨率课程表、没有任何 RL / 后训练 / 蒸馏环节的描述。它把建模范式当作”从 v0.1 继承且保持稳定”的基线，本版只讲分辨率和推理拓扑。所以训练/RL/蒸馏这几维在 v0.2 层面基本为”未披露”，能确认的只有：整体仍是端到端因果流式训练、生成侧为 flow-matching、结构范式与 v0.1 一致。
Infra（训练 / 推理工程）
这是 v0.2 的真正重点，也是全文着墨最多的地方。训练侧的算力/卡数/并行策略未披露；下面全是推理部署（serving）工程。
核心矛盾：640×368 的画面比 192p 大得多，latent 生成成本涨了，但必须塞进原来那个 160 ms 流式单元、不能拖慢交互循环。解法是把同一个端到端模型在部署时拆成 thinker–performer 两个角色：
- Thinker（单 GPU，延迟关键路径）：承载因果音视频编码器、更新语言与状态的那段短 token-causal Transformer 计算、K/V cache 构建，以及把上一单元 latent 渲染成音视频、立即输出的因果解码器。关键点是——语言/状态那段计算最终只以 K/V cache 的形式体现出来，作为生成的条件。所以 thinker 始终是一条紧凑的低延迟交互路径，留在单卡上。
- Performer（多 GPU，Ulysses 式上下文并行组）：只保留昂贵的 flow-matching latent 生成路径。thinker 广播出 performer 可用的 K/V 切片，每个 performer rank 把它写进预先分片好的本地 cache（pre-sharded K/V cache），然后对下一单元跑 Ulysses 上下文并行去噪。
分片策略里有个务实的取舍：只有高分辨率视频 latent 这条长序列才按 rank 切分，去噪时用 Ulysses 的 all-to-all / gather 集合通信在 performer 组内部收发；而一个 160 ms 单元里的音频 latent token 很少，切分只会带来通信开销而非有效并行，所以音频 latent 不做序列分片。同时，因为语言/状态计算已经折进 thinker 产出的 K/V 切片里，performer 组内部不需要再单独通信一条语言序列——这保住了 thinker↔performer 之间那个紧凑边界，把新增的硬件都堆在视觉生成上。
调度上，v0.2 把相邻单元的四件事流水线化：当前帧感知、上一帧解码、thinker↔performer 的 K/V 与 latent 传输、下一帧视频 latent 的并行去噪。吞吐只要满足”performer 组计算 + 通信 ≤ 一个 160 ms 单元”就成立；延迟是另一条独立的信号到信号路径（编码 → 状态更新 → latent 生成 → 解码），保持约 200 ms。作者反复强调这两者被解耦：v0.2 新增的重活全集中在上下文并行的 performer 里，thinker 那条延迟关键路径不受影响。这就是”分辨率涨了、延迟不变”能成立的工程根据。
具体到 performer 用几张卡、Ulysses 组多大、单元内各段耗时的分解:未披露。
评测 benchmark
这份报告基本没有量化 benchmark，需要直说。它只报告两类东西：
- 延迟/运行时协议：沿用 v0.1 的应答边界定义——模型侧信号到信号延迟从”一个 160 ms 用户流式单元对 thinker 可用”开始计时，到”对应音视频应答单元解码完毕待输出”结束。在这套 serving 路径下，v0.2 在产出 640×368 / 25 FPS 视频的同时保持约 200 ms 模型侧延迟；加上与 v0.1 相同的 350 ms 双向网络预算，端到端约 550 ms。作者特意说明网络项是外部部署假设、带宽受限的传输效应不计入这里报告的模型侧延迟。项目页还给了一个交互指标：约 0.5 秒的近乎瞬时 prefill（prompt 生效到新场景进入实时会话），且 demo 声明”未加速、含真实网络耗时、无重定时或拼接”。
- 定性视觉观察：用生成的 640×368 对话作定性观察，看听/说两种状态下的视觉稳定性与可读性——面部细节、视线、口型、手、姿态、周围物体、局部场景布局。结论是定性的：“更清晰的近景通话 + 有场景感的中景智能体”。
作者自己也点明，公开实时系统各报各的端点（首包语音延迟、首帧延迟、FPS、音画时延、产品级响应时间等口径不一），所以他们只按 v0.1 的同一应答边界报 v0.2 的运行时。没有 FID、没有唇同步指标、没有 VBench 类视频质量分、没有与其它系统的横向数值对比。凡涉及标准化质量 benchmark：未报告。
创新点与影响
把 v0.2 的贡献讲清楚，它不是一次能力跃迁，而是一次干净的工程升级：
- “保延迟涨分辨率”这件事本身：在实时交互里，分辨率翻几倍而端到端延迟一毫秒不涨，靠的不是把模型做小，而是把成本重新分配——延迟关键路径（thinker）留单卡不动，新增的视觉生成成本全部倒进可横向扩展的上下文并行 performer。这是”用并行度换分辨率、而非用延迟换分辨率”的清晰示范。
- thinker–performer 的拆分设计：让语言/状态计算只以 K/V cache 的形式跨过边界，配合 pre-sharded 的 performer 端 K/V cache 和”长视频 latent 分片、短音频 latent 不分片”的差异化并行，把一个单体端到端模型干净地拆成”低延迟控制路径 + 可扩展生成路径”。这套模式对任何”实时 + 大画面”的流式生成部署都有参考价值。
- 交互形态从近景头像扩到中景场景化数字人：能看清身体、手、周围物体和场景布局，意味着从”视频通话头像”往”处在具体环境里的实时智能体”迈了一步；加上 prompt 现场生成场景、约 0.5 秒 prefill，产品想象空间更大。
局限也要摆明：① 这是一份很短的升级报告，数据、训练、RL/蒸馏、模型规模全部未披露，只有推理拓扑讲得细；② 没有量化质量 benchmark，效果只有延迟协议 + 定性观察，和其它实时数字人/流式视频系统无法直接数值对比；③ 未开源（无权重、无代码、无 ModelScope card），外部无法复现或独立验证延迟数字；④ 版本号仍是 v0.x，作者自己把它定位为 preliminary 阶段的迭代。
原始链接
- arxiv_abs: https://arxiv.org/abs/2607.04443
- arxiv_html（全文）: https://arxiv.org/html/2607.04443v3
- arxiv_pdf: https://arxiv.org/pdf/2607.04443
- 项目页（官方，一等公民，中英双语）: https://wan-streamer.com/
- HuggingFace collection（仅两篇 paper，无权重）: https://huggingface.co/collections/ali-vilab/wan-streamer
- 前作 v0.1: https://arxiv.org/abs/2606.25041