本地 PC 实时换脸：GPU、FPS、摄像头与隐私

结论: 实时换脸会在你自己的机器上，对摄像头的每一帧完整跑一遍检测、换脸、合成流程。帧率由最慢的那个环节决定，硬件加速决定它是否可用，而最吃 FPS 的设置通常是画质增强。

视频导出可以慢慢跑，实时预览不行。30 FPS 意味着每帧大约只有 33 毫秒，要在其中完成采集、找脸、换脸、必要时修复，并把画面显示出来。下面的一切都由这个约束推导而来。

1. 每一帧摄像头画面经历了什么

实时路径是一个循环，其中每个环节都有成本：

• 采集。按请求的分辨率和帧率从摄像头取一帧。
• 检测与分析。定位并描述该帧中的人脸，包括用于判断“谁是谁”的嵌入向量。
• 指派。把每张检测到的脸匹配到源脸——要么是所有人共用的默认源，要么是已映射身份中最接近的一个。
• 换脸。换脸模型按源—目标配对逐次执行，结果合成回该帧。
• 可选修复。如果画质增强开启且当前运行环境支持实时增强，则按人脸各跑一次修复。
• 显示。成品帧被编码，通过本地回环连接推送到应用窗口。

由此可以直接得出两点。第一，这条链路是按人脸而不是按帧计费的——画面里两个人，换脸和修复的工作量大致翻倍。第二，你看到的帧率由最慢的环节决定，所以如果瓶颈是增强，换一台更快的摄像头没有意义。

2. 摄像头采集：请求的参数与实际拿到的参数

Deep Face Cam 以 960×540、60 FPS、MJPG 打开摄像头，然后回读设备实际给出的参数。这个请求是刻意设计的：540p 是合理的实时工作分辨率，而在打开时就要求 MJPG 在 Windows 上尤其重要——摄像头停留在未压缩格式时，可能因带宽限制被压到每秒只有几帧。

在 Windows 上，应用会依次尝试 DirectShow、Media Foundation，最后是通用回退，因为这些后端枚举摄像头的顺序不同，也不是每台设备在每个后端下都表现一致。在 macOS 上使用 AVFoundation 加通用回退。

应用还会实测真实帧率，而不是相信驱动上报的值，因为该值在 DirectShow 下并不可靠——实际输出 60 FPS 的摄像头常常仍报告 30。想看实时数字，请在选项面板打开 Show FPS。

3. Execution provider：决定其余一切的设置

推理通过 ONNX Runtime 执行，所选的 execution provider 是影响实时性能的最大单一因素。后端在启动时检测可用项，并按以下顺序优先选择：

Provider	平台	说明
CUDA	Windows、NVIDIA GPU	NVIDIA 上性能最好，但对驱动、CUDA 和 cuDNN 的版本兼容性敏感。
ROCm	AMD 计算栈	存在时优先于 CoreML 和 DirectML。
CoreML	macOS、Apple 芯片	用于替代 PyTorch MPS；视模型切分情况可能跨 CPU、GPU 和神经引擎运行。
DirectML	Windows	对 NVIDIA、AMD 和 Intel 的 GPU 覆盖面广。
CPU	全平台	兼容性最好、速度最低。可用于导出，实时场景下最吃力。

Windows 的 CPU、DirectML 和 CUDA 版本来自不同的依赖集合，是分别打包的。也就是说，选对安装包本身就是这个决策的一部分，而不是事后能切换的开关。在 Apple 芯片上，应用还会把生成的 CoreML 缓存文件写入用户模型目录，因此某个模型的首次运行可能比后续更慢。

还要注意：实时人脸修复只有在运行环境使用 CUDA 或 DirectML 时才启用。在其他 provider 上，实时链路只跑换脸，而图片和视频导出仍可使用任意增强模型。详见GFPGAN 与 GPEN 对比。

4. 你的 FPS 到底花在哪了

实时预览太慢时，按下面的顺序排查。这个顺序综合了各项通常占用的时间和调整的难易程度。

因素	影响	先试什么
画质增强	最高。每张脸、每一帧都是一整轮修复。	关闭，或降到 256 的模型。
人脸数量	高。换脸和修复都按人脸执行。	调整构图，只让需要的人脸入镜。
Execution provider	高。纯 CPU 跑实时是最难的情况。	安装与你的 GPU 匹配的版本。
采集分辨率	中。影响检测和合成开销。	实时分辨率保持适中，它不是导出。
摄像头格式	中，且经常看不见。未压缩格式会先卡住设备本身。	用 Show FPS 确认实测采集帧率。
其他 GPU 负载	不定。游戏、编码器和浏览器会争抢同一块设备。	直播期间关闭其他重度占用 GPU 的程序。
温度限制	渐进式。笔记本在几分钟后会降频。	以持续帧率为准，而不是最初三十秒。

把帧率和延迟分开看。预览可以跑在舒适的帧率上，却依然感觉“慢半拍”，因为每一帧都要经过多个环节和缓冲。如果困扰你的是延迟，请减少单帧工作量，而不只是降分辨率。

帧预算、采集分辨率与该记录什么

实时首先是算术，其次才是调参。每帧预算由目标帧率固定下来，而采集、检测、指派、换脸、可选修复和显示全部必须塞进这个预算里。

目标帧率	每帧时间	留给检测、换脸和修复
15 FPS	66.7 ms	≈ 61 ms
24 FPS	41.7 ms	≈ 37 ms
30 FPS	33.3 ms	≈ 28 ms
60 FPS	16.7 ms	≈ 12 ms

第三列假设采集和显示约占 5 毫秒。这是一个假设，不是在你机器上的实测值——请把它当作问题的形状，而不是规格。

采集分辨率	每帧像素	相对 960 × 540 默认值
640 × 360	230,400	0.44×
960 × 540	518,400	1.00×
1280 × 720	921,600	1.78×
1920 × 1080	2,073,600	4.00×

检测和合成随帧内像素数增长，换脸和修复随人脸数量增长。所以提高采集分辨率和多加一个人，是两种不同性质的开销。

实测时该记录哪些字段

字段	为什么重要
操作系统与版本变体	CPU、DirectML 和 CUDA 是不同的 Windows 构建；macOS 按架构区分。
Execution provider	影响最大的单一因素，同时决定实时修复是否可用。
GPU 与驱动版本	CUDA 性能对驱动、CUDA 和 cuDNN 的兼容性很敏感。
采集分辨率	决定每帧的检测与合成开销。
上报帧率 vs 实测帧率	DirectShow 上，实际输出 60 FPS 的摄像头常常报告 30。
帧内人脸数	换脸和修复按人脸计费，人数会直接放大工作量。
增强档位	Off / GPEN-256 / GPEN-512 / GFPGAN 在设计上就有不同的单脸开销。
5 分钟后的持续帧率	笔记本会降频，开头三十秒不是真实数字。

5. 让实时结果真正能用

实时比文件渲染更不容忍失误，因为你没法回头修某一帧。质量的大部分取决于开始之前就定下来的东西：

• 源照片。清晰、光线均匀、接近正脸。规则与视频相同，但在实时中更关键。
• 光线。均匀的正面光胜过身后一扇明亮的窗户。逆光是实时换脸不断崩掉的最常见原因。
• 距离与构图。脸在画面里太小，会让检测可用的信息变少。
• 动作。快速转头和手从脸前划过是最容易失败的帧；在正式依赖这套设置前，请刻意测试这些动作。
• 镜像。预览可以水平翻转，这会影响你自己动作的自然感，但不影响输出的几何关系。

当镜头前不止一个人时，实时指派是持续进行的相似度判断，而不是预先分析好的映射，因此天然不如已映射的视频文件稳定。差异见多人换脸指南。

6. 本地预览是什么，不是什么

这一点值得直说，因为它是关于实时换脸工具最常见的错误假设。Deep Face Cam 在它自己的预览窗口里显示实时结果。它不会注册成系统级的虚拟摄像头设备，因此 Zoom、Discord、OBS 和浏览器都不会在摄像头列表里看到它。

如果你需要把输出送进其他应用，那条链路只能依靠单独的屏幕或窗口捕获软件，并连带承受画质、延迟和平台方面的全部限制。在你亲自验证那条具体链路之前，不要假设它可行；同时请记住，在会议或身份验证场景中把修改过的摄像头画面当作你真实的样貌呈现，正是负责任使用政策明确禁止的用途。

7. 隐私：哪些留在本地，哪些不是

“本地”和“离线”不是同一个说法，而这个区别在实时摄像头场景中最要紧。

• 核心处理在设备上。摄像头帧、换脸和预览由运行在你机器上的后端处理。
• 预览走回环连接。随附后端通过 127.0.0.1 的本地连接把处理后的帧送到应用窗口——这是你电脑内部的通道，不是上传。
• 模型只取一次，且需确认。大体积模型文件不随源码仓库分发，在你确认后下载到用户目录，并对照公开校验值验证。
• 仍存在网络使用。安装包、模型下载、文档链接和更新检查都会用到网络。
• 生成文件留在磁盘上。模型、输出、临时文件和设置位于按用户划分的应用数据目录中——这在会话结束后清理时值得知道。

对任何做出此类声明的工具，诚实的建议都是一样的：测试你实际要用的那个版本，完成首次模型下载，观察它的行为，再把它对准敏感素材。设计说明见隐私说明。

实时排错

现象	可能原因	检查什么
摄像头打不开	其他应用占用了设备，或后端不匹配。	关闭其他摄像头程序；Windows 上应用会依次回退 DirectShow、Media Foundation 和通用后端。
采集帧率极低	摄像头协商到了未压缩格式。	打开 Show FPS，与摄像头标称帧率对比。
实时下增强选项不可用	运行环境不是 CUDA 或 DirectML。	检查 provider；图片和视频导出仍可使用增强。
转头时脸丢失	检测跟不上大幅偏离正脸的角度。	改善光线和构图；正式使用前先测试动作幅度。
脸换到了错误的人身上	实时指派是逐帧的相似度判断。	减少入镜人数，或改用文件流程。
几分钟后 FPS 下降	温度导致降频。	以持续帧率衡量，而不是最初几秒。
首次运行明显更慢	模型加载，以及 Apple 芯片上的 CoreML 缓存生成。	先预热一次，再做测量。

常见问题

实时换脸需要 GPU 吗？

CPU 路径能跑通整条流程，但实时正是加速最关键的场景，因为每一帧的时间预算是固定的。Windows 因此提供了独立的 CPU、DirectML 和 CUDA 版本；Apple 芯片上使用 CoreML provider。

能在 Zoom、Discord 或 OBS 里当摄像头用吗？

不能直接用。应用把结果显示在自己的预览窗口里，不会注册成系统虚拟摄像头设备，所以其他程序不会把它列为摄像头输入。

为什么实时 FPS 低于摄像头标称帧率？

因为采集只是第一个环节。检测、指派、换脸、可选修复和显示都要挤进同一份帧预算，而最慢的那一步决定节奏。

实时应该用多大分辨率？

比导出低。应用默认按 960×540 采集，作为预览的工作点是合理的；把 4K 推进实时链路没有好处。

实时换脸会上传我的摄像头画面吗？

核心处理在你的机器上进行，预览通过本地回环连接传输。网络仍会用于经确认的模型下载和链接，因此请确认你所安装版本的实际行为。

两个人能同时用实时换脸吗？

可以，但指派是按每帧的相似度决定，而不是基于预先分析好的映射，因此比已映射的视频渲染更不稳定，建议当作预览使用。

相关文章

• GFPGAN 与 GPEN：该用哪种画质增强
• 多人视频换脸：本地一次替换多张脸
• 如何在 PC 或 Mac 上本地完成视频换脸
• PC 与 Mac 本地换脸软件
• 如何在本地给 GIF 换脸，不用上传
• Deep Face Cam 源码仓库
• 隐私说明