
导读:人工智能在娱乐行业的曙光开启了创造力和创新的新时代。OpenAI 的 Sora 是最具突破性的发展之一,它是人工智能与电影制作融合的工具。这项能够根据文本提示生成高质量视频的技术不仅是一种新颖的技术,而且是一种新的技术。它代表了内容创建、消费和感知方式的重大飞跃。这些进步的影响是巨大的,涉及创造力、生产效率,甚至讲故事的本质。当我们深入探讨人工智能在娱乐领域的未来时,了解 Sora 等技术的作用至关重要。
Sora 生成的视频效果好吗?确实好。Sora 算得上 AGI 发展历程上的里程碑吗?我个人觉得算。我们知道它效果好就行了,有必要知道 Sora 到底是怎么做的吗?我觉得最好是每个人能有知情的选择权,任何想知道的人都能够知道,这种状态比较好。那我们知道 Sora 到底是怎么做出来的吗?不知道。马斯克讽刺 OpenAI 是 CloseAI,为示道不同,转头就把 Grok 开源了。且不论 Grok 效果是否足够好,马斯克此举是否有表演成分,能开源出来这行为就值得称赞。OpenAI 树大招风,目前被树立成技术封闭的头号代表,想想花了上亿美金做出来的大模型,凭啥要开源?不开源确实也正常。所谓 “
开源固然可赞,闭源亦可理解”。但是,我个人一年多来的感觉,OpenAI 技术强归强,然而有逐渐把技术神秘化的倾向,如果不信您可以去读一下 Altman 的各种访谈。在这个 AI 技术越来越封闭的智能时代,技术神秘化导向的自然结果就是盲目崇拜,智能时代所谓的 “信息平权” 或只能成梦想。我不认为这是一个好的趋势,我发自内心地尊敬对技术开放作出任何贡献的人或团体,且认为
对技术神秘化的去魅,这应该是 AI 技术从业者值得追求的目标。本文试图尽我所能地以通俗易懂的方式来分析 Sora 的可能做法,包括它的整体结构以及关键组件。我希望即使您不太懂技术,也能大致看明白 Sora 的可能做法,所以画了几十张图来让看似复杂的机制更好理解,如果您看完对某部分仍不理解,那是我的问题。

Key Messages

这部分把本文关键信息列在这里,特供给没空或没耐心看长文的同学,当然我觉得您光看这些估计也未必能看明白。Key Message 1:Sora 的整体结构如下(本文后续有逐步推导过程)

Key Message 2:Sora 的 Visual Encoder-Decoder 很可能采用了 TECO(Temporally Consistent Transformer )模型的思路,而不是广泛传闻的 MAGVIT-v2(本文后续给出了判断理由,及适配 Sora 而改造的 TECO 具体做法)。Encoder-Decoder 部分的核心可能在于:为了能生成长达 60 秒的高质量视频,如何维护 “长时一致性” 最为关键。要在信息压缩与输入部分及早融入视频的 “长时一致性” 信息,不能只靠 Diffusion Model,两者要打配合。

Key Message 3:Sora 之所以把 Patch 部分称为 “Spacetime Latent Patch”,大概是有一定理由的/Patch 部分支持 “可变分辨率及可变长宽比” 视频,应该是采用了 NaVIT 的思路,而不是 Padding 方案(本文后续部分给出了方案选择原因)。

Key Message 4:目前的 AI 发展状态下,您可能需要了解下 Diffusion Model 的基本原理(后文会给出较易理解的 Diffusion 模型基本原理介绍)

Key Message 5:Video DiTs 很可能长得像下面这个样子(本文后续内容会给出推导过程)

Key Message 6:Sora 保持生成视频的 “长时一致性” 也许会采取暴力手段(后文给出了可能采用的其它非暴力方法 FDM)

Key Message 7:Sora 应该包含双向训练过程(后文给出了双向训练的可能实现机制)


为何能对 Sora 进行逆向工程


能否对 Sora 进行逆向工程,要依赖一些基本假设,若基本假设成立,则逆向工程可行,如不成立,则无希望。上面列出了 Sora 可被逆向工程的两个基本假设。首先,我们假设 Sora 并未有重大算法创新,是沿着目前主流技术的渐进式改进。这条无论是从 OpenAI 的算法设计哲学角度(我来替 OpenAI 归纳下核心思想:简洁通用的模型结构才具备 Scale 潜力,如果可能的话,尽量都用标准的 Transformer 来做,因为它的 Scale 潜力目前被验证是最好的,其它想取代 Transformer 的改进模型都请靠边站。模型结构改进不是重点,重点在于怼算力怼数据,通过 Scale Transformer 的模型规模来获取大收益。),还是历史经验角度(比如 ChatGPT,关键技术皆参考业界前沿技术,RLHF 强化学习是 OpenAI 独创的,但并非必需品,比如目前有用 DPO 取代 RLHF 的趋势)来看,这个条件大体应该是成立的。第二个条件,其实 Sora 技术报告透漏了不少关于模型选型的信息,但是您得仔细看才行。

关于 Sora 技术报告透漏的信息,这里举个例子。它明确提到了使用图片和视频联合训练模型,而不像大多数视频生成模型那样,在训练的时候只用视频数据。这是关键信息,对保证 Sora 效果也肯定是个重要因素,原因后文会谈。既然 Sora 需要图片和视频联合训练,这等于对 Sora 内部结构怎么设计增加了约束条件,而这有利于我们进行逆向工程。

再举个例子,Sora 应采取了逐帧生成的技术路线,而不像很多视频生成模型那样,采取 “关键帧生成 + 插帧” 的模式。上图中 Sora 技术报告标红圈的部分是支持这一判断的部分证据,如果您参考的文献足够多,会发现一旦提 “generating entire video all at once”,一般和 “at once” 对应的方法指的就是 “关键帧 + 插帧” 的模式。上图下方给出了 Google 的视频生成模型 Lumiere 的论文摘要(可参考:《Lumiere:A Space-Time Diffusion Model for Video Generation》),也提到了 “at once” 等字眼,表明自己用的不是 “关键帧 + 插帧” 的模式,这是把 “at once” 作为论文创新点高度来提的。“关键帧生成 + 插帧” 是视频生成模型中普遍采用的模式,但它的问题是会导致生成的视频整体动作幅度很小、而且不好维护全局的时间一致性。我们看到市面上很多视频生成产品都有这个问题,就可以倒推它们大概采用了 “关键帧 + 插帧” 的模式。可以看出,这点也是保证 Sora 视频质量好的重要技术选型决策,但若您看文献不够仔细,就不太容易发现这个点。

归纳一下,之所以我们能对 Sora 进行逆向工程,是因为前述两个基本假设大致成立,而每当 Sora 技术报告透漏出某个技术选型,就等于我们在算法庞大的设计空间里就去掉了很多种可能,这相当于通过对主流技术进行不断剪枝,就可逐步靠近 Sora 的技术真相。接下来让我们根据目前的主流技术,结合 Sora 的技术报告,假设 Sora 模型已经训练好了,来一步步推导出 Sora 可能采用的整体技术架构。

逐步推导 Sora 的整体结构


Sora 给人的第一印象是高质量的 <文本 - 视频> 生成模型:用户输入 Prompt 说清楚你想要生成视频的内容是什么,Sora 能生成真实度很高的 10 秒到 60 秒的视频。至于内部它是怎么做到这一点的,目前我们还一无所知。

首先,我们可如上图所示,技术性地稍微展开一下,细化 Sora 的整体轮廓。用户给出相对较短且描述粗略的 Prompt 后,Sora 先用 GPT 对用户 Prompt 进行扩写,扩充出包含细节描述的长 Prompt,这个操作是 Sora 技术报告里明确提到的。这步 Prompt 扩写很重要,Prompt 对细节描述得越明确,则视频生成质量越好,而靠用户写长 Prompt 不现实,让 GPT 来加入细节描述,这体现了 “
在尽可能多的生产环节让大模型辅助或取代人” 的思路。那么,Sora 内部一定有文本编码器(Text Encoder),把长 Prompt 对应的文字描述转化成每个 Token 对应的 Embedding,这意味着把文字描述从文本空间转换为隐空间(Latent Space)的参数,而这个 Text Encoder 大概率是 CLIP 模型对应的 “文本编码器”(CLIP 学习到了两个编码器:“文本编码器” 及 “图片编码器”,两者通过 CLIP 进行了文本空间和图片空间的语义对齐),DALLE 系列里的文本编码器使用的就是它。上文分析过,Sora 应该走的是视频逐帧生成的路子,假设希望生成 10 秒长度、分辨率为 1080
1080 的视频,按照电影级标准 “24 帧/秒” 流畅度来算,可知 Sora 需要生成 2410=240 帧 1080
1080 分辨率的图片。所以,若已知输出视频的长度和分辨率,我们可以在生成视频前,事先产生好 240 帧 10801080 的噪音图,然后 Sora 在用户 Prompt 语义的指导下,按照时间顺序,逐帧生成符合用户 Prompt 描述的 240 张视频帧对应图片,这样就形成了视频生成结果。

从 Sora 技术报告已知,它采用的生成模型是 Diffusion 模型,关于 Diffusion 模型的基本原理我们放在后文讲解,但现在面临的问题是:Diffusion Model 也有不同的做法,到底 Sora 用的是像素空间(Pixel Space)的 Diffusion Model,还是隐空间(Latent Space)的 Diffusion Model 呢?现在我们需要关于此做出技术决策。

在做决策前,先了解下两个空间的 Diffusion Model 对应的特点。上图展示的是在像素空间内做 Diffusion Model 的思路,很直观,就是说在像素范围内通过 Diffusion Model 进行加噪音和去噪音的过程。因为图片包含像素太多,比如 1080*1080 的一张图片,就包含超过 116 万个像素点,所以像素空间的 Diffusion Model 就需要很大的计算资源,而且无论训练还是推理,速度会很慢,但是像素空间保留的细节信息丰富,所以像素空间的 Diffusion Model 效果是比较好的。这是它的特点。

再说隐空间 Diffusion Model 的特点。最早的 Diffusion Model 都是在像素空间的,但速度实在太慢,所以后来有研究人员提出可以在对像素压缩后的隐空间内做 Diffusion Model。具体而言,就是引入一个图像 “编码器”(Encoder)和 “解码器”(Decoder),编码器负责把图片表征从高维度的像素空间压缩到低维度的参数隐空间,而在经过 Diffusion Model 去噪后,生成隐空间内的图片内容,再靠解码器给隐空间图片内容添加细节信息,转换回图片像素空间。可以看出,Latent Diffusion Model(LDM)的特点正好和 Pixel Diffusion Model(PDM)相反,节省资源速度快,但是效果比 PDM 差点。

现在来做技术选型,从 Sora 技术报告明显可看出,它采用的是 Latent Diffusion Model,这个也正常,目前无论做图像还是视频生成,很少有用 Pixel Diffusion Model,大部分都用 LDM。但是,LDM 也存在一个压缩率的问题,可以压缩得比较狠,这样速度会更快,也可以压缩的不那么狠。我猜 Sora 在 Encoder 这一步不会压缩得太狠,这样就能保留更多原始图片细节信息,效果可能会更好些。Sora 大概率会重点保证生成视频的质量,为此可以多消耗些计算资源,“以资源换质量”。Sora 生成视频速度很慢,很可能跟 Encoder 压缩率不高有一定关系。

于是,目前我们得到上图所示的 Sora 整体结构图,主要变化是增加了针对视频的 Encoder 和 Decoder,以试图加快模型训练和推理速度。另外,一般把文本编码结果作为 LDM 模型的输入条件,用来指导生成图片或视频的内容能遵循用户 Prompt 描述。

现在,我们面临新的技术决策点:对视频帧通过 Encoder 压缩编码后,是否会有 Patchify(中文翻译是 “切块”?不确定)操作?Patchify 本质上可看成对视频数据的二次压缩,从 Sora 技术报告可看出,它应有此步骤,这也很正常,目前的视频生成模型一般都包含这个步骤。而且 Sora 将他们自己的做法称为 “Spacetime Latent Patch”,至于为啥这么叫,我在后文关键模块分析会给出一个解释。另外,Sora 还主打一个 “支持不同分辨率、不同长宽比” 的图片与视频生成,为了支持这个功能,那在 Patchify 这步就需要做些特殊的处理。

于是,加入 Spacetime Latent Patch 后,目前的 Sora 整体结构就如上图所示。Patchify 一般放在视频编码器之后,而且输出时把多维的结果打成一维线性的,作为后续 Diffusion Model 的输入。

我们接着往下推导,来看下实现 Diffusion Model 时具体采用的神经网络结构,此处需注意,Diffusion Model 是种偏向数学化的算法思想,具体实现时可以采用不同的神经网络结构。其实目前 Diffusion Model 视频生成的主流网络结构一般会用 U-Net,Transformer 做 Diffusion 视频生成目前并非主流。当然,Sora 出现之后,选择 Transformer 来做 Diffusion Model 肯定很快会成为主流结构。从 Sora 技术报告可知,它采用的骨干网络是 Transformer,应该主要看中了它良好的可扩展性,方便把模型规模推上去。当然用 Transformer+Diffusion 做视频生成,Sora 并不是第一个这么做的,这再次印证了 OpenAI 经常干的那种操作,就是利用 “吸星大法” 从开源届汲取各种前沿思路,但是自己反而越来越封闭的 CloseAI 作风。

于是,我们把基于 Transformer 网络结构的信息融进去,目前 Sora 整体结构如上图所示。

让我们继续。Sora 在宣传时特别强调一个特性:可以支持不同分辨率(Variable Resolution)、不同长宽比(Various Aspect Ratio)、不同时长(Various Duration)的视频训练与生成。目前主流技术里这么做的不能说没有,但是确实极少,三者同时做到的在公开文献里我没有看到过,要做到这一点,对具体技术选型时也有不少要求,所以作为宣传点无可厚非。后文为了表达简洁些,统一以 “不同分辨率” 来同时代表 “不同分辨率和不同长宽比”,这点在阅读后文的时候还请注意。关于生成视频时长问题我们后文会单独分析。

这里先解释下什么是 “不同分辨率和长宽比”。如上图所示,其实好理解,分辨率的话一般跟图片大小有关系,图片小分辨率就低一些,图片大清晰度或分辨率就高一些,而长宽比就比如我们经常看到的短视频的 “竖屏模式” 和长视频的 “横屏模式” 等。Sora 都支持。

那为啥要支持 “不同的分辨率和长宽比” 呢?上图给了个例子,目前做视频或者图片生成的主流技术,为了方面内部处理(训练时 Batch 内数据的规则性),会把输入的图片或视频大小统一起来,比如对于不同大小的图片,通过 Crop 操作,就是在图片中心截取一个正方形的图片片段,通过这种方式把输入大小统一。而这么做的问题上图展示出来了,因为你截图,所以很容易把一个完整的实体切割开,使用这种经过 Crop 数据训练的视频生成模型,生成的人体就很容易看着不完整,而使用 “不同的分辨率和长宽比”,会保持原始数据所有信息,就没有这个问题,实体表达的完整性就会好很多。从这也可看出,Sora 为了保视频质量,真的是在视频生成的全环节都拼了全力。

我们把 Sora 这一关键特性表达到整体结构图上,就如上图所示。如果要支持这一特点,那么在 Spacetime Latent Patch 以及 LDM 这两个阶段,需要作出一些特殊的设计决策,这也是我们用来在后面推断 Sora 关键技术的重要参考和约束信息。

下一个决策点之前我们提到过,Sora 使用了图片和视频联合训练,这对于保证视频生成质量很重要。

为啥说这点重要呢?上图给了个例子(可参考:《Phenaki:Variable Length Video Generation From Open Domain Textual Description》),用户 Prompt 要求输出的视频是 “Water Color Style” 风格的,如果只用视频训练(右侧视频截图),就做不到这一点,而如果混合了 80% 的视频数据和 20% 的图片数据训练的视频生成模型(左侧视频截图),做得就不错。这是因为带标注的 < 文本 - 图片 > 数据量多,所以各种风格的图片数据都包含,而带标视频数据数量少,所以很多情景要求下的数据都没有,就导致了这种生成结果的差异。从此例子可以看出视频和图片联合训练对于视频生成质量的影响。

如果 Sora 要支持图片和视频联合训练,则需要在视频编码 - 解码器,以及 Spacetime Latent Patch 阶段做技术选型要作出独特的设计,这进一步形成了关键模块的设计约束。加上越多约束,其实你能做的技术选择就越少,就越容易推断出具体的做法。目前的 Sora 整体结构如上图所示。

Sora 的另外一大特性是能生成长达 60 秒的较长时长的视频,这点众所周知。

如果把时长要求加进去,Sora 应该会在 “视觉编码器 - 解码器” 阶段,以及 LDM 阶段作出一些独特的设计,才有可能维护这么长时间的视觉连贯性和内容一致性。把所有这些约束都加入后,我们就经过一步步推导,最终得出了 Sora 完整的整体结构,如上图所示。

如果对文生视频领域比较熟悉,我觉得从技术报告推导出 Sora 的整体结构,这事难度不算大,真正难的地方在于 Sora 关键模块具体采用的什么技术。可列出的关键技术主要有四块:
视频编码器 - 解码器,在支持 “图片 && 视频联合训练”、“视频长时一致性” 这两个约束条件下,具体模型应该如何设计?
Spacetime Latent Patch,在支持 “图片 && 视频联合训练”、“可变分辨率” 这两个约束条件下,具体模型应该如何设计?
基于 Transformer 的视频 Diffusion Model,在支持 “可变分辨率” 约束条件下,具体模型应该如何设计?(这块的长时一致性策略放在第四部分了)
Diffusion Model 阶段的长时一致性如何维护?