内网拉不动模型FaceFusion 模型下载与离线部署三步跑通【免费下载链接】facefusionIndustry leading face manipulation platform项目地址: https://gitcode.com/GitHub_Trending/fa/facefusion第一次跑 FaceFusion下载进度条卡了十分钟报连接超时第二天再跑又弹出validating hash for scrfd_2.5g.onnx failed。模型文件下到一半被掐断、哈希对不上、内网环境干脆连 GitHub 都够不着——这些是 FaceFusion 模型下载环节最常见的三种翻车现场。好消息是它的下载链路设计得比想象中厚道断点续传、多源切换、CRC32 校验全部内置你只需要知道在哪一层介入。最小可跑一条命令拉齐模型先确认三个前置条件缺一个都会在pre_check阶段直接退出退出码 2Python 3.10 及以上系统 PATH 里能找到curl、ffmpeg、ffprobe然后执行这一条把全部处理器需要的模型拉齐# 强制下载全量模型完成后自动退出 python facefusion.py force-download --download-scope full怎么判断跑对了日志里逐个刷出validating hash for xxx succeeded和validating source for xxx.onnx succeeded进程以退出码 0 结束项目根目录下会多出一个.assets/models/目录里面每个.onnx旁边都躺着一个同名.hash文件。如果只是想验证机器现在能不能跑用默认参数再跑一遍就够了。文件齐了的话它只做本地校验几秒钟内退出码 0缺什么就补下什么。模型都放在哪.assets/models 与双文件机制FaceFusion 的每个模型都是双文件模型本体加一个同目录的.hash文件。校验用的是 CRC32hash_helper.py里就是zlib.crc32不是 SHA256.hash文件里存的就是这 8 位十六进制值。记住这一点后面排查哈希失败会省很多弯路。下载链路是一条标准的配置→执行→校验链选源按--download-providers的先后顺序遍历 provider对每个候选地址先curl -I探活第一个能通的生效下载底层是系统 curl带--continue-at -断点续传、--retry 5、--connect-timeout 5进度条按远程Content-Length计算校验.hash文件缺失会先补下然后逐个比对 CRC32对不上的模型会被自动删除并打deleting corrupt source日志下次运行重新拉。两个内置 provider 的差异值得看一眼Provider默认顺序下载地址备注github第一优先github.com/facefusion/facefusion-assets 的 releases官方发布包huggingface第二优先huggingface.co内置 hf-mirror.com 兜底国内网络经常直接命中镜像上面这张是它的 Web 界面python facefusion.py run启动右侧栏可以逐处理器查看模型状态和命令行走的是同一套下载逻辑。网络不稳换源与断点续传适用条件能连外网但连 GitHub 时快时慢、动辄超时。先换源把 huggingface 提到第一位它带 hf-mirror.com 兜底国内环境命中率明显更高# 指定下载源顺序先试 huggingface失败再落回 github python facefusion.py force-download --download-scope full --download-providers huggingface github断点续传不用你手动处理——下载命令本身就带--continue-at -上次下到 60% 的.onnx重跑会从 60% 继续不会从头来。想确认某个文件是否完整直接比体积即可本地大小小于远程Content-Length就会被判定待下载。如果公司网络必须走代理设置环境变量后再执行就行curl 会自动识别# 代理环境下载 export https_proxyhttp://your-proxy:port python facefusion.py force-download --download-scope full只跑最小集lite scope 快速启动适用条件机器磁盘紧张或只想先跑通 face_swapper 这类主力功能不想把全量模型full 范围下包含 deep_swapper 的全部人物模型体积非常可观一次性灌进来。--download-scope只有两个合法值默认是lite范围拉取内容体积量级适用场景lite每个处理器保留的轻量模型子集几百 MB日常开发、先跑通流程full所有处理器的全部模型数 GB生产部署、离线打包# 默认即 lite显式写出便于和 full 区分 python facefusion.py force-download --download-scope lite预期结果.assets/models/里只出现 lite 子集的模型退出码 0。之后如果切到某个 full 范围才支持的模型运行run/headless-run时对应模块的pre_check会按需触发补下载——按需拉取是逐模型生效的不会因为当初选了 lite 就卡死你。完全离线内网部署三步走适用条件目标机器完全无法访问外网。核心思路是联网机拉齐 拷贝.assets/models 离机机本地校验。联网机拉齐并打包# 联网机拉全量后把模型目录压成 tar 包 python facefusion.py force-download --download-scope full tar -czf facefusion-models.tar.gz .assets/models拷入内网机并解压把 tar 包随代码一起传到内网机器解压到仓库根目录下模型必须落在.assets/models/路径写死在代码里# 内网机解压到 FaceFusion 仓库根目录 tar -xzf facefusion-models.tar.gz -C /path/to/facefusion/离线校验这是最容易忽略的一步。在内网机上再跑一次 force-download——由于所有文件已就位且校验通过它不会发起任何真实下载本质上是一次纯本地 CRC32 体检# 内网机退出码 0 即部署完成 python facefusion.py force-download --download-scope full想看得更细这段脚本会逐个输出每个.onnx的校验结果FAIL 的重新从联网机拷一次对应文件即可import os from facefusion.hash_helper import validate_hash # CRC32 校验缺 .hash 文件返回 False models_dir .assets/models for name in sorted(os.listdir(models_dir)): if name.endswith(.onnx): print(name, OK if validate_hash(os.path.join(models_dir, name)) else FAIL)高频坑点现象日志刷validating hash for xxx failed/validating source for xxx.onnx failed根因模型文件下载中断或损坏CRC32 与.hash内容对不上。解法不用手动删——conditional_download_sources会把校验失败的源文件自动清掉重跑一次 force-download 让它重新拉即可。想手动干预的话⚠️ 以下命令会删除模型文件请确认路径无误再执行# 删除损坏文件后重跑触发重新下载 rm .assets/models/scrfd_2.5g.onnx python facefusion.py force-download --download-scope full现象下载瞬间失败日志里一条downloading进度条都没出现根因所有 provider 探活curl -I都没通过resolve_download_url返回空直接跳过。解法先单独确认连通性再决定换源还是上代理# 逐个探活看哪个源能通 curl -I https://huggingface.co -m 5 curl -I https://hf-mirror.com -m 5现象启动即退出日志提示dependency not installed根因curl、ffmpeg、ffprobe三者之一不在 PATH 里pre_check 直接拦截。解法装齐三个依赖即可force-download本身不依赖 GPU 和显卡驱动CPU 环境就能把模型拉完。现象明明体积看着够校验还是 FAIL根因.hash文件和.onnx不是同一批下载的比如只拷了模型没拷 hash或 hash 是旧版本。解法.hash与模型必须成对替换二者的版本要一致只拷其中一个等于没拷。生产环境备忘模型来源只用官方 provider.onnx与.hash成对校验后再上线离线包.assets/models的 tar 包按 FaceFusion 版本号归档升级时整包替换磁盘预算按 full 范围估算deep_swapper 全量模型是体积大头部署账号对.assets/有写权限自动清理损坏文件需要删文件定期跑一次 force-download 做本地完整性体检退出码 0 即通过到这里下载链路的两层保障你已经摸清了provider 顺序管从哪拉CRC32 管拉得对不对。剩下的活交给它自动补人只负责判断。下一步建议翻一下facefusion/download.py里resolve_download_url的探活与回退逻辑十几行就能看懂。【免费下载链接】facefusionIndustry leading face manipulation platform项目地址: https://gitcode.com/GitHub_Trending/fa/facefusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/4 19:06:42 · 阅读 1.2k 内网拉不动模型？FaceFusion 模型下载与离线部署三步跑通
内网拉不动模型FaceFusion 模型下载与离线部署三步跑通【免费下载链接】facefusionIndustry leading face manipulation platform项目地址: https://gitcode.com/GitHub_Trending/fa/facefusion第一次跑 FaceFusion下载进度条卡了十分钟报连接超时第二天再跑又弹出validating hash for scrfd_2.5g.onnx failed。模型文件下到一半被掐断、哈希对不上、内网环境干脆连 GitHub 都够不着——这些是 FaceFusion 模型下载环节最常见的三种翻车现场。好消息是它的下载链路设计得比想象中厚道断点续传、多源切换、CRC32 校验全部内置你只需要知道在哪一层介入。最小可跑一条命令拉齐模型先确认三个前置条件缺一个都会在pre_check阶段直接退出退出码 2Python 3.10 及以上系统 PATH 里能找到curl、ffmpeg、ffprobe然后执行这一条把全部处理器需要的模型拉齐# 强制下载全量模型完成后自动退出 python facefusion.py force-download --download-scope full怎么判断跑对了日志里逐个刷出validating hash for xxx succeeded和validating source for xxx.onnx succeeded进程以退出码 0 结束项目根目录下会多出一个.assets/models/目录里面每个.onnx旁边都躺着一个同名.hash文件。如果只是想验证机器现在能不能跑用默认参数再跑一遍就够了。文件齐了的话它只做本地校验几秒钟内退出码 0缺什么就补下什么。模型都放在哪.assets/models 与双文件机制FaceFusion 的每个模型都是双文件模型本体加一个同目录的.hash文件。校验用的是 CRC32hash_helper.py里就是zlib.crc32不是 SHA256.hash文件里存的就是这 8 位十六进制值。记住这一点后面排查哈希失败会省很多弯路。下载链路是一条标准的配置→执行→校验链选源按--download-providers的先后顺序遍历 provider对每个候选地址先curl -I探活第一个能通的生效下载底层是系统 curl带--continue-at -断点续传、--retry 5、--connect-timeout 5进度条按远程Content-Length计算校验.hash文件缺失会先补下然后逐个比对 CRC32对不上的模型会被自动删除并打deleting corrupt source日志下次运行重新拉。两个内置 provider 的差异值得看一眼Provider默认顺序下载地址备注github第一优先github.com/facefusion/facefusion-assets 的 releases官方发布包huggingface第二优先huggingface.co内置 hf-mirror.com 兜底国内网络经常直接命中镜像上面这张是它的 Web 界面python facefusion.py run启动右侧栏可以逐处理器查看模型状态和命令行走的是同一套下载逻辑。网络不稳换源与断点续传适用条件能连外网但连 GitHub 时快时慢、动辄超时。先换源把 huggingface 提到第一位它带 hf-mirror.com 兜底国内环境命中率明显更高# 指定下载源顺序先试 huggingface失败再落回 github python facefusion.py force-download --download-scope full --download-providers huggingface github断点续传不用你手动处理——下载命令本身就带--continue-at -上次下到 60% 的.onnx重跑会从 60% 继续不会从头来。想确认某个文件是否完整直接比体积即可本地大小小于远程Content-Length就会被判定待下载。如果公司网络必须走代理设置环境变量后再执行就行curl 会自动识别# 代理环境下载 export https_proxyhttp://your-proxy:port python facefusion.py force-download --download-scope full只跑最小集lite scope 快速启动适用条件机器磁盘紧张或只想先跑通 face_swapper 这类主力功能不想把全量模型full 范围下包含 deep_swapper 的全部人物模型体积非常可观一次性灌进来。--download-scope只有两个合法值默认是lite范围拉取内容体积量级适用场景lite每个处理器保留的轻量模型子集几百 MB日常开发、先跑通流程full所有处理器的全部模型数 GB生产部署、离线打包# 默认即 lite显式写出便于和 full 区分 python facefusion.py force-download --download-scope lite预期结果.assets/models/里只出现 lite 子集的模型退出码 0。之后如果切到某个 full 范围才支持的模型运行run/headless-run时对应模块的pre_check会按需触发补下载——按需拉取是逐模型生效的不会因为当初选了 lite 就卡死你。完全离线内网部署三步走适用条件目标机器完全无法访问外网。核心思路是联网机拉齐 拷贝.assets/models 离机机本地校验。联网机拉齐并打包# 联网机拉全量后把模型目录压成 tar 包 python facefusion.py force-download --download-scope full tar -czf facefusion-models.tar.gz .assets/models拷入内网机并解压把 tar 包随代码一起传到内网机器解压到仓库根目录下模型必须落在.assets/models/路径写死在代码里# 内网机解压到 FaceFusion 仓库根目录 tar -xzf facefusion-models.tar.gz -C /path/to/facefusion/离线校验这是最容易忽略的一步。在内网机上再跑一次 force-download——由于所有文件已就位且校验通过它不会发起任何真实下载本质上是一次纯本地 CRC32 体检# 内网机退出码 0 即部署完成 python facefusion.py force-download --download-scope full想看得更细这段脚本会逐个输出每个.onnx的校验结果FAIL 的重新从联网机拷一次对应文件即可import os from facefusion.hash_helper import validate_hash # CRC32 校验缺 .hash 文件返回 False models_dir .assets/models for name in sorted(os.listdir(models_dir)): if name.endswith(.onnx): print(name, OK if validate_hash(os.path.join(models_dir, name)) else FAIL)高频坑点现象日志刷validating hash for xxx failed/validating source for xxx.onnx failed根因模型文件下载中断或损坏CRC32 与.hash内容对不上。解法不用手动删——conditional_download_sources会把校验失败的源文件自动清掉重跑一次 force-download 让它重新拉即可。想手动干预的话⚠️ 以下命令会删除模型文件请确认路径无误再执行# 删除损坏文件后重跑触发重新下载 rm .assets/models/scrfd_2.5g.onnx python facefusion.py force-download --download-scope full现象下载瞬间失败日志里一条downloading进度条都没出现根因所有 provider 探活curl -I都没通过resolve_download_url返回空直接跳过。解法先单独确认连通性再决定换源还是上代理# 逐个探活看哪个源能通 curl -I https://huggingface.co -m 5 curl -I https://hf-mirror.com -m 5现象启动即退出日志提示dependency not installed根因curl、ffmpeg、ffprobe三者之一不在 PATH 里pre_check 直接拦截。解法装齐三个依赖即可force-download本身不依赖 GPU 和显卡驱动CPU 环境就能把模型拉完。现象明明体积看着够校验还是 FAIL根因.hash文件和.onnx不是同一批下载的比如只拷了模型没拷 hash或 hash 是旧版本。解法.hash与模型必须成对替换二者的版本要一致只拷其中一个等于没拷。生产环境备忘模型来源只用官方 provider.onnx与.hash成对校验后再上线离线包.assets/models的 tar 包按 FaceFusion 版本号归档升级时整包替换磁盘预算按 full 范围估算deep_swapper 全量模型是体积大头部署账号对.assets/有写权限自动清理损坏文件需要删文件定期跑一次 force-download 做本地完整性体检退出码 0 即通过到这里下载链路的两层保障你已经摸清了provider 顺序管从哪拉CRC32 管拉得对不对。剩下的活交给它自动补人只负责判断。下一步建议翻一下facefusion/download.py里resolve_download_url的探活与回退逻辑十几行就能看懂。【免费下载链接】facefusionIndustry leading face manipulation platform项目地址: https://gitcode.com/GitHub_Trending/fa/facefusion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考