Wan-Dancer 装完跑不起来

Wan-Dancer 装完跑不起来，通常不是单一原因：要么依赖没装全、版本对不上，要么显卡撑不住默认的分辨率和精度。这两类问题在启动阶段都表现为“程序直接退出”，只看终端最后一行很容易判错方向。建议按这个顺序处理：先把完整堆栈写进日志文件，再读报错文本判断问题类型，然后分别验证依赖和显存，最后才改配置。还没读到 traceback 就升级或降级一堆包，往往会让问题更难判断。

判断可以分成三段：报错文本、依赖与版本、显存与精度。先重定向标准错误并保留完整 traceback。看到 ModuleNotFoundError 或 requires 冲突提示时先查包；看到 CUDA out of memory 时先降分辨率与精度；看到 no CUDA-capable device 或 CUDA unavailable 时先确认驱动和设备可见性。每次改动都要能用一条命令复现，否则换机器后同样的问题还会出现。边界：下文命令中的脚本名、配置字段需要按项目实际入口替换，不要照抄。

把启动时的完整报错和堆栈原样留存到日志文件

终端滚过去的报错经常只剩最后一行，而最后一行通常只说明进程退出。因此在项目根目录先执行下面的命令，把标准输出和标准错误一起写入文件，再从文件末尾向前阅读：

mkdir -p logs PYTHONUNBUFFERED=1 python infer.py `--config` configs/infer.yaml > logs/run.log 2>&1 # 想同时看屏幕就加 tee PYTHONUNBUFFERED=1 python infer.py `--config` configs/infer.yaml 2>&1 | tee logs/run.log

第一条只做重定向，适合启动几秒就退出、来不及看清的情况；第二条用 tee，适合需要一边运行一边观察。infer.py 和配置路径要换成仓库实际的推理入口，这类视频生成项目常见的是 infer、generate、demo 等脚本，按 README 给出的入口写。加 PYTHONUNBUFFERED=1 是为了避免进程崩溃时缓冲区里的日志还没写入文件。

打开 logs/run.log 后，重点检查这几类行：

• 缺包：ModuleNotFoundError、ImportError: cannot import name 开头的行；

• 版本冲突：pip 输出的 requires ... which is not installed、incompatible 提示，或 import 时报 undefined symbol；

• 显存与设备：CUDA out of memory、Torch not compiled with CUDA enabled、no CUDA-capable device。

读完这一段，基本可以决定往哪个方向查：命中依赖类关键词，就接着看第二、三节；命中显存或设备类关键词，可以直接跳到第四节。中途不要顺手升级或降级一堆包，否则会把你刚拿到的线索冲掉。

对照报错确认是缺包还是版本对不上

依赖问题的典型特征是“还没碰到显卡就退出”。先把当前环境装了什么记录成快照，再和项目声明的版本范围比对：

python -V pip list `--format`=freeze | sort > logs/pip-freeze.txt pip check pip show torch torchvision transformers diffusers accelerate pipdeptree -p torch # 需先 pip install pipdeptree

pip check 会直接列出互相冲突的包；pipdeptree -p torch 能看出是哪个依赖把 torch 拉到了不想要的版本。接着打开项目的 requirements.txt 或 pyproject.toml，逐条比对带 >=、<、~= 的范围要求，确认当前装的版本是否落在区间内。torch 的版本还要和 torch.version.cuda、nvidia-smi 里的驱动版本对得上，CUDA 运行时对不上时，常见表现就是 undefined symbol 或加载阶段直接崩。下面的对照表用于把报错文本快速归到某一类，只作分流，不作结论。

日志里的文本特征大概率属于先查什么No module named / ModuleNotFoundError缺包，或用错了解释器虚拟环境是否激活，pip 和 python 是否同一环境cannot import name / undefined symbol包与包、包与 CUDA 版本不兼容pip show 的版本、torch.version.cudarequires ... but you have ...依赖冲突pip check、pipdeptreeCUDA out of memory显存帧数、分辨率、精度、batch_sizeTorch not compiled with CUDA enabled / no CUDA-capable device运行环境或驱动下一节的最小示例expected scalar type Half but found Float精度配置与权重类型不匹配dtype 配置与权重精度

用最小可跑示例确认框架能识别到显卡

这一节只验证一件事：框架能不能看到显卡。不加载模型、不读权重，单独跑下面这段：

Wan-Dancer 装完跑不起来——卡在依赖还是显存？

import torch print('torch', torch.__version__, 'cuda', torch.version.cuda) print('available', torch.cuda.is_available(), 'count', torch.cuda.device_count()) for i in range(torch.cuda.device_count()): p = torch.cuda.get_device_properties(i) print(i, p.name, round(p.total_memory / 1024**3, 1), 'GiB')

预期输出是 available 为 True、count 至少为 1，并且每个设备一行，带型号和显存总量。如果 available 是 False 而 nvidia-smi 能看到卡，问题在驱动、CUDA 运行时，或容器没有把设备传给进程，不在这段代码里；如果输出的显存总量明显小于模型权重文件的体积，说明默认配置本身就放不下，直接进第四节。把这段输出连同 nvidia-smi 的结果存进 logs，后续改环境时可以作为对照。

降低精度与分辨率再试一次

显存不足的报错文本有固定特征：CUDA out of memory. Tried to allocate ... MiB. GPU 0 has a total capacity of ... of which ... is free，有时后面还会说明申请的张量尺寸。看到这句再降配；如果报的是维度不匹配、权重 key 不存在之类的逻辑错误，降精度不会让它消失，只会把问题延后。

降配的落点在配置文件或启动参数里，通常能在这几个字段上调整，字段名按项目实际改：

# configs/infer.yaml 示例 resolution: [480, 832] num_frames: 16 # 视频类模型先砍帧数通常最有效 batch_size: 1 dtype: fp16 # 可选 fp16 / bf16，bf16 需要较新的卡 cpu_offload: true # 项目支持的话可以先打开

顺序建议：先降帧数和分辨率，再换 dtype，最后才考虑 offload。bf16 对显存更友好，但对硬件有要求；fp16 在老卡上更常见，可也可能带来数值问题。如果报错从 OOM 变成了 NaN 或画面异常，说明精度或分辨率选得不合适，退回更保守的组合再验证。降到能跑之后，逐项加回去，每加一项记录一次日志，才能知道到底是哪一项占用了显存。另外，如果 OOM 出现在模型加载第一步，说明权重都放不下，跟分辨率无关，要从精度和分片加载考虑。

把跑通的环境与参数固化成一条启动命令

跑通那一次的环境是最值得留下的产出。建议把下面这份清单写进 logs/env.txt，同时把命令固化成 run.sh：

# logs/env.txt 记录模板 gpu: # nvidia-smi 里的型号，单卡显存 GiB driver: # nvidia-smi 右上角的 Driver Version cuda_runtime: # torch.version.cuda python: # python -V torch: torchvision: transformers: diffusers: accelerate: weights: # 权重版本标识 + 精度（fp16/bf16） infer_args: # 分辨率、帧数、步数、batch_size、dtype command: # 实际跑通的完整命令

# run.sh set -e cd /path/to/project PYTHONUNBUFFERED=1 python infer.py `--config` configs/infer.yaml 2>&1 | tee logs/run.log

换机器时先跑第三节那段设备查询，确认显卡和显存总量对得上，再执行 run.sh。如果新机器显存更小，直接按第四节把 num_frames 和分辨率降到记录值以下再试，比从头猜配置快得多；如果设备查询结果一致但仍然启动失败，回到第一节比对两次日志的差异，通常能从第一处不同定位到真正的变化点。