JoyAI-VL-Interaction:实时视觉-语言交互智能 JoyAI-VL-Interaction: Real-Time Vision-Language Interaction Intelligence
8B视觉交互模型,每秒自决说话、沉默或委派后台
前置知识
交互模型 (Interaction Model)
与回合制不同,交互模型在持续视觉流中每秒自主决定是否发言、何时发言、何时沉默、何时把难题交给后台,模拟人在场式的协作。
本文核心论点:'何时回应'必须作为模型可学习的能力,而非外置计时器或轮询,理解后续设计与评测都建立在此概念上。
AdaCodec / 预测式视觉编码
源自视频编解码与预测编码,仅对参考帧用全量 ViT token,可预测帧只编码运动向量与残差(约 16 token),场景变化时插入新参考帧。
把长视频 token 预算从'随帧数线性增长'变成'随场景变化缓慢增长',是模型连续运行多小时而 token 不爆的关键工程基础。
时间对齐监督 (Time-aligned supervision)
对流式数据每秒打上 、、delegate 三类标签,让沉默成为一等动作;用加权 SFT(沉默 0.4、响应 1.5)抑制沉默主导造成的梯度偏向。
把'什么时候说话'变成可学习监督目标的桥梁,没有它模型就无法从数据中学到主动响应的时间感。
GRPO + answer-centered 窗口采样
GRPO 直接优化每秒的策略,针对正确且落在窗口内的回答、合时的沉默、合时的委派发放奖励;用 answer-centered 采样把无关沉默压缩掉。
token 级 SFT 学不到精微的时机选择,正是 GRPO 把'在正确的秒数发声'的能力推到可用阈值。
vLLM 前缀复用 (Prefix reuse)
把分块摘要文本预填进 KV 缓存,每秒推理只重算新增帧与上一回复,过去 chunk 的摘要被引擎复用,使小时级视频仍可亚秒延迟运行。
没有它再聪明的模型也无法在 vLLM 上稳定实时部署;论文'2 小时亚秒延迟'数据的工程底座。
研究动机
现有大模型基本都是回合制:用户说话才回答,等级再低也只是把回答做得更快,无法对画面里'还没人开口'的事件主动响应。论文给出三条证据:其一,GPT-Realtime-2、Qwen3.5-Omni 等原生端到端 omni 模型仍围绕对话轮流;其二,豆包 app 视频通话靠外部定时器每隔几秒轮询一次,但核心仍是 turn-based,反应永远慢于轮询间隔,5 分钟无语音会自动挂断;其三,Gemini 视频通话甚至不轮询,仅在问题被提出的那一帧作答。流式视频理解研究则多停留在实验室阶段:响应性、主动响应、长时记忆多单独推进一项,用离线 benchmark 评估,鲜有人把三者装进可部署系统。真实场景里'摔倒立即报警'、'购物页面出现目标商品时插话'等动作,结构性地被现行设计错过。
本文的目标是目标是打造一个真正'在场'的视觉驱动交互模型,让'什么时候行动'成为模型每秒学到的内部决策,并把'说话/沉默/委派'三类动作视为同等的一等公民。具体而言,作者希望发布三件事:(i) 一个 8B 量级、以视觉为主驱动、可在消费级硬件本地部署的 JoyAI-VL-Interaction 模型,并完整公开训练配方;(ii) 一个开箱即用的完整系统,包含可插拔 ASR/TTS、可视化 UI、长时记忆、vLLM 服务路径以及连接任意 background 的桥接层;(iii) 六类现实场景的 head-to-head 人评数据,证明其在事件驱动设定下对豆包、Gemini 视频通话助理有明显优势。最终实现'我回到家累垮了,有人在你开口前说句你看起来很累'这样的共在式体验,让模型从'被调用的工具'转向'在场的参与者'。
与已有工作不同的是,切入角度是把'何时行动'上升为可独立学习的能力,并在开放形态中同时交付模型、训练配方与可部署系统。区别于豆包以时钟轮询堆在 turn-based 核心之外、区别于 GPT-Realtime-2 / Qwen3.5-Omni 以对话轮流为优化目标、区别于 Thinking Machines Lab (TML) ~276B MoE 把音频与视觉一并融合并把 speech 锁进模型;本文坚持以视觉为第一驱动、speech 作为可插拔 I/O,保持 8B 紧凑规模可本地运行,并首次公开发布包含数据配方与可部署系统的完整栈。文献层面的三重缺口——'一项指标单独推进'、'离线 benchmark 评估'、'只停留在模型本身'——被同时回答。
核心方法
JoyAI-VL-Interaction 以 Qwen3-8B 的语言部分与 Qwen3-VL 的 ViT 为底,新增投建适配器得到 JoyAI-VL 1.0 作为初始包;视频帧用 AdaCodec 编码为'参考帧 + 16 token 预测帧'混合流,使 token 预算随场景变化而非帧数线性增长。在每一秒模型在三种动作中选一:以 保持沉默、以 生成回复、或以委派协议把难题扔给后台异步模型并继续在场。训练分两阶段:先用包含多类数据加权 SFT(沉默 0.4、响应 1.5、其余 1)让模型区分三类动作;再以 GRPO 在 answer-centered 窗口轨迹上对时机、沉默、委派质量发放奖励。系统外圈用可热替换的 ASR/TTS、可视化 UI、三层记忆 $T_s=100\text{s},M=5,L=15$ 封装约 2 小时上下文,在 vLLM 上复用 KV 前缀实现亚秒级端到端延迟。
核心创新在于把'何时行动'与'说什么'合并为同一可学习决策的三元组。技术上分三层:(i) 动作形式上让沉默成为与响应同等的一类 token,并用加权 SFT 抑制沉默对梯度的支配,让模型不会退化为'一直说话'或'一直沉默';(ii) 时机监督上用 6 类、4M+ 条时间对齐数据(包括三种 timing 的 QA、计数、评论、警报、委派回合),以双层 verifier 同时校验全局内容与触发帧的正确性;(iii) 委派协议上让模型发出隐藏委派 token 与查询,在画面持续流动的同时可由用户接入任意后台模型/agent。和已有方法最本质的区别是:在 turn-based 系统中几秒钟动作由外部时钟决定,在 TML 系统中由大的音视觉 MoE 内部决定,而在本文中由一个紧凑的、视觉优先、以秒级决策为目标的 8B 模型决定,并将整套决定路径完整开源。
方法步骤详情
训练与部署分五步。第一步,建立基础:JoyAI-VL 1.0 由 Qwen3-8B + Qwen3-VL ViT + 投影层从头组成,经表示对齐与 RL 作为初始 VLM。第二步,构建数据:构造 4M+ 时间对齐流数据,覆盖主动警报、三种 timing 的 QA、计数、实时评论、闲聊、委派回合六类,每秒打三类标签并含全局 + 触发帧双层 verifier。第三步,加权 SFT:把以上数据混入 turn-based 数据,损失 $\mathcal{L}(\theta)=-\frac{1}{|A|}\sum_{j\in A} w_j \log p_\theta(y_j|y_{<j})$ 中 $w_j$ 对重复沉默取 0.4、响应取 1.5。第四步,GRPO:以 answer-centered 采样压缩 horizon,对合时的响应、沉默、委派发奖并惩罚虚假警报,LLM judge 补内容分。第五步,部署:vLLM + 三层记忆 $T_s=100\text{s}, M=5, L=15$ 实现 KV 前缀复用;ASR/TTS/UI/background 全部可换,委派用与模型无关的文本协议。
技术新颖性
新颖性从三方面衡量。第一是设计哲学:明确提出'何时行动 = 模型可扩展能力'这一被前者默认隐藏的能力,把内部每秒决策的权重与动作空间摆在算法层面,与 TML、豆包、Gemini 等差异化地提出完整源代码 + 模型 + 训练配方。第二是数据:以 6 类 4M+ 时间对齐样本把'沉默 = 一类动作'而非缺失纳入监督,并以双重 verifier 同时检验时长一致性与触发帧内容,这在公开文献中属首次。第三是工程系统:AdaCodec 把可预测帧压缩为 16 token,vLLM 前缀复用使约 2 小时连续视频仍可亚秒延迟运行;同时论文第一次公开宣布在事件驱动场景下超过豆包、Gemini 两个虽大得多的产品,也第一次公开确认了'能力涌现'——跨应用导购、推项目型评论这些在训练集中不存在的场景也能独立推断出来。
实验结果
论文以 6 场景 58 案例与豆包、Gemini 视频通话助理进行 5 人盲评双轴打分,quality 与 timing 各 3 级。对豆包总胜率 77.6%(损失 5.2%、平局 17.2%),对 Gemini 高达 87.9%(损失仅 1.7%、平局 10.3%)。最强优势集中在'在正确秒数发声'的场景:对两者警报与监控胜率均为 100%;对 Gemini 实时计数、实时翻译、实时评论均为 100%;长时记忆胜率两者均为 77.8%。豆包唯一接近持平的是实时评论与指导 55.6%(豆包胜 22.2%),Gemini 唯一接近的是时间意识 50%(Gemini 胜 10%)。案例分析中,摔倒警报响应、计时烤鱼提示、街道字幕实时翻译等都需要精确时机,'compact 8B vs larger turn-based' 的胜出表明当'时机决策'是原生能力时可补偿其他量级优势。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 整体 vs Doubao | Human pairwise win rate (%) | 77.6% win | Doubao 5.2% win | +72.4 pp 净胜率 |
| 整体 vs Gemini | Human pairwise win rate (%) | 87.9% win | Gemini 1.7% win | +86.2 pp 净胜率 |
| 监控与报警 vs Doubao | 胜率 (10 案例) | 100% win, 0% loss | Doubao 0% win | 全部胜出,无平局 |
| 监控与报警 vs Gemini | 胜率 (10 案例) | 100% win, 0% loss | Gemini 0% win | 全部胜出,无平局 |
| 实时翻译 vs Gemini | 胜率 (10 案例) | 100% win, 0% loss | Gemini 0% win | 全部胜出,无平局 |
| 长时记忆 vs Doubao/Gemini | 胜率 (9 案例 each) | 77.8% win each | 0% win;D 约 5 分钟、Gemini 约 2:15 自动挂断 | +77.8 pp 净胜率 |
| 实时计数 vs Doubao | 胜率 (10 案例) | 70% win, 0% loss, 30% tie | Doubao 0% win | +70 pp 净胜率,无损失 |
| 实时评论与指导 vs Gemini | 胜率 (9 案例) | 100% win | Gemini 0% win | 全部胜出,0 平局 |
局限与改进
作者明确承认三点不足。第一是规模上只有 8B 参数,远小于豆包背后的 Seed 2.0 与 Gemini-3.1-flash-live,常规回合制能力(世界知识、聊天体验、罕见输入稳健性)不及两位对手。第二是数据:尚未调优混合配比、进一步清洗与扩展规模,评论场景较稀疏、紧凑规模模型在该任务上偶尔出现幻觉(被限定为'品质问题'而非时机问题)。第三是评测:仅 6 场景 58 案例,相比最终计划只是初步,作者主动愿在此时发布是为让社区参与到'交互能力如何扩能'的探索中。从独立角度看,评测仅在中文环境与 5 名研究员进行、缺乏英语/多语言/多人口构成,且缺乏与真实延迟与 token 限额的定量指标对比,是值得补充的部分。
独立分析的弱点
独立可观察到的弱点可从四角度概括。第一是案例集中:58 个案例与 5 名研究员盲评对个别示例变动敏感;展示顺序仅随机化、场景未被多次重复;评分三档粒度较粗、'fair' 与 'good' 之间难以区分。第二是品质问题:作者明确承认评论时偶尔幻觉,这在流式场景中比回合制更具杀伤力,需调用更精细的视觉验证器、子句级 timeline grounding、或护栏型外部知识作为补充。第三是委派机制的后台性能未量化:作者只在'手机界面生成 HTML'与'购物里达'中举例,未对委派响应时间、取消成功率、以及不同 background 模型的代价/质量比给出量化指标;同样未给出 GPU 规格、推理吞吐、显存峰值的公开数表。第四是公平性:豆包与 Gemini 仅以'当前应用版本'出现、未通过 API、未受 token 限额、未多语言、未多视频源。
未来方向
作者明示后续工作包含 (i) 调优数据混合并扩充体量、减少评论场景幻觉;(ii) 拉大评估规模与设置、用更细的指标;(iii) 进一步推进交互能力上限。独立可拉伸的方向至少有四类。第一,护栏与安全:单人独居、老人摔倒、繁儿走错场景都需要可审计的安全协议,建议增加运行时护栏、speaker ID、可访问性输入选项与伤害后果责任梳理。第二,多语言与多文化:当前评估仅在中文与中文研究员进行,应以英文、日韩等多语言扩展以检验框架。第三,背景代理生态:委派接口只接文本协议,未与 web 代理、代码执行、机器人控制等深度融合;可在 Hermes Agent、OpenClaw 等可扩展代理上推广。第四,主动评估与测试:58 案例不足以稳定估计长尾表现,建议构建以真实直播/安全联动的事件驱动 server-side 评估,越过离线 benchmark 限制。
复现评估
复现性高:作者公开了 8B 模型权重、时间对齐数据构造流程、训练配方、vLLM 服务路径,以及在 GitHub (jd-opensource/JoyAI-VL-Interaction) 上的可部署系统;项目页面对样例演示、案例视频与评估协议有详细说明。构建需以下步骤:(i) 准备 JoyAI-VL 1.0 权重为初始包;(ii) 采集/筛选符合 6 类别、含双重 verifier 通过的流数据(论文公开流程但未给出完全下载链接,需自行申请或制作);(iii) 在多 GPU 节点上跑 SFT + GRPO(基于 EasyVideoR1),部署在 vLLM 上以小时级 streaming 运行。论文未列出 GPU 类别、参数总量、训练时长与电费,这部分需要从作者发布的 README 中补足。代码门槛主要是 AdaCodec 集成、beam-based 委派跨进程桥接,以及与 live-vlm-webui 的 UI 调控;总体复现难度中等、需准备多台 GPU。
论文图表
展示三个真实场景的实时推理过程:'监控警报'(用户设定警报后模型在着火瞬间发言)、'实时计数多个物品'(边看边数瓶子)、'评论与委派请背景'(用户提出购物评论或 HTML 生成任务时委派后台)。
在一张图里代表多个场景的'问/答/沉默/委派/回流'信息流,是 motivation 与 method 部分的最佳视觉总览。
左侧展示以图片-文本对话为输入、输出 </silence> 或 'The car is moving towards the left.' 的模型架构;右侧展示 AdaCodec:参考帧为完整 RGB、可预测帧为 motion vector + residual,仅需约 16 个 token,使 256 visual tokens 缩减到 16 visual tokens。
同时说明架构与编码器的原始压缩倍率 (16 token vs 256 token),是论文'小时级流式不爆上下文'的关键架构说明。