Wan 万相:视频生成侧的开放权重基线,让整个生态能在自己机器上迭代
wan
阿里通义万相把视频生成模型以 Apache-2.0 放出权重,是视频域里最重要的公共基线。它的价值与闭源服务不同:不在于「今天出片最好看」,而在于可微调、可复现、可在自己的推理栈上跑——LoRA、ControlNet 式条件控制、量化加速、蒸馏少步数这一整套生态工作都围绕它展开。对情报站来说,一个开放权重基线意味着「视频生成现在能做到什么」这个问题第一次有了可以自己验证的参照系,而不必相信厂商精选样本。许可与仓库公开这两条已核验,画质与物理表现仍是 C 级厂商口径。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- 开放权重许可
- 厂商宣称 · 2025-07
- 成熟度
- 产品
- 研究 → 演示 → 产品 → 生产
编辑判断Wan 在这条阶梯上的身份是公共参照系,不是「最强出片工具」。这个区别很重要:视频生成域的闭源产品彼此无法公平比较(各家只放精选样本、提示词与采样参数都不公开),而一个 Apache-2.0 的开放权重模型可以被任何人在同一套硬件、同一批提示词下跑,于是它成了社区事实上的对照组——新的加速方法、条件控制方法、蒸馏方法,几乎都要在它身上证明有效。
可核验的 A 级事实:仓库公开、许可为 Apache-2.0(GitHub API 已确认)。属于 C 级的:官方给出的画质、运动幅度、物理合理性宣称——没有自托管跑过同一批提示词的对照,所以不作为结论。
需要如实写清的门槛:自托管视频模型的显存与时间成本远高于图像。这不是「下载权重就能用」的场景,批量生产要么用量化与少步蒸馏换质量,要么付云服务的时间成本。把它当基线用于研究和方法验证是合适的,把它当生产工具则需要先算清单位成本。
为什么开放权重在视频域比在图像域更重要
图像域的开放权重生态已经很成熟,闭源服务与开放模型之间的质量差距小到多数生产场景感知不出。视频域相反:闭源产品的样本与开放权重的实际表现差距仍然明显,而且没有第三方能公平验证——你无法在闭源服务上跑自己的对照实验,只能相信厂商放出来的那几十段精选。这种信息不对称在视频域造成的实际后果是:团队按 demo 立项,做到一半发现真实水位差得远。
一个 Apache-2.0 的视频基线打破了这一点。任何人都可以在自己的硬件上,用自己的提示词,得到自己的真实读数。这对情报站尤其关键:本站对视频域结论普遍标 C,不是因为悲观,而是因为缺少可复现的对照——开放权重是唯一能把它升到 B/A 的路径。
围绕它长出来的生态
- 条件控制:参考图像、姿态、深度、边缘图作为额外输入,把「怎么动」的自由度收窄到可控范围。这是从抽卡走向调度的关键一层。
- 少步蒸馏与加速:把几十步采样压到几步,时间成本降一个量级,代价是细节与运动连贯性的损失——这是当前最活跃的方向。
- 风格 LoRA:与图像域同源的微调路径,让特定美术风格可复用。视频 LoRA 的训练成本远高于图像,所以数量少但价值高。
- 推理优化:显存分块、序列并行、量化,把「只能在大集群上跑」变成「单卡工作站能跑短片段」。
自托管的真实成本账
| 环节 | 成本性质 | 说明 |
|---|---|---|
| 显存 | 硬门槛 | 视频模型的激活与 KV 显存远高于图像;分辨率与帧数是平方级放大 |
| 单条生成时间 | 线性成本 | 数十步采样 × 每步全序列注意力,单条 5 秒片段常要数分钟 |
| 重 roll 次数 | 乘数 | 生产场景三到十次是常态,时间成本要按这个倍数算 |
| 蒸馏/量化 | 一次性投入 | 换来数量级的时间下降,代价是质量损失,需要自己验证能接受 |
| 存储与传输 | 易被忽略 | 视频文件比图像大两到三个数量级,批量生产的落盘与 CDN 成本不可忽略 |
边界与失败模式
- 开放权重不等于开放能力上限:厂商通常把最强档位留在闭源服务里,开放的是能力子集。拿开放基线的表现推断该团队的真实水位会低估。
- 物理与时序一致性:与整个视频域同样的问题——流体、碰撞、物体守恒、长时序身份保持都不可靠,越长的片段越明显。
- 提示词敏感性:开放权重模型没有闭源产品那层提示词重写与优化,自然语言描述的质量直接决定输出质量,同样的意思换一种写法结果差别很大。
- 许可细节要读:Apache-2.0 覆盖代码与权重,但商用时的输出内容合规、训练数据来源声明是另一层,团队落地前需要法务确认。
待核验清单(我们下一步做什么)
这条要升到 B/A,路径很清楚也很重:在一台固定的机器上用固定的一批提示词,把 Wan 的开放档位与两到三家闭源服务的输出放在一起,盲评时序一致性、运动幅度与物理合理性;记录单条的显存峰值与墙钟时间;跑一遍少步蒸馏版本,量化质量损失。这是我们视频域唯一一条可能拿到 A 级读数的资产,优先级最高,但需要专门的算力预算。