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

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

性能的意義

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

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

性能評估的觀測指標

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

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

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

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

從批跑到壓測

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

數量得足夠，否則均值和分位點計算就達不到統計意義。

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

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

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

小結

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