InfinityEdit：为什么视频编辑一碰上直播流就失灵？

想象你坐在直播导播台前。游戏主播打到正酣，画面还在以每秒十几帧的速度长出来，这时指令到了："接下来把整场直播调成赛博朋克霓虹风。" 传统视频编辑工具在这一刻会本能地卡壳，因为它们的全部工作方式都建立在同一个前提上：素材已经完整躺在那里，长度固定，我可以把每一帧取出来、逐帧对齐、逐帧改写。可直播流的素材永远不会"完整"，它一直在变长，编辑指令到达时，要改的那段视频还没有结束。恰恰是这条"永不结束"的裂缝，让所有为完整素材设计的手法在这一刻集体失效。

这条裂缝为什么致命？答案藏在"逐帧对应"这个词里。整段改写能成立，靠的是一个前提，论文称之为 in-place editing（就地编辑）假设：素材必须完整。有了完整的前序片段 $V_\text{pcd}$ 与编辑指令 $c_\text{edit}$，模型才能逐帧对齐地改写出续接片段 $V_\text{tgt}$。可续接场景里，前序与目标两个片段的时长一般不相等（$T_1 \neq T_2$），目标帧与输入帧之间没有逐帧对应关系。就地编辑的全部动作都围绕对齐展开，这里却恰恰没有可对齐的东西。指令说"把这段视频改掉"，可模型手里只有一段还没结束的画面；按时间戳去变换已有帧，等于对着一个不存在的坐标系下刀。多轮场景下情况更糟：每轮输出又会变成下一轮的输入条件，对齐参照从"原始素材"一步步换成"自己上一轮生成的产物"，越往后越失真。InfinityEdit

这种失灵不是个别实现的缺陷，而是现成方法论的默认前提集体失效。在一篇覆盖面很广的视频扩散综述里，指令式编辑被分成"保持一致、专用控制、效率优先"三支，而这三支无一例外都默认同一个前提：源视频是一段定长、可以被整段拿住的素材。定义本身没有给"素材还在持续到达"留下任何位置，也就是说，每一种现成思路都是在为完整素材设计手术方案，没有一种回答过"素材还没结束该怎么办"。这个集体空出来的缺口，论文称之为 infinite video editing（无限视频编辑）。Video Diffusion Models Survey

把失灵的原因再往下想一层，就知道它具体断在哪两个环节。其一是忠实延续（faithful continuation）：没有可对齐的源帧，编辑必须生成自然的续接，而不是按时间戳变换已有画面。其二是累积稳定（accumulation stability）：每轮输出变成下一轮的输入条件，$V^{(i)} = \mathcal{G}(V^{(i-1)}[-T_1:],, c_\text{edit}^{(i)})$，错误会随着编辑轮次滚雪球。论文用同一个场景把失灵摆得很具体：一段风景源视频上，相机运动加风格变换的指令被持续施加三轮，整段改写型方法在每一轮都要去"对齐"一段已经不存在对应关系的源画面，特征迅速失真；而把编辑理解成"续写"的方法，则能一路延续源视频的内容。给一场正在进行的游戏直播换画风，对一段还没拍完的镜头施加相机移动，这类指令要的不是改写已经发生的东西，而是让尚未发生的画面按新要求长出来。素材没有尽头，逐帧对齐便无从谈起。这个设定不是凭空想象出来的，实时内容创作、直播和交互式影像都在把生成推向"永不结束"，未结束的流只会越来越多。

图注：同一段风景源视频、同一串编辑指令（相机运动加风格变换）下不同方法的输出对比，每一行是一种方法，逐行展示三轮编辑后的累积结果，带 † 标记的方法不读取源视频。同为"整段改写"思路的基线在指令链下逐渐失真，InfinityEdit 延续了源视频的内容。InfinityEdit

换句话说，视频编辑过去是"对着整段素材做手术"，而无限视频编辑要求的是"顺着一条不结束的河流续写"。这立刻逼出一个前置问题：要接住这种编辑，得先有一个能无限续写的生成器。这样的生成器存在吗？

挂上编辑器之前：流式生成器凭什么能无限续写？

存在。它凭什么能无限续写？把"生成"拆成逐帧的增量步骤就行：每一帧都只依赖已经生成的历史做一步因果预测，生成器不知道也不关心终点在哪，素材就能一直续下去。LongLive 是这条路线上代表性的工程：它把视频生成做成帧级的因果自回归，每生成一帧只做增量计算，把前面算好的 KV cache（键值缓存）留作缓存复用；注意力只盯着最近几秒的短窗口，再往最前面固定保留一个"画面汇点"帧当全局锚点，靠它撑住长程一致性。最妙的是它把"中途换 prompt"做成了标准动作：用户切换指令的那一刻，用已经生成的视频帧加上新 prompt 的 embedding 重新算一遍 cross-attention（交叉注意力）的缓存状态，画面就能平滑过渡到新指令。为了让这套东西真的扛住长时间运行，它还要处理一个隐蔽问题：只在短视频上训练、拿到长视频上推理的模型，会一路吃自己生成的、渐渐失真的历史，长程一致性慢慢崩塌。LongLive 用 streaming long tuning 在训练时也滚动续写、逐段监督，把这种漂移压了下去。这套系统在单张 H100 上实测跑出 20.7 FPS，最长可以连续生成 240 秒。能稳定跑出这种数字，无限续写早已是相当成熟的工程。LongLive

图注：LongLive 的系统总览。左半边是连续 prompt 流驱动下的长视频生成，短窗口注意力配合画面汇点（frame sink）保持长程一致；右半边是 prompt 切换时的 KV-recache，把上一段视频的视觉内容与新 prompt 一起送入交叉注意力，重建缓存状态。LongLive

LongLive 不是孤例，把它和另外几条路线并排看，结论是一致的：无限续写的基本盘已经站稳。Self Forcing 走 chunk 级自回归加滚动 KV cache，并在训练时让模型吃自己生成的帧，实测 17 FPS；Self Forcing StreamDiT 换了一条路，用窗口注意力加滑动缓冲，4B 参数也能到 16 FPS；StreamDiT 更早的 Diffusion Forcing 则在理论上铺好了路基：让序列里每个 token 各自拥有独立的噪声水平，就把"逐帧自回归"和"整段扩散"统一进同一个框架，支撑起超过 1000 帧的稳定续写。Diffusion Forcing

这张路线图带出一个关键事实：InfinityEdit 没有自己造一个流式生成器。它把 14B 的 Helios-Distilled 当作一个冻结的基座直接踩上去，生成、续写、换条件全都交给基座。它的全部新意不在"怎么无限生成"，而在"怎么把编辑塞进生成里，还不弄脏生成"。那么，编辑能力该长在哪个位置，才能在指令到达时生效，又不对基座动手脚？

只挂一层适配器，模型从哪里学会边续写边听话？

先回答监督从哪来。要让模型学会"顺着已有流继续走、同时服从编辑"，训练数据不能是"同一段素材的逐帧改写对"，而必须是 $V_\text{pcd} \rightarrow V_\text{tgt}$ 这种前后长度不同的三元组。论文为此搭了一条三步数据管线：

这条管线的机关在"连接帧"：取源视频的最后一帧当桥，经过编辑后的这一帧成为目标片段的第一帧，内容因此被延续、编辑也被注入。管线里还有两个容易忽略的细节。抽象的编辑类型本身不绑定任何具体画面，必须先按源视频的主体展开成可执行的指令，第一步骤的 Gemini 3 Flash 干的就是这件事。而"类型感知"意味着，外观类编辑会真的改写连接帧的色彩与风格，运镜类则保持画面内容不动、只让镜头本身的运动发生变化。源视频采样自 UltraVideo 数据集，20 名标注员按对齐度、一致性、合理性、画质四个维度把关。InfinityEdit

有了数据，适配器才谈得上学。整个模型的主体就是那个 14B 的流式基座，每个 transformer 层后面挂一个轻量的 Edit-Ignition Adapter，基座权重完全冻结，只有适配器加一份共享的 sigma 嵌入是可训练的。适配器内部有三种注意力，各管一件事。第一种是历史交叉注意力（History Cross-Attention），让当前 chunk 的开头几帧去做 query、去读历史帧，把"上一步长什么样"的锚定信号吸进来；第二种是时序因果自注意力（Temporal Causal Self-Attention），在时间维上做带因果遮罩的自注意力，保证信息只从早帧流向晚帧，维持流式的时序；第三种是编辑交叉注意力（Edit Cross-Attention），把编辑指令注入当前 chunk 的所有去噪 token，决定"这次改什么"。三个模块的输出都还要先过一层 AdaLN 调制，尺度与偏移由一份共享的噪声水平嵌入预测，让适配器对不同去噪阶段的画面保持敏感。

图注：适配器由三种注意力模块组成，整体挂接在冻结基座之上：历史交叉注意力锚定输入、时序因果自注意力维持早到晚的信息流、编辑交叉注意力注入指令，各模块输出以残差形式叠加回原始特征。InfinityEdit

三种模块固然各有分工，但让这套设计成立的关键工程细节在出口：每个模块的输出投影都从零初始化。这意味着适配器刚挂上去时是一个恒等映射，什么都不改，训练只是在这层"什么都不改"的基础上一点点叠加能力。这有点像给照片叠加一个刚创建时完全透明的图层。图层全透明时，底下的照片原样可见，这就是零初始化带来的恒等映射；之后训练只往这个图层里添颜色，照片本体始终没有被碰过。基座的生成先验因此在起步阶段毫发无损，编辑能力始终以"残差"的形式叠加在基座之上，这正是它轻、它可插拔、它不污染基座的根源。

训练目标里还藏着一个贴近实战的设计。适配器在推理时要面对"自己生成的历史"，而训练时理论上的历史是干净的真实帧，这种错位会积累误差，是生成式模型典型的暴露偏差问题。论文把每段历史潜变量以一定概率混入噪声再喂给适配器，三种时间尺度的历史各自独立地做这种污染，让适配器在训练阶段就习惯"不完美的过去"，把偏差提前消化掉。可训练时学到的这套能力，推理时到底怎么用，才能不拖累基座本来就有的无限续写本领？

为什么只在指令到达的一瞬点燃，其余一概不碰？

论文的推理策略叫 ignite-then-continue（点燃，然后继续）。每条编辑指令到达时，只有它所在的那个 chunk 会让适配器激活。chunk 是流式生成的最小单元，通常是一小撮帧：这一瞬间适配器接管去噪，用单阶段 Euler 调度快速生成，再补一个接近零噪声的细节精修步。这个精修步对应训练目标里那个接近零的噪声分量，专门把点火那一拍的细节收干净。指令处理完，下一个 chunk 立刻交还给冻结的基座，由它用原来的调度器继续无限生成。这就像在直播导播台上装了一个"转场"键：按下那一拍，画面做一次特殊处理，松开之后信号继续原样播出。适配器就是那个转场键，它只在指令到达的那一拍生效，其余时间完全不碰信号。

为什么可以这样放心？因为基座本来就以它生成过的历史为条件，点火 chunk 一旦落入历史窗口，后续 chunk 会自动把编辑效果继承下去，编辑只发生在引入它的那个位置。再配上两个工程组件，这套机制就完整了。一个是滑动历史窗口：每生成一个 chunk 就追加进记忆，但只保留最近的一段，记忆开销不会随编辑轮次无限增长。另一个是锚帧重置：每轮编辑结束后，把生成状态里的干净锚帧 $x_0$ 重置为这个编辑 chunk 的第一帧，并保持到下一轮指令到达，同时把基座的场景 prompt 换成当前的编辑指令。

这套"点火就改、松手就续"的节奏，正好踩在流式生成器的因果结构上。因果自回归生成器只向历史看，条件只在自己被引入的位置生效，后续 chunk 会把编辑当成既成事实继承下去，不需要任何额外的对齐步骤。LongLive 在 prompt 切换时重建 KV 缓存，让生成平滑跟上新指令；锚帧重置要解决的其实是同一家族的问题：怎么把"换条件"做成一个干净、局部的动作，而不是推倒重来。InfinityEdit

图注：推理流水线的时序示意。每一轮编辑都从一个点火 chunk 开始，此时适配器激活；之后的 chunk 交还冻结基座继续生成，锚帧重置与滑动历史窗口负责把各轮编辑在时序上衔接起来。InfinityEdit

把这一章浓缩成一句话，就是"只在指令所在的位置改写，其他位置不被适配器污染"。这句话同时回答了第一章的两个挑战：忠实延续靠锚帧和历史窗口提供的续接参照，累积稳定靠编辑不叠加在基座之上，这项设计旨在避免适配器在每个后续 chunk 反复介入；它能否保住多轮稳定性，需看下一节的测试。设计听着自洽，但当它和拿到同一串指令的基线站上擂台时，到底经不经得起测？

同一串指令链，只有它既延续、又越改越稳？

论文没有沿用现成的评测，而是自己搭了一座擂台：OOD sequential-editing benchmark。所谓 OOD，是这 200 段源视频与训练集不重叠，覆盖 5 类主体，题材和分布都是模型没见过的编辑对象，专测泛化而不是背题；每段视频喂 3 轮编辑指令、覆盖 15 个编辑类型，逐轮累计 12 个 chunk。五个基线天然分成三族，恰好对应三种失败方式：纯基座族（Helios-Base，不带适配器，只把源 prompt 换成指令）、就地编辑族（Lucy-Edit、SANA-Streaming，逐帧对齐改写）、自由生成族（Anchor-Forcing、Infinity-RoPE，干脆不取源视频）。InfinityEdit

量化结果用 VBench 的三个维度最能说明问题：

相机运动这一项尤其值得细看：在"续接"场景下，既要延续画面又要展现新的运镜，本就互相拉扯，领先第二名 0.22 分意味着编辑指令不是被"画"上去的，而是真的驱动了镜头。运动平滑度紧随基座自身的最优值，说明挂上适配器没有破坏生成质量。时间闪烁在第三轮编辑后才测，是最能暴露累积退化的指标，它拿第一意味着多轮编辑之后时间一致性没有崩。除了这三项硬指标，论文还请了 Gemini-3.5-Flash 当评委，按 1 到 5 分给编辑忠实度、视觉质量、场景身份保持、跨编辑一致性四个维度打分，四项全部第一。两头的基线各有死穴：就地编辑族每轮重写自己的上轮输出，跨编辑一致性越来越差；自由生成族不读源视频，场景身份保持普遍不到 2 分。至于 Dynamic Degree 这类指标，论文明确说它只反映画面动了多少，衡量的是运动量而非编辑保真，仅作参考。

但最能显出这套设计成色的，是"越改越稳"这一条。跨三轮编辑的美学质量曲线里，基线在第一轮之后就掉了 0.02 到 0.04，论文方法几乎是一条平线；逐轮的编辑忠实度波动只有 0.023，是唯一同时分高又稳定的方法。这里有一个要读准的陷阱：就地编辑族的曲线看起来在"上升"，那是虚假的，因为它每轮都把上一轮输出整段重写一遍，画布越改越松，指标自然好看，语义却早已漂走。长视频测试把每段编辑进一步拉长，序列总长超过 1000 帧，画面依旧保持视觉稳定，编辑指令被忠实执行。

同一串指令链上，基线要么不续接、要么越改越糟，只有它同时守住了延续与稳定。但也要清醒：这座擂台是它自己搭的，benchmark 是它自己建的，基座 Helios 则是外部的流式生成模型。这个取舍放进更大的坐标系里，到底值不值？

一根轻量适配器，撬动了什么，又把上限押在了哪里？

2026 年夏天，流式视频编辑同时出现了三条技术路线，正好是三种实现哲学。InfinityEdit 之外，LiveEdit 走的是整模型蒸馏：把双向扩散模型通过三阶段蒸馏整体重铸成一台 4 步因果编辑器，再用 AR-oriented Mask Cache 把未编辑背景区域大约七成的 token 直接砍掉，这些区域直接复用上一 chunk 的特征，计算只留给真正变化的地方，最终跑到 12.66 FPS；代价是每一步都动全身，编辑器一旦定形，想换基座就得重新蒸馏一遍。LiveEdit

JoyAI-Video-Edit 走得更重：16B 参数从头训一套端到端系统，MLLM 负责编条件、因果 VAE 负责编解码、MM-DiT 做联合生成，再配两套蒸馏技巧，在 B200 上做到 30 FPS @ 720p，代码和权重直接开源。JoyAI-Video-Edit

图注：JoyAI-Video-Edit 的整体架构，从左到右依次是 MLLM（从文本与视觉输入提取条件 token）、Causal Video VAE（把视频与参考图投影到共享潜空间）、MM-DiT（联合建模条件与视觉 latent 并生成编辑结果），三模块拼成一套端到端的自回归扩散编辑器。JoyAI-Video-Edit

三条路线正好是三种取舍。JoyAI 最重，换来全流程可控和极致速度；LiveEdit 把基座整个改造成编辑器，换来实时性与强背景保持；InfinityEdit 最轻，换来可插拔、可复用、低成本，只要地基还是一个流式生成器，适配器就能装上去。但轻的代价同样清楚：它的上限押在基座上，基座的质量决定天花板；它的表达力押在指令上，而论文自己承认，目前只能吃自然语言指令，用图像或视频示例作参考是下一步方向，编辑边界处的过渡还有突兀感，不同编辑类型之间的平滑切换也还没有解决。InfinityEdit

放进产品语境里看，这条最轻的路线反而是最容易落地的一条。LiveEdit 和 JoyAI-Video-Edit 交付的是"一台专用的编辑器"，从数据到蒸馏都要重走一遍；InfinityEdit 交付的是一块可以插在流式生成器上的模块，复用的成本低得多。当然，这也意味着它最依赖生态：没有足够好的流式生成器当基座，它什么都不是。

最后提醒一句：这是一篇 v1 预印本，还没有第三方独立复现，GitHub 仓库与项目页的状态也未经验证，读它的数字时值得留一分审慎。视频编辑正在从"改完一整段"变成"边播边改"。InfinityEdit 最有价值的地方，不止是把指标刷到了前列，而是证明了编辑可以做成流上一个随时按下的键：只在需要的那一拍被点燃，其余时候静静让信号流过。编辑从此不再是离线剪辑台上的工种，而成了直播流上的一种实时能力。

想深入可以读原文：InfinityEdit: Infinite Video Editing with a Lightweight Edit-Ignition Adapter — arXiv:2608.20910

参考文献

1. InfinityEdit: Infinite Video Editing with a Lightweight Edit-Ignition Adapter（浙江大学 + 阿里集团，arXiv:2608.20910）— https://arxiv.org/abs/2608.20910
2. LongLive: Real-time Interactive Long Video Generation（NVIDIA Research 等，arXiv:2509.22622）— https://arxiv.org/abs/2509.22622
3. Self Forcing: Bridging the Train-Test Gap in Autoregressive Video Diffusion（arXiv:2506.08009）— https://arxiv.org/abs/2506.08009
4. StreamDiT: Real-Time Streaming Text-to-Video Generation（UC Berkeley + Meta，arXiv:2507.03745）— https://arxiv.org/abs/2507.03745
5. LiveEdit: Towards Real-Time Diffusion-Based Streaming Video Editing（arXiv:2606.26740，ECCV 2026）— https://arxiv.org/abs/2606.26740
6. Diffusion Forcing: Next-token Prediction Meets Full-Sequence Diffusion（MIT，arXiv:2407.01392，NeurIPS 2024）— https://arxiv.org/abs/2407.01392
7. Survey of Video Diffusion Models: Foundations, Implementations, and Applications（arXiv:2504.16081，TMLR）— https://arxiv.org/abs/2504.16081
8. JoyAI-Video-Edit: Real-Time Open-Ended Video Editing with Autoregressive Diffusion（京东开源体系，arXiv:2608.03974）— https://arxiv.org/abs/2608.03974