Kyutai开放CADRE视频编码器，面向实时世界模型

世界模型的画面够不够清楚，和按下方向键后多久能看到响应，是两件事。Kyutai 的 CADRE 把优化重点放在后者：调整视频自编码器的压缩方式，在画质、动作响应和生成速度之间重新找平衡。

据原文转述的论文结果，相关世界模型能在单张 H100 上以 20 fps 运行，响应延迟低于 230 ms。对程序员更有用的发现是：平均帧率高，交互仍可能迟钝；重建画面漂亮，也未必能生成更好的后续视频。

为什么帧率很高，操作还是跟不上

世界模型先在潜在空间（latent space）里生成内容，再由解码器还原成视频。可以把它理解成：模型先生成一份压缩后的画面描述，然后把描述展开成像素。

自编码器的压缩率写作 τ×s×s，其中 τ 是每个潜变量覆盖的帧数，s 是空间压缩倍数。压缩得越狠，后续计算通常越省，但一次打包的帧越多，动作也越容易排队。

论文把延迟写成 τ/f，再加上生成和解码时间。f 是视频帧率。假设 τ = 8、视频为 20 fps，仅分块等待就有 400 ms。原文引用的人体感知参考是：自身动作延迟超过约 230 ms，人会察觉。

吞吐量回答每秒能产出多少帧，响应延迟回答一次操作要等多久。

这个区别直接体现在对比里。LTX-2 的最高吞吐达到 87.4 fps，动作延迟却是 492 ms；CADRE-2×32×32 只有 23.4 fps，延迟反而降到 185 ms。交互场景不能只盯 fps。

CADRE 改的是压缩瓶颈和解码方法

CADRE 发布了 7 个自编码器，每个约有 476M 可训练参数，另配冻结的 86M DINOv3 ViT-B/16。编码端沿用 MIRA 的做法：DINOv3 提取每帧的图块特征，再用一个可训练的 3D 卷积压缩成 64 通道潜变量。7 个成员之间只改变这个瓶颈，方便观察压缩方式的影响。

解码端是包含 24 个模块的因果扩散 Transformer，按块流式输出。这里的「因果」指生成当前内容时不依赖未来帧。通过渐进式自蒸馏，解码只需 1 或 2 步；训练在单个阶段完成，不使用对抗损失。

作者认为，强压缩后直接用感知回归还原画面，容易得到模糊结果；扩散解码则可以采样出清晰的视频。但清晰不等于准确，仍要检查动作是否跟得上。

训练数据来自 23 个公开视频来源，约 76k 小时，覆盖网络视频、机器人、驾驶和游戏。评测时，他们为各自编码器训练相同的 1.2B 参数因果扩散 Transformer，在机器人操作 ABC、人类操作 EgoDex、驾驶 PhysicalAI AV、室内导航 RealEstate10K 四个环境中比较。每次先看 2 s 真实视频，再生成 4.8 s。

这种设计有助于比较自编码器，但每个世界模型只覆盖一个环境，分辨率为 288×512，不能直接推导到通用世界模型。

选哪种压缩，要看摄像机和动作

CADRE 在与 MIRA、Wan 2.2、Cosmos、LTX-2 的 48 项比较中，有 42 项在速度不逊于对方时质量更好。下面这些数字也显示，它并非处处领先。

自编码器	动作延迟	最高 fps	驾驶 FVD↓	机器人 FVD↓	机器人 ARR↑
CADRE-2×32×32	185 ms	23.4	171.3	105.0	0.45
CADRE-2×16×16	216 ms	17.3	162.6	47.6	0.73
MIRA recipe	175 ms	26.6	311.6	267.1	0.39
Wan 2.2 VAE	317 ms	34.2	599.7	52.9	0.85
Cosmos CV8x8x8	605 ms	39.0	452.5	39.5	0.78
LTX-2 VAE	492 ms	87.4	913.3	69.6	0.25

测试使用单张 H100、bf16、batch 1；CADRE 采用 1 步解码，量化版本未披露。所有数据均由 Kyutai 自报。

FID 主要衡量画面质量，FVD 用于评估视频分布与时序质量；ARR 通过冻结的逆动力学探针评估动作跟随，1 代表达到真实视频的参考水平。

作者给出的选型经验有三条。固定摄像机更能容忍时间压缩；移动摄像机更适合减少每块帧数、增加空间压缩；空间压缩过强时，动作质量可能先坏掉，静态画质指标却变化不大。机器人实验中，空间压缩从 16× 增至 32×，FVD 变成约 2.4 倍，FID 几乎不动。

压缩放在哪里也有影响。在 8 帧设置下，把时间聚合放到世界模型内部做 patching，ARR 从 0.72 降到 0.56。相较重新训练的 MIRA 解码器，1 步扩散解码的 FVD 降低了 1.4 至 2.5 倍。这些是实验结果；把它们推广成所有任务的选型规则，还需要更多验证。

我的判断

我认同它把动作延迟单独拿出来衡量。面向键盘控制的生成式环境，用户关心的是输入之后画面多久改变，平均 fps 无法替代这个指标。

但「低于 230 ms」不是完整的胜利。CADRE-2×16×16 延迟为 216 ms，最高吞吐却只有 17.3 fps；更快的 CADRE-2×32×32，机器人 ARR 又只有 0.45，低于 Wan 2.2 的 0.85。延迟、连续输出速度、动作准确性需要一起选。

重建指标同样不能单独决策。Wan 2.2 在 OpenVid-HD 上的 PSNR 为 35.02 dB，高于两款 CADRE 的 22.86、25.12 dB，但其室内生成序列 FVD 排在最后。这支持「重建质量不足以预测后续生成质量」，还不足以证明重建质量不重要。

长时间块也有接缝问题：τ = 8 时，各环境的边界超额指标达到 1.6 至 1.8。原文没有充分解释这个指标的直观尺度，不能把它直接当成用户体验评分。商业使用则有明确限制：代码是 MIT，权重采用 CC BY-NC 4.0，并涉及 DINOv3 License；代码开放不代表权重可商用。

能拿来做什么

• 做键盘控制的视频生成原型时，把输入到对应画面出现的延迟单独记录，再看持续 fps 和动作跟随，避免仅凭播放流畅度判断交互体验。
• 复现实验时，可先比较 CADRE-2×16×16 与 CADRE-2×32×32，观察空间压缩对速度和动作的影响；原文没有普通消费级显卡数据，不要预设本地也能达到相同速度。
• 为固定机位和移动视角分别选配置，并同时检查 FVD、ARR。只看单帧截图或 FID，可能漏掉动作失真和分块接缝。
• 可用发布的 7 个自编码器、4 个更长训练的多分辨率版本及基于 CADRE-2×16×16 的 4 个世界模型做非商业研究；商业方案应先解决权重许可问题。