htdemucs vs BS-RoFormer vs Spleeter：2026 音源分離基準測試
從 SDR 分數、推論成本到實際延遲，比較 htdemucs、BS-RoFormer 與 Spleeter 三大開源音源分離模型——基於 aistemsplitter.org 的生產部署實測資料。
如果你在過去十二個月研究過 AI 音樂分離，大概都遇到過同樣這三個名字：Spleeter、htdemucs（Hybrid Transformer Demucs）以及 BS-RoFormer。它們出現在每一篇比較文章、每一份研究論文、以及每一個「如何提取人聲」的教學裡——但這些比較通常都不對。多數文章只引用 2019 年論文中一個 SDR 數字就交差了事。
如果你打算把產品做出來、把流程跑起來、或為實際音訊挑一個模型，這種比較毫無用處。
這篇文章從真正影響部署音源分離決策的維度來比較這三個模型：
- 品質——來自同行評審文獻的 SDR 分數，不是憑感覺
- 推論速度——你在生產環境中實際要等待的時間
- 每首歌的成本——以 2026 年的價格在通用 GPU 上運行
- 輸出靈活性——2 軌、4 軌還是 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 而不是預設檢查點。 在 Replicate 的 Serverless 計費上，三個 Demucs 變體（default、6s、ft）每次呼叫的成本基本一樣——但 ft 提供的分離品質明顯更好。我們一開始也沒料到這點，是真的去看實際帳單之後才看清楚。
BS-RoFormer 只在貝斯這一項上明顯領先，而且僅限延遲不重要的場景。Spleeter 是 2019 年的模型跑在 2026 年的硬體上——速度很快，但品質差距現在已經聽得出來。
本文剩下的部分解釋為什麼。
我們所謂的「品質」是什麼——簡述 SDR
音樂音源分離的品質通常以 訊號失真比（Signal-to-Distortion Ratio, SDR） 衡量，單位是分貝（dB）。數值越高越好。標準參考資料集是 MUSDB18（高品質版本為 MUSDB18-HQ），包含 150 首完整曲目，分別有人聲、鼓、貝斯與「其他」的獨立音軌。
幾個實用的參考錨點：
- SDR < 6 dB：明顯有瑕疵、人聲帶有「相位感」、音軌之間有可聽見的串音
- SDR 6–8 dB：足以應付休閒用途（卡拉 OK、學歌、構思想法）
- SDR 8–10 dB：足夠乾淨，可用於內容創作與多數 DJ 應用
- SDR > 10 dB：對一般聽眾來說已接近透明；經輕度後製即可達到發行級品質
人聲只要超過約 9 dB，多數聽眾在盲聽測試中已分不出差異。再往上的提升主要關係到邊緣情況——重殘響、重疊人聲、複雜混音。
關於 SI-SDR 的補充：部分近期論文使用 SI-SDR（scale-invariant SDR，尺度不變 SDR），它修正了單純的增益差異，更具穩健性。當本文中的數字與其他來源不符，多半就是因為衡量指標的定義不同。
三個模型的簡介
Spleeter（Deezer，2019）
由 Deezer 研究團隊於 2019 年釋出，Spleeter 是一個在頻譜域運作的 U-Net 架構。它有 2 軌（人聲／伴奏）、4 軌（人聲／鼓／貝斯／其他）與 5 軌（多加鋼琴）三種設定。
當時這是一個里程碑式的釋出——首次有人能在筆電的 CPU 上跑出夠好的音源分離，且沒有授權費用。六年後，它在品質上已被每一個現代模型超越，但仍以絕對優勢保持最快、最輕量的地位。
htdemucs（Meta AI，2022）
來自 Meta AI 研究團隊的第四代 Demucs 模型。與 Spleeter 不同，htdemucs 是一個 混合（hybrid） 模型——它同時在時域（波形）與頻域（頻譜）運作，並由一個 Transformer 主幹將兩者連起來。原始論文 報告在 MUSDB-HQ 上比上一代 Demucs 提升 1.4 dB SDR。
實務上有兩個變體比較重要：
htdemucs——標準 4 軌模型htdemucs_6s——6 軌變體，多加吉他與鋼琴音軌
另外還有 htdemucs_ft，是經過微調的版本，速度較慢但個別音軌的精度略高。
htdemucs 在 2021 年的 Sony Music Demixing Challenge 取得有競爭力的成績，至今仍是多數不追求絕對 SOTA 的生產流程的預設選擇。
BS-RoFormer（2023）
目前在 MUSDB18-HQ 上的最新技術水準，BS-RoFormer（Band-Split RoPE Transformer）是一個純 Transformer 架構，以階層式 RoPE Transformer 取代 RNN 模組。它將輸入頻譜切分為多個不重疊的頻率子帶，利用「不同樂器佔據特有頻率範圍」這一事實（貝斯偏低、鈸偏高等等）。
在 MUSDB18-HQ 加上額外 500 首歌的資料集上訓練的 BS-RoFormer 拿下 Sound Demixing Challenge 2023（SDX23）音樂音源分離賽道的第一名。即使是未使用額外資料訓練的較小版本，在 MUSDB18-HQ 上仍報告平均 9.80 dB SDR。
缺點是：它比 htdemucs 更慢、更吃記憶體，而且生產可用的開源權重至今仍分散在社群實作中，沒有單一的標準釋出。
1. 品質基準（已發表的 SDR 分數）
這正是多數比較文章站不住腳的地方——它們挑一個單一數字。以下是已發表文獻中針對 MUSDB18-HQ（除非註明，否則未使用額外訓練資料）的各音軌 SDR 分數：
| 模型 | 人聲 | 鼓 | 貝斯 | 其他 | 平均 |
|---|---|---|---|---|---|
| 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（微調） | 約 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 最大的勝出在貝斯。 貝斯分離從約 8.6 dB（htdemucs）跳升到約 11.28 dB（BS-RoFormer）——這個差距在盲聽測試中聽得出來。人聲與鼓的提升幅度則小得多。如果你做的東西明確需要乾淨的貝斯（DJ 工具、轉譜、給貝斯手的音樂教學），BS-RoFormer 額外的運算成本是值得的。其他用途下，差距已在感知邊界。
htdemucs_ft 被低估了。 多數比較文章只測試預設的 htdemucs 檢查點。微調版本（htdemucs_ft）以約 4 倍的推論時間為代價，把與 BS-RoFormer 的差距大幅縮小——而實務上仍比 BS-RoFormer 快。
2. 推論速度（真實世界，不是理論值）
以下是 3 分鐘歌曲在單張 A40 GPU 上、從 API 呼叫到輸出可下載為止的端到端時間估計：
| 模型 | 端到端時間 | 即時速度倍率 |
|---|---|---|
| Spleeter（4 軌、GPU） | 約 2–5 秒 | 約 40–90× 即時速度 |
| htdemucs（預設、4 軌） | 約 30–45 秒 | 約 4–6× 即時速度 |
| htdemucs_6s（6 軌） | 約 40–60 秒 | 約 3–5× 即時速度 |
| htdemucs_ft（微調） | 約 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 的參考實作之間速度差異極大，取決於你用的是誰的檢查點與推論程式碼。上表數字是針對 社群常用的 MVSep BS-RoFormer SW 構建版本。
如果你做的是讓使用者等結果的消費級產品，根據我們的經驗，3 分鐘歌曲處理超過約 60 秒，轉換率就會開始下滑。這讓 htdemucs（預設與 6s）剛好還在可接受範圍內，把 htdemucs_ft 與 BS-RoFormer 推向非同步／佇列流程，讓使用者稍後再回來取結果。
3. 每首歌的成本（生產部署的經濟學）
這是大多數網路上的比較完全錯掉的章節。Replicate 的公開定價看起來很直觀——A40 每秒 $0.000725，乘上推論時間，搞定。實際上這個算法跟你的真正帳單差了大約 2 倍，而且還有一個幾乎沒有比較文章提到的有趣轉折。
我們生產部署的核心發現
我們在 aistemsplitter.org 已經把 htdemucs 三個變體跑在生產環境好幾個月了——htdemucs（預設 4 軌）、htdemucs_6s（6 軌）以及 htdemucs_ft（微調）。在 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（微調） | 約 $0.11 | 約 $0.045 |
| BS-RoFormer | 約 $0.065 | 約 $0.06–0.10（變動較大） |
為什麼三個 Demucs 變體會收斂到同樣的成本
天真定價模型假設你只為純 GPU 推論時間付費。實務上，每一次 Replicate 呼叫還包含：
- 容器冷啟動時間（從零擴展時 5–30 秒）
- 模型權重載入到 GPU 記憶體
- 音訊檔案下載與 ffmpeg 前處理
- 結果編碼與上傳回儲存
- 每次呼叫的最低計費時長
這些開銷大致是每次呼叫的 固定成本——它們不會隨模型多複雜而增加。當 GPU 前向傳遞從 30 秒（htdemucs 預設）變成 90 秒（htdemucs_ft），額外 的運算對帳單的影響其實沒你想像那麼大，因為每次呼叫的固定開銷已經吃掉預算的大部分。
實務上的意義：如果你已經在 htdemucs 平台上，幾乎沒有經濟上的理由不挑你的延遲預算容許下品質最高的變體。 如果使用者願意等 60 秒，就用 htdemucs_6s（6 軌、預設速度）。如果他們願意等 2 分鐘，就用 htdemucs_ft（微調，多數音軌品質接近 BS-RoFormer）。帳單一樣。
這跟你光看學術論文與 Replicate 的公開 GPU 定價會得到的結論完全相反。它要等你月底真的看帳單時才會浮現。
對單位經濟學的意義
如果你正在為一個音軌分離產品做單位經濟學模型，無論你選哪個 Demucs 變體，都把每首歌 $0.04–$0.05 當作下限。這就決定了：
- 免費方案的天花板——每位使用者 10 分鐘免費（約 3 首歌），每位註冊在轉換之前會吃掉約 $0.13 的成本
- 可行的最低點數包定價——零售價低於每首歌約 $0.10，扣掉 Stripe 手續費、客服與基礎建設管銷後就毫無毛利
- 批量處理成本——每月 10,000 首歌，純推論成本約 $450，這還沒算儲存、頻寬與其他基礎建設
兩個重要的注意事項：
- 流量低時冷啟動會主導成本。 如果你的服務每天處理少於數百首歌，冷啟動的開銷比例會更大。在非常低的流量下，實際成本可能會往每首歌 $0.06–$0.07 漂移。
- 每月推論花費超過約 $2k 之後，自架才比較划算。 在你有足夠的穩定流量讓專屬 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 分鐘可以接受
- 貝斯品質特別重要（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 的網址匯入是 UX 勝負的一半。 要使用者下載檔案再上傳，會流失約 40% 的人。透過 yt-dlp 直接吃網址要維護起來很煩（年齡限制影片、地區封鎖、直播）但值得。
- 6 軌是使用者真的會「驚豔」的場景。 當有人第一次在自己最愛的歌裡聽到吉他從鋼琴中分離出來，他們會去告訴朋友。4 軌讓人覺得「不錯」；6 軌讓人覺得「等等，這怎麼可能」。
如果你想在不自己架工具鏈的情況下聽聽 6 軌 htdemucs 在真實音訊上是什麼效果，我們的網站有免費點數可以試幾首歌。
這個領域接下來的發展
幾個值得關注 2026 年的開放問題：
- 8 軌（人聲／和聲／鼓／貝斯／吉他／鋼琴／合成器／其他）會成為標配嗎？ 社群微調正在往這個方向走，但個別合成器與和聲音軌的訓練資料是瓶頸。
- 在消費級硬體上做到即時？ 目前沒有任何開源模型能在 CPU 上以可接受的品質跑到即時速度。模型蒸餾會改變這點，但 2026 年大概還不會。
- 多語言／非西方的人聲分離。 多數已發表的基準由英語流行與搖滾主導。我們在使用不同唱腔的語言上明顯看到較低的表現（華語、大量自動修音的港式流行、寶萊塢的疊聲）。這是這個領域真正的缺口，不是模型部署的問題。
如果你也在這個領域工作、有我們會感興趣的資料——或者你在這些模型上踩到我們還沒踩過的東西——寫信給我們。
參考文獻
- 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 等人，SDX23 結果
- MVSep 模型排行榜 — mvsep.com/en/algorithms
最後更新：2026 年 4 月。如果你發現資料、SDR 數字或任何實務聲明上的錯誤，寄一份更正給我們，我們會在文中註明出處後更新。
作者
分類
更多文章
如何使用 AI Stem Splitter 製作練習用的伴奏帶
一套實用的工作流程，教你做出「除了你的樂器之外什麼都有」的伴奏帶——涵蓋模型選擇（4 軌 vs 6 軌）、人聲／吉他／貝斯／鼓的個別步驟、哪些歌曲分軌效果不佳，以及如何放慢速度練習。
最佳人聲移除器工具比較：我用同一首歌實測了 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.