AI人声分离实操：用Demucs和UVR提取干净伴奏与纯BEAT

很多人找《峠の恋人》的原版伴奏、纯BEAT、带和声版本，与其到处求文件，不如自己用 AI 人声分离工具把伴奏提取出来。这次我们来看一套可以完整跑通的人声分离方案：以本地部署为主，覆盖环境准备、模型选择、单曲分离、批量任务和效果验证，核心目的是拿到干净的伴奏、纯 BEAT，或者保留背景和声的版本。

整套方案围绕 Demucs 和 UVR 两款主流工具展开，它们都是目前社区里成熟度高、可免费使用的开源方案。Demucs 适合命令行和脚本化批量处理，UVR 则提供图形界面，方便手动调模型、看实时结果。对普通音乐制作、翻唱练习、混音拆轨来说，这两个工具基本够用了。文章会直接给出安装命令、分离命令、批量脚本和常见问题排查，并说明哪些场景适合、哪些场景不适合，以及版权边界必须注意在哪。

如果你是给视频做 BGM、做翻唱伴奏、练习混音，或者只是想把一首歌拆成人声和器乐，这篇文章可以直接收藏。整个流程不要求高性能显卡，CPU 也能跑，有 NVIDIA GPU 会更快。下面先从核心能力开始。

1. 核心能力速览

这套方案解决的核心问题很直接：当你没有官方伴奏、没有纯 BEAT 文件时，可以用 AI 把一首歌里的人和乐器分开。分离结果不是绝对无损，但在大多数非商用场景下，听感已经足够干净。

2. 适用场景与使用边界

这类工具的适用人群很明确。

• 音乐制作人：需要一段干净伴奏做 remix 或编曲练习。
• 翻唱作者：不想用有版权的伴奏，尝试从原曲提取参考。
• 混音学习者：想把歌曲拆成人声、鼓、贝斯、其他，分析混音层次。
• 视频创作者：需要一段没有人声的纯 BEAT 作为背景底噪。
• 音频工具链开发者：想把人声分离能力集成到批量任务脚本中。

它解决的是“没有官方分轨时，如何获得相对干净的分离素材”这一痛点。分离出来的伴奏和 BEAT 精度受原始音质、模型选择、参数设置影响较大，不能保证达到母带级质量，但足以支撑试听、练习和参考。

同时必须明确使用边界。

• 不建议把分离结果用于商业发行。
• 不建议将未授权分离后的伴奏上传到公开平台。
• 不建议对受版权保护的歌曲进行再分发、二次出售。
• 涉及歌手声音、肖像、歌词作品时，需要确认词曲授权、录音版权和表演者权益。
• 更稳妥的用法是：只处理自己拥有合法权利的音频，分离结果仅用于个人学习和技术验证。

3. 环境准备与前置条件

在开始分离之前，先确认本机环境。这里以 Demucs 为主，UVR 作为 GUI 补充。

3.1 系统与依赖

3.2 环境检查命令

python --version pip --version # 有 NVIDIA 显卡时查看驱动与显存 nvidia-smi

如果nvidia-smi能正常输出显卡信息，说明驱动和 CUDA 环境正常。如果没有 NVIDIA 显卡也没关系，Demucs 可以使用 CPU 推理，只是耗时更长。

3.3 安装 Demucs

建议在虚拟环境中安装，避免污染系统 Python。

python -m venv venv # Windows venv\Scripts\activate # Linux / macOS source venv/bin/activate pip install -U demucs

安装完成后验证命令：

demucs --help

如果有 GPU 但默认安装的 PyTorch 没有使用 CUDA，可以按 PyTorch 官方命令重新安装 CUDA 版本，再装 Demucs。具体 CUDA 版本需要与显卡驱动匹配。

3.4 安装 UVR

UVR 一般提供图形界面安装包或便携版，下载后直接解压运行即可。这种方式适合不习惯命令行的用户，模型列表在界面内可视化选择，音频拖进去就能跑。

4. 安装部署与启动方式

部署方式主要分两条路线：命令行路线适合脚本化和批量处理，图形界面路线适合手动调参和快速验证。

4.1 Demucs 命令行启动

Demucs 安装完成后，在终端里直接运行分离命令。下面的示例把一首本地音频拆成人声、鼓、贝斯、其他四轨，并额外生成去人声伴奏：

demucs --two-stems=vocals -n htdemucs -o output_dir "input_audio.wav"

参数含义：

如果不加--two-stems，Demucs 默认输出 drums、bass、other、vocals 四轨，同时也会给出 no_vocals 合成伴奏。

4.2 指定 CPU 推理

没有 NVIDIA GPU 时，强制使用 CPU：

demucs -d cpu -n htdemucs -o output_dir "input_audio.wav"

用 CPU 跑也不是不行，只是遇到长音频时耗时明显。建议第一次测试时先截取 30 秒片段验证流程。

4.3 UVR 图形界面启动

UVR 启动后，界面一般分为“选择音频文件”“选择分离模型”“开始处理”三个区域。操作流程通常是：

1. 选择需要处理的音频文件。
2. 在模型列表中选一个适合分离模型的预训练模型。
3. 设置输出目录。
4. 点击 Start 开始分离。
5. 完成后在输出目录查看分离文件。

UVR 里常见模型有 MDX-Net 系列、Karaoke 系列、Demucs 系列等，具体名称以界面内置列表为准。不同模型对和声、金属声、鼓点保留的倾向不同，多试几个才知道哪个更匹配目标歌曲。

5. 功能测试与效果验证

这里以《峠の恋人》这类中文/日文风格说唱曲目为例给出一套验证流程。前提是你手头有合法授权的音频文件，比如已购买的数字专辑或官方发行音频，仅用于个人技术验证。

5.1 测试目的

• 验证人声与伴奏分离效果。
• 验证能否得到纯 BEAT。
• 验证能否保留和声。
• 验证批量处理是否可用。

5.2 准备测试素材

从原始音频中截取一段 30 秒左右的片段，作为首次测试输入，避免一次性处理整首歌浪费等待时间。

推荐使用 ffmpeg 截取片段：

ffmpeg -i input_audio.mp3 -ss 00:00:30 -t 00:00:30 -c copy sample_30s.mp3

没有 ffmpeg 的可以用 Audacity 等音频编辑器手动截取导出 WAV。使用 WAV 作为测试输入，可以减少 MP3 压缩对分离质量的影响。

5.3 基础人声分离测试

demucs --two-stems=vocals -n htdemucs -o test_output sample_30s.wav

预期输出：

test_output/htdemucs/sample_30s/ ├── vocals.wav └── no_vocals.wav

vocals.wav应该是接近纯净的人声轨道，no_vocals.wav是去除主唱后的伴奏版本。判断成功的标准很简单：播放no_vocals.wav时，主唱声音明显消失，鼓点、贝斯、旋律保留完整；播放vocals.wav时，人声清晰，器乐残留弱。

如果no_vocals.wav里还能听到明显人声，可以从两个方向排查：一是原曲本身在录音阶段就把人声混进了乐器 bus，二是模型选择或者参数还需要调整。可以换htdemucs_ft模型再跑一次。

5.4 纯 BEAT 与带和声测试

“纯 BEAT”通常指的是干净节拍底，重鼓点、贝斯与旋律保留，没有人声。用四轨分离结果可以进一步处理：

demucs -n htdemucs -o test_output sample_30s.wav

输出目录：

test_output/htdemucs/sample_30s/ ├── drums.wav ├── bass.wav ├── other.wav ├── vocals.wav └── no_vocals.wav

如果你想获得更偏向纯 BEAT 的结果，可以把drums.wav、bass.wav和other.wav用音频编辑软件混合，或者直接播放no_vocals.wav感受整体伴奏质感。

“带和声”的需求稍微复杂一些。默认模型倾向于把所有人声都归到vocals.wav，包括主唱和背景和声。如果你想要一个保留背景和声、去掉主唱的版本，可以用下面几种方式：

• 在 UVR 中选择更擅长处理卡拉 OK 场景的模型，这类模型通常会对主唱更激进、对和声保留更宽容。
• 尝试htdemucs_ft模型，它对和声的处理有时比基础版更自然。
• 使用 UVR 的输出通道控制，只保留部分声道或和声相关轨道。

这一项没有统一标准，实际效果以听感为准。判断标准是：主唱消失，但和声在副歌处仍能听到，整体 BEAT 完整。

5.5 多参数对照测试

为了找到当前曲目最合适的分离效果，可以做一组对照测试：

demucs -n htdemucs -o compare_htdemucs sample_30s.wav demucs -n htdemucs_ft -o compare_htdemucs_ft sample_30s.wav

对比两个输出目录中no_vocals.wav的听感。通常htdemucs的器乐分离干净，htdemucs_ft对人声处理更细腻，但不同歌曲结论可能相反。多跑几个模型，保留效果最好的版本即可。

6. 批量任务与脚本化处理

Demucs 的优势之一是可以批量处理，不用手动逐首操作。

6.1 目录批量分离

假设有多个音频文件放在inputs目录：

demucs --two-stems=vocals -n htdemucs -o batch_output inputs/*.wav

一条命令就可以遍历所有符合条件的音频文件。输出会按每个文件名生成独立子目录，方便后续整理。

6.2 Python 批量脚本

在 Python 里可以用subprocess调用 Demucs，并记录日志和失败文件。下面是一个通用模板：

import subprocess from pathlib import Path input_dir = Path("./inputs") output_dir = Path("./batch_output") log_file = Path("./batch_log.txt") input_dir.mkdir(exist_ok=True) output_dir.mkdir(exist_ok=True) audio_files = list(input_dir.rglob("*.*")) failed_files = [] for audio_file in audio_files: if audio_file.suffix.lower() not in [".wav", ".flac", ".mp3"]: continue print(f"Processing: {audio_file.name}") try: subprocess.run( [ "demucs", "--two-stems=vocals", "-n", "htdemucs", "-o", str(output_dir), str(audio_file), ], check=True, timeout=1800, ) with open(log_file, "a", encoding="utf-8") as f: f.write(f"OK: {audio_file.name}\n") except Exception as e: failed_files.append(audio_file.name) with open(log_file, "a", encoding="utf-8") as f: f.write(f"FAIL: {audio_file.name} | {e}\n") print("Failed files:", failed_files)

这个脚本会在日志中标记成功和失败文件，遇到损坏或异常音频时不会中断整个队列。批量任务建议加失败重试和输出文件存在性检查，避免重复处理。

6.3 API 化扩展

如果想把分离能力接到自己的 Web 服务或者前端工具里，可以考虑把 Demucs 作为 Python 库直接调用，或者用 FastAPI 封装一个 HTTP 接口。这部分没有统一模板，需要参考 Demucs 和当前项目的具体接口定义。更简单的方式是在脚本里调用命令行，外部系统通过提交任务文件和读取输出目录来完成任务。

7. 资源占用与性能观察

人声分离是计算密集任务，性能表现直接影响批量处理的效率。

7.1 如何观察资源占用

• CPU：任务管理器或 htop 中查看进程 CPU 百分比。
• 内存：任务管理器或free -h查看内存占用。
• GPU 显存：任务管理器 GPU 专用显存，或命令行周期性执行nvidia-smi。

观察时重点看三点：分离开始时资源占用是否突然升高、是否出现显存溢出、整首歌处理完成后资源是否正常释放。

7.2 CPU 与 GPU 的差异

从常规使用经验来看，CPU 也能跑 Demucs，但耗时明显更高。一个 4 分钟左右的音频，CPU 推理可能需要数分钟到十几分钟，GPU 推理通常在几十秒到几分钟内完成，具体时间取决于显卡型号和模型复杂度。实际数字需要以本机测试为准。

如果没有 GPU，建议先跑短片段验证流程，再决定是否用长音频。

7.3 影响性能的关键因素

• 音频时长：越长越慢。
• 采样率：44.1kHz 和 48kHz 是常见输入，过高会额外增加计算量。
• 模型复杂度：htdemucs_ft比htdemucs更精细，耗时也更高。
• 输出轨数：--two-stems比默认四轨更快。
• 并发数：Demucs 默认使用单卡推理，多文件批量时尽量不要同时启动多个进程，否则容易吃满显存。

7.4 降低资源占用的方法

• 使用--two-stems=vocals，减少输出轨数。
• 把输入音频转成 44.1kHz WAV。
• 先分离片段，确认参数后再处理全长。
• GPU 显存不足时用 CPU 推理，或者降低采样率。
• 批量任务中限制同时运行的进程数。

8. 常见问题与排查方法

如果问题没有出现在上面，优先看终端输出的日志。不管 Demucs 还是 UVR，日志里一般会写明是模型下载失败、路径错误，还是显存分配失败。找到具体报错词，再去搜对应解决方案，效率更高。

9. 最佳实践与使用建议

从实际工程化的角度，提几条建议。

第一，第一次测试不要直接跑整首歌。先截取 30 秒片段，调整好模型和参数后，再处理完整音频。这样能快速判断模型适不适合当前曲风，也能避免浪费大量时间。

第二，工程目录分开管理。输入文件、中间片段、不同模型输出、最终成品尽量分目录存放，命名时带上模型名称和日期，例如：

inputs/原曲/ outputs/htdemucs/ outputs/htdemucs_ft/ comparison/各模型听感对比/

第三，批量任务一定要加日志。记录每个文件的成功、失败、耗时和异常信息，否则某个文件卡住时很难定位。

第四，注意端口和进程残留。如果你后续把分离能力封装成 Web 服务，启动后要注意关闭进程，避免端口被占用。本地命令行方式一般不会遇到端口问题。

第五，分离结果听感验证不能省。指标再漂亮，最终还是要用耳朵判断。建议把输出文件拖入音频编辑软件，对比人声轨和伴奏轨的相位、响度和残留。

第六，合规优先。分离出来的伴奏不能直接当成“原版伴奏”传播，更不能绕过版权方去发行。涉及歌手、词曲、录音版权的内容，必须获得授权后再使用。

10. 总结与下一步

这套方案最值得尝试的点在于：不需要求人找伴奏，不需要下载来路不明的文件，用 Demucs 或 UVR 就能从自己手头的合法音频里分离出伴奏、纯 BEAT 甚至保留和声的版本。

拿到《峠の恋人》这类歌曲的测试素材后，第一步建议先跑htdemucs --two-stems=vocals验证基础分离效果，确认伴奏是否干净，再考虑是否需要保留和声、提取纯 BEAT 或者批量处理整个文件夹。

最容易踩的坑集中在三处：一是 Python 和 PyTorch 的 CUDA 版本不匹配，二是模型文件下载失败，三是输入路径包含中文或空格导致输出为空。按上面的表格逐项排查基本都能解决。

后续可以继续扩展的方向包括：把 Demucs 封装成 Web API，接入自己的批量任务队列；用 UVR 对不同曲风做对比测试，整理出适合自己场景的模型推荐；在分离出的纯 BEAT 上做混音、翻唱或 BGM 剪辑。先跑通一个小流程，再慢慢构建自己的伴奏处理流水线。