这些年视频生成模型迭代很快，但有一个后缀一直让我特别关注：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 视频 DiT：patch 化与空间-时间注意力

主干网络层面，Wan2.2 走的是扩散 Transformer（DiT）路线，这一点和目前主流的视频生成模型方向一致。

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 个专家（通常 k=2），然后把 token 的中间表示传给这些专家并行计算，最后把结果加权合并。

这里有一个很多人忽略的工程难点：负载均衡。如果路由器不受约束，最后可能所有 token 都涌向少数几个"什么都会"的专家，造成计算热点；而大部分专家闲在那里。所以训练时通常会在损失函数里加一个辅助的负载均衡损失，鼓励路由打分尽量均匀地分布到各个专家。这样每个专家都能得到充分的训练，推理时的并行调度也更均匀，不会出现某个 GPU 跑到冒烟、其他 GPU 闲着的情况。

还有一个细节：训练和推理时的路由动态性。训练时每个 token 的去向是由路由器现场决定的，同一个 token 在不同训练步里可能被分给不同专家。推理时，如果框架做了 expert parallelism，token 会被发送到存放对应专家的 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 采样参数与生成时间的关系

推理阶段有一个参数表格值得收藏，这里把主要影响因素列一下：

因为这些参数是互相耦合的，调参时最好一次只动一个变量，不要同时改步数和引导系数，否则你很难知道是哪一步变化导致了效果的突变。

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，先把架构层面的每一条链路走通，再回头解决"怎么动得更好看"的问题——地基稳了，后续的发挥空间才够大。