本文翻译自英文原文，如有出入，以英文原文为准。
ArtifactNet 研究 · 第 5 篇 · 2/3 · 2026 年 5 月
蒸馏与运行时——轻量 ≠ 快速
ArtifactNet 研究历程第 5 篇。这是 2026 年 5 月的记录：当时我们想把 SOTA 检测精度从 4 秒批量推理搬到流式实时处理。模型缩小了，反而更慢了；我们用 28 种方式更换运行时，撞上了硬件下限；也学到了代价高昂的一课：“实时模型”并不等同于“检测模型”。下面是把一个追求精度的模型硬塞进实时约束的工程过程——成功与失败，一并如实写出。
想看看当前模型的实际效果？ 用免费演示处理任意曲目——与下文所述相同的取证流程，无需账号。
ArtifactNet 的检测流程本质上是离线的。
audio → STFT → ArtifactUNet (residual extraction) → HPSS → 7-channel forensic features
→ ResidualCNN → per-segment P(AI) → per-track median verdict
判断一首曲目时，我们抽取七个 4 秒片段，作为一个批次一起运行。每首曲目 0.58s，这已经绰绰有余；而且用户只想要结果，所以延迟从来不是问题。
问题来自方向相反的孪生研究。用同样的残差物理来去除 AI 音频里的 RVQ 鬼影，就得到一个音质修复工具（de-artifact）。我们还想把它做成音频插件（VST3）。插件必须对宿主送来的每个 256/512 采样点的块当场处理并返回——它看不到未来的帧（因果），也不能等上 4 秒。
换句话说，同一个 ArtifactUNet 主干网络必须同时活在两个世界里：
| 检测 | de-artifact 实时 | |
|---|---|---|
| 处理单位 | 4s 片段批处理 | 数十毫秒的块流式处理 |
| 未来帧 | 允许（双向） | 禁止（因果） |
| 延迟 | 无关紧要 | 几百毫秒以内 |
| 输出 | P(AI) | 还原后的波形 |
5 月的工作，就是为弥合这道鸿沟所做的工程。而在这个过程中，“模型越小越快”的直觉被打破了三次。
第一版设计是 ArtifactUNetLite：1.85M 参数（3.6M Teacher 的一半）、在单一模型中同时处理 44.1/48/96 kHz 的多采样率架构，以及面向插件的因果流式处理。
有几项设计决策被明确定了下来：
CausalChannelLayerNorm（逐帧 LN）。GroupNorm/BatchNorm 会在时间轴上泄漏统计量，破坏因果性。单元测试强制要求“未来对过去输出的影响 = 0”（过去 Δ = 0.00）。residual = m·X、clean = (1−m)·X 强制二者构成互补的一对。8 项单元测试全部通过——多采样率下的 hop 在 44.1/48/96 上都稳定在 2.90ms，残差+干净信号重建输入的误差为 8.94e-08，因果性也成立。
接着，速度测试的结果令人震惊。在 CPU 上，Lite 比现有的检测 UNet 慢 2.5 倍——尽管参数已经减半。
深入排查后，原因很清楚：
第一课：参数量不能代表速度。实时速度来自两点：(a) 用较大的 hop 减少帧数，(b) 向解码器一侧逐级收窄通道数以降低累计开销——Lite 两样都放弃了。
我们没有抛弃 Lite。单一的多采样率模型、零前瞻的因果流式处理，以及较小的权重内存（对移动端和存储友好），依然是真正的价值。但我们明确定下：它不会再被当作“RT 加速”路线提出。
接下来是面向真正实时去除的 ArtifactUNetRT 系列。它不再处理 4 秒片段，而是流式处理短帧：
| 名称 | T 帧数 | 片段长度 | 用途 |
|---|---|---|---|
| RT8 | 8 | ~93ms | 最低延迟 |
| RT16 | 16 | ~186ms | 推荐的低延迟档 |
| RT24 | 24 | ~278ms | |
| RT48 | 48 | ~557ms | 标准模式 |
两项关键技术：
CausalCLN 在推理时被替换为标准的 LayerNorm 模式（数值完全一致；详见 §6）。RT 系列使用 N_FFT=1024（117K 参数）——这是为低延迟而优化的小型频谱输入。它非常适合 VST3 的实时去除。
但我们在这里掉进了一个陷阱。“能不能把这个很快的 RT 模型也直接用在检测流程里？”我们提取了它的残差，送进现有的检测 CNN——结果 CNN 兼容性骤降到 30%。
原因简单而根本。检测 CNN 是在 N_FFT=2048 的频谱基底上训练的。RT 模型使用 N_FFT=1024，输入空间完全不同。残差的频率分辨率只有一半，CNN 看到的是它从未见过的分布。两个输入空间不同的模型，甚至无法直接比较。
第二课：为实时而更改的频谱基底，与下游模型不兼容。为速度而降低 N_FFT，是一个只适用于去除的选择，无法迁移到检测上。
第三个模型成了连接两个世界的桥梁。ArtifactUNetFast 是一个 534K 的模型，比 Teacher（3.6M）小 6.7 倍，并且保留了 N_FFT=2048。由于频谱基底相同，它可以直接接入检测流程，同时还支持因果流式处理。
| 项目 | 规格 |
|---|---|
| 参数量 | 534K（比 Teacher 小 6.7 倍） |
| 架构 | CausalDSConv + CausalCLN，4 级 U-Net，base_channels=24 |
| 输入 | (B, 2, 1025, T)——cat([H_mag, P_mag])，单次前向（Teacher 要做两次） |
| 输出 | (B, 2, 1025, T)——[mask_H, mask_P] ∈ [0, 0.5]² |
| 训练 | 从冻结的 Teacher 进行知识蒸馏 |
| 损失 | 1.0 × MSE(mask) + 0.1 × spectral_convergence |
| 数据 | AIME + Jamendo + lo-fi hiphop（12K 个文件，60K 个片段，SR 池 44.1/48k） |
蒸馏的核心是模仿 Teacher 的掩码，同时把输入打包成 2 个通道，使 H/P 在一次前向中处理完（Teacher 要把 H 和 P 分两次运行）。在收敛到最佳损失 0.06645 之后，我们在 10 首曲目上与 Teacher 做了对比：
| 指标 | 数值 |
|---|---|
| 掩码 Pearson 相关 | H=0.84，P=0.86（强相关） |
| 掩码 MAE | H=0.080，P=0.073 |
| 掩码分布 | Student 0.28 对比 Teacher 0.31 |
| 频谱收敛 | 0.38（残差特性得以保留） |
掩码比 Teacher 的略粗糙，但分布和特性都得以保留——残差提取能正确运作。
速度才是重头戏。在 PyTorch 上，它与 Teacher 相近，但换到 ONNX Runtime 上，情况就完全不同了：
| 模型 | ORT CPU 4 线程 p50 | RTF | 总延迟 |
|---|---|---|---|
| Teacher（PyTorch，2 次前向） | ~998ms | 0.25 | ~4s |
| Fast（PyTorch，1 次前向） | ~1066ms | 0.27 | ~4s |
| Fast ORT T=16 | 18.5ms | 0.10 | 204ms ✅ |
| Fast ORT T=24 | 27.8ms | 0.10 | 306ms |
ORT 相比 PyTorch 加速 50 倍。在 T16 下，片段（186ms）加推理（18.5ms）合计 204ms 的总延迟——处在实时插件的预算之内。
我们导出了三种产物——原始 ONNX（供 ORT 运行时使用）、CausalCLN 图手术版本（仅限 Rust/tract 的自定义算子），以及经 onnxsim 优化的版本。注意，图手术版本在 ORT 上创建会话会失败（不支持该自定义算子），因此它只能用于 Rust/tract。这个分叉引出了下一节的运行时之战。
模型确定之后，问题变成了该用哪个运行时来跑它。为了压缩 de-artifact 实时去除（RT48 立体声）的延迟，我们几乎试遍了所有推理引擎和设置。
| 阶段 | RTF（立体声） |
|---|---|
| tract 顺序执行（起点） | 0.416 |
| tract 并行 L‖R | 0.218 |
| 迁移到 ORT FP32 4‖4 | 0.031 |
| ORT 配置调优 | 0.029 |
| CausalCLN→LayerNorm ONNX 图手术 | 0.023 |
| 理论最小值（需要自定义算子） | ~0.018 |
仅仅从 tract 换到 ONNX Runtime，RTF 就从 0.416 改善到 0.031——提升了 18 倍（tract 的顺序执行，对比 ORT 的 MLAS 优化加上 L/R 会话并行）。图手术把它降到了 0.023。CPU 的绝对下限（Ryzen 5800X，AVX2 FP32）是立体声 11.9ms，RTF 0.022。
| 设置 | 延迟（p50） | RTF | 相对 CPU |
|---|---|---|---|
| CPU 立体声 4‖4T | 12.2ms | 0.0223 | 1× |
| CUDA 顺序 L→R | 3.9ms | 0.0072 | 3.1× |
| CUDA Graph FP16 | 2.52ms | 0.0046 | 4.8× |
| TRT FP16 顺序 | 1.71ms | 0.0031 | 7.1× |
| TRT FP16 batch=2 | 1.44ms | 0.0026 | 8.5× |
GPU（RTX 3060）的最终下限是 TensorRT FP16 batch=2，1.44ms（RTF 0.0026）。把立体声的 L+R 合并进单次前向的 batch 维度，始终比多流更快（TRT 的 batch 融合会以最优方式分配 SM 资源）。强制 LayerNorm 使用 FP16（禁用 FP32 回退），又额外提升了 5%。
看起来很快、却失败或退化的路线：
试遍 ORT SessionBuilder 的全部 28 个选项之后，我们得出结论：11.5–12.3ms 就是这套硬件的绝对下限。想再降下去，就得重新训练模型（缩小）或换新硬件。这不是失败，而是划定了边界——知道什么是可能的，才能决定在这条线之上放弃什么。
补充说明一下贯穿整条运行时阶梯、反复出现的 CausalCLN→LayerNorm 图手术。它是最小、却最干净的一项优化。
训练时的 CausalChannelLayerNorm 是一个自定义算子，逐帧计算 (C,F) 统计量。它能保证因果性，但在推理图中无法干净地映射到标准 ONNX 算子。于是我们直接对计算图动手术，把它换成数值等价的标准 LayerNorm + 转置模式。
关键在于，输出逐位完全一致，只有运行时变快了——因为 ORT 会把标准的 LayerNorm 模式识别为融合内核。在 ORT 1.24.x 上重新验证，图手术实测带来 +3.69ms 的收益；在性能剖析中，LayerNorm 占总耗时的 20.1%，图手术新增的 Transpose 占 16.8%——但整体仍是净收益。
一个有意思的反例：把同样的 LayerNorm 直接实现为 Rust 自定义算子，反而让单声道退化了 1.3ms。对于较小的 T=48 循环，ORT 的 MLAS 融合实现胜过了带循环转置的 Rust 实现。“手写内核总是更快”同样是一种错误的直觉。
实时去除分叉为 RT/Fast 两条路线的同时，我们也检查了检测流程本身能否迁移到 ORT。答案是直接把 Teacher 导出为 ONNX。
| 项目 | 结果 |
|---|---|
| ORT 4 线程，单声道 | 275.8ms（达到 <500ms 的目标） |
| CNN 判定一致率 | 100% (9/9) |
| 数值误差 | 最大 2.56e-06 |
| 参数量 | 3.6M |
| ONNX 节点数 | 76（简单的 UNet 结构） |
保留 N_FFT=2048，使其与检测 CNN 的判定达到 100% 一致（数值误差 2.56e-06）。这正是它与 RT 模型的决定性区别：
| 模型 | ORT 速度 | CNN 兼容性 | 用途 |
|---|---|---|---|
| RT（N_FFT=1024，117K） | 立体声 12.3ms | 30% | 仅限 VST3 |
| Teacher（N_FFT=2048，3.6M） | 单声道 275.8ms | 100% | 检测流程 |
对检测而言，答案是大的 Teacher，而不是小的 RT 模型——判断标准是兼容性，而不是速度。
这是本文的核心。整个 5 月，我们一直被一个诱惑缠着：把这些快模型直接用在检测流程里。结果失败了三次，每次的原因都不同。
(1) ArtifactUNetRT——频谱基底不匹配。N_FFT=1024，因此 CNN 兼容性只有 30%。（§3）
(2) ArtifactUNetLite——参数量倒挂。1.85M，在 CPU 上却比检测 UNet 慢 2.5 倍。（§2）
(3) ArtifactUNetFast——双层陷阱。
Fast 保留了 N_FFT=2048，所以不存在 RT 那样的兼容性问题。这就引出了一个自然的问题：“如果在 Fast 上重新训练检测 CNN 会怎样？”对残差的比较揭示了两件事：
| UNet 路径 | TPR（AI） | FPR（真实） |
|---|---|---|
| codec4（当前生产） | 98.0% | 0.0% |
| phase2（Fast 的 teacher） | 100.0% | 55.0% |
| Fast（直接替换） | 98.0% | 52.5% |
正确的顺序很清楚——要用 Fast 做检测，必须先从感知编解码器的 teacher（codec4）重新蒸馏，再在其上叠加 CNN。而且如果目标不是实时流式处理，检测就不需要因果约束，那么一个双向的轻量 student 在精度和效率上都占优。
第三课，也是最大的一课：实时约束（因果、短 hop、小 N_FFT、2 通道融合）与检测的精度和速度正面冲突。想让同一个主干网络兼顾两个世界的野心，每一次都付出了不同的代价。结论是分工：去除用 Fast/RT，检测用 Teacher/codec4。
这个月还有两项检查作为收尾。
对抗性规避测试。de-artifact 的目的是提升音频质量，而不是规避检测。尽管如此，作为尽职调查，我们自查了这款抑制工具是否可能被滥用于规避——把原始音频以及抑制强度 α=0.5/1/2/4 下的输出分别送过检测流程，测量 P(AI) 的变化。（检测的鲁棒性会在后续的一篇中讨论。）
轻量 SOTA 对比。大约同一时期，我们在一个小子集上（SONICS 伪造 150 + 真实 150），与一个外部基线（基于 MERT 的 2 阶段模型，174M 参数）做了对比。4.2M 的 ArtifactNet 以TPR 100%、FPR 10.7%、F1 0.949 领先，胜过 174M 的模型（F1 0.929），速度快 4.5 倍——每首曲目 0.58s，对比 2.62s。考虑到子集规模，重点不在绝对数字，而在于参数量相差 40 倍却仍占优势——这再次印证了本系列的前提：小模型是走向实时的起点。
参数量不等于速度。两次倒挂——Lite（2.5 倍）和 Fast（3.44 倍）——指向同一个事实：实时速度取决于 hop 大小、通道收窄方式、激活张量大小和内核启动次数。在缩小模型之前，先对真正慢的地方做性能剖析。
实时优化会破坏下游兼容性。降低 N_FFT（RT）以及因果/2 通道融合（Fast），都与下游的检测 CNN 发生了冲突。要让同一个主干网络服务多个用途，必须先决定哪些维度共享、哪些维度分叉。我们共享了频谱基底（N_FFT=2048），并把因果性和通道融合分叉出去。
把运行时试遍不是失败，而是划定边界。依次试过 tract→ORT→TVM→OpenVINO→TensorRT，钉死了硬件下限（CPU 11.9ms，GPU 1.44ms），让我们得以在这条下限之上，合理地决定该放弃什么、该重新训练什么。
下一篇中，我们会把这个打磨过的 SOTA 拿出去攻击它的剩余弱点——结果反而开始怀疑我们自己的评估方法。
ArtifactNet 研究团队 · 2026 年 5 月