同时有一个副产物VAD保证有效收敛，最终的输出为bark域的22个增益，经过插值平滑处理后与带噪信号的频域信号相乘，反变换后得到降噪后的时域语音信号。
即使采用cache buffer的策略保证分帧后的效果，由于模型的感受野较大，性能开销也无法达到移动端实时的要求，同时，模型整段增强时本身消耗就比较大
对输出影响不大或有些neuron的output总是为0，那这种情况下就可以把它移除。
使用更少的bit来表示权重
尤其是网络通信库。个人刚融入这个环境时，觉得不能写一个基于 epoll/iocp/kqueue 接口封装一个异步网络通信库
IT系统的可观测性实施起来其实和电气工程还是比较类似，核心还是观察我们各个系统、应用的输出，通过数据来判断整体的工作状态。通常我们会把这些输出进行分类，总结为Traces、Metrics、Logs。关于这三种数据的特点、应用场景以及关系等，我们会在后面进行详细展开。
利用这些项目的组合或多或少可以解决针对性的一类或者几类问题，但真正应用起来你会发现各种问题：
1. 多套方案交织：可能要使用至少Metrics、Logging、Tracing3种方案，维护代价巨大
数据+算力：采集上来的数据，首先会进入到我们的管道系统（类似于Kafka），根据不同的数据类型构建不同的索引，目前每天我们的平台会有几十PB的新数据写入并存储下。除了常见的查询和分析能力外
对于存储引擎，我们的设计目标的第一要素是统一，能够用一套引擎存储各类可观测的数据；第二要素是快，包括写入、查询，能够适用于阿里内外部超大规模的场景（日写入几十PB）。
Traces/Logs：最简单直接的方式是关键词的查询，包括TraceID查询也只是关键词查询的特例
数据分析（一般针对Traces、Logs）：通常Traces、Logs还会用于数据分析和挖掘，所以要使用图灵完备的语言，一般程序员接受最广的是SQL
AIOps巡检：针对时序数据特别开发的基于时序异常算法的巡检能力，用机器和算力帮我们去检查到底是哪个指标的哪个维度出现问题。
