企业官网建设流程全解析

论文：LongLive: Real-time Interactive Long Video Generation

代码：NVlabs/LongLive: Long Video Gen Infrastructure

一、LongLive 到底想解决什么问题？

LongLive 这篇论文解决的是：

怎么让一个视频生成模型既能生成长视频，又能实时生成，还能在生成过程中接受新的 prompt，并且画面不要突然崩掉。

传统视频生成有几个痛点。

第一，扩散模型质量不错，但通常很慢。
它们大多用双向注意力，不能像语言模型那样方便地用 KV cache 加速，所以很难做到实时长视频生成。

第二，因果自回归模型比较快。
因为它可以像语言模型一样一边生成一边缓存历史的 K/V。但问题是，它通常只在短视频上训练，测试时硬拉长到几十秒、一两分钟，就容易画质下降、人物漂移、背景变掉。

第三，交互式提示切换很难。
比如前 5 秒 prompt 是：

一个男人抱着手站在办公室里

5 秒后用户换成：

他放下手臂，准备讲话

模型要做到两件事：

1. 男人还是同一个男人，办公室还是同一个办公室；
2. 新 prompt 又必须生效，男人真的要放下手臂。

这两个目标本身是冲突的。
如果太依赖历史，模型就不听新 prompt；如果完全丢掉历史，画面又会突然变。

LongLive 的核心就是围绕这个矛盾设计了一整套方案。

二、LongLive 的整体思路

LongLive 是一个帧级因果自回归视频生成框架。

简单说，它不是一次性生成完整视频，而是像写文章一样，一帧一帧、或者一小段一小段往后续写。

生成下一段时，它会用前面已经生成的视频作为历史上下文。为了加速，它会把历史上下文对应的注意力 Key/Value 存进KV cache。

可以类比语言模型：

语言模型：前面生成过的 token 存 KV cache，后面接着写 LongLive：前面生成过的视频 latent 存 KV cache，后面接着生成视频

不过视频比文本复杂很多，因为视频有画面一致性、动作连续性、prompt 切换等问题。

为了解决这些问题，LongLive 主要提出了三类关键技术：

1. KV-recache：解决 prompt 切换时旧语义残留和画面断裂的问题；
2. Streaming Long Tuning：解决长视频训练和推理不一致的问题；
3. Short Window Attention + Frame Sink：解决长视频推理的显存、速度和长程一致性问题。

下面逐个讲。

三、KV-recache：提示词切换时，怎么既保留画面，又换掉旧指令？

1. 什么是提示切换边界？

提示切换边界就是新 prompt 开始生效的时间点。

比如：

0s - 5s: Prompt 1，一个男人抱着手站在办公室 5s - 10s: Prompt 2，他放下手臂准备讲话

这里的5s就是 prompt switching boundary，也就是提示切换边界。

在 Figure 2 和 Figure 3 里，5s、10s、15s 这些位置就是类似的切换点。

2. previous video 是什么？是 latent 还是 KV cache？

KV-recache 用到的 previous video，不是旧 KV cache 本身。

更准确地说，它是：

已经生成的视频内容在模型内部的 latent tokens / latent frames。

也就是说，模型不是直接拿 RGB 像素去 recache，而是拿已经生成出来的视频 latent 表示。

KV cache 是由这些 latent 经过 Transformer/DiT 后算出来的中间状态。

关系是：

已生成视频 latent ↓ 经过 DiT / Transformer 得到各层 self-attention 的 K/V ↓ 形成 KV cache

所以：

previous video ≈ 已生成的视频 latent KV cache ≈ 模型处理这些 latent 后得到的注意力缓存

3. 需要一直存之前所有 latent 吗？

理论上，如果要重新理解“之前生成的视频”，确实需要保存一些之前生成的视频 latent。

但实际不一定要把完整 240 秒的所有 latent 都常驻 GPU。

因为 LongLive 同时用了：

Short Window Attention + Frame Sink

所以真正需要参与当前上下文的通常是：

1. Frame Sink 对应的早期关键帧 latent 2. 最近窗口内的 latent

也就是：

recache_context = sink_latents + recent_window_latents

完整视频可以流式解码、放 CPU、放磁盘，或者仅用于最终输出，不一定全部参与 attention。

所以 KV-recache 并不意味着显存里要一直存整个长视频的全部 latent。

4. prompt 是 cross-attention 注入的，那为什么会影响 self-attention 的 KV cache？

这是最容易混淆的点。

在 DiT / Transformer 视频模型里，prompt 通常是：

prompt → text encoder → text embeddings → cross-attention 注入视频 tokens

没错，prompt 是通过 cross-attention 注入的。

但是问题在于：

视频 token 的 hidden states 会被 prompt 影响，而 self-attention 的 K/V 是由这些 hidden states 投影出来的。

简化一下：

video hidden state h 经过 cross-attention 注入 prompt 语义 变成被 prompt 条件化后的 h' 然后： K = W_K h' V = W_V h'

所以如果之前的 prompt 是：

男人抱着手站着

那么旧 KV cache 里不只是有“这个男人、这个办公室”的视觉信息，还会混入“抱着手站着”的旧语义。

当新 prompt 变成：

他放下手臂

如果你只是换掉 cross-attention 的文本 embedding，但继续用旧 self-attention KV，就会出现冲突：

新 cross-attention 说：放下手臂 旧 self-KV 还在说：抱着手

这就是为什么只换 prompt embedding 不够，还要重新计算历史视频上下文对应的 KV cache。

5. KV-recache 具体怎么做？

KV-recache 的核心是：

用 previous video latent + new prompt embeddings 重新前向一遍模型 得到新的 recached tokens / 新 KV cache

Figure 2 右图就画了这个过程：

New Prompt \ Attention → Recached tokens → 更新 KV cache / Previous Video

更直白地说：

模型拿已经生成的视频 latent，再结合新的 prompt，通过 cross-attention 重新理解这段历史视频，然后重新生成一份新的 K/V cache。

所以它不是“改一改旧 KV cache”，也不是“直接保留旧 KV cache”。

它是：

丢掉旧 KV cache 保留 previous video latent 用 new prompt 重新算一份新的 KV cache

四、Figure 3：为什么 KV-recache 比保留/清空 KV cache 更好？

Figure 3 比较了三种策略。

1. 不用 KV cache：新 prompt 生效，但画面不连续

第一种是w/o KV cache。

也就是新 prompt 来了以后，不保留历史 cache。

结果是新 prompt 比较容易生效，比如人物确实放下手臂了。

但问题是画面突变：

• 人物可能变脸；
• 衣服变了；
• 办公室背景变了；
• 镜头位置变了；
• 视频不连续。

所以它的特点是：

新 prompt 遵循好 视觉连续性差

2. 保留旧 KV cache：画面连续，但新 prompt 被忽略

第二种是w/ KV cache。

也就是一直保留旧 KV cache。

这样画面很连续，因为模型记得之前的人、背景、姿态。

但新 prompt 经常不生效。
比如 prompt 让他放下手臂，模型还是让他抱着手站着。

原因就是旧 KV cache 里面残留旧 prompt 的语义。

所以它的特点是：

视觉连续性好 新 prompt 遵循差

3. KV-recache：画面连续，新 prompt 也生效

第三种就是 LongLive 的KV-recache。

它不是清空历史，也不是死用旧 cache，而是：

用历史视频 latent 保留视觉状态 用新 prompt 重新计算 cache

所以它能做到：

• 人物还是同一个；
• 背景还是同一个办公室；
• 镜头和风格保持连续；
• 新 prompt 又能生效，比如人物真的放下手臂。

所以它的特点是：

视觉连续性较好 新 prompt 遵循也较好

一句话概括：

KV-recache 就像是“带着前面画面的记忆，重新理解当前状态，并换成新指令继续生成”。

五、Short Window Attention：为什么不能一直关注全部历史？

长视频生成时，如果每一帧都关注从 0 秒到当前的全部历史，成本会越来越高。

假设生成到 100 秒，模型还要看前面所有帧，那 KV cache 会越来越大，attention 也越来越慢。

所以 LongLive 用Short Window Attention。

它的意思是：

当前生成时，只关注最近一小段历史，而不是全部历史。

比如只看最近几帧、最近几秒，普通历史太早的 KV 就驱逐掉。

这和 KV cache 的关系很直接：

Short Window Attention = 只保留/访问最近窗口的 KV cache

好处是：

• 显存少；
• 计算快；
• 推理速度高；
• 可以支持更长视频。

但它也有问题：

如果只看最近窗口，模型可能忘记早期的重要信息。

比如主角一开始穿红色衣服，后面可能变蓝；一开始是办公室，后面背景可能漂移。

这就需要 Frame Sink。

六、Frame Sink：短窗口之外，保留几个长期锚点

Frame Sink 是 Figure 2 左侧那条灰色竖条。

它表示：

视频开头的一些帧/latent tokens 被永久保留在 KV cache 里，作为全局视觉锚点。

所以 LongLive 的上下文不是单纯：

最近窗口

而是：

Frame Sink + 最近窗口

也就是：

KV cache = sink frames 的 KV + recent window 的 KV

Frame Sink 的作用是帮助模型记住：

• 主体是谁；
• 场景是什么；
• 风格是什么；
• 服装是什么；
• 初始布局是什么。

这样即使用 short window，模型也不容易在长视频后面彻底忘掉最初状态。

所以：

Short Window Attention 负责快 Frame Sink 负责稳

它们都和 KV cache 强相关，本质上就是 KV cache 的管理策略。

七、Streaming Long Tuning：为什么要这样训练？

LongLive 不只是改推理，还改训练。

因为如果训练和推理方式不一致，模型长视频生成会崩。

Figure 4 就是在讲这个问题。

八、Figure 4(a)：Short Tuning 的问题

Short Tuning 是普通短片段训练。

每次训练一个独立的 5 秒 clip：

Iter 1: 生成 0-5s，教师监督 Iter 2: 又生成一个新的 0-5s，教师监督 Iter 3: 又生成一个新的 0-5s，教师监督

这种训练让模型很会生成短视频。

但问题是，推理时不是每次都从 0 秒开始干净生成。

推理长视频时是：

先生成 0-5s 再基于自己生成的 0-5s 生成 5-10s 再基于自己生成的 0-10s 生成 10-15s ...

也就是说，推理时模型的输入历史是它自己生成的，里面可能有误差、漂移、噪声。

Short Tuning 没有训练模型处理这种情况。

所以会出现：

train-short-test-long

也就是短视频训练、长视频测试，导致长视频质量下降。

九、Figure 4(b)：Naïve Long Tuning 为什么不行？

Naïve Long Tuning 是最直接的想法：

那我就一次性训练完整 60 秒视频吧。

图里就是 Student 一次生成 0-60s，然后 Teacher 监督整个长视频。

但这有两个问题：

1. 会 OOM

因为视频 token 太多。

训练和推理不同。
推理时可以只存 KV cache，不需要反向传播。

但训练时反向传播要保存大量中间激活，比如：

• 每层 hidden states；
• Q/K/V；
• attention 中间结果；
• cross-attention 激活；
• MLP 激活；
• diffusion timestep 相关状态；
• loss 计算图；
• 可能还有 teacher 前向。

对 60 秒、120 秒甚至 240 秒视频一次性反传，显存会爆。

所以会 OOM。

2. Teacher 监督整个长视频不可靠

LongLive 的 teacher 通常是一个强大的短视频扩散模型，或者说它擅长监督短片段。

但它不一定擅长一次性监督完整 60 秒长视频。

原因是：

• teacher 自己可能也是按短视频训练的；
• 双向扩散 teacher 处理长视频成本极高；
• 长序列不在 teacher 熟悉分布内；
• teacher 对超长一致性的判断可能不可靠；
• 强行监督长视频可能给错误信号。

所以 Figure 4(b) 里写的是：

OOM & Incorrect Supervision

十、Figure 4(c)：Streaming Long Tuning 怎么解决？

Streaming Long Tuning 是 LongLive 的核心训练方法。

它的做法是：

学生模型基于自己生成的历史继续生成下一段 教师只监督当前新生成的 5 秒片段

比如：

第 1 次：学生生成 0-5s，教师监督 0-5s 第 2 次：学生基于 0-5s 历史生成 5-10s，教师监督 5-10s 第 3 次：学生基于 0-10s 历史生成 10-15s，教师监督 10-15s ...

图里写得很清楚：

reusing the historical KV cache each iteration to generate the next 5s clip, then supervising it with the teacher.

也就是：

每次复用历史 KV cache 生成下一个 5 秒 clip，然后用 teacher 监督这个新 clip。

十一、Teacher 是怎么监督短片段的？

这里要注意，teacher 不一定是自回归模型，也不需要 KV cache。

Teacher 可以是双向扩散模型。
这不矛盾，因为 teacher 只在训练时用来提供局部监督，不是最终部署模型。

学生模型要学会：

基于历史 KV cache 自回归生成长视频

教师模型只需要：

看当前 5 秒片段和 prompt，提供质量/分布监督

LongLive 基于 Self-Forcing / DMD，也就是Distribution Matching Distillation。

它不是简单地：

teacher 生成一个视频，student 和它做 MSE

而更像是：

student 生成当前短片段 teacher 作为冻结的视频扩散模型 对这个短片段提供去噪/score/分布匹配方向 让 student 的生成分布靠近 teacher 所代表的高质量视频分布

简化理解：

Teacher 不一定给一个固定答案，而是告诉 student：“你这个 5 秒片段应该往更像高质量视频、更符合 prompt 的方向调整。”

loss 只作用于当前新生成的 5 秒片段。

历史片段会作为条件继续使用，但通常 detach，不跨整个历史反向传播。

十二、只监督当前 5 秒，为什么还能训练长视频能力？

关键是：

当前这 5 秒不是从干净状态独立生成的，而是基于学生自己生成的历史生成的。

比如训练到第 8 段：

35s - 40s

这段的输入不是干净 GT 视频，而是：

学生自己生成的 0s - 35s 历史

这和真实推理时一致。

所以模型训练时会看到：

• 自己生成的历史；
• 历史误差；
• 历史 KV cache；
• 长时间 rollout 后的状态；
• prompt switch 后的 recache 状态；
• short window + frame sink 的真实上下文结构。

这就是：

train-long-test-long

虽然 loss 只在当前短片段上，但模型所处的状态已经是长视频推理状态。

这比 Short Tuning 更接近真实推理。

十三、为什么历史 detach 也可以？

因为 Streaming Long Tuning 的目的不是让梯度从第 40 秒一路传回第 0 秒，而是让模型学会：

在真实长视频推理状态下，怎么生成下一段

历史片段虽然 detach，但它仍然作为条件存在。

也就是：

history 负责提供真实推理状态 current clip 的 loss 负责更新模型

这样就不用保存整个长视频的计算图，自然避免 OOM。

十四、LongLive 针对什么模型做训练？

论文主要基于：

Wan2.1-T2V-1.3B

它是一个 1.3B 参数的文本到视频基础模型，原本主要生成短片段。

LongLive 不是从零训练一个模型，而是在这个基础模型上做适配和长视频调优。

整体可以理解为两阶段。

阶段一：短片段 Self-Forcing / DMD 适配

目标是把基础短视频模型变成一个：

因果 AR 支持 KV cache 可以少步快速生成 短视频质量还不错

的学生模型。

也就是先让模型具备短视频上的快速因果生成能力。

可以写成：

Wan2.1-T2V-1.3B → Self-Forcing / DMD short tuning → causal short-video student

阶段二：Streaming Long Tuning

目标是让这个短视频学生适应长视频和交互式 prompt switch。

这一阶段做：

复用历史 KV cache 学生每次生成下一个 5s clip 教师只监督当前 5s clip 历史 detach prompt switch 时执行 KV-recache 训练时使用 short window attention + frame sink

最终得到 LongLive。

十五、三张图串起来的完整逻辑

可以这样理解：

Figure 2 讲推理结构

LongLive 推理时：

用 short window attention 控制计算量 用 frame sink 保持长期一致性 顺序接收多个 prompt prompt 切换时用 KV-recache 更新缓存

Figure 3 讲为什么需要 KV-recache

三种策略对比：

不用 KV cache： 新 prompt 生效，但画面断裂 保留旧 KV cache： 画面连续，但新 prompt 被忽略 KV-recache： 画面连续，新 prompt 也生效

Figure 4 讲怎么训练这个系统

三种训练方式对比：

Short Tuning： 只会短视频，长视频退化 Naïve Long Tuning： 一次性训练长视频，OOM，teacher 监督也不可靠 Streaming Long Tuning： 学生流式生成，复用历史 KV cache teacher 只监督当前短片段 训练状态和推理状态一致

十六、最后总括

LongLive 的核心可以用一句话总结：

它把一个原本偏短视频的高质量视频模型，改造成一个可以实时、流式、交互式生成长视频的因果自回归模型。

具体怎么做到？

第一，用KV cache像语言模型一样加速视频自回归生成。

第二，用Short Window Attention只保留最近窗口的 KV，避免长视频推理越来越慢。

第三，用Frame Sink永久保留开头关键帧的 KV，避免短窗口导致模型忘记主体和场景。

第四，用KV-recache在 prompt 切换时，用 previous video latent 和 new prompt 重新计算 cache，既保留视觉连续性，又让新 prompt 生效。

第五，用Streaming Long Tuning在训练时模拟真实推理：学生基于自己生成的历史继续生成，teacher 只监督当前短片段，从而避免 OOM，也避免短视频训练、长视频测试的不一致。

所以 LongLive 的重点不是单个技巧，而是一整套闭环：

推理时怎么用 cache 训练时就怎么模拟 cache 推理时怎么切 prompt 训练时就怎么加入 recache 推理时只看短窗口 + sink 训练时也用同样结构

这就是它能做到实时交互式长视频生成的关键。