Deep-Live-Cam 实时换脸加载 inswapper_128 失败按三层分流一次定位【免费下载链接】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 模型加载失败的三类形态不讨论换脸质量最快的排除路径是先用 CPU 提供器跑一次把「文件问题」和「环境问题」分开。Deep-Live-Cam 是一个用单张图片就能做实时摄像头换脸和一键视频换脸的开源项目而 inswapper_128 这个 ONNX 模型正位于整条换脸管线的最前端——绝大多数启动失败都会收敛在它身上。把加载失败分到三层文件、运行时、环境结论先行加载失败只有三种根因先对号入座再动手能省掉一半试错。文件层是「模型缺失或损坏」运行时层是「执行提供器或 CUDA 运行库有问题」环境层是「Python 版本、目录权限、磁盘空间这类基础条件」。下面每层都按同一套四件套展开典型报错、验证命令、最小动作、预期效果。文件层先确认 inswapper 模型不缺、没断典型报错状态栏出现Model not found in .../models或Error loading face swapper model。前者表示inswapper_128_fp16.onnx约 275MB和inswapper_128.onnx约 550MB两个文件都不在后者通常指向文件损坏或下载截断。验证命令ls models/最小动作目录为空或文件大小明显偏小就按 models 目录说明 里给出的地址把对应文件放进models/。首次启动时pre_check会尝试自动下载网络不通时会静默失败所以别假设它下过。预期效果启动后状态栏出现Face swapper model loaded successfully.换脸流程可以继续走。pre_start只要求两个 inswapper 文件至少存在其一。运行时层执行提供器与 CUDA 组件典型报错控制台报CUDAExecutionProvider not found或Failed to load library libcudnn.so。这两条基本都指向 onnxruntime-gpu 的 CUDA 运行库组件缺失cuDNN 没装或版本不匹配模型文件此时是无辜的——先排除文件再怀疑环境。还有一条CUDA graph init failed, using standard session这不是加载失败是 CUDA 图不可用后的自动回退直接忽略。验证命令先用 CPU 提供器绕开 GPU 链路确认模型本身没问题python run.py --execution-provider cpu最小动作CPU 能加载而 CUDA 不能问题就锁定在环境侧。此时两条路二选一单独补齐 cuDNN 依赖或改用python run.py启动——它在 Linux 下内置了 cuDNN 的预加载逻辑绕过它直接python -m modules.core会漏掉这一步。无界面场景还可以在modules/globals.py写死回退链execution_providers [CUDAExecutionProvider, CPUExecutionProvider]ONNX Runtime 按列表顺序执行第一个提供器跑不动的算子自动落到下一个。预期效果模型不再加载失败CUDA 确实不可用时所有子图在 CPU 执行性能等同纯 CPU管线照样跑通只是实时帧率下降。环境层Python 版本、目录权限、磁盘空间典型报错Failed to create directory ... permissionmodels 目录无写权限或进程显示 Loading face swapper model 后直接退出常见于版本或依赖不满足。验证命令看 Python 版本是否在 3.11–3.14 区间README 推荐 3.14以及nvidia-smi能否看到显卡。最小动作版本不对就用匹配版本重建 venv权限不对就换有权限的用户运行或给目录授权磁盘不足就清理models/所在分区。预期效果首次启动能自动创建models/目录并正常下载模型加载流程不再中途退出。环境基线一张表过完 11 项检查结论先行逐项过一遍下表任何一行触线就按「降级动作」处理不必逐条排查整条依赖链。检查项怎么查红线降级动作Python 版本python --version3.11–3.14推荐 3.14用匹配版本重建 venvonnxruntime-gpu 版本pip show onnxruntime-gpu必须 1.26.0requirements.txt 锁定执行pip install -r requirements.txtCUDA 环境nvidia-smiCUDA 12.x 且显卡可见改用 cpu 提供器或修复驱动models/ 目录ls models/存在且可写首次启动自动创建修复目录权限或更换运行用户inswapper_128_fp16.onnx查看文件大小约 275MB 且存在按 models/instructions.txt 下载inswapper_128.onnx查看文件大小约 550MB 且存在二者存其一即可同上models/ 所在磁盘剩余空间查看分区剩余容量≥5GB模型 临时帧清理磁盘或换到空间充足的盘onnxruntime 可用提供器onnxruntime.get_available_providers()列表非空且含你想用的提供器重装对应版本的 onnxruntime 变体execution_providers 当前值检查--execution-provider传参非空且每项都在可用列表内重新传--execution-provider参数显存与系统内存nvidia-smi/free -h有余量关闭占用 GPU 的其他进程GFPGANv1.4.pth确认是否启用 face_enhancer仅启用增强器时需要按 models/instructions.txt 下载不用增强器可忽略加载成功后再做这三个验证结论先行状态栏显示加载成功不等于万事大吉三个动作各花不到一分钟能把「静默损坏」和「提供器错配」提前暴露。完整性校验怀疑模型文件被截断或损坏时直接校验结构import onnx onnx.checker.check_model(onnx.load(models/inswapper_128_fp16.onnx))不抛异常即文件完好抛错就重新下载。可用提供器列表执行onnxruntime.get_available_providers()确认返回值包含你计划使用的提供器。列表里没有 CUDA 却想跑 GPU后面的一切报错都是预期内的。CPU 与 GPU 对比加载分别用python run.py --execution-provider cpu和默认 GPU 链路各启动一次。两次都出现Face swapper model loaded successfully.说明模型文件与两条链路都健康只有 GPU 侧失败就把注意力集中到 cuDNN 与 onnxruntime-gpu 上。进阶选项只值得动这三处加载稳定之后的调优只有三处真正值得改其余参数动了收益很小FP16/FP32 选择何时改——用 16xx 系显卡时FP16 会出 NaN怎么改——get_face_swapper在 torch 能感知 CUDA 且 fp16 文件存在时自动选 FP16否则回退 FP32想强制 FP32 就在models/只保留inswapper_128.onnx副作用——FP32 推理略慢、显存占用翻倍。线程与内存何时改——视频处理内存吃紧时怎么改——调低--execution-threads与--max-memorymodules/processors/frame/core.py会按帧数与线程数自动推导 batch_size没有手工批处理参数副作用——整体处理变慢。日志级别何时改——怀疑处理帧环节有问题时怎么改——把modules.globals.log_level切到 debug它控制 ffmpeg 日志副作用——处理帧时控制台输出会明显变啰嗦。都不命中去官方 issues 前备齐三样东西如果三层分流加环境基线都没定位到问题直接去项目官方 issues 页搜相同报错特征发帖前备齐三样完整控制台输出含启动命令、onnxruntime.get_available_providers()的返回值、你实际传入的--execution-provider参数或execution_providers当前值。有这三样维护者能直接判断卡在哪一层省掉来回追问。【免费下载链接】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），仅供参考