FPGA 17最佳論文導讀 ESE: Efficient Speech Recognition Engine with Compressed LSTM on FPGA

歡迎轉載，轉載請註明：本文出自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