本地跑 Hypit 生成视频时显存不够，通常不是 Hypit 本身坏了，而是分辨率、帧数、批量大小三者叠加超出显卡可分配显存。判断路径建议按顺序走：先在启动日志里确认报错确实来自显存分配失败，再记录当前分辨率与帧数作为可回退基线，然后只降分辨率跑到能完整出片的最小值，仍不够再降帧数或减少单次生成帧数，最后在跑通的基础上逐项恢复参数，把本地稳定值记下来。风格、运镜、质感这些属于画质层面的调参，应放在流程能稳定出片之后再做，否则很容易把显存问题误判成模型或提示词问题。

显存不足时不要一上来就换模型或改提示词，先区分报错是不是显存分配失败，再固定当前分辨率、帧数、批量大小作为基线。降级顺序建议先分辨率（1080p→720p→480p），再帧数或单次生成帧数，每次只改一个维度并观察能否完整出片。跑通后按相反顺序逐项恢复并记录稳定值。不同显卡、不同精度和是否启用显存卸载，边界差别较大，需要结合本机环境确认，不要直接套用他人配置。

在启动日志里确认显存不足的报错信息

第一步不是调参数，而是确认报错类型。显存不足和模型路径写错、依赖缺失、编解码器不可用这几类错误，处理方式完全不同。先找到日志位置，再按关键词筛一遍。

日志通常出现在这几个位置，按实际部署方式确认：

• 直接在前台运行时，看终端 stdout / stderr 输出；
• 用脚本或服务运行时，看脚本里重定向的日志文件路径，例如 logs/ 目录下带时间戳的文件；
• 用容器运行时，用 docker logs <容器名> 或等价命令查看；
• 用 systemd 托管时，用 journalctl -u <服务名> -n 200 查看最近日志。

显存相关的报错关键词占位，按你实际框架输出的原文匹配即可，不要凭记忆去凑：out of memory、CUDA out of memory、OOM、failed to allocate、memory 与 allocate 同段出现。如果报错里出现的是文件找不到、模块导入失败、编码器打不开，那属于另外一类问题，不要按显存不足处理。

另外提一句：显存不足有时表现为进程被系统直接杀掉，日志末尾没有明显报错。这种情况可以用 nvidia-smi 在生成过程中另开一个终端观察显存占用曲线，看是否在某一帧附近冲到接近上限后进程消失。

记录当前任务的分辨率、帧数和批量大小

调参之前先留基线，否则降下去之后不知道该恢复到哪。找到实际生效的配置文件（不同部署方式可能是 YAML、JSON、Python 参数或命令行参数），把当前的这几个配置项抄一份出来。配置项名称以你本机的实际文件为准，常见占位如下：

• 分辨率：resolution、width / height、size
• 帧数：fps、frame_rate、num_frames、video_length
• 批量：batch_size、num_videos
• 精度与卸载：dtype、precision、offload、cpu_offload 一类开关

# 示例：把当前生效配置复制一份留档，名称按你的实际文件改
cp config.yaml config.baseline.yaml
diff config.baseline.yaml config.yaml   # 之后每次改动都能看出差异

如果配置来自命令行参数，建议把完整启动命令写进一个脚本文件再执行，这样命令行本身就是可回退的记录。

先降分辨率到能完整出片的最小值

分辨率对显存的影响通常比帧数更直接，所以先动分辨率。降级顺序建议按 1080p → 720p → 480p 逐级往下试，每次只改一级，改完立刻跑一次最短可用的生成任务，不要一次跳两级。宽度和高度建议保持常见比例，避免触发某些环节的尺寸对齐问题。

每降一级需要观察的指标：

• 任务是否从头跑到结束，输出文件是否完整、能否正常播放；
• 生成过程中 nvidia-smi 显示的显存占用峰值是否仍贴近上限；
• 单帧或单步耗时是否明显变长（有时显存换入换出会让速度崩掉，这也是要留意的信号）；
• 日志里是否还出现显存分配失败的原文。

只要在某一档能稳定跑完整段视频，就先把这一档记下来，不要急着继续往下降。继续降虽然更容易跑通，但会浪费掉本来可用的画质空间。

再降帧数或减少单次生成帧数

如果分辨率已经降到 480p 仍然报显存不足，说明剩下的显存压力主要来自帧数维度，这时候再动帧数。可试的调整方式有两类，改哪一种取决于你的配置结构：

• 降输出帧率：例如 24 → 16 → 12，先看是否还报显存不足；
• 减少单次生成的帧数：把一次生成的长片段拆成多段分别生成，再拼接。配置里对应的可能是 num_frames 或分段长度一类的项。

# 示例：分辨率固定后，只调整帧数相关项，逐次运行
# resolution: 480p
# fps: 24 -> 16 -> 12
# num_frames / video_length: 按片段长度逐步减半尝试

验证方式很简单也很明确：能否生成一段完整片段。分段生成时要额外确认两个点——各段之间画面是否连续（避免接缝跳变），以及拼接后的总时长是否与预期一致。如果只是能出文件但时长对不上，说明分段参数没配好，不算跑通。

跑通后逐步恢复参数并记录稳定值

跑通之后不要停在最低档，按与降级相反的顺序往回恢复，每次只恢复一项，跑一次记录一次。建议的恢复顺序是：先把分辨率提回上一档，稳定后再提帧数，最后再考虑提高单次生成帧数或批量。任何一步出现显存不足或生成中断，就退回上一步并把它作为当前边界。

记录表按下面几列维护即可，填自己的实际值：

这张表的用处是，下次换提示词或调风格时，能快速退回一个已知可用的配置，而不是重新从报错开始试。显存边界和显卡型号、精度设置、是否启用显存卸载都有关系，同一档参数换一台机器结论可能不同，所以记录的是本机稳定值，不是通用推荐值。