之前自己练琴想扒一首歌的贝斯线，市面上的工具要么只能分 4 轨
（ vocals/drums/bass/other ），要么订阅一个月用两次就忘了取消。
看到 Meta AI 的 htdemucs_6s 模型能分 6 轨（多了 guitar 和 piano ），
就花了几个月做了个站。
技术上踩了一些坑，分享出来给可能也想做类似东西的同学参考。
一、模型选型:为什么是 htdemucs
主流开源音频分离模型:
对比测了 spleeter / htdemucs / BS-RoFormer:
对面向 C 端的服务来说，60 秒出结果 vs 3 分钟出结果差别太大
如果是离线批处理或专业制作，BS-RoFormer 应该是更好的选择。
二、推理平台:为什么是 Replicate
最早自己开了 RunPod 4090 实例跑，跑通没问题，但有几个问题:
[ol]
[/ol]
后来转去 Replicate ，按秒计费，没人用就 0 成本。
htdemucs 一首 3 分钟的歌大概 25-40 秒推理时间，
按 A40 GPU 计费下来单首 GPU 成本大概 2-3 美分。
对于一个早期阶段、流量不稳定的产品，按需付费比固定 GPU 划算太多。
对比过的几家:
三、几个非模型层面的坑
[ol]
YouTube 链接处理:用户贴 URL 比让他下载文件转格式 UX 好太多。
yt-dlp 是必备，但要处理大量 edge case （年龄限制、地区限制、live 流），
还得加超时和文件大小限制防滥用。
多轨同步播放器:6 个 stem 同时播放还要支持 mute/solo/seek ，
一开始用 howler.js 单实例切换完全不行（ latency 差几十 ms 听得出来），
最后用 Web Audio API 自己写了个共享 AudioContext 的播放器。
格式转换:用户上传可能是 MP3/WAV/FLAC/M4A/OGG/WEBM 各种格式，
htdemucs 只吃 WAV 。前置 ffmpeg 转码层是必须的，
但 ffmpeg 在 Replicate 容器里跑得慢，
后来改成在自己服务器转码完再丢给 Replicate ，整体延迟降了 30%。
BPM/key 检测:用 librosa 自己算的，但 librosa 的 key detection
在电子乐上准确率一般，准备后续接入 essentia 重做。
[/ol]
四、成品
站点:aistemsplitter.org
有免费额度，够分两三首歌看看质量。如果想多跑几首，
V2EX 的同学可以在结账页用 v2ex 这个码，我加了点额度——主要是
想多收一些技术圈的反馈，特别是中文歌的分离效果。
主要想问几个问题:
[ol]
(需要支持自定义模型权重)
有没有什么改进思路?是该等更好的开源模型,还是有
预处理/后处理的方法可以缓解?
[/ol]
谢谢各位,欢迎拍砖。
