炒股就看金麒麟分析師研報，權威，專業，及時，全面，助您挖掘潛力主題機會！

新智元報道

編輯：KingHZ 好睏

【新智元導讀】AI非上雲不可、非集羣不能？萬字實測告訴你，32B卡不卡？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參數。

2. 運行測試腳本

然後，針對知識庫的檢索問答，我們寫了一個測試腳本。

通過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模型測試

在測試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）

如下表所示，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）

在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模型測試

Qwen3-8B在測試batch size達到256情況下，平均吞吐率可達11.31 token/s，而吞葉率最高可達2895 token/s，同時，首字時延只有2.93秒左右。

圖4：Qwen3-8B（NVIDIA RTX™ 5880 Ada ×1）

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）

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模型測試

如下圖，可以看出在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）

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）

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模型測試

如下表所示，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）

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）

依測試結果來看，我們建議的batch size在10-32之間，期間首字時延都是2-10秒。

圖13：DeepSeek-R1-Distill-Qwen-7B（NVIDIA RTX™ 5880 Ada ×2）

Qwen3-8B模型測試

Qwen3-8B測試結果如下，在batch size爲256時，平均吞吐率可以達到17.63 token/s，而總吞吐率可達最高4508.57 token/s，與此同時，首字時延也才達到1.90秒。

圖14：Qwen3-8B（NVIDIA RTX™ 5880 Ada ×2）

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）

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模型測試

在batch size爲256時，平均吞吐率可達12.19 token/s，總吞吐率最高3121 token/s，同時，首字時延才達到2.83秒，可以算是比較適合我們在日常對話的使用了。

圖17：Qwen3-14B（NVIDIA RTX™ 5880 Ada ×2）

在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）

在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模型測試

在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）

在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）

在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模型測試

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）

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）

當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對比測試

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）

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）

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的考量，我們依據測試結果做如下建議：

如上測試可知，FP16版本的70B模型，在體驗較爲理想的要求下（吞吐率達到18-20 token/s，首字時延3秒內），併發用戶數僅爲4左右。

而FP8版本，在相似體驗的情況下，可達到8個併發訪問。

因爲在多併發的情況下，例如一百個併發用戶使用，其用戶體驗是相似的，都可以獲得每秒至少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模型，在四卡NVIDIARTX™ 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分貝上下，對於日常辦公沒有噪音影響。而其他的測試案用例，則基本上察覺不到噪聲。

海量資訊、精準解讀，盡在新浪財經APP