8 家降噪算法横评总评：谁在什么场景下最强？

本系列前面几篇讲完了 8 家降噪算法的原理、代码和 5 case 定性观感，本篇把它们放到同一批 332 条音频上做统一 STOI + DNSMOS 评测，从性价比、场景敏感度、有参 / 无参一致性等多角度看真实分层。

8 家一览：

一、评测口径

数据集（332 条 · 全部走同一批 · 对齐可比）：

评测维度：

推理硬件：RTX 4090D 24 GB · torch 2.1.2 + CUDA 12.1 · Ubuntu 22.04 · Python 3.11

二、综合质量排名 · 谁最”性价比”？

8 家按 4 数据集 DNSMOS OVR 均值降序排 · 每条柱右侧标算法名、综合均值和参数量 · 红虚线是原始 noisy 均值 2.37。

读图三句话： -MP-SENet 2.1 M 直接顶到最高 3.83· 参数量最小拿分最高的档 -SGMSE+ 65 M 综合排第 2（3.76）—— 生成式路线在白噪场景 3.77 反超 MP-SENet（3.61），但整体被 diffusion 多步采样拖慢算力成本（30 步 × 单步 U-Net 前向） -htdemucs 41 M 反而垫底 2.96—— 分离征用路线在 babble 场景直接崩

三、5 维雷达 · 每家的能力形状

每张子图 5 维：STOI（场景细分集） + DNSMOS OVR × 4 数据集。面积越大越强。轴范围统一 STOI [0.8, 1.0] · OVR [1.5, 4.2]。

分层观察： -满饱和五边形：MP-SENet—— 5 维都到 0.7+ · 全场景最均衡 -面积大但有偏斜：FRCRN—— 场景细分 / 白噪 / 咖啡厅都强 · 但 car 只 3.79 · 部分维度不占优 -面积大但 STOI 一角短一截：SGMSE+—— 4 个 DNSMOS 维度都饱满（0.7+）· 但 STOI 归一后约 0.67 · 生成式路线特点 -规则但偏小：DFN3 / Meta denoiser · 整体稳定 · white / cafe 中档 · car 维度较强 · 但综合不拔尖 -偏斜：FullSubNet+整体缩水一圈 · 尤其 white / cafe 只到 0.55 · 说明它对稳态白噪和 babble 都相对弱 -一角塌陷：htdemucs 的 cafe 顶点几乎缩到中心—— babble 场景 vocals 分支分不出目标说话人 vs 干扰说话人

四、noisy → 降噪后 · 每家 4 数据集的提升距离

每家一行 · 每子图从灰色 baseline 端点延伸到彩色端点 · 线越长提升越大 · 红色数值表示低于 baseline（降噪反而变差）。

读图观察： -咖啡厅 babble 场景 · htdemucs 独一份反向（2.17 → 2.15 · 红字标出）—— 分离征用路线在 babble 场景直接崩，vocals 分支把干扰说话人也保留下来 -白噪场景 · SGMSE+ 3.77 断层第一—— 稳态噪声正好是 diffusion 生成式路线的主场（噪声成分单一 · 生成任务简单） -咖啡厅场景 · MP-SENet 3.81 顶掉 SGMSE+ 3.68—— babble 场景反而判别式方法更稳（生成式在多说话人混叠时可能生成”合理但非目标”的语音） -车内场景（baseline 3.17）· 8 家提升幅度最小（0.4-0.9 分）· 底子好、SE 效果打折 -场景细分集· 提升幅度最分散 · 因为 16 种噪声本身混合了稳态 / 瞬态 / 混响 / babble · 各家在不同 case 上表现不一

8 家在 cafe 拉出的 1.66 分差距是全表最大跨度 · 说明 babble 是最能区分算法上下限的场景。

五、STOI vs DNSMOS · 有参无参一致吗？

左右两列都按 DNSMOS OVR 从大到小排 · 看 STOI 是否也是同样顺序 · 排序错位 = 两个指标不同向。

读图观察： -MP-SENet / FRCRN 顶部双料（右侧 DNSMOS 3.83 / 3.82 · 左侧 STOI 0.976 / 0.971）—— 有参客观和无参主观一致高分 -htdemucs 底部双料（右 2.98 · 左 0.930）—— 场景细分集上双指标都偏低 -SGMSE+ 关键错位（DNSMOS 排第 5 但 STOI 掉到第 7）—— 生成式路线的典型信号：样本级不完全对齐 clean（STOI 偏低），但音频听起来自然（DNSMOS 中上）

结论：STOI 和 DNSMOS 在除 SGMSE+ 外的非生成式路线大体同向（FullSubNet+ / RNNoise 之间有小错位不影响主结论）· 但生成式路线（SGMSE+）在两个指标间有系统性偏离 · 生产选型时两个指标都要看。

六、性能对比 · CPU / GPU RTF

RTF（Real-Time Factor）= 推理耗时 / 音频时长 · 越低越快。RTF < 1 表示”处理比播放快” · 可实时。测试环境：RTX 4090D · CPU 服务端多核 x86_64 · 音频 32 × 84s 长文件。SGMSE+ CPU 因 diffusion 30 步逆 SDE 极慢 · 单条 5s 短样本 CPU 上都要 25 分钟以上 · 用 “>500” 口径截断显示。

关键观察：

• SGMSE+ 独一份 GPU 都要 0.64—— Diffusion 30 步 × 65 M U-Net · GPU 上 RTF < 1 意味着吞吐上仍能追上实时（1s 音频推理 0.64s），但每条音频要跑 30 步逆 SDE · 端到端延迟高（10s 音频约 6.4s 才能出结果，不适合流式实时）·CPU 完全不可行（RTF > 500 · 只能 GPU 部署）
• FRCRN CPU 2.08 越过实时线—— 复数 CRN + CFSMN 对 CPU 不友好 · 但 GPU 上 0.013 富余 ·CPU 部署应避开
• MP-SENet CPU 0.494 边缘可实时—— 分段 attention 2s 段本身开销大 · 建议 GPU 部署
• RNNoise CPU 反而比 GPU 快（0.008 vs 0.023）—— 88K 纯 C runtime · Python + CUDA 加载开销大过网络本身
• DFN3 GPU 0.019 · CPU 0.031 · 两者都很快—— Rust 单线程 CPU runtime 就有充足实时余量 · 这也是作者官方口径主打 CPU 实时的原因
• htdemucs CPU 0.281—— 时域 conv 对 CPU 优化好 · 意外可用 · 但 41M 权重加载慢

部署建议：

七、结论 & 场景选型

核心结论： 1.参数量不是决定性因素：MP-SENet 2.1 M 综合最优 · SGMSE+ 65 M 第 2 · htdemucs 41 M 反而垫底 · 选算法看架构 + 训练数据 + 场景匹配，不看参数量 2.场景比算法更重要：cafe (babble) 的分差 1.66 分大于跨算法均值分差 · 选算法前先看业务场景 3.判别式和生成式路线在指标上有系统性差异：SGMSE+ 综合排第 2、白噪场景 DNSMOS 第 1，但场景细分集 DNSMOS 只排第 5、STOI 更是掉到第 7；DNSMOS 显著高于 STOI 排名是生成式路线特点（不完全对齐 clean 但听感自然）—— 两个指标都要看

场景选型指南：

Caveat： -DNSMOS 是无参 MOS 预测模型（onnx 打分）· 对剪切 / 音乐残留 / 瞬态伪影这类听感缺陷敏感度有限 · 生产选型建议听感 + 业务样本二次验证 -本文 baseline 混合了 16 种噪声 + 3 类无参数据集· 只覆盖典型场景 · 不代表所有业务分布 -算法延迟本文只列论文口径（算法原理级 · 分析窗 + look-ahead）·端到端延迟（含 I/O · resample · 分段策略）需按部署链路另测 -SGMSE+ 每次采样有随机差异（stochastic）· 本文全程 seed = 42 固定 · 生产用需固定 seed 保可复现 -本次实验 checkpoint / 环境版本：Meta denoiser master64 · FRCRN ModelScopedamo/speech_frcrn_ans_cirm_16k· FullSubNet+ Google Drive1UJSt1G0P_...· MP-SENetbest_ckpt/g_best_dns· htdemucs pretrained · RNNoisepyrnnoise 0.4.x· DFN3deepfilternet 0.5.6· SGMSE+ VBD Google Drive1_H3EXvhcYBhOZ...· DNSMOSmicrosoft/DNS-Challengesig_bak_ovr.onnx

附：8 家 · 适用与避开场景速查

系列告一段落：8 家 · 3 条技术路线（端侧 / 服务端 / 特色）· 5 case + 332 条 benchmark · 从原理到实测。选型看场景 + 硬件预算，不是”哪家最强”。