Wan2.1 这个模型刚开源那阵子，我正好在折腾视频生成相关的项目，看到它的技术报告之后第一反应是：这套组合拳打得挺有意思。它没有走很多团队"堆参数、堆数据"的蛮力路线，而是在架构层面做了几个相当关键的选择——用 DiT 做主干、用 Flow Matching 做训练目标、自研 Wan-VAE 做视频编解码、再配上 umT5 做文本编码。这几个模块单独拎出来都不算新鲜，但把它们捏在一起并且调通，这里面的工程细节才是真正值钱的部分。
我写这篇东西的出发点很简单：网上关于 Wan2.1 的讨论大多停留在"效果好不好""能不能跑"这个层面，很少有人把它的技术选型逻辑讲透。比如为什么是 Flow Matching 而不是 DDPM？为什么 VAE 要自研而不是直接用现成的？单流 DiT 和双流 DiT 到底差在哪？这些问题如果不搞清楚，你调参就是瞎调，出问题也不知道往哪个方向排查。所以下面我会从架构设计的角度，把 Wan2.1 这套技术栈拆开来讲，适合已经有一定扩散模型基础、想深入理解视频生成架构的读者，也适合正在做类似项目、需要做技术选型参考的从业者。
1. 从 DiT 到单流 DiT：主干网络到底改了什么
1.1 DiT 的基本盘：把 Transformer 塞进扩散模型
要理解 Wan2.1 的主干，得先把 DiT 这个东西说清楚。DiT 全称 Diffusion Transformer，核心思想就一句话：把传统扩散模型里用的 U-Net 换成 Transformer。这个替换听起来简单，但背后的动机很实在。
U-Net 在图像扩散里用了很多年，它的结构是卷积加下采样再加跳连，对图像的局部特征捕捉得很好。但视频不一样，视频多了时间维度，帧与帧之间的长距离依赖关系用卷积去建模效率很低。卷积的感受野是局部的，你要让它"看到"隔了十几帧的画面关联，就得堆很多层，参数量和计算量都上去了。Transformer 的自注意力机制天然就是全局的，任何两个位置的信息都能直接交互，这对视频里的时空建模来说是对路的。
DiT 的做法是把输入图像切成 patch，每个 patch 当成一个 token，然后走标准的 Transformer 流程。Wan2.1 在这个基础上做了适配，把视频的时空信息也切成 patch 来处理。具体来说，它会把视频在时间维度上也做切分，比如每几帧组成一个时间 patch，然后空间上再切，最终形成一个三维的 patch 序列送进 Transformer。
这里有个细节值得注意：patch 的切分策略直接影响计算复杂度。自注意力的复杂度是 token 数量的平方，你切得越细，token 越多，计算量涨得越快。Wan2.1 在 patch size 的选择上做了权衡，具体参数在技术报告里有，核心思路是在生成质量和推理成本之间找平衡点。我实测下来的感受是，patch size 稍微大一点，推理速度提升很明显，但细节损失也能看出来，尤其是快速运动的画面容易出现糊的情况。
1.2 单流 DiT 的设计取舍：为什么不用双流
这是 Wan2.1 架构里我觉得最值得聊的一个点。所谓"单流"和"双流"，指的是模型处理不同模态信息的方式。
双流 DiT 的思路是：文本走一条 Transformer 分支，图像/视频走另一条分支，两条分支各自处理，然后在某些层做交叉注意力来融合信息。这种设计在早期的多模态模型里很常见，好处是每个模态有独立的参数空间，可以针对性地优化。但坏处也很明显：参数量大、计算开销高，而且两条分支的融合时机和融合方式需要仔细设计，调不好容易出现模态对齐问题。
单流 DiT 则把所有信息——文本 token、图像 patch token、时间步 embedding——全部拼成一个序列，送进同一个 Transformer 里处理。这样做的好处是信息融合更自然，因为自注意力机制会自动学习不同 token 之间的关联，不需要人为设计融合点。参数量也更省，因为只有一套 Transformer 参数。
Wan2.1 选单流路线，我认为核心考量是视频生成这个场景的特殊性。视频的数据量本来就大，token 数量比图像多一个量级，如果用双流架构，计算开销会大到难以接受。单流架构在 token 效率上更有优势，而且视频生成里文本和视觉信息的交互非常频繁——每一帧的内容都要和文本描述对齐——单流架构的全局注意力恰好适合这种密集交互。
不过单流也有它的代价。文本 token 和视觉 token 混在一起，模型需要学会区分它们，这增加了训练难度。Wan2.1 的解决办法是在输入层面做明确的模态标识，让模型能清楚地知道每个 token 来自哪个模态。具体怎么做的，下面讲输入处理的时候会展开。
1.3 时间步信息的注入方式
扩散模型的一个核心问题是：模型需要知道当前处于去噪的哪个阶段。因为不同噪声水平下，模型要做的事情完全不同——高噪声时是在确定大体结构，低噪声时是在抠细节。所以时间步信息的注入方式很关键。
Wan2.1 用的是自适应层归一化（AdaLN）的方案，这是 DiT 系列的标配做法。具体来说，时间步 embedding 经过几层 MLP 之后，会生成一组缩放和平移参数，作用在 Transformer 的 LayerNorm 上。这样每个 Transformer 块都能根据当前时间步调整自己的行为。
这个设计的好处是参数效率高，时间步信息通过调制 LayerNorm 的方式影响整个网络，不需要额外的注意力层或者卷积层。而且 AdaLN 的调制是逐通道的，粒度够细，模型可以学到很精细的时间步依赖关系。
实操中有一个容易踩的坑：时间步 embedding 的维度要和 Transformer 的隐藏维度匹配，如果对不上，调制就会出问题。Wan2.1 在这方面做了对齐处理，但如果你自己改架构，这个点一定要检查。
2. Flow Matching：为什么放弃 DDPM 那套玩法
2.1 从 DDPM 到 Flow Matching 的演进逻辑
扩散模型的经典做法是 DDPM（Denoising Diffusion Probabilistic Models），它的核心是一套马尔可夫链：前向过程逐步加噪声，反向过程逐步去噪声。数学上很漂亮，但实际训练和采样的时候有几个让人头疼的问题。
第一个问题是采样步数多。DDPM 的反向过程是逐步去噪的，标准实现要几百甚至上千步才能生成一个像样的结果。虽然后来有 DDIM 这样的加速采样方法，但本质上还是在走一条弯曲的路径，步数少了质量就掉。
第二个问题是训练目标的设计。DDPM 预测的是噪声，但噪声和图像之间的关系不是线性的，模型学起来需要绕个弯。而且不同时间步的噪声水平差异很大，损失函数的加权方式对最终效果影响很大，调起来很麻烦。
Flow Matching 的思路完全不同。它不搞马尔可夫链那一套，而是直接学一个速度场——从噪声分布到数据分布的一条直线路径。训练目标是让模型预测这条路径上的速度向量，采样的时候沿着速度场积分就行。
这个思路的好处是路径是直的，理论上可以用很少的步数完成采样。而且训练目标更直接，模型学的是"往哪个方向走"，而不是"当前噪声是多少"，直觉上更好理解。
2.2 Flow Matching 在 Wan2.1 里的具体实现
Wan2.1 用的 Flow Matching 实现有几个细节值得说。
首先是路径设计。Flow Matching 的核心是定义一条从噪声到数据的概率路径。最简单的选择是直线路径，也就是噪声和数据之间的线性插值。Wan2.1 用的就是这种方案，数学形式很简洁：x_t = (1-t) * noise + t * data，其中 t 从 0 到 1。模型要预测的就是 dx_t/dt，也就是 data - noise 这个常数向量。
这个设计的巧妙之处在于，目标速度是一个常数，不依赖于 t。这意味着模型在不同时间步学到的目标是一致的，训练信号很稳定。相比之下，DDPM 的预测目标在不同时间步差异很大，模型需要学一个更复杂的函数。
其次是时间步采样策略。训练的时候，t 是从 [0,1] 里采样的。均匀采样是最简单的做法，但实际效果不一定最好。因为路径两端——纯噪声和纯数据附近——的梯度行为和高噪声区域不一样，需要针对性地调整采样分布。Wan2.1 在这方面做了调优，具体策略技术报告里有说明，核心思路是让训练样本在不同噪声水平上的分布更合理。
再就是推理时的积分方法。Flow Matching 理论上可以用欧拉法一步到位，但实际为了质量，还是会用多步积分。Wan2.1 支持多种采样器配置，步数可以根据质量要求灵活调整。我实测下来，20 到 30 步就能出不错的结果，比传统 DDPM 动辄上百步要高效得多。
2.3 Flow Matching 带来的实际收益与代价
从实际使用角度看，Flow Matching 给 Wan2.1 带来的最大收益是采样效率。同样的硬件条件下，Flow Matching 能用更少的步数达到可用的生成质量，这对视频生成尤其重要——视频的每一帧都要去噪，步数少了整体推理时间下降非常明显。
另一个收益是训练稳定性。Flow Matching 的损失函数形式更简单，梯度行为更可预测，训练过程中不容易出现 loss 震荡或者模式崩溃。这对大规模训练来说很关键，因为训练一次的成本很高，稳定性直接决定了能不能跑出好结果。
代价方面，Flow Matching 对时间步的建模要求其实更高。因为路径是直的，模型需要精确地学到每个时间步的速度方向，如果时间步 embedding 不够准确，生成质量会明显下降。这也是为什么 Wan2.1 在时间步注入上用了 AdaLN 这种比较精细的方案。
还有一个容易被忽略的点：Flow Matching 的采样路径虽然是直的，但实际模型学到的速度场不可能是完美的常数，总会有误差。这些误差在积分过程中会累积，步数太少的时候累积误差会导致结果偏离。所以实际使用中，步数不能压得太极限，要根据具体场景做权衡。
3. Wan-VAE：视频编解码为什么要自己造
3.1 通用 VAE 在视频场景下的水土不服
大部分图像扩散模型用的 VAE 是在图像数据上训练的，比如那几种常见的开源 VAE。这些 VAE 在图像上表现很好，但直接拿来处理视频就会出问题。
第一个问题是时间一致性。图像 VAE 是逐帧处理的，每一帧独立编码解码。视频里相邻帧的内容高度相关，逐帧处理会丢失这种时间上的连续性，导致解码出来的视频有闪烁或者抖动。你可能会想，那我在 VAE 里加个时间维度的卷积不就行了？理论上可以，但通用 VAE 的架构不是这么设计的，硬改的话预训练权重就用不上了，等于从头训练。
第二个问题是压缩率。视频的数据量比图像大得多，如果压缩率不够高，latent 序列会非常长，后面 DiT 的计算量就爆炸了。通用图像 VAE 的压缩率是针对图像优化的，对视频来说往往不够。
第三个问题是运动信息的保留。视频的核心信息不只是每一帧的画面内容，还有帧与帧之间的运动。通用 VAE 没有针对运动做优化，快速运动的区域容易编码失真，解码出来就是糊的。
3.2 Wan-VAE 的架构设计与关键参数
Wan-VAE 是 Wan2.1 团队自研的视频 VAE，专门针对上面这些问题做了设计。
架构上，它用的是 3D 卷积加注意力机制的混合结构。3D 卷积负责捕捉局部的时空特征，注意力机制负责建模长距离的时间依赖。这个组合在视频处理里比较常见，关键是具体的配置——多少层、每层的通道数、下采样倍率这些。
压缩率方面，Wan-VAE 在空间和时间上都做了下采样。空间上下采样比较好理解，就是把画面尺寸缩小；时间上下采样是把帧率降低，比如每 4 帧压缩成 1 帧的 latent。这个时间压缩率很关键，压缩太少 latent 序列太长，压缩太多运动信息丢失严重。Wan2.1 选的压缩率是在大量实验基础上确定的，具体数值技术报告里有。
通道数方面，Wan-VAE 的 latent 通道数比通用图像 VAE 要多。这是因为视频的信息量更大，需要更多的通道来承载。通道数多了，latent 的表达能力更强，但后面 DiT 的输入维度也相应增加，计算量会上去。这是一个需要权衡的点。
3.3 自研 VAE 的工程代价与回报
自己训练一个 VAE 不是小事。数据方面，需要大规模的视频数据集，而且要做清洗和筛选，保证训练数据的质量。训练方面，VAE 的训练虽然比扩散模型简单，但视频 VAE 的训练量很大，需要不少算力。评估方面，VAE 的质量评估不像生成模型那么直观，需要设计专门的指标，比如重建误差、时间一致性指标、运动保真度等。
但回报也是实打实的。自研 VAE 可以针对 Wan2.1 的整体架构做优化，比如 latent 的维度和 DiT 的输入要求精确匹配，不需要做额外的适配层。而且 VAE 和 DiT 可以联合调优，整体效果比用现成组件拼起来要好。
我在实际项目里的体会是，如果你的视频生成任务对质量要求高，自研 VAE 或者至少做针对性的微调是值得的。通用 VAE 虽然省事，但天花板明显，后期想提升质量会发现瓶颈就在 VAE 上。
4. umT5 文本编码器：多语言能力背后的考量
4.1 为什么选 umT5 而不是 CLIP
文本编码器的选择看起来是个小问题，但对生成模型的影响很大。CLIP 是图像生成里的标配，它的文本编码器在英文上表现很好，但有个明显的短板：多语言能力弱。CLIP 的训练数据主要是英文图文对，其他语言的支持很有限。
Wan2.1 选 umT5 作为文本编码器，核心考量就是多语言。umT5 是 T5 的多语言版本，在包括中文在内的多种语言上都有不错的预训练基础。这意味着 Wan2.1 可以原生支持中文 prompt，不需要额外的翻译或者适配层。
另一个考量是文本理解的深度。T5 系列用的是 encoder-decoder 架构，encoder 部分对文本的语义理解能力很强。相比之下，CLIP 的文本编码器是一个相对轻量的 Transformer，对复杂文本描述的理解能力有限。视频生成往往需要更详细的文本描述——不只是"一只猫"，而是"一只橘色的猫在草地上奔跑，阳光从左边照过来"——这种复杂描述需要更强的文本理解能力。
4.2 umT5 在 Wan2.1 里的接入方式
umT5 在 Wan2.1 里的角色是把文本 prompt 编码成一系列 embedding 向量，然后这些向量作为条件信息送进 DiT。
具体流程是这样的：文本先经过 tokenizer 变成 token 序列，然后送进 umT5 的 encoder，输出每个 token 的 embedding。这些 embedding 会经过一个投影层，维度对齐到 DiT 的隐藏维度，然后和视觉 token 拼在一起送进 Transformer。
这里有个细节：文本 token 的数量和视觉 token 的数量差异很大。一段 prompt 可能就几十个 token，但视频的 patch token 可能上千。这种数量上的不平衡会影响注意力的分配。Wan2.1 的处理方式是在注意力计算时做适当的缩放或者掩码，保证文本信息不会被视觉 token 淹没。
另一个细节是文本 embedding 的注入时机。有些架构是在每一层都注入文本条件，有些是只在输入层注入一次。Wan2.1 用的是后者，文本 embedding 和视觉 token 拼在一起，后续层通过自注意力来利用这些信息。这种设计更简洁，参数效率更高。
4.3 多语言支持的实测表现
从实际使用角度看，umT5 带来的多语言支持是 Wan2.1 的一个实用优势。我用中文 prompt 测试过，生成结果和英文 prompt 的质量差距不大，这说明 umT5 的中文理解能力确实到位。
但也有一些需要注意的地方。中文和英文的表达习惯不同，同样的意思，中文 prompt 可能需要不同的措辞才能得到理想的结果。比如中文里"唯美"这个词很抽象，模型可能理解不到位，但换成具体的描述"柔和的光线、浅景深、暖色调"，效果就好很多。这不是 umT5 的问题，而是跨语言生成任务的共性挑战。
还有一个实操经验：prompt 的长度要控制。umT5 虽然支持长文本，但过长的 prompt 会导致文本 token 太多，注意力分散，反而影响生成质量。我的经验是，核心描述控制在两三句话以内，把最关键的信息放在前面。
5. 组件协同：四个模块怎么捏成一个整体
5.1 数据流：从文本到视频的完整链路
把四个组件串起来看，Wan2.1 的数据流是这样的：
文本 prompt 先经过 umT5 编码，得到文本 embedding 序列。同时，视频数据经过 Wan-VAE 编码，得到 latent 序列。这两个序列在输入层拼接，加上时间步 embedding，一起送进单流 DiT。DiT 输出预测的速度场，Flow Matching 的采样器根据速度场做积分，逐步从噪声生成 latent。最后，生成的 latent 经过 Wan-VAE 解码，得到最终的视频。
这个链路里，每个组件的输出都要和下一个组件的输入精确匹配。umT5 的输出维度要和 DiT 的输入维度对齐，Wan-VAE 的 latent 维度也要和 DiT 对齐，DiT 的输出要和 Flow Matching 的速度场维度对齐。任何一个地方对不上，整个链路就跑不通。
5.2 训练策略：分阶段还是一起训
Wan2.1 的训练策略是分阶段的。VAE 先单独训练，因为 VAE 的训练目标和扩散模型完全不同，一起训会互相干扰。VAE 训练好之后冻结，然后训练 DiT 和文本编码器的投影层。文本编码器本身也是冻结的，只训练投影层，这样可以复用 umT5 的预训练知识，同时减少训练参数量。
这种分阶段策略的好处是每个阶段的目标明确，训练稳定。坏处是 VAE 的质量直接决定了最终效果的上限，如果 VAE 训得不好，后面 DiT 再强也救不回来。所以 VAE 的训练需要格外用心，评估指标要设计得全面。
5.3 推理优化：怎么让这套架构跑得更快
Wan2.1 的推理优化有几个方向。
第一个是采样步数的优化。Flow Matching 理论上支持少步采样，但实际需要根据质量要求做权衡。Wan2.1 提供了不同步数的配置，用户可以根据场景选择。
第二个是注意力计算的优化。视频的 token 数量大，自注意力的计算是瓶颈。Wan2.1 用了 FlashAttention 这类优化技术，把注意力的显存占用和计算时间都降下来了。
第三个是 VAE 解码的优化。VAE 解码是逐帧或者逐块进行的，可以并行化。Wan2.1 在解码阶段做了并行处理，减少了整体推理时间。
第四个是模型量化。Wan2.1 支持 FP16 和 BF16 推理，显存占用比 FP32 低不少，速度也更快。如果显存紧张，还可以考虑 INT8 量化，但质量会有一定损失，需要权衡。
6. 实操中容易踩的坑与排查思路
6.1 生成质量不达预期时的排查顺序
用 Wan2.1 的时候，如果生成质量不好，排查要有顺序，不能瞎试。
先看 VAE 的重建质量。把一段真实视频用 VAE 编码再解码，看重建结果和原视频的差距。如果重建本身就糊，那问题在 VAE，后面的 DiT 再调也没用。VAE 重建质量差通常是训练不充分或者压缩率太高导致的。
再看文本条件的对齐。用一个非常明确的 prompt，比如"一个红色的圆形在白色背景上旋转"，看生成结果是否遵循了这个描述。如果文本对齐不好，可能是文本编码器的问题，也可能是文本和视觉 token 的融合出了问题。
最后看采样配置。步数太少、采样器选择不当都会影响质量。可以试试增加步数，或者换一种采样器，看质量是否有提升。
6.2 显存不够用的几种解法
视频生成的显存需求很大，Wan2.1 也不例外。显存不够的时候，可以按下面的顺序尝试：
降低分辨率是最直接的办法，但会影响生成质量。减少帧数也可以，但视频太短可能表达不完整。用 FP16 或者 BF16 推理能省不少显存，质量损失很小，推荐优先尝试。如果还不够，可以试试梯度检查点技术，用计算时间换显存。最后的手段是模型量化，INT8 能进一步降低显存，但质量损失需要评估。
6.3 时间一致性问题的定位与改善
视频生成里最让人头疼的问题之一就是时间一致性——画面闪烁、物体形变、运动不连贯。Wan2.1 在这方面做了不少优化，但实际使用中还是可能遇到。
定位时间一致性问题，可以先看是 VAE 的问题还是 DiT 的问题。把 VAE 单独拿出来做重建测试，如果重建视频就有闪烁，那是 VAE 的时间建模不够好。如果重建没问题但生成有问题，那是 DiT 在时间维度上的建模需要改进。
改善时间一致性，可以从几个方面入手：增加时间维度的注意力层、在训练数据里增加运动丰富的样本、调整时间压缩率。Wan2.1 的默认配置已经做了不少优化，如果还有问题，可能需要针对具体场景做微调。
7. 我对这套技术栈的一些个人判断
Wan2.1 这套技术选型，我的整体评价是"务实"。它没有追求某个单点的极致创新，而是把几个成熟的技术——DiT、Flow Matching、自研 VAE、umT5——组合成了一个协调的整体。这种工程能力其实比单点创新更难，因为要处理的是组件之间的接口、训练策略的协调、推理性能的优化，这些都是脏活累活。
从趋势上看，Flow Matching 替代 DDPM 应该是大概率事件，采样效率的优势太明显了。单流 DiT 在多模态融合上的优势也会让更多团队跟进。自研 VAE 这个事，取决于团队有没有足够的资源和数据，小团队可能还是得用现成的，但大团队自研的回报是实打实的。
最后分享一个我在实际项目里的体会：视频生成模型的调优，很多时候不是模型架构的问题，而是数据的问题。Wan2.1 的架构再好，如果你的训练数据质量不行，生成结果也好不到哪去。所以与其在架构上反复折腾，不如先把数据清洗和筛选做到位。这个道理听起来简单，但真正做的时候，很多人还是会忍不住去改模型，而忽略了数据这个更根本的因素。
