什么是前端智能推理引擎

在前端智能推理引擎之前，我們先來說一下什么是 ”端智能” 。

端智能（On-Device Machine Learning）是指把機器學(xué)習(xí)的應(yīng)用放在端側(cè)做。這里的“端側(cè)”，是相對于云服務(wù)而言的。它可以是手機，也可以是 IOT 設(shè)備等。

傳統(tǒng)的機器學(xué)習(xí)，由于模型大小、機器算力的問題，很多是放在服務(wù)端做的。比如 Amazon AWS 有“Amazon Rekognition Service”，Google 有 “Google Cloud Vision Service”。而隨著以手機為代表的端側(cè)設(shè)備算力的提高，以及模型設(shè)計本身的演進，大小更小、能力更強的模型逐漸能夠部署到端上運行。

相比云端部署的方式，APP端擁有更直接的用戶特征，同時具備如下優(yōu)勢：

• 實時性高， 端側(cè)處理可節(jié)省數(shù)據(jù)的網(wǎng)絡(luò)傳輸時間。

• 節(jié)省資源， 充分利用端側(cè)算力和存儲空間。

• 隱私性好， 產(chǎn)生數(shù)據(jù)到消費數(shù)據(jù)都在端側(cè)完成，避免傳輸引起的隱私泄露風(fēng)險 。

這些是端智能的優(yōu)勢，但它不是萬金油，仍然存在一些局限性：

• 設(shè)備資源有限， 端側(cè)算力、存儲是有限的，不能做大規(guī)模高強度的持續(xù)計算。

• 算法規(guī)模小， 端側(cè)算力小，而且單用戶的數(shù)據(jù)，在算法上并不能做到最優(yōu)。

• 用戶數(shù)據(jù)有限， 端側(cè)數(shù)據(jù)不適合長期存儲，同時可用數(shù)據(jù)有限。

同理，前端智能是指將機器學(xué)習(xí)的應(yīng)用放到前端上(web、h5、小程序等).

所以，什么是前端智能推理引擎呢？

如下圖：

前端智能推理引擎實際上就是利用前端上算力去執(zhí)行模型的那個東西。

業(yè)界現(xiàn)有的前端推理引擎

這里列出三個常見的推理引擎

• tensorflow.js (下面簡稱為tfjs)

• ONNX.js

• WebDNN

對于一個端上推理引擎來說，最重要的是什么？當(dāng)然是性能了！性能越好，也代表在端上的應(yīng)用場景也會越多，下面我們來看下這三個推理引擎的性能對比：

(下面數(shù)據(jù)使用模型為MobileNetV2分類模型)

cpu（js計算）

可以看到，在純JS環(huán)境下進行計算，僅僅做一次分類都要1500ms以上。設(shè)想一下如果一個相機需要實時對拍攝的物體做分類預(yù)測(比如預(yù)測拍攝的對象是貓還是狗)，那么每預(yù)測一次需要1500ms，這樣的性能是無法忍受的。

WASM

在WASM環(huán)境下，性能最佳的ONNX.js達到了135ms的性能，也就是7fps左右，已經(jīng)到了勉強能用的程度了。而tfjs卻是糟糕的1501ms。這里是因為onnx.js利用了worker進行多線程加速，所以性能最好。

WebGL（GPU）

最后是GPU環(huán)境，可以看到tfjs和ONNXjs的性能都達到了比較好的性能水平，而WebDNN表現(xiàn)較為糟糕。

除了上面這三種引擎，目前國內(nèi)還有百度的paddle.js以及淘寶的mnn.js等，這里不做討論。

當(dāng)然，在選擇一個合適的推理引擎時，除了性能以外，還有生態(tài)、引擎維護情況等等一系列的考慮。從綜合的方面來說，tfjs是當(dāng)下市場上最適合的前端推理引擎。因為tfjs可以依靠tensorflow的強大的生態(tài)、google官方團隊的全職維護等。相比之下ONNX框架比較小眾，且ONNXjs已經(jīng)有近一年沒有維護了。WebDNN性能及生態(tài)都沒有任何競爭力。

前端上的高性能計算方案

從上一章節(jié)其實能看到，在前端上做高性能計算一般比較普遍的就是WASM和基于WebGL的GPU計算，當(dāng)然也有asm.js這里不做討論。

WASM

WASM大家應(yīng)該是比較熟悉的，這里只做下簡短的介紹：

WebAssembly是一種運行在現(xiàn)代網(wǎng)絡(luò)瀏覽器中的新型代碼，并且提供新的性能特性和效果。它設(shè)計的目的不是為了手寫代碼而是為諸如C、C++和Rust等低級源語言提供一個高效的編譯目標(biāo)。

對于網(wǎng)絡(luò)平臺而言，這具有巨大的意義——這為客戶端app提供了一種在網(wǎng)絡(luò)平臺以接近本地速度的方式運行多種語言編寫的代碼的方式；在這之前，客戶端app是不可能做到的。

而且，你在不知道如何編寫WebAssembly代碼的情況下就可以使用它。WebAssembly的模塊可以被導(dǎo)入的到一個網(wǎng)絡(luò)app（或Node.js）中，并且暴露出供JavaScript使用的WebAssembly函數(shù)。JavaScript框架不但可以使用WebAssembly獲得巨大性能優(yōu)勢和新特性，而且還能使得各種功能保持對網(wǎng)絡(luò)開發(fā)者的易用性。 --《摘自 MDNWebAssembly概念 》

WebGL

啥？WebGL不是做圖形渲染的嗎？不是做3D的嗎？為啥能做高性能計算？

可能一些同學(xué)聽說過gpgpu.js這個庫，這個庫就是利用webgl做通用計算的，具體的原理是怎么樣的呢？(為了能夠繼續(xù)往下閱讀，請先快速瀏覽下這篇文章)：《 利用WebGL2 實現(xiàn)Web前端的GPU計算 》。

將推理引擎的性能進行極致優(yōu)化

好了，目前我們知道在前端上的兩種高性能計算方式了，那么如果現(xiàn)有的框架(tfjs、onnxjs)性能上就是不滿足我們的需求怎么辦呢？怎么樣才能進一步提升引擎性能，并落地生產(chǎn)環(huán)境呢？

答案是：手撕源碼，優(yōu)化性能。對，就是這么簡單粗暴。以tfjs為例(其他的框架原理上是一致的)，下面給大家介紹下如何用不同的姿勢去優(yōu)化引擎性能。

在去年年初時候，我們團隊和google的tfjs團隊做了一次深入交流，google那邊明確表示tfjs后面的發(fā)展方向以WASM計算為主、webgl計算不做新的feature以維護為主。 但是現(xiàn)階段各瀏覽器、小程序?qū)ASM 的支持并不完整(例如SIMD、Multi-Thread等特性)，所以 WASM暫時無法在生產(chǎn)環(huán)境落地。 所以，現(xiàn)階段還是需要依賴webgl的計算能力。糟糕的是，此時tfjs的webgl性能在移動端上表現(xiàn)依舊差強人意，尤其在中低端機上的性能完全達不到我們的業(yè)務(wù)要求。沒辦法，只能自己硬著頭皮進去優(yōu)化引擎。所以以下的內(nèi)容都是針對于webgl計算進行介紹。

優(yōu)化 WebGL 高性能計算的n種姿勢

姿勢一：計算向量化

計算向量化是指，利用glsl的vec2/vec4/matrix數(shù)據(jù)類型進行計算，因為對于GPU來說，最大的優(yōu)勢就是計算并行化，通過向量去計算能夠盡可能地達到并行化的效果。

例如一次矩陣乘法：

c = a1 * b1 + a2 * b2 + a3 * b3 + a4 * b4;

可以改為

c = dot(vec4(a1, a2, a3, a4), vec4(b1,b2,b3,b4));

向量化的同時也要配合內(nèi)存布局的優(yōu)化；

姿勢二：內(nèi)存布局優(yōu)化

如果讀了上面《 利用WebGL2 實現(xiàn)Web前端的GPU計算 》這篇文章的同學(xué)應(yīng)該了解到，在GPU內(nèi)所有的數(shù)據(jù)存儲都是通過Texture的，而Texture本身是一個 長n * 寬m * 通道(rgba)4 的東西，如果我們要存一個3 * 224 * 224 * 150的四維矩陣進去要怎么辦呢？肯定會涉及到矩陣的編碼，即以一定的格式把高維矩陣存進特性形狀的Texture內(nèi)，而Texture的數(shù)據(jù)排布又會影響計算過程中的讀存性能。例如，舉一個較簡單的例子：

如果是常規(guī)內(nèi)存排布的話，計算一次需要按行或者案列遍歷矩陣一次，而GPU的cache是tile類型的，即n*n類型的緩存，根據(jù)不同芯片n有所不同。所以這種遍歷方式會頻繁造成cache miss，從而成為性能的瓶頸。所以，我們就要通過內(nèi)存排布的方式進行性能優(yōu)化。類似下圖：

姿勢三：圖優(yōu)化

由于一個模型是一個一個的算子組成的，而在GPU內(nèi)每個算子被設(shè)計成一個webgl program，每次切換program的時候會造成較多的性能損耗。所以如果有一種手段能夠減少模型的program數(shù)量，對性能的提升也是十分可觀的。如下圖：

我們將一些可以融合的節(jié)點在圖結(jié)構(gòu)上進行融合(nOP -> 1OP)，基于新的計算結(jié)點實現(xiàn)新的OP。這樣一來大大減少了OP的數(shù)量，進而減少了Program的數(shù)量，所以提升了推理性能。在低端手機上效果尤為明顯。

姿勢四：混合精度計算

以上所有的計算都是基于常規(guī)浮點數(shù)計算，也就是float32單精度浮點數(shù)計算。那么，在GPU內(nèi)是否能實現(xiàn)混合精度的計算呢？例如float16、float32、uint8混合精度的計算。答案是可以的，在GPU內(nèi)實現(xiàn)混合精度計算的價值是在于提升GPU的bandwidth。由于webgl的texture每一個像素點包含rgba四個通道，而每個通道最高為32位，我們可以在32位內(nèi)盡可能存儲更多的數(shù)據(jù)。如果精度為float16，那么可以存儲兩個float16，bandwidth就是之前的2倍，同理uint8的bandwidth是之前的4倍。這個性能的提升就是巨大的。還是上圖說話吧：

姿勢n：...

優(yōu)化的手段還有很多，這里就不一一列舉了。

引擎落地的場景

目前，基于我們深度優(yōu)化的引擎已經(jīng)落地螞蟻集團及阿里經(jīng)濟體多個應(yīng)用場景，比較典型的就是文章開頭演示的寵物識別，還有卡證識別、碎屏相機等等等場景。

業(yè)界的有之前比較火的虛擬試妝小程序等。

[[380522]]

讀到這篇文章的朋友們也可以打開你們的腦洞，挖掘出更多更好玩的智能場景。

未來展望

隨著市面是機型的更新?lián)Q代及引擎的深入優(yōu)化，我相信tfjs會在更多富交互的場景上大放異彩，例如擁有AI能力的前端游戲、AR、VR等等場景。現(xiàn)在我們要做的就是靜下心來，站在巨人的肩膀上持續(xù)打磨我們的引擎，愿等花開。