具身智能 | WorldVLN前序：InfinityStar 与 TimeSformer

转载自公众号：敢敢AUTOHUB

0. 简介

InfinityStar 构建了一条完整的离散自回归视频生成流水线。它先用视频 VAE 把图像或视频压缩成连续 latent，再用多尺度 BSQ/LFQ 量化器把 latent 转成离散 bit token；随后，Infinity 自回归 Transformer 根据文本条件、历史视觉 token 和尺度信息预测后续 token；最后，系统把预测 token 转回 latent，并交给 VAE decoder 还原成视频。这个流程的重点在“可预测的离散视觉序列”，而不是单独更换 decoder。

在官方代码中，infinity/utils/load.py 负责加载 visual tokenizer，infinity/models/videovae/models/wan_bsq_vae.py 中仍然定义并使用 CogVideoXDecoder3D，infinity/models/infinity.py 则承担自回归 Transformer 的主体工作。主要工作在于视觉 token 的离散化、多尺度时空调度、4D 位置编码和稀疏注意力组织方式。

1. InfinityStar 要解决的问题

1.1 扩散视频模型为什么慢

扩散视频模型的基本思路是从噪声中逐步去噪，直到得到清晰的视频。这个过程很适合生成细节丰富的图像和视频，但推理时往往需要几十步甚至更多步的迭代。视频又比图像多了时间维，高分辨率视频还会带来更大的空间网格，因此总计算量会快速上升。对于离线创作，这种等待还可以接受；但对于实时视频编辑、交互式视频生成、云端渲染和游戏内容生成，分钟级等待会直接限制产品形态。

InfinityStar 选择自回归路线，本质上是在寻找另一种计算组织方式。自回归模型不需要反复去噪，而是按 token 顺序生成内容，更接近语言模型的生成方式。它可以利用缓存，也更天然支持续写和交互。然而视频 token 远比文本 token 密集，如何在速度和质量之间取得平衡，是这条路线一直难以突破的核心问题。

1.2 自回归视频生成为什么难

文本自回归模型面对的是离散词元，词表稳定、序列结构明确；视频自回归模型面对的是连续像素世界，必须先把图像和视频压缩成离散 token。这个转换一旦做得不好，就会出现两个问题：token 太粗会损失纹理和结构，token 太细又会让序列长度过长，导致训练和推理成本失控。尤其是 720p 视频，空间维度和时间维度叠加后，朴素展开会产生极长序列。

此外，视频不仅要 “每一帧好看”，还要 “帧与帧之间合理”。静态纹理、物体边界、镜头运动、主体动作、遮挡变化都需要被统一建模。如果模型只关注空间，很容易生成像幻灯片一样的结果；如果只关注时间，又会丢失画面细节。InfinityStar 的难点正是在一个离散自回归框架里同时兼顾 空间纹理、时间运动、跨帧一致性和长上下文引用。

1.3 InfinityStar 的路线选择

InfinityStar 的做法可以概括为三句话：用强视频 VAE 保住重建质量，用离散量化器把 latent 变成可预测 token，用时空金字塔和稀疏注意力降低长序列压力。自回归视频生成不一定只能停留在低分辨率或玩具级 demo。只要 Tokenizer、时空金字塔、4D RoPE、稀疏注意力和 AR 预测头 配合得当，自回归模型也可以进入高分辨率视频生成场景。对工程实现来说，这比“换一个 Transformer”更重要，因为真正影响结果的是 整条系统链路，而不是某个模块的名称。

2. 官方整体流程

2.1 从像素到 latent

官方流程的第一步是用视频 VAE encoder 压缩像素。输入视频可以表示为 [B, 3, T, H, W]，经过 encoder 后变成低分辨率 latent。这个 latent 保留了重建视频所需的主要视觉信息，但空间分辨率和时间分辨率都被压缩，因此后续模型不必直接面对原始像素。代码中 AutoencoderKLCogVideoX.encode_for_raw_features 会完成这类编码，并在内部进行 patchify、投影和缩放。

这一步的作用类似“把高清视频装进更小的容器”。如果容器设计得太小，重建时细节会丢失；如果容器太大，自回归 Transformer 又会承受过长序列。InfinityStar 没有从零设计一个完全离散的视频 tokenizer，而是在已有连续视频 VAE 的基础上插入离散化机制，这样可以 继承 VAE 的重建能力，同时获得 离散 token 的可预测性。这里要注意，VAE encoder 负责压缩像素，不直接负责生成，它只是把视频变成更短、更易建模的 latent 表示。

2.2 从 latent 到离散 token

连续 latent 不能直接作为自回归分类目标，因为它是浮点数空间。InfinityStar 使用多尺度 BSQ/LFQ 量化器，把 latent 或 latent 残差转换成 bit label。代码中的 MultiScaleBSQTP、lfq_detail、lfq_semantic 等模块对应不同尺度和不同维度的量化。低分辨率尺度更偏语义结构，高分辨率尺度更偏细节纹理，这样模型可以先预测大体结构，再逐步补充高频信息。

从训练角度看，自回归 Transformer最终预测的是每个 bit 的类别，而不是直接回归像素。这让训练目标变得接近语言模型中的 token prediction。不同的是，视觉 token 带有尺度、时间和空间位置，不能只靠一维位置表示，因此后面还需要4D RoPE 和特殊 attention mask来帮助模型理解每个 token 的时空含义。也就是说，量化器真正完成的是把 “连续 latent 回归”转成“离散 bit 分类”，这是自回归视觉生成能够稳定训练的关键。

2.3 从 token 回到视频

推理阶段，Infinity Transformer 预测出的 bit token 不能直接显示成视频，必须先通过 indices_to_codes 转回量化 latent。随后，系统按多尺度 schedule 把不同尺度的 code 插值到目标大小并累加残差，最后调用 VAE decoder 解码成像素视频。代码中的 infinity/schedules/infinity_elegant.py 负责这部分逻辑，video_decode 会把所有预测尺度重新拼成可解码 latent。

这也是为什么 decoder 改造不能孤立进行。Transformer 负责预测 token，VAE decoder 负责还原像素，中间必须守住 token -> latent -> pixel 的接口闭环。只要 decoder 的输入形状、latent 分布或量化尺度被改动，就可能影响整个闭环。如果只是加入一个 TSFormer latent refiner，保持输入输出仍为 [B, C, T, H, W]，对原系统影响较小；如果完全替换 decoder 或改变 latent channel，就必须同步修改 tokenizer、训练缓存、推理脚本和可能的自回归预测 head。

3. 视觉分词器

3.1 为什么需要 tokenizer

视觉 tokenizer 的任务是把连续图像或视频变成离散 token。对自回归生成来说，这是基础设施。如果没有 tokenizer，Transformer 就要直接预测像素或连续 latent，训练难度和输出稳定性都会很差；如果 tokenizer 质量不够，模型生成再准确也只能还原出模糊、破碎或闪烁的视频。因此，InfinityStar 的性能并不只来自 Transformer，也来自 tokenizer 对视觉世界的压缩和离散表达能力。

优秀的视频 tokenizer 要同时满足三个条件：压缩率高、重建质量高、token 语义稳定。压缩率高可以降低序列长度，重建质量高可以保住画面细节，语义稳定则让自回归模型更容易学习 token 之间的关系。InfinityStar 通过继承连续视频 VAE 的重建能力，并在中间插入多尺度量化器，试图同时满足这三个条件。换句话说，Tokenizer 决定生成上限，后面的 Transformer 只能在 tokenizer 定义出的离散视觉空间里生成内容。

3.2 连续 VAE 与离散量化器的关系

连续 VAE 可以理解为“压缩和解压工具”，它擅长把视频变成 latent，再把 latent 还原成视频。离散量化器则像“编码字典”，它把 latent 中的连续数值转成可分类、可预测的离散 bit。两者结合后，系统既保留了 VAE 的重建能力，又获得了自回归模型需要的 token 形式。官方代码里，VAE decoder 并没有消失，而是继续承担最后的像素重建。

这个关系可以用一个简单流程理解：video -> VAE encoder -> latent -> quantizer -> bit tokens -> Transformer prediction -> codes -> VAE decoder -> video。其中，Transformer 只负责预测离散 token，不直接画视频；真正把 latent 变回像素的仍是 decoder。后续如果改造 decoder，必须尊重这条接口边界。

3.3 多尺度残差量化的直观理解

多尺度残差量化的直观含义是：不要让模型一次性预测完整视频，而是 先预测粗尺度结构，再预测剩余误差。粗尺度负责 场景布局、主体形状和整体运动，高尺度负责 纹理、边缘和局部细节。每一层都在回答一个问题：“在已有重建结果的基础上，还缺什么？”这种方法让生成任务变得更分层，也让高分辨率视频的 token 预测更可控。

在代码逻辑中，可以看到系统会维护 cum_var_input，然后计算当前目标 target 与累计结果之间的残差 residual。残差被下采样到当前尺度后进入量化器，得到 bit indices；解码时再把 code 插值回目标大小并累加。这样做比直接量化完整 latent 更适合高分辨率生成，因为它把复杂视觉信息拆成了多个 逐步修正的子任务。

4. 时空金字塔

4.1 先生成空间外观

时空金字塔的第一层可以看作视频的空间底座。对于图像或视频第一帧，模型主要需要确定物体、背景、材质、颜色和构图，这些信息更偏空间外观。代码中的尺度可以表示为 (pt, ph, pw)，其中 pt=1 时更像图像尺度，ph/pw 表示 latent 网格大小。模型先在低空间分辨率上确定大结构，再逐步补充更高空间分辨率的细节。

这种设计的好处是让模型先学 “画面是什么”，再学 “画面如何动”。如果一开始就把所有时间和空间 token 混在一起，模型需要同时处理纹理、运动、遮挡、镜头变化等多种因素，学习难度会显著增加。把第一帧或图像尺度作为底座，可以让后续视频片段更容易保持主体一致和风格一致。这里的 pt=1 可以理解为 空间外观锚点，后续视频尺度再在这个锚点上生成运动。

4.2 再生成时间运动

空间外观确定后，模型开始生成视频片段的时间运动。视频尺度中 pt 大于 1，表示一个压缩后的时间片段。每个片段仍然有多级空间尺度，所以它不是简单地“一口气生成所有帧”，而是在时间片段内继续按空间层级补充细节。这样模型既能看到片段级运动，又能保留逐尺度细化的能力。

对于长视频或交互式视频，时空金字塔还可以按 clip 向后扩展。已有片段会成为后续片段的上下文，新片段只需要在相关历史信息基础上继续生成。官方infer_interact_480p.py和 480p 变长视频设置就体现了这种续写思路。这里的核心不是无限上下文，而是有选择地引用历史尺度，让长视频生成保持可计算。

4.3 为什么能统一图像、视频和续写

在这套表示下，图像生成就是只生成 pt=1 的空间尺度；视频生成是在图像尺度后继续生成视频尺度；图生视频是把参考图像编码成上下文，再生成后续运动；视频续写则是把已有视频片段编码成历史 token，再预测后续 token。任务形式不同，但底层都是“给定条件，按时空尺度预测离散视觉 token”。

这就是 InfinityStar “统一”二字的实际含义。它不是为每个任务单独训练一套完全不同的网络，而是通过尺度调度和条件输入变化，让同一个自回归框架覆盖多个生成任务。对于工程系统来说，这种统一性很重要，因为 训练、推理、缓存、调度和部署可以复用同一套底层逻辑。

5. Infinity Transformer

5.1 文本条件如何进入模型

InfinityStar 使用文本编码器把 prompt 转成 hidden states，再通过 text_norm 和 text_proj 投影到 Transformer 的模型维度。视觉 token 经过 word_embed 映射后，会和文本 token 一起进入 Transformer。训练时还会使用 classifier-free guidance 相关机制，让模型学习有条件和无条件两种生成方式，推理时再通过 guidance 强化文本遵循度。

从工程角度看，文本不是简单拼在 prompt 字符串里，而是 作为一段可被注意力访问的条件 token。视觉尺度 token 可以看见文本条件，文本 token 自身也有有效长度和 mask 控制。这个设计让模型在预测每个视觉 bit 时都能参考 prompt 语义，例如主体、风格、镜头、动作和场景描述。

5.2 4D RoPE 表达什么

普通语言模型的一维位置编码只需要回答“这是第几个 token”。视频生成不够用，因为视觉 token 同时属于某个尺度、某个时间位置、某个高度位置和某个宽度位置。InfinityStar 使用 4D RoPE，把 scale、frame、height、width 四类位置分别编码，再组合成每个视觉 token 的旋转位置嵌入。这样模型能区分 “同一空间位置的不同时刻” 和 “同一时刻的不同空间位置”。

官方代码中precompute_rope4d_freqs_grid会预先生成 scales、frames、height、width 的频率缓存。推理和训练时，当前尺度的 token 会拿到对应的 4D 位置编码。对于多尺度时空生成，这个设计非常关键，因为不同尺度的 token 并不是简单线性排列；没有明确的位置结构，模型很难知道某个 token 到底是在补空间细节，还是在补时间运动。

5.3 稀疏注意力如何降低上下文压力

如果视频 token 全部做全局注意力，计算和显存都会随序列长度快速增长。InfinityStar 使用基于尺度关系的注意力 mask，让每个尺度 只关注自己、文本条件和必要的历史尺度。代码中 flex_attn_mask.py 会根据 super_scale_lengths 与 querysid_refsid 构造 block mask，再交给 FlexAttention 执行。这种方式让模型按生成结构组织上下文，而不是盲目看完整历史。

可以把它理解为一种 “有选择的回看”。生成当前尺度时，模型不需要读完所有早期细节，只需要读取对当前预测有帮助的上下文。例如后续视频片段可能主要参考前一个片段的关键尺度，而不是每一个低层 token。这样既节省计算，也减少无关 token 对注意力的干扰。

6.TimeSformer 与 TSFormer 思路

6.1 TimeSformer 原本是视频理解模型

TimeSformer 是 Facebook AI 在 ICML 2021 发表的视频理解模型，原任务是动作识别和视频分类。它把视频拆成 frame-level patches，再用 Transformer 在时间和空间维度上建模。论文指出，在多种注意力方案中，divided space-time attention 表现最好：也就是每个 block 内先做时间注意力，再做空间注意力。

需要注意，TimeSformer 的原始输出是分类结果，它使用 cls_token 汇聚整段视频信息，再接分类头。VAE decoder 的目标完全不同：decoder 要输出 dense reconstruction，每个位置都要保留局部结构和像素重建信息。因此，TimeSformer 可以提供注意力结构思路，但不能作为 decoder 原样复制。二者真正能迁移的是 时空注意力结构，不是分类头。

6.2 Divided Space-Time Attention 的核心

Divided space-time attention 的核心是把一个大问题拆成两个较小的问题。第一步固定空间位置，在不同时间帧之间做 temporal attention，让模型理解这个位置随时间如何变化；第二步固定时间帧，在同一帧内不同空间位置之间做 spatial attention，让模型理解画面内部结构。相比把所有 T*H*W token 混在一起做 joint attention，这种拆分通常更省计算，也更有利于视频结构建模。

迁移到生成任务时，最有价值的是这种拆分方式。对于 latent decoder，可以先让每个空间位置沿时间维交流，减少闪烁和运动不连贯；再让同一时间帧内的空间 token 交流，提升结构和纹理一致性。这样 TSFormer block 就成为一个 dense feature refinement 模块，而不是分类模型。TSFormer 风格 decoder 必须 保留 dense token 输出，不能把信息汇聚到单个 cls_token。

6.3 为什么不能直接照搬分类模型

分类模型关心的是全局语义，它可以把所有信息压到一个 cls_token 中；decoder 关心的是局部还原，它必须保留每个时空位置的细节。如果把 TimeSformer 的 cls_token 分类逻辑照搬到 decoder，重建任务会失去 dense 输出结构。正确做法是 删除分类头和 cls_token 汇聚逻辑，保留每个 token 的输出，并把输入输出都保持为 [B, C, T, H, W]。

此外，TimeSformer 的输入是 RGB patch embedding，而 VAE decoder 的输入是 latent feature。两者分布不同、通道数不同、训练目标不同。迁移时必须重新设计输入投影、位置编码、归一化、残差连接和初始化策略。官方 TimeSformer 中 temporal_fc 的零初始化是一个可借鉴的稳定训练技巧，但它服务于新模块平滑接入，而不是直接复制原网络。这里要抽取的是 “时间注意力 + 空间注意力”的 dense refinement 思想。

7. 参考资料

1. InfinityStar arXiv 页面：https://arxiv.org/abs/2511.046752. InfinityStar 官方 GitHub 仓库：https://github.com/FoundationVision/InfinityStar3. InfinityStar Hugging Face 权重页：https://huggingface.co/FoundationVision/InfinityStar4. TimeSformer arXiv 页面：https://arxiv.org/abs/2102.050955. TimeSformer 官方 GitHub 仓库：https://github.com/facebookresearch/TimeSformer6. 本地代码核查版本：InfinityStar commit 7465753，TimeSformer commit a5ef29a。