IBC 2026 | 面向实时视频的低延迟交互系统
内容提要
本文提出一套低延迟边云系统，集成六种流式视频VLM后端，共享ASR/TTS与统一编排，支持实时语音交互。实验显示，在合适后端与WebRTC传输下，首句VLM文本延迟约0.9–1.0秒，首段TTS音频约1.3–1.5秒。研究表明实时视频理解是分层系统问题，VLM到TTS交接尤为关键，低首token延迟并不保证快速语音响应。
延伸解读
系统架构：边云协同与统一运行时
文章提出的边云系统采用服务器为中心的架构，客户端仅负责采集、发布和播放，云端统一处理会话、ASR/TTS和VLM推理。这种设计将异构后端适配和传输归一化，使不同VLM后端能在同一语音使能运行时中比较。共享ASR/TTS服务（Qwen3-ASR-1.7B和Qwen3-TTS-12Hz-1.7B-Base）确保后端比较不受各自语音栈干扰，为部署导向的评测提供了可复现基础。
延迟瓶颈：VLM到TTS交接比首token更关键
实验显示，ASR最终延迟和TTS首包延迟在各后端间接近（ASR 80–98ms，TTS 196–215ms），差异主要来自准备时间、VLM首token延迟和VLM到TTS交接。ViSpeak、InfiniteVL、AURA和MiniCPM-o的首音频在0.82–1.13秒，而FluxMem和MMDuet2分别高达4.93秒和17.39秒。这表明低TTFT并不保证快速语音响应，VLM到TTS的交接是影响用户感知延迟的关键环节。
传输协议选择：WebRTC显著优于RTSP/WS
在传输层对比中，WebRTC的视频延迟稳定在几十毫秒量级，而RTSP/WS的视频延迟在半秒左右，音频趋势相同。客户端在环实验进一步显示，WebRTC路径下三种终端（Android手机、PC、智能眼镜）的VLM首文本延迟为920–982ms，首非静音TTS音频为1.26–1.53秒；RTSP/WS则分别推高至1.18–1.19秒和1.88–2.16秒。由于服务端流水线未变，差异主要来自端点检测、缓冲、媒体交付、解码和播放。
模型能力与交互行为：实时理解易，回溯与主动响应难
引用OVO-Bench和StreamingBench分数显示，AURA在开源模型中整体表现最好（OVO-Bench ALL 65.3，StreamingBench ALL 73.1），ViSpeak和MiniCPM-o接近，专有模型GPT-4o和Gemini-1.5-Pro更高。在相同视频和触发条件下，六个后端对当前场景的实时理解均能支持，但回溯记忆、主动响应和多响应暴露较大差异。例如MMDuet2默认0.5fps采样可能漏掉短时动作证据，在多响应案例中未产出有效输出。
Q&A
这套低延迟边云系统集成了哪些视频VLM后端？
系统集成了六种具有流式或交互能力的代表性视频VLM后端：AURA、InfiniteVL、FluxMem、MiniCPM-o、ViSpeak和MMDuet2。
在合适的后端和WebRTC传输下，系统的延迟表现如何？
在合适的后端选择与WebRTC传输路径下，系统达到约0.9–1.0秒的首句VLM文本延迟和1.3–1.5秒的首段非静音TTS音频延迟。
为什么低首token延迟不一定能保证快速的语音响应？
因为对于语音反馈系统，VLM到TTS的交接尤为重要。即使VLM首token延迟低，如果VLM到TTS的交接环节耗时较长，整体语音响应仍会变慢。
系统在传输协议延迟方面，WebRTC和RTSP/WS有何差异？
WebRTC的视频延迟稳定在几十毫秒量级，而RTSP/WS的视频延迟在半秒左右；音频趋势相同。文本在两条路径下均很低。实际交互路径主要使用上行视频、下行文本和双向音频，因此WebRTC在视频项上的优势直接转化为用户可感知的延迟降低。
客户端在环实验中，不同终端和传输方式下的延迟有何不同？
以MiniCPM-o为后端，WebRTC路径下三种终端（Android手机、PC、智能眼镜）表现接近：ASR最终文本272–290ms，VLM首文本920–982ms，首非静音TTS音频1.26–1.53秒。RTSP/WS将这些数值推高至ASR 555–568ms、VLM首文本1.18–1.19秒、首非静音音频1.88–2.16秒。差异主要来自端点检测、缓冲、媒体交付、解码和播放。
不同VLM后端在交互行为（如回溯记忆、主动响应）上有何差异？
当前场景的实时理解各后端均能支持，但回溯记忆、主动响应和多响应暴露了较大差异。例如MMDuet2虽为交互响应时机设计，但其默认0.5fps采样可能漏掉短时动作证据，在多响应案例中未产出有效输出。
