StreamEval：交互式流式视频生成评测基准，画质好不等于会执行指令

速览

一、评测对象从「帧好不好看」换成了「中途请求有没有到点生效」

StreamEval 把「交互式流式视频生成」的多任务评测整合成了一套可以横向比较的分数，而它测出来的最关键一条是：画面质量和人物身份保持做得好不好，跟模型能不能可靠执行会话中途到达的请求，几乎是两回事。这个结论来自 37 个模型在 300 条脚本化用例上的成绩单，也是这篇基准论文最值得记住的地方。StreamEval

先说清「交互式流式」到底指什么。它不是「低延迟生成」的同义词，关键语义是模型一边出帧、一边接收会话中途发来的新请求，并据此改变后面还没生成的内容。一次性生成是给一句 prompt 然后等整段视频吐出来，生成过程中没有任何输入。交互式流式则在第 3 秒、第 7 秒、第 12 秒不断有新要求进来，每一条都要求「从此刻起按我说的改」。

论文把每条请求拆成三个必须同时成立的问题：什么时候生效、改什么、什么必须保持。请求迟到不算通过，改动必须落在正确的目标上，非目标内容和源视频本身的运动不能被破坏，撤销类请求还要把状态恢复到当时的源素材。三件事同时成立，才算「执行了一个请求」。这个拆法也是它区别于画质基准的原因：画质指标只看输出画面，看不到请求到达的时刻。

这套评测直到最近才做得出来。2023 年的 StreamDiffusion 已经在 pipeline 层把「边生成边接收输入」做成了实时系统，但它全程零训练、只做流式图像，评测口径里完全没有「请求是否按期生效、非目标内容是否被保住」这类维度。StreamDiffusion 真正的机制难题要到 2025 年的 Self Forcing 才被系统讲清：自回归视频扩散模型训练时看到的是真值上下文，推理时只能依赖自己生成的上下文，两者的分布错配会让误差随生成推进不断累积，长视频越往后越退化。Self Forcing

图注：Teacher Forcing、Diffusion Forcing 与 Self Forcing 三种上下文配置的注意力掩码对照。(a)(b) 都在整段视频上并行训练，用自定义掩码维持因果依赖；(c) 在训练期就做自回归 rollout 并带 KV cache，以镜像推理过程。图中 3 帧 x 2 token 只是示意规模。Self Forcing

这条因果链正好解释了为什么「执行与保持」必须单独成维。训练产物不在推理分布里，模型越往后生成越可能漂移、越可能在响应新请求时破坏已有状态，而这些退化不会体现在单帧画质上。

二、一条用例就是一份带时间表的会话脚本

StreamEval 的一条用例不是一段短视频，而是一份写死了时间表的会话脚本，它预先规定好「到第几秒谁说什么、必须改什么、必须保住什么」。正因为保持要求被写进了用例，基准才能评「请求执行」而不只是「画面好不好」。三个任务族覆盖全部五类任务：avatar 交互（数字人对话、数字人表演）、世界生成、实时视频编辑（指令编辑、参考图编辑），编辑类共用同一段源视频，指令或参考图随时间变化。StreamEval

图注：五任务总览，按三类任务族分区。蓝区是 avatar 交互，含对话与表演；绿区是世界生成，面板下方有一条 0 s 到 10 s 的在线输入时间轴；黄棕区是实时视频编辑，标注共享源视频，指令面板显示 0 s 的哑光黄到 5 s 的哑光紫。StreamEval

五类任务的边界由两条区分轴钉死。对话和表演看回应是否由系统自主生成：对话要求对用户语音给出上下文恰当的回应并维持人设与对话历史，表演只渲染规定好的语音和被要求的视线、表情、姿态、手势。指令编辑和参考编辑看目标外观来自哪里：前者来自文本，后者来自参考图。两类编辑共享同一份契约，改动目标、保留非目标内容与源运动，撤销后要恢复到当时的源状态。

规模在论文里一次性给全。每个任务 60 条用例，15、30、60、120、300 秒五个时长档各 12 条，合计 300 条，跨 240 个独立素材族，含 1,347 个计划内在线事件。一轮跑完 300 条会话代表 525 分钟的实际流式生成量，每个用例每个模型跑三次独立重复。

官方仓库把论文里的用例从叙述落成了文件。cases.jsonl 是输入时间线，oracles.jsonl 记录期望结果与 protected[] 受保护内容，manifest.json 存素材路径与 SHA-256 哈希。oracle 绝不传给被测模型，仓库文档把它升级成硬约束，只有受信调度器能看到完整时间线。仓库实测的 300 条用例、240 个素材族、1,347 个事件与论文口径一致。StreamEval 官方仓库 用例的构造与质检也走了自动化流程：多模态输入由视觉模型和语音模型合成，再按模态分别筛查，包括视觉缺陷检查、语音匹配的 WER 不超过 0.25、时长与冻结帧检查，不合格的进打回重生成再复查的修订回路。

图注：基准构造与验证流程。左栏是输入构造，从场景撰写到多模态输入合成；右栏是自动筛查与发布，按模态检查视觉、语音匹配与媒体，图中包含一条从标记输入到重新生成、复查、保留的修订回路，底部是版本化发布。StreamEval 官方仓库

官方自己给出的硬证据是，公开可读的那批用例里仍有 98 条 oracle 标记为待媒体复核与标定，全部落在 development 层。也就是说这套用例与裁判目前仍在标定过程中，这一点后面还会回到。

三、十项指标分四维，但 Quality 是缺陷等级映射、Stability 被它门控、Overall 还含 +5 接口加分

StreamEval 的分数是一套有明确判定契约的量，不是笼统的「能力分」。十项指标按四个维度组织：任务执行维度含 Dialogue、Following、Edit Success；状态一致性维度含 Stability、Continuity、Preservation；视觉保真维度含 Quality、Identity、Reference；视听协调维度是 A–V Sync。全部归一化到 0 到 100，但读法有几处和直觉不一样。StreamEval

最容易被读错的是 Quality。它不是一个普通画质分，而是裁判缺陷等级的映射：无缺陷、一个轻微缺陷、多个轻微缺陷、一个严重缺陷、多个严重缺陷分别对应评级 5 到 1，最终分等于 25 乘以评级减 1。因此 Quality 75 分的意思是「有一个轻微缺陷」，而不是「画面质量打了 75 分」。

第二个陷阱是 Stability 被 Quality 门控。Stability 衡量的是无严重时序缺陷、至多一个轻微时序缺陷、且 Quality 评级不低于 3 的片段所占的时长比例，因此两个指标口径重叠，高 Stability 同时要求画面质量可接受。

第三个陷阱在 Overall。它是任务级 Q-Overall 加上一个接口加分 B：avatar 任务里支持自定义头像的系统加 5 分，只能用厂商固定头像的加 0 分，所以 avatar 任务的量纲最高可以到 105。这 5 分衡量的是系统能不能接受自定义头像这一接口能力，不会改变底层指标分。聚合链路则是先把同一用例的三次重复取平均，再在每个时长档内对用例取平均，最后对五个时长档等权平均，所以 300 秒的长会话不会按时长比例主导最终评分。还有两条同样影响读数的细则：未决判定记成一个区间、表格取下界，所有计划内的控制机会都留在分母里，包括没被触发的触发器和超出厂商会话上限的控制。

讲解：为什么 Quality 75 分不是画质 75 分

图注：评测工作流三段式。第一段是录制用例与输出帧，第二段是结构化 VLM 观察，分为质量与稳定性、参考匹配、保持三类检查，第三段用固定规则把观察换算成运行级分数，再依次按三次重复、条件、五个时长档聚合，最后得到任务级 Overall。StreamEval

至于裁判可靠性，论文给的是验收标准而非实测值：每类假阳率不超过 5%、假阴率不超过 10%、未决率不超过 10%。外部有量级参照：「把判断锚定在具名视觉准则上」这一类做法里，20 个裁判在 309 题上最强也只有 0.631，机会水平是 0.322，说明换一个更强的裁判模型并不自动变准。VisionQ

四、37 个模型的成绩单：画质与身份保持的高低，和「能否执行请求」并不共变

这张成绩单最反直觉的地方不是某个模型差，而是三个维度几乎不共变：最高画质、最高保持力、最高执行分落在不同模型身上。评测覆盖 37 个模型、47 个任务配置，分布是数字人对话 15、avatar 表演 7、世界生成 17（12 个文本条件加 5 个图像条件）、指令编辑 5、参考编辑 3。两条呈现口径要记住：编辑表只展示 Overall 不低于 5 的配置，且这个子集是评测之后才选定的，存在选择偏差；固定头像系统的 Identity 只能对自身首帧评级。

（以上为论文静态表格 Table 2、Table 4、Table 5 的数值。StreamEval）

表格里的反差很具体。MuseTalk 1.5 的 Quality 和 Stability 都超过 95，A–V Sync 却只有 38.09。LiveAvatar FULL 的 Stability 打到满分 100，A–V Sync 是 0。avatar 表演任务里 Vidu S2 Avatar 的 A–V Sync 高达 99.60、Identity 86.12，Following 却只有 36.90，而这已经是 7 个模型里的最高值。Vidu S2 世界生成中 HappyOyster 的画质与稳定性都是该表最高，Following 与 Continuity 却只有个位数。编辑侧 JoyAI-Video-Edit 的 Preservation 领先全场，Edit Success 只有 43.52。论文摘要给出的三个执行类上限也落在这里：avatar 表演 Following 最高 36.90、文本条件世界生成 Following 最高 25.93、参考编辑 Edit Success 最高 15.00。也就是说，参考编辑这条任务上「完整完成一次编辑」的成功率，全场最好也只有 15 分。

定性上执行失败长什么样，论文用一次参考编辑会话做了实录。参考 A 预加载成红色披风，10 秒时切换到金色缎面披风，20 秒请求撤销。两个 B 阶段输出都保住了底层场景与源运动，但仍然保留原来的灰色披风，没有采用所要求的外观。

图注：参考编辑在输入变化下的实录，三栏分别是参考 A 预加载、参考 B 于 10 秒到达、20 秒请求撤销，每栏把源帧与输出帧按录制时刻配对，放大插图标出披风区域。插图中的披风仍是浅灰白色，与顶部参考 B 小图的金黄不同，说明源运动与场景被保住了但目标外观没被采纳。StreamEval

这些低分不是「画质差」。生成侧的根因是自回归滚动的漂移，误差随生成推进累积，所以世界生成里 Continuity 与 Following 常常同时低。记忆类模型把容量投在几何记忆上，比如 Matrix-Game 3.5 把锚帧、上下文帧、噪声目标帧和记忆 token 塞进同一条带相机位姿的序列，连续性做到最好，但它的请求执行靠段级外部 prompt 改写，模型内部没有一等请求通道。Matrix-Game 3.5 编辑侧的根因是源流漂移，输出既要跟当前源块对齐、又要保住未被编辑目标的身份与运动，这两者在训练目标里是一对需要调的权衡。JoyAI-Video-Edit 两条线都指向同一件事：执行请求不是这些模型的默认能力。

榜单的实时校验支持同一结论。抓取日 2026-10-22，五个榜单与论文 Table 2 到 Table 6 逐格零差异、模型集合也一致，说明结论在抓取日仍然成立。但页面只写「按月更新」，没有分数时间戳，且大量指标标为 undetermined，其数值实际是下界。StreamEval 榜单

五、执行请求难在「何时生效、改什么、保住什么」同时成立，而这套基准自身也还有未验的部分

时序与保持约束之所以是硬骨头，是因为三件事必须同时成立，而不是各自成立即可。请求必须在检查窗口内生效，迟到不算通过；改动必须落在正确的作用域与目标上；非目标内容与当前源运动必须被保住，撤销要恢复到当时的源状态。Edit Success 之所以要求同时满足作用域、激活状态、截止时间、持续性、受保护内容五项检查，正是因为这三点里漏掉任何一个，执行都不算完整。

讲解：执行一个请求要同时过哪几道关

这也解释了 StreamEval 相对既有基准的增量位置。VBench 系测的是离线一次性短片段的画质与内在忠实性，它的 18 个细粒度维度全是片段内属性，没有交互、会话或状态保持维度。VBench-2.0 最接近的先行工作是 WBench，它测多轮交互世界模型，但它的「保持」是事后测量式的，用例规格里只写世界设定与交互序列，没有显式声明「本轮必须保住什么」，因此没有独立成维的 Preservation 指标，参考条件也不是一等公民。WBench StreamAV-Bench 已经把状态保持与音画同步单列，证明这两件事并非 StreamEval 首创，但它的交互轨道只覆盖世界状态更新，没有数字人对话与 avatar 表演。StreamAV-Bench StreamEval 补的正是这个缝：把 avatar 交互、世界生成、实时编辑三条线并进同一套「执行加保持」框架，并给出 15 到 300 秒的均衡多时长设计。

而这套基准自身还有没验完的部分，必须和已解决的部分分开看。已解决的有跨五种任务的统一执行与保持口径、15 到 300 秒的均衡多时长设计、以及公开的用例、oracle 与评测 harness。未解决的至少有四类。指标覆盖度上还缺全局重置、并发编辑仍处于激活状态时的选择性恢复这类场景。用例真实性与素材授权边界上，第三方素材各自许可，公开可读的 98 条 oracle 仍标记为待媒体复核与标定。裁判可靠性上，论文只给验收标准，没有报告任何实测值，仓库也明示历史标定结果不随发布提供、未标定指标保持 provisional，而「收集人类成对判断并检验其与任务规则的一致性」被列为下一步，所以现在不能说这套分数与人类判断一致。可复现性上，大量厂商 API 型被评模型是黑盒，部分上游只允许学术研究用途，完整训练流水线没有开源。

最后收敛成一句可操作的判断：要判断一个视频系统能不能做交互，该看的是执行类指标，而不是它的画质分。

想深入可以读原文：StreamEval: Evaluating Interactive Streaming Video Generation Models — arXiv:2610.28402

参考文献

• StreamEval: Evaluating Interactive Streaming Video Generation Models — arXiv:2610.28402
• StreamEval Leaderboard（官方站点，抓取日 2026-10-22）— streameval.ai
• StreamEval 官方代码、基准数据与评测 harness — github.com/StreamEval/StreamEval
• VBench-2.0: Advancing Video Generation Benchmark Suite for Intrinsic Faithfulness — arXiv:2503.21755
• WBench: A Comprehensive Multi-turn Benchmark for Interactive Video World Model Evaluation — arXiv:2605.25874
• StreamAV-Bench: A Comprehensive Benchmark for Streaming Audio-Video Generation — arXiv:2608.26336
• JoyAI-Video-Edit: Real-Time Open-Ended Video Editing with Autoregressive Diffusion — arXiv:2608.03974
• Vidu S2: Real-Time Interactive, Editable, and Spatial Video Generation — arXiv:2609.11638
• StreamDiffusion: A Pipeline-level Solution for Real-time Interactive Generation — arXiv:2312.12491
• Self Forcing: Bridging the Train-Test Gap in Autoregressive Video Diffusion — arXiv:2506.08009
• VisionQ: VLM-as-a-Judge Taxonomy, Dataset and Benchmark for Qualitative Analysis in Computer Vision — arXiv:2610.00666
• Matrix-Game 3.5: Enhancing Real-Time Streaming Interactive World Models with Patch Memory — arXiv:2608.29910