当AI生成视频不再需要"压缩字典"，直接在像素上作画会发生什么

先说一件挺反直觉的事。

现在几乎所有能生成图片和视频的AI模型，背后都藏着一个叫VAE的东西。

VAE（变分自编码器）：一种把图像压缩成更小的"潜在空间"表示，再从这个压缩表示还原出图像的神经网络工具。

你可以把VAE想象成一个专业的速记员。你说一长段话，速记员不会把每个字都记下来,他会用一套只有他自己看得懂的简写符号,把你的话"压缩"成几行速记符。之后需要还原时，他再把这些符号"解压"回完整的话。问题是,如果你的任务不只是记录你说的话，还要一字不漏地保留你说话时的语气、停顿、口音,这种压缩就会丢信息。而视频和图像生成模型里的VAE,干的正是这种"速记"的活,它把像素压缩成一种更紧凑、但也更抽象的表示,模型在这个被压缩过的空间里"画画"，而不是直接在像素上画。

这套压缩再还原的流程用了很多年，大家也习以为常了。直到最近，一批研究者开始问一个看似很笨的问题：我们真的需要这个速记员吗？能不能直接在原始像素上训练模型，跳过压缩这一步？

这就是PixelUMM这篇论文要讲的故事。它出自NVIDIA和滑铁卢大学的研究团队，目标是做一个不需要任何预训练视觉编码器、不需要VAE，直接吃像素、吐像素的统一模型，而且这个模型既要能看懂图片和视频（理解），也要能画出图片和视频（生成）。

**这篇论文最打动人的地方不是它又多了一个百分点的跑分，而是它老老实实把一堆"换个设计会怎样"的实验都做了一遍，并且把代价和收益都摆出来给你看。**

这事儿到底难在哪

要理解PixelUMM解决的问题,得先搞清楚现在的统一多模态模型是怎么工作的。

统一多模态模型（UMM）：指一个系统既能理解视觉内容（看图说话、回答关于图片的问题），又能生成视觉内容（根据文字描述画图或生成视频）的AI模型。

像BAGEL这样的代表性模型，采用的是"双通道"方案：用一个ViT（视觉Transformer）专门提取图像的语义特征,负责"理解"这部分任务;再用一个VAE提取图像的重建特征,负责"生成"这部分任务。这两套特征分别送进模型的大脑里。

ViT（视觉Transformer）：一种把图片切成小块（patch），再用Transformer架构处理这些小块来理解图片内容的神经网络。

这个双通道设计听起来挺合理，理解和生成本来就是两种不同的活儿，分开处理很自然。但问题是，一张图片要同时被ViT和VAE各编码一遍,这意味着同样一张图，在模型的"视野"里要占两份token（词元）的位置。

token：模型处理信息的最小单位，可以理解为"词"或者图像的一个小块,模型的计算量和显存占用基本跟token数量成正比。

如果你需要在一次对话里塞进好几张图、一段视频、还有来回好几轮的文字交流，这种"每张图算两份"的设计会让上下文迅速膨胀，显存和计算的压力跟着飙升。更麻烦的是，这种双流输入和主流的视觉语言模型（VLM）预训练习惯的单一视觉流不一样，想把VAE token加进现有的训练管线，得大改数据处理和训练配方,这对"统一"这个目标本身是种讽刺,你想统一理解和生成，结果接口先不统一了。

于是有一批工作，比如JiT和PixelDiT，提出了另一条路:干脆别要那个压缩环节了，直接在像素空间里训练生成模型。TUNA-2、SenseNova-U1等工作把这套思路用到了图像的统一理解和生成上。

但这些工作基本都停留在图像层面。视频就麻烦多了。

视频生成常用的做法是用因果3D VAE，把视频的第一帧单独编码，后面的帧再按时间关系编码;而视频理解常用的做法是把采样出来的几帧当作独立图片，各自过一遍图像编码器。这两种约定根本不是一个体系，没法简单拼到一起去。PixelUMM要做的，就是重新设计一套图像和视频都通用的像素接口，让理解和生成共享同一套视觉表示。

像素空间里到底怎么"画"视频

PixelUMM的做法，是把图片切成16×16的小方块（patch），把视频切成4帧×16×16的小方块（tubelet）。

patch（图像块）/tubelet（时空块）：patch是把一张图切成的若干个小方格，每个方格里的像素被当作一个处理单元；tubelet是patch在视频里的升级版,不仅切空间，还把时间维度也切开,比如把4帧×16像素×16像素的一小块时空区域打包成一个单元。

切好之后，每个patch或tubelet只经过一层简单的线性层，就直接映射成Transformer能处理的向量。输出的时候反过来，一层RMSNorm加一层线性层，再把向量还原成像素。整个过程里,没有任何预训练的视觉编码器、没有VAE、没有离散视觉词表,从像素到模型大脑，再从模型大脑回到像素，中间就隔着两层最朴素的线性变换。

这里有个挺讲究的细节:理解任务和生成任务，用的是两套不同的线性层。干净的图片和视频走"理解投影"，被加了噪声的生成目标走"生成投影"。这两套参数看起来做的是类似的事,都是把像素映射成向量,但PixelUMM坚持把它们分开。

这就好比一家餐厅同时做外卖打包和堂食摆盘。外卖打包要考虑路上不能洒、不能凉;堂食摆盘要考虑颜值和出餐速度。你可以让同一个厨师用同一口锅炒菜,这是共享的部分,但打包和摆盘这两个"最后一步",最好让两个不同的人专门负责,因为他们要优化的目标根本不一样。如果硬要用同一套逻辑去处理"看图"和"画图"这两件事，模型很容易在两头都做得不够好。

为了让理解专家和生成专家各自专心做自己的事，同时又能共享对世界的整体认知，PixelUMM用了一种叫Mixture-of-Transformers（专家混合Transformer，简称MoT）的架构。

MoT架构：让模型的每一层都有两套独立的归一化层、注意力投影和前馈网络（分别服务于理解和生成），但所有token仍然在同一个自注意力机制里互相"看见"对方。

这意味着文本token和干净的视觉token走理解通道，带噪声的视觉token走生成通道，两条通道在参数上是分开的，但在注意力这一步是打通的，信息可以自由流动。

还有一个挺有意思的省略：PixelUMM没有像BAGEL那样搞一套显式的"时间步嵌入"（告诉模型现在加噪加到了第几步）。它让去噪网络直接从带噪的像素本身去猜测当前的噪声程度有多大。这就像一个经验丰富的调酒师,不需要你告诉他"现在是第三次加水"，他尝一口就知道现在这杯酒兑稀到什么程度了,凭的是感觉而不是刻意记的步数。

视频理解和视频生成，接口怎么对齐

视频这块最棘手的问题是帧率。不同视频的帧率五花八门，有的是30帧每秒，有的可能才1帧每秒。PixelUMM设计了两种模式来应对：

dense_mode（密集模式）与sparse_mode（稀疏模式）：当输入视频帧率不低于4FPS时，用dense_mode，按4FPS采样并把每4帧打包成一个tubelet走视频理解投影；当帧率低于4FPS时，用sparse_mode，按1FPS采样，每一帧单独走图像理解投影，避免硬凑帧数造成的浪费。

有意思的是，论文专门做了个实验对比这两种模式在视频理解任务上的表现（这个实验被编号为F8），结果显示：MVBench上dense_mode只比sparse_mode高0.07分，Video-MME和LongVideoBench上dense_mode反而低了0.22和0.68分，LVBench完全没差别。换句话说，更高帧率、带时间压缩的输入，并没有换来明显更好的理解效果。这是个挺打破预期的结果,直觉上帧率越高信息越全，应该更准，但数据说没有必然联系。

在attention（注意力机制）的设计上，PixelUMM也做了区分。图像内部是双向注意力，所有patch互相看得见；视频的多帧之间是按时间顺序的单向流动，后面的帧能看到前面的帧，前面的帧看不到后面的,这很符合常识，毕竟现实里你不能"看见未来"；生成任务里，带噪的目标token可以双向看整个生成目标块，同时能看到前面的文字提示，但干净的上文看不到后面要生成的噪声内容。

四个核心任务怎么塞进一个对话格式

PixelUMM把图像理解、视频理解、文生图、文生视频这四个任务，都统一塞进了一种叫ChatML的对话格式里。

这套设计的好处是，理解和生成不再是两个互相隔离的系统，而是同一个对话流程里的不同环节,文字提示词可以直接"指挥"后面的像素生成，而生成出的像素又可以被同一个模型拿来做进一步理解或编辑。这解决的核心矛盾是：如果理解和生成用两套完全独立的表示和流程,就很难支持"看一张图，编辑它，再看编辑结果"这种链式的多轮任务。

接下来是最有价值的部分：那些没有被写进最终模型，却被诚实记录下来的实验

这篇论文有个挺少见的做法：专门开了一节，把各种"如果换个设计会怎样"的对照实验一条一条列出来，连带每条实验在训练曲线和生成图片上的具体差异,哪怕有些设计最终没被采用。这种诚实程度在论文里不算常见。

patch切得越小,学习越容易,但处理量更大

研究者做了个对照实验：用16×16的patch和用32×32的patch，分别训练一个一模一样的模型，看谁学得更快。

在同样的序列长度预算下，32×32的patch能塞进四倍数量的图片,毕竟每张图被切得更"粗"，占的token更少，一个训练步能处理更多图。但结果恰恰相反：16×16的模型训练损失（衡量生成质量的指标，越低越好）始终更低，收敛更稳定。即使32×32的模型见过了四倍的数据量，它依然没能追上16×16模型的表现。

这就像搬家打包。你可以把家具拆得特别碎、塞进很小的箱子里，这样一次能搬更多箱子;但拆得太碎之后，到了新家重新组装的难度会指数级上升,零件太多太细，你很容易装错、装漏。patch切得越大（32×32），相当于把图像信息压缩得更粗暴，模型要从这种粗粒度的信息里"猜"出细节,这件事天生就比从细粒度信息里学习更难，不管你喂给它多少数据。

这个结论直接推翻了一个很自然的直觉：以为"数据量大就能补偿压缩损失"，但实验告诉你,有些信息损失，光靠加数据是补不回来的。

视频patch怎么切,压缩越狠，学得越费劲

类似的实验也在视频上重复了一遍，这次编号为F2。研究者测试了四种时空patch配置：32×32空间×4帧、32×32空间×2帧、16×16空间×4帧、32×32空间×1帧（单帧,相当于基本没有时间压缩）。

结果呈现出清晰的规律：压缩程度越低（也就是一个token对应的原始像素越少），训练损失越低，其中32×32×1帧这种几乎不压缩时间维度的配置表现最好。但PixelUMM最终选用的是16×16×4帧，原因不是它表现最好，而是因为这个配置和业界常用的视频VAE（比如Wan2.2）的空间时间压缩比例一致,方便和现有生态对齐。

这里藏着一个挺现实的取舍：最优的技术方案和最实用的工程方案，经常不是同一个。研究者选了后者,这个决定本身就值得记一笔,因为它说明"统一"这件事，有时候要向生态系统的现实让步，而不是一味追求纸面上的最佳性能。

像素级输出会留下"棋盘纹"，怎么办

这是整篇论文里我觉得最有画面感的发现。当用较高的CFG（classifier-free guidance，分类器自由引导，一种控制生成结果多大程度服从文字提示的采样技巧）生成图片或视频时，画面里那些本该平滑的区域（比如天空、墙壁）会出现一种很淡但能看出来的网格状痕迹，边界刚好对应patch的边缘。

这个现象其实很好理解。模型是按一个个patch独立预测像素的，哪怕共享了上下文信息，不同patch之间的输出在数值上多少会有点不连续,就像拼图拼接处那道若隐若现的缝。

研究者试了三种卷积风格的输出头来缓解这个问题，分别叫"Wan风格的上采样加卷积"、"时间优先的PixelShuffle"和"空间优先的PixelShuffle"。PixelShuffle是一种通过重新排列通道和空间维度来实现上采样的操作，不需要额外的卷积计算，效率更高。

实验结果挺有意思：Wan风格的卷积头确实把网格痕迹压得最干净，但训练损失一直卡在0.05以上，比PixelShuffle高出一截，生成的画面也更模糊;两种PixelShuffle方案则在训练损失和纹路抑制之间找到了更好的平衡点，其中时间优先版本略微优于空间优先版本。

这就像去除衣服上的褶皱。你可以用高温蒸汽熨斗用力压，褶皱肯定能烫平，但布料的纤维也可能因为高温受损、变得发硬发亮;或者你选择低温慢慢熨，褶皱去得没那么彻底，但布料的质感保留得更好。没有一种方法是零代价的，你总要在"彻底消除某个瑕疵"和"保留别的东西"之间做取舍。

不过有个前提要说清楚：虽然卷积头效果更好,但因为把输出头从线性换成卷积需要重新训练，PixelUMM最终发布的模型、论文里的性能评测、以及展示图，用的仍然是最朴素的线性输出头。这些卷积方案的价值目前还停留在"我们验证过这条路能走通"的阶段。

像素空间和VAE空间，谁学得快

这个实验（F4）对比了直接在像素上训练和在VAE压缩后的潜在空间里训练，两者的早期训练动态。研究者特别提醒了一句很重要的话：两种设置下记录的损失数值不能直接比大小，因为它们计算损失的"空间"根本不同,一个是像素空间的误差,另一个是VAE潜在空间的误差,量纲都不一样。单纯看谁的损失数字更小，没有意义。

唯一能比较的是梯度范数，结果显示两者几乎相等，说明优化过程的"剧烈程度"是类似的。像素空间的训练偶尔会出现损失突然跳高的尖峰，这个现象目前论文里没有深究原因,只是诚实地记录下来了。

模型越大,学得越快,但快多少跟任务有关

研究者还做了模型规模的对比，把1.7B参数和8B参数的模型用完全相同的训练配方跑了一遍。结果是8B模型用大约三分之一的训练步数就达到了和1.7B模型相当的损失水平,这个加速比例看起来挺诱人。

但紧接着的另一个实验（关于分布式计算规模）揭示了更微妙的东西：把GPU数量从8张加到128张，对文字部分（交叉熵损失）的收敛速度提升特别夸张，大概是9倍,CE损失到1.0只需要大约2000步，而小规模训练要17500步;但对图像生成部分（MSE损失）的提升就温和多了，只有1.3倍左右。

这说明一件事：更多的计算资源、更大的模型，并不是对所有任务"一视同仁"地有效。文字预测这种相对规整的任务，吃计算资源吃得更"香"，而像素级的生成任务,本质上是在拟合一个连续的、高维的分布,从更多计算里能榨取的边际收益明显更少。

视觉条件引导生成，理解能力会被拖垒吗

PixelUMM还支持一种叫"多模态上下文条件"的能力,就是让一张参考图或一段参考视频，通过理解专家进入模型的上下文，然后让生成专家根据这些条件去合成新的内容。这正是图像编辑、视频编辑、图生视频这些任务的基础。

这套设计最大的好处是，干净的条件图像走理解通道，不需要像BAGEL那样额外搭一套VAE token的"第二条线"。研究者专门做了个对照实验（F7），看模型在学会这种视觉条件能力之后，原本的理解能力会不会退化。

结果是好坏参半但不算灾难性的：BLINK提升了2.37分，CV-Bench提升了2.27分，四个视频理解基准全部有0.89到3.49分的提升;但SEED-I掉了5.41分，CountBench、PixMo-Count、V*也都有不同程度的下降。

这组数字提醒我们一件容易被忽视的事：给模型加新能力，不是纯粹的"叠加"，而是一种此消彼长的权衡。有些理解任务会因为多任务训练而变强，有些则会被挤占了注意力而变弱。这不是PixelUMM独有的问题，几乎所有多任务学习系统都要面对这种拉扯。

最终的跑分成绩单

把这些设计决策综合起来之后，PixelUMM在一系列公开基准上做了测评。在图像理解方面，它在MMMU上拿到41.67分、ChartQA上82.96分、OCRBench上78.00分，和BAGEL、TUNA-2等同类统一模型相比属于中等偏上水平，但距离专门做理解任务的VLM（比如Qwen3-VL的69.60分MMMU）还有明显差距。

在视频理解上，PixelUMM在MVBench拿到70.53分，是和它对比的几个统一模型里最高的（Show-o2只有49.80，TUNA是54.40，Lance是62.00）；在图像生成的GenEval基准上，综合得分0.83，在同类统一模型中处于中上游；视频生成方面，在VBench上的总分和UniVideo、TUNA等模型互有胜负，没有绝对碾压，但确实站稳了"能打"的位置。

论文特别强调了一句很诚实的话：由于各模型训练数据不同，这些对比结果不能用来断定哪种架构天生更优越，或者哪个模型收敛更快。这是一种少见的克制，很多论文在跑分漂亮的时候，是不愿意主动加这种免责声明的。

Q&A

Q1：PixelUMM和BAGEL这类模型最大的区别是什么？

A：BAGEL用ViT提取理解特征、VAE提取生成特征，一张图要占两份视觉token；PixelUMM完全不用任何预训练视觉编码器或VAE，图片和视频都直接切成像素patch或tubelet，经过一层线性投影就进入模型，理解和生成共享同一套像素接口。

Q2：PixelUMM里的patch切得越小，训练效果一定越好吗？

A：实验显示16×16的patch比32×32训练损失更低，即使32×32在同样序列预算下能处理四倍数据量也追不上。但论文没有测试更小的patch，所以"越小越好"不能简单外推，研究者认为未来可以探索更大patch（64）是否在更大算力下表现不同。

Q3：PixelUMM生成的图片为什么会出现网格状痕迹？

A：因为模型是按patch独立预测像素的，不同patch拼接处容易有数值不连续，在高CFG引导和平滑区域（比如天空）特别明显。论文测试了卷积风格的输出头来缓解，其中PixelShuffle方案在训练损失和纹路抑制之间效果最平衡，但目前发布模型仍用线性头。