企業需要多少 GPU？從模型大小、Token、併發量估算算力需求

企業部署大型語言模型，需要多少 GPU，先看兩件事：一組配置能否放下模型，以及這組配置能否在可接受的回應時間內處理尖峰流量。先確認每組需要幾張 GPU，再透過實際測試估算需要多少組，最後加入備援，才能得到正式部署的卡數。

只知道模型是 8B、70B，或每月會處理幾百萬 Token，還不足以直接換算卡數。企業還要確認模型精度、每次輸入與輸出長度、尖峰請求量，以及使用者能接受的回應速度。NVIDIA 的容量規劃指引也採用特定工作負載下的實測容量與預期尖峰需求，回推需要的 GPU 數量。

本文以企業常見的 LLM 推論為主，依序回答三個問題：模型需要幾張 GPU 才放得下、尖峰時需要處理多少工作，以及一組服務的實測容量可以承接多少需求。

第一步：模型放得進幾張 GPU？

模型參數量與精度決定單一服務副本（Replica）至少需要多少 GPU 記憶體。所謂一個 Replica，是指一份可獨立對外承接請求的模型服務，可能部署在一張或多張 GPU 上。最基本的權重記憶體可用參數量乘以每個參數的位元組數估算：

模型權重記憶體＝模型參數量 × 每個參數的位元組數

常見的初步換算如下。表中皆為純權重理論值，未包含量化額外資訊與模型執行空間。

這只是模型權重，不等於部署時的完整 GPU 記憶體。推論還需要保存對話內容的 KV Cache，以及框架執行與暫存空間。NVIDIA 的記憶體排錯文件也將權重載入與 KV Cache 分配分開處理，並以「參數量 × 每參數位元組 ÷ 多卡切分數」估算每張 GPU 的權重記憶體。

因此，70B 模型量化成 FP8 後，理論權重約 70GB，不代表它能在一張 80GB GPU 上穩定承接正式流量。剩餘記憶體是否足以容納 KV Cache 與尖峰請求，仍要由 Context 長度、併發量與推論框架驗證。

如果模型權重已超過單卡記憶體，可評估量化、較小模型或多卡切分。若權重放得下，但執行時記憶體不足，再調整 Context 長度、同時請求數與推論框架設定。量化可能改變模型品質，多卡切分也會增加通訊需求，因此都要再以實際模型驗證。

第二步：尖峰時需要處理多少工作？

推論容量應以尖峰期間的工作量計算，而非只看每月 Token 總量。相同的一百萬 Token，分散在整天處理，和集中在上班時間由大量使用者同時送出請求，所需 GPU 數量可能完全不同。

企業可先整理六個需求欄位：

併發使用者數不等於同時請求數。五百名登入使用者若每分鐘只送出少量請求，實際同時工作量可能不高；批次系統即使只有少數使用者，也可能持續送入大量工作。已有正式流量時，應從系統紀錄取得尖峰 RPS、Token 分布與請求時間；尚未上線時，可先建立一般與尖峰兩種情境。

若只有請求速率與平均處理時間，可用下式建立併發量的初步假設：

平均同時請求數 ≈ 每秒請求數 × 平均請求處理時間（秒）

此為佇列理論中的 Little’s Law。這個近似值適合建立測試起點，不宜直接當成採購卡數。正式估算還要觀察尖峰分布與排隊時間。

第三步：從實測結果換算 GPU 數量

正式 GPU 數量應以實際可承接的處理量計算，也就是一組服務在回應速度與成功率達標時，每秒能完成多少請求。一組可獨立承接請求的模型服務（Replica），可能使用一張或多張 GPU。

需要的服務組數＝向上取整（尖峰每秒請求數 ÷ 單組服務每秒可處理的請求數）

基礎 GPU 數＝每組使用的 GPU 數 × 需要的服務組數

接著再依服務等級、維護需求、故障容忍與擴充時間加入容量餘裕或 N+1 備援。容量餘裕沒有所有企業共用的固定百分比；流量波動、自動擴充速度，以及一組服務故障會損失多少容量，都會改變最終數量。

推論容量估算範例

以下為方法示範，數字不代表特定 GPU 或供應商的效能承諾。

尖峰每秒有 6 個請求，單組每秒可處理 2 個，因此需要 6 ÷ 2＝3 組服務。每組使用 2 張 GPU，基礎容量共 6 張 GPU。以 Token 吞吐交叉檢查，需求為每秒輸出 2,400 Token，3 組服務也能輸出 2,400 Token。

若要求其中一組故障時仍能承接尖峰，則配置 4 組服務，共 8 張 GPU。以上為相同輸入／輸出長度及測試條件下的示意，擴充後仍須驗證整體容量。

實測時應固定模型版本、精度、輸入與輸出長度、推論引擎、GPU 配置及同時請求數，並記錄每秒完成請求數、每秒輸出 Token、成功率與回應時間。使用者送出問題後，等多久看到第一個字，稱為首字延遲（Time to First Token，TTFT）；這是判斷互動體驗是否達標的重要指標。每秒輸出 Token 數（Tokens Per Second，TPS）則衡量輸出速度，應區分單一請求與整體服務的吞吐量，並以一致的計時範圍比較。較完整的測試可再觀察 P95 等長尾延遲與排隊時間。

NVIDIA 的 LLM 測試指南指出，輸入與輸出長度、同時請求數及請求速率都會改變記憶體、吞吐與延遲。公開測試數字可用來縮小候選範圍，正式卡數仍應以企業自己的模型與流量條件驗證。

微調與訓練為什麼要另外估算？

微調與訓練會額外保存梯度、Optimizer State 與 Activation，記憶體需求通常高於推論。LoRA／QLoRA、全參數微調與從頭訓練需要更新的參數不同，卡數還會受到 Batch Size、Sequence Length、資料量、完成期限，以及多 GPU 擴充效率影響。因此，本篇的推論公式不能直接套用到訓練工作；這類需求應以實際訓練方法和小規模試跑另外估算。Hugging Face 的 GPU 記憶體說明也將訓練記憶體拆成權重、Optimizer State、梯度、Activation 與暫存空間。

KONST 的 GPU 部署選擇

KONST Group（康斯特超算集團）提供裸機 GPU 與 GPU 叢集，並透過 Konstra AI 承接 AI 資料中心建置、設備維運與算力交付，對應不同規模與控制需求的算力部署。企業可依容量測試結果、使用週期與後續擴充需求，選擇適合的部署方案。

聯絡我們，填寫您的資訊與需求，康斯特團隊將在 3 個工作日內聯繫您。

相關產品與服務：GPU 裸機租賃、算力租賃與託管。

FAQ

70B 模型需要幾張 GPU？

70B 模型需要的 GPU 數量取決於精度、單張 GPU 記憶體、Context 長度、同時請求數與回應速度。BF16 權重理論值約 140GB，FP8 約 70GB，INT4 約 35GB；實際部署還要保留 KV Cache 與執行空間。企業應先確認一組服務需要幾張 GPU，再用真實流量測試計算需要幾組。

每月 Token 數可以直接換算 GPU 數量嗎？

每月 Token 適合估算總用量與成本，不能單獨決定 GPU 容量。卡數更受尖峰每秒請求數、每次輸入與輸出長度、同時請求數及回應速度影響。相同月用量若集中在少數尖峰時段，所需 GPU 數量通常較高。

併發使用者數等於併發請求數嗎？

登入或在線使用者未必同時呼叫模型。GPU 數量應優先使用尖峰同時請求數與每秒請求數估算；缺少正式資料時，可用使用者操作頻率和平均請求時間建立情境，再透過測試校正。

GPU 記憶體足夠，為什麼還要增加 GPU？

記憶體足夠只代表模型可以執行。當單組服務無法在尖峰流量下同時滿足每秒請求量、Token 產出與回應速度，仍需增加服務組數，或調整模型、量化方式與推論設定。