在“AI互动数字人+WebRTC音视频实战”这个系列里，真正决定数字人交互体验的并不是只有 WebRTC 推流和拉流本身，而是媒体链路前后所依赖的人工智能模型。一个典型的本地数字人流程至少包含：音频采集、语音识别、对话生成、语音合成、口型或表情驱动，最后才是把渲染好的画面和声音通过 WebRTC 送到浏览器端。在这些环节中，语音识别、对话模型、TTS 合成等绝大多数模型都跑在 PyTorch 上。想让用户说完一句话之后，几百毫秒内就能看到数字人开口回应，就必须让 PyTorch 使用 GPU 计算，而不是靠 CPU 慢慢推理。
这一章完成的是整个数字人项目的计算基础：安装支持 GPU 的 PyTorch。安装本身不复杂，复杂的是很多人在这一步踩过同一个坑——明明 nvidia-smi 能看到显卡，程序里torch.cuda.is_available() 却返回 False。原因通常不在 PyTorch，而在驱动、CUDA 运行时、wheel 版本、Python 环境这几层之间的关系没有理清。下面按实际排查链路，把“驱动确认 -> 环境创建 -> PyTorch 安装 -> 四步验证 -> 常见故障 -> 项目落地建议”完整走一遍。
1. 先理解数字人链路为什么绕不开 GPU 版 PyTorch
1.1 数字人的模型推理与 WebRTC 媒体流是前后端关系
在 WebRTC 音视频架构里，数字人通常表现为一路经过模型处理后生成的媒体流。浏览器采集用户声音，通过 WebRTC 推到服务端或另一个端侧；服务端拿到音频后交给 ASR 模型转写文字，再交给对话模型生成回复，接着由 TTS 模型合成语音；如果还有数字人视频形象，还需要驱动音频到口型、表情甚至肢体动作。这些环节完成后，生成结果被编码成媒体流，再通过 WebRTC 推给用户。
PyTorch 在这条链路中承担的是“模型推理”的角色。它不直接负责推流和拉流，但 ASR、TTS、数字人渲染前的视觉模型，几乎都以 PyTorch 格式发布权重、以 PyTorch 定义网络结构。WebRTC 网关保证的是音视频能低延迟传输，而模型推理保证的是音视频的内容能实时被生成。任何一环拖慢，整个对话都会变得不可用。
1.2 延迟预算决定了没有 GPU 很难做实时互动
实时对话通常有一个模糊的延迟预期：用户说完一句话，数字人在 1 秒以内开始有回应，体验才接近真人对话。CPU 推理在小模型上或许还能接受，但数字人链路里的语音合成或口型驱动模型参数往往在千万到数十亿级别，CPU 完成一个句子的合成可能耗费数秒到十几秒。这个延迟放在 WebRTC 场景里，用户会明显感觉对话“断掉了”。
GPU 提供的是大规模并行计算能力。对于 TTS、声学特征提取、注意力机制这类矩阵密集计算，NVIDIA 显卡配合 CUDA 能获得数量级上的提升。更关键的是，服务端如果同时服务多个用户，GPU 还能通过批处理提高吞吐。也就是说，GPU 版 PyTorch 不只是“快一点”，而是决定这套数字人架构能否支撑实时互动的最底层前提。
1.3 驱动、CUDA 运行时、PyTorch wheel 的关系要先分清
安装前必须把一个概念理清：NVIDIA 驱动、CUDA Toolkit、PyTorch GPU wheel 是三层不同的东西。
NVIDIA 驱动是系统底层组件，负责让操作系统识别显卡，并通过 CUDA 用户态接口提供 GPU 计算能力。CUDA Toolkit 是一套开发工具，里面包含编译器 nvcc、调试工具以及各种 CUDA 库，完整安装体积很大。PyTorch 官方发布带 CUDA 支持的 wheel 包时，已经像“打包依赖”一样把运行所需的 CUDA 运行时库、cuDNN、cuBLAS 等库打进 torch 包内。
因此，大多数用 PyTorch 做推理和训练的开发者，不需要手动安装完整 CUDA Toolkit。只要 NVIDIA 驱动的版本足够新，能够支持对应 CUDA 运行时，再安装一个带 cu 标识的 PyTorch wheel 即可。理解这点后，很多“要不要先装 CUDA”的纠结会自然消失：先确认驱动是否支持目标 CUDA 版本，然后直接安装匹配的 PyTorch wheel。
2. 环境准备：先把 NVIDIA 驱动和 GPU 实况确认清楚
2.1 用一条命令确认 GPU 是否可用
不管你是本机 Linux、Windows、WSL2，还是云 GPU 实例，第一步都是执行 nvidia-smi：
nvidia-smi正常情况下会输出类似下面的信息：
+-----------------------------------------------------------------------------+ | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 NVIDIA GeForce RTX 4070 Off | 00000000:01:00.0 On | N/A | | 30% 52C P0 35W / 200W | 1024MiB / 12288MiB | 0% Default | +-------------------------------+----------------------+----------------------+重点看三处：显卡型号、Driver Version、右上角的 CUDA Version。这里有一个容易被误解的地方——右上角显示的 CUDA Version 并不是你机器里已经装了 CUDA Toolkit，而是当前驱动最高能支持的 CUDA 版本。比如驱动 535 通常最高支持 CUDA 12.2，意思是任何要求 CUDA 12.1 及以下的运行时都能跑，但要求 CUDA 12.4 的 PyTorch wheel 可能因为驱动过旧而无法运行。
| 常见环境 | 是否需要手动装驱动 | 验证方法 | 注意事项 |
|---|---|---|---|
| 本机 Linux（Ubuntu 等） | 多数需要 | nvidia-smi | 优先使用官方驱动或发行版软件源驱动 |
| 本机 Windows | 需要 | 命令提示符执行 nvidia-smi | 安装后若提示命令不存在，需配置 PATH 或到驱动目录执行 |
| WSL2 | 不需要在 Linux 内装驱动 | WSL 内执行 nvidia-smi | Windows 宿主安装驱动即可，WSL 共享使用 |
| 云 GPU 实例 | 通常预装 | nvidia-smi | 重点确认版本是否满足后续 PyTorch 要求 |
| 普通虚拟机 | 视 GPU 直通能力而定 | nvidia-smi | 若未直通 GPU，可能显示无设备，不建议跑模型推理 |
如果是本机 Linux 且 nvidia-smi 没有输出，先确认显卡是否被系统识别：
lspci | grep -i nvidia如果能看到 NVIDIA 设备但 nvidia-smi 不存在，说明驱动没有安装。Ubuntu 上比较常见的安装方式是：
sudo apt update ubuntu-drivers devices sudo ubuntu-drivers install sudo reboot如果你使用的是 NVIDIA 官方 .run 安装包，则按官方文档执行，安装完成后重启并再次验证 nvidia-smi。
2.2 驱动版本与 PyTorch CUDA 变体的匹配原则
PyTorch 官网上提供的安装命令带有 cu118、cu121、cu124、cu126 等标识，这些数字代表 PyTorch wheel 内部捆绑的 CUDA 运行时版本。驱动与运行时必须满足一个方向性原则：驱动支持的最高 CUDA 版本必须大于或等于 wheel 捆绑的 CUDA 运行时版本。
| PyTorch 常见变体（示例） | 捆绑 CUDA 运行时 | Linux 驱动下限（参考） |
|---|---|---|
| cu118 | CUDA 11.8 | 520.61.05 |
| cu121 | CUDA 12.1 | 530.30.02 |
| cu124 | CUDA 12.4 | 550.54.14 |
| 更高变体 | cu126/cu128 等 | 以 NVIDIA 官方兼容矩阵为准 |
驱动可以向下兼容更低版本的 CUDA 运行时，但不能向上支持超过它自身能力的版本。比如驱动 535 支持到 CUDA 12.2，你安装 cu118 或 cu121 没有问题；但如果强行安装 cu124，运行时会因为驱动版本过低而报错，或直接出现 torch.cuda.is_available() 返回 False。因此，环境检查的第一步是记住自己驱动支持的 CUDA 能力上限，再据此选择 PyTorch 变体。
2.3 使用 conda 创建独立 Python 环境
GPU 版 PyTorch 安装会把大量 CUDA 相关库写入环境。如果直接装在系统 Python 或 conda base 环境里，后续安装数字人相关模型依赖时很容易出现版本冲突。推荐为整个项目创建一个独立环境。
如果你还没有 Anaconda 或 Miniconda，先安装 Miniconda，然后执行：
conda create -n digital_human python=3.10 -y conda activate digital_human python -V创建环境时指定 Python 版本有几个考虑点：
- PyTorch 会随着版本发布逐步扩大支持的 Python 范围。选择 3.10 或 3.11 对大多数模型仓库兼容性较好。
- 部分数字人开源项目依赖旧版包，Python 版本过高会导致某些依赖找不到对应 wheel。
- 不要使用 python 3.7 或更老版本，新版本 PyTorch 通常已经放弃支持。
创建完成后，建议顺手记录当前环境的路径和 Python 版本，之后所有模型依赖都安装在这个环境里。后续如果环境搞乱，直接删除重建即可，不用影响系统全局。
3. 用官方命令安装 GPU 版 PyTorch
3.1 到 PyTorch 官网生成当前匹配的安装命令
PyTorch 安装页面会根据操作系统、包管理器、CUDA 版本动态生成命令。因为 PyTorch 版本迭代很快，稳定的最佳做法是打开 PyTorch 官网的 Get Started 页面，选择自己的操作系统和 CUDA 版本，复制站内生成的命令，而不是凭记忆写一个旧命令。
在 Python 3.10 环境中，如果驱动支持 CUDA 12.4，典型的 pip 安装命令如下：
python -m pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu124注意这里使用的是 python -m pip，而不是裸 pip，这样能确保命令作用在当前激活的 digital_human 环境内。--index-url 参数让 pip 从 PyTorch 官方 CUDA wheel 索引下载，而不是从默认 PyPI 下载 CPU 版本。
安装完成后，先检查包版本：
pip list | grep torch如果看到形如 torch 2.x.x+cu124 的版本号，说明安装的是带 CUDA 的 wheel。如果版本号末尾没有 +cu 标识，很可能装成了 CPU 版。
3.2 torch、torchvision、torchaudio 分别解决什么问题
官方命令总是同时安装三个包，它们由 PyTorch 团队按同一套版本节奏发布。在数字人项目里，这三个包的用途并不相同：
- torch：核心框架，包含张量、自动求导、神经网络模块。数字人所有模型都基于它。
- torchaudio：音频读取、音频特征提取工具。ASR 前端、TTS 后处理通常依赖它做频谱、梅尔特征等变换。
- torchvision：视觉模型和数据集工具。如果数字人包含口型驱动、人脸关键点检测、视频生成等视觉模型，会需要它。
这三个包必须使用同一版本和同一 CUDA 变体，否则可能出现 ABI 不兼容。例如 torch 使用 2.3.1+cu124，torchvision 和 torchaudio 也要尽量使用对应版本 0.18.1 和 2.3.1 的 cu124 构建。
如果项目明确不使用 torchvision，为了减少体积可以只安装 torch 和 torchaudio。但要注意，很多模型仓库会在 import 阶段直接引入 torchvision，缺包会在运行时才暴露。保守做法是三个包一起安装。
3.3 conda 安装方案以及 pip 与 conda 的取舍
conda 用户也可以安装 GPU 版 PyTorch。当前官方给出的 conda 命令大致是：
conda install pytorch torchvision torchaudio pytorch-cuda=12.4 -c pytorch -c nvidia这条命令会从 pytorch 和 nvidia 两个 channel 分别拉取 PyTorch 本体与 CUDA 相关依赖包。conda 方案的优点是依赖解析更完整，遇到 cudnn、cublas 这类系统级库时不容易漏装；缺点是下载体积大，而且如果环境中混用了 pip 安装的包，后续可能产生两套 CUDA 库同时存在的混乱。
从项目落地角度，推荐优先使用 pip 官方 wheel 方案。原因很直接：安装命令短、版本标识明确、官方索引里的 wheel 自带 CUDA 运行库，最容易被验证脚本确认。conda 方案适合那些必须通过 conda 管理依赖、或需要较老 CUDA 库的特殊项目。
3.4 不同 CUDA 版本的迁移与锁定策略
不要盲目追求最新版本。项目用到的大模型仓库一般会在 README 或 requirements.txt 里声明测试过的 PyTorch 版本；某些 TTS 或数字人渲染仓库可能停留在 torch 2.0 或 2.1。盲目升级到最新 PyTorch 后，模型加载可能报算子不兼容或权重映射失败。
建议的做法是：
- 先看项目要求的 torch 主版本。
- 再看自己驱动支持的 CUDA 上限。
- 两者交叉后选择一个确定版本，例如 torch 2.3.1+cu124。
- 把版本写入文件，方便团队保持一致。
锁定依赖可以使用：
python -m pip install torch==2.3.1 torchvision==0.18.1 torchaudio==2.3.1 --index-url https://download.pytorch.org/whl/cu124需要注意的是，如果你把版本号和 +cu 后缀一起写在 requirements.txt，再用默认 PyPI 源安装，往往会因为找不到本地版本而报错。正确的做法是明确指定使用 PyTorch CUDA wheel 索引，或只锁定主版本号、依靠索引里的默认构建。
4. 安装后的四步验证：不是 import 不报错就结束
4.1 第一步：确认 wheel 版本里带 cu 标识
安装完成后，在项目环境里执行：
python -c "import torch; print(torch.__version__)"预期输出类似 2.3.1+cu124。这里的 +cu124 是判断 GPU 版是否装对的第一依据。
如果输出是 2.3.1、2.3.1+cpu 或 2.3.1+rocm，说明你装的不是目标 CUDA 变体。常见原因是当时没有使用 --index-url，或者 conda 环境没有激活，pip 落到了别的环境里。
4.2 第二步：验证 torch.cuda.is_available()
将下面的脚本保存为 gpu_check.py：
import torch print("PyTorch version:", torch.__version__) print("CUDA available:", torch.cuda.is_available()) if torch.cuda.is_available(): print("CUDA runtime version:", torch.version.cuda) print("cuDNN version:", torch.backends.cudnn.version()) print("GPU count:", torch.cuda.device_count()) for i in range(torch.cuda.device_count()): props = torch.cuda.get_device_properties(i) print(f"GPU {i}: {props.name}, {props.total_memory / 1024 ** 3:.1f} GB") else: print("CUDA is NOT available, check driver and wheel variant.")运行：
python gpu_check.py正常结果中，CUDA available 应为 True，并打印显卡名称和
