README.md

metadata

title: RVC 翻唱工作站
emoji: 🎤
colorFrom: purple
colorTo: indigo
sdk: gradio
sdk_version: 6.26.0
python_version: '3.10'
app_file: app.py
pinned: false
license: mit
short_description: PyMSS 三板斧分离 + RVC 变声翻唱
hardware: zero-a10g

RVC 翻唱工作站（PyMSS 分离 + RVC 变声，ZeroGPU）

上传一首歌，自动完成「人声分离 → 去混响 → RVC 变声 → 成品混音」，输出 5 路音频。

工作流

步骤	模型	输入来源	输出音轨
1	big_beta6x	原始输入	vocals / other(伴奏)
2	mel_band_karaoke_fusion_standard	步骤1 vocals	Vocals / Instrumental(和声)
3	dereverb_mel_band_roformer_anvuew_sdr_19.1729	步骤2 Vocals	noreverb / reverb

• noreverb → RVC 变声，作为主人声
• Instrumental → 和声，默认原样混入；可选「和声处理」也过 RVC；可选「移除和声」整条丢弃

页面输出（5 个音频框）

1. 伴奏（other）
2. 变声后的主人声（noreverb）
3. 和声（Instrumental，可能已被 RVC 处理；勾选「移除和声」时为空）
4. 混响（reverb）
5. 合并成品 = ①+②+③+④，对齐时长叠加后做峰值归一化

两个选项默认都不勾选：移除和声、和声处理。

部署步骤

1. 创建 Space

• SDK 选 Gradio，硬件在 Settings → Space Hardware 里选 ZeroGPU （README 里已写 hardware: zero-a10g，这是 ZeroGPU 的标识符）
• 建议设为 Private，因为要往里配私有音色的读取权限

2. 分离模型：什么都不用传

Space 仓库的 Git/LFS 存储上限只有约 1 GB（那个「50 GB」是运行时的临时磁盘，不是仓库），所以三个分离模型（合计约 3.3 GB）不可能塞进仓库。

app.py 会在启动时用 snapshot_download 从 pymss 官方仓库 baicai1145/pymss 拉取到容器临时盘 /tmp/pymss_models，再交给 pymss 加载。这些是公开模型，不需要任何 token。

想换模型（比如换更小的 big_beta7，约 0.9 GB，能明显缩短冷启动），改 config.yaml 里对应的 ckpt / config 相对路径即可，路径以官方仓库里的实际结构为准。

3. 配置两个私有 RVC 音色

编辑 config.yaml，把 voices 里的 repo_id 换成你的私有模型仓库：

voices:
  - id: voice_a
    label: 音色 A
    repo_id: your-name/my-voice-a
    model_file: model.pth
    index_file: model.index
  - id: voice_b
    label: 音色 B
    repo_id: your-name/my-voice-b
    model_file: model.pth
    index_file: model.index

然后在 Space 的 Settings → Variables and secrets 里添加 Secret：

• HF_TOKEN = 有权读取这两个私有仓库的 Hugging Face Access Token

（Private Space 会自动注入一个 HF_TOKEN，但它只有本条 Space 仓库的权限；音色放在别的私有仓库时，需要手动加一个有读权限的覆盖掉。）

音色同样下载到容器临时盘 /tmp/pymss_models/rvc/，不会进仓库。

4. 常见需要调的参数

config.yaml → runtime：

字段	默认	说明
output_sr	44100	输出采样率（三个分离模型都是 44100）
gpu_declared_seconds	60	固定声明给 @spaces.GPU 的秒数，实际预占 = 该值 × gpu_duration_factor（= 90s）。它同时是运行时限，长音频要往上调
gpu_duration_factor	1.5	ZeroGPU 硬件系数（spaces/zero/configs.json），换硬件时会变
mix_peak	0.97	合并轨峰值归一化目标
pitch_algo	rmvpe+	音高提取算法，rmvpe+ 质量最好
model_cache_dir	/tmp/pymss_models	分离模型 + 音色下载缓存（临时盘）
work_dir	/tmp/rvc_cover	每次请求的中间文件目录，1 小时后自动清理

注意事项

• Python 版本必须是 3.10，别改：infer_rvc_python 依赖的 faiss-cpu（以及 1.3.x 的 pyworld）在 Python 3.12 上没有任何可用 wheel，pip 会直接 ResolutionImpossible。原因和版本对应关系写在 requirements.txt 顶部。
• infer_rvc_python 是 vendored 的，不在 requirements.txt 里：它死锁 torchcrepe==0.0.20 → librosa==0.9.1，而 pymss 要求 librosa>=0.10.2，两者不相容、pip 无解。所以整个包放在 vendor/infer_rvc_python/，由 app.py 用 sys.path 引入，它的运行期依赖在 requirements.txt 里显式列出。**别把 vendor/ 加进 .gitignore，也别再往 requirements.txt 里写 infer_rvc_python**。
• 构建阶段要现编译 pyworld：Linux 上 pyworld 官方没有 wheel（只有 Windows wheel + sdist），只能从源码编译（需要 gcc / Cython），所以首次构建会稍慢，这一步报错就是编译环境问题。
• 冷启动会下载约 3.3 GB 模型：容器临时盘每次重启都会被清空，Space 睡醒后会重新下载，第一次访问会慢几分钟。介意的话可以在 Space 设置里加购 persistent storage，或把 vocal_split 换成体积更小的模型。
• ZeroGPU 的额度按「实际耗时」扣，不是按声明值扣。实测：204.1s 音频实际耗时约 38~40s，配额计量显示 0.7/5 min（≈42s）；多次测量基本与音频长度成固定比例，约 0.19 秒 GPU 时间 / 秒音频，跟音频是无损还是低品质无关（解码开销相比模型推理可忽略）。
• 但调度门槛按「声明值」预检查：剩余配额 < 声明值 × 硬件系数 会直接被拒（quota exceeded），与实际跑多久无关。所以声明值固定在 60（→ 预占 90s）最省事。
• 硬件系数 1.5：SDK 把声明值乘上硬件系数再交给调度器（spaces/zero/configs.json 里 RTX PRO 6000 Blackwell = 1.5，H200 = 1.0）；这个系数同时也是函数真正可用的运行时间 —— 声明 60 意味着约 90s 跑道。
• 声明值同时是运行时限，别为省额度调太小：一旦实际跑超，ZeroGPU 会 abort 任务（GPU task aborted），配额照样扣、结果也拿不到。60（90s 跑道）按实测速度够跑约 7 分钟以内的音频；更长的歌按 0.19s / 秒音频 往上调 gpu_declared_seconds。
• 首次调用偏慢：RVC 音色模型是在第一次请求时才真正加载进显存的（infer_rvc_python 的惰性加载），之后会复用。
• 并发：页面请求会串行执行（内部有锁），避免多个任务互抢显存和中间文件。
• 仅供学习与研究使用，请勿用于侵权或未授权的声音克隆。