Demucs量化模型怎么选：mdx_q与mdx_extra_q的差异全解析

【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs

先讲个常见画面：你是一个做播客剪辑的自由创作者，电脑是几年前的老款笔记本，风扇一响就心里一紧。你把一首三分钟的歌拖进 Demucs，想把人声和伴奏分开，结果等了几分钟，内存条都冒汗了。这时候你听人说，Demucs 有量化模型，体积小速度快，但又有 mdx_q 和 mdx_extra_q 两个名字——到底该下哪个？

这个问题其实不用看一堆跑分就能回答，因为它藏在两个配置文件里。我们把项目源码翻出来，一步步拆给你看。

第一步：别急着跑测试，先读这两个配置文件

Demucs 的模型在 demucs/remote/ 目录下以 YAML 文件的方式"打包"，一个文件就是一整套可下载的模型组合。打开两个主角，内容出乎意料地短：

# demucs/remote/mdx_q.yaml models: ['6b9c2ca1', 'b72baf4e', '42e558d4', '305bc58f'] weights: [ [1., 1., 0., 0.], [0., 1., 0., 0.], [1., 0., 1., 1.], [1., 0., 1., 1.], ] segment: 44

# demucs/remote/mdx_extra_q.yaml models: ['83fc094f', '464b36d7', '14fc6a69', '7fd6ef75'] segment: 44

看到关键差异了吗？两个文件都是四个模型（models 列表里的哈希值就是四个独立模型的"身份证号"），segment: 44也相同，表示每 44 秒切一段处理。唯一的区别，是 mdx_q 多了一个 weights 权重矩阵，而 mdx_extra_q 没有。

这就要说到 Demucs 的一个核心机制——Bag of Models（模型包）。名字听着唬人，其实就像乐队的四个乐手一起合奏：每个模型各自给出分离结果，最后按权重"投票"合成最终输出。读取逻辑在 demucs/repo.py 的BagOnlyRepo类里，YAML 里有 weights 就走加权投票，没有就四个结果简单平均。

mdx_q 的权重矩阵是 4 行 4 列，意思是不同声源（鼓、贝斯、其他、人声）可以用不同的"乐手组合"。比如第一行[1., 1., 0., 0.]，就是分离某一类声源时只信前两个模型；而 mdx_extra_q 让四个模型在所有声源上平分话语权。换句话说，mdx_q 更像一个"按声源找专家"的组合，mdx_extra_q 更像"四个全能的家伙一起干"。

第二步：搞懂量化，为什么文件能瘦到三分之一

既然名字里都有_q，就绕不开量化。普通模型用 32 位浮点数（FP32）存权重，你可以把它想象成一张用超高精度保存的照片。量化就是把它转成 8 位整数（INT8）——相当于把照片存成 JPEG，肉眼几乎看不出差别，但文件大小直接缩水。

Demucs 用的量化工具是 DiffQ，相关代码在 demucs/states.py 的get_quantizer里。它有两种玩法：DiffQuantizer在训练时就把压缩考虑进去（训练感知量化），UniformQuantizer则用指定的 bit 数（比如 8 bit）均匀量化。配置文件里那串哈希签名，指向的正是量化后的成品。

量化带来两个直接好处：

• 模型体积大幅缩小：一个基础 mdx 模型的完整权重大约在 300MB 以上，量化后通常能压到 100MB 以内，下载和加载都快得多。
• 内存占用成倍下降：推理时权重不再需要以 FP32 常驻内存，对低内存设备非常友好。

代价呢？量化毕竟是有损压缩，分离质量会有一点点回落，尤其是贝斯、鼓这类低频瞬态丰富的声源，损失会比人声略明显。但好消息是，这个回落通常控制在可接受范围内，人耳在大多数素材上未必听得出差异。

第三步：你的场景，决定了该选谁

与其纠结"哪个更好"，不如问"哪个更适合我"。下面这张决策图帮你快速定位：

具体来说：

选 mdx_q 的场景：直播伴唱分离、会议降噪、手机或嵌入式设备上的实时处理。它用"按声源分配专家"的策略，推理更快、内存更省，在低端机器上体验差距尤其明显。命令一行搞定：

python -m demucs.separate --model mdx_q input.mp3

选 mdx_extra_q 的场景：录播后期、音乐制作、对分离干净度有要求的离线处理。四个模型等权平均的"全员参与"模式，在复杂混音下通常给出更稳定的结果。想要质量再进一步，可以叠加多次位移求平均的--shifts参数：

python -m demucs.separate --model mdx_extra_q --shifts 3 input.wav

小提示：--shifts会对音频做微小时移后再分离并平均，能改善边界质量，但代价是计算时间成倍增加，属于"用时间换精度"的招数。

第四步：想自己验证？项目里有现成的工具

如果你不想凭感觉选，项目提供了 tools/test_pretrained.py 这类工具，可以拿你自己的音频样本批量测试不同模型的分离结果，对比输出文件的实际听感。参考 docs/mdx.md 还能了解官方在 MDX 挑战赛上的评估口径——注意里面提到，导出模型时加--half用半精度保存，体积减半且几乎不影响指标，这也是很多轻量部署的默认姿势。

另外要提醒一句：在get_model_from_args的逻辑里，项目默认模型早已换成更现代的 htdemucs，想要回到经典量化模型，才需要显式指定-n mdx_extra_q。所以你现在知道，那句"回到旧默认"指的就是它。

最后的结论：别纠结，按场景对号入座

一句话收尾：要速度选 mdx_q，要质感选 mdx_extra_q。

• 资源紧张、追求实时反馈 → mdx_q，它把四个模型按声源动态加权，快且省。
• 机器尚可、追求稳定输出 → mdx_extra_q，四个模型平等协作，复杂素材下更稳。
• 两者差距并没有天壤之别，真正影响体验的往往是segment段长和--shifts这类处理参数，建议先用你的真实素材各跑一遍再定。

展望一下，随着 DiffQ 这类量化训练技术继续成熟（可以顺着 demucs/states.py 里的实现往下挖），未来的模型压缩会越来越"无感"——可能某天你会发现，默认模型本身就是量化过的，选型纠结也就彻底不存在了。

【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs