htdemucs vs BS-RoFormer vs Spleeter : benchmark 2026 de séparation audio

Si vous avez passé un peu de temps sur la séparation de sources audio par IA ces douze derniers mois, vous êtes probablement tombé sur les trois mêmes noms : Spleeter, htdemucs (Hybrid Transformer Demucs) et BS-RoFormer. On les retrouve dans chaque comparatif, chaque article de recherche, chaque tutoriel « comment extraire les voix » — mais la façon dont on les compare est généralement à côté de la plaque. La plupart des articles citent un seul score SDR tiré d'un papier de 2019 et s'arrêtent là.

Ça ne sert à rien quand on essaie de livrer un produit, de construire un pipeline ou de choisir un modèle pour de l'audio réel.

Cet article compare les trois sur les dimensions qui comptent vraiment quand on déploie de la séparation audio en production :

Qualité — scores SDR issus de sources évaluées par les pairs, pas d'impressions
Vitesse d'inférence — ce que vous attendrez réellement en production
Coût par morceau — exécution sur GPU grand public aux prix de 2026
Flexibilité de sortie — 2 stems, 4 stems ou 6 stems
Quand chacun est le bon choix — et quand il ne l'est pas

Tout ce qui suit s'appuie sur des benchmarks publiés et sur notre propre déploiement de htdemucs en production à grande échelle. Quand nous citons des chiffres, nous citons la source.

TL;DR (pour celles et ceux qui veulent la réponse tout de suite)

Modèle	Idéal pour	Stems en sortie	Qualité (SDR moyen)	Vitesse
Spleeter	Temps réel, faibles ressources, traitement par lots	2, 4 ou 5	~5.9 dB (voix)	~100× temps réel sur GPU
htdemucs	Apps C2C en production, équilibre qualité/vitesse	4 ou 6	~9.0 dB (moyenne)	~5–8× temps réel sur A40
BS-RoFormer	Travail offline haute fidélité, mastering, archivage	4 (en général)	~9.80 dB (moyenne)	~2–3× temps réel sur A40

Si vous ne deviez retenir qu'une chose de cet article : htdemucs est le bon choix par défaut pour quasiment n'importe quel produit, et vous devriez probablement faire tourner htdemucs_ft plutôt que le checkpoint par défaut. Sur la facturation serverless de Replicate, les trois variantes Demucs (default, 6s, ft) coûtent essentiellement la même chose par appel — mais ft délivre une séparation nettement meilleure. Nous ne nous y attendions pas au démarrage ; ce n'est devenu évident qu'en regardant notre vraie facture.

BS-RoFormer n'est sensiblement meilleur que sur la basse, et seulement quand la latence n'est pas un sujet. Spleeter est un modèle de 2019 qui tourne sur du matériel de 2026 — rapide, mais l'écart de qualité est désormais audible.

Le reste de l'article explique pourquoi.

Ce qu'on entend par « qualité » — le SDR en bref

La qualité de la séparation de sources musicales est généralement mesurée en Signal-to-Distortion Ratio (SDR), en décibels. Plus c'est élevé, mieux c'est. Le jeu de données de référence est MUSDB18 (ou MUSDB18-HQ pour de l'audio haute qualité), qui contient 150 morceaux en intégralité avec des stems isolés pour les voix, batterie, basse et « other ».

Quelques repères pratiques :

<6 dB SDR : artefacts perceptibles, voix « phasées », fuite audible entre stems
6–8 dB SDR : exploitable pour des usages décontractés (karaoké, apprentissage de morceaux, esquisses d'idées)
8–10 dB SDR : assez propre pour la création de contenu et la plupart des usages DJ
>10 dB SDR : proche de la transparence pour l'auditeur moyen ; convient à du travail prêt à publier après un léger nettoyage

Au-delà de ~9 dB sur la voix, la plupart des auditeurs ne perçoivent plus la différence en test à l'aveugle. Les gains au-delà concernent surtout les cas limites — réverbération forte, voix doublées, mixages complexes.

Une note sur le SI-SDR : certains papiers récents reportent du SI-SDR (SDR invariant à l'échelle), qui corrige les simples différences de gain et est plus robuste. Quand les chiffres de cet article diffèrent d'autres sources, c'est généralement la définition de la métrique qui est en cause.

Les trois modèles, en bref

Spleeter (Deezer, 2019)

Publié par l'équipe de recherche de Deezer en 2019, Spleeter est une architecture U-Net opérant dans le domaine spectrogramme. Il est livré en configurations 2-stems (voix/accompagnement), 4-stems (voix/batterie/basse/other) et 5-stems (ajoute le piano).

C'était une sortie marquante à l'époque — la première fois qu'on pouvait faire tourner une séparation de sources audio assez bonne sur le CPU d'un laptop, sans frais de licence. Six ans plus tard, il a été dépassé en qualité par tous les modèles modernes, mais il reste de très loin l'option la plus rapide et la plus légère.

htdemucs (Meta AI, 2022)

Le modèle Demucs de quatrième génération de l'équipe de recherche de Meta AI. Contrairement à Spleeter, htdemucs est un modèle hybride — il opère à la fois dans le domaine temporel (waveform) et dans le domaine fréquentiel (spectrogramme), avec un backbone Transformer qui les relie. Le papier original reporte une amélioration de 1.4 dB SDR par rapport à la génération Demucs précédente sur MUSDB-HQ.

Deux variantes comptent en pratique :

htdemucs — le modèle 4-stems standard
htdemucs_6s — une variante 6-stems qui ajoute des stems isolés de guitare et de piano

Il existe aussi htdemucs_ft, une version fine-tunée plus lente mais légèrement plus précise sur les stems individuels.

htdemucs s'est bien classé au Sony Music Demixing Challenge 2021 et reste le choix par défaut dans la plupart des pipelines de production qui ne courent pas après le SOTA absolu.

BS-RoFormer (2023)

Actuel état de l'art sur MUSDB18-HQ, BS-RoFormer (Band-Split RoPE Transformer) est une architecture purement Transformer qui remplace les modules RNN par un Transformer hiérarchique avec RoPE. Il découpe le spectrogramme d'entrée en plusieurs sous-bandes fréquentielles non chevauchantes, en exploitant le fait que les différents instruments occupent des plages de fréquences caractéristiques (basse en bas, cymbales en haut, etc.).

BS-RoFormer entraîné sur MUSDB18-HQ plus 500 morceaux supplémentaires a remporté la première place dans la catégorie Music Source Separation du Sound Demixing Challenge 2023 (SDX23). Même la version plus petite entraînée sans données supplémentaires reporte 9.80 dB de SDR moyen sur MUSDB18-HQ.

L'envers de la médaille : il est plus lent et plus gourmand en mémoire que htdemucs, et les poids ouverts prêts pour la production sont encore éparpillés entre des implémentations communautaires plutôt qu'une release canonique unique.

1. Benchmark qualité (scores SDR publiés)

C'est là que la plupart des comparatifs s'écroulent — ils sélectionnent un seul chiffre. Voici les scores SDR par stem issus de la littérature publiée, sur MUSDB18-HQ (sans données d'entraînement supplémentaires sauf indication contraire) :

Modèle	Voix	Batterie	Basse	Other	Moyenne
Spleeter (4-stems)	~5.9 dB	~5.9 dB	~5.5 dB	~4.5 dB	~5.4 dB
htdemucs (default)	~8.1 dB	~8.4 dB	~8.6 dB	~5.9 dB	~7.7 dB
htdemucs_ft (fine-tuné)	~8.9 dB	~9.5 dB	~9.4 dB	~6.4 dB	~8.5 dB
BS-RoFormer (sans données supp.)	—	—	~11.28 dB	—	~9.80 dB
BS-RoFormer (avec 500 morceaux supp.)	—	—	—	—	~9.76 dB+

Sources : scores Spleeter du papier JOSS Spleeter et du benchmark de séparation BeatsToRapOn. Scores htdemucs de Hybrid Spectrogram and Waveform Source Separation et de Benchmarks and leaderboards for sound demixing tasks. Scores BS-RoFormer issus des résultats SDX23 documentés dans le même papier.

Quelques observations sur le tableau :

L'écart Spleeter → htdemucs est plus grand que l'écart htdemucs → BS-RoFormer. Passer de Spleeter à htdemucs vous rapporte environ +2.3 dB en moyenne. Passer de htdemucs à BS-RoFormer vous rapporte environ +1.3 dB. C'est pour cela que htdemucs est le sweet spot pratique pour la majorité des cas d'usage.

Le plus gros gain de BS-RoFormer est sur la basse. La séparation de la basse passe d'environ 8.6 dB (htdemucs) à environ 11.28 dB (BS-RoFormer) — un écart audible en test à l'aveugle. Les gains sur les voix et la batterie sont plus modestes. Si vous construisez quelque chose qui exige spécifiquement une basse propre (outils DJ, transcription, pédagogie musicale pour bassistes), BS-RoFormer mérite la dépense de calcul supplémentaire. Pour le reste, le gain est à la limite du perceptible.

htdemucs_ft est sous-coté. Beaucoup de comparatifs ne testent que le checkpoint htdemucs par défaut. La version fine-tunée (htdemucs_ft) comble la majeure partie de l'écart avec BS-RoFormer au prix d'environ 4× le temps d'inférence — toujours plus rapide que BS-RoFormer en pratique.

2. Vitesse d'inférence (en conditions réelles, pas théoriques)

Temps de bout en bout approximatif pour un morceau de 3 minutes sur un seul GPU A40, mesuré de l'appel API à la sortie téléchargeable :

Modèle	Temps de bout en bout	Multiplicateur temps réel
Spleeter (4-stems, GPU)	~2–5 secondes	~40–90× temps réel
htdemucs (default, 4-stems)	~30–45 secondes	~4–6× temps réel
htdemucs_6s (6-stems)	~40–60 secondes	~3–5× temps réel
htdemucs_ft (fine-tuné)	~90–150 secondes	~1.2–2× temps réel
BS-RoFormer	~60–120 secondes	~1.5–3× temps réel

Notes :

Temps de bout en bout ≠ temps d'inférence GPU pur. Les benchmarks publics ne reportent en général que le forward pass du modèle sur des entrées propres. Le temps réel en production inclut le cold start du conteneur (5–30s en serverless), les I/O audio (téléchargement du fichier, pré-traitement ffmpeg) et l'upload du résultat. Nos chiffres ci-dessus sont mesurés de bout en bout sur Replicate.
Spleeter joue dans une autre catégorie côté vitesse. C'est le seul à tourner confortablement plus vite que le temps réel sur CPU seul.
Le paramètre overlap de htdemucs est un gros levier de vitesse. La valeur par défaut overlap=0.25 est un compromis raisonnable ; passer à overlap=0.5 améliore légèrement la qualité pour ~2× le coût ; passer à overlap=0 rend l'inférence nettement plus rapide mais introduit des artefacts de découpage audibles aux frontières des segments.
Les implémentations de référence de BS-RoFormer varient énormément en vitesse selon le checkpoint et le code d'inférence utilisés. Les chiffres ci-dessus correspondent au build BS-RoFormer SW populaire dans la communauté MVSep.

Si vous livrez un produit grand public où l'utilisateur attend les résultats, tout ce qui dépasse ~60 secondes pour un morceau de 3 minutes commence à plomber la conversion, d'après notre expérience. Cela maintient htdemucs (default et 6s) dans une zone acceptable et pousse htdemucs_ft et BS-RoFormer vers des flux asynchrones / en file d'attente où l'utilisateur peut revenir plus tard.

3. Coût par morceau (économie d'un déploiement en production)

C'est la section où la plupart des comparatifs en ligne se trompent complètement. Le tarif public de Replicate semble simple — A40 à $0.000725/seconde, multiplié par le temps d'inférence, c'est plié. En pratique, ce calcul est faux d'un facteur ~2× par rapport à votre vraie facture, et il y a un détail plus intéressant que presque aucun comparatif ne mentionne.

Le constat principal de notre déploiement en production

Nous faisons tourner htdemucs en production sur aistemsplitter.org depuis plusieurs mois sur les trois variantes Demucs — htdemucs (4-stems par défaut), htdemucs_6s (6-stems) et htdemucs_ft (fine-tuné). Sur les instances GPU A40 de Replicate, les trois variantes coûtent à peu près la même chose par appel sur notre vraie facture : environ 22 appels par $1, soit $0.045 par morceau environ.

Cela mérite une pause, parce que ça contredit ce qu'on attendrait au vu des temps d'inférence publiés.

Modèle	Coût naïf (tarif public × temps d'inférence)	Notre coût mesuré réel
Spleeter (GPU)	<$0.002	<$0.005
htdemucs (default)	~$0.022	~$0.045
htdemucs_6s (6-stems)	~$0.029	~$0.045
htdemucs_ft (fine-tuné)	~$0.11	~$0.045
BS-RoFormer	~$0.065	~$0.06–0.10 (variable)

Pourquoi les trois variantes Demucs convergent vers le même coût

Le modèle de tarification naïf suppose qu'on ne paie que le temps d'inférence GPU pur. En réalité, chaque appel Replicate inclut aussi :

Le cold start du conteneur (5–30 secondes quand on remonte depuis zéro)
Le chargement des poids du modèle en mémoire GPU
Le téléchargement du fichier audio et le pré-traitement ffmpeg
L'encodage du résultat et l'upload vers le stockage
Une durée minimale facturable par appel

Ces overheads sont grosso modo des coûts fixes par invocation — ils n'augmentent pas avec la complexité du modèle. Quand le forward GPU passe de 30 secondes (htdemucs default) à 90 secondes (htdemucs_ft), le calcul supplémentaire pèse moins lourd sur la facture qu'on ne s'y attendrait, parce que l'overhead par appel mange déjà la majeure partie du budget.

Implication pratique : si vous êtes déjà sur la plateforme htdemucs, il n'y a quasiment aucune raison économique de ne pas utiliser la variante de plus haute qualité que votre budget de latence permet. Si vos utilisateurs attendent 60 secondes, utilisez htdemucs_6s (6 stems, vitesse standard). S'ils attendent 2 minutes, utilisez htdemucs_ft (fine-tuné, qualité proche de BS-RoFormer sur la plupart des stems). La facture est la même.

C'est le contraire de la conclusion qu'on tirerait en lisant les papiers académiques et la grille tarifaire GPU affichée par Replicate. Ça ne se voit qu'une fois la facture du mois sous les yeux.

Implications pour l'unit economics

Si vous modélisez l'unit economics d'un produit de séparation de stems, prévoyez $0.04–$0.05 par morceau comme plancher, quelle que soit la variante Demucs choisie. Cela fixe :

Le plafond du free tier — à 10 minutes gratuites par utilisateur (≈3 morceaux gratuits), vous absorbez environ $0.13 par inscription avant toute conversion
Le tarif minimum viable d'un pack de crédits — tout ce qui descend en-dessous d'environ $0.10/morceau au détail ne laisse pas de marge pour les frais Stripe, le support et l'overhead infrastructure
Le coût de traitement en masse — à 10 000 morceaux/mois, vous êtes sur ~$450 d'inférence pure, avant stockage, bande passante et tout le reste

Deux mises en garde importantes :

Les cold starts dominent à faible trafic. Si votre service traite moins de quelques centaines de morceaux par jour, l'overhead de cold start devient proportionnellement plus lourd. À très faible trafic, le coût réel peut grimper vers $0.06–$0.07 par morceau.
Le self-hosting ne devient compétitif qu'au-delà d'environ $2k/mois en dépense d'inférence. Tant que vous n'avez pas assez de trafic soutenu pour garder un GPU dédié à >40 % d'utilisation, le GPU serverless est moins cher que RunPod, Vast.ai ou votre propre colo. Nous l'avons mesuré directement — Replicate est resté moins cher que de l'infrastructure dédiée pendant toute notre période de lancement.

4. Flexibilité de sortie (nombre de stems et format)

Modèle	Configurations de stems disponibles	Notes
Spleeter	2, 4 ou 5 stems	Le 5-stems ajoute le piano (modèle séparé)
htdemucs	4 ou 6 stems	`htdemucs_6s` ajoute guitare + piano
BS-RoFormer	4 stems (le plus souvent) ; quelques builds 6-stems communautaires	La qualité chute sur les stems plus rares guitare/piano

C'est là que htdemucs_6s est vraiment seul dans sa catégorie. Si votre cas d'usage exige des stems isolés de guitare ou de piano (pédagogie musicale, remix multipiste, transcription), htdemucs_6s est le seul modèle largement déployé qui les fournit avec une qualité de production. Des variantes BS-RoFormer 6-stems existent dans la communauté mais sont moins matures ; le BS-RoFormer canonique est un système 4-stems.

Pour les cas d'usage « voix uniquement » ou « instrumental uniquement » (la foule du karaoké), les trois modèles font le job, et il faut choisir sur la vitesse, pas la qualité. Spleeter à 90× le temps réel vous donnera un instrumental utilisable en quelques millisecondes.

5. Quand choisir lequel

Après plusieurs mois à les faire tourner en production, voici l'arbre de décision simple que nous donnerions à quelqu'un qui démarre de zéro :

Choisissez Spleeter quand :

Vous devez traiter de l'audio en temps réel ou quasi temps réel
Vous tournez sur CPU ou sur du matériel contraint
Vous avez besoin de débit en traitement par lots (par exemple, extraction de features sur un catalogue musical)
L'exigence de qualité est « exploitable », pas « bonne »

Choisissez htdemucs quand :

Vous construisez un produit grand public où les utilisateurs attendent <60 secondes
Vous avez besoin de 6 stems (utilisez htdemucs_6s)
Vous voulez le meilleur rapport qualité/euro en production
Vous ne voulez pas maintenir de code d'inférence sur mesure (il est bien supporté sur toutes les grandes plateformes de model-serving)

Choisissez BS-RoFormer quand :

Vous tournez en offline ou en batch où 1–2 minutes par morceau sont acceptables
La qualité de la basse compte spécifiquement (outils DJ, transcription, analyse audio)
Vous produisez du travail prêt à publier et le SDR marginal a de l'importance
Vous êtes prêt à investir du temps d'ingénierie pour suivre les sorties de modèles communautaires

Ne choisissez aucun de ces modèles quand :

Vous avez seulement besoin d'un suppresseur de voix pour le karaoké. Utilisez Spleeter 2-stems ; la différence de qualité ne compte pas pour de l'audio chanté qui sortira par un micro.
Vous avez besoin de séparation de stems en temps réel dans une application DJ. Aucun de ces modèles n'est temps réel sur du matériel grand public. Utilisez un DAW avec séparation temps réel intégrée (Ableton 12, etc.) ou pré-traitez les pistes hors ligne.

À quoi ça ressemble en pratique

Nous faisons tourner htdemucs_6s en production sur aistemsplitter.org — une version hébergée de la séparation 6-stems destinée à celles et ceux qui ne veulent pas monter la toolchain locale (ce qui, entre les versions de PyTorch, les versions de CUDA et l'enfer des dépendances audio, prend un après-midi entier à la plupart des gens).

Quelques choses apprises sur le terrain qui ne sont pas dans les papiers :

Le coût de production réel est environ 2× ce que les calculs naïfs suggèrent, et à peu près plat entre les variantes Demucs. Le tarif GPU public × le temps d'inférence vous donne un chiffre qui ignore l'overhead plateforme. Notre vraie facture Replicate revient à environ $0.045 par morceau — et c'est le même chiffre qu'on fasse tourner htdemucs, htdemucs_6s ou htdemucs_ft. L'overhead fixe par appel noie la différence de calcul marginal entre modèles. Ce seul fait a changé notre façon d'aborder le choix de modèle : choisissez sur la qualité, pas sur le coût de calcul théorique, parce que la différence de coût ne se manifeste pas réellement sur la facture.
La conversion de format compte plus que le modèle. htdemucs n'accepte que du WAV en entrée. Les utilisateurs uploadent du MP3, du FLAC, du M4A, de l'OGG, et de plus en plus de conteneurs WebM bizarres. La couche de pré-traitement ffmpeg n'est pas triviale à bien faire à grande échelle.
L'ingestion d'URLs YouTube/SoundCloud est la moitié du gain UX. Demander aux utilisateurs de télécharger un fichier puis de l'uploader en perd ~40 %. L'ingestion directe par URL via yt-dlp est pénible à maintenir (vidéos avec restriction d'âge, blocages géographiques, livestreams) mais ça vaut le coup.
Le cas 6-stems, c'est là où les utilisateurs voient la magie. Quand quelqu'un entend pour la première fois la guitare isolée du piano sur son morceau préféré, il en parle à ses amis. Le cas 4-stems est « sympa » ; le cas 6-stems, c'est « attends, c'est possible ça ? ».

Si vous voulez entendre ce que donne htdemucs 6-stems sur du vrai audio sans monter la toolchain, notre site offre des crédits gratuits pour essayer quelques morceaux.

La suite, dans ce domaine

Quelques questions ouvertes à surveiller en 2026 :

Le 8-stems (voix/chœurs/batterie/basse/guitare/piano/synthé/other) va-t-il devenir standard ? Les fine-tunes communautaires vont dans ce sens, mais les données d'entraînement pour les stems individuels de synthé et de chœurs sont le goulet d'étranglement.
Du temps réel sur du matériel grand public ? Aucun modèle ouvert actuel ne tourne en temps réel sur un CPU avec une qualité acceptable. Cela changera avec la distillation de modèles, mais probablement pas en 2026.
Séparation vocale multilingue / non-occidentale. La plupart des benchmarks publiés sont dominés par la pop et le rock anglophones. Nous observons des performances notablement plus faibles sur des langues avec des techniques vocales différentes (mandarin, cantopop avec auto-tune massif, empilements vocaux Bollywood). C'est un vrai trou dans le domaine, pas un problème de déploiement de modèle.

Si vous bossez dans cet espace et avez des données qui pourraient nous intéresser — ou si vous êtes tombé sur quelque chose à propos de ces modèles que nous n'avons pas vu — écrivez-nous.

Références

htdemucs — Rouard, S., Massa, F., Défossez, A. Hybrid Transformers for Music Source Separation. arXiv:2211.08553
Demucs v4 (hybride) — 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. Résultats du Challenge SDX23
Spleeter — Hennequin, R., Khlif, A., Voituret, F., Moussallam, M. Spleeter: a fast and efficient music source separation tool with pre-trained models. JOSS 2020
Jeu de données 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., résultats SDX23
Classement des modèles MVSep — mvsep.com/en/algorithms

Mis à jour : avril 2026. Si vous repérez une erreur dans les données, les chiffres SDR ou l'une des affirmations pratiques, envoyez-nous une correction et nous mettrons l'article à jour avec attribution.