我在很多文章里都有吐槽大規(guī)模預訓練模型的性能差，落地成本高，這一期就和大家講講，怎么評估算法的性能的。

當然，這篇文章應該是比較科普的，主要是為了讓大家樹立一個性能意識，在進行方案選型和最終檢測的時候，能有關注性能的這個意識。

性能的意義

這里所謂的性能，本質是對執(zhí)行速度、執(zhí)行資源消耗的一種評估。在現(xiàn)實的落地場景，一個模型最終能不能用起來，除了和算法效果有關，即類似準確率召回率，還和依賴的資源以及速度是相關的。

我們可以把運行環(huán)境比作一個空間有限的房間，如果你的刀是40米長的，其實很難在這個房間里使的舒服，即使他的傷害很高很強，與之相反，一把短一些的到在有限空間內，用起來會更得心應手。這就是性能的意義，在預訓練模型逐步熱門之后，這個問題會更加尖銳，預訓練無論是計算復雜度，還是空間需求，都很大，先不說訓練，就是推理，單機推理還算可以，但是耗時，還是高并發(fā)需求下，并非所有的組織都能支持，因此，我們需要對性能有足夠的敏感性，否則會很可能會出現(xiàn)，一頓操作效果調優(yōu)一個月的預訓練模型，最終因為上不了線功虧一簣的尷尬情況，當然，這也是作為一名算法工程師，必備的一種能力。

性能評估的觀測指標

要評估性能好壞，有哪些評估項，又有那些評估指標，詳細介紹下。

首先是單機速度的評估。即單進程下，每次推理所需要的時間，或者單位時間下能處理的計算次數(shù)，一般評估的是rt（Reaction Time，響應時間）或者qps/tps（query per second，transaction per second）。但是，由于很多時候，不同的輸入可能會影響這個時間，所以一般使用和在線分布接近的樣本或者query來批量請求，求平均值，而常見的，耗時長度的分布服從二八法則，因此我們要關注的是TOP耗時的情況，因此我們還會看不同位置的分位點情況，例如90%、95%或者99%分位點。另外還有種評估的方式，用合格率之類的方法，例如最高耗時不能超過200ms，超過的算失敗，然后計算成功率，成功率99%以上。

對于互聯(lián)網(wǎng)環(huán)境，除了單機速度，還必須考慮并發(fā)能力，并發(fā)能力是指當同時很多請求同時或者接近同時請求的時候的性能狀態(tài)，很多時候，因為熱點事件的出現(xiàn)，大家會大量開始在網(wǎng)上檢索請求，對計算機而言，完不成的任務就會開始排隊（這個和銀行柜臺類似的），排隊太長系統(tǒng)自然就難堪重負崩潰了，例如微博、B站、知乎這種偶爾的崩潰就很多是因為這個原因。指標上，其實更多是和單機的評估類似，只是評估的時候，一般是用多進程同時請求以模擬在線情況，例如4進程、8進程這種，然后來看速度還能不能保證在合格范圍內。

除了速度之外，偶爾還要看看其他的問題，例如內存，有沒有內存泄漏（在服務運行期間內存有沒有持續(xù)增加），在高峰期內存是否在正常范圍內（例如80%以內），都是需要關注的。

從批跑到壓測

前面有提到，評估性能最簡單的方式就是批量跑case，簡單的性能評估，其實就是找一批和query批量跑，然后掐時間。這里，先說下這個query需要有什么要求：

數(shù)量得足夠，否則均值和分位點計算就達不到統(tǒng)計意義。

而且盡可能和現(xiàn)實場景匹配，這樣測得時間和在線實際時間比較接近（這個其實沒那么難，直接撈日志抽樣即可）

這個時間的評估其實不難，簡單的用tqdm，上面就顯示平均時間（X item/s），但是如果要算分位點了，肯定要把每個case的時間都記錄下來再統(tǒng)計，例如弄numpy里面的函數(shù)計算，寫起來并不算困難。

但是，一旦要考慮并發(fā)能力了，那就要壓測了，即壓力測試，所謂的壓測，其實就是計算機模擬N個用戶，同時不斷向服務發(fā)送請求，當然，要壓測的話，通常需要把模型打包成服務，例如grpc或者http的。然后和觀測上面提的指標，耗時、qps、成功率、內存等。一般情況，我們不需要用所有服務器來實驗，一般也是對一臺機器即可，因為多臺機器，如果有做負載均衡，其實性能就是多臺機器求和而已。python實現(xiàn)上，先是對模型打包成服務形成服務端，而壓測腳本這邊寫一個客戶端來請求服務端，上壓測的話就弄個多進程觸發(fā)即可，網(wǎng)上有很多樣例代碼，直接搜，當然別指望能照搬，肯定是需要自己服務的情況來修改額，畢竟接口不盡相同。

小結

本文給大家簡單介紹了算法這邊需要關注的性能，以及評估的主要方式，能讓大家對性能樹立一個基本的概念，讓大家清楚性能是什么，怎么觀測等，后續(xù)會給大家介紹一些性能調優(yōu)的手段，幫助大家更好地優(yōu)化性能，成功把自己心心念念的模型推上線。