Sora 火了之后，视频生成这个赛道一下变得拥挤起来。每天刷 arXiv、GitHub Trending，你会发现一个新信号：不管闭源厂商还是开源社区，新一代视频模型的架构选择都惊人统一——DiT，Diffusion Transformer。Sora 的技术报告没把网络结构细节全部抖出来，但明确写了 backbone 用的是 DiT，就这一句话，基本给行业派发了标准剧本。后续 Open-Sora、CogVideoX、HunyuanVideo 这一批模型，主干全是 DiT 或者它的变体。
DiT 全称 Diffusion Transformer，翻译成大白话是“把扩散模型里的去噪骨干网络从 U-Net 换成 Transformer”。它解决的问题很直接：视频生成既要有逐帧的高清细节，又要保持长远的时空一致性；过去的卷积网络擅长前者，却很难搞定后者。DiT 用 Transformer 的全局注意力统一处理时空信息，让模型在更大数据、更大算力下还能继续涨能力。
这篇漫话不打算贴一大堆源码，而是把 DiT 的关键组件、架构选型和工程落地的坑一次性讲清楚。想看明白 Sora 之后为什么大家都在“抄剧本”的读者，或者正准备入局视频生成、想做二次开发和微调的工程师，都适合往下看。
1. 从 U-Net 到 DiT：视频生成架构的“同一本剧本”
1.1 从“噪点里长图”说起：扩散模型的基本盘
要理解 DiT，先把扩散模型这个底子说清楚。扩散模型的核心思想是两步走：前向过程不断往干净数据上加噪声，直到它变成一坨纯噪声；反向过程则是训练一个神经网络，从噪声里一步步把数据“捞”回来。整个过程由一个噪声调度器控制，在某个时间步 t 下，真实样本 x 会变成带噪的 x_t，模型要做的，就是根据这个 x_t、当前时间步 t 以及条件信息（文本、图像、类别等），预测出被加进去的噪声，或者是 flow matching 里常说的速度场。
训练过程听起来很像“作弊”：不需要复杂的对抗博弈，只需要随机采样时间步、加噪、让网络预测噪声，然后算一个 MSE loss 就完事。Sora 也好，开源的视频模型也好，底层都是这套游戏规则。视频生成一般不会直接作用在原始像素上，而是先把视频通过一个自编码器压缩到隐空间，在隐空间里做扩散和去噪，最后再解码回像素画面。这一步很像先用 ZIP 压缩视频，在压缩后的“精华”里作画，再解压回完整视频，能大幅降低计算量。
1.2 U-Net 时代：局部归纳偏置的双刃剑
在 DiT 成为主流之前，扩散模型的去噪网络几乎被 U-Net 垄断。U-Net 是卷积网络的代表，里面大量使用卷积核，再配合一些注意力模块。卷积核的感受野天生就是局部的，这种“局部归纳偏置”对图像纹理和细节建模非常友好，训练起来也相对稳定，参数效率很高，早期效果确实能打。
但到了视频生成，问题就来了。视频多了一个时间维度，模型不仅要理解单帧里有什么，还要理解一个物体从左走到右之后，它的外观、形变、遮挡关系该怎么连续变化。卷积的局部感受野很难做到这种长程的时空依赖，于是大家开始打补丁：有的在 U-Net 里加入时间维度的 3D 卷积，有的在相邻帧之间加时序注意力，有的把整个视频切成片段再拼接。你会发现，这些方案本身没有统一范式，更像是在一个原本为图像设计的骨架上不断贴膏药。每换一个数据集，每换一个视频长度，都要重新调一堆结构，扩展性很差。
1.3 DiT 的登场：Transformer 担任去噪骨干
2022 年底，论文《Scalable Diffusion Models with Transformers》把 Transformer 直接搬进了扩散模型。作者把图像切成 patch，喂给标准的 Transformer block，用自适应层归一化注入时间步和类别条件，在 ImageNet 生成任务上拿到了当时最好的 FID，同时也证明了一件关键的事：模型参数量越大、数据量越大，效果还能继续涨，这就是扩展性。
Sora 出现之后，DiT 几乎成了视频模型的默认答案。OpenAI 没有公开 Sora 的完整结构，但一句“we use a DiT backbone”已经足够说明方向。对于从业者来说，这句话比什么都重要：它告诉大家，视频生成不再需要发明一种全新结构，只需要把 DiT 从图像扩展到三维时空 patch，并且把数据规模和算力堆上去，就能做出 Sora 级别的效果。
1.4 大家都在抄什么：主干一致，细节各有私货
说“所有视频模型都在抄同一个剧本”，这里的“所有”当然是夸张说法，准确讲是绝大多数新一代视频模型在主干上极度趋同。抄的核心是什么？就是把视频通过时空自编码器压缩成隐空间，然后切成时空 patch，丢进 Transformer block，用扩散或流匹配目标训练，最后解码成视频。
但每个团队都会往这套主干上塞自己的私货。CogVideoX 用 3D VAE 做时空压缩，压缩率很高；HunyuanVideo 采用双流到单流的设计，先分别处理空间和时间特征，再融合；Open-Sora 在长视频、多分辨率、工程鲁棒性上做了大量优化；Wan 2.1、Mochi、Emu3 这些模型又各有各自的位置编码和条件注入策略。这个状态很像汽车行业：大家都是发动机加方向盘加四个轮子的底盘方案，但每家的引擎调校、悬挂、内饰各不相同。你很难说某台车完全复制了另一台，但宏观架构确实收敛到了一起。
2. DiT 的工作原理：把视频变成“一页页格子纸”
2.1 从连续帧到离散 Token：Patchify 到底在干嘛
DiT 最核心的一个操作就是 patchify。把视频切成一个个小块，再把每个小块拉平成向量，这些向量就是 Transformer 处理的 token。为什么要这么干？因为 Transformer 本身没有“相邻像素关系更紧密”这种先验，它只看序列。如果你直接把像素点作为 token，序列长度会爆炸到完全没法算。但如果你把局部小块作为 token，每个 token 内部已经保留了空间结构信息，序列长度也压到了一个合理范围。
举个具体例子。假设一段视频的分辨率是 512×512，共 16 帧，经过时空自编码器压缩后，时间维度缩到 4 帧，空间维度缩到 64×64，通道数变成 4。如果你设定时空 patch 大小为 2×4×4，那么时间上 4 帧能切成 2 个片段，空间上 64×64 能切成 16×16 个小块，最终 token 数量是 2×16×16=512 个。每个 token 的向量维度就是 patch 大小乘以通道数，即 2×4×4×4=128 维。这个长度对 Transformer 来说非常友好。
patch 大小直接影响效果和算力。patch 越小，序列越长，模型能看到的细节越多，但显存和计算量也越大。patch 越大，序列越短，但容易丢失细节。视频模型里常用的 patch 尺寸一般是时间维 1 或者 2，空间维 2 到 8。这个选择很大程度决定了视频生成画面的细腻程度和运动连贯性。
2.2 加噪去噪：DiT 在扩散过程里扮演什么角色
把视频变成 patch token 之后，后续的扩散过程就相对规整了。训练阶段，DiT 接收一个带噪的隐空间序列，以及当前时间步 t 和条件信息，输出对噪声（或速度场）的预测，和真实噪声算损失。采样阶段，从纯噪声出发，每次让 DiT 预测噪声，然后由一个调度器根据当前噪声水平算出下一步稍微干净一点的隐空间，反复迭代几十步后，就得到了一份比较干净的隐空间表示，最后输入给 VAE 解码器生成视频。
很多人会有个疑问：既然都上 Transformer 了，为什么不直接自回归预测下一帧？这个思路确实也有，但扩散模型在视频生成上有一个天然优势：它在一个连续的时间维度上迭代，能同时构建整个视频片段的全局结构，而不是一帧一帧地单向生成。单向生成容易积累误差，前面有一点抖动，后面会越来越歪；扩散模型的去噪过程更像是从一张模糊的草图开始，每一步都在修正整体轮廓，最终收敛到比较一致的画面。
另外，现在越来越多的视频模型选择 flow matching 而不是传统 DDPM。flow matching 的思路是让干净数据和纯噪声按时间线性插值，模型直接预测速度场，训练目标更简单，采样步数也可以大幅减少。Sora 的技术报告没有给出训练损失的细节，但很多迹象表明它更接近 flow matching 一族。采用哪种路径，会影响采样步数和收敛速度，但 DiT 的角色没有变——它始终是那个在噪声混沌中“猜”出干净方向的核心引擎。
2.3 条件注入方式：文本、时间步和控制信号怎么“指挥”Transformer
视频生成不是无中生有，你需要告诉模型生成一只猫，还是生成一段雨天街道，因此条件信息必须能有效地进入 Transformer。DiT 论文里对比了几种注入方式，每种都值得了解。
第一种是 AdaLN，自适应层归一化。它的做法是把时间步、文本特征等条件向量经过一个 MLP 映射成每个 Transformer block 里 LayerNorm 的缩放和平移参数。条件不同，每一层特征就被整体放大或缩小、平移，相当于“调队友的音量”。实现简单，计算开销极小，DiT 原论文里效果也最好。但它的问题在于把条件信息压缩成了向量级的统计量，对于非常细粒度的文本语义可能不够精细。
第二种是 Cross-Attention，交叉注意力。视觉 token 作为查询，文本 token 作为键和值，在每个 block 里额外做一次注意力，让每个视觉 token 都能从文本序列里找到自己需要的信息。这种方式对语义细节更友好，但多一层注意力，计算量上升不少。
第三种是 In-Context，把条件 token 直接拼在视觉 token 序列前面。像 GPT 处理上下文一样，让模型自己从拼接序列中提取信息。这个最简单，也最符合 Transformer 的原始设计，但条件序列越长，整体序列就越长，算力开销也上去了。
真实视频模型往往不是只用一种。Open-Sora 倾向把文本 token 拼进序列，同时用 AdaLN 注入时间步；CogVideoX 使用交叉注意力来加强文本语义；HunyuanVideo 在双流阶段分别处理文本-图像交叉注意力，融合阶段再做联合注意力。条件注入方式直接决定了模型对文本指令的跟随能力，这也是你在复现或微调模型时最需要关注的地方之一。
2.4 位置编码：让 Transformer 知道时间顺序和空间位置
Transformer 结构本身不区分 token 的先后顺序，所以必须给每个 patch 加上位置编码。图像模型一般只需要二维位置编码，比如把 patch 在高度和宽度上的坐标编码进去。视频要多一个时间维度，所以位置编码必须覆盖时间、高、宽三个轴。
早期方案是绝对位置编码，每个位置对应一个固定向量，实现简单，但遇到训练时没见过的分辨率或帧数，效果会下降。现在更主流的是 RoPE，旋转位置编码，它表达相对位置关系，对长视频和可变分辨率的泛化能力更好。很多实现会在时间维用一维 RoPE，空间维用二维 RoPE，最后把位置信息相加或者拼接进 token。位置编码这个环节特别容易出 bug，我见过不少复现项目画面乱跳，最后查下来都是位置编码没对齐时间和空间轴。你要是准备自己写代码，建议把这一段单独做可视化验证。
3. 为什么是“单流”DiT？——视频模型选型背后的工程逻辑
3.1 单流、双流是什么，为什么都在喊“单流”
网上讨论视频 DiT 时，你很容易看到“单流”这个词。简单来说，如果空间和时间信息被放在同一组 token 里，喂进相同的 Transformer block 一起做注意力，这就是单流 DiT；如果分别用两套网络分支处理空间信息流和时间信息流，再在某个阶段融合，那就是双流设计。
Sora 为什么被认为倾向单流？因为它提到了时空 patch 的概念，把不同帧的 patch 全部拉平成一个序列。这种设计的直觉是：空间和时间没有本质区别，都只是序列上的不同位置。模型不需要提前被规定“哪个是空间关系，哪个是时间关系”，而是自己从数据里学。单流的优点是结构简单、实现直接、扩展性好，符合 Transformer 的 scaling law；缺点是序列特别长，计算复杂度极高，而且如果数据不够大，模型可能学不好时间关系。
双流的思路则更保守一点：先让空间流专心处理画面内结构，让时间流专心处理跨帧变化，最后再融合。这样可以减少模型在早期被过多任务干扰，尤其在小数据和中等算力场景下，效果往往比纯单流更容易调好。HunyuanVideo 使用的就是双流到单流的过渡结构，先分别提取空间和时间特征，再在最后的联合块里统一融合。本质上，它是在单流和双流之间找一个折中点。
所以准确地说，不是“所有模型都在抄单流”，而是越来越多的模型在结构设计上向统一 Transformer 靠拢。单流代表一种极简主义信仰：结构越统一，规模扩展时越不容易出岔子。而双流代表一种工程师的现实主义：在有限的算力和数据里，注入一些任务先验反而更稳。
3.2 与 3D-CNN、RNN、U-Net 同场竞技，DiT 赢在哪
视频生成领域之前不是没有尝试过其他结构，只是它们各有硬伤。
3D-CNN 是 U-Net 的自然延伸，把卷积核从二维变成三维，直接对时空体素做卷积。它对局部运动有不错的捕捉能力，但感受野有限，画面左侧和右侧的长期一致性很难保证，而且 3D 卷积的计算量增长很快。
RNN 类方法把视频当时间序列，一帧一帧地预测。它的优点是天然符合时间因果性，计算量相对可控，但在长序列上难以并行，训练效率低，而且信息在长距离传播中容易衰减，到最后模型基本只记得最近几帧内容。
U-Net 加临时注意力虽然能缓解一些问题，但整体上还是保留了大量卷积操作。卷积的局部归纳偏置在小数据上是个加分项，但在大数据、大模型情况下反而成了上限。它让人很难直观理解“参数量增加以后，模型到底是变聪明了，还是只是把固定的局部模式背得更熟”。
DiT 的赢点在于把视频理解成一个纯序列问题，用全局注意力建模任意距离的交互关系，理论上不存在“太远了记不住”这个限制，而且 Transformer 的架构非常统一，加层、加头、加宽度都可以直接套现成的训练经验。Sora 之后，各家动辄几十亿参数的视频模型几乎全部选择 DiT，根本原因不是它结构新颖，而是它在大规模算力下最能出效果。
3.3 Token 序列有多长？算力瓶颈从何而来
DiT 最大的代价就是序列长。一个简单的换算：一张 256×256 的图像，如果 patch 大小是 4×4，得到的 token 数量是 64×64=4096 个。对视频来说还要乘以时间维度，假设 16 帧，时间是 4 个 patch，那 token 数量就是 4096×4=16384 个。这么多 token 做标准全局自注意力，计算复杂度是 O(n²)，显存消耗非常恐怖。
因此，工程上几乎没有任何生产级视频模型敢直接对所有 token 做完整全局注意力。常用的折中方案包括：把注意力分解成空间注意力和时间注意力，先在同一帧内做空间建模，再在同一个空间位置上跨帧做时间建模；或者用窗口注意力，只让 token 在局部窗口内交互；或者用 FlashAttention、SageAttention 这类高效算子降低显存占用。很多实现号称单流 DiT，实际上注意力路径仍然是经过工程裁剪的，不是字面意义上的所有 token 两两互联。
理解这一点很重要。当你看到某个模型声称“全局时空注意力”时，要去看它的代码里具体在哪里被切成了局部窗口，在哪里做了降采样或 pooling。这决定了它能多连贯地生成数十秒长的视频，也决定了你的 GPU 到底能不能跑起来。
4. 从理解到上手：DiT 类视频模型的实操笔记
4.1 训练视频 DiT 的最小配置
很多人看完架构分析就热血上头，直接想训练一个 Sora。我的建议是，先看明白最小配置有多重。
数据方面，你需要大量短视频片段，每段最好都配有高质量文本描述。视频数据的处理链路通常包括抽帧、裁剪、缩放、去水印、清洗低质量片段、生成 caption 等步骤。caption 质量直接决定模型的指令跟随能力，现在很多团队甚至先用一个强视觉语言模型为短视频自动生成详细描述，再用作文本条件。
算力方面，如果只是微调或小规模训练，一张 24GB 显存的消费级显卡也能跑，但非常吃力。预训练一个能看的视频 DiT，单卡 A100 80GB 是入门，H100 更好。模型规模建议从小开始，比如 hidden size 768、12 层 Transformer、12 个注意力头，先拿 16 帧 256×256 的分辨率验证流程，再逐步扩大。
组件方面，你需要一个时空 VAE 把视频压缩成隐空间，一个文本编码器把 caption 变成向量，一个 DiT 主干，再加上一个 scheduler。Open-Sora 的代码仓库把这套流程封装得很清晰，我建议第一次接触的人直接以它为参照，不要从零造轮子。
4.2 一条可以“抄作业”的最小训练流程
基于常见实践，我整理出一个非常简化但完整的训练循环，演示 DiT 在视频数据上是怎么训练的。
首先，用预训练 VAE 把每段视频编码成隐空间张量。假设视频经过 VAE 后得到张量形状为 B×C×T×H×W，B 是批量大小，C 是隐空间通道，T、H、W 分别是压缩后的时间、高、宽。接着把这些隐空间张量切成 patch，并加上位置编码，转换成 Transformer 输入序列。
每个训练步骤大致如下：
def train_step(batch_videos, batch_texts): # 1. 视频过 VAE 编码器得到隐空间表示 latents = vae.encode(batch_videos) # (B, C, T, H, W) # 2. 文本过 text encoder 得到文本向量 text_emb = text_encoder(batch_texts) # (B, L, D) # 3. 把隐空间切成 patch，拼上条件文本 token tokens = patchify(latents) # (B, N, D_tok) tokens = concat_text(tokens, text_emb) # 4. 随机采样时间步 t，并按调度器加噪 t = torch.randint(0, cfg.num_train_steps, (B,)) noise = torch.randn_like(tokens) noisy_tokens = scheduler.add_noise(tokens, noise, t) # 5. DiT 前向，预测噪声（或速度场） pred = dit(noisy_tokens, t, condition=text_emb) # 6. 计算损失，反向传播 loss = mse_loss(pred, noise) loss.backward() optimizer.step()真实项目里还会加入 EMA、学习率预热、梯度裁剪、混合精度等细节。但拿到这段流程，你已经能理解 Open-Sora、CogVideoX 这类代码库在干什么了。我特别提醒一句：视频数据最烦人的不是模型，而是数据 padding 和 masking。不同视频片段帧数、宽高比都不一样，怎么把它们凑成一个 batch，怎么在时间维度上对齐，是训练脚本里最容易出错的地方。
4.3 推理采样和提速：别一上来就生成超长视频
训练完模型，推理阶段同样有学问。默认情况下，你需要从一个纯噪声张量出发，循环调用 DiT 很多次，每次预测噪声并更新隐空间。常用的采样器包括 DDIM、Euler、DPM-Solver 等。采样步数越多，画面越稳定，但速度越慢。用 flow matching 训练出来的模型，一般 20 到 30 步就能得到不错效果，传统 DDPM 模型可能需要 50 到 100 步。
CFG 是另一个要调的关键参数。简单说，CFG 就是同时让模型分别在“有条件”和“无条件”两种状态下预测，再按权重把两种预测拉远，让条件信息更强烈地影响生成结果。CFG 太低，画面可能不符合文本描述；CFG 太高，画面会过饱和、出现不自然的伪影，甚至颜色像滤镜糊了一层。视频模型常用的 CFG 范围大概在 3 到 7 之间，具体要看你数据训练时的分布。
不要一上来就生成几十秒的视频。经验做法是先让模型生成 8 到 16 帧的短视频，验证效果稳定后再扩大帧数。需要长视频时，很多工程方案是先生成关键帧，再用插帧模型把中间帧补出来。这比让模型一步到位生成超长视频稳定得多。
4.4 显存爆了、速度太慢？我给你一套工程组合拳
实际操作中，大多数人遇到的第一个瓶颈就是显存。视频 DiT 的 attention 计算量和中间激活值都很大，单卡很容易 OOM。我的建议是分步骤排查。
第一，升级 attention 实现。把 PyTorch 原生 attention 换成 FlashAttention 或者 SageAttention，显存占用可能直接降一半，速度还更快。第二，开梯度检查点，训练时用激活值换显存，虽然速度变慢，但能撑住更大的 batch。第三，使用混合精度，bf16 在 A100 和 H100 上非常稳定，显存压力明显降低。第四，模型并行和序列并行，这是多卡环境下的进阶选择，如果只是微调，可以先用前三种方案。
推理环节也有自己的技巧。VAE 解码通常是瓶颈之一，可以把 VAE 参数先冻结并缓存到磁盘，避免每轮推理重复编码。注意力缓存也有用，先生成第一帧的隐状态，后续帧重复利用部分键值，能显著提速，但处理不当容易造成闪烁。文字条件比较长的场景，可以考虑对文本编码器进行离线预处理，把文本向量提前算好，省掉每次推理重复过文本编码器的时间。
5. 常见问题与排查速查表
5.1 训练不收敛、输出糊成一团？先别急着怪模型
训练 DiT 类视频模型时，最常见的失败模式是生成结果一片模糊，或者训练损失一直不降。这种问题往往不是模型结构错了，而是哪一层环节没对齐。
我的排查顺序是固定的。第一步，检查 VAE 能否闭环。拿一段干净视频，先编码再解码，如果重建结果就很糊，那问题在 VAE，不在 DiT。第二步，做小批量过拟合实验，拿一条视频反复训练，如果模型连这一条都学不会，要么学习率不对，要么条件信息没正确注入。第三步，检查文本 embedding 是否真的进入了网络。很多新人会把文本在某个环节丢掉，或者维度没对齐，模型最后完全是在跑无条件生成，自然不跟 prompt。第四步，看学习率和优化器。视频 DiT 参数量大，AdamW 配上 1e-4 左右的基础学习率比较常见，还需要预热阶段。学习率太高很容易出现 NaN。
还有一个容易忽略的问题：数据本身脏。视频里有大量黑屏、重复帧、只有一个镜头不动的情况，模型会疯狂学会“输出静态模糊画面”。数据清洗的质量，往往比模型参数大小更能影响最终效果。
5.2 生成长视频容易崩？这不只是算力问题
很多模型生成 16 帧效果不错，但一旦让它生成 32 帧甚至更长，画面就开始漂移，物体变形，动作断裂。这是视频 DiT 最核心的痛处。
原因有几个层面。第一，训练数据里的长片段太少，模型没见过长距离时间依赖，自然学不会。第二，注意力范围受限，如果实现里采用了窗口注意力，跨长距离的信息交互不足，物体离开窗口后就被“遗忘”。第三，隐空间 VAE 的时间压缩会导致短时间细节被磨平，帧与帧之间微小运动失真，生成后表现为闪烁。第四，自回归类生成策略会让误差逐步累积，第一帧轻微偏差，到了第 30 帧可能已经变成一个完全不同的画面。
解决方向也很明确。从数据层面，要尽量增加训练集中长片段比例，或者采样时使用不同帧率。从模型层面，可以考虑把窗口注意力范围扩大，或者加入时间维度的全局注意力，代价是算力上升。从后处理层面，用插帧模型对相邻帧做平滑，能挽回一部分视觉效果，但无法解决根本问题。我个人的经验是，把长视频任务拆成“短片段生成+插帧+拼合”的管线，比强行训练超长生成模型要现实得多。
5.3 开源 DiT 模型各有各的脾气：横向对比与选型建议
现在的开源视频生成模型数量已经很多，但主流的 DiT 类方案就那几个，各有各的侧重。
Open-Sora 是社区里最活跃的开源实现，模块化做得好，从数据处理到训练、推理的文档都算齐全。它比较适合作为学习参考和二次开发基础，你可以在它上面换 VAE、换文本编码器、调整 DiT 结构，改动成本相对低。缺点是默认配置下长视频效果一般，需要自己调。
CogVideoX 是智谱开源的一套视频模型，它的 3D VAE 压缩率很高，模型体积从 2B 到 5B 都有，对消费级显卡相对友好，图生视频和文本生视频都支持。如果你追求开箱即用，不想自己把整条训练管线搭起来，CogVideoX 是很务实的选择。
HunyuanVideo 是腾讯开源的大规模视频模型，参数量大，效果细腻，视觉质量在开源模型里属于第一梯队。但它对显存和部署工程的要求也高，适合有一定集群资源、追求最高生成质量的团队。
Latte 是偏研究性质的项目，结构最接近论文里的原始 DiT，适合做学术实验、架构分析，而不是直接当产品用。
如果你刚开始接触视频模型，我个人建议从 Open-Sora 或者 CogVideoX 入手，先跑通一个 16 帧 256 分辨率的 demo，观察生成质量，再根据自己的硬件条件决定是否换更大模型。
| 模型 | 特点 | 适合场景 | 上手难度 |
|---|---|---|---|
| Open-Sora | 模块化清晰，社区活跃 | 学习、二次开发、工程调优 | 中 |
| CogVideoX | 3D VAE，模型体量较轻 | 开箱即用、图生视频、短篇生成 | 低 |
| HunyuanVideo | 参数量大，生成质量高 | 高质量视频生成、有集群资源 | 高 |
| Latte | 结构接近论文原始 DiT | 学术研究、架构对比实验 | 中 |
5.4 问题速查表：一次看懂现象、原因和对策
最后把实际开发中经常遇到的问题整理成速查表，方便你直接对照排查。
| 现象 | 可能原因 | 对策 |
|---|---|---|
| 显存 OOM | 分辨率/帧数太高，注意力未优化 | 降低输入大小、FlashAttention、梯度检查点、模型 offload |
| 训练损失 NaN | 学习率过高、混合精度不稳定 | 降低学习率、关掉 AMP 试跑、检查输入数据是否有 NaN |
| 画面过曝光、色彩过饱和 | CFG 权重太高 | 降低 CFG，比如从 7 降到 3 或 4 |
| 文本指令不跟随 | 文本编码器容量不足、条件注入方式单一 | 换更强文本编码器、增加交叉注意力、改善 prompt 模板 |
| 生成视频闪烁 | VAE 时间不一致、推理连续性不足 | 检查 VAETemporal重建、降低 CFG、用插帧后处理 |
| 细节纹理差 | patch 过大、VAE 压缩丢失细节 | 减小 patch 尺寸、用更高分辨率训练数据 |
| 长视频物体漂移 | 窗口注意力范围不够、训练长片段少 | 增大注意力窗口、增加长片段数据、拆成短视频生成再拼接 |
这几点几乎覆盖了我在复现视频 DiT 过程中踩过的所有典型坑。很多问题看起来是网络结构不对，最后查下来要么是数据问题，要么是工程配置问题。DIT 这个架构本身已经非常成熟，真正拉开差距的，往往是这些容易被忽略的细节。
最后分享一点个人体会。我从开始复现 DiT 到现在，最大的感受就是：不要被“Transformer + 扩散”这些大词唬住，它本质就是一套非常工程化的管线——VAE 负责压缩，DiT 负责在隐空间里猜出没有噪声的中间表示，scheduler 负责一步步落笔。新人最容易卡住的往往是形状对齐这些枯燥环节：视频 latent 的维度、patch 后的序列长度、时间步的 batch 维度，每一步把张量形状打印出来，问题就少了一半。如果你想进入视频生成这个领域，不用指望一步到位练出 Sora 级模型，先跑通一个 16 帧 256 分辨率的 DiT 流程，理解每个模块的作用，再考虑扩大规模。架构已经收敛到这种程度，接下来拼的不是网络结构的新花样，而是数据、算力和工程细节的硬功夫。这话听起来不太性感，却是我踩了一堆坑之后最真实的体会。
