FPGA 17最佳论文导读 ESE: Efficient Speech Recognition Engine with Compressed LSTM on FPGA

Posted 2022-06-16 大饼博士X

欢迎转载，转载请注明：本文出自Bin的专栏blog.csdn.net/xbinworld。
技术交流QQ群：433250724，欢迎对算法、机器学习技术感兴趣的同学加入。

---

后面陆续写一些关于神经网络加速芯片设计的paper，前面已经写了ISSCC2017，当然，因为只有利用不加班的下班时间来看和写，可能周期会比较长…不过呢，多学习一些总是好的。最近有点忙，没有保持写的节奏，后面加油吧!）。下一篇会开始写ISCA 2017的论文。

---

作者与单位：

国内知名的深鉴科技的几位初创写的一篇，拿了今年FPGA会议的best paper，今天来看一看到底有些什么内容。文章围绕在FPGA下设计LSTM执行引擎，主要考虑的点是稀疏的计算架构。说实话，稀疏计算已经说的快熟（lan）了，关键还是这样的架构要在牺牲通用性下，得到足够强劲的收益；在一些专用的计算场景下，确实可以做到很好的效果，但也并不是一个免费的午餐。

背景介绍

先介绍一下语音识别和LSTM的简单背景。本文关注的应用场景是语音识别，当前一个基本的语音识别模型的流程是：

其中，现在非常常用的用于建模声学模型的是LSTM网络模型，它用于得到acoustic output probabilities（音节的输出概率），而且很有可能会占据整个系统中的90%以上的执行时间。所以作者认为要加速LSTM计算。

LSTM的结构如下图所示：

一个LSTM层里面，实际上是对一个序列x_1 … x_T的递归计算，其中最重要的是有i，f，o三个门控单元，分别叫做input，forget，output gate；一种比较流行的计算模式如下公式所示，也就是Figure 4所代表的含义。更详细的介绍本篇不写了，如果读者有兴趣可以看下[1]，我后面也打算在深度学习系列中写一篇RNN/LSRM的博文。

模型压缩

主要是Pruning和Conpression几步，具体下面会讲。

1. 剪枝pruning与负载均衡Load Balance
   基本的剪枝方法和Deep Compression [2]方法是一致的——将最小数值的Weight稀疏掉，然后再用retraining的方法保持原来的模型精度；retraining的时候胡保持已经被稀疏掉的参数不更新（一直是0）。但是作者提出，如果只是这样简单的稀疏，会有严重的负载不均衡现象，尤其是在硬件计算中，如果需要一个批次的计算全部完成，就会因为非零参数严重不均匀，出现快的计算单元等待慢的计算单元执行的情况，造成性能的浪费。

方法很简单，就是将分组了的参数按照一致的比例去稀疏，而不是原来那样全局稀疏；并通过retraining把损失的精度补回来。这样就做到了负载均衡的稀疏参数了。

1. 量化Quantizaiton
   参数和数据最低可以做到12bit量化；参数和数据的动态区间不同：
   
   

2. 编码Encoding
   属于CSC的编码，因为DDR位宽是512bit，所以需要512b对齐，PCIE接口位宽是128bit，所以有128bit对齐的要求。一个weight包含了12bit数据本身+4bit offset，offset表示距离上一个非0值的中间有几个0；

下面这张图是想表示在本文的设计中，一个input data读一次会被计算多次（吐槽一下，作者在画图以及后面文字解释的时候对于column的使用非常随意，有的时候是图上的一行，有的时候又是一列，看起来很费劲。FPGA会议的最佳论文…建议再严谨易读一点比较好。当然，也有可能是我没理解…）

下面是整个系统的架构图，可以看到，有多个channel，每个channel独立计算一个voice vector；在一个channel内部，见右图，有很多个PE，每个PE独立占有一个数据FIFO，而PE的数据来源都是共享的。大概的执行流程如下：参数会通过指针buffer和weight buffer先把参数连续存在片上RAM中，在解码中，因为知道了某个参数的位置index（通过offset，就可以知道它要和哪个数据相乘），就把需要的数据按序取到FIFO中，在计算的时候就不需要管序号了，只要FIFO和weight buffer中取出来的数据对的上；临时sum结果存在act buffer中，然后每一次乘完后再由Accu累加器把之前的结果和当前结果累加起来；这里有一点，因为一个PE可能需要处理参数矩阵中的多列，所以我猜测act buffer是可以存多个临时结果的。另外剩下的部分就是向量点乘，然后是加法，激活函数这些，完成LSTM整个过程，就不说了。整个ESE有32个channel，每个channel有32个PE。

这样看来，处理一个voice数据只有32个PE，也就是32个MAC，需要同时处理32个voice数据才能用满引擎。其实也折射了另外一个问题，sparse计算架构，单个数据处理时很难把并行的PE数量做大（为什么呢？因为目前看到的方案，在sparse计算中，要么就是用参数索引数据，要么用数据索引参数，索引取数据开销比较大；还有一个问题是，一个weight column可以做local reduction，以减少中间计算结果，但是data利用率低，要想data利用率高，中间计算结果就很大，这也是一个矛盾。），还是需要批处理才能提高总的性能。如果有更好的sparse计算架构，希望可以推荐给我学习。

OK，本篇就记录到此，后面会写一下今年ISCA的paper学习笔记。

参考资料

[1] http://www.jianshu.com/p/9dc9f41f0b29
[2] Deep Compression: Compressing Deep Neural Networks with Pruning, Trained Quantization and Huffman Coding
[3] ESE: Efficient Speech Recognition Engine with Compressed LSTM on FPGA