模型如何一边看、一边听、一边回应：实时流式音视频多模态模型技术路线

type

Post

status

Published

date

Jul 30, 2026

slug

real-time-streaming-multimodal-models

summary

从每秒一帧的客户端采样到原生全双工 AV2AV，系统梳理实时流式音视频多模态的六条技术路线：增量 prefill 与 KV/GDN 状态、共享时间轴、显式说话触发、异步思考、模态专家，以及因果音视频生成；并拆解 Qwen3.5-Omni、MiniCPM-o、ROMA、DuplexOmni、ELLSA 与 Wan-Streamer 的实现边界与选型要点。

一、先定义问题：四种“支持视频”不是同一种能力

图 1：本文采用的 L0—L3 能力分级。三个“实时”——传输、推理和交互——只有同时成立，系统才接近持续在场。

L0：上传后理解

用户录完一段视频，服务端拿到完整文件后统一抽帧、编码和推理。这是视频理解，不是流式视频。它可以回答“刚才发生了什么”，却无法在杯子即将掉落时提醒，也无法在用户演示操作的中途纠错。

L1：稀疏视觉流

音频连续上传，视频在客户端被采成周期性图片。Gemini Live 明确把视频作为逐张图片发送，最高 1 FPS；Qwen Realtime 的官方建议也是 JPEG、480p/720p、每秒不超过 1 帧。S1 S2

这一路线很实用：复用成熟的实时会话接口，视觉 token 成本可控，普通网络也扛得住。但它观察到的是一串视觉快照，不是 25 FPS 的连续运动。快速手势、视线变化、短暂遮挡和细粒度动作很容易落在采样间隙里。

L2：增量音视频理解

新帧与新音频块被分块编码，历史状态持续保存在 KV Cache 或其他循环状态中，模型不必每次从头读完会话。此时“流式”进入了模型内部：它能让一段尚未结束的事件逐步改变当前判断，并在合适时刻触发回复。

MiniCPM-o 的 streaming_prefill、ROMA 的一秒多模态单元、Qwen3.5-Omni Thinker 的 chunked prefill，都属于这一层的不同实现。S3 S4 S5

L3：原生全双工 AV2AV

输入和输出的音视频可以重叠进行。模型一边接收用户的声音和画面，一边生成自己的语音、表情或动作；用户插话后，输出可以中止、重规划并继续。

这里的 AV2AV 是 Audio-Video-to-Audio-Video，不是给语音助手外挂一个口型驱动数字人。后者通常要等语音或文本确定后再渲染头像，输出形象无法反过来参与同一条连续时间线。Wan-Streamer 是目前公开资料中最接近原生 L3 的代表。

三种“实时”必须分别测

产品文档常用一个“低延迟”覆盖三件事：

传输实时：摄像头和麦克风的数据能否持续抵达服务端；

推理实时：新到达的块是否增量进入模型状态，还是提问时重新拼接全部历史；

交互实时：系统能否感知停顿、保持沉默、主动开口、处理重叠语音并响应打断。

这也解释了为什么“接口支持 WebRTC”不能证明模型原生流式，“模型声称全双工”也不能保证弱网下的端到端体验。两边要同时成立。

二、所有路线都绕不开的五个技术问题

单看模型结构，很容易被不同项目的命名带跑。把名字拿掉，实时音视频系统最终都要回答五个问题。

1. 连续视频怎样压进可承受的 token 预算

16 kHz 单声道 PCM 每秒有 16000 个采样，经过音频编码后尚可压到个位数或几十个 token；视频则同时包含空间和时间两个维度。假设每秒只取 1 帧，每帧仍可能产生数百乃至上千个视觉 token。若真的按 25 FPS 处理，长会话很快会撞上显存、上下文和首包时延三重限制。

因此，现实系统通常组合使用：

客户端降帧率、缩放、JPEG 压缩；

服务端视觉 resampler，把一帧压成固定数量 token；

相似帧过滤、关键帧选择或事件驱动采样；

对静态背景建立持久表示，只发送变化；

用连续 latent 而非离散视觉 token 生成输出视频。

“支持 1080p 输入”与“模型理解 1080p 的每一帧”是完全不同的说法。前者可能只是接口接收上限。

2. 音频与视频怎样共享时间

一段话和一个动作是否相关，取决于它们是否发生在同一个时间窗。离线模型可以把视频均匀抽帧后整体编码；在线模型没有完整未来，必须在数据到达时建立时间关系。

主流做法有两类：

显式时间 ID：给音频 token、视频 token 和文本 token 标上统一时间坐标，例如 Qwen3.5-Omni 用 TMRoPE 和显式时间戳对齐动态帧率视频与音频；

固定时间窗：把一秒或 160 毫秒内的视觉、音频和输出组织为一个流式单元，例如 MiniCPM-o、ROMA、Wan-Streamer。

时间窗越短，交互越灵敏，但序列更长、调度更频繁；时间窗越长，吞吐更好，却可能把 300 毫秒内发生的“抬手—停顿—开口”压成同一块。

3. 历史怎样留下，未来怎样不泄漏

离线 Transformer 可以看到整段序列。流式模型必须保证时间的输出只依赖之前的信息，同时又不能反复计算过去。

典型组合是：

encoder 使用 causal / chunk-causal attention；

backbone 持久化 KV Cache；

语音和视频 decoder 只消费已确认的历史 latent；

分块 prefill 将新输入追加进缓存；

对长会话做滑窗、压缩记忆或分层状态。

如果接口在每次 query 时把缓冲区里的全部帧和音频重新拼成 prompt，即使数据通过 WebSocket 到达，它也仍然只是“流式传输 + 批式推理”。vLLM-Omni 当前的 Streaming Video API 就明确把 session KV reuse 与 incremental prefill 列为尚未实现的限制。S14

4. 模型何时开口

传统语音助手依赖 VAD 判断“用户说完了”。在视频场景里，轮次边界不再只由声音决定：

用户可能沉默地演示一个动作，期待模型及时纠错；

用户说“你看这里”，真正的信息在随后两秒的画面里；

模型发现危险时应该主动打断；

用户只是短暂停顿或转身拿工具，模型不应抢话。

这推动了三种机制：

外部 VAD / 语义 VAD 决定 turn；

在主干上增加 Speak Head，单独学习听或说；

把 [listen]、[speak]、[interrupt] 等控制信号写进生成序列。

“回答什么”与“现在要不要回答”相关，但不是同一个预测任务。ROMA 把后者显式拆成二分类头，MiniCPM-o 把它做成流内控制。

5. 深度思考怎样不阻塞自然交流

人类对话里，简单回应可以立刻给出，复杂问题则会边说边想、查资料再补充。若模型必须完成整个 reasoning 或工具调用后才能发出第一段语音，它的能力越强，反而越像卡住。

DuplexOmni 的核心不是换一个视觉编码器，而是把低延迟 Interaction Layer 与可插拔 Thinking Layer 解耦。前者维持“我在听、我先回应”的节奏，后者异步完成复杂推理，再把中间结果逐步回灌。这是流式多模态从“模型结构问题”走向“认知调度问题”的一个明显信号。

三、路线一：客户端采帧，把视频降维成稀疏视觉事件

这是目前最容易产品化、也最容易被误称为“实时视频模型”的路线。

Gemini Live：一个持续会话，视频仍是逐张图片

Gemini Live 使用有状态 WebSocket。客户端持续发送 16 kHz PCM 音频，并将视频转成单张 JPEG 图片，官方限制最高 1 FPS；模型可返回 24 kHz PCM 音频，并支持打断。S1

从工程边界看，它的实时性主要落在会话协议与音频交互上：

这一设计有三个直接后果。

第一，视觉成本与原始摄像头帧率脱钩。手机仍可 30 FPS 采集，但只有少量代表帧进入模型。第二，客户端握有采样策略，产品可以根据运动强度、场景变化或网络状态动态取帧。第三，模型端看不到采样间隔中的真实运动，所谓“视频理解”更接近带时间顺序的多图理解。

因此它适合：

用户举起商品、零件或作业本，让助手识别并讲解；

桌面摄像头低频观察场景，音频承担主要交互；

对动作时序不敏感的导览、陪伴与远程协助。

它不适合精细动作纠错、手语、快速安全事件、球类轨迹和依赖视听亚秒同步的任务。

Qwen Realtime：同样的 API 外形，背后连接 Omni 模型

Qwen Realtime 同时提供 WebSocket 与 WebRTC。WebSocket 模式下，音频先进入缓冲区，图片可作为本地文件或实时视频帧持续追加；官方建议 JPEG、480p/720p、单帧不超过 256 KB、每秒不超过 1 帧，并要求先发送音频。WebRTC 模式则直接使用 RTP 音视频轨道。S2

这组约束透露了一个重要的系统事实：即便底层 Qwen3.5-Omni 能处理动态帧率视频，公开实时 API 仍会在接入层把摄像头流约束为稀疏帧。模型能力与产品服务边界不能混为一谈。

官方还为会话设置了视频累计时长、轮次和音频时长上限；不同 Plus / Flash 版本数值不同。S17 这不是无关紧要的计费细节，而是状态管理策略的一部分：实时会话要控制缓存增长、排队和尾延迟。

这条路线真正值得优化的是采样器

固定 1 FPS 只是安全默认值，不是最优策略。更合理的客户端可以根据：

帧间视觉相似度；

光流或运动幅度；

用户语言中的指示词，如“现在”“这里”“这个动作”；

模型反馈的不确定性；

网络带宽与排队长度；

动态决定何时送帧。也就是说，第一代实时视频助手的关键模块可能不是更大的 VLM，而是一个面向回答价值的视觉采样控制器。

Artic 的思路正沿这个方向推进：传输系统根据模型的响应能力和区域重要性调整码率与量化，而不再只优化人眼观看的 VMAF。后文会回到这一点。

四、路线二：分块编码与共享时间轴，让模型真正保留“正在发生”

稀疏帧解决了带宽，但没有自动解决持续状态。Qwen3.5-Omni 与 MiniCPM-o 4.5 给出了两种代表性实现。

Qwen3.5-Omni：Thinker–Talker 上的动态时间对齐

图 2：Qwen3.5-Omni 的 Thinker–Talker 架构。视觉与 AuT 音频编码结果进入 Hybrid Attention MoE Thinker，Talker 再生成多码本语音 token，并由因果流式 codec decoder 输出波形。来源：Qwen Team, Qwen3.5-Omni Technical Report, Figure 2，CC BY 4.0。

Qwen3.5-Omni 沿用了 Thinker–Talker 分工，但把流式能力推进到编码、注意力与语音生成链路。

输入怎样进入。 视觉编码器接收图片和动态帧率视频。AuT 音频编码器将音频下采样 16 倍，得到约 6.25 Hz 的音频 token——每个 token 对应约 160 毫秒，并用动态注意力窗口兼顾局部低延迟与较长语义。S3

时间怎样对齐。 模型使用 TMRoPE，把视频和音频映射到统一时间坐标。报告描述的关键做法是：视频可以是动态 FPS，音频和视频时间 ID 以 160 毫秒为分辨率推进，同时可加入显式 timestamp text。这使“某一帧”和“某一段声音”不必靠序列位置碰巧相邻。S3

状态怎样保留。 Thinker 并不会在每个时间点重新计算完整的音视频窗口。新到达的多模态块经过编码后，只对新增 token 执行 chunked prefill；历史则以 full-attention 层的 KV Cache 和 Gated DeltaNet 层的递归状态两种形式继续参与计算。S3

Chunked prefill：逻辑上看到全部历史，实际只计算新块

先区分“模型此刻能够利用的逻辑上下文”和“本次前向真正送入的 token”。假设音视频流被切成三个时间块，普通无状态调用会反复提交完整输入；有状态的流式 prefill 则逐块追加：

处理时，Thinker 在逻辑上可以利用，但送入主干做本次 prefill 的通常只有新产生的 embedding。和已经进入主干缓存，不需要重新执行整条 Hybrid MoE 前向。

这里要把 encoder 和主干分开看。的原始音频与视频仍需经过各自 encoder，才能变成新增 embedding；至于应用再次提交重叠帧时，历史原始帧会不会重新编码，则取决于运行时是否只摄取新数据、是否缓存 encoder 输出。技术报告确认音视频 encoder 能沿时间维输出 chunk、Thinker 支持 chunked prefill，但没有公开线上服务的视觉特征缓存策略。因此，可以确定的是“进入 Thinker 的历史 token 不做完整主干重算”，不能仅凭 chunked prefill 推导出“任何历史画面都绝不会再次经过视觉 encoder”。S3

“chunked”表示一次摄取一块新 token，而不是像自回归解码那样每次只处理一个 token。假设历史长度为，新块包含个 token，模型会并行处理位置到。chunk 内仍使用因果 mask：第一个新 token 只能读取历史，第二个还可以读取第一个，依此类推。这样既保留了流式因果性，又能利用 GPU 的块状矩阵计算。

图 2.1：本文根据 Qwen3.5-Omni 报告与 Qwen3.5 Hybrid Attention 结构重绘。进入 Thinker 主干的新增 token 只做一次增量 prefill；full-attention 层追加 KV，GDN 层更新固定形状的递归状态。图中不假设服务端一定缓存视觉 encoder 输出。

Full attention：旧 token 保留 K/V，新 token 只计算自己的 Q/K/V

在 full-attention 层，历史 token 已经产生了和。新块到来时，只需计算：

随后，新 query 同时读取历史 KV 与本块前序位置：

处理完毕后，被追加进 KV Cache，供下一个音视频块使用。旧 token 的 hidden state 不需要更新，因为因果模型中位置的表示只依赖及其之前的信息，未来 token 的到来不会改变它。

若忽略常数和头数，重新计算长度的完整前缀需要约的注意力计算；复用 KV 后，新块只需约。它省掉了旧 token 之间已经完成的计算。不过，新 query 仍要读取历史 KV，因此上下文越长，full-attention 层的显存占用与 KV I/O 仍会增长。

Gated DeltaNet：历史被压进递归状态，而不是逐 token KV

Gated DeltaNet（GDN）走的是另一条路。它不会为每个历史 token 保存一对完整 K/V，而是把过去的信息连续更新到一个固定形状的状态中。省略具体门控和 delta rule 后，可以把单步过程写成：

当一个包含个 token 的新块到来时，GDN 从块开始前的出发，依次吸收新块信息，最后得到。实现时可以使用面向 chunk 的并行 scan / kernel，不必从第一个历史 token 重新递推。下一块只需要接着这个最终状态继续更新。

因此，两类层保存的“历史”并不相同：

full-attention 层保存随上下文增长的 token 级 K/V，能够让新 query 精确访问具体历史位置；

GDN 层保存固定形状的递归状态，避免在每一层搬运完整历史 KV；

Hybrid backbone 将二者交错：GDN 承担更便宜的长序列状态传播，间隔出现的 full attention 保留精确的全局 token 交互能力；

MoE 解决的是每个新 token 激活哪些前馈专家，降低计算量，但不负责会话状态的保存。

这就是报告所说 GDN 能降低长音视频推理中的 KV-cache I/O 的具体含义：它不是“把所有旧 KV 压缩后仍按 token 查询”，而是把一部分层改造成递归状态机。Qwen3.5 系列公开实现采用 GDN 与 full attention 的混合层布局；Qwen3.5-Omni 报告确认 Thinker 和 Talker 都使用包含 GDN 的 Hybrid MoE，但没有公开每个 Omni 版本的完整层数和服务端缓存配置。S3 S19

套回滑动窗口：到是否重算

如果上一个时刻的逻辑窗口是：

当前窗口是：

那么在有状态流式推理里，不应把整个当作一条新 prompt 再算一次。真正新增的只有：

如果应用每次都把完整发给一个无状态接口，并且服务端没有 prefix cache，窗口内 token 才会被全部重新计算。

严格的固定长度滑窗还有一个边界。full-attention KV Cache 可以淘汰最旧位置，使新 query 不再访问它；但 GDN 的递归状态已经吸收了早期 token，一般不能精确地把某个最旧 token 的贡献“减掉”。因此，Qwen3.5-Omni 更适合被理解为前缀状态持续增长或累积，而不是每一步都执行可逆的固定长度滑窗。256K 是模型训练和支持的最大逻辑上下文，并不表示每次流式更新都会重新计算 256K token；超过上限后采用截断、重建、摘要还是其他缓存回收方式，技术报告没有公开。S3

输出怎样流出。 Talker 不直接生成完整波形，而是通过多 token 预测生成 RVQ codec token，因果式 Code2Wav 再把已到达的 codec 块立刻解码成语音。ARIA（Adaptive Rate Interleave Alignment）用于协调文本 token 与语音 token 的不同生成速率，避免固定比例把语音节奏绑死。S3

这是一条非常典型的“统一理解主干 + 独立流式语音解码”路线。它能持续看和听，能低延迟说，但输出视频不在生成闭环里，因此属于 L2，而不是原生 AV2AV。

报告给出了视频输入在单并发下的首包时延：Flash 约 426 ms、Plus 约 651 ms；音频分别约 235 ms、435 ms。S3 这些数字只适合说明同一报告内的相对量级，不能与其他项目的“首个音频块”“模型侧 latency”直接横比，因为输入长度、网络、硬件和计时边界都不同。

MiniCPM-o 4.5：Omni-Flow 把输入和输出切到同一条流

MiniCPM-o 4.5 的实现更适合观察“流式模型内部到底存什么”。它不是简单地把图片和音频拼进 prompt，而是把环境输入与模型输出组织成连续时间窗。S4

先分清 MiniCPM-o 4.5 与 Omni-Flow

MiniCPM-o 4.5 是一套具体的多模态模型与推理系统，Omni-Flow 则是它实现全双工交互时采用的建模和执行范式。 前者回答“哪些模块负责理解和生成”，后者回答“输入、控制和输出怎样沿时间排列，状态怎样跨时间窗延续”。两者不是并列的两个模型，Omni-Flow 也不是一层可以单独画在网络结构里的神经模块。S4 S20

因此，streaming_prefill 和 streaming_generate 是公开实现用来执行 Omni-Flow 的接口，不是 Omni-Flow 本身；而 Qwen3-8B、视觉与音频 encoder、语音 decoder 才是实际参与计算的模型组件。概念上可以把 Omni-Flow 理解为 MiniCPM-o 4.5 的“全双工运行规则”，公开代码中的状态结构和接口则是这套规则的具体落地。S20

先看实际结构：不是两套名为 Thinker–Talker 的大模型

这里需要先校正一个容易由术语产生的误解：Omni-Flow 不是一对叫作 Thinker 和 Talker 的模型模块，而是把输入、控制和输出排列到共享时间轴上的序列化与交互框架。 MiniCPM-o 4.5 的实际模型结构更接近“一个中心语义主干，加一条轻量语音生成链”。S4 S20

图 3：本文根据 MiniCPM-o 4.5 论文与公开实现重绘的端到端结构。图中的 thinker-like / talker-like 只是功能类比，不是论文定义的模块名。

视觉和音频先由各自的 encoder 压缩成 embedding，再共同进入唯一的 Qwen3-8B 主干。这个主干承担三类工作：理解当前音视频和历史上下文；生成 <|listen|> / <|speak|> 控制；在需要开口时生成文本 token 及其 hidden states。论文给出的全双工文本解码速度约为每秒 3—4 个 token。S4

当主干决定说话时，新增文本 token 与对应的 LLM hidden states 会一起送入约 0.3B 的轻量 Llama 语音 token decoder。它不重新理解视频和音频，而是把主干已经形成的语义表示展开为约 25 token/s 的 S3 语音 token；之后，流式 flow-matching decoder 再结合参考音频，把这些语音 token 增量还原成可播放波形。TAIL 位于文本与语音时间线之间，负责限制文本前瞻并协调语音生成和实际播放进度。S4

因此，如果只讨论功能，可以把 Qwen3-8B 称为 thinker-like，把“语音 token decoder + 波形 decoder”称为 talker-like；但它和 Qwen3.5-Omni 的显式 Thinker–Talker 架构并不相同。MiniCPM-o 没有另一套与语义主干对称的 Talker Hybrid MoE，也不是两套大主干各自持续推理；它是中心 LLM 先给出控制、文本与 hidden states，轻量声学生成链再消费这些状态。所谓全双工主要来自跨时间窗的重叠：模型一边播放上一窗生成的语音，一边继续摄取下一窗的画面和声音。

视觉与音频先被压到相近量级

MiniCPM-o 4.5 使用约 0.4B 的 SigLIP 视觉模块。一张图片可按 slice 处理，每个 slice 原本有 1024 个 token，再经 resampler 压缩为 64 个，压缩比 16 倍。全双工设置下单 slice 最大约 448×448。S4

音频侧使用约 0.3B 的 Whisper Medium。原始编码约 50 token/s，再压缩 5 倍到 10 token/s。这样音频和低帧率视觉可以在同一秒内进入主干，而不会让视觉 token 完全淹没其他模态。S4

Omni-Flow 不再把输入、回答当作两个阶段

上面的模型结构说明“由哪些模块计算”；接下来沿一个时间窗展开 Omni-Flow，看这些模块接收的输入和产生的输出如何进入同一条因果序列。

图 3.1：上半部分是本文根据 MiniCPM-o Omni-Flow 重绘的时间窗；下半部分是 ROMA 的显式 Speak Head。两者都把轮次问题改写为时间上的连续决策。

对时间窗，可以把流式单元抽象为：

其中是环境视觉，是环境音频，是模型在该窗的文本/语音输出，是 listen / speak 控制。模型没有输出时，不是留空，而是写入 [listen]。于是“沉默”也成为可学习的序列状态。

论文的消融值得注意：在其训练设置里，1.0 秒时间窗优于 0.2 秒和 0.1 秒；显式边界有帮助；独立的 Listen–Speak 控制也优于只靠文本内容暗示状态。S4 这说明更细的切片并不自动带来更好的实时性。调度次数、短块语义不足和训练分布都可能抵消理论上的低延迟。

TAIL 解决文本、语音和播放进度的错位

主干大约生成 3—4 个文本 token/s，语音 decoder 则约 25 个 speech token/s。如果机械地按固定比例交错，文本可能思考得太快，语音来不及播放；也可能文字不足，声音被迫等待。S4

TAIL（论文中的时间对齐机制）根据累计播放进度动态调整当前生成的文本量，并限制前瞻范围。目标不是让所有模态 token 一一对齐，而是保证可听见的输出时间线不被文本解码节奏拖垮。

推理接口暴露了真正的状态边界

有必要把 streaming_prefill 和 streaming_generate 展开，因为它们不是普通 chat API 的两个方便函数，而是 Omni-Flow 在推理时的直接落地。不过也要避免倒因为果：Omni-Flow 是训练和序列化范式，这两个接口只是公开实现用来执行每个时间窗的方法。

全双工模型先通过 as_duplex() 切换模式，再由 prepare() 初始化一次会话。prepare() 会清空上次交互状态，将 system prompt 和可选的参考音频预填进主干，并初始化 TTS、Token2Wav 与滑动窗口状态。此后，每个约 1 秒的时间窗都运行同一个循环：S5 S20

这不是“先听完整段，再回答”的两阶段流程。prefill → generate 会在每个时间窗重复，前一个窗生成的输出和后一个窗新到达的环境输入都会进入同一条因果序列：

或者：

下一秒到来时，直接追加在后面。于是“监听”不是没有调用模型，也不是由外部 VAD 暂停生成，而是模型明确生成进历史的一种输出状态。

streaming_prefill 负责把当前环境写进状态。 源码会先判断这一窗属于 AUDIO、VISION、OMNI 还是 TEXT，然后写入 <unit> 边界。视频帧经 SigLIP 与 resampler 变成视觉 embedding；音频经过支持增量 KV Cache 的 Whisper encoder、投影和池化后变成音频 embedding。两类 embedding 随后被送进 Qwen3 主干。主干更新自己的 KV Cache，但此时不展开完整回答，只保存最后位置产生的 pending_logits。S20

可以把 pending_logits 理解为“模型看完这一秒以后，对下一个控制 / 内容 token 的即时分布”。它连接了摄取和决策，使 streaming_generate 不必再把这一秒的图像和音频重新前向一次。

streaming_generate 先决定 listen 还是 speak，再决定说什么。 它直接消费 streaming_prefill 留下的 pending_logits。在论文采用的显式 Listen–Speak 控制里，第一个关键输出是 <|listen|> 或 <|speak|>：

若为 <|listen|>，该时间窗立即以 </unit> 结束，返回 is_listen=True 和静音波形；

若为 <|speak|>，主干在该窗内继续生成一小段文本，公开实现默认最多生成 20 个 speak/text token；

新文本 token 对应的 LLM hidden states 被送入轻量语音 decoder，后者复用自己的 TTS KV Cache，生成约一秒的语音 token；

Token2Wav 再把语音 token 增量转换为可播放波形；如果轮次尚未结束，TTS 和 waveform cache 会保留给下一时间窗继续使用。S20

一次循环实际维护的不只是“一个 KV Cache”，而是几组生命周期不同的状态：

状态	由谁更新	保存什么	何时重置或回收
LLM / Omni-Flow 状态	prefill 与 generate 都会更新	system prompt、历次 `<unit>`，以及视觉/音频 embedding、listen/speak 和文本产生的主干 KV	会话重置，或按 basic/context 滑动窗口回收
音频 encoder 状态	`streaming_prefill`	Whisper encoder 的历史 KV、尚未消费的音频 buffer、chunk 计数	encoder 上下文到顶或会话重置
`pending_logits`	prefill 产生，generate 消费	当前时间窗末尾的下一 token 分布	每个时间窗只消费一次
TTS 状态	`streaming_generate`	已生成语音 token 的 KV、文本进度和当前发言起点	一次发言结束后重置
Token2Wav 状态	`streaming_generate`	尚未合成为波形的语音 token、flow / vocoder cache	发言结束并 flush 后重置

这种拆分解释了“全双工”是怎样出现的：模型在第秒生成的语音可以继续播放；第秒的新画面和环境音频仍可进入下一次 prefill，模型再根据更新后的现场决定续说、结束或保持监听。输入与输出在墙上时钟中重叠，但在因果 token 序列里仍按“本窗输入在前、本窗决策与输出在后”的顺序组织。

公开实现还在每个 </unit> 后登记时间单元，并提供两种长会话回收策略：basic 只保留最近的 token；context 额外保护 system prompt 与最近上下文。这里的滑窗是推理系统的缓存管理，不是 Omni-Flow 的训练定义。S5 S20

还要区分模型仓库里的另一组同名方法。半双工 streaming 示例使用 streaming_prefill(session_id, msgs, ...) 逐块摄取完整用户输入，等最后一个 chunk 到达后才调用一次 streaming_generate；它的目标主要是降低回答的首 token 延迟。全双工 Omni-Flow 使用的则是 as_duplex() 后的接口：每个时间窗都交替调用一次 prefill 和 generate，并在当窗输出 listen 或 speak。只看函数名，很容易把两者误认为同一种执行方式。S20

对外的 Realtime API 又隐藏了这层区别。客户端只需通过 WebSocket 连续发送 input.append——16 kHz 单声道 float32 PCM 和可选 JPEG 帧——并接收 listen、text、audio 三类 response.output.delta。Gateway 与 PyTorch 或 C++ worker 在内部驱动上述时间窗循环。S5

因此，这两个接口最值得读者记住的不是名称，而是状态边界：prefill 摄取当前一秒并留下下一 token 分布；generate 消费这份分布，完成 listen/speak 决策和当窗输出；两者共同把 Omni-Flow 的一个 写进持续会话。

作者还声称模型可在低于 12 GB RAM 的边缘设备运行。S4 这应理解为特定量化、后端与配置下的项目目标，不宜直接推导成所有实时视频工作负载都能在消费设备上满速运行。

五、路线三：把“何时说”从“说什么”里拆出来

共享时间轴让模型知道发生了什么，但并不能保证它学会自然轮次。ROMA 的设计很克制：它基本沿用 Qwen2.5-Omni，只新增一个很小的 Speak Head，把主动响应变成显式预测任务。S6

ROMA：一秒多模态单元 + 二分类触发头

ROMA 将每 1 秒音频和同一秒的视频帧组成一个 multimodal unit。视频与音频 token 按固定顺序包装，使用 chunked TMRoPE：S6

同一单元内的视频 token 共享时间 ID；

音频 token 按 40 ms 分辨率推进；

后续单元延续全局时间 ID；

历史通过持久 KV Cache 保留。

模型推理时以 2 FPS 读取视频，每帧像素数限制在 65,536 以内。论文报告单个流式单元的平均编码时间约 0.3697 秒，这让每秒一次的在线决策在其测试硬件上具备可行性。S6

Speak Head 是一个两层 MLP，与语言模型输出头并行。它不是只看最后一层 hidden state，而是对最后层做加权组合，然后每个流式单元输出一次“触发 / 不触发”。这样做的直觉是：中间层可能保留更多音视频时序线索，最后一层则更偏向下一个文本 token。S6

训练分两阶段：

先做 streaming format alignment，让原本按完整轮次训练的 Omni 模型适应一秒一块的输入格式；

再用 timing BCE 训练 Speak Head，同时保留一个较小权重的问答语言模型损失，避免模型只学会时机却丢掉回答能力。

训练数据也围绕响应时机分层：约 2.7 万主动在线交互样本、10.9 万旁白样本、54 万反应式问答样本。这里“主动”不是营销标签，而是监督信号里真的存在“看见某事后，不等用户提问就开口”。S6

为什么一个小 Head 值得单列为路线

它提供了很强的工程可解释性：

threshold 可以按场景调节，安全提醒宁可敏感，陪伴对话可以更克制；

Speak Head 可以单独做 ROC、误触发和漏触发评估；

主干模型与语音合成链路可以保持相对稳定；

轮次数据量不够时，不必重训整套音视频生成模型。

代价也明显。每秒一次的二分类仍是粗粒度控制；它判断“现在是否说”，但重叠语音、被打断后的续接、后台工具调用等复杂交互仍需额外状态机。ROMA 更像是从回合制走向全双工的最小改造，而不是终点。

六、路线四：交互层与思考层异步，让“先接住话”不必等“完全想清楚”

图 4：DuplexOmni 将实时 Interaction Layer 与可插拔 Thinking Layer 解耦；Interaction Model 内部再以时间片驱动 Thinker–Talker。来源：DuplexOmni, Figure 2。

许多全双工模型的矛盾是：交互要求 500 毫秒内有反应，复杂推理却可能需要数秒。DuplexOmni 把这个冲突变成架构边界。S7

先分清两组容易混淆的名字

论文层面的 Interaction Layer / Thinking Layer，和 Interaction Model 内部的 Thinker / Talker 不是同一组模块：S7 S21

Interaction Layer（S1） 是整套实时 DuplexOmni 模型，负责持续听、看、控制节奏并输出文本和语音；

Thinking Layer（S2） 是外接的慢速推理或工具服务，可以是更强的 LLM、检索系统或 Agent；

Thinker 是 S1 内部的多模态语言主干；

Talker 也是 S1 内部的语音 codec 生成模块。

因此，问“Interaction Layer 和 Thinking Layer 是否一起训练”时，答案是：没有证据表明 S1 与外部 S2 做了端到端联合训练。 S2 是通过 OpenAI-compatible endpoint 接入的可插拔服务；论文实验的默认配置甚至直接使用 Gemini-3.1-Flash-Lite 作为 Thinking Layer。训练的重点是让 S1 学会何时请求 S2、等待或取消，以及怎样把 S2 返回的片段组织成适合当前对话的表达，而不是把梯度反传进 S2。S7 S21

真正进入训练流水线的是 S1 内部的 Thinker 与 Talker

DuplexOmni 从 Qwen3-Omni 初始化，进行两阶段 SFT：第一阶段用大规模语音交互数据建立基础的全双工听说能力，第二阶段用更高质量的复杂交互和视频通话数据强化打断、后台思考和视觉场景。S7

但 Thinker 与 Talker 也不是在同一个 step 里同时更新。论文描述的是交替优化：训练 Thinker 时冻结 Talker，只计算 Thinker 的交叉熵；训练 Talker 时冻结 Thinker，只计算 Talker MoE 与 MTP 的交叉熵，两部分数据比例为 1:1。公开训练 README 给出的标准路径更明确地采用先训练 Thinker，再从 Thinker checkpoint 训练 Talker，并注明不要求 joint training。两种表述的执行粒度略有区别，但共同点一致：Thinker 与 Talker 共享训练数据和接口约束，却没有同时接受一条端到端梯度。S7 S21

可以把 Thinker 的监督写成 masked next-token cross-entropy：

其中包括按时间片组织的音频、视频、历史和 S2 feedback；是训练标签不等于 -100 的位置。目标不只是普通回答文本，还覆盖数据中显式标注的交互控制与语义输出，因此 Thinker 会学习“现在继续听、开始说、停止播放、请求或暂停后台思考”等行为。公开实时实现把这些结果具体解析为 asr、tts、tts_control 和 system2_control。S7 S21

Talker 的损失又分成两部分。主自回归分支预测每个 speech frame 的第 0 层 RVQ codec：

MTP / code predictor 再根据 Talker hidden state、第 0 层 codec 和已经生成的残差层，预测其余 RVQ codebook：

源码中的统一形式是：

公开 Talker recipe 设置、、，同时冻结 language model 与 visual module，只训练 Talker；代码里最后一项变量仍叫 mlp_loss，实际计算的是各残差 RVQ codebook 的 MTP cross-entropy。Thinker 阶段则使用标准语言模型交叉熵。这里没有一项“Interaction–Thinking alignment loss”，因为外部 S2 根本不在这条梯度图里。S21

推理时，S1 与 S2 通过控制 token 和流式片段协作

每个约 480 ms 的时间片，Interaction Layer 持续接收当前音频、同时间片采样的视频帧、对话历史，以及此前已经到达的 S2 片段。它不会因为发起慢思考而暂停：

论文层面的协议是：S1 需要帮助时，把对话文本、视频信息与任务状态发给 S2；S2 用特殊控制 token 包装中间结果并流式返回；如果用户补充条件或任务已经变化，S1 可以停止当前 S2 输出，再用新上下文发起请求。S1 始终保留最终表达权——S2 返回的是“后台材料”，不是直接绕过 S1 播放给用户的答案。S7

公开实时服务给出了更具体的实现。S1 每片输出 system2_control：[THINK] 会创建一个异步 S2 streaming task，[WAIT] 会停止或取消旧任务。S2 输出被拆成 【…】 短片段放入队列，随后以 from_s2 字段逐片注入后续 S1 请求；实现还在相邻 S2 片段之间加入约 0.5—1.0 秒的调度间隔，避免后台模型一次吐出过多文字，压垮实时说话节奏。如果 S1 生成 [STOP]，服务会丢弃尚未播放的 Talker 音频并清空播放缓冲，用于处理打断。S21

S1 内部，Thinker 与 Talker 也按流水线解耦

在时间片，Thinker 生成 Assistant 文本 token、对应 embedding 和 hidden states 。二者分别投影后逐位置相加，形成 Talker 条件：

Talker 的 prefix 不只包含当前，还保留此前各时间片的条件序列和完整 RVQ codec 历史。它在当前片生成六个 codec frame，对应约 480 ms 语音，再由 Code2Wav 解码。公开服务进一步把 Thinker、Talker 和 orchestrator 拆成独立服务：Thinker 先返回文本、token id 与对齐 hidden states，orchestrator 将这些张量放入异步队列，Talker worker 随后生成音频。这样下一轮感知与文本决策可以继续推进，不必和上一片语音生成严格串行。S7 S21

Talker 复用 KV Cache 与 codec history，Thinker 和 Talker 再配合图执行优化，目标是让实时因子 RTF 小于 1——即生成一秒语音所需计算少于一秒。外层的 S1–S2 异步解决“慢思考阻塞交互”，内层的 Thinker–Talker 流水线解决“文本决策阻塞语音生成”；这是 DuplexOmni 实际上存在的两级解耦。

训练数据必须包含“对话中的不完美时序”

DuplexOmni 使用 Writer–Director 方式构造包含重叠、沉默、补充、打断和延迟思考的训练场景。这个细节比模型参数量更值得关注：回合制语料里没有“用户在模型说到一半时插话”，结构再先进也学不会自然恢复。

公开模型卡显示权重采用 Apache-2.0 发布，Thinker 与 Talker 合计约 35B BF16；项目建议至少 8 张 H20 才能获得低延迟，并明确列出意外沉默和语音质量问题。S8 这给出了一个很现实的定位：DuplexOmni 展示的是强全双工交互架构，不是轻量生产方案。

论文表格给出约 0.506 秒 latency。S7 与 Qwen 或 Wan 的数字一样，应按该项目测量边界阅读，而非放进排行榜。

七、路线五：模态专家各算各的，但在同一个注意力空间里交流

图 5：ELLSA 的 Self-Attention Mixture-of-Experts。Speech Expert 与 Action Expert 保留各自参数，但产生的 K/V 按同一因果序列进入统一注意力上下文。来源：ELLSA, Figure 1。

ELLSA 面向的不只是视频通话，而是机器人与具身交互：输入有语音和视觉，输出除了语音，还可能是离散动作。它采用 SA-MoE（Self-Attention Mixture-of-Experts）避免让一个稠密主干同时承担所有模态计算。S9

第一步不是“融合特征”，而是把四条流排成一条因果时间线

ELLSA 默认以一秒为一个 time block。第个块不是简单地把四种 embedding 相加，而是构造成一段有固定语法的交错序列：S9

这里的 <bos> 是 begin-of-speech，不是通常语言模型里的 begin-of-sequence；boi、bot、boa 分别表示 image、text 和 action 的开始。模态边界 token 同时承担两个功能：一是告诉模型当前区间该走哪个专家，二是把“什么时候说、什么时候动”变成可监督的序列预测问题。

具体到每个块：

语音输入先经过 32 层、hidden size 2048 的流式 Mamba encoder，以 25 Hz 产生表示；每 5 帧拼接一次，下采样到 5 Hz，所以一秒最终只向主干送入 5 个 speech embedding。

视觉输入由 Emu3-VisionTokenizer 离散化。在 LIBERO 设置里，每秒不是只有一张图，而是前视相机和夹爪相机各取一帧；时间采样仍然只有 1 Hz。

文本输出每块最多生成 8 个 token。没有必要开口时，模型必须显式生成 <silence>，而不是依赖外部 VAD 替它决定。

动作输出由 FAST tokenizer 表示。公开的一秒配置每块生成约 10 个 action frame 对应的 token；不应移动时则生成 dummy action。

固定顺序也确定了块内因果关系：当前动作可以依赖刚刚听到的语音、当前画面和本块生成的文本；文本可以依赖语音与画面，但不能反过来看到尚未生成的动作。跨块再按时间继续追加，因此整体仍是一条标准的 causal sequence。

语音输出是一个例外：它不作为第五段 codec token 塞回主序列。ELLSA 从 Speech Expert 生成文本时的 hidden states 中抽取条件，经两层 MLP 投影后交给 CosyVoice2-0.5B。TTS 模块每 8 个文本 embedding 生成 25 个 speech codec。这样，文本承担“这一秒说什么”的语义骨架，codec 模型承担“怎样发声”。S9 S22

SA-MoE 不是常见的 Top-K MoE

“Speech Expert 与 Action Expert 共享注意力”很容易被理解成共享同一套 attention 权重，实际并不是。两套专家各自保留预训练得到的 Q/K/V projection、output projection、LayerNorm 和 MLP；所谓 unified self-attention，指的是它们产生的 K/V 按原始 token 顺序进入同一个因果注意力上下文。S9 S22

对第层、第个 token，先由模态边界确定专家：

然后只用该专家的投影计算当前位置的 query、key 和 value：

但注意力读取的是此前所有专家写入的统一 K/V 序列：

最后，attention output projection 和 MLP 又按路由回对应专家。以一个 text token 为例：它的来自 Speech Expert，却能注意到前面由 Action Expert 编码的前视图和夹爪图 K/V；以随后生成的 action token 为例，它用 Action Expert 的参数计算，但可以读取刚刚的语音、视觉和回答文本。因此，“专家各算各的”与“跨模态共享状态”同时成立。

它与普通 MoE 有三个关键区别：

没有学习型 router，也没有 Top-K、负载均衡或 expert capacity；模态区间直接决定路由。

一个位置只激活一套专家参数，但 attention 的历史不按专家隔离。

两个专家必须逐层对齐。ELLSA 恰好选择了配置相容的 Llama-3.1-8B-Instruct 与 Emu3-Base：都是 32 层、hidden size 4096、32 个 attention head 和 8 个 KV head，所以每一层都能直接交汇，构建 SA-MoE 本身不需要新增主干参数。两者保留各自的 RoPE 设置，但共享全局 token index。S9

这也是作者把 speech 与 text 合成一个专家、vision 与 action 合成另一个专家的原因：前者尽量继承 Llama 的语言能力，后者尽量继承 Emu3 / UniVLA 的视觉—动作能力。论文的三专家消融显示，继续把 speech/text 或 vision/action 拆开并没有带来稳定收益。

推理时，一秒钟内实际发生什么

可以顺着一个“机器人一边放碗、一边回答问题”的时间块看：

Mamba encoder 增量编码这一秒新到达的语音，得到 5 个 speech embedding。

系统抽取当前前视图和夹爪图，视觉 tokenizer 将两张图变成离散 token。

SA-MoE 对“语音 → 图像”做 causal prefill，把两种专家产生的 K/V 写入同一缓存。

Speech Expert 自回归生成最多 8 个 text token；若听到普通问题就回答，若无人说话则生成 <silence>，若听到打断命令可生成 Action Cancelled。

文本 hidden states 同时送往 CosyVoice 条件接口，生成该段话的 speech codec。

插入 <boa> 后切换到 Action Expert，自回归生成 FAST action token。动作专家能看到本块文本，因此可以区分“继续动作并回答”和“停止动作并确认取消”。

这里的“同时说和做”是同一时间块上的并发输出语义，不意味着 GPU 在一个瞬间并行采样两串 token。公开参考实现仍按“文本在前、动作在后”的块内顺序解码；随后语音和动作覆盖同一个输出时间段。固定顺序换来的好处是因果关系明确，代价是动作必须等本块文本决策完成。

ELLSA 对不同历史采用不同保留策略：语音输入与文本输出保留完整会话历史，以维持对话连贯；视觉与动作只保留最近两秒，避免每秒数百个图像 token 让上下文迅速膨胀。这不是把过去画面“总结”进一个专门记忆模块，而是直接承认具身控制更依赖近期观测，语言对话更依赖长期历史。S9

两个专家怎样训练到能彼此读懂

ELLSA 不是把 Llama 和 Emu3 拼起来后直接端到端全量训练，而是分三阶段降低能力互相覆盖的风险。S9

第一阶段：分别建立专家。 Mamba speech encoder 先在 LibriHeavy 与 GigaSpeech 上预训练 300k steps；随后连接 Llama-3.1-8B，在 ASR 和 speech QA 上训练 40k steps，此时只训练连接器和 Llama LoRA，encoder 与 Llama 主体冻结。Action Expert 则直接继承 UniVLA：其 Emu3-Base 已经过 world-model post-training 和 policy learning，最后 1,024 个词表位置被替换成 FAST action token。

第二阶段：训练 SA-MoE 的跨专家协作。 两个专家都挂 rank 256、scale 1.0 的 LoRA，在 ASR、语音问答、语音条件机器人控制、边说边做、场景问答、错误指令拒绝和 action barge-in 的混合数据上训练。论文配置为 batch size 1024、学习率、500 steps。输入 speech embedding 和 image token 的 label 被 mask，只监督模型应该生成的 text 与 action token。S9 S22

公开实现将主损失写成按有效 token 数归一化的两路 next-token cross-entropy：

其中：

和分别是未被 -100 mask 的文本与动作位置；对应代码里的 action_loss_weight。关键不只是“同时有两个 loss”，而是两路梯度都要穿过共享的跨专家 attention 信息流：文本 loss 会迫使 Speech Expert 学会读取视觉 K/V，动作 loss 会迫使 Action Expert 学会读取语音和文本 K/V。

第三阶段：接入语音生成。 主 SA-MoE 冻结，随机初始化的两层 connector 把 Speech Expert hidden states 投到 CosyVoice2-0.5B 的输入空间，只微调 synthesizer 的 language-model 部分。此时优化目标切换为 speech codec 的生成 loss：

论文配置训练 20k steps。公开代码在这一阶段把原 SA-MoE loss 乘零，只保留 CosyVoice 返回的 codec loss，因此“会不会说、做什么”与“声音怎样合成”在训练上也是分开的。S9 S22

为什么选择一秒，而不是更细的时间块

一秒块看起来不够“实时”，但它是语音响应速度和动作连续性之间的折中。论文在 A100 上测得一秒配置每块 speech-to-speech 约 854 ms、speech-to-action 约 786 ms，能在下一块到来前完成。作者也训练了 0.48 秒版本：语音每块改成 4 个文本 token，动作改成 5 帧，延迟降到约 455 / 428 ms；但动作专家的 LIBERO LONG 成功率从 94.0% 降到 81.0%，整套 SA-MoE 的 LONG 成功率从 84.4% 降到 71.6%。作者推测，动作片段太短会削弱时间连续性。S9

这个消融揭示了 ELLSA 与视频聊天模型不同的实时约束：聊天模型通常希望块越小越好，机器人策略却需要一段足够长的 action chunk 才稳定。块长度不是纯粹的系统延迟参数，它也改变了学习目标。

这条路线解决了什么，又没有解决什么

ELLSA 真正解决的是：多输入、多输出怎样共享一条因果状态，同时避免每个 token 都穿过全部模态参数。 对具身系统，它允许语言专家和动作专家分别继承已有能力，再通过统一 K/V 时序学会协作。

但它还不是高帧率视频理解方案。默认每个相机每秒只取一帧，适合桌面操作、慢速导航和状态问答，不足以捕捉快速手势或细粒度运动。图像 token 也远多于语音 token：论文估计一张图约 300 token，而十秒语音只有约 50 个 token，这种长度失衡会让跨模态对齐偏向视觉。SA-MoE 合并后，相比独立专家，论文报告 speech 与 action 性能仍分别有约 10.3% 和 6.4% 的相对下降。S9

项目在 2026 年 4 月公开模型与推理代码，仓库采用 Apache-2.0；但官方 README 仍将完整训练支持列为待办，当前代码更适合复现实验和理解架构，而不是直接作为成熟的实时机器人 serving stack。S10 S22

八、路线六：原生因果 AV2AV，让输出视频进入同一条时间线

前面五条路线的输出主要是文本和语音。Wan-Streamer 把问题推到更难的一层：模型除理解用户音视频之外，还要连续生成自己的声音、画面和行为。S11

v0.1：单 Transformer 混合离散文本与连续音视频 latent

Wan-Streamer v0.1 使用严格因果的音频 / 视频 VAE、encoder 和 decoder。时间被切成 160 ms 单元，目标输出视频为 25 FPS。S11

在同一个 Transformer 内：

文本是离散 token，用 next-token prediction；

音频和视频是连续 latent，用联合 conditional flow matching；

输入、历史输出和当前待生成 latent 通过 block-causal attention 连接；

一旦当前块完成生成，其 clean latent 会被提交到历史，供下一块条件化。

这与“LLM 先写文本—TTS 合成声音—数字人再驱动嘴型”有本质差异。后者是串联流水线，前一阶段的延迟会累积，且视频动作只被动跟随已确定的语音；Wan-Streamer 让声音和画面在同一生成状态中共同演进。

为什么要用 flow matching，而不是把视频全离散化

视频若全部变成离散 token，25 FPS 输出会形成极长序列；连续 latent 更适合保留细节，但每个块需要多步去噪。Wan-Streamer 用三阶段训练降低这个成本：

文本、音频、视频能力分别预训练；

用双工互动数据训练共同的流式行为；

用更多 solver steps 和 classifier-free guidance 的教师蒸馏出更快的学生，并通过 rolling distillation / self-forcing 缓解训练与自回归推理的分布差异。

这里的难点已经不只是 token 数，而是必须在下一个 160 ms 截止前完成当前块的多步连续生成。

v0.2 / v0.3 的 Thinker–Performer：训练是一个模型，部署才拆成两条计算路径

图 6：本文根据 Wan-Streamer v0.2 Figure 2 重绘，v0.3 原样继承这套部署流水。单 GPU Thinker 在处理当前输入 和更新 的同时，解码上一块 ；多 GPU Performer 并行生成当前块 latent。

先明确一个边界：Thinker 和 Performer 不是两套分别训练、用文本协议串起来的模型。Wan-Streamer 训练时仍是一个端到端 Transformer；只有实时 serving 时，才按照计算特征把同一模型拆成单 GPU Thinker 和多 GPU Performer。v0.3 没有重新设计这套部署拓扑，而是完整继承 v0.2。S12 S23

Thinker 负责延迟敏感但序列较短的路径：

用因果 audio / video encoder 编码当前 160 ms 用户输入；

运行较短的 token-causal Transformer pass，更新语言、行为和交互状态；

为每一层产生本块新增的、Performer-compatible K/V slice；

接收 Performer 上一块返回的 clean audio / video latent ；

用因果 decoder 把解码成可以立即发送的 RGB 帧与音频波形。

Performer 只负责计算最重的 latent generation：

接收 Thinker 刚生成的，写入各 GPU 已经预分片的历史 KV Cache；

用 conditional flow matching 为下一输出单元迭代去噪；

将高分辨率 video latent 的长序列切到多个 rank 上，执行 Ulysses-style context parallel attention；

生成完成后把 clean latent 交回 Thinker，而不是自己做最终像素与波形解码。

两者之间真正传输的主要是：

语言与行为 token 不需要作为另一条长序列发送给 Performer，因为它们已经被折叠进 Thinker 构建的 K/V 条件。边界因此比“LLM 输出一大段 prompt，再交给视频模型”紧凑得多。

Ulysses 并行到底并行了什么

640×368 视频的 latent 序列明显长于同一 160 ms 内的音频 latent。v0.2 / v0.3 因此只对视频序列做 context parallel：每个 Performer rank 保存一部分预分片 KV，并持有当前 video latent 序列的一段；attention 前后通过 Ulysses all-to-all / gather 交换所需分片，使一次去噪 step 能利用完整上下文。音频 latent 很短，若也切分，通信开销可能比计算收益更大，所以保持不分片。S23

这里的并行对象不是“四帧分别给四张卡生成”。160 ms 在 25 FPS 下恰好对应约 4 帧，但视频帧已经编码成一条联合 latent sequence；Ulysses 沿这条序列分片，并在 attention 内交换信息，所以跨帧运动和音视频条件仍处于同一次联合生成中。

相邻三个时间块怎样重叠

把图中的 unit 展开，会看到三项工作同时发生：

Thinker 编码当前用户输入，并将新增语义写成；

Thinker 解码 Performer 已经完成的上一响应 latent ，立即对外播放；

Performer 用和历史 cache 去噪生成下一响应 latent 。

到 unit 时，被送回 Thinker 解码，Performer 已经开始算。因此，系统不是按下面的串行路径运行：

而是形成跨块流水：

实时吞吐的硬约束是 Performer 计算、Thinker–Performer 传输和 Performer 组内通信必须大体装进一个 160 ms cadence；否则未完成的 latent 会逐块积压。端到端 signal-to-signal latency 则从可用开始，经过编码、状态更新、latent generation 和解码，到对应响应可以发送为止，论文报告约 200 ms。两者不矛盾：160 ms 是稳定流水的吞吐节拍，200 ms 是一个信号穿过整条流水线的延迟。S23

v0.3：把长期不变的 World 与不断变化的 Event Stream 分离

图 7：本文根据 Wan-Streamer v0.3 Figure 2 与 World–Event formalization 重绘。角色、场景、声学与音色等持久 World context 只预填一次，之后每个时间块持续追加用户输入、语言形式的事件和同步音视频 realization。

v0.3 将条件分成两类：

World：场景、角色身份、外观、音色、声学环境等长时间稳定的信息；

Event Stream：用户当前声音、画面、行为文本和即时事件。

World 可以写成一个字段可变的结构化记录：

其中可以包含 scene、layout、character identity、appearance、persona、ambient sound 和 voice timbre。它不是每 160 ms 重复拼进 prompt，而是在会话开始时 tokenization 并 prefill 一次。官方 v0.2 演示页给出的部署口径是 Thinker 与 Performer 都会完成场景 prefill，约 0.5 秒后新场景进入实时状态；v0.3 延续这条机制，只是 World 描述比早期单一角色 prompt 更结构化。S12 S23

随后，每个时间局部事件写成：

是事件生效区间，指向 World 中的角色或“无角色”事件，用自然语言描述说话、动作、镜头移动、环境变化或声音。多个事件可以时间重叠，例如一个角色边说话、边转头，同时背景里有门关闭。

流式生成的概率分解为：

其中是到当前为止的用户文本、音频和视频。离散的语言与行为 directive 继续做 next-token prediction；连续的 audio / video latent 在同一个 clean context 下做 conditional flow matching。当前块得到的 clean latent 会提交回历史，下一块不仅能看到用户做过什么，也能看到智能体自己上一刻的表情、姿态和声音。S12

World/Event 怎样落到 Thinker–Performer 上

World/Event 是建模语义，Thinker/Performer 是部署切分，两者并不是平行的四个模块。对应关系可以这样理解：

状态	会话中怎样更新	主要落点
World tokens	建立会话时 prefill，之后通常不重复编码	Thinker 的 token/state history；对应 K/V 同步到 Performer cache
用户 Event 输入	每 160 ms 由新文本、音频和视频追加	Thinker encoder 与 token-causal pass
语言形式的 agent event	Thinker 预测说话内容和行为 directive	Thinker 的语言/状态流，并写入新增 K/V
Audio/video realization	Performer 根据 World、历史和 flow-matching 生成	Performer latent path；完成后交回 Thinker 解码

因此，World“只 prefill 一次”并不意味着 Performer 后续不再使用它。World 的影响已经固化在双方的前缀 KV Cache 中；每个新块只需传播增量，而不是重新传整份角色和场景描述。

自由行为为什么没有引入新的慢路径

v0.3 不建立一个单独的动作规划器，而是在智能体语言流里交错两类 token：

括号内是开放词表行为，括号外是真正说出的内容。Thinker 在同一 token-causal pass 中预测二者，它们一起进入；Performer 随后把“拿杯子、望向窗外”和“说出这句话”共同渲染成同步音视频。因此行为不是 TTS 完成后再由动作模型补上的后处理，也不需要新增一条 latency-critical RPC。S12

模型输出仍为 640×368、25 FPS，每 160 ms 一个同步音视频单元。v0.3 改变的是预训练目标和表达空间，而不是 v0.2 已经确定的分辨率、时间块和 Thinker–Performer serving topology。S12

这个设计揭示了长时视频交互的另一条主线：不要把“这个角色长什么样”和“他此刻抬起了左手”以同样频率重复编码。持久世界与瞬时事件分离，既节省上下文，也减少角色漂移。

原生 AV2AV 的代价

Wan-Streamer 接近能力阶梯的 L3，但成本最高：

训练数据必须包含同步输入输出音视频和自然重叠；

因果视频 decoder 的画质与延迟直接冲突；

任何流式误差都会进入历史并持续累积；

打断不再只是停止音频队列，还要安全终止视频 latent 并重建动作连续性；

服务端必须同时满足高吞吐 Transformer 与低尾延迟 flow solver。

因此，原生 AV2AV 不会立刻替代语音输出型 Omni 模型。它更可能先用于虚拟角色、远程呈现和高价值陪伴，再逐步下沉。

九、模型之外：实时视频最终是 RTC、推理服务与反馈控制的共同问题

图 8：生产系统参考架构。模型侧首包只是总延迟的一段；终端采样、网络、排队、播放缓冲和打断清理同样决定体验。

把模型部署成一个 WebSocket endpoint 只是起点。端到端延迟可以粗略拆成：

如果用户在模型说话时打断，还要加上 VAD / 语义判断、服务端 cancel 传播、客户端播放队列清空和回声闭环隔离。

Artic：传视频不是为了好看，而是为了让模型答对

传统 RTC 的 ABR 主要优化分辨率、帧率、卡顿和 VMAF。视频助手的接收者是模型：有些区域即使人眼觉得模糊，模型仍能答对；另一些看似轻微的压缩却会抹掉标签、手势或工具细节。

Artic 提出两类机制：S13

ReCapABR：根据模型“回答能力随码率何时饱和”来限制视频码率，为网络波动留出余量；

ZeCoStream：利用模型反馈定位与当前回答相关的区域，客户端在低带宽时调整量化参数，把比特留给关键区域。

作者在 DeViBench 上报告，相比基线准确率提升 15.12%，延迟降低 135.31 ms。S13 这仍是特定数据集与网络轨迹下的结果，但方向很重要：未来的视频传输控制目标会从“像不像原视频”转向“足不足以支持当前决策”。

这里也有明显风险。模型此刻认为不重要的区域，可能在十秒后变成推理关键。因此 ZeCoStream 只在带宽紧张时激进压缩，并需要保留足够的未来上下文。

vLLM-Omni：接口流式不代表计算增量

vLLM-Omni 的 Streaming Video API 提供 /v1/video/chat/stream WebSocket endpoint。客户端可发送 base64 JPEG/PNG 帧和可选的 16 kHz PCM 音频，服务端返回 text / audio delta；还可用 EVS 阈值过滤近重复帧。默认每次使用 4 帧，最大缓冲 50 帧。S14

但当前文档明确指出：session KV reuse 与 incremental prefill 尚未实现，每次 query 会从缓冲的帧和音频重建 prompt。S14

这正好提供了选型时必须追问的边界：

帧是到达即编码，还是提问时统一编码？

同一帧会不会在多次 query 中重复 prefill？

长会话显存随时间怎样增长？

相似帧过滤发生在解码前还是视觉编码后？

多租户 batching 会不会破坏每个会话的时间节奏？

如果这些问题没有答案，“支持流式视频 API”仍不能推导出稳定的低延迟。

百度智能云 RTC：生产链路会保留级联系统

百度智能云的多模态互动 RTC 将端侧 SDK、云端 RTC、降噪 / 分离 / 声纹 / VAD、智能打断，以及 ASR—LLM—TTS 或多模态模型连接成一套服务；产品页还强调智能抽帧，并支持文本、图片、语音流、视频流输入。S15

这代表另一种务实路线：生产系统不会因为端到端 Omni 模型出现，就立刻删除所有可观测、可替换的组件。级联链路在很多场景仍有优势：

ASR 文本便于审计、检索和规则控制；

独立 VAD 与打断模块更易调参；

TTS 可稳定复用品牌音色；

视觉模型只在必要时唤起，控制 GPU 成本。

厂商给出的 1.4 秒语音端到端和 0.8 秒内打断属于产品侧口径，应该在自己的地区、网络、并发与终端设备上复测。S15

十、训练数据与评测：今天的瓶颈越来越不像“模型不够大”

流式数据不能由离线问答直接替代

离线 VQA 常见格式是“完整视频 + 问题 + 答案”。全双工训练至少还需要：

每段输入的真实时间戳；

模型应该沉默的区间；

主动开口的触发点；

用户和模型重叠说话；

用户中途打断；

说到一半发现新视觉证据后的修正；

输出语音、动作或视频的同步轨迹。

ROMA 用主动、旁白和反应式数据训练时机；DuplexOmni 专门合成 overlap、silence、supplement、interruption 和 delayed thinking；Wan-Streamer 还要构造双向同步音视频。三者的共同结论是：轮次和时间本身就是监督信号。

只测“视频问答准确率”会掩盖两类崩溃

VideoFDB 收集 237 段双人互动片段，覆盖 11 类非语言动态，用来评估 AV2AV 全双工会话代理。作者将其称为首个面向该任务的视听全双工 benchmark。S16

论文观察到两种典型失败：

captioning collapse：模型不断描述画面，而不是参与对话；

visual-stream ignorance：模型在显式 VQA 时会用视觉，一进入持续对话就主要依赖音频，忽略正在变化的画面。

这说明“单轮问图能答对”并不等于“长会话里会持续看”。真实评测至少要分开测：

维度	应测问题	常见错误
时间定位	能否把声音与同一时刻动作关联	用错帧、提前使用未来信息
持续视觉	没有显式提问时是否仍跟踪画面	只听音频、视觉状态停滞
响应时机	该沉默时沉默，该提醒时提醒	抢话、漏报、机械等 VAD
打断恢复	被插话后能否停止并续接	旧音频继续播放、重复回答
长时一致性	数分钟后是否记得对象与位置变化	KV 膨胀、身份漂移、背景重算
弱网鲁棒性	降帧、丢包、抖动时是否保住关键判断	画面虽流畅但答案错误
输出同步	语音、字幕、动作、视频是否同拍	口型和语义错位、动作滞后

延迟指标必须写清计时边界

目前论文里的 latency 可能分别指：

单个多模态单元编码耗时；

最后一个输入包到首个文本 token；

最后一个输入包到首个 codec token；

服务端收到数据到首个可播放音频块；

包含网络的用户端到用户端；

平均值、P50 或 P95；

单并发或满载。

因此，本文没有制作“谁最快”的排行榜。一个更有用的实验表应该同时报告：硬件、输入帧率与分辨率、音频块长度、并发、上下文长度、首文本、首音频、RTF、P95、网络与播放缓冲。

十一、横向比较：六条技术路线分别在优化什么

图 9：主流方案的差异可以理解为“把可流式性插在哪一层”。现实系统通常同时采用其中两到四层。

路线 / 代表项目	视频怎样进入	状态怎样保留	谁决定何时响应	输出	最强项	主要边界
客户端采帧：Gemini Live、Qwen Realtime	JPEG，通常 ≤1 FPS	云端有状态会话，内部细节不完全公开	VAD / 语义 VAD / 服务事件	文本、语音	产品化快、带宽低	快速动作与细粒度视听同步不足
分块编码：Qwen3.5-Omni	动态 FPS 视觉 + AuT 音频 token	chunked prefill、Hybrid Attention MoE、长上下文	模型与服务控制	文本、流式语音	统一理解、强通用能力	公开服务仍可能限制到稀疏帧；不输出视频
共享时间轴：MiniCPM-o 4.5	压缩视觉 slice + 10 audio token/s	Omni-Flow、streaming prefill、KV	Listen–Speak 控制	文本、语音	开源、状态边界清晰、可边缘化	视觉帧率和窗口粒度仍有限
显式触发：ROMA	每秒单元、2 FPS	chunked TMRoPE、持久 KV	两层 Speak Head	文本、语音	时机可单测、改造成本低	触发粒度粗，复杂重叠仍靠系统
异步思考：DuplexOmni	连续音视频进入 Interaction Model	前台交互状态 + 后台思考反馈	时间片控制与 Interaction Layer	文本、语音	深推理不阻塞即时回应	35B、硬件重、公开版本仍有沉默与音质问题
模态专家：ELLSA	每秒一帧 + 一秒语音	共享 attention / KV，模态专家分算	`<silence>` 与流内生成	文本、语音、动作	具身 MIMO、模块可替换	视频稀疏，专家边界可能限制细粒度融合
原生 AV2AV：Wan-Streamer	因果音视频 latent，160 ms 单元	block-causal attention、历史 clean latent、World/Event	单模型内生控制	文本、语音、25 FPS 视频	输入输出音视频在同一时间线	训练、推理和部署成本最高

这张表也说明，“哪一个项目最好”没有统一答案。不同场景真正需要的能力不同。

如果做手机或网页视频助手

优先从 L1 开始：WebRTC / WebSocket + 连续音频 + 自适应 JPEG 采帧。先建立端到端延迟和视觉采样收益曲线，再决定是否需要模型内部增量 prefill。Gemini Live 或 Qwen Realtime 一类托管服务适合验证产品。

关键投入不应只是 prompt，而是：

运动和语义共同驱动的采帧；

客户端时间戳；

打断队列管理；

每一段延迟的埋点；

视频缺帧时的降级行为。

如果做本地或私有化实时助手

MiniCPM-o 4.5 的接口形态更值得参考：将输入摄取与输出生成显式拆开，持续维护 KV。若现有 Omni 主干已经稳定，ROMA 式 Speak Head 是加入主动性的低风险方式。

不要一开始就追求原生 25 FPS。先验证 1—2 FPS 是否覆盖任务；对真正需要高速视觉的局部模块，可外挂轻量追踪器、姿态模型或事件检测器，把结构化结果作为高频流送给主干。

如果做机器人

ELLSA 的模态专家和共享注意力适合动作空间复杂、模块需要替换的系统；MiniCPM-o / ROMA 更适合以语言交互为中心的设备。安全控制仍应留在独立的确定性回路，不能让大模型的 1 秒时间窗直接承担毫秒级制动。

如果做虚拟角色或远程呈现

Wan-Streamer 的 World / Event 分离和 Thinker–Performer 流水线是更接近目标的架构。若成本暂时不可接受，可以采用过渡方案：Omni 模型流式输出语义和语音，低延迟表情 / 动作模型消费同一时间戳流。但要清楚，这仍不是原生 AV2AV，打断时需要跨组件回滚。