Deep-Live-Cam 模型加载失败排查按启动阶段一次定位 4 个故障点【免费下载链接】Deep-Live-Camreal time face swap and one-click video deepfake with only a single image项目地址: https://gitcode.com/GitHub_Trending/de/Deep-Live-Cam第一次启动 Deep-Live-Cam 就遇到模型加载失败时原因大概率逃不出三种inswapper_128 模型文件不在、CUDA 运行库组件没配齐、执行提供器链断掉。这篇文章把启动过程拆成四个阶段先帮你判断故障落在哪一环再给出对应的动手步骤。内容只覆盖换脸模型的加载链路换脸质量与编码参数不在范围内。报错关键词分诊把故障对号到 4 个启动位置先扫一眼控制台和状态栏的原文确定该去哪个章节查启动前Failed to create directory ... permission—— models 目录建不出来当前账号没有写权限。模型获取Model not found in .../models—— 两个 inswapper 文件都不在。会话创建CUDAExecutionProvider not found、Failed to load library libcudnn.so—— 提供器链走不通。加载之后Error loading face swapper model—— 文件损坏或下载被截断。CUDA graph init failed, using standard session不属于失败表示 CUDA 图初始化没成功、程序已自动回退标准会话看到它可以忽略。启动前检查清单3 个前提条件 2 分钟核对运行环境。Python 需要在 3.11–3.14 之间README 推荐 3.14。在虚拟环境里执行python --version核对版本对不上就按合适版本重新建一个 venv。依赖版本。requirements.txt 把 GPU 运行时锁死在onnxruntime-gpu1.26.0。装完依赖执行一次pip install -r requirements.txt再用pip show onnxruntime-gpu确认装上的是 -gpu 变体而不是普通 onnxruntime否则 CUDA 提供器永远不在可选列表里。磁盘与目录权限。models 目录首次启动时自动创建运行账号必须对项目根目录有写权限磁盘至少留出 5GB装得下模型本体和视频处理时的临时帧。显存与系统内存是否宽裕用nvidia-smi和free -h各看一眼紧张就先关掉其他占用 GPU 的进程。阶段一模型文件缺失与自动下载静默失败状态栏出现Model not found in .../models时判断很简单modules/processors/frame/face_swapper.py 的 pre_start 只要求下面两个文件至少存在一个这条提示说明两个都没有。目录为什么是空的pre_check 发现缺文件会尝试自动下载网络不通时只在控制台打一行[DLC.MODELS] Failed to download ...就放弃进程照常往下走状态栏还会追加一句让你手动放置 inswapper_128.onnx 或检查网络的提示。所以动手前先验证ls models/两个文件都没有或体积明显偏小 —— 按 models/instructions.txt 里记录的地址手动补全。目标是inswapper_128_fp16.onnx约 275MB或inswapper_128.onnx约 550MB存其一即可。打算开 face_enhancer 增强器 —— 另需把GFPGANv1.4.pth放进同一目录不用增强器则忽略。文件明明在、启动仍失败 —— 问题不在这一环继续看阶段二。预期结果重新运行后状态栏从Loading face swapper model走到Face swapper model loaded successfully。阶段二执行提供器与会话创建先排除环境侧嫌疑。报CUDAExecutionProvider not found时绝大多数情况是 onnxruntime-gpu 依赖的 CUDA 运行库组件如 cuDNN没装或版本不匹配模型文件本身通常没有嫌疑。成本最低的动作是换一条确定能走通的路python run.py --execution-provider cpu对照结论cpu 路径能加载成功说明模型文件被排除嫌疑问题锁定在环境侧之后单独修 cuDNN 与驱动即可。CPU 下帧率会降但整条管线能跑通。⚠️启动入口别绕开 run.py。在 Linux 上run.py 会在建会话之前用 ctypes 把 venv 里 cuDNN、cuBLAS 等共享库预加载进进程换成python -m modules.core等方式进入会跳过这一步直接撞上Failed to load library libcudnn.so。统一用python run.py启动。无界面场景可以固定回退链。在 modules/globals.py 中把提供器列表写成execution_providers [CUDAExecutionProvider, CPUExecutionProvider]列表按顺序逐个尝试头部提供器跑不动的算子会自动落到下一位GPU 链路断了模型依旧能加载。预期结果是加载不再报错CUDA 确实不可用时所有子图落在 CPU 上执行性能等同纯 CPU。阶段三加载之后的验证与常见误判用 cpu/cuda 对照划分责任。同一条模型文件分别走两种提供器只有 cuda 挂、cpu 正常查环境驱动、cuDNN、onnxruntime 变体两边都挂优先怀疑文件本身。精度版本是自动选的。torch 能感知到 CUDA 且 models/ 下放着 fp16 文件时加载 FP16 版本其余情形一律用 FP32。16xx 系显卡是特例FP16 推理可能输出 NaN这类卡遇到画面异常就改用 FP32 文件。怀疑文件损坏时做完整性校验python -c import onnx; onnx.checker.check_model(onnx.load(models/inswapper_128_fp16.onnx))静默跑完代表结构有效抛出异常就重新下载。想看更多日志细节把modules.globals.log_level切到 debug处理帧阶段的 ffmpeg 输出会变啰嗦但信息更全。批处理大小没有手工开关。批尺寸由 frames 数量与线程数在modules/processors/frame/core.py内部推导视频处理内存吃紧时调低--execution-threads与--max-memory可以间接把批缩下来。仍无解时带 2 份材料去求助以上都没命中时别只贴一行报错就提问。把完整控制台输出连同onnxruntime.get_available_providers()的返回值它直接列出你的 onnxruntime 实际装了哪些提供器一起收集好再到项目官方 issues 页搜索相同报错特征的历史工单。带着这两份材料提问基本能一次对上症结。【免费下载链接】Deep-Live-Camreal time face swap and one-click video deepfake with only a single image项目地址: https://gitcode.com/GitHub_Trending/de/Deep-Live-Cam创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考