EchoWM 这类交互式视听生成模型，显存不是由某一个参数单独决定的：分辨率决定单帧张量的大小，帧长决定时间维度上要同时保住多少份中间激活，帧率往往还牵动抽帧数量或时间步数。在本机试跑之前，先把这三个量里能用仓库配置控制的项找出来，再固定其中两项、只动一项，才可能得到一条自己能复现的显存曲线；否则一跑就爆显存时，很难判断到底是帧长太长，还是分辨率太高。

先跑一次最短生成，用 nvidia-smi 在权重加载后、推理中、结束后各记一次显存峰值，建立本机基线；然后固定分辨率与帧率，只按固定步长加大帧长，记录“时长—显存峰值—单次耗时”三列。显存随时长线性上升，说明时间维度是主要成本；很快触顶则瓶颈更可能在分辨率或注意力实现。爆显存后按分辨率→帧长→帧率→精度/分块的顺序降级，每步复测并把可用参数写回配置文件。

在仓库配置与说明里确认能调的输入参数

不要凭猜测改参数。先在仓库根目录定位推理入口和配置文件：README 里的 inference / demo 一节通常给出启动命令；命令指向的脚本里，时长、分辨率、帧率这类参数一般出现在 argparse 的 add_argument、dataclass 配置类，或单独放在 configs、examples 目录的 yaml/json 文件里。用一次全仓库检索把候选字段找出来，字段名以仓库说明和源码为准，不要照搬下面示例里的拼写：

# 在仓库根目录执行，先看哪些文件同时出现帧数/时长/分辨率/帧率相关词
ls
sed -n '1,80p' README.md   # 找 inference / demo / usage 段

grep -rn -E "num_frames|frame_num|n_frames|length|duration|fps|frame_rate|height|width|resolution" \
  `--include`="*.py" `--include`="*.yaml" `--include`="*.yml" `--include`="*.json" . | head -50

检索结果里，出现在 argparse 或入口 yaml 中的字段才是命令行可覆盖的；如果只出现在模型内部构造函数里，说明它由配置文件派生，改上层字段即可。确认方式很简单：对推理脚本执行 `--help`（例如 python infer.py `--help`），看哪些参数能被命令行覆盖、默认值是多少、单位是帧还是秒。把这份参数清单记下来，后面每次实验只改其中一项。

用系统监控记录一次最短生成的显存峰值

先用仓库示例里最短、最小的一次生成跑通，不追求效果，只为拿到本机基线。开一个终端做轮询采样，另开一个终端跑生成：

# 终端 A：每秒采样一次，落盘方便回看
nvidia-smi `--query-gpu`=timestamp,memory.used,memory.total,utilization.gpu \
  `--format`=csv -l 1 | tee mem_watch.csv

# 终端 B：用仓库示例参数启动一次最短生成（占位符按仓库实际命令替换）
python infer.py `--config` <示例配置> `--seed` 0 `--output` <输出目录>

观测时机按三段看：权重加载完成后先看一次（这是同进程内的空闲基线，包含框架和权重本身的开销），日志出现采样、去噪或前向步骤时再看一次（这是峰值最可能出现的位置），进程退出或等待数秒后再看一次（缓存不一定会立刻归还，所以不要拿退出后的数值当作下一轮的起点）。三次数值记在同一行，后面所有对照都只和这个基线比。

只加大时长，记录显存随时长的变化

固定分辨率、帧率和采样设置，只改帧长或时长字段。递增步长取仓库默认值的约四分之一到一半比较省时间：默认帧长是两位数时，加 8 或 16 帧一轮；默认很短时可以先翻倍。每轮都按上一节的方式采样，填进下面这张对照记录表（列固定为三段观测，可另存为 CSV 或电子表格）：

看趋势而不是看单点：如果峰值随帧长大致按比例上升，说明时间维度上的激活是主要成本，降帧长会直接有效；如果加到某一档后曲线突然变陡或直接报错，先怀疑是不是触发了显存分配碎片或某个固定缓存，而不是继续按线性外推。单次耗时同时记下来，是因为交互式场景下能忍受的等待时间往往比显存更早成为限制。

只加大分辨率或帧率，找到最先触顶的那一项

把帧长退回到一个确定能跑通的值并锁死，然后分两组做：一组只逐步抬高分辨率（尽量保持宽高比，避免个别尺寸触发非最优的算子实现），一组只抬帧率或抽帧数量。两组各自记录同样的三列数据，把先报显存不足的那一组标出来，它就是你这台机器上的成本大头。

判定口径要统一：显存不足通常表现为 CUDA out of memory 一类报错，关键是看它出现在哪一步——如果是权重还在加载、模型还没开始推理就报错，说明是权重和框架本身超了，调帧长分辨率都没用；如果是推理中途报错，日志里那一行前面的步骤名（采样步、注意力前向、解码等）就是定位线索。日志位置按启动方式确认：前台运行的终端输出、重定向的 nohup.out、logs 目录下的文件，或 Web 演示页后端所在终端的输出。同一轮报错要连上下文一起复制进记录表，不要只记一句 OOM。

按代价从低到高做降级并复测

降级顺序按对生成质量的影响、对连续性的影响和改起来是否麻烦来排，从代价低的一头开始，每降一档就重跑一遍并复测：

1. 降分辨率：对画面细节影响直观但最容易收回显存，先把宽高降到上一档能跑通的值。
2. 降帧长或时长：直接减少时间维度的激活量；交互式场景里缩短单次生成、用更短的片段承接，通常比一次性生成长片段更稳。
3. 降帧率或抽帧数量：注意这会改变画面节奏，需要和播放端一起确认可接受范围。
4. 换更省的精度或注意力实现：只在仓库确实提供开关时使用，改了要重跑同一组参数确认结果没有明显劣化。
5. 分段生成再拼接：作为最后的办法，拼接处的时间连续性需要另外检查，不要把带 seam 的结果当作可用参数。

每步复测的验证方式保持一致：用第 2 节的 nvidia-smi 采样跑同一段输入，连续两次不报显存不足、峰值有明显余量、单次耗时在你能接受的范围，才算这一档可用。确认后把帧长、分辨率、帧率这三个值写回配置文件或启动命令（写回配置比每次敲命令行更不容易漏项），并在记录表里标注最终组合和它的显存峰值。同一块卡在不同驱动、不同框架版本下余量会变，换了环境建议重跑一次最短生成，重新确认基线。