企业官网建设流程全解析

单卡 24GB 做首帧视频：Wan 与 Hunyuan 怎么筛？

手里有一张已经定好人物、构图和场景的首帧，还有一张 24GB NVIDIA GPU。现在要做一段约 720P 的短片，观察人物能否保持、动作是否符合提示词。搜索模型时，Wan2.2 的“24GB”与 HunyuanVideo-1.5 的“最低 14GB”很容易被读成两个现成答案。

问题是，这些数字属于具体命令和运行前提。它们还不能回答：给定这张首帧、目标分辨率和时长，完整视频是否能在你的机器上生成。本文只做官方路径初筛，再给出本机容量探针的记录方法；没有作者本机的速度、画质或成功率数据。

先把输入固定，再看官方命令

本轮只比较单张首帧加动作提示词的 I2V（图生视频）。目标约 720P，具体帧数和时长以两条官方路径共同能运行的设置为准；差异必须记录。系统内存、磁盘、驱动和依赖同样会影响能否完成，不在“24GB 显卡”四个字里。

纯文生视频、多参考图、音频驱动与长镜头续写都改变了输入任务。把它们塞进同一张首帧的候选表，显存或画质数字再精确，也不能构成同条件对照。

先定义一段短片什么情况下算能用

首帧任务的输入已经固定了不少视觉信息，却没有自动定义后续动作。可以先写一条可以观察的目标：人物在片段内把杯子拿起，然后放回桌上，脸和服装不发生明显变化。与此同时，说明允许什么镜头运动、允许物体暂时遮挡多久、输出时长是否必须覆盖完整动作。这个例子只是待测任务，不是任何模型已经完成的演示。

如果没有这一层约定，两条后端会很容易在不同问题上“赢”。一条只生成缓慢推镜，人物始终稳定；另一条尝试拿杯子，却出现接触错误。前者可能更漂亮，却没有完成拿杯子这个任务。反过来，动作完整但人物被替换，也可能不符合首帧身份要求。先写需要保留的对象和需要发生的动作，才有办法把容量与业务可用性接起来。

输入图也要先检查。低清脸部、被裁掉的手、遮挡严重的杯子，都会让后续评价缺少可观察的起点。如果两条路径实际使用不同裁剪，人物位置和动作空间便已改变。保留原图和两边实际送入模型的尺寸、裁剪或缩放记录；若必须适应不同长宽比，解释差异影响，避免只说“同一张图片”。

在这轮初筛中，最小任务不是越短越好，而是短到能够节省资源、又长到包含一个完整可检查动作。为了降低显存只剩一瞬间的镜头，能够证明部分生成链路完成，不能证明原短片目标已经满足。先把动作结束条件写出来，才能在调整帧数时看出有没有改变问题。

Wan 的 24GB 注释，紧跟的是 T2V 命令

Wan2.2 官方 README在 TI2V-5B 章节先给出单卡Text-to-Video命令：--task ti2v-5B、--size 1280*704，并使用--offload_model True、--convert_model_dtype、--t5_cpu。紧接这条命令，文档标注“至少 24GB VRAM”。下一段才给出单卡Image-to-Video命令，增加--image，但没有给 I2V 单独写一个最低显存保证。

因此 TI2V-5B 的 I2V有官方入口，值得在目标卡上做容量探针；“24GB 一定能完成这次 I2V”仍是待测命题。README 还说明 TI2V-5B 支持 720P/24fps 的 T2V 与 I2V；能力支持也不能替代本次设置下的完整生成记录。

同一仓库的 I2V-A14B 单卡示例标注至少 80GB VRAM。在仅有一张 24GB 卡的预算下，可以先排除这一条官方单卡路径。这不意味着第三方量化、分布式或其他配置绝对无法运行；若使用它们，需要另列实现来源、权重与条件，不能挪用 TI2V-5B 的那一行。

从文档数字到候选，必须把限定词带过去

读官方 README 时，可以把命令、紧接的注释和所属任务标题一起保存。显存数字如果脱离了这些相邻文本，就容易在笔记中变成整个模型家族的通用门槛。这里 Wan 的例子尤其具体：任务名包含文字与图片能力，不等于每一种输入都有同样的容量保证；添加图片输入后，仍要看完整路径的实际资源。

筛选时也应保留排除的范围。A14B 这一条官方单卡命令超出预算，所以本轮不跑它；结论只约束这条命令，不约束所有可能的压缩或替代后端。若后续采用另一个实现，实验对象就是“某实现、某权重、某配置”，不是把同一家族名称搬回原表。这样既不会过度排除，也不会用未经核验的第三方成功消息替换官方条件。

有时读者会问，既然未保证 I2V 的 24GB，为什么还要保留 Wan 候选？因为有匹配图片输入的官方入口，已足以支持一次有限成本的容量探针。候选筛选可以允许未知项，前提是将未知项明示，并设定试验预算；它不需要先证明全部条件，也不能先宣布结果。真正要避免的是把“值得试”提前写成“保证可交付”。

文档核对日期也属于条件。本文保留的是既有版本的入口解释，未来 README 若增加 I2V 实测，应重新保存版本和上下文；旧文章的数值不应自动覆盖新命令。使用旧配置复现时反而应该回到旧 commit，保证参数含义与这次记录一致。

Hunyuan 的 14GB，绑定模型卸载

HunyuanVideo-1.5 官方仓库提供 I2V 入口，列出的最低 GPU 显存是 14GB，并明确注明启用model offloading。这个数字说明可把官方 I2V 路径纳入候选，却不能推出本次约 720P 设置已经在 24GB 卡完成，也不能推出比 Wan 更快或更省总资源。

卸载可能把部分负担移到系统内存和数据传输。实际峰值要看权重、精度、分辨率、帧数、VAE 和推理配置。特别是“权重成功加载”与“采样、解码、编码全部完成”不能写成同一个成功。

卸载之后，要追完整任务的资源路径

GPU 显存不足通常最醒目，但卸载场景还有主机内存、数据传输与磁盘。可以先观察模型装载是否完成，再观察采样是否持续推进，最后观察视频是否被完整解码和写入。若装载很顺利、到解码阶段才失败，继续讨论权重参数量并不能解释峰值；若 CPU 内存不足导致进程退出，降低 GPU 常驻量也未必解决。

假设 Hunyuan 路径能在目标卡装载，采样结束后却因资源问题没有成片。它应记为“采样完成、完整输出失败”，不记成可运行；假设 Wan 只有缩短帧数后完成，则新记录应写缩短后的输出条件。两个假设都没有替任一模型下结论，只说明为什么成功记录必须贯穿加载、采样、解码和编码。

测峰值时要注明工具和单位，并记录任务开始前的空闲资源。工作站上的其他进程可能占用显存或主机内存，造成同命令不同结果。先把与本轮任务无关的占用情况记录下来，不能在不知道用途时直接结束其他进程。用于候选比较的环境尽量固定，资源不足时明确写出外部占用，使下次复现者能够解释差异。

卸载还会影响等待体验。加载慢、首轮慢与持续采样慢，对一次性创作和长期驻留服务的意义不同。因此保留冷启动总耗时与稳定运行阶段的时间，别只挑最短的采样片段。当前我们还没有这些本机数字，正需要由容量探针把它们补出来。

初筛得到两条探针，不是模型排名

表格的“保留”仅表示值得上机测。它不是“推荐先用哪一个”的性能排名。两条路径都可能因为目标时长、分辨率、系统内存或依赖而失败；也可能在不同配置下表现不同。

同一个目标，不强求内部参数完全相同

跨模型对照更适合固定用户目标，而不是机械固定每一个内部参数。两边使用同样数字的步数，未必代表相同计算量或相同生成方式；相同 Seed 也不意味着两家模型从相同随机状态产生同一条轨迹。Seed 的价值首先是让同一实现中的一次运行可追溯，不能作为跨实现随机性的等价保证。

可以先让每条官方路径按其完整默认方案完成，再逐项写出输出分辨率、帧数、帧率和耗时。若实际分辨率不同，把原始输出保留，必要时另作展示用缩放，并明确其用途。缩放后的文件可以方便观看，却不能抹去原始资源成本和生成细节差异；最终评估仍应能回到各自原片。

还要区分总预算和单次成本。假设一个模型很快，但同一动作要多次尝试才能得到可用片；另一个单次慢，却在少量尝试中就满足要求。实际选择需要保留尝试次数、失败类型和筛选过程，而不只是报告一条成功视频的耗时。本文没有足够样本做这种成本结论，只提出后续应采集的证据。

只要有一条路径尚未完成完整任务，先不要进入画质排名。可以报告两条容量结果和下一步，但不能把资源失败的视频缺失当成画质差。反之，两边都完成后，也不能只因一条更省显存就宣布它更适合任务；人物稳定、动作达成与等待预算仍须逐项判断。

把“可试”变成可复现的本机记录

固定同一张首帧、动作目标和可接受失败定义；分别保存仓库 commit、权重 revision、依赖、精度、卸载开关、提示词格式与输出设置。两家模型的默认采样步数或比例未必能逐项相等，差异应写在记录里，不用参数同名冒充同条件。

第一轮先做容量探针：模型是否加载、完整短片是否产出、OOM 发生在采样还是 VAE 解码、峰值显存与系统内存、加载/采样/解码/编码各段耗时。只有整条路径完成，才能写“在这组条件下运行通过”。

之后再用相同素材集合和多个 Seed 看首帧身份、动作是否完成、物体接触、时间连续性与失败样本。四个 Seed 可用于发现明显故障，不能据此给统计可靠的质量排名。若一条路径只能降分辨率或缩短时长才能跑通，就把它记为另一个实验条件。

输入：首帧文件 SHA、动作目标、提示词、Seed 环境：GPU/显存、驱动/CUDA、系统内存、磁盘 实现：仓库 commit、权重 revision、依赖、精度、卸载、VAE 输出：分辨率、帧数、时长、帧率 运行：加载成功？完整视频成功？失败阶段和错误？ 资源：峰值显存/系统内存、加载/采样/解码/编码/总耗时 结果：首帧身份、动作、接触、时序和失败样本 结论：官方候选 / 本机探针通过 / 需要复测 / 当前不适用

一次失败怎样减少下一轮的不确定性

容量探针失败时，先保留错误、退出码、失败阶段和资源曲线，不立即同时更换精度、帧数和卸载开关。若能够确认是解码阶段的资源峰值，下一次只验证与该阶段相关的调整；若是缺权重或依赖，先补齐环境，原任务设置暂时保持。否则第二轮即使成功，也说不清成功来自哪一处改动。

完成之后逐帧检查几个关键位置：动作开始、物体接触、动作结束和最后一帧。首帧本来受到输入图约束，只看开头会低估后段身份或物体变化。也应检查视频确实包含期望的帧数，而不是播放器能够打开就算完整。没有明显动作的静态输出需要单独记录，不能以“人物保持得很好”代替动作目标。

最小素材集合可以从一个简单动作开始，再加入一个遮挡或接触更明显的动作。每一张图分别记录，而不是把不同难度的样本合成一个印象。小样本能发现明显反例，但不支持普遍成功率；失败案例保留原始输入、输出与设置，后续更换模型时也有共同参照。

最终记录最好能够支持三个不同决策。其一是这张卡在当前配置下能不能生成完整视频；其二是这个动作目标是否达成；其三是资源与等待代价是否符合项目要求。任一项不满足就说明理由。比如完整成片但动作未达成，下一步是调整动作表达和样本，不能继续借显存数字证明业务已经可用。

如果预算只够先试一个候选，可以按环境准备程度安排顺序：已有完整依赖与权重的一条先做，另一条保留待测。不把这种排期写成模型技术排名。对个人创作，输出是否可接受可能比吞吐更紧迫；对持续服务，冷启动、驻留和重复执行成本又会改变选择。先拿到相同任务的完整证据，再决定哪一个更符合自己的工作方式。

初筛时还有一种看似公平的办法：把两个模型的结果都处理到统一画布，再评哪个好看。它适合展示，但资源与质量评价要谨慎。裁剪会隐藏边缘人物或手部问题，补帧可能改变动作流畅度，后期锐化又会改变细节观感。先保留未经额外加工的生成文件，再明确展示版做了什么；别把后期处理效果算成模型本身能力。

提示词也保持可追溯。两条路径可能对同一意图使用不同表达，应同时存用户原意和各模型实际收到的文本。如果采用自动改写，记录它的输入输出；否则所谓同动作对照，实际上可能有一边被添加了复杂运镜或细节限制。初筛阶段先选清楚、短而可观察的动作，减少这类隐含变化。

输出失败不一定都来自模型。保存目录不可写、磁盘空间不足、编码组件异常，同样可能让完整文件缺失。日志若证明视频张量已经生成而写文件失败，就把失败点记在输出环节，并在解决后用相同配置复跑。这样既不会误判模型容量，也不会因为中间过程成功便放弃完整交付核验。

在候选表的未知项被逐步填上之前，最有用的结论仍是有限的：哪些入口匹配任务、哪些条件超出当前预算、哪一次探针应该先做。表格留空比填猜测数字可靠。等实际证据回来，再把特定配置下的成功或失败写进去，文章就从初筛建议变成可复查的本机记录。

最后还要核对实际使用的代码、权重和输出用途所对应的许可证与访问条件。现在能确定的是初筛顺序和记录方式；最终后端选择要等同输入、同目标的完整本机结果。

资料：Wan2.2 官方仓库、HunyuanVideo-1.5 官方仓库，核对日期 2026-09-26。本文为官方资料分析与待执行测试设计，未运行模型。