这些年视频生成模型迭代很快但有一个后缀一直让我特别关注Wan2.2-i2v-a14b。i2v 是 image-to-video图生视频a14b 按照这类命名习惯可以理解为激活参数约 14B 的模型变体。简单说它的任务就是给一张参考图和一个可选的文本提示生成一段连贯、有运动、还保留原图主体特征的视频。这个任务听起来很朴素但实际做过的都知道它比文生视频难不少。文本生成视频时模型对主角长什么样、穿什么、在什么环境里有相当大的自由度图生视频则要求模型同时做两件容易打架的事既要严格保留参考图的人物/物体/构图/风格保真度又要在后续的每一帧里让画面产生可信的运动动态一致性。一旦视频模型架构在设计时没把图像条件这条路走通最常见的结果就是生成几秒后主体悄悄变样或者整段视频像一张图片被缓慢平移根本没有真正的物理运动。我最早是被它的参数设计吸引的。14B 级别在今天不算夸张但如果配合稀疏专家架构MoE它在推理侧的性价比就会和同参数的稠密模型拉开明显差距。加上它面向图生视频任务整个训练和采样链路也针对首帧条件做了专门处理。这篇就把我理解的 Wan2.2-i2v-a14b 架构拆开聊一聊从任务定位、主干网络、参数设计、条件注入到训练和推理落地尽量把为什么这样设计讲透。想看技术方案能不能落在自己项目里的读者应该能从里面找到不少可以对照评估的线索。1. 一张图如何变成一段视频任务定位与总体管线1.1 为什么 i2v 不能简单等价于文生视频加一张图很多刚接触图生视频的人会有一个直觉文生视频已经能把文本变成视频那我把图片描述成一段文本喂进去不就行了或者更直接一点把图片当作输入序列里的一个 token让模型在生成时参考它。这个思路方向没错但实际做起来会发现几个关键差异。文生视频生成的每一帧模型都是从头推理出来的。模型脑子里先有文本语义再把语义投射成视觉内容所以对具体长什么样没有强约束。图生视频则相反第一帧已经是确定的像素后续每一帧必须在这一帧的基础上演化。也就是说模型做的不是 open-ended 生成而是条件外推。它需要回答的问题非常具体这个人的头发是怎么被风吹动的这个镜头从哪个角度开始转光线在运动过程中应该怎么变化另一个差异在评估维度上。文生视频更多看文本对齐semantic alignment和单帧质量图生视频还要额外看主体一致性identity preservation和视频稳定性temporal stability。这些指标背后对应的架构设计是一整套东西图像编码器怎么抽特征、图像条件在主干网络哪个位置注入、时间模块如何建模帧间依赖、训练时数据怎么配比。只要有任何一个环节脱节最终拿到手的视频就会出现前两秒很惊艳第三秒开始整个人都变形了的典型毛病。1.2 从输入参考图到输出视频的整体处理流程抛开具体实现Wan2.2-i2v-a14b 这类模型的完整链路通常可以拆成四段。输入侧先把参考图编码成模型能理解的特征。这个编码过程不是简单地把图像缩小作为第一帧而是通过一个图像编码器把画面映射到和视频隐空间兼容的表示里。文本提示词也走专属的文本编码器。然后是条件注入。图像特征和文本特征会被组织成统一的序列输入到视频主干网络用注意力机制逐步融合。这里有个细节图生视频模型一般会让首帧特征对生成过程施加很强的控制本质上是把首帧保真变成生成目标的硬约束。接着扩散主干在隐空间里做去噪。主干网络是一套处理 3D 数据的扩散 Transformer它会同时建模空间结构单帧画面信息和时间结构帧与帧之间的运动关系。它不是在原始像素空间里工作而是在一个被压缩过的视频潜在表示空间里做迭代去噪这样可以省掉大量算力。最后把所有去噪完成的隐变量送进视频解码器Video VAE 的 decoder逐帧重建出 RGB 像素再拼接成最终视频文件。整条链路里VAE 负责压缩还原扩散主干负责生成内容条件编码器负责告诉模型生成什么。这个流程很像拍电影的分工图像条件帮你搭好场景和主角文本提示告诉你剧情走向扩散主干负责把每一帧的表演演出来VAE 把表演记录下来。任何一个环节出问题观众看到的都会是掉帧、鬼影或者主角换脸。2. 主干网络拆解3D VAE、视频扩散 Transformer 与时间建模2.1 3D VAE 如何把视频压扁再还原不做压缩直接在像素空间跑扩散在视频生成里基本是行不通的。一个 5 秒 720p 视频有几十帧每帧的像素数量以百万计如果模型在这个原始空间里做几十步迭代去噪算力消耗会大到没有实际部署意义。所以主流方案都是先把视频压缩进一个低维隐空间在隐空间里完成扩散过程最后再解码回像素。Wan2.2-i2v-a14b 使用的视频 VAE 是 3D 卷积结构它同时压缩空间维度和时间维度。空间上图片的宽高会被成倍缩小例如缩小 8 倍甚至 16 倍时间上相邻的几帧会被合并成一个时间步也就是说视频在进入主干网络之前已经从很长的离散帧序列变成了时间维度也变短了的压缩序列。整个过程像把一部长电影先转成低分辨率压缩包等视频剪辑完成后再还原画质。这个 VAE 的质量会直接决定生成结果的上限。如果 VAE 在压缩时丢失了纹理细节后续主干网络再怎么努力也补不回来如果它在时间维度上压缩得过于激进画面里的细微动作就会糊成一团。很多开源社区在跑视频生成模型时会特意比较不同 VAE 的还原效果原因也在这里两套模型很可能生成逻辑差不多但画面清晰度差距明显第一责任人往往是 VAE 在视频高频率细节上的重建能力。另一个值得注意的点把图像编码进视频 VAE 的隐空间和把一段真实视频编码进隐空间这两个操作的不对称性。静态图只有一帧它在时间维度上天然是静止的而训练时的视频数据是有真实运动信息的。图生视频模型在训练时通常会把参考图也做成首帧后续帧的格式甚至对图片数据做一定的运动增强避免模型把静态输入和静态输出错误关联起来。2.2 视频 DiTpatch 化与空间-时间注意力主干网络层面Wan2.2 走的是扩散 TransformerDiT路线这一点和目前主流的视频生成模型方向一致。Transformer 处理视频隐空间的第一步是 patch 化把压缩后的视频潜在张量切成一个个小的 patch每个 patch 相当于视频中的一个局部时空块。然后给每个 patch 加上位置编码让模型知道它对应的是画面里哪个位置、哪一帧。这一步很关键因为 patch 本身只是数据块如果不告诉模型这些块的空间和时间坐标注意力机制就不知道哪些 patch 应该在空间上靠近、哪些补丁应该在时间上连续。patch 进入 Transformer 之后会经过多层注意力计算。这里有一个设计分叉有的模型用联合时空注意力一个注意力模块同时看到空间和时间上的所有 patch有的模型用分解式时空注意力先做空间注意力再做时间注意力或者反过来。联合注意力理论上能捕捉更复杂的时空关系但计算量增长快分解式注意力效率更高工程实现也方便代价是空间与时间的跨维度交互略弱。Wan2.2 系列的工程实现选择了偏实用的路线这也是它能在有限算力下跑出较长视频的原因之一。时间建模的核心就在于这些注意力模块如何捕捉帧间依赖。早期视频生成模型容易被吐槽只动了背景人物表情完全僵硬本质上就是时间注意力没有真正建模出物体的物理运动只是做了空间图片之间的像素平滑过渡。更成熟的架构会在多个 Transformer 层的不同阶段都插入时间建模让模型从粗粒度运动整体运镜到细粒度运动手指动作、布料纹理变化都有对应的表达空间。2.3 序列变长之后的工程代价视频 DiT 和文本 DiT 最大的工程差异在序列长度。一段 5 秒、30fps 的视频即使被 VAE 做了时间压缩主干网络处理的 token 数量依然可能数以万计甚至十万级。自注意力的计算复杂度是平方级的序列一长计算量就会失控。这也是我判断 Wan2.2-i2v-a14b 采用 MoE 结构的直接原因之一纯稠密 Transformer 在视频这种长序列场景下扩展参数的边际收益会被算力需求迅速吞噬。只有通过稀疏激活让每个 token 只经过部分参数才能在不显著增加计算量的前提下把模型容量做大。换句话说这个架构本身就是在对模型容量和序列长度带来的计算压力做一次权衡。在推理时长序列还意味着 KV cache 的显存占用会非常可观。如果模型在生成每一帧时都重新计算前面所有 patch 的注意力状态显存会迅速被耗尽。所以工程上一般会考虑分块推理、KV cache 复用等策略。这些细节在模型架构图上未必会画出来但却是真正影响部署体验的重要部分。3. 14B 参数不是所有专家都上班稀疏激活背后的 MoE 设计3.1 为什么视频生成需要 MoE先明确一个概念a14b 如果代表激活参数量约 14B这种命名在开源模型里很常见那它的实际总参数量可能远大于 14B只是每次前向计算时只会激活一部分参数。为什么非要做稀疏结构我们可以做一个简单估算。14B 稠密模型在 FP16 精度下的权重就至少占 28GB 显存已经接近单张主流 GPU 的承载上限推理时还要考虑激活值、KV cache、临时计算缓冲区单卡几乎不可能跑起来。换成 MoE 结构后总参数量哪怕达到几十亿甚至几百亿单次 token 计算只激活其中一部分专家计算量和激活值显存就能控制下来唯一的代价是权重文件占的磁盘和加载后占的内存变大了。视频生成对模型容量的需求又是刚性的。它要学的知识面比文生图宽得多运动学规律、遮挡关系、物体形变、光照变化、物理交互。稠密模型想把这些都装进有限参数里只能靠增大参数量和算力很快就碰到工程天花板。MoE 则提供了一条内存换计算或稀疏换容量的路线同一个模型里放很多专家每个专家擅长某种类型的运动或某种视觉模式模型整体容量大了但单次推理不用把所有人都叫来上班。3.2 路由 Top-k 选择与负载均衡MoE 在 Transformer 里的工作方式一般是这样的每个 token 经过共享的 attention 计算之后会被送到一个路由器router。路由器给所有专家打分选出得分最高的 k 个专家通常 k2然后把 token 的中间表示传给这些专家并行计算最后把结果加权合并。这里有一个很多人忽略的工程难点负载均衡。如果路由器不受约束最后可能所有 token 都涌向少数几个什么都会的专家造成计算热点而大部分专家闲在那里。所以训练时通常会在损失函数里加一个辅助的负载均衡损失鼓励路由打分尽量均匀地分布到各个专家。这样每个专家都能得到充分的训练推理时的并行调度也更均匀不会出现某个 GPU 跑到冒烟、其他 GPU 闲着的情况。还有一个细节训练和推理时的路由动态性。训练时每个 token 的去向是由路由器现场决定的同一个 token 在不同训练步里可能被分给不同专家。推理时如果框架做了 expert parallelismtoken 会被发送到存放对应专家的 GPU 上进行计算这个过程中跨设备通信的开销会被放大。所以部署 MoE 模型不是简单把权重放到显存里就完事还需要考虑专家分片策略和通信拓扑。很多明明模型不大但推理特别慢的问题根子就出在专家分配不均匀或者跨卡通信太多上。3.3 参数规模带来的推理现实把账算清楚会对14B有更准确的预期。激活参数与显存的关系可以用一句话概括单 token 的计算量由激活参数决定模型整体占用的显存容量由总参数量决定。所以 a14b 变体哪怕激活参数只有 14B加载权重时依然要看总参数量。如果总参数接近 50B 甚至更高FP16 权重文件可能达到 100GB 以上必须做多卡分片或者在单卡上用量化如 INT8/INT4才能装下。推理延迟方面影响最大的从来不是参数量本身而是序列长度。视频生成的每一步去噪都要处理大量 token步骤再多通常几十步总耗时自然上去了。所以后续优化的方向主要在两个层面减少采样步数用更高效的采样器或蒸馏模型以及优化长序列注意力比如引入某种形式的窗口注意力或者对 KV cache 做压缩。Wan2.2 这类模型在宣传时会强调低资源也能跑本质上就是通过在这两方面做了工程取舍。我当时看到一个很形象的比喻稠密模型像一个所有员工都在同一间办公室的大公司通讯顺畅但开销巨大MoE 模型像一个有多个专业团队的大楼每次任务只需要叫相关团队进场。团队切换和沟通会有额外成本但整体吞吐和容纳的专业领域可以多很多。做大视频模型走 MoE 路线几乎是必然选择。4. 文本与图像双条件注入把参考图稳住的关键4.1 图像条件进入主干网络的路径图生视频模型最需要处理好的问题就是把参考图的信息焊进生成过程里。不同模型选择的路不一样但大致能分成三类。第一种是拼接法把图像编码器的输出 token 直接拼到文本 token 序列里和视频隐变量序列一起进入 Transformer 注意力。这种方式最简单图像信息和文本信息在每一层注意力里天然融合。缺点是序列长度会增加而且图像信息的控制权重不够精准。第二种是交叉注意力主干网络每一层里设置一个专门的交叉注意力模块让视频 token 作为 Query图像 token 作为 Key 和 Value。这种方式对图像条件的控制更直接模型可以反复从参考图里取信息来修正当前帧的内容主体一致性通常更有保障。第三种是把图像条件注入到扩散模型的时序模块里例如先在文本和图像共同条件下预测首帧的运动趋势再基于这个趋势展开后续帧。这种方式更接近 i2v 任务本身的物理含义——从首帧出发做时序外推。一个成熟的架构一般不会只用一种而是组合使用浅层用拼接增强早期融合深层用交叉注意力做细节锚定。不管选哪种方式训练时都要注意一个条件泄露问题。如果图像编码器过于强大模型可能完全依赖图像特征忽略文本描述的运动指令最后生成的视频会退化成参考图的各种微动而不是用户期待的按照提示词动起来。反过来如果图像条件注入太弱视频又会偏离参考图主体很快变形。让模型在保真度和运动性之间找到平衡点很多功夫都花在训练策略和数据配比上而不单是网络结构。4.2 图像-文本双条件如何叠加与平衡Wan2.2 系列在图生视频任务上还有一个常见设计同时支持文生视频和图生视频模式。也就是说训练时既有纯文本条件的数据也有文本图像条件的数据模型学会在不同条件组合下工作。推理时用户如果只给文本模型就走文生视频路线如果给了参考图就走图生视频路线这个灵活性对实际产品很重要因为用户的使用场景从来不是单一的。双条件的平衡主要体现在引导系数guidance scale上。扩散模型常用 classifier-free guidance 技术推理时同时计算有条件输出和无条件输出按一定权重拉开两者的差异让模型更坚定地按照条件生成。在 i2v 模型里文本条件和图像条件在采样时可以被分配不同的权重。很多调参经验里都会提到提高图像条件的权重可以增强主体一致性但过高的图像权重会让画面运动变得迟缓感觉像首帧被拖拽住了增大文本权重则让运动更明显但也可能引入不期望的场景变化。实操上这组权重需要针对具体素材反复试。4.3 控制哪里动、怎么动的若干手段图生视频在应用层面的一个痛点是用户想控制的往往不是整段视频都要动而是只有某些区域动其他地方保持静止。拿电商场景举例一件衣服的静态图客户希望只有袖子飘动、衣身花纹和版型保持不变又比如人物半身像希望只有头发有风吹效果五官和背景不改变。天然的视频生成模型默认是全局运动的这时需要额外手段。最直接的手段是通过文本提示描述运动区域和运动方式例如只有头发被风轻轻吹起其他部分保持静止。这种方法对模型语义理解能力要求较高效果不稳定。更精细的做法是在输入阶段提供运动蒙版motion mask把参考图里允许运动的区域显式标注出来让模型只在这些区域激活时间注意力。也可以在后处理阶段做局部区域的重采样把运动幅度控制在特定区域里。Wan2.2 这类开源模型虽然没有把运动控制能力全部内置但通过 prompt 和参数调整配合外部分割工具已经能在业务里实现相当不错的区域控制效果。5. 训练策略与数据管线先学会生成视频再学会跟着图画视频5.1 从文生视频到图生视频的能力迁移训练 i2v 模型的第一步通常是先训练一个强大的文生视频模型。这个阶段的目的是让模型学会什么是可信的运动建立一个通用的物理世界模型。之后做图生视频的适配时在保留原有运动能力的基础上把图像条件加进去教会模型根据给定首帧约束在合理范围内保持一致性并继续运动。这种两阶段思路比从头训练 i2v 模型效率高得多因为运动规律这块通用的知识没必要重新学一遍。微调阶段有一个常见风险叫灾难性遗忘。如果图生视频微调数据质量不好或者配比不对模型会逐渐忘记之前学到的运动知识生成的动作变得僵硬重复。缓解方法一般有两类一类是在微调数据里混合较高质量文生视频数据让模型持续复习另一类是冻结大部分主干网络参数只训练和图像条件注入相关的模块比如图像编码器到主干网络的投影层和交叉注意力层。Wan2.2-i2v 这类模型在开源时通常会区分 full fine-tune 和 adapter 两种思路专业用户想要更好的效果可以基于 checkpoint 做 adapter 微调来适配自己的风格数据。5.2 flow matching更高效的扩散训练目标模型训练细节上需要提到 flow matching流匹配目标。扩散模型传统上以加噪-去噪为目标从纯噪声一步步还原图像。flow matching 换了一种视角生成过程被建模成从噪声分布到数据分布之间的最优传输路径模型学习的是预测一个速度场然后沿着直线路径从噪声走到数据。用这种目标训练采样步数可以明显减少视频生成的速度也更快。这种设计对视频生成特别有价值。视频比图像的数据维度高得多生成需要的迭代步数越多成本越高。用 flow matching 可以把训练和推理的路径设计得更直接算力利用率更高。很多新出的视频生成模型哪怕结构看起来各不相同底层都用上了这类连续归一化流Continuous Normalizing Flow的思路说明它已经成为视频生成的基础范式Wan2.2 系列紧随潮流也在预料之中。5.3 数据配比与文本—图像对齐数据是 i2v 架构成功落地的隐性因素训练时同时用到纯图像数据、文生视频数据、图生视频数据。纯图像数据的加入很关键它让模型学到高质量的单帧渲染能力保证静态视觉质量文生视频数据提供运动多样性图生视频数据专门教会模型图像条件如何使用。配比不合理时会出现典型症状图生视频数据过多模型过拟合到训练集风格生硬照搬某一类场景文生视频数据过多模型对图像条件的响应则变得不够精准。另一个训练细节是多尺度与多时长采样。如果训练时只用固定分辨率和固定长度视频模型对用户输入的分辨率/时长变化的适应能力就会很弱。成熟的训练方案会让不同批次的数据拥有不同的分辨率、帧数和宽高比并配合相应的位置编码策略。这也是为什么同一个 checkpoint 在推理时什么分辨率都能生成一段的原因——它天然就见过各种尺寸的数据。6. 推理资源评估与落地边界一张卡能跑多远6.1 从 14B 激活参数推算显存与算力很多人拿到模型先问一句我的显卡跑得动吗我习惯把成本拆成两部分看加载开销和运行开销。加载开销取决于权重的总参数量与精度。假设总参数在 14B 左右、FP16 精度权重就占约 28GB 显存这已经超过了一张常见 24GB 显卡的容量必须量化或者多卡分片。如果 a14b 是激活参数而总参数更大权重占用会更高单卡纯 FP16 方案基本不现实。如果使用 INT8 量化权重可以降到 14GB 左右单卡勉强能装下但推理时还需要预留激活值和 KV cache 的空间。运行开销才是视频生成的主要成本。以生成一段 5 秒 24fps 的视频为例模型要在隐空间里反复多次去噪每一步都要处理整段视频的所有 token。序列长度越大注意力计算越贵。实测下来影响耗时最大的往往是输出时长时长从 5 秒增加到 10 秒padding 后的 token 数量不是线性增长那么简单注意力的二次复杂度会让成本增长得更陡。实际使用中我会建议大家先明确自己的需求是不是真的需要那么长的视频如果一个需求 5 秒能表达清楚不要盲目追求 10 秒以上。6.2 采样参数与生成时间的关系推理阶段有一个参数表格值得收藏这里把主要影响因素列一下参数越大/越多对生成的影响采样步数更多质量更高耗时线性增长超过一定步数后提升放缓CFG引导系数更高条件一致性更强过高的引导会让画面过饱和、运动停滞分辨率更高单帧质量更好但视频总 token 量大幅增加显存和耗时同时上升帧数/时长更长时间信息更充分但注意力计算和显存占用上升更明显图像条件权重更高主体保真度更好但动作幅度和运动多样性下降因为这些参数是互相耦合的调参时最好一次只动一个变量不要同时改步数和引导系数否则你很难知道是哪一步变化导致了效果的突变。6.3 工程落地时的三种部署模式把模型工程化时通常有三条路线可走。第一条是本地单卡轻量化模式。适合个人创作者和小团队通过量化、减少视频长度、降低分辨率把模型压进消费级显卡。这个模式下很多高级功能如超长视频、高帧率被剪掉了但日常的创意素材生成足够用。第二条是自建多卡服务模式。适合需要私有化部署、对数据安全要求高的团队。通过多卡分片支撑模型权重用可并发优化的框架处理请求能实现一个基础的视频生成服务。这条路线最大的成本是运维和机时但灵活性最高可以自由做微调、改采样策略。第三条是混合模式本地做个性化微调和数据管理云端做大规模生成任务。这种方式在需要大量算力的团队里比较常见架构适配上也更省心。选哪条路线要看团队的核心诉求就像选服务器一样不是看绝对性能最强而是看日常负载和预算结构是否匹配。7. 部署踩坑与效果调优我实测下来特别要注意的几点7.1 部署阶段最常见的几个坑第一个坑是 VAE 兼容性问题。视频 VAE 对输入输出的维度换算有严格要求不同 checkpoint 如果搭配了不同的 VAE 版本解码时往往会出现画面颜色偏绿/偏紫、明暗异常等问题。部署用推理管线时最好严格锁定模型发布时配套的 VAE不要混用官方默认配置之外的组件。第二个坑是 padding 对运动的影响。模型一般会在输入视频的宽高和长度上做补边padding处理不当时空的部分会显著影响时间注意力的计算结果。如果生成结果出现首尾帧内容跳动、或某些区域出现奇怪的拖影优先检查推理框架的 padding 方式是不是和训练时一致。第三个坑是数据类型。半精度FP16和混合精度BF16在视频扩散模型里的数值表现与图像模型不完全一样视频生成经过几十步迭代微小误差会被累积放大最终表现为画面上的噪点或色块。如果你用了某些推理加速框架尽量先输出一小段视频做质量对照确认无异常后再批量生成。第四个坑也是新手最容易忽略的图文条件的引导权重失衡。很多默认配置下文本引导权重偏高导致参考图只是一个起点过几帧之后就会跑偏。我的习惯做法是先把图像条件权重抬高确认主体稳定再逐步降低到合适位置。这个方式比反复改 prompt 效果更直接。7.2 运动质量调优少即是多效果调优阶段我有两条心得特别想分享。第一条视频生成的 CFG 引导系数和文生图不是一回事。文生图常用 5-7 的 CFG视频生成往往需要明显更低甚至 2-4 就能有不错的平衡度。过高的 CFG 在视频里的典型症状不是过曝而是动作僵硬、画面像被胶水粘住细节纹理出现伪影。很多用户抱怨视频模型生成动作死板检查一下引导系数往往就能发现问题。第二条想提升运动幅度时不要一头扎进 prompt 里写剧烈运动之类的词效果经常适得其反。更可靠的做法是控制住哪些部分要保持不动把运动的期望描述集中在具体对象上比如只有窗帘随风摆动人物完全静止。这是因为 i2v 模型默认会尽量保持参考图的所有内容当你把某个对象的运动指令说得更具体时模型反而更容易把本应静止的部分保护住同时释放指定区域的运动自由度。反过来如果你整个 prompt 都是抽象的保持图像内容不变模型确实会很稳定但它也就真的不敢动了。图生视频模型拆到最后本质上是在保真度和运动度之间不断做平衡。Wan2.2-i2v-a14b 这个架构给我的感觉是它没有在高容量和长视频上做特别激进的尝试而是在每个关键环节上选了务实路线用 MoE 控制计算成本用 3D VAE 压缩时空维度用双条件注入保留首帧信息用 flow matching 加速采样。这套组合不一定每一项都是最新奇的技术合在一起却能形成一个相对完整的图生视频落地方案。如果你正在做类似的视觉内容生成项目我建议不要急于调 prompt先把架构层面的每一条链路走通再回头解决怎么动得更好看的问题——地基稳了后续的发挥空间才够大。
