Deep-Live-Cam 源码配置思路：环境、模型与执行后端分开排查
配置 Deep-Live-Cam 时，最需要先确定的是正在配置哪套代码。官方最新发行标签是 2.8，发行标题为 Ultimate，但该标签固定提交中的公开 README 仍以 2.1.6 为主标题。发行说明中的 Ultimate 更新项目，不宜直接作为公开源码的依赖清单和功能保证。
本文围绕标签 2.8 对应的公开源码说明准备顺序。资源形式是固定提交源码归档，运行环境和需要另取的模型仍需配置。安装示例用于解释官方文档的入口，实际是否适用于自己的系统，需在对应环境检查；不要拿某个后端安装成功代替整个处理流程已经可用。
先建立能回溯的环境
官方手动安装说明列出 Python、pip、Git、FFmpeg，Windows 另列 Visual Studio 2022 运行库。Python 推荐版本是 3.14，文档写明的范围为 3.11 至 3.14。依赖安装时，应同时核对解释器版本、系统和所用包，而不是把"找不到安装包"直接解释成源码损坏。
在解压后的项目目录创建虚拟环境。Windows 的基础步骤可以写为：
powershell
python -m venv venv
venv\Scripts\activate
pip install -r requirements.txt固定 README 中的 Windows 激活路径存在多余空格，实际路径应为上面的形式。这个排版问题应当修正，不能把错误空格当成程序要求。Linux 使用 source venv/bin/activate 激活环境，再安装同一份依赖清单。
环境独立的意义，是让包版本与这个项目建立清楚的对应关系。系统上同时维护别的 Python 应用时，不宜为一次安装随意卸载其他项目依赖。后面需要调整推理后端，优先在当前虚拟环境中处理，保留其他项目的工作条件。
Apple Silicon 的官方步骤另列 python@3.14 与 python-tk@3.14。tkinter 关系到图形窗口，解释器安装成功与图形支持可用并不是同一项检查。多套 Python 并存时，安装依赖与运行项目要明确指向同一套解释器。
模型目录是第二道检查
手动安装说明列出的模型是 gfpgan-1024.onnx 与 inswapper_128_fp16.onnx，放置位置为项目 models 目录。源码、Python 包和模型分别负责不同部分；把压缩包解开，并不能据此判断推理条件齐备。
排查加载错误时，先确认文件是否真实存在、名称是否对应、是否放在预期目录。只看到一个 models 文件夹，无法证明其中包含程序需要的模型内容。同样，不要把一个下载页面或文件快捷方式当成模型本体。
README 还提示初次执行会下载约三百兆模型，这意味着首次启动的联网准备与后续处理不能混为一谈。在记录环境问题时，将"依赖尚未安装""模型尚未就位""程序启动后没有预览"分开描述，会比统称"打不开"更有帮助。
先确认基础入口，再切换后端
文档给出的 CPU 基础启动方式是：
bash
python run.py这可以作为理解主入口的起点，并不意味着 CPU 能满足所有实时任务。开始时先用自有短素材，确认图形界面、输入选择和输出保存的过程；再根据自己的设备处理加速，比同时改变模型、后端和输入素材更容易定位问题。
后端名称与硬件路径应对应：
- NVIDIA 使用 cuda，需要核对 CUDA、cuDNN 与推理包的对应关系。
- Apple Silicon 使用 coreml，先确认解释器与官方 macOS 依赖。
- Windows DirectML 使用 dml，依赖对应的推理包。
- Intel OpenVINO 使用 openvino，运行库与推理包需要按版本配对。
四条路径对应不同的环境准备，应按自己的设备选择相关说明。排查时保留所选后端的名称，方便将报错与具体运行库对应起来。
Apple Silicon 的启动示例是：
bash
python3.14 run.py --execution-provider coreml官方说明指出，macOS 的官方 onnxruntime 包提供 CoreML 后端；旧的 onnxruntime-silicon 分支可能遮蔽正确的包。遇到这种冲突，应按当前项目环境核对，不能因为旧教程安装过某个分支，就认定它仍是必需项。
NVIDIA 部分尤其不能混用两个来源。公开源码 README 列出的 CUDA 安装版本为 12.8.0，2.8 Ultimate 发行说明则提到更新的 NVIDIA 栈。安装前确认文档属于所用代码，避免把成品更新说明拼接成源码教程。OpenVINO 也有对应版本要求，单独更新其中一个包不能自动代表组合兼容。
切换后端前，可以先记录当前解释器、依赖安装结果和基础启动表现。若只在加速入口失败，这份记录能帮助区分后端问题与原有输入问题。不要一边更换推理包，一边更改源图片和目标视频，否则新结果难以对应到具体变化。
安装依赖的输出也应保留到首次运行结束。最后一条报错可能只是后续结果，前面真正失败的包名和版本更有定位价值。把完整错误原文与所用环境放在一起，后续重新创建虚拟环境时才能核对差别；仅保存一张最后几行的截图，可能遗漏实际失败位置。
用两个任务检查处理链路
图片或视频模式：运行程序，选源人脸图片，选目标图片或视频，点击 Start。README 说明输出在以目标视频命名的目录。检查时至少要区分"开始处理"和"找到结果"两个状态，不能按下按钮就结束验证。
摄像头模式：选源图片，选摄像头，点击 Live，等预览出现。文档提供十到三十秒的等待参考，设备上的实际耗时需要观察。切换人脸时重新选择源图片。若预览正常，随后再配置 OBS 等窗口采集工具，将本地结果接入自己的直播工作流。
排查时依次看环境、模型、输入、处理结果和采集环节。比如预览已经出现，但 OBS 中没有对应画面，就应先检查采集对象；程序还在报模型加载错误时，调整直播软件的采集设置并不能补齐模型。
错误信息按发生位置记录
窗口没有出现，先检查启动命令所用解释器以及 tkinter；模型加载失败，回到文件名和目录；基础流程可用、指定加速后失败，再检查后端所需运行库。需要求助时，记录系统、Python、所选后端、执行入口和原始报错，比只列显卡名称更能缩小范围。
Mouth Mask 与 Face Mapping 是功能层面的选项。前者保留原嘴部运动，后者面向多人对象的人脸对应。先确认基础结果，再逐项加入这些处理，可以看清每个选项改变的是什么。不要把换脸、变声和直接输出虚拟摄像头当作同一能力。
完整命令行参数表在 README 中标有 Unmaintained，本文不将其全部展开为当前可执行保证。代码许可与模型用途也应分别核对：公开代码采用 AGPL-3.0，README 对相关模型提示非商业研究用途。把依赖、素材和使用范围一并记录，后续迁移环境或继续做项目时才有完整依据。
下载与获取
资源为 2.8 标签固定提交源码及许可证，需要另行准备环境和模型。
百度网盘:https://pan.baidu.com/s/1zzv-EKl-04SEEa4FZOiz2g?pwd=lbb7 提取码:lbb7