硬件与性能
本页说明 RVC Next 怎样选择计算设备和精度、怎样管理显存，以及影响速度和实时延迟的设置。
本页说明 RVC Next 怎样选择计算设备和精度、怎样管理显存，以及影响速度和实时延迟的设置。相关设置都在 compute 组（Web UI 的 设置 › 计算），完整列表见 配置与环境变量。
选择设备
compute.device（设置 › 计算 › 设备）可以是：
| 值 | 含义 |
|---|---|
auto（默认） | 按下面的 GPU 规则选择最合适的显卡（CUDA、ROCm 或 XPU）；都没有时尝试 DirectML，再不行用 CPU。auto 不会选择 MPS |
cpu | 只用 CPU |
cuda:N | 第 N 块 NVIDIA 显卡（从 0 开始），在 ROCm 版 torch 上则是第 N 块 AMD 显卡。GPU 规则会跳过的卡也照样使用（以 fp32 运行）；编号不存在时退回 CPU |
xpu:N | XPU 版 torch 上的第 N 块 Intel 显卡（Arc、数据中心 GPU、较新的核显）。退回规则与 cuda:N 相同 |
dml | DirectML（Windows 上的 AMD、Intel 等显卡）。不可用时退回 CPU |
mps | Apple Silicon 的 Metal（实验性）。不可用时退回 CPU |
GPU 规则
auto 沿用原版 RVC（configs/config.py）的规则，逐块检查 CUDA 显卡：
| 显卡 | 结果 |
|---|---|
| 显存不足 4 GiB，或计算能力低于 5.3 | 不使用 |
| 计算能力 6.1（Pascal，如 GTX 10 系列），或 GTX 16xx | 使用，fp32 |
| 计算能力高于 6.1（RTX 20 系列及更新） | 使用，fp16 |
| 其他（计算能力 5.3 到 6.1 之间） | 不使用 |
ROCm 上的 AMD 显卡（仍是 cuda:N）和 Intel XPU 显卡不看计算能力：显存至少 4 GiB 就使用；ROCm 显卡以 fp16 运行，XPU 显卡在设备报告支持 fp16 时以 fp16 运行。
有多块可用显卡时，选计算能力最高的，相同时选显存最大的。rvc-next doctor 和 设置 › 计算 下方的设备列表会列出每个设备、规则给出的精度和原因（例如 "Pascal SM 6.1 and GTX 16xx cards run in fp32"）。
精度
compute.precision（精度）：
auto：按 GPU 规则；fp32：始终用 fp32；fp16：在 CUDA、ROCm 和 XPU 上强制 fp16（包括规则判为 fp32 的显卡）。
DirectML、MPS 和 CPU 上始终是 fp32（DirectML 上的人声分离例外，见下）。fp16 更快、显存占用更少；如果某块卡在 fp16 下输出异常，改为 fp32。
精度还决定长音频的分块大小（与原版相同）：显存不超过 4 GiB 的 CUDA、ROCm 和 XPU 卡用最小的分块，fp16 用较大的分块，其他情况用中等分块。
安装对应的 PyTorch
设备是否可用取决于安装的 PyTorch：NVIDIA 显卡需要 CUDA 版的 torch，AMD 显卡需要 ROCm 版（AMD 自己发布，支持 Windows 和 Linux），Intel 显卡需要 XPU 版；只装了 CPU 版时 auto 会选 CPU。安装方法见 安装；rvc-next doctor 显示 torch 版本和它的构建目标（例如 CUDA 13.0、ROCm 10.0 或 XPU）。
CUDA Graph
CUDA Graph 把一次推理录制下来、之后直接重放，减少 CPU 调度开销，对实时变声的小块推理帮助最大：
| 设置 | 界面 | 默认值 |
|---|---|---|
compute.cuda_graph_offline | 转换时使用 CUDA Graph | 关 |
compute.cuda_graph_live | 实时转换使用 CUDA Graph | 开 |
只在 NVIDIA CUDA 上起作用：ROCm 和 XPU 上这两个开关不生效，推理以普通模式运行。录制按输入的形状缓存（每个调用点最多 8 个，环境变量 RVC_NEXT_CUDA_GRAPH_MAX_CACHE 可调），录制失败时自动退回普通模式。离线转换的输入长度各不相同，难以复用录制结果，所以默认关闭。
AMD ROCm 与 Intel XPU
- ROCm：torch 的 ROCm 版（Windows 和 Linux）把 AMD 显卡当作 CUDA 设备，所以它们显示为
cuda:N，CUDA 上能运行的功能都能在上面运行，CUDA Graph 除外。人声分离直接使用显卡。 - XPU：Intel 显卡显示为
xpu:N。转换、实时变声、训练（fp16 使用 AMP；多卡训练使用xccl后端）以及音高和特征提取都在上面运行。人声分离先在 CPU 上加载模型再移到显卡，并以 fp32 运行，因为 pymss 本身不支持 XPU。 - 多卡训练通过
CUDA_VISIBLE_DEVICES（ROCm 也读取它）或 XPU 上的ZE_AFFINITY_MASK选择显卡。训练 中的 GPU 编号指当前 torch 构建所提供的那一类设备。
DirectML
- 安装 DirectML 支持：
pip install "rvc-next[directml]"（安装torch-directml和onnxruntime-directml）。 - RMVPE 在 DirectML 上使用 ONNX 版本，需要资源
rmvpe-onnx：rvc-next assets download rmvpe-onnx。它不在all分组里，缺少时界面和命令行会提示下载。 - 人声分离在 DirectML 上默认以 fp16 运行，并使用较小的分块；如果 fp16 失败，任务会自动改用 fp32 重新运行一次（日志中有 "Retrying in fp32"）。
Apple Silicon（MPS）
把 compute.device 设为 mps 才会使用 Metal，auto 不会选它。MPS 上以 fp32 运行，属于实验性支持。
显存管理
模型缓存
服务器加载过的模型会留在内存（显存）里，下次使用时不必重新加载：HuBERT、各种音高算法的模型，以及最近使用的 3 个音色和它们的索引。实时变声在自己的工作进程里也保留一份。
顶栏的 显存 指示器显示已用/总显存和 已加载： 的模型列表（没有时显示 未加载任何模型）。
空闲卸载
compute.unload_after_minutes（空闲多少分钟后卸载模型（0：从不），默认 10）：服务器里的模型空闲超过这个时间后自动卸载。服务器每 30 秒检查一次。
释放显存
在顶栏 显存 菜单中点 释放显存，立即卸载所有缓存的模型，包括空闲的实时变声工作进程中的模型，并把显存还给驱动。
只有在没有任务排队或运行、实时变声也没有运行时才能释放；否则菜单项显示为 释放显存（请等待：有任务正在运行） 或 释放显存（请等待：实时变声正在运行），因为这些模型正在使用，释放后马上又要重新加载。
命令行没有单独的释放命令：每条命令结束时进程退出，显存随之释放。
显存不足
当推理或训练报告显存不足（CUDA 的 OutOfMemoryError，以及 MPS、DirectML 的相应错误）时：
- 任务失败，错误为 GPU 不可用或显存不足（
compute_unavailable，detail.reason为out_of_memory；命令行退出码 9）； - 服务器随即卸载所有没在使用的模型，让下一次从空的显存开始；实时变声的工作进程出错时先卸载自己的模型；
- 这样失败的任务不会自动重试，需要你在 任务 中点 重试。
减少显存占用的办法：
- 把 同时运行的 GPU 任务数 保持为 1；
- 转换或训练前先 释放显存，或停止实时变声；
- 训练时减小批大小（
train run --batch-size），关闭 将数据集缓存到显存； - 改用 fp16（如果显卡支持），或在显存很小的卡上改用 CPU。
GPU 任务排队
转换、分离和训练任务在 compute.device 不是 cpu 时属于 GPU 任务：
compute.gpu_jobs（同时运行的 GPU 任务数，默认 1，最大 16）限制同时运行的 GPU 任务数量，其余任务排队（状态 等待中，等待 GPU）。显存充足时可以调大。- 设备为
cpu时这些任务改为 CPU 任务，最多同时运行 CPU 核数的一半个。 - 实验的 GPU 设为
cpu时（新实验的默认值来自training.gpus），训练也作为 CPU 任务运行。 - 预览（只转换前几秒）的优先级高于普通转换。
实时变声优先
实时变声对延迟最敏感，所以它开始时（设备不是 cpu）会占用 GPU：
- 已经在运行的 GPU 任务继续运行；
- 新的 GPU 任务进入等待，任务卡片上出现 仍然运行，提示 实时转换正在使用 GPU。同时运行可能导致声音卡顿。 点它可以不等实时变声结束就开始；
- 实时变声停止后，等待的任务自动开始。
命令行（rvc-next convert 等）在自己的进程中运行任务，不参与正在运行的服务器的 GPU 排队。服务器正在实时变声时，在同一台电脑上用命令行跑 GPU 任务同样可能造成卡顿。
实时变声的延迟与块长
实时变声每次处理一个"块"的音频。估计延迟（实时页面和 live check 显示）按下式计算：
延迟 ≈ 块长 + 交叉淡化 + 10 ms（SOLA 搜索）
+ 块长（输出缓冲预先填入一块静音）
+ 块长（仅当输入输出是分离的两个流时）
+ 输入设备延迟 + 输出设备延迟
+ min(交叉淡化, 40 ms)（仅当开启输入降噪时）按默认的 块长 250 毫秒、交叉淡化 50 毫秒，单个双工流时约为 560 毫秒加上设备延迟。
这里的设备延迟是 PortAudio 报告的值，往往偏乐观（MME、DirectSound 和蓝牙设备尤其如此）。要得到真实数值，把输出接回输入，然后在实时页面使用 测量延迟，或运行 rvc-next live latency：它让测试噪声经过实时变声所用的同一组缓冲，通过互相关在输入中找到它们，再加上转换器自身的延迟。详见 测量真实延迟。
要让变声不断音，每块的推理时间必须明显短于块长。实时页面的 负载 条显示推理耗时（p95）与块长之比：
- 负载超过 80% 时进度条变红，并出现按钮 将块长增加到 {ms} 毫秒（建议值让负载回到约 70%，上限 1500 毫秒），点击即可调整；
- 出现 欠载、溢出 计数或爆音时，同样应增大块长；
- 运行中修改块长、交叉淡化、上下文会重新缓冲，不需要重新加载模型。
CPU 和 GPU 的差别主要体现在这里：在 GPU 上推理快，可以用较短的块长换取低延迟；在 CPU 上推理慢得多，通常需要更长的块长（延迟随之增加），pm 音高算法也比 RMVPE 快。上下文 越长效果越平滑，但每块的计算量也越大；降噪会增加一些耗时。
更多实时变声的使用说明见 实时变声。