算法

ONNX - 它到底快在哪，又慢在哪 一、ONNX 是什么 ONNX（Open Neural Network Exchange）本质上是一种模型的中间表示格式（IR），类似于编译器里的 LLVM IR。 用 PyTorch 训练完一个模型之后，模型的计算逻辑是用 Python 描述的，跑推理的时候要经过 Python 解释器、PyTorch 的调度器、再到底层的 CUDA kernel。这条链路很长，开销不小。ONNX 做的事情是：把模型的计算图从 PyTorch 的世界里"导出"成一个独立的、与框架无关的静态计算图，然后交给专门的推理引擎（比如 ONNX Runtime）去执行。 打个比方：PyTorch 训练出来的模型像一份 Python 脚本，每次执行都要解释器逐行翻译；ONNX 导出后的模型像一份编译好的二进制文件，直接跑就行。 一个典型的 ONNX 文件（.onnx）里面存的是： 计算图的拓扑结构（哪些算子、怎么连接） 每个算子的类型和参数（Conv、MatMul、Relu 等） 模型的权重（以 protobuf 格式序列化） 输入输出的 shape 和数据类型 这里要注意一点：ONNX 本身只是一个格式规范，它不负责执行。真正跑推理的是 ONNX Runtime（简称 ORT）或者其他兼容 ONNX 的推理引擎（TensorRT、OpenVINO 等）。说"用 ONNX 加速"，实际上是"用 ONNX Runtime 加速"。 二、ONNX Runtime 为什么能快 理解了 ONNX 是什么之后，关键问题来了：为什么换个引擎跑就能快？ 2.1 去掉了 Python 开销 PyTorch 推理时，即使模型本身的计算是在 GPU 上跑的，Python 层面仍然有大量开销： ...

GTCRN 演进路径 记录 v1 → v2 → v3 → v3.1/v3.2 → v4 → v4.1 的改动和原因。 版本概览 版本 改动点 参数量 质量指标 内存 实时 v1 baseline 基线 139K DNSMOS 3.15 — × v2 transient 换损失函数 139K DNSMOS 3.15 — × v3 causal 因果化改造 145K DNSMOS 2.98 — √ v3.1 precision KD + QAT 压缩 41.6K PESQ 2.041 228 KB (INT8) √ v3.2 transient 宽度1.5× + 瞬态损失 ~83K PESQ ~2.15 ~355 KB (INT8) √ v4 network opt 架构精简 (4层GTConv) ~87K PESQ 2.147 683 KB (FP32) √ v4.1 int8 INT8 混合精度 C 推理 ~87K PESQ 2.037 464 KB √ 网络结构 (v1/v2 共用) 输入 spec (B, 513, T, 2) │ ├─ 可学习频带权重 (513,) │ ▼ ERB_48k.bm(): 513 → 219 │ 低频171保留，高频342→48 ERB band │ ▼ SFE_Lite: DWConv(1×5) → PWConv → BN │ ▼ ┌─ Encoder ─────────────────────────────┐ │ DSConv: 219→110 (stride=2) ← skip1 │ │ DSConv: 110→55 (stride=2) ← skip2 │ │ GTConvLite×6 (d=1,2,4,8,4,2) ← skip3-8 │ SubbandAttention │ └───────────────────────────────────────┘ │ ▼ DPGRNN_Enhanced × 2 │ intra: 双向GRU (频率轴) │ inter: 单向GRU (时间轴) │ ▼ ┌─ Decoder ─────────────────────────────┐ │ GTConvLite×6 + skip (逆序) │ │ DSDeconv: 55→110 + skip2 │ │ DSDeconv: 110→219 + skip1 │ └───────────────────────────────────────┘ │ ▼ ERB_48k.bs(): 219 → 513 │ ▼ CRM掩码 → 输出 GTConvLite 内部 x → DWConv(3×3, dilation) → PWConv → BN → PReLU → TRALite (时序注意力) → SEBlock (通道注意力) → + x (残差) DPGRNN 内部 x (B,C,T,F) → reshape (B*T, F, C) → Linear → 双向GRU (频率轴) → Linear → reshape + LayerNorm → reshape (B*F, T, C) → Linear → 单向GRU (时间轴) → Linear → reshape + LayerNorm → 输出 v1 → v2: 换损失函数 问题 v1 用的是标准 SpecRIMAGLoss，对所有帧一视同仁。但实际听感上，键盘敲击、鼠标点击这类突发噪音处理得不好。DNSMOS 是整段平均，掩盖了这个问题。 ...

GTCRN-Light v3 技术说明书 0. 扼要（Executive Summary） GTCRN-Light v3（以下简称 v3）是在原生 GTRCN 基础上进行的等价轻量化实现：完整保留“ERB→SFE→Encoder（频轴两次 /2）→DPGRNN（intra→inter）→Decoder（镜像+跳连）→ERB⁻¹→复域 CRM”的主干数据流与功能语义，通过算子级设计收缩参数与 MACs，同时增强形状稳定性与工程可部署性。 核心收益： 结构等价：无语义重构、无路径删减；对齐原版的时/频建模顺序与接口。 计算瘦身：卷积 DW-Separable 化、RNN 低秩瓶颈、门控去 RNN 化、ERB 固定权重化。 工程稳态：严格的频轴上/下采样闭环（33→65→129），对齐安全，易于导出与部署。 1. 设计目标与边界（Design Goals & Constraints） 不改变 GTRCN 的任务假设与编解码语义：复域 CRM、ERB 子带、频轴二次下采样、DPGRNN（先 intra 后 inter）、镜像解码与跳连。 降低参数与 MACs，但不牺牲 DPGRNN 的双路径长程/跨频建模。 形状稳定：频轴整数对齐，杜绝奇偶差累积；跳连前天然同维。 部署友好：避免难以量化/导出的算子（极小化状态化 RNN、减少不必要的线性层）。 2. 与原生 GTRCN 保持一致的“架构不变量” 数据流： (B,F,T,2) → [|S|, Re, Im] → ERB(bm) → SFE → Encoder(freq /2 ×2) → DPGRNN(intra→inter) → Decoder → ERB(bs) → CRM × S(复域) 采样策略：ERB 后 F=129；编码两次在频轴 /2：129→65→33；解码反向：33→65→129（确保 33→65→129 的闭环）。 时/频耦合：瓶颈处严格遵循 intra-(per time, across F) → inter-(per freq, across T) 的双路径顺序。 输出语义：预测 CRM（实/虚） 并在复域与输入逐点相乘。 3. 轻量化的四大支柱（Pillars of Lightweighting） 3.1 卷积主干 DW-Separable 化 + 轻量 GT-ConvLite 动机：将 2D 卷积的通道耦合与空间（T/F）卷积解耦，保留感受野与局部子带建模能力的同时，将参数与 MACs 近似按 1/通道数 降低。 ...