尧图网站建设 
Deep-Live-Cam inswapper_128 ONNX 模型加载失败5分钟定位与修复三类典型报错【免费下载链接】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看到CUDAExecutionProvider not found、状态栏提示Model not found in .../models或者停在 Loading face swapper model 后进程直接退出时你遇到的都是同一个问题inswapper_128 这个 ONNX 模型ONNX 是一种跨平台推理模型格式没能在执行提供器上建起推理会话。本文覆盖这三类加载失败的排查与修复不涉及换脸质量与编码参数。症状识别与快速分流模型加载失败的表现基本收敛为下面四种先对照你实际看到的内容控制台报CUDAExecutionProvider not found或加载阶段抛 CUDA 相关异常 → 跳到「提示 CUDAExecutionProvider not foundCUDA 运行库缺失」状态栏提示Model not found in .../models或Could not obtain the inswapper model→ 跳到「提示 Model not foundinswapper_128 模型文件缺失」Linux 终端打印Failed to load library libcudnn.so→ 跳到「Linux 报 Failed to load library libcudnn.socuDNN 未被预加载」显示 Loading face swapper model 后无成功提示、帧处理直接跳过 → 依次排查上面三个分支再看「环境基线核查」四个症状都不命中时直接进「环境基线核查」逐项过一遍。分支诊断与修复提示 CUDAExecutionProvider not foundCUDA 运行库缺失现象控制台报CUDAExecutionProvider not found状态栏停在 Loading face swapper model换脸帧被跳过。根因执行提供器Execution Provider是 ONNX Runtime微软开源的推理引擎里决定算子跑在哪块硬件上的后端。这个报错几乎都是 onnxruntime-gpu 缺少 CUDA 运行库组件——cuDNNNVIDIA 深度学习加速库没装或版本不匹配导致 GPU 提供器注册失败与模型文件本身无关。修复先不动任何文件切到 CPU 提供器绕开 GPU 会话创建python run.py --execution-provider cpuCPU 能加载说明模型文件完整问题锁定到环境侧之后单独重装 onnxruntime-gpu 或补装 cuDNN不必怀疑模型。验证状态栏出现Face swapper model loaded successfully实时帧率会降但管线跑通。提示 Model not foundinswapper_128 模型文件缺失现象状态栏提示Model not found in .../models或下载阶段打印Could not obtain the inswapper model。根因modules/processors/frame/face_swapper.py 的 pre_check 会自动下载inswapper_128.onnx或inswapper_128_fp16.onnx网络不通时下载静默失败models 目录保持为空pre_start 检查发现两个文件都不存在就抛出 Model not found。修复先确认目录内容ls -lh models/目录为空或文件被截断完整的inswapper_128.onnx应为 554253681 字节时按 models/instructions.txt 给出的下载地址手动取回文件放入models/两者存其一即可。验证重新启动后状态栏出现Face swapper model loaded successfully且加载日志指明实际使用的模型路径。Linux 报 Failed to load library libcudnn.socuDNN 未被预加载现象终端打印Failed to load library libcudnn.soCUDA 会话创建失败。这个坑我踩过绝大多数是启动方式造成的。根因run.py 启动时内置了一段 Linux 预加载逻辑用ctypes.CDLL把 venv 里nvidia/*/lib下的 cuDNN 等共享库提前加载进进程onnxruntime 的 CUDA 提供器 dlopen 时才能找到。绕过它直接python -m modules.core启动就会漏掉这一步。修复改回用入口脚本启动python run.py无界面场景也可以固定回退链把 modules/globals.py 中execution_providers一行的赋值改为execution_providers [CUDAExecutionProvider, CPUExecutionProvider]ONNX Runtime 按列表顺序执行第一个提供器跑不动的算子自动落到下一个GPU 链路失效时模型依然能加载。验证加载不再失败CUDA 确实不可用时所有子图落在 CPU 执行性能等同纯 CPU。环境基线核查上面三个分支之外还有几项读者自己不容易意识到的环境约束逐项打勾✅ Python 版本 → 不低于 3.11README 推荐 3.14python --version检查 → 不满足时用匹配版本重建 venv✅ onnxruntime 变体版本 → 非 macOS 锁定onnxruntime-gpu1.26.0macOS arm64 为onnxruntime1.28.0见 requirements.txt → 执行pip install -r requirements.txt✅ CUDA 与驱动 →nvidia-smi可见显卡且为 CUDA 12.x → 改用 cpu 提供器或修复驱动✅ models/ 目录权限 → 存在且可写首次启动自动创建无权限会打印Failed to create directory→ 换有权限的用户运行✅ insightface 检测包 →~/.insightface/models/buffalo_l/下 5 个 onnx 文件齐全缺了会自动下载 → 网络不通时手动补齐✅ 磁盘剩余空间 → models 目录所在分区 ≥5GB → 清理磁盘或换到空间充足的盘✅ 可用执行提供器 →onnxruntime.get_available_providers()返回非空且包含想用的提供器 → 重装对应变体✅ 显存与内存 →nvidia-smi/free -h有余量 → 关闭占用 GPU 的其他进程跑通之后的调优与边界能加载成功之后下面几个点决定体验好坏。FP16/FP32 自动选择。get_face_swapper() 在 torch 能感知 CUDA 且 fp16 文件存在时自动选 FP16显存带宽减半否则回退 FP32。注意 16xx 系显卡GTX 1650/1660/1660 Ti 等没有 Tensor CoreFP16 推理会出 NaN把models/里的inswapper_128_fp16.onnx移走即可强制走 FP32。批处理大小。modules/processors/frame/core.py 按帧数与线程数自动推导 batch_size没有手工参数。视频处理内存吃紧时调低--execution-threads与--max-memory就能间接缩小批次。模型完整性校验。怀疑模型损坏或下载截断时直接校验文件python -c import onnx; onnx.checker.check_model(onnx.load(models/inswapper_128.onnx)); print(OK)日志级别。modules.globals.log_level 默认是 error切到 debug 后处理帧时 ffmpeg 相关输出会变啰嗦适合排查帧读取和编码环节的问题排完记得切回去。如果以上都没命中把完整控制台输出和onnxruntime.get_available_providers()的返回值一起收集去项目官方 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），仅供参考 Deep-Live-Cam inswapper_128 ONNX 模型加载失败：5分钟定位与修复三类典型报错
Deep-Live-Cam inswapper_128 ONNX 模型加载失败5分钟定位与修复三类典型报错【免费下载链接】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看到CUDAExecutionProvider not found、状态栏提示Model not found in .../models或者停在 Loading face swapper model 后进程直接退出时你遇到的都是同一个问题inswapper_128 这个 ONNX 模型ONNX 是一种跨平台推理模型格式没能在执行提供器上建起推理会话。本文覆盖这三类加载失败的排查与修复不涉及换脸质量与编码参数。症状识别与快速分流模型加载失败的表现基本收敛为下面四种先对照你实际看到的内容控制台报CUDAExecutionProvider not found或加载阶段抛 CUDA 相关异常 → 跳到「提示 CUDAExecutionProvider not foundCUDA 运行库缺失」状态栏提示Model not found in .../models或Could not obtain the inswapper model→ 跳到「提示 Model not foundinswapper_128 模型文件缺失」Linux 终端打印Failed to load library libcudnn.so→ 跳到「Linux 报 Failed to load library libcudnn.socuDNN 未被预加载」显示 Loading face swapper model 后无成功提示、帧处理直接跳过 → 依次排查上面三个分支再看「环境基线核查」四个症状都不命中时直接进「环境基线核查」逐项过一遍。分支诊断与修复提示 CUDAExecutionProvider not foundCUDA 运行库缺失现象控制台报CUDAExecutionProvider not found状态栏停在 Loading face swapper model换脸帧被跳过。根因执行提供器Execution Provider是 ONNX Runtime微软开源的推理引擎里决定算子跑在哪块硬件上的后端。这个报错几乎都是 onnxruntime-gpu 缺少 CUDA 运行库组件——cuDNNNVIDIA 深度学习加速库没装或版本不匹配导致 GPU 提供器注册失败与模型文件本身无关。修复先不动任何文件切到 CPU 提供器绕开 GPU 会话创建python run.py --execution-provider cpuCPU 能加载说明模型文件完整问题锁定到环境侧之后单独重装 onnxruntime-gpu 或补装 cuDNN不必怀疑模型。验证状态栏出现Face swapper model loaded successfully实时帧率会降但管线跑通。提示 Model not foundinswapper_128 模型文件缺失现象状态栏提示Model not found in .../models或下载阶段打印Could not obtain the inswapper model。根因modules/processors/frame/face_swapper.py 的 pre_check 会自动下载inswapper_128.onnx或inswapper_128_fp16.onnx网络不通时下载静默失败models 目录保持为空pre_start 检查发现两个文件都不存在就抛出 Model not found。修复先确认目录内容ls -lh models/目录为空或文件被截断完整的inswapper_128.onnx应为 554253681 字节时按 models/instructions.txt 给出的下载地址手动取回文件放入models/两者存其一即可。验证重新启动后状态栏出现Face swapper model loaded successfully且加载日志指明实际使用的模型路径。Linux 报 Failed to load library libcudnn.socuDNN 未被预加载现象终端打印Failed to load library libcudnn.soCUDA 会话创建失败。这个坑我踩过绝大多数是启动方式造成的。根因run.py 启动时内置了一段 Linux 预加载逻辑用ctypes.CDLL把 venv 里nvidia/*/lib下的 cuDNN 等共享库提前加载进进程onnxruntime 的 CUDA 提供器 dlopen 时才能找到。绕过它直接python -m modules.core启动就会漏掉这一步。修复改回用入口脚本启动python run.py无界面场景也可以固定回退链把 modules/globals.py 中execution_providers一行的赋值改为execution_providers [CUDAExecutionProvider, CPUExecutionProvider]ONNX Runtime 按列表顺序执行第一个提供器跑不动的算子自动落到下一个GPU 链路失效时模型依然能加载。验证加载不再失败CUDA 确实不可用时所有子图落在 CPU 执行性能等同纯 CPU。环境基线核查上面三个分支之外还有几项读者自己不容易意识到的环境约束逐项打勾✅ Python 版本 → 不低于 3.11README 推荐 3.14python --version检查 → 不满足时用匹配版本重建 venv✅ onnxruntime 变体版本 → 非 macOS 锁定onnxruntime-gpu1.26.0macOS arm64 为onnxruntime1.28.0见 requirements.txt → 执行pip install -r requirements.txt✅ CUDA 与驱动 →nvidia-smi可见显卡且为 CUDA 12.x → 改用 cpu 提供器或修复驱动✅ models/ 目录权限 → 存在且可写首次启动自动创建无权限会打印Failed to create directory→ 换有权限的用户运行✅ insightface 检测包 →~/.insightface/models/buffalo_l/下 5 个 onnx 文件齐全缺了会自动下载 → 网络不通时手动补齐✅ 磁盘剩余空间 → models 目录所在分区 ≥5GB → 清理磁盘或换到空间充足的盘✅ 可用执行提供器 →onnxruntime.get_available_providers()返回非空且包含想用的提供器 → 重装对应变体✅ 显存与内存 →nvidia-smi/free -h有余量 → 关闭占用 GPU 的其他进程跑通之后的调优与边界能加载成功之后下面几个点决定体验好坏。FP16/FP32 自动选择。get_face_swapper() 在 torch 能感知 CUDA 且 fp16 文件存在时自动选 FP16显存带宽减半否则回退 FP32。注意 16xx 系显卡GTX 1650/1660/1660 Ti 等没有 Tensor CoreFP16 推理会出 NaN把models/里的inswapper_128_fp16.onnx移走即可强制走 FP32。批处理大小。modules/processors/frame/core.py 按帧数与线程数自动推导 batch_size没有手工参数。视频处理内存吃紧时调低--execution-threads与--max-memory就能间接缩小批次。模型完整性校验。怀疑模型损坏或下载截断时直接校验文件python -c import onnx; onnx.checker.check_model(onnx.load(models/inswapper_128.onnx)); print(OK)日志级别。modules.globals.log_level 默认是 error切到 debug 后处理帧时 ffmpeg 相关输出会变啰嗦适合排查帧读取和编码环节的问题排完记得切回去。如果以上都没命中把完整控制台输出和onnxruntime.get_available_providers()的返回值一起收集去项目官方 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），仅供参考