Un problème de signal avant d'être un problème de modèle
Extraire les stems d'un morceau - isoler la voix, la batterie, la basse, le reste - revient à défaire une somme. Le mixage a additionné des sources ; il s'agit de retrouver les termes à partir du seul résultat. Rien ne garantit que la décomposition soit unique, et c'est précisément ce qui rend le problème intéressant.
La matière première ne s'y prête pas naturellement. Une minute d'audio en qualité CD, c'est plus de deux millions et demi d'échantillons par canal : une séquence trop longue et trop peu structurée pour être présentée telle quelle à un réseau.
Passer par le spectre
L'analyse spectrale règle ce problème de représentation. La transformée de Fourier à court terme découpe le signal en fenêtres qui se chevauchent et donne, pour chacune, la répartition de l'énergie par fréquence. On obtient une image - un spectrogramme - où le temps est en abscisse, la fréquence en ordonnée et l'intensité en valeur.
Ce changement de représentation a une conséquence directe : les sources deviennent visuellement séparables. Une voix, une caisse claire et une ligne de basse n'occupent ni les mêmes bandes ni les mêmes motifs temporels. Le problème de séparation redevient un problème de masquage, sur lequel les architectures convolutives sont à leur aise.
Le réglage de la fenêtre est un arbitrage qu'on ne peut pas esquiver : une fenêtre longue donne une résolution fréquentielle fine mais floute les transitoires ; une fenêtre courte fait l'inverse. Les percussions et les nappes harmoniques ne demandent pas le même compromis.
Normaliser avant d'inférer
Les fichiers qui entrent dans le pipeline n'ont rien en commun : fréquences d'échantillonnage différentes, mono ou stéréo, niveaux qui vont du master compressé à la maquette enregistrée trop bas. Un modèle entraîné sur des entrées calibrées se dégrade dès que cette calibration n'est plus respectée.
Le prétraitement remet donc tout à plat - rééchantillonnage, gestion des canaux, normalisation du niveau - avant tout découpage. C'est la partie la moins spectaculaire du pipeline, et celle dont dépend la reproductibilité des résultats.
Servir l'inférence
Le modèle retenu est BS-Roformer, un transformer qui découpe le spectre en bandes et applique l'attention à l'intérieur de chacune : il exploite exactement la structure fréquentielle décrite plus haut. Un spectrogramme est un tenseur dense et la séparation de sources est un calcul lourd, donc le GPU n'est pas une optimisation mais la condition pour rester sous un temps de réponse acceptable.
L'orchestration serverless répond à un autre problème : la charge est intermittente. Des pics quand des fichiers arrivent, rien entre deux. Un GPU réservé en permanence coûterait cher à ne rien faire. L'inférence tourne donc sur des workers RunPod dimensionnés à la demande, zéro worker actif au repos, trois au maximum, cinq secondes d'inactivité avant extinction. Le coût suit le traitement réel, au prix d'un démarrage à froid qu'il faut contenir.
Le reste de la chaîne est découplé pour la même raison : l'API valide et dépose le fichier, un worker séparé prend les tâches en attente et appelle le GPU, les stems repartent vers le stockage. Aucun composant n'attend un autre en tenant une connexion ouverte, ce qui rend les pics absorbables.
Ce que j'en retiens
Sur une chaîne de ce type, le modèle est rarement le goulot d'étranglement. Ce sont les entrées-sorties, la préparation du signal et la façon dont on découpe le travail qui décident du temps de réponse réel.
Et le choix de la représentation reste la décision la plus structurante du projet : tout ce qui vient après - architecture, découpage, post-traitement - en découle.