Demucs人声分离部署实战：从装到批量交付，8个避坑点一次讲透

Demucs人声分离部署实战：从装到批量交付，8个避坑点一次讲透

【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs

去年我接了一个音乐播客的活，每周要往期节目里扒人声、做伴奏去底噪。搜了一圈工具，最后锁定了Demucs——论文叫 "Hybrid Spectrogram and Waveform Source Separation"，是目前口碑最好的开源人声分离项目，在 MUSDB 测试集上整体 SDR 高达 9.00 dB，吊打一堆商业方案。结果装了一下午，第一次运行就报错，折腾到半夜才跑通第一首歌。

不过坑踩完之后是真香：默认的htdemucs模型，一条 4 分钟的歌在 GPU 上 2 分钟内出齐鼓、贝斯、人声、伴奏四个音轨；即使纯 CPU，处理时长也只有音频时长的 1.5 倍左右。这篇就把我从装到批量交付的全过程写出来，顺带把 8 个坑位标在对应位置，你照着做，不用再交学费。

先交代我的实战环境，方便你对号入座：Ubuntu 22.04 LTS、Python 3.10、NVIDIA 显卡（6GB 显存，属于"勉强能跑"的配置），任务是为播客批量分离人声。

第一次运行就翻车，问题出在哪

按照网上流传的"三分钟安装"，我兴冲冲执行了：

sudo apt update && sudo apt install -y python3-pip python3-venv ffmpeg build-essential pip3 install --user -U demucs

然后拿一首 MP3 试跑：

demucs -d cpu test.mp3

结果直接弹了RuntimeError: ffmpeg not found。查了官方文档 docs/linux.md 才明白：Demucs 解码音频依赖 torchaudio，而 torchaudio 0.12 起，没有 ffmpeg 就解不了 MP3。我的 ffmpeg 是装了的，问题出在 pip 的 demucs 装到了~/.local，而命令行找不到用户级 bin。解决很简单，Linux 上统一用模块方式调用：

python3 -m demucs -d cpu test.mp3

这一跑就是 6 分钟。CPU 处理一条 4 分钟的歌要 6 分钟，30 期播客等于一下午泡汤——纯 CPU 只适合偶尔试一嗓子，批量处理必须上 GPU。

怎么让速度翻 3 倍：GPU 加速与显存不够怎么办

Demucs 对显存不算客气：官方 README 里写了，默认参数需要约 7GB 显存，最低 3GB 能跑。我这张 6GB 的卡直接撞上CUDA out of memory。

官方说明（README.md）：如果你有 GPU 但内存不足，请使用--segment SEGMENT来缩短每个分片的长度，建议至少 10 秒；同时设置环境变量PYTORCH_NO_CUDA_MEMORY_CACHING=1也有帮助。

我踩完给出的组合拳是：

PYTORCH_NO_CUDA_MEMORY_CACHING=1 demucs -d cuda --segment 8 test.mp3

把音频切成 8 秒的小段分别推理，显存占用直接压到 1.5GB 左右，4 分钟的歌 2 分钟内跑完。但注意一个隐藏坑：Transformer 类模型（htdemucs 系列）训练时最长只支持 7.8 秒的分片，你传--segment 10它会直接报错：

Cannot use a Transformer model with a longer segment than it was trained for. Maximum segment is: 7.8

这条校验在源码 demucs/separate.py 里写得明明白白，所以--segment 8就是 Transformer 模型的极限档位。

坑位预警 1：--segment不是越大越好。分片太长既超显存又触发模型限制；分片太短（比如 4 秒）分离质量会明显变差。8 秒是"显存和音质"的甜点位。

坑位预警 2：环境变量PYTORCH_NO_CUDA_MEMORY_CACHING=1会牺牲一点速度换显存，只在你显存确实吃紧时再加。

顺带提一句驱动检查，装机前先nvidia-smi看一眼，没有输出就去装驱动，别再在驱动都没装的情况下白调半天参数。

哪种模型适合你的活儿：从"一顿乱选"到看表下单

Demucs 的-n参数可以选模型，第一次用demucs --list-models就能看到全部清单。我最初无脑选mdx_extra（追求"最高质量"），结果 6GB 显存跑得吭哧吭哧，进度条走得比下歌还慢。后来我把所有模型都试了一遍，结论是这样一张表：

坑位预警 3：htdemucs_ft的质量提升主要是"锦上添花"，但你付出的代价是慢 4 倍。批量场景果断放弃它。

坑位预警 4：网上很多老教程默认模型还是mdx_extra_q，而 v4 早已把默认模型换成了htdemucs。用老教程的参数跑，等于用 2021 年的思路开 2023 年的车。

我的播客场景选的就是htdemucs，配合--two-stems=vocals直接出"人声 + 伴奏"两个文件（也就是卡拉 OK 模式），省得自己再混音：

python3 -m demucs -n htdemucs -d cuda --segment 8 --two-stems=vocals episode_01.mp3

--two-stems的实现逻辑在 demucs/separate.py 里是"先完整分离再混合"——所以它不会变快也不会省显存，只是帮你把伴奏轨合并好，命名成no_vocals.wav。

一晚上要出 100 首歌，怎么批量干

单曲跑通之后，真正的考验来了：30 期播客、每期一个多小时，等于一百多首歌。逐条执行命令显然不现实，我写了个批量脚本，先建好输入输出目录：

mkdir -p input separated

#!/bin/bash # batch_separate.sh INPUT_DIR="input" OUTPUT_DIR="separated" for file in "$INPUT_DIR"/*.mp3; do python3 -m demucs -n htdemucs -d cuda --segment 8 \ --two-stems=vocals -o "$OUTPUT_DIR" "$file" done

这里的-o指定输出根目录，结果会按separated/htdemucs/歌曲名/的层级存放，四个文件vocals.wav、drums.wav、bass.wav、other.wav整整齐齐（用了--two-stems则只有两个）。

坑位预警 5：文件名带空格时必须加引号。Demucs 会报File xxx does not exist. If the path contains spaces...，报错信息本身就教你怎么改——把整个路径用引号包起来。上面脚本里"$file"就是为这个坑准备的。

批量还有个提速神器：-j并行。它同时处理多个文件，但代价是内存按倍数上涨——官方在 demucs/api.py 的注释里特意警告过jobs会显著增加内存占用。我的经验是：

• CPU 场景：-j设为 CPU 核心数的一半，nproc查核心数；
• GPU 场景：显存本来就紧张，老老实实单线程跑，-j留给 CPU 核多的机器。

坑位预警 6：不要一个脚本同时挂 4 个以上的 Demucs 进程。内存溢出时系统不会报"内存不足"，而是直接把你进程杀掉，日志一片安静，你根本不知道发生了什么。

输出文件太占空间，怎么压缩又不心疼

WAV 是默认输出，一条 4 分钟的歌四个音轨加起来轻轻松松 250MB+，一百首歌就是 25GB。我的方案：交付用 MP3 320kbps，存档用 FLAC：

# 交付版本：MP3 320k，音质足够播客用 python3 -m demucs -n htdemucs --mp3 --mp3-bitrate 320 episode_01.mp3 # 存档版本：FLAC 无损压缩 python3 -m demucs -n htdemucs --flac episode_01.mp3

这两个参数在 demucs/separate.py 里是互斥的（同属一个参数组），别想着--mp3 --flac一起上。需要更高保真度时还有--float32（体积翻倍）和--int24（24 位整型），都是老录音棚的常见需求。

坑位预警 7：默认输出是 int16 WAV，MP3 编码走的是--mp3-preset（2 为最高质量、7 为最快）。如果你追求极致音质，别省这个参数，默认就是 2。

同样的歌，CPU 和 GPU 到底差多少

参数调完，我专门做了一轮对照测试，就用项目根目录的test.mp3，4 分钟的流行歌，模型htdemucs，结果很直观：

结论很明确：GPU 分片是"显存 3~6GB"档位的唯一解，速度是 CPU 的 3 倍，显存占用还压进安全区。如果你的显存连 2GB 都没有，可以再叠加PYTORCH_NO_CUDA_MEMORY_CACHING=1，官方实测分离 4 分钟的歌只用了 1.5GB。

坑位预警 8：CPU 处理时长约为音频时长的 1.5 倍是"正常水平"，不是卡死。看到一个多小时的歌 CPU 跑一个半小时，别急着 Ctrl+C，那是它在正常干活。

交付前的验收清单，和下一步还能做什么

照上面的流程走完，每期播客从"扔进去"到"拿到人声轨"大概 40 分钟（单期 1 小时 + 分片 + MP3 编码）。交付前你可以对着这张单子勾一遍：

• demucs --version能输出版本号，命令行不用再加python3 -m前缀（把~/.local/bin加进 PATH）
• 分离结果在separated/模型名/歌曲名/下，命名规范无乱码
• 人声轨无爆音（有爆音就把--clip-mode clamp换成默认的rescale，它会自动缩放防削波）
• GPU 显存峰值记录在案，确认跑一整批不会中途崩
• MP3 交付件大小符合预期，抽查 3 秒人声无金属味

如果批量任务要长期挂机，可以把它注册成 systemd 服务，开机自启、崩了自动重启，日志走journalctl -u demucs -f随时看。

再往深走，有三条路供你选：

1. 把 Demucs 集成进自己的程序——它提供了干净的 Python API（demucs/api.py），一句demucs.separate.main(["--mp3", "song.mp3"])就能在自己的工具里调用；
2. 调模型性能——仓库自带 tools/bench.py 基准脚本，能精确测出每个模型的前向耗时和显存峰值，想换卡、换模型前先跑一遍它；
3. 自己微调模型——官方把训练配置放在 conf/variant/finetune.yaml，想针对"播客说话声"这类特殊场景练专属模型，这是现成的起点。

这张架构图就是 Demucs 的核心思路：一条时域分支、一条频域分支，中间用一个跨域 Transformer 打通两边信息，最后把两条路的结果合在一起。理解了它，你就明白为什么它能把"波形细节"和"频谱整体感"同时抓住——这也是它人声分离质量稳居第一梯队的原因。

工具装好只是开始，真正值钱的是你把它用顺手的参数组合。我的这套配置也许不是你的最优解，但照着这个思路走，你今晚就能跑通第一首歌。

【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs