? ? ? ? 當你自己在服務器上部署好一個模型后,使用場景會有兩種。第一種就是你自己去玩,結合自有的數據做RAG等等,這種情況下一般是不會考慮并發的問題。第二種是將部署好的服務給到別人來使用,這時候就必須知道我的服務到底支持多大的訪問數量,是否要做分布式部署。本文先不擴展分布式部署,字數有限這部分內容另外些一篇文章。
一、預估模型推理時顯存占用的計算公式
模型參數 * 每個參數所占字節 =?權重所需顯存
① 已知條件:模型參數數量為70億(7B)個參數。每個參數使用 16位浮點數 表示,即每個參數占用 2字節(Bytes)。
② 計算過程:
總存儲需求? ?= 參數數量 × 每個參數占用的字節數
?????????????????????=?
?????????????????????=?
轉換為GB()即:??
③ 結論為:模型權重的大小約為 14GB。因此,為了加載這個模型,顯存容量需要大于14GB,否則會因為顯存不足而無法運行。
④ 重要說明:實際應用中,除了模型權重本身,還需要額外的顯存來存儲以下內容。
- 優化器狀態:如果使用優化器(如 Adam),它會存儲額外的狀態信息(如動量、方差等),通常會使顯存需求翻倍或更多。
- 激活值和中間結果:在訓練或推理過程中,模型會生成大量的中間數據,這些也需要占用顯存。
- 批量數據(重點關注):輸入數據和對應的標簽也會占用一部分顯存。
????????加載一個7B模型大概需要14G的顯存容量,但這僅僅只是加載到顯存上而已,都還沒開始推理呢。一旦模型開始推理,就會額外占用更多的顯存。好在現有的大模型推理框架可以幫助我們優化顯存。
二、計算剩余顯存量支持的最大并行訪問數
????????vLLM 和 LMDeploy 這樣的大模型推理框架時,采用了許多優化技術(具體哪些優化技術我自己也還在學習中,文末附上知乎大佬的文章鏈接供大家一同學習),有效的減少顯存占用和提高推理效率。這意味著對于優化器狀態和激活值的顯存需求可能已經得到了有效的管理或減輕,使得這些因素在估算顯存需求時變得不那么關鍵。然而,用戶輸入(例如批量數據、請求數據)依舊是影響最大并行訪問數的重要因素。
????????假設你的服務器還剩余GB的顯存,你可以根據每個請求需要的顯存量來估算最大并行訪問數。這里有一個簡化的計算方法:
① 先估算單個請求所需的顯存量
????????包括處理用戶輸入所需的顯存以及運行模型時生成的任何臨時數據。如果這個數值不是直接給出的,你可能需要通過實驗或查看文檔來獲得一個近似值。一般在你所下載的模型中有個config文件,里面的max_length就是的了。設這個數值為MB(注意單位轉換,因為通常這里的數值會比較小,用MB更直觀)。

② 再計算最大并行訪問數
????????將剩余的顯存量從GB轉換成MB( ),然后除以單個請求所需的顯存量
MB:
用千問2.5-7B和24G顯存舉個例子具體舉例(,
):?
在給定的條件下,服務器最多可以支持 256個并行訪問。?
【注】除了顯存,還需要考慮 CPU、網絡帶寬、磁盤 I/O 等其他硬件資源是否能夠支持如此高的并發。還有就是請求大小不是一成不變的,單個請求的顯存需求 Y 會隨輸入數據的變化而波動。
????????公式是理論上的最大值。實際應用中,為了保證系統的穩定性和響應速度,你需要做一些測試,然后做具體調整,比如預留 20% 的顯存作為緩沖。不過這種方法,也足夠讓你可以預估出在當前硬件條件下,你的服務能夠同時處理的最大請求數量,從而更好地規劃資源和服務能力。?
?
?推薦SayHelloCode大佬寫的有關vLLM推理優化原理的博客:vLLM(一)PagedAttention 算法