本地LLM萬字救場指南來了！全網超全AI實測：4卡狂飆70B大模型
今年上半年，隨著DeepSeek R1的發布，國內大模型的應用迎來井噴式的發展，各種大模型的信息滿天飛，連普通消費者都多多少少被大模型一體機給安利了，特別是滿血版的DeepSeek 671B。
然而理性地來講，671B模型的部署成本動輒百萬起步，遠超一般企業的IT預算。
同時，我們對大模型的使用與功能挖掘還停留在初期階段，特別是在后千模大戰的時代，32B/70B等中檔模型已經可以滿足許多企業的需求。
所以，如何選擇一個適合自己的大模型，并為此大模型選擇一臺合適的工作站？今天我們就來為大家說一說這個話題。
為了解決大模型實用性和經濟性的問題，我們重中之重是對其進行性能以及使用評估，為此我們使用了 Dell Precision 7960 塔式工作站，針對市面上最主流的模型進行了評測。
測試環境
硬件環境
機器平臺：Dell Precision 7960 Tower
GPU：單張、雙卡及四卡 NVIDIA RTX? 5880 Ada
CPU：Intel? Xeon? w7-3555
內存：64G DDR5 × 12
Dell Precision 7960 Tower
模型參數
不同尺寸的大模型，應用的場景也各不相同。以下是我們此次主要測試的模型尺寸及相應的使用場景。
模型名稱
- 大語言模型
對于70B模型，我們還額外測試了其FP8量化的性能表現，來為有大并發用戶數的情況提供參考。
- 多模態大模型
為了適應對多模態大模型的使用要求，我們還針對Qwen2.5的兩個多模態大模型進行了測試，分別是7B以及32B的模型。
推理框架
使用了目前廣受歡迎的vllm推理引擎來進行測試，為了最大程度利用GPU的顯存，將其「gpu utilization」參數設置為0.93。
軟件平臺
操作系統：ubuntu22.04
Driver Version：570.124
CUDA：12.8
軟件包：conda python3.10 torch2.6.0 vllm0.8.5
測試過程指令
1. 運行vllm
首先，根據不同的GPU數量調整tensor-parallel-size參數。
vllm serve DeepSeek-R1-Distill-Qwen-7B --port 9812 --tensor-parallel-size 1 --gpu-memory-utilization 0.93
vllm serve DeepSeek-R1-Distill-Qwen-7B --port 9812 --tensor-parallel-size 1 --gpu-memory-utilization 0.932. 運行測試腳本
然后，針對知識庫的檢索問答，我們寫了一個測試腳本。
通過prompt讓模型進行總結，對每個請求輸入4k的token，輸出約512個token的總結，并收集在此期間的性能指標。
3. 收集測試指標并匯總
測試用例
為了貼近真實情況，使用了三種測試用例：
為了消除誤差，每個測試進行了多次，并取平均值。
大語言模型測試
單卡NVIDIA RTX? 5880 Ada運行7B/8B/14B模型
先說在NVIDIA RTX? 5880 Ada單卡環境下測試的情況。
我們測試了DeepSeek-R1-Distill-Qwen-7B以及Qwen3-8B和Qwen3-14B。
由于32B/70B的模型的參數量較大，對顯卡的顯存需求更高，因此我們將在雙卡及四卡中進行測試。
DeepSeek-R1-Distill-Qwen-7B模型測試
- input 128/output 128
在測試batch size達到256情況下，平均輸出吞吐率可以達到12.35 token/s，而總輸出吞葉率最高可達3161 token/s。
其中，平均吞吐率能夠反映模型對每一個請求的響應能力及速度，而總吞吐率則體現了機器總的處理能力。
與此同時，首字時延只有2.89秒左右，意味著用戶在輸出問題到獲取模型的應答只需要消耗2.9秒的時間。
圖1：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×1）
- input 128/output 2048
如下表所示，DeepSeek-R1-Distill-Qwen-7B在測試batch size達到256情況下：
平均吞吐率可以達到16.82 token/s，而吞葉率最高可達4396 token/s，同時，首字時延為2.91秒左右。
圖2：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×1）
- input 4096/output 512
在batch size為256時，平均吞吐率為4.24 token/s，而吞吐率可達最高1085 token/s。但同時，其首字時延高達167.43秒，這會嚴重影響到我們的用戶體驗。
因此，比較合理的batch size應該是在16-32之間。
比如batch_size=20，其首字時延為6.03s，而平均吞吐率可以達到35.71 token/s，總的吞吐率為714 token/s。
這樣會比較符合我們用戶在使用大模型做一些知識庫檢索和應用時更希望得到的體驗。
圖3：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×1）
Qwen3-8B模型測試
- input 128/output 128
Qwen3-8B在測試batch size達到256情況下，平均吞吐率可達11.31 token/s，而吞葉率最高可達2895 token/s，同時，首字時延只有2.93秒左右。
圖4：Qwen3-8B（NVIDIA RTX? 5880 Ada ×1）
- input 128/output 2048
Qwen3-8B的測試結果如下，在batch size為256時，平均吞吐率為13.40 token/s，吞吐率可達最高3430.40 token/s，但同時，首字總時延達到3.08秒。
所以比較合理的batch size可以是128。
這樣首字時延約為1.51秒，而平均吞吐率能達到23.88 token/s，吞吐率也能達到3056.64token/s。
圖5：Qwen3-8B（NVIDIA RTX? 5880 Ada ×1）
- input 4096/output 512
Qwen3-8B測試結果如下，在batch size為256時，平均吞吐率為7.94 token/s，而總吞吐率可達最高2033 token/s，但同時，其首字時延高達217.69秒，用戶體驗不佳。
因此，合理的batch size應該是在10-20之間。
比如batch size=16，其首字時延為5.18s，而平均吞吐率可以達到25 token/s，總吞吐率為400 token/s。
如此一來，這更符合我們用戶在使用大模型做一些知識庫檢索和應用時，更希望得到的體驗。
圖6：Qwen3-8（NVIDIA RTX? 5880 Ada ×1）
Qwen3-14B模型測試
- input 128/output 128
如下圖，可以看出在batch size=256時，平均吞吐率可達5.69 token/s，而總吞葉率最高可達1457 token/s。但與此同時，首字時延達到6.01秒左右。
為追求更好的用戶體驗，滿足用戶在日常對話中的需求，建議batch size=128或者100，保證首字時延在2-3秒。
而且，在batch size=128時，平均吞吐率可達9.03 token/s，總吞吐量可以達到1156 token/s。
圖7：Qwen3-14B（NVIDIA RTX? 5880 Ada ×1）
- input 128/output 2048
Qwen3-14B的測試結果如下，在batch size為256時，平均吞吐率為6.09 token/s，總吞吐率可達1552 token/s，但首字總時延達到6.06秒，這個表現是用戶不太可以接受的。
如果體驗要更好的話可以設置batch size為128。
此時，首字時延約為3.36秒，而且平均吞吐率能達到14.22 token/s，總吞吐率甚至能達到最高的1820 token/s。
圖8：Qwen3-14B（NVIDIA RTX? 5880 Ada ×1）
- input 4096/output 512
Qwen3-14B測試結果如下，在batch size為256時，會出現部分的并發請求失敗的現象，這是由于請求并發數過多，而顯卡性能不足，無法同時處理多個請求，因此我們只統計到128的并發數。
而在batch size為128時，平均吞吐率為8.77 token/s，而吞吐率可達最高2245 token/s，但同時，其首字時延高達194.19秒，這會嚴重影響到我們的用戶體驗。
因此，比較合理的batch size應該是在10-20之間。
比如batch size=16，其首字時延為8.52s，而平均吞吐率可以達到17.86 token/s，總的吞吐率為286 token/s，這會更符合我們用戶在使用大模型做一些知識庫檢索和應用時的使用預期。
圖9：Qwen3-14B（NVIDIA RTX? 5880 Ada ×1）
單卡GPU功率
圖10：單卡NVIDIA RTX? 5880 Ada功率
雙卡NVIDIA RTX? 5880 Ada運行7B/8B/14B/32B模型
接下來我們看看雙卡NVIDIA RTX? 5880 Ada運行DeepSeekR1-7B、Qwen3-8B、Qwen3-14B的模型的情況，另外還加上了Qwen3-32B的模型來做測試。
DeepSeekR1-7B模型測試
- input128/output 128
如下表所示，DeepSeek-R1-Distill-Qwen-7B在測試batch size達到256情況下，平均吞吐率達到21.59 token/s，而總吞葉率最高可達5528 token/s，同時，首字時延也在1.61秒左右。
相比之下，我們可以選擇batch size區間為128-256作為大模型進行日常對話時的基礎指標。
圖11：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×2）
- input 128/output 2048
DeepSeek-R1-Distill-Qwen-7B的測試結果如下，在batch size為256時，平均吞吐率為32.53 token/s，總吞吐率可達最高8327 token/s，同時，首字總時延也才達到0.36秒。
圖12：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×2）
- input 4096/output 512
依測試結果來看，我們建議的batch size在10-32之間，期間首字時延都是2-10秒。
圖13：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX? 5880 Ada ×2）
Qwen3-8B模型測試
- input 128/output 128
Qwen3-8B測試結果如下，在batch size為256時，平均吞吐率可以達到17.63 token/s，而總吞吐率可達最高4508.57 token/s，與此同時，首字時延也才達到1.90秒。
圖14：Qwen3-8B（NVIDIA RTX? 5880 Ada ×2）
- input 128/output 2048
Qwen3-8B的測試結果如下，在batch size為256時，平均吞吐率為22.12 token/s，總吞吐率可達最高5663.89 token/s，同時，首字總時延也才達到2.18秒。
如果希望優化用戶體驗的話，可以選擇batch size為128。
此時，首字時延約為1.01秒，而平均吞吐率能達到35.22 token/s，總吞吐率也能達到4508 token/s。
圖15：Qwen3-8B（NVIDIA RTX? 5880 Ada ×2）
- input 4096/output 512
Qwen3-8B測試結果如下，在batch size為256時，平均吞吐率為6.58 token/s，而吞吐率可達最高1684 token/s，但同時，其首字時延高達141.89秒，用戶體驗不佳。
因此，我們可以選擇batch size在16-32之間。
這時首字時延區間為5-10秒，比如batch size=20，其首字時延為5.77s，而平均吞吐率可以達到40 token/s，總吞吐率為800 token/s，這樣可以更好地支撐用戶在知識庫檢索應用方面的需求。
圖16：Qwen3-8B（NVIDIA RTX? 5880 Ada ×2）
Qwen3-14B模型測試
- input 128/output 128
在batch size為256時，平均吞吐率可達12.19 token/s，總吞吐率最高3121 token/s，同時，首字時延才達到2.83秒，可以算是比較適合我們在日常對話的使用了。
圖17：Qwen3-14B（NVIDIA RTX? 5880 Ada ×2）
- input 128/output 2048
在batch size為256時，平均吞吐率為15.61 token/s，總吞吐率可達最高3996 token/s。同時，首字總時延也才達到3.33秒。
追求更好的用戶體驗可以將batch size設置為128，其首字時延約為1.62秒，而平均吞吐率能達到25.54 token/s，總吞吐率也能達到3269 token/s。
圖18：Qwen3-14B（NVIDIA RTX? 5880 Ada ×2）
- input 4096/output 512
在batch size為256時，平均吞吐率為5.15 token/s，而吞吐率可達最高1318 token/s，不過首字時延高達203.56秒，并不是一個理想的使用狀態。
比較合理的batch size應該是在10-20之間。
比如batch size=20，其首字時延為6.37s，平均吞吐率達到28.57 token/s，總吞吐率為571 token/s。對于采用大模型做知識庫應用的話，可以達到一個相對理想的使用情況。
圖19：Qwen3-14B（NVIDIA RTX? 5880 Ada ×2）
Qwen3-32B模型測試
- input 128/output 128
在batch size為256時，平均吞吐率可達4.42 token/s，總吞吐率最高1133 token/s，但同時，首字時延達到7.67秒，這其實和我們在日常對話的期望是相悖的。
較為合理的batch size應該是在20-64之間。
比如batch size為50，首字時延只有1.47秒，平均吞吐率為12.90 token/s，而總吞吐率更是達到865 token/s，比較適合我們在日常對話的使用。
圖20：Qwen3-32B（NVIDIA RTX? 5880 Ada ×2）
- input 128/output 2048
在batch size為256時，平均吞吐率為6.22 token/s，總吞吐率可達最高1591 token/s，同時，首字總時延也達到7.3秒。
同樣的，如果注重用戶體驗的話，可以選擇batch size為50-100。
比如batch_size=64，其首字時延約為2.26秒，而平均吞吐率能達到16.08 token/s，總吞吐率也能達到1028 token/s。
圖21：Qwen3-32B（NVIDIA RTX? 5880 Ada ×2）
- input 4096/output 512
在batch size為256時，會出現部分的并發請求失敗的現象，這是由于請求并發數過多，而顯卡性能不足，無法同時處理多個請求，因此我們只統計到128的并發數。
而在batch size為128時，平均吞吐率為7.35 token/s，而吞吐率可達最高941 token/s，但同時，其首字時延高達233.39秒，這會嚴重影響到用戶體驗。
測試對比下來，比較合理的batch size應該是在10-20之間。
此時首字時延約為3-9秒，比如batch size為10，其首字時延約為3.70s，而平均吞吐率可以達到16.95 token/s，總吞吐率為170 token/s，這會更符合日常用戶的需求。
圖22：Qwen3-32B（NVIDIA RTX? 5880 Ada ×2）
雙卡GPU功率
圖23：雙卡NVIDIA RTX? 5880 Ada運行功率
四卡NVIDIA RTX? 5880 Ada運行32B/70B/70B-FP8模型
最后來看重磅的四卡情況，我們選擇DeepSeek-R1-Distill-Llama-70B的模型，并且進行了FP16與FP8量化版的對比測試，同時也測試了Qwen3-32B模型在四卡情況下的推理性能。
Qwen3-32B模型測試
- input 128/output 128
batch size為256時，平均吞吐率可達8.52 token/s，總吞吐率達到2182 token/s。同時，首字時延達到1.98秒。
而在batch size為128時，平均吞吐率可達21.09 token/s，總吞吐率達到最高的2698 token/s，此時首字時延達到0.38秒。
相比之下batch size為128時配置的模型更適用于用戶日常的對話。
圖24：Qwen3-32B（NVIDIA RTX? 5880 Ada ×4）
- input 128/output 2048
batch size為256時，平均吞吐率為10.86 token/s，總吞吐率可達最高2779 token/s，同時，首字總時延也達到4.48秒。
如果希望用戶體驗更好的話，可以選擇batch size為100或者128。
比如batch size=100，其首字時延約為0.29秒，而平均吞吐率能達到21.84 token/s，總吞吐率也能達到2183 token/s。
圖25：Qwen3-32B（NVIDIA RTX? 5880 Ada ×4）
- input 4096/output 512
當batch size為256時，平均吞吐率為3.62 token/s，而吞吐率可達最高927 token/s，但同時，其首字時延高達262.12秒，嚴重降低用戶體驗。
比較合適的batch size應該是在10-20之間。
比如batch size=16，其首字時延為6.92s，而平均吞吐率可以達到25 token/s，總的吞吐率為400 token/s，此時效果會比較好。
圖26：Qwen3-32B（NVIDIA RTX? 5880 Ada ×4）
DeepSeek-R1-Distill-Llama-70B/70B-FP8對比測試
- input 128/output 128
DeepSeek-R1-Distill-Llama-70B在batch size為100的情況下，平均吞吐率可達到8.26 token/s，總的吞吐率可達到825 token/s。
雖然batch size為256時，可以達到最高總吞吐率999 token/s，但是其首字時延達到了9.22秒，不適合用戶在日常對話中使用，會嚴重影響用戶的體驗。
綜合比較batch size設置為100是在此用例中較為理想的。
圖27：DeepSeek-R1-Distill-Llama-70B（NVIDIA RTX? 5880 Ada ×4）
為了對比，我們對DeepSeek-R1-Distill-Llama-70B進行了FP8的量化。其表現如下圖。
在測試batch size達到256的情況下，平均吞吐率為4.53 token/s，而總吞葉率最高可達1160 token/s，但首字時延達到了7.96秒。
同樣的，我們關注batch size為100的情況下，平均吞吐率可達到8.90 token/s，總吞吐率可達到890 token/s，因此batch size選為100時也同樣較為合適。
圖28：DeepSeek-R1-Distill-Llama-70B-FP8-dynamic（NVIDIA RTX? 5880 Ada ×4）
- input 128/output 2048
DeepSeek-R1-Distill-Llama-70B在batch size為100時，平均吞吐率可達到11.46 token/s，總吞吐率可達到1146 token/s。
即使batch size為256時，能夠達到最高總吞吐率1504 token/s，但是其首字時延達到了9.01秒，效果不佳。
因此batch size設置為100可以達到較為理想的效果。
圖29：DeepSeek-R1-Distill-Llama-70B（NVIDIA RTX? 5880 Ada ×4）
我們同樣在這個用例，來看看DeepSeek-R1-Distill-Llama-70B FP8量化的情況。測試結果如下。
在batch size達到256時，平均吞吐率為8.27 token/s，總吞葉率最高可達1882 token/s，但首字時延達到了8.27秒。
同樣的，我們關注batch size為100的情況下，平均吞吐率可達到13.61 token/s，總的吞吐率可達到1361 token/s，而首字時延也只有3.49秒。
因此batch size選為100時也同樣較為合適。
圖30：DeepSeek-R1-Distill-Llama-70B-FP8-dynamic（NVIDIA RTX? 5880 Ada ×4）
- input 4096/output 512
DeepSeek-R1-Distill-Llama-70B測試情況如下圖。
在batch size為256時，會出現部分的并發請求失敗的現象，這是由于請求并發數過多后，導致顯卡性能無法同時處理多個請求，因此只統計到128的并發數。
而在batch size為128時，首字時延高達279.36秒，會降低用戶體驗。
綜合看來，比較合理的batch size應該是在10-16之間。
期間的時延為5-8秒，比如我們可以選取batch size為10，其首字時延為5s，而平均吞吐率可以達到14.49 token/s，總的吞吐率為145 token/s。
圖31：DeepSeek-R1-Distill-Llama-70B（NVIDIA RTX? 5880 Ada ×4）
我們再來看看70B FP8量化后的模型測試情況。
DeepSeek-R1-Distill-Llama-70B-FP8-dynamic測試結果如下，同樣在batch size為256時，出現部分的并發請求失敗的現象，因此我們并未將其進行統計。
而在batch size=128時，其平均吞吐率為4.12 token/s，而吞吐率可達最高527 token/s，但同時，其首字時延高達136.52秒，用戶體驗嚴重受限。
因此，比較合理的batch size應該是10左右，比如我們可以選取batch size=10，其首字時延為4.18s，而平均吞吐率可以達到20.41 token/s，總的吞吐率為204 token/s。
這會更符合我們用戶在使用大模型做一些知識庫檢索和應用時的預期。
圖32：DeepSeek-R1-Distill-Llama-70B-FP8-dynamic（NVIDIA RTX? 5880 Ada ×4）
四卡GPU功率和利用率
圖33：四卡NVIDIA RTX? 5880 Ada功率和利用率
圖34：四卡NVIDIA RTX? 5880 Ada系統資源的占用率
70B FP16 or FP8?
對于70B的模型，使用FP16與FP8的考量，我們依據測試結果做如下建議：
- 對于要求多并發的需求，如果是用于知識庫應用場景，我們建議使用FP8量化版本。
如上測試可知，FP16版本的70B模型，在體驗較為理想的要求下（吞吐率達到18-20 token/s，首字時延3秒內），并發用戶數僅為4左右。
而FP8版本，在相似體驗的情況下，可達到8個并發訪問。
- 對于推理有較多需求的用戶，建議使用FP16版本。
因為在多并發的情況下，例如一百個并發用戶使用，其用戶體驗是相似的，都可以獲得每秒至少11個token的速度，同時首字時延均為3秒多。
而在相似用戶體驗的情況下，FP16版本的70B模型，相比FP8版本，能帶來更高的準確率。
使用泊松分布模擬用戶隨機發送請求
以上的測試用例是比較理想化的，為了仿真用戶的真實使用場景，我們將在常用模型上模擬用戶隨機發送請求的情況。
使用的測試模型為Qwen3-8B和Qwen3-32B，分別使用單卡和四卡的NVIDIA RTX? 5880 Ada進行測試。
我們將使用知識庫檢索這一用例進行測試，即在input 4k/output 512的情況下，通過泊松分布來模仿用戶在不同時間點隨機發送請求。
為了發現使用瓶頸，我們仿真了每分鐘60次及100次請求的情況，測試結果見下。
單卡NVIDIA RTX? 5880 Ada運行Qwen3-8B
我們先看Qwen3-8B在單卡NVIDIA RTX? 5880 Ada上的測試結果：
先看第一個測試案例60reqs/min，泊松分布的參數λ=1，我們通過泊松分布發送請求的隨機性來模仿多個用戶在不同時間點使用的情況，發送請求的泊松分布如下所示：
（因為是泊松分布的隨機性，所以只能在指定請求數下盡量保證期望時間為60s，在30s時出現最高的請求數5，存在部分空閑的時間間隔沒有發送請求。）
由下圖的每個請求的首字時延可以看到，在前40個請求中，首字時延還是比較穩定的，但是在之后有明顯上升的趨勢。
由泊松分布圖可以猜測，應該是在30s處發送了5個請求，之后又在40s處連續發送多個請求，可能導致模型無法及時處理，從而出現阻塞的現象，導致之后的請求時延增大。
具體測試的結果如下表所示：
可以看出60reqs/min在單卡的8B模型上表現不俗，平均每個請求的首字時延只有5秒，平均吞吐率也能達到10.9 token/s，對于用戶在進行知識庫檢索問答時，有比較良好的體驗。
第二個測試案例是100reqs/min，泊松分布的參數λ=1.67。
同樣的，我們通過泊松分布發送請求的隨機性來模仿多個用戶在不同時間點使用的情況，發送請求的泊松分布如下所示：
由下圖的每個請求的首字時延可以看到，同樣在前40個請求中，首字時延還是比較穩定的，但是在之后有明顯上升的趨勢。
可以得知，此時已經超過了顯卡處理請求的能力范疇，之后隨著請求數的增加，后面發送的請求開始排隊阻塞，從而導致首字時延的累加。
最后測得的指標如下表所示：
可以看到在此案例下，平均首字時延高達27.689秒，會導致用戶體驗不佳，即使平均吞吐率有9 token/s。
但是在一分鐘內處理100個requests，對于單卡的8B模型來說，還是會有請求超載的現象。
四卡NVIDIA RTX? 5880 Ada運行Qwen3-32B
下面是Qwen3-32B在四卡上進行測試的結果：
第一個測試案例是60reqs/min，我們通過泊松分布發送請求的隨機性來模仿多個用戶在不同時間點使用的情況，發送請求的泊松分布如下所示：
每個請求的首字時延如上圖所示，可以看到，首字時延隨著請求數的增加不斷波動，這是由于當請求數量增加時，顯卡由于未處理之前的線程導致后面線程排隊阻塞，導致時延增加。
從泊松分布圖也能看出來，前期出現多次高請求數的時間段，所以會有時延突增的現象；而隨著之后請求數逐漸下降，當處理完之前的請求時，也會使得后面發送請求的首字時延減少。
下表是測得的具體指標：
可以看出60reqs/min在四卡的32B模型上表現不俗，平均每個請求的首字時延只有4.26秒，平均吞吐率也能達到8.85 token/s，對于用戶在進行知識庫檢索問答時能獲得較好的體驗感。
第二個測試案例是100reqs/min。
同樣的，我們通過泊松分布發送請求的隨機性來模仿多個用戶在不同時間點使用的情況，發送請求的泊松分布如下所示：
每個請求的首字時延如上圖所示。
可以看到，首字時延隨著請求數的增加不斷增加，再通過第一個案例可以發現，當在60s內發送100個requests時，顯卡已經有點過載了，才會導致首字時延的不斷增加。
雖然平均首字時延僅有約8.7秒，但是在后期，性能會逐漸下降，超出用戶可以接受的范疇。
下表是測得的具體指標：
所以我們得出一個結論，32B模型，在四卡NVIDIA RTX? 5880 Ada的Dell Precision 7960機器上能夠應對的處理次數，一分鐘約為60次，即每小時大約3600次。
多模態性能測試
由于以上的幾個大模型，都缺少圖片的理解能力，為了補充這一缺失，我們日常工作中，還需要部署多模態大模型。
目前主流的多模態大模型，有Pixtral，MiniCPM，Qwen等幾種，我們選擇了廣受好評的Qwen2.5-VL來做為測試的基準，原因是業界已經有許多團隊基于Qwen2.5做了各種微調，用于滿足不同的使用場景。
我們測試了兩種模型尺寸，分別是Qwen2.5-VL7B以及32B，分別使用單卡和四卡進行測試。
測試用例
為了與貼近真實情況，使用了三種測試用例，分別是分辨率為720p，1080p和4k的圖片數據。
其中，我們是通過取100張COCO圖片數據集，執行圖片描述任務，我們獲取了每次大模型對每一張圖片進行分析時的指標，并取了平均值。
具體如下表所示，時延單位為秒，吞吐率單位為token/s。
測試結果
Qwen2.5-VL-7B-Instruct模型使用的是單卡的NVIDIA RTX? 5880 Ada，而Qwen2.5-VL-32B-Instruct這個模型使用的是四卡的NVIDIA RTX? 5880 Ada。
首先我們主要關注7B模型的平均首字時延和吞吐率。
在720p這種較低分辨率的圖片下，首字時延只有0.39秒，而在4k超清畫質的圖片測試中，要高達6.26秒的時延。
除此之外，不同畫質的吞吐率其實差別不大，所以如果想要獲得較好的用戶體驗還是要盡量避免選用4k分辨率的圖片進行大模型的識別。
NVIDIA RTX? 5880 Ada單卡測試數據
接著看一下32B模型的平均首字時延和吞吐率。
在720p這種較低分辨率的圖片下，首字時延也只有0.65秒，而在4k超清畫質的圖片測試中，要高達8.36秒的時延。
除此之外，不同畫質的吞吐率其實差別不大，如果想要獲得更快的推理速度需要避免選擇4k分辨率的圖片進行大模型識別。
NVIDIA RTX? 5880 Ada四卡測試數據
測試結論
1. 對于知識庫類的應用
我們建議使用單卡或雙卡NVIDIA RTX? 5880 Ada就可以了，因為知識庫應用可以使用7B、8B的模型，這個配置對于部署7B、8B模型來說已經足夠了。
使用8B模型，在保證體驗的情況下，對于單卡及雙卡的并發用戶數，分別是20及40，考慮到用戶隨機訪問的情況，每小時能處理的請求總量分別是3000、6000次。
2. 對于智能體類的應用
我們建議使用四卡NVIDIA RTX? 5880 Ada的配置。
因為智能體會帶來大量的思考過程以及工具調用，對于模型能力有一定的要求，所以建議使用32B模型。
而32B模型在四卡的配置上，能達到比較好的用戶體驗，特別是長上下文的情況下，四卡機能比雙卡機帶來3-4倍的并發用戶數量支持。
同樣，為了保證用戶體驗，四卡機32B模型的并發數量最好是控制在20左右，考慮到用戶隨機訪問的情況，每小時能處理的請求總量約為7000次。
3. 設備表現出色
對于Dell Precision 7960的表現我們還是非常滿意，不只是在性能方面能充分發揮大模型的能力。
同時，在測試過程中的噪音控制也是相當不錯的，即使在四卡做大并發的使用場景下，其噪音分貝也僅有55分貝上下，對于日常辦公沒有噪音影響。而其他的測試案用例，則基本上察覺不到噪聲。
