2024 年前后，AI 视频生成有个挺尴尬的处境。
模型能生成的视频是真的长了，几十秒的连贯视频不再是奢望。但代价是什么呢？生成速度慢得让人抓狂。你以为模型在拼命画画，其实它有一大半时间在做一件听起来很奇怪的事情：反复给自己"补笔记"。
这就是这篇论文要解决的问题。Meta 的研究团队发现，几乎所有主流的自回归视频生成方法，都在做一种本质上"白费力气"的计算。他们把这个问题揪出来，提出了一个叫 FlashForward 的方案，在保持画质甚至更好的前提下，把生成速度干到了比同类方法快 1.16 到 2.92 倍。
这篇论文有意思的地方在于，它没有去发明什么新的网络结构，而是重新设计了一个更底层的东西：模型内部的"记忆机制"是怎么传递的。听起来抽象，但拆开看你会发现，这其实是个特别朴素的道理被长期忽略了。
视频生成为什么要"分块画"
要理解这篇论文，得先知道自回归视频扩散模型是怎么工作的。
自回归视频扩散模型：一种把长视频切成一小段一小段（称为"chunk"，块）来生成的模型，每一块要经过几轮"去噪"才能从一堆随机噪声变成清晰画面，前面生成好的块会作为后面块的参考。
这种做法很像你写连载小说。你不可能一口气把整部小说写完再发表，得一章一章来，而且写第五章的时候，你得记得前四章讲了什么，人物性格、场景细节都不能乱。
问题就出在"记得前面讲了什么"这件事上。视频模型为了记住之前生成的块，会把这些块的特征存进一个叫 KV 缓存的东西里。
KV 缓存：Key-Value Cache 的简称，是 Transformer 类模型里用来存储历史信息的机制，后面生成新内容时会去"查阅"这份缓存，避免每次都从头计算。
现在关键问题来了：这份缓存该存"多干净"的内容？
如果你等一个视频块彻底生成完、画面完全清晰了才把它存进缓存，那这份记忆质量很高，但你得为此单独跑一次模型来"提取"这份干净记忆，这次运算不产生任何新的视频内容，纯粹是为了记笔记而记笔记。Self-Forcing 这个此前的代表性方法就是这么干的：每生成完一个块，额外做一次模型前向传播，专门用来构建缓存。
这就好比你开会记笔记，会议进行中你不敢分心去记，非要等会议全部结束了，再把录音倒回去重新听一遍、专门抽时间整理成笔记。这样笔记质量确实高，但你多花了一倍的时间。如果不这样做，笔记可能有点乱，但你能立刻投入下一场会议。Self-Forcing 选择的是"笔记质量优先"，代价是每生成一块视频，就要多付出一次几乎等价的计算成本。
HiAR 这个方法想了个改进办法：不等画面彻底干净，用"没那么噪的中间状态"来构建缓存，这样不同的视频块可以在执行上有所重叠，效率更高一些。但代价是它得在每一个去噪阶段都重新跑一次编码，相当于会议记笔记这件事没有省，只是从会后集中记变成了会中频繁打断记。
论文管这种"要不要额外跑一次模型专门造缓存"的设计，叫作跨块状态契约。
跨块状态契约：指定每个视频块要"发布"什么样的表示、在什么噪声程度下发布、以及后面的块什么时候可以读取这份表示的一套规则。这个契约不仅决定了模型能用到哪些历史记忆，还决定了各个块的生成能不能并行执行。
核心洞察：造缓存的计算其实早就存在了
FlashForward 的核心想法，说出来会让人有点恍然大悟的感觉。
每一次普通的去噪前向传播，模型内部本来就已经计算出了当前块在这个噪声阶段的 KV 表示。这份表示虽然还没完全去噪，是"半成品"，但它是模型正常工作流程里免费产出的副产品。
那为什么还要额外跑一次模型去"重新造"一份干净的缓存呢？
这就好比公司开周会，主持人在讲每一页 PPT 的时候，其实已经顺手把要点写在了白板上。可流程规定，会议结束后还要专门安排半小时，把白板内容重新誊抄成一份"正式会议纪要"。FlashForward 做的事情就是说：白板上的字已经够用了，直接拍照存档就行，为什么非要誊抄一遍？
论文把这个思路叫作原位 KV 复用，直接把每次去噪前向传播产生的 KV，发布给后面在同一个去噪阶段的块去读取。
这样一来，每一次模型前向传播都同时做了两件事：推进当前这个块的生成进度，顺便把记忆发布出去。没有任何一次计算是"白跑"的。
更妙的是，这种设计带来一个意外的好处：流水线并行。既然每个块在每个阶段产生的记忆立刻可用，那就可以给四个 GPU 各自分配一个去噪阶段，让不同的视频块同时占据不同的阶段在跑。第一块在第四阶段跑的时候，第二块已经可以开始跑第三阶段了，像多个工人在流水线上错开干活，而不是一个人干完一件事才轮到下一件。论文管这种执行方式叫渲染器块-阶段波front，形成一种"反对角线"式的调度。
但天下没有免费的午餐。这份"顺手拿来"的记忆是有代价的：它是噪声状态下的，不完整、不干净，而且只包含过去的信息，没有未来的信息。如果只靠这份记忆，视频容易出现外观和运动上的"漂移"，颜色越拍越偏，动作越走越乱。
用稀疏的"清晰锚点"来兜底
既然原位复用的记忆是噪的，那怎么办？FlashForward 的答案是：另外搭一套稀疏的、干净的辅助记忆，来给整个生成过程提供长程的结构性指引。
具体做法是引入一个规划器角色，先在整个视频时间轴上稀疏地生成一些关键帧潜变量，论文里叫锚点。
锚点：在视频时间轴上按固定间隔选取的少数几个关键位置（论文中每隔 10 帧潜变量选一个），规划器会先把这些位置的画面彻底生成清楚，然后提取出它们的干净 KV 缓存，供后续渲染阶段参考。
拿论文里的具体例子来说，一个 81 帧的视频潜变量序列，规划器会在第 0、10、20、30……80 帧这九个位置生成清晰锚点，每三个一组分批完成。之后有一个专门叫渲染器的角色，去生成这 81 帧里的每一帧，每渲染一个三帧的小块，都会读取离它最近的一组锚点作为参考，比如生成第 6 到 8 帧的时候，会参考第 0、10、20 帧这三个锚点，前后都有，形成"两侧夹击"式的引导。
这个设计的巧妙之处在于两种记忆各司其职，分工明确。
稀疏的锚点记忆负责粗粒度的长程结构，告诉模型"这一大段时间里画面大致应该往哪个方向走"；密集的原位历史记忆负责细粒度的、刚刚发生的动态变化，告诉模型"上一秒钟到底发生了什么"。
这就像你在导航一次自驾长途旅行。手机导航给你的是整条路线的全局规划，从北京到上海要经过哪些主要城市，这是粗粒度的、提前规划好的"锚点"。而你实际开车时盯着的仪表盘和路况，则是细粒度的、实时更新的"历史记忆"。如果只有全局路线没有实时路况，你可能开着开着就撞上了突然出现的障碍；如果只盯着仪表盘不看全局路线，你可能开出很远才发现方向早就错了。两者缺一不可，而且各自更新的频率完全不同，导航路线不需要每秒都刷新，但路况必须实时刷新。
关键是，只有稀疏的规划器块需要额外的"干净提取"前向传播，因为规划器的推进步幅很大，一次跳跃能覆盖 30 个潜变量的距离，而渲染器一次只推进 3 个潜变量，相当于将近十倍的跨度差异。这意味着造干净缓存这件"昂贵"的事情，被摊薄到了极少数几个点上，而渲染器绝大部分的密集生成过程完全不需要承担这份额外开销。
两个角色共用一个大脑
规划器和渲染器听起来像是两个不同的模型，实际上论文用的是同一套骨干网络，通过角色专属的嵌入向量和 LoRA 适配器来区分行为。
LoRA：Low-Rank Adaptation 的简称，一种给大模型做轻量化微调的技术，不需要改动整个网络的参数，只在关键层旁边插入一个小的低秩矩阵来学习新任务，训练和部署成本都低很多。
这个设计的道理也很实在：规划器和渲染器虽然要做的事情不一样，一个负责稀疏跳跃式的关键帧规划，一个负责密集连续的逐帧渲染，但它们对画面美学、物体外观、语言理解这些底层视觉语言知识的需求是共通的。与其训练两个完全独立的模型各自浪费一遍学习成本，不如共享大部分参数，只用小小的适配器去学习"角色专属"的时序依赖方式。
这好比一个演员分饰两角。同一个人可以演反派也可以演正派，他的表演功底、台词功力是共用的，但通过换装、换语气这些"轻量级"的调整，就能呈现出完全不同的角色状态。不需要为每个角色单独培养一个演员。
训练分两个阶段。第一阶段叫打包式监督微调，直接用真实视频同时训练两个角色，让模型学会规划器的大步幅因果依赖和渲染器的锚点加历史依赖这两种模式。第二阶段叫自回滚蒸馏，让模型在自己生成的内容上（而不是真实数据上）继续训练，因为真实推理时用的锚点和历史记录都是模型自己生成的，会存在偏差，这个阶段就是专门用来纠正这种"训练和测试不一致"的问题，同时把去噪步数压缩到只需要四步。
为什么不能直接把锚点塞进最终视频里
这里有个论文专门花了篇幅讨论的细节，挺值得说一说，因为它反直觉。
按理说，规划器辛辛苦苦生成的锚点画面已经很清晰了，直接把它们塞进最终输出的视频里，省得渲染器重新生成这几帧，岂不是更省计算量？
研究团队真的试了这个"更省事"的做法，结果出现了周期性的接缝问题。每隔十帧，画面就会有一个肉眼可见的跳变，比如亮度突然变暗、颜色突然变得更暖或更艳。论文用了具体的实验来分析这个现象：经过监督微调阶段后，规划器输出的画面和渲染器输出的画面在平均亮度上几乎没有差异，差距只有 0.094。但一旦经过四步蒸馏，这个差距会被拉大十倍以上，达到 1.172，而且如果继续更新共享骨干网络，差距会进一步扩大到 6.244。
这说明什么？规划器和渲染器虽然共享大部分参数，但经过蒸馏训练之后，两条通路的输出统计特性会逐渐"分道扬镳"。渲染器的输出亮度提升幅度总是比规划器大，导致两者拼接的地方出现明显断层。
这就像两个厨师本来用同一份菜谱，但因为分工不同，一个专门做主菜一个专门做配菜，练着练着各自形成了自己的手感，主菜咸淡和配菜咸淡慢慢就不统一了，拼在一个盘子里端上桌，食客一尝就能吃出来接缝感。
FlashForward 最终的解决方案是：锚点只用来"指路"，不进最终成品。渲染器要重新生成视频里的每一个位置，包括锚点对应的那几帧，锚点的干净 KV 只作为参考条件，从不直接进入输出序列。这样最终视频永远是渲染器一个通路的产物，不存在跨角色拼接，接缝问题自然就消失了。论文的量化实验显示，这种全位置渲染的方式把锚点处的画面跳变指标从两种拼接方案的 3.34 到 3.93，降到了自己的 1.83。
实测数据：到底快了多少，好了多少
说了这么多设计思路，最终还是要看实际效果。
在速度上，论文对比了 Self-Forcing（干净历史方案）、HiAR（较不噪历史方案）和 FlashForward，在 1.3B 和 14B 两个模型规模、480p 和 720p 两种分辨率下，测试了 20 秒、35 秒、65 秒的视频生成。结果显示，从 20 秒的视频开始，FlashForward 在四 GPU 配置下始终是最快的方案，比 HiAR 快 1.16 到 1.69 倍，比 Self-Forcing 快 1.42 到 2.92 倍。
在 65 秒这个最长的测试档位上，14B 模型 720p 分辨率的场景里，FlashForward 相比传统的双向生成方式实现了 8.4 倍的加速，这是个相当夸张的数字。
画质方面，论文用了业内通用的 VBench 评测体系。在 20 秒视频的 VBench-1.0 评测中，1.3B 模型、480p 分辨率下，FlashForward 拿到了 0.838 的总分，超过 Self-Forcing 的 0.805 和 HiAR 的 0.821。更值得关注的是长视频场景下的表现：
| 时长 | FlashForward 总分 | Self-Forcing 总分 | HiAR 总分 |
|------|------|------|------|
| 20秒 | **0.8404** | 0.8258 | 0.8265 |
| 35秒 | **0.8401** | 0.8087 | 0.8230 |
| 65秒 | **0.8395** | 0.7806 | 0.8219 |
从这个表格能看出一个特别重要的趋势：Self-Forcing 的分数随着视频时长增加明显下滑，从 0.8258 掉到 0.7806，掉了近 0.05 分。而 FlashForward 从 20 秒到 65 秒几乎纹丝不动，稳定在 0.84 左右。这说明它的两侧锚点设计确实在长视频场景下起到了防止漂移的作用，画面不会随着生成时间拉长而越来越走样。
论文里还放了具体的对比视频截图。Self-Forcing 生成的视频会出现明显的色彩漂移，画面越往后颜色越怪。HiAR 虽然避免了这种整体色彩崩坏，但会在细节上跑偏，比如浣熊的脸和耳朵形状慢慢变了，织毛衣的人脸变得像个洋娃娃，人物手臂在斗篷下始终模糊不清。而 FlashForward 生成的视频，无论是锚点位置还是非锚点位置，画面看起来没有明显区别，运动也保持连贯。
这个思路能走多远
论文的作者也坦诚地写了目前方案的局限。
比如规划器和流水线启动都需要一定的"热身"时间，这在短视频场景下会拉低相对收益，单 GPU 推理也没法利用多阶段并行的优势。训练数据只用了真实世界视频，这可能让模型偏向写实风格，在动画等风格化场景上表现如何还不确定。锚点间隔和条件窗口目前都是固定值，怎么根据内容自适应调整，还是未来要解决的问题。
不过这篇论文提出的"跨块状态契约"这个分析框架，本身的价值可能超出了 FlashForward 这一个具体方案。它把此前各种自回归视频生成方法的差异，统一归纳成了"记忆在什么噪声水平发布、什么时候可用"这一套坐标系，这让后续研究者可以更清晰地定位自己的方法处在什么位置，还有哪些设计空间没被探索。
写在后面
读这篇论文的时候，最触动我的其实不是加速比这个数字，而是它揭示的一种思维惯性：我们经常为了追求"更干净"而重复劳动，却没意识到"够用的脏"可能才是效率最优解。
Self-Forcing 那种额外跑一遍模型专门造干净缓存的做法，如果你不带着这篇论文的视角去看，其实一点都不显得奇怪，甚至会觉得理所应当，反正模型输出好的质量最重要。但 FlashForward 提出的原位复用思路提醒了一件事：系统里往往已经存在你需要的东西，只是没人愿意去"将就"用它，大家习惯性地选择重新计算一份"更完美"的版本。
论文里那个关于锚点接缝的实验分析我反复看了几遍，尤其是共享骨干网络在蒸馏后两条通路输出统计量会逐渐分化这个发现。这其实是个挺普适的现象：两个共享大部分参数、但分工不同的系统，经过长期各自独立的训练强化，会在细微处产生不可忽视的行为差异，哪怕它们看起来"应该"是一致的。这跟团队协作里两个人明明用同一套流程规范，但各自习惯久了做事风格还是会慢慢跑偏，是一个道理。
论文最后提到的一个未来方向也挺值得琢磨：能不能让锚点的位置本身也变得自适应，而不是死板地每隔十帧放一个。如果视频里某一段动作特别剧烈，是不是应该多放几个锚点稳住阵脚？这个问题论文没有回答，但留下的这个开放性口子，可能比正文里已经解决的问题更有意思。
Q&A
Q1：FlashForward是什么？
A：FlashForward是Meta研究团队提出的一种快速自回归视频扩散生成方法，核心思路是直接复用每次去噪计算中产生的KV缓存，避免额外的"造缓存"前向传播，同时用稀疏的清晰锚点帧提供长程结构引导，从而在保持画质的同时大幅提升生成速度。
Q2：FlashForward比其他方法快多少？
A：在四GPU配置、20秒以上视频的测试中，FlashForward比HiAR快1.16到1.69倍，比Self-Forcing快1.42到2.92倍，在14B模型720p分辨率的65秒视频场景下，相比双向生成方式最高能实现8.4倍加速。
Q3：为什么FlashForward不直接把规划器生成的锚点帧放进最终视频？
A：实验发现直接拼接会在锚点位置产生周期性接缝，因为蒸馏训练后规划器和渲染器的输出亮度等统计特性会逐渐产生差异。FlashForward让渲染器重新生成包括锚点在内的每一帧，锚点只作为参考条件，从而避免了跨角色拼接导致的画面跳变问题。
