模型如何边看边听、边回应：实时流式多模态模型技术路线
内容提要
本文调研实时多模态视频模型，提出L0-L3能力分级，区分“支持视频”的四种层次。核心在于“可流式性”插入的层级：客户端采帧、分块编码、共享时间轴、显式触发、异步思考、模态专家或原生AV2AV。文章分析Qwen3.5-Omni、MiniCPM-o、ROMA、DuplexOmni、ELLSA、Wan-Streamer等方案，强调真正的实时取决于状态增量更新、说话时机可学习及音视频因果生成，并给出选型建议。
延伸解读
“实时”的三个层次：传输、推理与交互
文章指出，产品文档常把“低延迟”混为一谈，但真正的实时需要传输、推理和交互三个层面同时成立。传输实时指数据持续抵达；推理实时指新数据增量进入模型状态而非每次重算；交互实时指模型能感知停顿、主动开口并处理打断。因此，接口支持WebRTC或模型声称全双工，都不足以证明端到端体验，选型时需分别验证。
视频输入不等于视频理解：采样策略是关键
文章强调，将摄像头接入模型不等于模型会“看直播”。当前主流方案如Gemini Live和Qwen Realtime，视频被降为每秒不超过1帧的JPEG图片，模型看到的是一串视觉快照，而非连续运动。因此，快速手势、短暂遮挡等细节容易丢失。文章建议，客户端应根据运动幅度、用户指示词等动态调整采样帧率，而非固定1 FPS，这比追求更大的视觉模型更关键。
从L0到L3：能力分级决定应用边界
文章提出L0-L3四级能力分级，区分“支持视频”的不同层次。L0是上传后理解，L1是稀疏视觉流，L2是增量音视频理解，L3是原生全双工AV2AV。不同层级对应不同应用场景：L1适合商品识别、远程协助；L2适合需要持续跟踪的对话；L3则面向虚拟角色等。选型时应根据任务对动作时序和视听同步的敏感度，选择合适层级，而非盲目追求最高级。
延迟指标需谨慎对比：计时边界各异
文章提醒，论文中的latency可能指编码耗时、首文本时间、首音频时间或端到端延迟，且测试硬件、输入长度、并发等条件不同，直接比较数字没有意义。例如Qwen3.5-Omni报告的首包延迟约426ms，DuplexOmni约0.506秒，但两者测量边界不同。建议团队在评估时，要求对方明确计时起点、终点、硬件配置和P95等细节，才能做出有效判断。
Q&A
实时多模态视频模型有哪些能力分级？
文章将实时多模态视频模型的能力分为L0到L3四个等级：L0是上传后理解，即服务端拿到完整视频文件后统一处理；L1是稀疏视觉流，客户端周期性发送图片，音频连续上传；L2是增量音视频理解，新帧和新音频块分块编码，历史状态保存在KV Cache中；L3是原生全双工AV2AV，输入和输出的音视频可以重叠进行，模型能同时生成语音、表情和动作。
为什么说“每秒传一张图”不等于真正的实时视频理解？
因为每秒传一张图只是客户端采帧的稀疏视觉流（L1），模型虽然不断收到新画面，但可能每次都在重建上下文，并不知道两张图之间发生了什么。真正的实时需要模型内部增量更新状态（L2），甚至原生生成音视频（L3），而不仅仅是传输层面的实时。
Qwen3.5-Omni是如何实现流式视频理解的？
Qwen3.5-Omni采用Thinker-Talker架构，视觉和音频编码后进入Hybrid Attention MoE Thinker，通过TMRoPE统一时间坐标，使用chunked prefill增量处理新块，历史状态保存在KV Cache和Gated DeltaNet递归状态中。Talker生成多码本语音token，由因果流式codec decoder输出波形。
MiniCPM-o 4.5的Omni-Flow是什么？
Omni-Flow是MiniCPM-o 4.5实现全双工交互的建模和执行范式，它将输入、控制和输出排列到共享时间轴上，每个约1秒的时间窗内交替执行streaming_prefill和streaming_generate，模型通过生成<|listen|>或<|speak|>控制信号来决定是继续监听还是开口说话。
ROMA是如何解决模型何时开口说话的问题？
ROMA在Qwen2.5-Omni基础上新增了一个小的Speak Head，它是一个两层MLP，与语言模型输出头并行，对最后几层hidden state加权组合，每个流式单元输出一次“触发/不触发”的二分类结果。训练分两阶段：先做流式格式对齐，再用时序BCE损失训练Speak Head，同时保留问答损失。
DuplexOmni如何平衡实时交互与深度思考？
DuplexOmni将实时Interaction Layer与可插拔Thinking Layer解耦。Interaction Layer负责持续听、看、控制节奏并输出文本和语音，Thinking Layer是外接的慢速推理或工具服务。推理时，Interaction Layer每约480毫秒处理一个时间片，需要帮助时向Thinking Layer发送请求，Thinking Layer流式返回中间结果，Interaction Layer始终保留最终表达权。
ELLSA的模态专家是如何共享注意力的？
ELLSA采用Self-Attention Mixture-of-Experts（SA-MoE），Speech Expert和Action Expert各自保留预训练参数，但产生的K/V按原始token顺序进入同一个因果注意力上下文。每个token根据模态边界选择专家计算Q/K/V，但注意力可以读取所有专家写入的K/V，从而实现跨模态信息共享。
Wan-Streamer是如何实现原生AV2AV的？
Wan-Streamer使用严格因果的音频/视频VAE，时间切成160毫秒单元，在同一个Transformer内，文本用next-token prediction，音频和视频用联合conditional flow matching生成连续latent。v0.2/v0.3将模型拆分为Thinker和Performer：Thinker负责编码输入和更新状态，Performer负责生成latent，两者通过K/V切片协作，实现音视频的同步生成。
实时视频系统需要解决哪些关键技术问题？
文章总结了五个关键技术问题：1. 连续视频如何压缩进可承受的token预算；2. 音频与视频如何共享时间轴；3. 历史状态如何保留且不泄漏未来信息；4. 模型何时开口说话；5. 深度思考如何不阻塞自然交流。
如何选择适合自己场景的实时多模态方案？
文章给出了选型建议：手机或网页视频助手可从L1开始，使用Gemini Live或Qwen Realtime；本地或私有化助手可参考MiniCPM-o 4.5或ROMA；机器人场景可考虑ELLSA；虚拟角色或远程呈现可考虑Wan-Streamer；复杂推理与实时对话并重可借鉴DuplexOmni的异步分层。
