htdemucs vs BS-RoFormer vs Spleeter：2026 年音源分离基准评测
从 SDR 分数、推理成本到真实生产延迟，全面对比三个主流开源音源分离模型——以及在生产环境中各自真正合适的场景。
如果你过去十二个月里关注过 AI 音乐分离，那大概率绕不开三个名字：Spleeter、htdemucs（Hybrid Transformer Demucs）和 BS-RoFormer。它们出现在每一篇对比文、每一篇研究论文和每一份「如何提取人声」的教程里——但大多数对比的方式都不对。多数文章只是引用一篇 2019 年论文里的某个 SDR 数字，就草草收尾。
如果你想做产品、搭建处理管线、或者为真实音频选一个模型，这种比法没什么用。
本文从部署音源分离时真正重要的几个维度来比较这三者：
- 质量——来自同行评审论文的 SDR 分数，不是凭感觉
- 推理速度——你在生产环境里实际要等多久
- 每首歌成本——以 2026 年的常规 GPU 价格为基准
- 输出灵活度——2 轨 vs 4 轨 vs 6 轨
- 每个模型在什么场景下是正确选择——以及什么时候不是
下面所有内容都基于已发表的基准测试，加上我们自己在生产环境里大规模部署 htdemucs 的实测。凡是引用数字的地方，我们都给出了出处。
TL;DR（直接给结论）
| 模型 | 适用场景 | 输出音轨 | 质量（平均 SDR） | 速度 |
|---|---|---|---|---|
| Spleeter | 实时、低资源、批量处理 | 2、4 或 5 | ~5.9 dB（人声） | GPU 上约 100× 实时 |
| htdemucs | 生产级 C2C 应用，质量与速度兼顾 | 4 或 6 | ~9.0 dB（平均） | A40 上约 5–8× 实时 |
| BS-RoFormer | 最高保真度的离线处理、母带、归档 | 通常 4 | ~9.80 dB（平均） | A40 上约 2–3× 实时 |
如果你只想从这篇文章带走一句话：htdemucs 是几乎所有产品的合理默认选择，而且你大概率应该跑 htdemucs_ft 而不是默认 checkpoint。 在 Replicate 的 serverless 计费下，三种 Demucs 变体（default、6s、ft）每次调用的成本几乎一样——但 ft 的分离质量明显更好。我们一开始也没料到这点，是看了实际账单之后才发现的。
BS-RoFormer 只在 bass 上有显著优势，且仅当你不在乎延迟的时候。Spleeter 是一个跑在 2026 年硬件上的 2019 年模型——快是真快，但质量差距如今已经能听出来了。
下面解释为什么。
我们说的「质量」是什么——简要解释 SDR
音乐音源分离的质量通常用 Signal-to-Distortion Ratio（SDR，信号失真比） 来衡量，单位是分贝，越高越好。参照数据集是 MUSDB18（高质量音频版本是 MUSDB18-HQ），包含 150 首完整歌曲，每首都附有人声、鼓、bass 和「其他」四类分离音轨。
几个实用的参考锚点：
- <6 dB SDR：能明显听到伪音，人声有「相位感」，音轨之间有可闻泄漏
- 6–8 dB SDR：日常用途够用（卡拉 OK、扒歌学习、灵感草稿）
- 8–10 dB SDR：内容创作和绝大多数 DJ 应用都干净够用
- >10 dB SDR：对普通听众而言已接近透明；轻度后期清理后可达到发行级质量
人声 SDR 大约超过 9 dB 之后，多数听众在盲听测试里已经分不出差别。再往上的提升集中在边缘场景——重混响、双人声、复杂混音。
关于 SI-SDR 的提醒：一些近期论文报告的是 SI-SDR（尺度不变 SDR），它会修正简单的增益差异，更鲁棒。如果本文中的数字与其他来源不同，通常是因为指标定义不一样。
三个模型简介
Spleeter（Deezer，2019）
由 Deezer 研究团队在 2019 年发布，Spleeter 是一种工作在频谱域的 U-Net 架构。它有 2 轨（人声/伴奏）、4 轨（人声/鼓/bass/其他）和 5 轨（再加钢琴）三种配置。
它在当时是里程碑式的发布——第一次让所有人都可以在笔记本 CPU 上免费跑出「够用」的音源分离。六年后，所有现代模型在质量上都已经超过了它，但它至今仍是最快、最轻量的选项，差距很大。
htdemucs（Meta AI，2022）
Meta AI 研究团队推出的第四代 Demucs 模型。与 Spleeter 不同，htdemucs 是 混合（hybrid） 模型——它同时在时域（波形）和频域（频谱）上工作，由 Transformer 主干将两者连接。原始论文 报告了相对上一代 Demucs 在 MUSDB-HQ 上 1.4 dB SDR 的提升。
实际中有两个变体值得关注：
htdemucs——标准 4 轨模型htdemucs_6s——6 轨变体，额外输出独立的吉他和钢琴音轨
还有一个 htdemucs_ft，是 fine-tune 版本，速度更慢，但单个音轨上略微更准。
htdemucs 在 2021 年 Sony Music Demixing Challenge 中表现颇具竞争力，至今仍是大多数不追求绝对 SOTA 的生产管线的默认选择。
BS-RoFormer（2023）
MUSDB18-HQ 当前的 SOTA。BS-RoFormer（Band-Split RoPE Transformer）是一种纯 Transformer 架构，用分层 RoPE Transformer 取代了 RNN 模块。它把输入频谱切分成多个不重叠的频率子带，利用「不同乐器占据特定频率范围」这一事实（bass 偏低、镲片偏高，等等）。
在 MUSDB18-HQ 加 500 首额外歌曲上训练的 BS-RoFormer 拿下了 Sound Demixing Challenge 2023（SDX23）音乐音源分离赛道的第一名。即便是不使用额外数据训练的较小版本，在 MUSDB18-HQ 上也报告了 9.80 dB 的平均 SDR。
代价是：它比 htdemucs 更慢、更吃显存，而且生产可用的开源权重还散落在各个社区实现里，没有一个统一的官方版本。
1. 质量基准（公开 SDR 分数）
这是大多数对比文章翻车的地方——他们随手挑一个数字了事。下面是已发表文献里在 MUSDB18-HQ（除非注明，未使用额外训练数据）上每个音轨的 SDR 分数：
| 模型 | 人声 | 鼓 | Bass | 其他 | 平均 |
|---|---|---|---|---|---|
| Spleeter（4 轨） | ~5.9 dB | ~5.9 dB | ~5.5 dB | ~4.5 dB | ~5.4 dB |
| htdemucs（默认） | ~8.1 dB | ~8.4 dB | ~8.6 dB | ~5.9 dB | ~7.7 dB |
| htdemucs_ft（fine-tune） | ~8.9 dB | ~9.5 dB | ~9.4 dB | ~6.4 dB | ~8.5 dB |
| BS-RoFormer（无额外数据） | — | — | ~11.28 dB | — | ~9.80 dB |
| BS-RoFormer（加 500 首额外歌曲） | — | — | — | — | ~9.76 dB+ |
来源：Spleeter 分数来自 Spleeter JOSS 论文 和 BeatsToRapOn 分离基准。htdemucs 分数来自 Hybrid Spectrogram and Waveform Source Separation 和 Benchmarks and leaderboards for sound demixing tasks。BS-RoFormer 分数来自 同一篇论文 中记录的 SDX23 结果。
从这张表里能看出几点：
Spleeter → htdemucs 之间的差距比 htdemucs → BS-RoFormer 之间的差距更大。 从 Spleeter 升级到 htdemucs，平均能拿到约 +2.3 dB；从 htdemucs 升级到 BS-RoFormer 大约是 +1.3 dB。这正是为什么 htdemucs 是大多数场景下的实用甜区。
BS-RoFormer 最大的胜势在 bass。 Bass 分离从 ~8.6 dB（htdemucs）跳到 ~11.28 dB（BS-RoFormer）——这是盲听里能听出来的差距。人声和鼓的提升要小得多。如果你做的东西特别需要干净的 bass（DJ 工具、扒谱、面向 bass 玩家的音乐教学），BS-RoFormer 值得多花的算力。其他场景下，提升处于刚能感知的边缘。
htdemucs_ft 被低估了。 很多对比只测了默认的 htdemucs checkpoint。Fine-tune 版本（htdemucs_ft）以约 4× 的推理时间为代价，几乎补齐了与 BS-RoFormer 之间的差距——而且实际上仍然比 BS-RoFormer 快。
2. 推理速度（真实情况，不是理论值）
在单张 A40 GPU 上处理一首 3 分钟歌曲的端到端大约耗时，从 API 调用到结果可下载：
| 模型 | 端到端耗时 | 实时倍率 |
|---|---|---|
| Spleeter（4 轨，GPU） | ~2–5 秒 | ~40–90× 实时 |
| htdemucs（默认，4 轨） | ~30–45 秒 | ~4–6× 实时 |
| htdemucs_6s（6 轨） | ~40–60 秒 | ~3–5× 实时 |
| htdemucs_ft（fine-tune） | ~90–150 秒 | ~1.2–2× 实时 |
| BS-RoFormer | ~60–120 秒 | ~1.5–3× 实时 |
注意事项：
- 端到端时间 ≠ 纯 GPU 推理时间。 公开基准通常只报告干净输入下模型的前向传播。真实生产时间还包括容器冷启动（serverless 环境下 5–30 秒）、音频 I/O（文件下载、ffmpeg 预处理）、以及结果上传。上面这些数字是 Replicate 上的端到端实测。
- Spleeter 的速度处在另一个量级。 它是唯一一个在纯 CPU 上也能舒舒服服跑得比实时快的模型。
- htdemucs 的
overlap参数是个很大的速度杠杆。 默认overlap=0.25是合理折中；设为overlap=0.5在约 2× 成本下略微提升质量；设为overlap=0会明显更快，但会在分段边界引入可闻的切块伪音。 - BS-RoFormer 的参考实现速度差异巨大，取决于你用的是谁的 checkpoint 和推理代码。上表是面向社区流行的 MVSep BS-RoFormer SW 构建的数据。
如果你做的是消费级产品、用户得在前端等结果，根据我们的经验，3 分钟歌曲处理时间一旦超过约 60 秒，转化率就开始受损。这把 htdemucs（default 和 6s）留在了可接受区间内，把 htdemucs_ft 和 BS-RoFormer 推向了异步/排队流程，让用户等会儿再回来取结果。
3. 每首歌成本（生产部署经济学）
这部分是大多数网络对比完全说错的地方。Replicate 上的公开计价看起来很直白——A40 是 $0.000725/秒，乘上推理时间就完事。实际上，这个算法和你真实账单大约差 2×，而且还有一个几乎没人提到的有趣细节。
我们生产部署中最重要的发现
我们在 aistemsplitter.org 上跑 htdemucs 已经几个月了，三种 Demucs 变体都在用——htdemucs（默认 4 轨）、htdemucs_6s（6 轨）、htdemucs_ft（fine-tune）。在 Replicate 的 A40 GPU 实例上，这三种变体在我们的实际账单里每次调用的成本几乎一样：大约是 每 1 美元 22 次调用，也就是大约 每首歌 $0.045。
这值得停下来想一下，因为它和你从已发表的推理时间推出来的预期相反。
| 模型 | 朴素成本（公开计价 × 推理时间） | 我们的实际测量成本 |
|---|---|---|
| Spleeter（GPU） | <$0.002 | <$0.005 |
| htdemucs（默认） | ~$0.022 | ~$0.045 |
| htdemucs_6s（6 轨） | ~$0.029 | ~$0.045 |
| htdemucs_ft（fine-tune） | ~$0.11 | ~$0.045 |
| BS-RoFormer | ~$0.065 | ~$0.06–0.10（浮动） |
为什么三种 Demucs 变体的成本会收敛到同一水平
朴素的计价模型假设你只为纯 GPU 推理时间付费。实际上，每次 Replicate 调用还包括：
- 容器冷启动时间（从零扩容时 5–30 秒）
- 把模型权重加载进 GPU 显存
- 音频文件下载和 ffmpeg 预处理
- 结果编码和回传到存储
- 每次调用的最小可计费时长
这些开销大体上是每次调用的 固定成本——它们不会随模型复杂度而显著放大。当 GPU 前向传播从 30 秒（htdemucs default）涨到 90 秒（htdemucs_ft）时，这部分 额外 的算力对账单的影响远小于你的预期，因为每次调用的固定开销已经吃掉了大头。
实际意义是：如果你已经在 htdemucs 这条路上，几乎没有任何经济理由不去用你的延迟预算允许的最高质量变体。 如果用户能等 60 秒，就用 htdemucs_6s（6 轨，默认速度）。如果他们能等 2 分钟，就用 htdemucs_ft（fine-tune，多数音轨上的质量逼近 BS-RoFormer）。账单一样。
这和你读学术论文加 Replicate 公开 GPU 计价得出的结论正好相反。它只在你月底真实看账单时才会显现。
对单位经济的影响
如果你在为一个音轨分离器产品建模单位经济，每首歌 $0.04–$0.05 应作为底价，无论你选择哪个 Demucs 变体。这意味着：
- 免费层上限——按每用户 10 分钟免费（≈3 首免费歌曲）算，在任何转化发生前你已经为每个注册用户消耗了大约 $0.13
- 可行的最低 credit pack 售价——零售价低于约 $0.10/首就没有空间承担 Stripe 手续费、客服和基础设施开销
- 批量处理成本——每月 1 万首歌的话，仅推理这一项就要约 $450，还没算存储、带宽和其他基础设施
两个重要的注意点：
- 低流量时冷启动占主导。 如果你的服务每天处理量低于几百首歌，冷启动开销在比例上会更大。在非常低的流量下，单首实际成本可能漂到 $0.06–$0.07。
- 自托管要在每月推理花费超过 ~$2k 之后才比 serverless 更划算。 在你有足够稳定流量、能让一张专用 GPU 利用率超过 40% 之前，serverless GPU 比 RunPod、Vast.ai 或自建机房都便宜。我们直接量过——整个上线期 Replicate 的成本始终低于专用基础设施。
4. 输出灵活度（音轨数量与格式）
| 模型 | 可用音轨配置 | 备注 |
|---|---|---|
| Spleeter | 2、4 或 5 轨 | 5 轨加钢琴（独立模型） |
| htdemucs | 4 或 6 轨 | htdemucs_6s 增加吉他和钢琴 |
| BS-RoFormer | 主要是 4 轨；社区有部分 6 轨构建 | 在较稀有的吉他/钢琴音轨上质量下降 |
这是 htdemucs_6s 真正独占的地方。 如果你的用例需要独立的吉他或钢琴音轨（音乐教学、多轨混音、扒谱），htdemucs_6s 是当下唯一一个在生产质量下广泛可用的模型。BS-RoFormer 的 6 轨变体在社区里存在，但成熟度更低；正典的 BS-RoFormer 是一个 4 轨系统。
对于「只要人声」或「只要伴奏」这类用例（卡拉 OK 人群），三个模型都能用，应当按速度而不是按质量来选。Spleeter 在 90× 实时下能在毫秒级给你一段可用的伴奏。
5. 什么时候选哪个
在生产环境跑了几个月之后，下面是我们会给从零起步的人一份简洁的决策树：
选 Spleeter 当：
- 你需要实时或接近实时地处理音频
- 你跑在 CPU 或资源受限的硬件上
- 你需要批量处理吞吐（例如对一个音乐库做特征提取）
- 质量门槛是「能用」而不是「好」
选 htdemucs 当：
- 你在做面向消费者的产品，用户等待时间需要 <60 秒
- 你需要 6 轨（用
htdemucs_6s） - 你想要生产环境下最佳的「每美元质量比」
- 你不想自己维护推理代码（它在所有主流模型服务平台上都有良好支持）
选 BS-RoFormer 当：
- 你跑的是离线或批处理任务，每首 1–2 分钟可以接受
- 你特别在意 bass 质量（DJ 工具、扒谱、音频分析）
- 你在做发行级作品，每一点 SDR 边际收益都重要
- 你愿意投入工程时间跟进社区模型发布
这三者都不要选，当：
- 你只需要做卡拉 OK 的人声去除。用 Spleeter 2 轨就够；通过麦克风外放的伴随演唱场景，质量差异并不重要。
- 你需要 DJ 应用里的实时音轨分离。这三个在消费级硬件上都不是实时的。请用一个内置实时分离的 DAW（Ableton 12 等），或者预先离线处理素材。
实际部署是什么样
我们在 aistemsplitter.org 上跑的是 htdemucs_6s——一个 6 轨分离的托管版本，目标用户是不想自己折腾本地工具链的人（在 PyTorch 版本、CUDA 版本和音频依赖地狱之间，搭一遍环境通常要花掉一整个下午）。
我们学到的几件论文里没说的事：
- 真实生产成本大约是朴素估算的 2×，并且在 Demucs 变体之间几乎是 持平 的。 公开 GPU 计价 × 推理时间得到的数字忽略了平台开销。我们 Replicate 上的真实账单算下来大约是每首歌 $0.045——而且无论我们跑
htdemucs、htdemucs_6s还是htdemucs_ft，这个数字都一样。每次调用的固定开销淹没了模型之间的边际算力差异。这一个事实改变了我们选模型的方式：按质量挑，不按理论算力成本挑，因为成本差在账单里根本不出现。 - 格式转换比模型本身更重要。 htdemucs 只接受 WAV 输入。用户上传的是 MP3、FLAC、M4A、OGG，以及越来越奇怪的 WebM 容器。要把 ffmpeg 预处理层在规模化场景下做对，并不平凡。
- YouTube/SoundCloud URL 摄入是 UX 收益的一半。 让用户先下载文件再上传会流失约 40%。通过 yt-dlp 直接从 URL 摄入维护起来很烦（年龄受限视频、地区锁、直播流），但值得做。
- 6 轨场景才是用户感受到「魔法」的地方。 当一个人第一次听到自己最喜欢的歌里吉他从钢琴里被分出来，他们会去告诉朋友。4 轨场景是「不错」；6 轨场景是「等等，这怎么做到的」。
如果你想在不搭工具链的前提下听一下 6 轨 htdemucs 在真实音频上的效果，我们站点上有免费额度可以试几首歌。
接下来这块领域会发生什么
2026 年值得关注的几个开放问题：
- 8 轨（人声/和声/鼓/bass/吉他/钢琴/合成器/其他）会成为标准吗？ 社区 fine-tune 在朝这个方向走，但单独的合成器和和声音轨的训练数据是瓶颈。
- 消费级硬件上的实时？ 目前没有任何开源模型能在 CPU 上以可接受的质量实时运行。模型蒸馏会改变这一点，但大概率不在 2026 年。
- 多语种 / 非西方音乐的人声分离。 多数公开基准被英语流行和摇滚主导。在使用不同发声技巧的语言上（普通话、重 auto-tune 的 Cantopop、宝莱坞的人声叠层），我们看到性能明显下降。这是该领域真实的空白，而不是模型部署问题。
如果你在这块工作，并且有我们会感兴趣的数据——或者你在这些模型上踩到过我们没踩过的坑——联系我们。
参考资料
- htdemucs——Rouard, S., Massa, F., Défossez, A. Hybrid Transformers for Music Source Separation. arXiv:2211.08553
- Demucs v4（hybrid）——Défossez, A. Hybrid Spectrogram and Waveform Source Separation. arXiv:2111.03600
- BS-RoFormer——Lu, W.-T., Wang, J.-C., et al. Music Source Separation with Band-Split RoPE Transformer. SDX23 Challenge results
- Spleeter——Hennequin, R., Khlif, A., Voituret, F., Moussallam, M. Spleeter: a fast and efficient music source separation tool with pre-trained models. JOSS 2020
- MUSDB18 数据集——Rafii, Z., Liutkus, A., Stöter, F.-R., Mimilakis, S. I., Bittner, R. The MUSDB18 corpus for music separation. Zenodo
- Sound Demixing Challenge 2023——Mitsufuji et al., SDX23 results
- MVSep 模型排行榜——mvsep.com/en/algorithms
最后更新：2026 年 4 月。如果你在数据、SDR 数字或任何实际结论里发现错误，发一封更正给我们，我们会更新文章并署名感谢。
作者
分类
更多文章
最佳人声去除工具横评：我用同一首歌实测了 7 款
我把同一首 Pixabay 曲目分别丢给 LALAL.AI、Moises、vocalremover.org、Voice.ai、Fadr、UVR 和我自己做的 AI Stem Splitter。这是一份戴着耳机听出来的诚实对比，外加一份获取干净六轨输出的逐步操作指南。
How to Remove Vocals from Any Song: A Beginner's Step-by-Step Guide (2026)
Step-by-step guide to removing vocals from any song with AI. No software to install, no signup for your first try. Get a clean instrumental in under 90 seconds.
如何用 AI Stem Splitter 制作练习伴奏
一套实用流程，做出「除自己乐器外全套乐队」的伴奏——涵盖模型选择（4 轨 vs 6 轨）、人声/吉他/贝斯/鼓的分步操作、哪些歌分不干净，以及怎么降速。