想把「上传音频 → 人声分离 → 变音 → 合回伴奏」做成一个接口，第一步就撞墙了。

现象

demucs 跑到一半，systemd 直接把服务杀掉：

Out of memory: Killed process (python) total-vm: ... anon-rss:3.4G

机器总共 1.9GB，加上 swap 也不够。而且被杀之后任务状态停在「处理中」，前端一直转圈。

关键参数是 –segment

htdemucs 默认按较长片段推理，内存占用随片段长度上升。把它压到模型训练时的上限：

demucs --two-stems=vocals --segment 7 -n htdemucs input.wav

峰值从 3.4GB 降到约 2.7GB。

注意两个细节：

• --segment 必须是整数，写 7.5 会直接报错。
• htdemucs 训练时最长就是 7.8 秒，超过它不会更准，只会更吃内存。

还有两个内存大户

参考音频的 index 文件。RVC 的 .index 动辄 400MB，加载进去就占满了。如果只是做变音、不追求极致相似度，超过 200MB 的直接跳过。

输入不截断。上传一首 10 分钟的播客，前面所有优化都白费。加一条硬限制：超过 4 分钟先截断再处理。

超时也要分开配

一开始只有一个超时值，结果 RVC 阶段被误杀。实际耗时差得很远：

| 阶段 | 一首 190 秒的歌 | |—|—| | demucs 分离 | 约 5 分钟 | | RVC 变音 | 约 15 分钟 |

所以：

AUDIO_TIMEOUT = 1500   # demucs
RVC_TIMEOUT   = 3300   # RVC

前端轮询的超时也要对齐，否则后端还在跑，前端已经放弃了。

结果

• 3 秒的音频：约 1.5 分钟
• 190 秒的歌：约 20 分钟
• 237 秒的歌：demucs 6 分钟 + RVC 16 分钟

CPU 推理大概是 4 倍实时，能接受。真要快还是得上显卡。

教训：在小内存机器上跑深度学习，先用 --segment 和输入长度把峰值摁住，再谈效果。