建站
咨詢
售后
建站咨詢
新聞中心
什么是前端智能推理引擎
專注于為中小企業(yè)提供網(wǎng)站建設(shè)、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)法庫免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了成百上千家企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
在前端智能推理引擎之前，我們先來說一下什么是 ”端智能” 。
端智能（On-Device Machine Learning）是指把機(jī)器學(xué)習(xí)的應(yīng)用放在端側(cè)做。這里的“端側(cè)”，是相對(duì)于云服務(wù)而言的。它可以是手機(jī)，也可以是 IOT 設(shè)備等。
傳統(tǒng)的機(jī)器學(xué)習(xí)，由于模型大小、機(jī)器算力的問題，很多是放在服務(wù)端做的。比如 Amazon AWS 有“Amazon Rekognition Service”，Google 有 “Google Cloud Vision Service”。而隨著以手機(jī)為代表的端側(cè)設(shè)備算力的提高，以及模型設(shè)計(jì)本身的演進(jìn)，大小更小、能力更強(qiáng)的模型逐漸能夠部署到端上運(yùn)行。
相比云端部署的方式，APP端擁有更直接的用戶特征，同時(shí)具備如下優(yōu)勢(shì)：
-
實(shí)時(shí)性高， 端側(cè)處理可節(jié)省數(shù)據(jù)的網(wǎng)絡(luò)傳輸時(shí)間。
-
節(jié)省資源， 充分利用端側(cè)算力和存儲(chǔ)空間。
-
隱私性好， 產(chǎn)生數(shù)據(jù)到消費(fèi)數(shù)據(jù)都在端側(cè)完成，避免傳輸引起的隱私泄露風(fēng)險(xiǎn) 。
這些是端智能的優(yōu)勢(shì)，但它不是萬金油，仍然存在一些局限性：
-
設(shè)備資源有限， 端側(cè)算力、存儲(chǔ)是有限的，不能做大規(guī)模高強(qiáng)度的持續(xù)計(jì)算。
-
算法規(guī)模小， 端側(cè)算力小，而且單用戶的數(shù)據(jù)，在算法上并不能做到最優(yōu)。
-
用戶數(shù)據(jù)有限， 端側(cè)數(shù)據(jù)不適合長(zhǎng)期存儲(chǔ)，同時(shí)可用數(shù)據(jù)有限。
同理，前端智能是指將機(jī)器學(xué)習(xí)的應(yīng)用放到前端上(web、h5、小程序等).
所以，什么是前端智能推理引擎呢？
如下圖：
前端智能推理引擎實(shí)際上就是利用前端上算力去執(zhí)行模型的那個(gè)東西。
業(yè)界現(xiàn)有的前端推理引擎
這里列出三個(gè)常見的推理引擎
-
tensorflow.js (下面簡(jiǎn)稱為tfjs)
-
ONNX.js
-
WebDNN
對(duì)于一個(gè)端上推理引擎來說，最重要的是什么？當(dāng)然是性能了！性能越好，也代表在端上的應(yīng)用場(chǎng)景也會(huì)越多，下面我們來看下這三個(gè)推理引擎的性能對(duì)比：
(下面數(shù)據(jù)使用模型為MobileNetV2分類模型)
cpu（js計(jì)算）
可以看到，在純JS環(huán)境下進(jìn)行計(jì)算，僅僅做一次分類都要1500ms以上。設(shè)想一下如果一個(gè)相機(jī)需要實(shí)時(shí)對(duì)拍攝的物體做分類預(yù)測(cè)(比如預(yù)測(cè)拍攝的對(duì)象是貓還是狗)，那么每預(yù)測(cè)一次需要1500ms，這樣的性能是無法忍受的。
WASM
在WASM環(huán)境下，性能最佳的ONNX.js達(dá)到了135ms的性能，也就是7fps左右，已經(jīng)到了勉強(qiáng)能用的程度了。而tfjs卻是糟糕的1501ms。這里是因?yàn)閛nnx.js利用了worker進(jìn)行多線程加速，所以性能最好。
WebGL（GPU）
最后是GPU環(huán)境，可以看到tfjs和ONNXjs的性能都達(dá)到了比較好的性能水平，而WebDNN表現(xiàn)較為糟糕。
除了上面這三種引擎，目前國(guó)內(nèi)還有百度的paddle.js以及淘寶的mnn.js等，這里不做討論。
當(dāng)然，在選擇一個(gè)合適的推理引擎時(shí)，除了性能以外，還有生態(tài)、引擎維護(hù)情況等等一系列的考慮。從綜合的方面來說，tfjs是當(dāng)下市場(chǎng)上最適合的前端推理引擎。因?yàn)閠fjs可以依靠tensorflow的強(qiáng)大的生態(tài)、google官方團(tuán)隊(duì)的全職維護(hù)等。相比之下ONNX框架比較小眾，且ONNXjs已經(jīng)有近一年沒有維護(hù)了。WebDNN性能及生態(tài)都沒有任何競(jìng)爭(zhēng)力。
前端上的高性能計(jì)算方案
從上一章節(jié)其實(shí)能看到，在前端上做高性能計(jì)算一般比較普遍的就是WASM和基于WebGL的GPU計(jì)算，當(dāng)然也有asm.js這里不做討論。
WASM
WASM大家應(yīng)該是比較熟悉的，這里只做下簡(jiǎn)短的介紹：
WebAssembly是一種運(yùn)行在現(xiàn)代網(wǎng)絡(luò)瀏覽器中的新型代碼，并且提供新的性能特性和效果。它設(shè)計(jì)的目的不是為了手寫代碼而是為諸如C、C++和Rust等低級(jí)源語言提供一個(gè)高效的編譯目標(biāo)。
對(duì)于網(wǎng)絡(luò)平臺(tái)而言，這具有巨大的意義——這為客戶端app提供了一種在網(wǎng)絡(luò)平臺(tái)以接近本地速度的方式運(yùn)行多種語言編寫的代碼的方式；在這之前，客戶端app是不可能做到的。
而且，你在不知道如何編寫WebAssembly代碼的情況下就可以使用它。WebAssembly的模塊可以被導(dǎo)入的到一個(gè)網(wǎng)絡(luò)app（或Node.js）中，并且暴露出供JavaScript使用的WebAssembly函數(shù)。JavaScript框架不但可以使用WebAssembly獲得巨大性能優(yōu)勢(shì)和新特性，而且還能使得各種功能保持對(duì)網(wǎng)絡(luò)開發(fā)者的易用性。 --《摘自 MDNWebAssembly概念 》
WebGL
啥？WebGL不是做圖形渲染的嗎？不是做3D的嗎？為啥能做高性能計(jì)算？
可能一些同學(xué)聽說過gpgpu.js這個(gè)庫，這個(gè)庫就是利用webgl做通用計(jì)算的，具體的原理是怎么樣的呢？(為了能夠繼續(xù)往下閱讀，請(qǐng)先快速瀏覽下這篇文章)：《 利用WebGL2 實(shí)現(xiàn)Web前端的GPU計(jì)算 》。
將推理引擎的性能進(jìn)行極致優(yōu)化
好了，目前我們知道在前端上的兩種高性能計(jì)算方式了，那么如果現(xiàn)有的框架(tfjs、onnxjs)性能上就是不滿足我們的需求怎么辦呢？怎么樣才能進(jìn)一步提升引擎性能，并落地生產(chǎn)環(huán)境呢？
答案是：手撕源碼，優(yōu)化性能。對(duì)，就是這么簡(jiǎn)單粗暴。以tfjs為例(其他的框架原理上是一致的)，下面給大家介紹下如何用不同的姿勢(shì)去優(yōu)化引擎性能。
在去年年初時(shí)候，我們團(tuán)隊(duì)和google的tfjs團(tuán)隊(duì)做了一次深入交流，google那邊明確表示tfjs后面的發(fā)展方向以WASM計(jì)算為主、webgl計(jì)算不做新的feature以維護(hù)為主。 但是現(xiàn)階段各瀏覽器、小程序?qū)ASM 的支持并不完整(例如SIMD、Multi-Thread等特性)，所以 WASM暫時(shí)無法在生產(chǎn)環(huán)境落地。 所以，現(xiàn)階段還是需要依賴webgl的計(jì)算能力。糟糕的是，此時(shí)tfjs的webgl性能在移動(dòng)端上表現(xiàn)依舊差強(qiáng)人意，尤其在中低端機(jī)上的性能完全達(dá)不到我們的業(yè)務(wù)要求。沒辦法，只能自己硬著頭皮進(jìn)去優(yōu)化引擎。所以以下的內(nèi)容都是針對(duì)于webgl計(jì)算進(jìn)行介紹。
優(yōu)化 WebGL 高性能計(jì)算的n種姿勢(shì)
姿勢(shì)一：計(jì)算向量化
計(jì)算向量化是指，利用glsl的vec2/vec4/matrix數(shù)據(jù)類型進(jìn)行計(jì)算，因?yàn)閷?duì)于GPU來說，最大的優(yōu)勢(shì)就是計(jì)算并行化，通過向量去計(jì)算能夠盡可能地達(dá)到并行化的效果。
例如一次矩陣乘法：
c = a1 * b1 + a2 * b2 + a3 * b3 + a4 * b4;
可以改為
c = dot(vec4(a1, a2, a3, a4), vec4(b1,b2,b3,b4));
向量化的同時(shí)也要配合內(nèi)存布局的優(yōu)化；
姿勢(shì)二：內(nèi)存布局優(yōu)化
如果讀了上面《 利用WebGL2 實(shí)現(xiàn)Web前端的GPU計(jì)算 》這篇文章的同學(xué)應(yīng)該了解到，在GPU內(nèi)所有的數(shù)據(jù)存儲(chǔ)都是通過Texture的，而Texture本身是一個(gè) 長(zhǎng)n * 寬m * 通道(rgba)4 的東西，如果我們要存一個(gè)3 * 224 * 224 * 150的四維矩陣進(jìn)去要怎么辦呢？肯定會(huì)涉及到矩陣的編碼，即以一定的格式把高維矩陣存進(jìn)特性形狀的Texture內(nèi)，而Texture的數(shù)據(jù)排布又會(huì)影響計(jì)算過程中的讀存性能。例如，舉一個(gè)較簡(jiǎn)單的例子：
如果是常規(guī)內(nèi)存排布的話，計(jì)算一次需要按行或者案列遍歷矩陣一次，而GPU的cache是tile類型的，即n*n類型的緩存，根據(jù)不同芯片n有所不同。所以這種遍歷方式會(huì)頻繁造成cache miss，從而成為性能的瓶頸。所以，我們就要通過內(nèi)存排布的方式進(jìn)行性能優(yōu)化。類似下圖：
姿勢(shì)三：圖優(yōu)化
由于一個(gè)模型是一個(gè)一個(gè)的算子組成的，而在GPU內(nèi)每個(gè)算子被設(shè)計(jì)成一個(gè)webgl program，每次切換program的時(shí)候會(huì)造成較多的性能損耗。所以如果有一種手段能夠減少模型的program數(shù)量，對(duì)性能的提升也是十分可觀的。如下圖：
我們將一些可以融合的節(jié)點(diǎn)在圖結(jié)構(gòu)上進(jìn)行融合(nOP -> 1OP)，基于新的計(jì)算結(jié)點(diǎn)實(shí)現(xiàn)新的OP。這樣一來大大減少了OP的數(shù)量，進(jìn)而減少了Program的數(shù)量，所以提升了推理性能。在低端手機(jī)上效果尤為明顯。
姿勢(shì)四：混合精度計(jì)算
以上所有的計(jì)算都是基于常規(guī)浮點(diǎn)數(shù)計(jì)算，也就是float32單精度浮點(diǎn)數(shù)計(jì)算。那么，在GPU內(nèi)是否能實(shí)現(xiàn)混合精度的計(jì)算呢？例如float16、float32、uint8混合精度的計(jì)算。答案是可以的，在GPU內(nèi)實(shí)現(xiàn)混合精度計(jì)算的價(jià)值是在于提升GPU的bandwidth。由于webgl的texture每一個(gè)像素點(diǎn)包含rgba四個(gè)通道，而每個(gè)通道最高為32位，我們可以在32位內(nèi)盡可能存儲(chǔ)更多的數(shù)據(jù)。如果精度為float16，那么可以存儲(chǔ)兩個(gè)float16，bandwidth就是之前的2倍，同理uint8的bandwidth是之前的4倍。這個(gè)性能的提升就是巨大的。還是上圖說話吧：
姿勢(shì)n：...
優(yōu)化的手段還有很多，這里就不一一列舉了。
引擎落地的場(chǎng)景
目前，基于我們深度優(yōu)化的引擎已經(jīng)落地螞蟻集團(tuán)及阿里經(jīng)濟(jì)體多個(gè)應(yīng)用場(chǎng)景，比較典型的就是文章開頭演示的寵物識(shí)別，還有卡證識(shí)別、碎屏相機(jī)等等等場(chǎng)景。
業(yè)界的有之前比較火的虛擬試妝小程序等。
讀到這篇文章的朋友們也可以打開你們的腦洞，挖掘出更多更好玩的智能場(chǎng)景。
未來展望
隨著市面是機(jī)型的更新?lián)Q代及引擎的深入優(yōu)化，我相信tfjs會(huì)在更多富交互的場(chǎng)景上大放異彩，例如擁有AI能力的前端游戲、AR、VR等等場(chǎng)景?，F(xiàn)在我們要做的就是靜下心來，站在巨人的肩膀上持續(xù)打磨我們的引擎，愿等花開。
文章名稱：如何打造一個(gè)高性能的前端智能推理引擎
本文鏈接：http://www.dlmjj.cn/article/dhcejpe.html
