深度學(xué)習模型大小與模型推理速度的探討（2）

3. 推理時(shí)間

這里涉及到一個(gè) gap，很多部署的同學(xué)們更喜歡談“計算效率”，而實(shí)際上算法同學(xué)真正關(guān)心的點(diǎn)是“推理時(shí)間”，導致兩者在對接的時(shí)候經(jīng)常會(huì )出現一些 misleading。因此我這里單獨開(kāi)一節來(lái)探討一下“推理時(shí)間”的評估方法。

其實(shí)也很簡(jiǎn)單，按照 RoofLine 模型，我們很容易就能得到算子實(shí)際的執行時(shí)間：

這是一個(gè)分段函數，拆開(kāi)來(lái)可得：

一句話(huà)總結：對于訪(fǎng)存密集型算子，推理時(shí)間跟訪(fǎng)存量呈線(xiàn)性關(guān)系，而對于計算密集型算子，推理時(shí)間跟計算量呈線(xiàn)性關(guān)系。

講到這里，我們就能初步回答本章一開(kāi)始的問(wèn)題了：按照 RoofLine 模型，在計算密集區，計算量越小，確實(shí)推理時(shí)間越小。但是在訪(fǎng)存密集區，計算量與推理時(shí)間沒(méi)關(guān)系，真正起作用的是訪(fǎng)存量，訪(fǎng)存量越小，推理的時(shí)間才越快。在全局上，計算量和推理時(shí)間并非具有線(xiàn)性關(guān)系。

上一節中，OP4 雖然計算效率很低，但由于訪(fǎng)存量也很低，因此其實(shí)推理速度還是快于其他幾個(gè) OP 的。但是我們可以觀(guān)察到，其計算量雖然只有 OP1 的 1/130，但是推理時(shí)間僅降低到了 1/6，兩者并非是線(xiàn)性關(guān)系（也是當年我把模型減到 1/10 計算量，但其實(shí)沒(méi)快多少的原因）。

再舉兩個(gè)例子強化一下，首先看這兩個(gè)卷積，他們的計算量差不多，但是因為都在訪(fǎng)存密集區，OP3 的訪(fǎng)存量遠低于 OP5，其推理也更快：

下面這個(gè)栗子更明顯，OP5 和 OP6 的區別僅僅是一個(gè)是 DepthWise Conv，一個(gè)是普通 Conv，其他參數沒(méi)有變化。按照我們之前的直觀(guān)感受，Conv 換成 DepthWise Conv 應該會(huì )更快，但實(shí)際上兩者的推理時(shí)間是差不多的（這組參數也是當年我用過(guò)的【手動(dòng)捂臉）：

4. 小結

從上面的討論中我們可以看出：計算量并不能單獨用來(lái)評估模型的推理時(shí)間，還必須結合硬件特性（算力&帶寬），以及訪(fǎng)存量來(lái)進(jìn)行綜合評估。并非是計算量越低模型推理越快。在評價(jià)模型大小時(shí)，也建議加上訪(fǎng)存量作為重要的評價(jià)指標。

需要強調的一點(diǎn)是，不同的硬件平臺峰值算力和內存帶寬不同，導致同一個(gè)模型在平臺 1 上可能是計算密集的，在平臺 2 上可能就變成了訪(fǎng)存密集的。例如上文提到的 Intel X86 平臺，“拐點(diǎn)”值為 48，而 NVIDIA V100“拐點(diǎn)”值為 173.6，上文舉的例子在 V100 平臺上僅有 OP2 落在了計算密集區，剩下的全部是訪(fǎng)存密集的。因此，同樣的模型在不同平臺上性質(zhì)可能會(huì )發(fā)生改變，需要具體情況具體分析。

我們很難給出一個(gè)通用性的結論，究其原因是 RoofLine 模型本身是一個(gè)非線(xiàn)性模型。這里必須要強調一點(diǎn)的是，除了峰值算力和內存帶寬之外，還有硬件限制、系統環(huán)境、軟件實(shí)現等諸多因素會(huì )影響程序的實(shí)際性能，使得其非線(xiàn)性特性更加嚴重。因此 RoofLine 模型僅僅只能提供一個(gè)性能上界的評估方式，并不代表能夠達到的實(shí)際性能。實(shí)際性能最準確的測量方式只有真機實(shí)測。

RoofLine 模型更重要的是提供了一種分析性能的思想，即計算密集型程序更多的受限于硬件算力，而訪(fǎng)存密集型程序更多的受限于硬件內存帶寬。在理解這一點(diǎn)的基礎上設計網(wǎng)絡(luò )結構，并分析網(wǎng)絡(luò )的性能，將更有理論參考。不會(huì )再對”計算量減半，為啥推理時(shí)間沒(méi)變“這種問(wèn)題抱有疑問(wèn)了（說(shuō)的就是我【流淚）

下文將對 RoofLine 模型的一些限制進(jìn)行討論，分析哪些因素將以何種方式影響程序，使得其到達不了 RoofLine 模型估計的性能上界。

（下文要開(kāi)始難度升級了，建議沒(méi)看懂 RoofLine 模型的同學(xué)們再把這一章看一遍，不然后面會(huì )看的有點(diǎn)懵）

三、影響模型推理性能的其他因素

RoofLine 模型可以用來(lái)評估程序的性能上界，但是實(shí)際能達到的性能還會(huì )受到硬件限制、系統環(huán)境、軟件實(shí)現等諸多因素的影響，距離性能上界有一定距離。本章將對這些影響因素進(jìn)行分析。

1. 硬件限制對性能上界的影響

前面 RoofLine 模型使用的峰值算力及內存帶寬，是根據紙面數據計算得到的，是理論上的最大值。但在實(shí)際情況下，硬件會(huì )因為種種原因，無(wú)法達到這個(gè)理論值。因此建議大家對硬件進(jìn)行micro-benchmark，以獲取硬件的真實(shí)性能上限。

以上文的 Intel X86 CPU 為例，我們之前計算的 avx512 理論算力為 4.608 TFLOPs/s，但這個(gè)數值的前提是頻率能維持在 4.5 GHz。然而實(shí)際上在使用 16 核跑 avx512 指令時(shí)，CPU 頻率會(huì )下降到約 2.9 GHz，此時(shí)理論算力僅剩下 2.96 TFLOPs/s，而實(shí)測值僅有 2.86 TFLOPs/s。

除了頻率之外，有些芯片可能會(huì )因為一些設計上或實(shí)現上的原因，導致在實(shí)際使用時(shí)達不到理論峰值。比如一些低端芯片不支持多****、不支持亂序執行、采用了阻塞式 Cache 等等，一些芯片甚至會(huì )有一些性能 bug，導致在實(shí)際使用時(shí)幾乎到達不了理論峰值（這里我個(gè)人傾向于把這些原因歸結為硬件限制帶來(lái)的損失）。

內存同理，該平臺理論帶寬為 96GB/s，但實(shí)測下來(lái)最高讀帶寬僅有 74 GB/s，僅能到達理論帶寬的 77%。

我們可以得到修正后的 RoofLine 模型，圖中藍色填充部分反映了因實(shí)際算力和內存帶寬達到不了理論值而造成的損失：

修正了實(shí)測峰值算力和內存帶寬后的 RoofLine 模型，藍色填充部分為硬件限制帶來(lái)的損失

修正后的模型“拐點(diǎn)”發(fā)生了變化，因此算子的性質(zhì)也會(huì )發(fā)生變化。建議拿到硬件后對硬件進(jìn)行 micro-benchmark，這里推薦兩個(gè)測試工具：

一個(gè)是高叔叔寫(xiě)的浮點(diǎn)峰值測試方法的文章，最后有 github 鏈接，大家可以 clone 下來(lái)測試硬件峰值：

還有一個(gè)是 stream 測試工具，可以用于測試內存帶寬：

2. 系統環(huán)境對性能的影響

除非程序運行在裸機中，否則操作系統一定會(huì )對性能上界產(chǎn)生一定影響，比如操作系統在多核間的調度損失、操作系統的內存管理帶來(lái)的損失、操作系統本身占用的運算資源等等。

對于一般的深度學(xué)習推理任務(wù)而言，現代操作系統對性能的影響并不是特別明顯。但是在一些特殊情況下，也會(huì )帶來(lái)嚴重的性能損失。我這里將會(huì )舉兩個(gè)例子：

一個(gè)是 Android 系統在大小核上的調度，一旦程序在 CPU 上的占用率不足（比如是周期工作的任務(wù)），則有可能被 Android 調度到小核上，帶來(lái)性能損失。

另一個(gè)例子是內存缺頁(yè)。在 Linux 系統上，當向系統申請內存頁(yè)后，系統只是返回了虛擬頁(yè)，等到程序實(shí)際使用虛擬頁(yè)時(shí)，才會(huì )通過(guò)觸發(fā)缺頁(yè)異常的方式，進(jìn)入操作系統內核分配物理頁(yè)，這一過(guò)程會(huì )嚴重降低性能。

好在這些問(wèn)題可以通過(guò)軟件進(jìn)行一部分彌補，例如調度問(wèn)題可以使用綁核來(lái)解決，缺頁(yè)問(wèn)題可以通過(guò)綁定物理頁(yè)（需要內核態(tài)）或內存池來(lái)解決。因此操作系統帶來(lái)的影響是可控的。

除了操作系統帶來(lái)的影響，系統中運行的其他進(jìn)程也會(huì )對當前進(jìn)程造成影響。比如一個(gè)系統中運行了多個(gè)深度學(xué)習實(shí)例，或者系統后臺一些 APP 自啟動(dòng)了等等。這些進(jìn)程都會(huì )占用核心算力和內存帶寬，造成當前進(jìn)程性能損失。

這往往會(huì )導致在工程測試環(huán)境下性能達標的模型，在實(shí)際部署時(shí)性能下降。因此，必須關(guān)注工程測試環(huán)境和實(shí)際部署系統環(huán)境的差異。如有條件，最好在實(shí)際部署環(huán)境下進(jìn)行測試。

3. 軟件實(shí)現對性能的影響

除了硬件限制和系統環(huán)境外，一個(gè)任務(wù)的軟件實(shí)現好壞對性能有著(zhù)重大的影響。

例如對于同樣的矩陣操作任務(wù)，使用 python 寫(xiě)的多重 for 循環(huán)，和用 numpy 高度優(yōu)化過(guò)的矩陣操作函數，性能可以差出 1~2 個(gè)數量級。

對于深度學(xué)習模型推理而言，推理框架對模型性能的影響主要體現在：是否充分利用了硬件的流水線(xiàn)資源、是否高效利用了硬件中的緩存、是否采用了時(shí)間復雜度更低的算法、是否解決了操作系統帶來(lái)的性能損失（如上文的調度問(wèn)題和內存缺頁(yè)問(wèn)題）、是否進(jìn)行了正確高效的圖優(yōu)化等等。

由于影響因素很多，因此軟件對性能的影響往往呈現出很強的非線(xiàn)性，導致在評估性能時(shí)很難給出一些普適性的結論，很多時(shí)候只能具體情況具體分析。（有的時(shí)候甚至有點(diǎn)玄學(xué)【捂臉）

例如同樣計算量的向量四則運算和超越函數，后者往往會(huì )慢于前者的原因是很多硬件不支持超越函數的 SIMD 指令；再比如空洞卷積（dilated Conv）性能會(huì )弱于普通卷積的原因是前者對訪(fǎng)存的利用不如后者高效等等。

在軟件實(shí)現的影響下，RoofLine 模型的上界再次下降，達到圖中的紅線(xiàn)（真實(shí)的非線(xiàn)性可能會(huì )比我隨手畫(huà)的要復雜的多）：

RoofLine 模型各種性能損失示意圖，圖中曲線(xiàn)不代表真實(shí)比例

因此，在評估或分析深度學(xué)習推理性能時(shí)，簡(jiǎn)單的計算量/訪(fǎng)存量指標是完全不夠的，只能做個(gè)性能上界參考。實(shí)際能達到的性能其實(shí)還要關(guān)注很多很多因素，例如算子的訪(fǎng)存模式、數據排布、是否能夠進(jìn)行圖融合、是否有精度可接受的低時(shí)間復雜度算法、算法并行度是否充足、各種運算的比例等等因素。

這些因素對于算法同學(xué)而言可能過(guò)于復雜，并不需要掌握。但如果所在的公司/部門(mén)有交流的機會(huì )的話(huà)，可以跟部署/優(yōu)化的同學(xué)針對模型結構和算子進(jìn)行探討，以獲取性能優(yōu)化的建議。

這里可以一些一般性的結論，僅供參考：

對于一些訪(fǎng)存非常密集且訪(fǎng)存 pattern 連續的算子，如 Concat、Eltwise Sum、ReLU、LeakyReLU、ReflectionPad 等，在 Tensor 數據量很大的情況下，軟件實(shí)現的損失會(huì )非常小，正常情況下基本都能達到內存帶寬實(shí)測上限；如果框架采用了融合策略的話(huà)，基本可以達到 0 開(kāi)銷(xiāo)。

對于 Conv/FC/Deconv 等算子，在計算密度很高的情況下，大多數框架是能夠很接近算力峰值的。但對于計算密度不是特別高的 case，不同框架的表現不一，需要實(shí)測才能確定。不過(guò)從大趨勢而言，都是計算密度越高，硬件的利用率越高的。

盡量使用常用的算子參數，例如 Conv 盡量使用 3x3_s1/s2，1x1___s1/s2 等，這些常用參數往往會(huì )被特殊優(yōu)化，性能更好。

4. 小結

RoofLine 模型僅能用于估計模型所能達到的性能上界，而實(shí)際部署時(shí)，還會(huì )受硬件限制、系統環(huán)境、軟件實(shí)現等因素的影響，導致無(wú)法達到 RoofLine 模型所定義的性能上界。

此外，由于這些因素往往會(huì )導致性能曲線(xiàn)有較強的非線(xiàn)性，理論分析和實(shí)測會(huì )有一定差距，有時(shí)這些因素會(huì )嚴重影響性能曲線(xiàn)，甚至會(huì )導致算子的性質(zhì)發(fā)生變化。因此本節討論的內容只是提供一些分析的思路與技巧，實(shí)測始終是最準確的性能評估方式。

四、面向推理速度的模型設計建議

前面討論了一大堆，其實(shí)最實(shí)用的還是“怎么設計模型能夠達到更快的推理速度”。

在給出我的個(gè)人建議之前，首先要先聲明的是：由于不同硬件、不同環(huán)境、不同框架的差異會(huì )很大，這些建議可能并不是在所有條件下都適用。在設計算法或性能測試遇到疑問(wèn)時(shí)，建議咨詢(xún)部署/優(yōu)化的同學(xué)。

好了，廢話(huà)不多說(shuō)（其實(shí)已經(jīng)說(shuō)了很多了），給出我的一些個(gè)人建議：

方法論建議：

了解目標硬件的峰值算力和內存帶寬，最好是實(shí)測值，用于指導網(wǎng)絡(luò )設計和算子參數選擇。

明確測試環(huán)境和實(shí)際部署環(huán)境的差異，最好能夠在實(shí)際部署環(huán)境下測試性能，或者在測試環(huán)境下模擬實(shí)際部署環(huán)境。

針對不同的硬件平臺，可以設計不同計算密度的網(wǎng)絡(luò )，以在各個(gè)平臺上充分發(fā)揮硬件計算能力（雖然工作量可能會(huì )翻好幾倍【捂臉）。

除了使用計算量來(lái)表示/對比模型大小外，建議引入訪(fǎng)存量、特定平臺執行時(shí)間，來(lái)綜合反映模型大小。

實(shí)測是最準確的性能評估方式，如果有條件快速實(shí)測的話(huà)，建議以實(shí)測與理論分析相結合的方式設計并迭代網(wǎng)絡(luò )。

遇到性能問(wèn)題時(shí)，可以逐層 profiling，并與部署/優(yōu)化同學(xué)保持緊密溝通，具體問(wèn)題具體分析（適當了解一下計算相關(guān)理論的話(huà)，可以更高效的溝通）。

網(wǎng)絡(luò )設計建議：

對于低算力平臺（CPU、低端 GPU 等），模型很容易受限于硬件計算能力，因此可以采用計算量低的網(wǎng)絡(luò )來(lái)降低推理時(shí)間。

對于高算力平臺（GPU、DSP 等），一味降低計算量來(lái)降低推理時(shí)間就并不可取了，往往更需要關(guān)注訪(fǎng)存量。單純降低計算量，很容易導致網(wǎng)絡(luò )落到硬件的訪(fǎng)存密集區，導致推理時(shí)間與計算量不成線(xiàn)性關(guān)系，反而跟訪(fǎng)存量呈強相關(guān)（而這類(lèi)硬件往往內存弱于計算）。相對于低計算密度網(wǎng)絡(luò )而言，高計算密度網(wǎng)絡(luò )有可能因為硬件效率更高，耗時(shí)不變乃至于更短。

面向推理性能設計網(wǎng)絡(luò )結構時(shí)，盡量采用經(jīng)典結構，大部分框架會(huì )對這類(lèi)結構進(jìn)行圖優(yōu)化，能夠有效減少計算量與訪(fǎng)存量。例如 Conv->BN->ReLU 就會(huì )融合成一個(gè)算子，但 Conv->ReLU->BN 就無(wú)法直接融合 BN 層

算子的參數盡量使用常用配置，如 Conv 盡量使用 3x3_s1/s2、1x1___s1/s2 等，軟件會(huì )對這些特殊參數做特殊優(yōu)化。

CNN 網(wǎng)絡(luò ) channel 數盡量選擇 4/8/16/32 的冪次，很多框架的很多算子實(shí)現在這樣的 channel 數下效果更好（具體用多少不同平臺不同框架不太一樣）。

框架除了計算耗時(shí)外，也處理網(wǎng)絡(luò )拓撲、內存池、線(xiàn)程池等開(kāi)銷(xiāo)，這些開(kāi)銷(xiāo)跟網(wǎng)絡(luò )層數成正比。因此相比于“大而淺”的網(wǎng)絡(luò )，“小而深”的網(wǎng)絡(luò )這部分開(kāi)銷(xiāo)更大。一般情況下這部分開(kāi)銷(xiāo)占比不大。但在網(wǎng)絡(luò )算子非常碎、層數非常多的時(shí)候，這部分開(kāi)銷(xiāo)有可能會(huì )影響多線(xiàn)程的擴展性，乃至于成為不可忽視的耗時(shí)因素。

一些其他建議：

除了優(yōu)化網(wǎng)絡(luò )結構、推理框架性能外，還可以考慮通過(guò)一些其他工程技巧來(lái)提升系統整體的性能。例如：對推理服務(wù)流水化，并行數據讀取與計算的過(guò)程，掩蓋 IO 延時(shí)。

本文介紹了評估模型大小的四個(gè)常用指標——計算量、參數量、訪(fǎng)存量、內存占用，從 RoofLine 模型入手詳細討論了影響模型推理速度的影響因素，并給出了面向推理速度的模型設計方法論與建議。

撰寫(xiě)本文的目的，不僅僅是給算法同學(xué)提供有效的網(wǎng)絡(luò )設計建議，更多的還是希望能夠傳達性能優(yōu)化的基礎知識與分析思路，減少算法設計到部署之間的 gap，更快速高效的設計推理友好的網(wǎng)絡(luò )模型。希望能對大家的工作有所幫助。

由于本人知識水平有限，如有錯誤和不詳盡的地方，望大家不吝指出，非常歡迎大家在評論區留言探討。