做 AI 互动数字人加 WebRTC 音视频实战，最绕不开的一步就是装支持 GPU 的 PyTorch。数字人模块里的语音驱动、口型生成、人脸渲染和对话模型，绝大多数都要跑在 PyTorch 上；WebRTC 负责把实时画面和声音送到浏览器端，但真正的模型推理压力，仍然集中在 GPU。装完 GPU 版之后，很多人在验证阶段会直接卡住，最常见的就是 torch.cuda.is_available() 返回 False，或者 import torch 本身报错。

我自己的建议是：不要一开始就盯着“哪个命令能装上”，先把 PyTorch、NVIDIA 驱动、CUDA 三者之间的关系弄清楚。版本对不上，后面跑数字人工程时会出现各种奇怪问题，而且排查成本很高。这篇内容按“需求分析 -> 版本确认 -> 安装 -> 验证 -> 排错”的顺序讲，重点保证一件事：让 PyTorch 真正吃到 GPU，能用于后续数字人和 WebRTC 工程的联调。

1. 先搞清楚数字人项目里的 GPU 压力到底在哪

在装环境之前，先想一个问题：数字人工程里，GPU 到底负责干什么？很多人会以为 WebRTC 是音视频服务，装了 GPU 就能让画面更流畅，其实不是。PyTorch 的 GPU 版本主要服务于模型推理，和 WebRTC 的推流、拉流、媒体转发是两回事。

1.1 数字人 + WebRTC 链路中，GPU 更多花在模型推理上

一个典型的 AI 互动数字人后端大概长这样：浏览器或者客户端采集画面和声音，通过 WebRTC 推到服务端；服务端拿到音频后，可能需要调用语音识别、语音合成、对话模型、口型驱动等能力；最后把实时生成的画面和声音再通过 WebRTC 拉回浏览器。

这里面，WebRTC 只负责传输。真正消耗算力的是语音合成模型和数字人驱动模型。比如根据一段音频去生成口型、表情、头部姿态，这些操作最终都会变成 PyTorch 张量计算。如果你的数字人还要接大语言模型做实时对话，那又多了文本生成这一层。

在 CPU 上跑这些模型，不是完全不能跑，而是实时性很难保证。单次推理可能从几百毫秒到几秒不等。放在演示环境里勉强能看，一旦同时收到多个用户请求，CPU 会被立刻打满。

所以安装支持 GPU 的 PyTorch，目标不是让 WebRTC 更流畅，而是让数字人后端的模型推理更快、吞吐更高。理解了这一点，后面配置环境时就不会把注意力放偏。

1.2 NVIDIA 驱动、CUDA 和 PyTorch 三者是什么关系

这个问题是新手最容易糊涂的地方。我们平时说的“安装 CUDA”，有时候指的是安装 NVIDIA 驱动，有时候指的是安装 CUDA Toolkit，有时候又指安装 PyTorch 的 CUDA 版本。其实它们是三层不同的东西。

NVIDIA 驱动是操作系统和显卡之间的桥梁。没有驱动，系统认不到显卡，后面的 CUDA、PyTorch 都用不了。

CUDA 是 NVIDIA 提供的并行计算平台。PyTorch 官方发布的 GPU 版本，会在安装包里带上编译好的 CUDA runtime 相关库，所以我们不一定需要在系统里手动安装完整的 CUDA Toolkit。

PyTorch 是最上层。它调用 CUDA 提供的接口，把神经网络计算分发到 GPU 上执行。

打个比方：驱动是路，CUDA 是交规，PyTorch 是跑在路上的车。路太旧，新车跑不了；路太新而车没升级，那只是没有充分利用路况而已，好在 NVIDIA 驱动通常向后兼容。真正需要关注的，是驱动版本能不能支撑你选的 PyTorch 版本。

命令行输入 nvidia-smi 后，右上角会显示一个 CUDA Version 。这个版本不是指你机器里已经装好了对应 CUDA Toolkit，而是指当前驱动最高支持到哪个 CUDA 版本。如果你安装的 PyTorch 要求更高版本，装的时候不一定报错，但一旦把模型放到 GPU 上运行，就可能出现 CUDA driver version is insufficient 。

1.3 先按硬件和场景决定安装路径

开始安装前，先确认机器上到底有没有 NVIDIA 显卡。

在 Linux 或 Windows 终端中输入：

nvidia-smi

如果有完整的表格输出，能看到显卡型号、显存、驱动版本和右上角的 CUDA 版本，说明驱动是好的。如果提示找不到命令，先检查 NVIDIA 驱动有没有装好。

有 NVIDIA 显卡，再考虑装 GPU 版 PyTorch。如果没有 NVIDIA 显卡，比如是 Apple Silicon 的 Mac，PyTorch 可以使用 MPS 后端的苹果 GPU；如果只是学习，先用 CPU 版把流程跑通也没有问题，等正式训练或推理时再换 GPU 机器。

数字人项目如果上生产，我会更推荐使用容器。用官方 PyTorch 镜像配合 NVIDIA Container Toolkit，能减少很多本地环境冲突。但容器方案依赖已经存在的基础镜像，如果项目是第一次从零搭建，还是要先从本机的 Python 虚拟环境开始。

2. 安装前先收集版本信息，别看到命令就复制

很多安装失败，不是命令敲错了，而是安装前没有确认版本。比如驱动版本太低、Python 版本不对、conda 环境没激活，这些都会导致后面跑数字人工程时无法定位问题。

2.1 查看显卡、驱动和 Python 版本

打开终端，先执行下面几条命令：

nvidia-smi
python3 --version
python --version
where python        # Windows
which python        # Linux / macOS

nvidia-smi 输出里的 Driver Version 表示当前驱动版本， CUDA Version 表示驱动能支持的最高 CUDA 版本。

Python 版本要重点看。PyTorch 的官方安装页会标明支持哪些 Python 版本，如果项目用的是 Python 3.8、3.10 或 3.11，要保证你当前正在使用的 Python 和 conda 环境匹配。很多 Windows 上的坑，是系统里有多个 Python，终端敲 python 时用的不是虚拟环境里的解释器。

2.2 nvidia-smi 右上角的 CUDA Version 不是已安装版本

这里几乎每次都要强调一遍： nvidia-smi 右上角的 CUDA Version ，不代表你已经安装了 CUDA Toolkit。

比如你的驱动显示 CUDA Version 是 12.2，这说明当前驱动最高能支持到 CUDA 12.2。PyTorch 官方如果发布了基于 CUDA 12.1 或 12.2 的安装包，正常来说可以跑。但你不能因为这个数字是 12.2，就以为驱动已经帮你装好了 CUDA，也不需要额外配置了。

真正安装 PyTorch 时，PyTorch 会带入自身需要的 CUDA 相关库。我们需要保证的是：驱动能支持 PyTorch 对应的 CUDA 运行版本。

2.3 查看显卡算力，老显卡尤其要注意

NVIDIA 显卡除了看型号，还要关心 Compute Capability，也就是计算能力。不同架构的显卡，对 CUDA 版本的支持范围不一样。

太老的显卡，比如 GTX 10 系列，如果安装最新版 PyTorch，有可能出现：

CUDA error: no kernel image is available for execution on the device

这种情况不是没装好，而是新版本的 PyTorch 没有针对老架构生成可执行内核，或者驱动版本太新、显卡算力不支持。

可以先在 NVIDIA 官网查这张显卡的 Compute Capability，再决定 PyTorch 版本。如果查不到，最稳妥的办法是先用一个中等版本的 PyTorch 尝试，比如标题带 cu118 或 cu121 的安装包，不要一上来就装最新版本。

3. 在 Linux 上安装 GPU 版 PyTorch 的完整流程

Linux 服务端是数字人项目最常见的使用环境。下面这套流程不是让你无脑复制，而是先把每一步的目的讲清楚。具体命令里的版本号会随时间变化，最终要打开 PyTorch 官网的 Install 页面，选择你的系统、包管理器、CUDA 版本，拿到当时最新的安装命令。

3.1 创建独立的 Python 虚拟环境

数字人项目通常依赖特别多，有 PyTorch、OpenCV、音频处理库、WebRTC 封装库等。如果直接装在系统 Python 或者 conda 的 base 环境里，很容易产生依赖冲突。

推荐用 conda 创建独立环境：

conda create -n digital_human python=3.10 -y
conda activate digital_human

这里用 Python 3.10 只是示例。最终用哪个版本，要以你下载的数字人项目代码为准，很多项目会在 requirements.txt 或 README 里写明。

激活环境后，再确认一下当前 Python 路径：

which python
python --version

如果路径里面没有 digital_human ，说明 conda 环境没有正确激活，需要先检查 conda 本身的初始化配置。

3.2 使用官方 index-url 安装 PyTorch，而不是默认 pip install torch

PyTorch 官方推荐的安装方式是使用带有 index-url 的 pip 命令。这样能确保安装的是带 CUDA 支持的 wheel 包，而不是不包含 GPU 支持的版本。

下面是一条示例命令：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

注意 cu121 是示例，表示 CUDA 12.1。具体数字要按官网实际页面选择。如果你的机器驱动版本较新，可以选更新的 CUDA 版本；如果是老显卡，优先考虑 cu118 或更早的版本。

这条命令执行前，还需要确认两件事：

1. 是否已经把虚拟环境激活。
2. 显卡驱动是否能支撑这个 CUDA 版本。

安装过程中如果网络不稳定，可以给 pip 加长超时时间：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 --timeout 600

安装完成后，用 pip list 看一下版本：

pip list | grep torch

正常会显示 torch、torchvision、torchaudio 三个包。如果结果显示的版本不是带 +cu121 之类的后缀，有可能是从默认 PyPI 源安装了另一份，这会直接影响后续 GPU 验证结果。

3.3 安装数字人项目里其他依赖时的注意事项

PyTorch 装好后，再安装数字人项目的其他依赖。常用命令是：

pip install -r requirements.txt

但这里有一个很常见的坑：如果 requirements.txt 里也写了 torch ，后面安装可能会把刚装好的 GPU 版覆盖成默认版本。

建议在安装项目依赖前，先看一下需求文件里对 torch 的约束：

grep -i torch requirements.txt

如果文件里写了 torch>=2.0 或者 torch==2.1.2 ，在安装时很容易从 PyPI 重新拉取一份。更稳妥的做法是，在 requirements.txt 里固定让它读本地的已安装版本，或者把 torch 从需求列表里去掉，使用单独维护的 GPU 版本安装命令。

数字人项目里还会遇到一堆编译相关的基础库，比如 cmake、ninja、opencv-python。这些库本身不参与 PyTorch 的 GPU 计算，但它们可能在安装时依赖默认 Python 环境。如果安装某个库时报了编译器错误，先安装系统编译工具：

sudo apt update
sudo apt install build-essential cmake

CentOS 或 RHEL 类的系统则用 yum 安装对应的 gcc、g++、cmake。这部分环境和你的服务器发行版强相关，不要只在报错时改 PyTorch 版本，先确认为什么编译失败。

3.4 验证 PyTorch 是否能调用 GPU

安装完成后，用一段最小验证代码确认 GPU 可用：

python -c "import torch; print(torch.__version__); print(torch.cuda.is_available()); print(torch.version.cuda)"

如果返回：

2.3.1+cu121
True
12.1

说明当前环境的 PyTorch 是 GPU 版本，CUDA 运行时也能正常加载。如果第一行是纯版本号没有 +cu 后缀，说明安装的可能不是 GPU wheel。

想看到具体的显卡名称和计算能力，可以再执行：

python -c "import torch; print(torch.cuda.get_device_name(0)); print(torch.cuda.get_device_capability(0))"

这里我先强调一个经验：不要在验证时急着加载完整数字人模型。先用官方自带的 CUDA 检查代码确认环境，再加载模型，这样能把“环境问题”和“模型问题”分开。很多人一上来就加载一个 2GB 的权重文件，结果报错后分不清是显卡驱动问题，还是模型代码问题。

4. 在 Windows 上安装 PyTorch GPU，要注意这些差异

Windows 也是常见的数字人本地调试环境。大部分流程和 Linux 一样，但有几个点特别容易踩坑。

4.1 激活独立环境后再安装，避免 Python 混乱

Windows 上如果安装了多个 Python 环境，比如官网安装包、Anaconda、Miniconda 同时存在，终端里的 python 命令指向谁会直接影响安装结果。

创建并激活环境：

conda create -n digital_human python=3.10 -y
conda activate digital_human

然后检查：

where python
where nvidia-smi

where python 应该显示当前 conda 环境路径。 where nvidia-smi 应该能找到 NVIDIA 驱动自带的命令。如果找不到 nvidia-smi，检查驱动是否安装完整，或者 PATH 环境变量里是否包含 System32。

Windows 上还有个容易忽略的问题：安装路径中如果有中文、空格或特殊符号，可能导致 torch.hub 下载权重、本地模型加载失败。项目路径尽量保持简单，比如 D:\code\digital_human 。

4.2 官方命令下载慢，不要随意换成 CPU 镜像

PyTorch 的 GPU wheel 体积很大，动辄 1GB 以上。Windows 下如果直接使用官方地址下载很慢，可以开一个临时显存缓存目录，或者用支持断点续传的下载工具，但核心命令仍然要从官方页面拿。

这里特别注意：很多人会因为下载慢，把安装源换成国内 pip 镜像。问题是，某些镜像源同步的 may be CPU 版本，或者没有及时更新 GPU 版本。装完后 torch.cuda.is_available() 返回 False，你再回头排查，时间成本更高。

如果实在网络不稳定，更推荐的做法是第一次先用 conda 的集合安装包试试，或者找一个离你近的 PyTorch wheel 镜像源，但装完后必须执行我上面写的验证代码。

4.3 缺少 DLL 或编译库时，先看 VS Build Tools

Windows 上最常见的安装问题之一是：

ImportError: DLL load failed while importing torch

出现这个问题，不一定是 PyTorch 没装好。先检查三件事：

1. NVIDIA 驱动是否正常， nvidia-smi 是否能输出。
2. PyTorch 是从哪个源安装的，虚拟环境是否干净。
3. 系统是否有 C++ 运行库。

如果后面还要编译 WebRTC 客户端 SDK 或者数字人相关的 C++ 扩展，Python 环境需要和 Visual Studio Build Tools 配合。即使只是安装 PyTorch，也建议先装好 VC++ 运行库，不要等到报错时再一个个猜。

4.4 Windows 下不要所有项目都共用 base 环境

Windows 本机调试时，很多人习惯直接打开 Anaconda Prompt，在 base 环境里跑所有项目。这种方式在数字人项目里非常危险。

原因是数字人项目需要的依赖太多了。base 环境里可能已经有旧版 torch、旧版 numpy、旧版 opencv，安装新项目时 pip 会尝试升级或卸载已有包，最后可能导致系统里其他脚本也跑不了。

我一般会为每个数字人项目建一个独立 conda 环境，环境名和项目名保持一致。这样做的好处是把调试记录和环境污染隔离。后面如果遇到找不到原因的问题，直接删除环境重建，比重装驱动、卸载 Anaconda 快得多。

5. 装完不是结束，放回数字人和 WebRTC 工程里实测

环境验证通过后，不要急着欢呼。很多项目的模型代码里可能根本没有把数据放到 GPU 上，或者保存模型时把权重保存成了 CPU 版本，导致安装成功但模型仍然跑在 CPU 上。

5.1 数字人模型代码里需要显式指定设备

PyTorch 不会因为你安装了 GPU 版，就让所有模型自动运行在 GPU 上。代码里必须做两件事。

第一，指定设备：

import torch

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = model.to(device)

第二，推理时把输入数据也放到同一个设备上：

input_tensor = input_tensor.to(device)
output = model(input_tensor)

如果数字人项目里用的是现成框架，一般在配置文件里会有一个 device 或者 use_gpu 选项。直接改成 cuda ，再试运行。如果代码里到处写的是 .cpu() 或者没传 device ，即使 PyTorch 装的是 GPU 版，实际仍在使用 CPU。

5.2 加载旧权重时注意权重保存设备

很多数字人模型是直接提供 .pth 或者 .pt 权重文件的。如果作者保存权重时是在 CPU 上，加载到 GPU 时需要加 map_location ：

state_dict = torch.load(model_path, map_location="cuda")

如果不加，PyTorch 可能试图先按照保存时的设备加载，然后转换，有时候会报错，有时候又会隐式降级到 CPU。等你跑起来一看，发现模型计算仍然很慢，才意识到设备没有指定对。

我自己踩过的一个坑是：项目配置文件默认写 device="cpu" ，代码虽然支持 GPU，但优先读取配置文件。安装完 GPU 版 PyTorch 后以为会自动变快，实际一直跑在 CPU 上。所以装完环境后，一定要在项目日志里打印当前使用的设备，不要只看 nvidia-smi 的显存占用。

5.3 用最小推理测试看延迟和显存占用

数字人工程最关心的是实时性。在正式联调 WebRTC 之前，可以用最小模型跑一次完整推理，统计延迟和显存占用。

计时时不要忘了做 CUDA 同步：

import torch
import time

torch.cuda.synchronize()
start = time.perf_counter()

# 这里放模型推理

torch.cuda.synchronize()
elapsed = time.perf_counter() - start
print(f"inference time: {elapsed:.4f}s")

如果不加 torch.cuda.synchronize() ，PyTorch 的一些算子会异步执行，计时结果会偏小，看起来很快，实际上端到端并没有那么快。

显存占用的查看方法仍然是 nvidia-smi ：

nvidia-smi

或者循环查看：

nvidia-smi -l 2

在 Windows PowerShell 里也可以使用：

nvidia-smi --loop=2

观察显存变化时，要区分是模型加载占用的显存，还是推理过程中动态分配的中间张量。

5.4 数字人服务跑起来后，再和 WebRTC 做端到端验证

环境安装的最终验证，要看整个数字人服务能不能在 GPU 推理的情况下稳定跑通。建议按下面顺序做一次全链路测试。

先启动 WebRTC 信令服务和媒体服务，浏览器端能正常推流、拉流。不要在这个阶段加载模型，先确认音视频链路是通的。

再启动数字人模型服务，用测试音频跑一次离线推理，确认输出画面、音轨基本正常。此时主要看模型有没有报错，显存有没有超限。

最后把两边串起来：浏览器推流到服务端，服务端触发数字人推理，把结果回推给浏览器。这个过程中如果出现画面卡顿，先用时间戳判断卡在 WebRTC 传输，还是模型推理。

比较常见的现象是：模型推理占用 GPU 时，显卡驱动把其他任务阻塞了。如果发现视频卡顿，但模型服务本身没有报错，可以先降低推理的输入分辨率，或者把数字人前置流程改成队列模式，不要让每个请求都在 GPU 上并行猛冲。

6. 常见报错和排查顺序

GPU 版 PyTorch 安装过程中会遇到的问题，大多数有通用规律。下面列一个现象和优先检查点的对照表，比一句一句看报错快得多。

现象	优先检查点
nvidia-smi 无法运行	NVIDIA 驱动未安装或未正确加载
torch.cuda.is_available() 返回 False	torch 是否从官方 index-url 安装；驱动版本是否太低
import torch 时报 DLL 加载失败	VC++ 运行库、Python 位数、虚拟环境是否干净
报错 CUDA driver version is insufficient	显卡驱动版本低于 PyTorch 所需 CUDA 版本
报错 no kernel image is available	显卡太老，PyTorch 版本不支持当前显卡算力
加载权重时显存不足	模型太大 / 批处理数量太高 / 其他进程占用显存
程序正常运行，但模型速度没有明显提升	代码里没有把模型和输入放到 GPU 上

6.1 先确认 GPU 和驱动状态

排查顺序不要乱来。第一步永远先执行：

nvidia-smi

这一步能确认显卡看得见、驱动正常运行。如果这一步都不行，后面所有操作都不用继续。

nvidia-smi 正常后，再执行 PyTorch 检查：

import torch
print(torch.__version__)
print(torch.version.cuda)
print(torch.cuda.is_available())

这里有个细节： torch.version.cuda 返回的是 PyTorch 编译时使用的 CUDA 版本。如果这个值不是 None，说明当前 torch 包确实带有 CUDA 支持。如果它是 None，那基本可以断定安装的是 CPU 版本的 torch。

6.2 版本不匹配时的处理顺序

如果 PyTorch 能正常导入，但 torch.cuda.is_available() 返回 False，优先查看当前 PyTorch 是怎么装的。

python -m pip show torch

注意输出里的 Location 字段。如果显示的位置不在你当前 conda 环境里，说明 pip 实际安装到了其他 Python 环境。这种情况在多个 Python 并存时特别常见。

接下来对比驱动支持的 CUDA 版本和 PyTorch 要求的 CUDA 版本。驱动版本如果偏低，有两个选择：

1. 升级 NVIDIA 驱动到支持更高 CUDA 版本的版本。
2. 卸载当前 PyTorch，安装更早的 CUDA 版本对应的包。

不要同时进行。先做其中一个，再验证。

6.3 老显卡和新 PyTorch 不兼容时的解决方法

老显卡遇到 no kernel image is available for execution on the device 时，说明 PyTorch 的二进制里没有针对你显卡架构的算子。此时换 PyTorch 版本比换驱动更有效。

具体做法：

pip uninstall torch torchvision torchaudio -y
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

cu118 在老显卡上通常兼容度会好一些。如果还是不行，可以选择 CPU 版本先用起来，或者换一张架构更新的显卡。

这里要特别提醒：不要因为老显卡不兼容新版本，就去修改什么底层配置文件或者强行绕过检查。那样做很容易引入更多不稳定因素。数字人项目更需要稳定可复现的环境，而不是极限压榨一张老显卡。

6.4 环境乱到无法定位时，直接重建虚拟环境

如果尝试了各种办法，PyTorch 仍然时好时坏，最节省时间的方案并不是继续卸载安装，而是删除整个虚拟环境重新创建。

conda deactivate
conda env remove -n digital_human -y
conda create -n digital_human python=3.10 -y
conda activate digital_human

然后严格按照官网命令安装 PyTorch，再安装项目其他依赖。这样做虽然要重新下载一遍依赖，但比在乱掉的环境中一个个排查要稳得多。

6.5 不要把所有报错都推到 PyTorch 上

数字人工程里还经常出现一种情况：PyTorch 明明验证通过，但项目启动后仍然报错。此时要看一下报错栈里具体是哪个模块。

比如 import cv2 失败，比如 WebRTC 相关扩展库找不到，这些和 PyTorch GPU 安装没有直接关系。先单独处理对应模块，不要一上来就把 PyTorch 卸载重装。

判断依据很简单：用最小验证脚本只 import torch，如果一切正常，那就说明 PyTorch 环境没有问题。问题出在数字人项目的其他依赖上。

7. 安装完成后的几个长期建议

到这里，GPU 版 PyTorch 已经能正常运作了，数字人项目也能把模型放到 GPU 上推理。下面再补充几条在真实项目里长期有用的经验。

7.1 把 GPU 环境检查写成一个脚本

推荐在项目里放一个 check_gpu.py 脚本，内容固定为：

import platform
import torch
import sys

print("python:", sys.version)
print("platform:", platform.platform())
print("torch:", torch.__version__)
print("cuda runtime:", torch.version.cuda)
print("cuda available:", torch.cuda.is_available())
if torch.cuda.is_available():
    print("gpu name:", torch.cuda.get_device_name(0))

以后每次项目部署或换机器时，先跑这个脚本。它能帮你快速确认环境是否满足要求，避免在项目主流程里被各种奇怪问题干扰。

7.2 多条 GPU 时用环境变量指定设备

服务器如果有多张显卡，PyTorch 默认使用的是 cuda:0 。但 cuda:0 不一定是你想用的卡，也不一定显存最大。

通过 nvidia-smi 先确认可用显存，再指定设备：

export CUDA_VISIBLE_DEVICES=1
python main.py

代码里也可以写：

device = torch.device("cuda:1")

注意，如果设置了 CUDA_VISIBLE_DEVICES=1 ，代码里实际看到的设备索引会被重新映射， cuda:1 可能就不存在了。所以更稳妥的做法是在代码里读取环境变量，而不是写死设备索引。

7.3 模型加载逻辑不要重复执行

数字人在线服务经常会使用 WebSocket 或者 HTTP 接口。如果把模型加载放到每次请求的处理函数里，相当于每个用户进来都会加载一次模型，显存很快就会耗尽。

更合适的方式是：启动服务时加载模型，保存在全局变量或单例对象里，请求只做 model inference。

_model = None

def get_model():
    global _model
    if _model is None:
        _model = load_model()
    return _model

很多数字人 WebRTC 服务是长连接模式，同一时间在线用户可能很多。重复加载模型会引发两个问题：一是显存不够，二是加载耗时导致请求超时。务必在项目初始阶段就把模型生命周期设计好。

7.4 端到端性能优化时，先分清瓶颈

GPU 安装完成后，如果数字人和 WebRTC 联调时机仍然卡顿，不要只盯着显卡利用率。瓶颈可能在 WebRTC 的编码、网络带宽、服务端媒体转发、模型推理队列，甚至可能是磁盘读取权重太慢。

排查顺序建议：

1. 看 GPU 利用率是不是接近 100%，如果是，考虑优化模型或降低分辨率。
2. 看 CPU 利用率是否被媒体处理打满，如果是，把媒体服务和 AI 推理服务拆开。
3. 看 WebRTC 推流端和拉流端的网络延迟，判断是网络问题还是服务端处理速度问题。
4. 看服务进程是否有明显的排队等待时间，比如多个用户同时点击时，请求是否串行。

有一次我遇到的情况是：GPU 利用率不高，画面还是卡。后来才发现是音频切片等待时间太长，模型一直没拿到足量的输入数据。所以不要只盯着 GPU 安装和显存，整个数据处理链路都要看。

7.5 版本升级和项目隔离

数字人项目依赖的大模型、人脸驱动、语音合成框架迭代很快，PyTorch 版本升级后，很多第三方扩展不一定能立刻适配。尤其是老权重文件、老服务框架，升级 PyTorch 后可能出现输出不一致或者算子兼容问题。

我的习惯是：项目建立时固定 PyTorch 大版本，并在 requirements-gpu.txt 里单独保存 GPU 安装命令。上线后除非有明确需求，否则不随便执行 pip install --upgrade torch 。

安装支持 GPU 的 PyTorch 只是数字人与 WebRTC 实战链路里的一小步。真正让项目稳定跑起来，还要靠环境规范、版本锁定和清晰的日志。以后遇到模型变慢、显存溢出、启动失败，先回到环境检查这一步，会省下很多排查时间。