如何選擇 GPU 伺服器顯示記憶體：模型載入、批次大小、並發推理估算

你在美國或香港伺服器上部署大型語言模型時，在推理過程中遇到顯示記憶體不足（out-of-memory）錯誤。上下文視窗越長，問題就越嚴重。你會疑惑：「針對目前的模型規模、批次大小與並發請求數，我到底需要多少 GPU 顯示記憶體？」

答案在於綜合計算模型權重、啟動（activation）記憶體以及並發帶來的額外開銷。例如，以 70 億參數模型（7B）為例，在 FP16 精度下，僅權重就需要 14 GB 顯示記憶體——也就是 70 億個參數乘上每個參數 2 位元組。

本指南會帶你一步步完成顯示記憶體估算。你會了解模型載入方式、批次大小對顯示記憶體的影響，以及並發推理如何放大記憶體需求。如此一來，你就能在不超支、也不過度壓縮配置的前提下，為美國或香港伺服器選擇合適的 GPU 顯示記憶體容量。全文聚焦實務解法，而非純理論推演。

核心重點

• 透過「參數量 × 每個參數的位元組數」計算權重顯示記憶體。一個 7B 模型在 FP16 下需要 14 GB 顯示記憶體。
• 額外預留 1–2 GB 供 CUDA 上下文與框架開銷使用，作為安全的顯示記憶體基準線。
• 啟動記憶體隨批次大小線性成長；KV Cache 則會隨序列長度呈二次方（平方）成長。
• 多個並發請求會共用同一份權重，每個請求只會額外增加自己的啟動記憶體與 KV Cache。
• 使用 vLLM 等分析工具或 nvidia-smi 驗證你的估算結果；先在小顯示記憶體的 GPU 上測試，再決定正式採購方案。

如何為模型載入選擇 GPU 伺服器顯示記憶體

從參數量估算權重顯示記憶體

先從一個簡單的計算開始：模型權重顯示記憶體 = 參數數量 × 每個參數佔用的位元組數。不同的資料型別會佔用不同空間。

一個 70 億參數的模型在 FP16 下，權重顯示記憶體需求為 14 GB，也就是 70 億 × 2 位元組。如果切換到 INT8，相同模型只需要 7 GB；INT4 則可進一步降到 3.5 GB。原因在於每個權重佔用的位元數更少：INT4 每個權重只用 4 位元，而 FP32 需要 32 位元，顯示記憶體需求因此減少 8 倍。

在訓練情境中，ZeRO 論文提出一個用於估算模型狀態（model states）的標準公式：(p + p + 12) * model_size。其中，p 為每個參數的位元組數（FP16 為 2、FP32 為 4），model_size 則是以十億參數為單位的模型規模。一個 100 億參數的模型在混合精度訓練下，大約需要 16 位元組/參數，總計約 160 GB 顯示記憶體。

但這個公式適用於「訓練」，不適用於「推理」。在推理階段，你不再需要最佳化器狀態，只需要權重本身即可。

考量開銷與 CUDA 上下文

只計算權重仍不足以精準反映真實情況。你的 GPU 還需要為 CUDA 上下文、cuDNN 與 cuBLAS 工作空間，以及 kernel 啟動開銷預留顯示記憶體，這些在模型尚未真正執行前就已先佔用空間。

推理執行環境與服務框架（如 vLLM、TensorRT-LLM）通常會在權重與 KV Cache 之外，額外佔用約 0.5–2 GB 的 CUDA 上下文與框架開銷。這在 A100、A6000 等熱門 GPU 上都很常見，實際數值則取決於框架與 GPU 組態。

實務上，你可以在權重顯示記憶體基礎上額外加上 1–2 GB 做為安全緩衝。以 7B FP16 模型為例，整體規劃約 15–16 GB 顯示記憶體較為穩健。這表示單卡 24 GB（如 RTX 4090）就已足以應付推理需求，並保留相當的餘裕。

在選擇 GPU 伺服器顯示記憶體時，要記住：最佳化器狀態只與訓練／微調相關，與純推理無關。上線部署時，你只需關注「權重 + 開銷」的組合即可，如此既能保證估算足夠精準，又不會讓預算失控。

批次大小與啟動記憶體

啟動記憶體如何隨批次大小擴張

啟動記憶體用來儲存前向傳遞中的中介張量。與權重不同，這些張量會隨輸入變動而改變，並且會隨批次大小線性成長。可以用一個簡單關係式來表示：單樣本啟動記憶體 × 批次大小 = 總啟動記憶體。

以一個具體範例說明：假設某一層同時處理 32 張 224×224 解析度、64 通道的影像，需要儲存 224 × 224 × 64 × 32 個數值，也就是 102,760,448 個元素，若使用 4 位元組浮點數，總共約 401.40 MB。若將批次大小從 32 翻倍到 64，記憶體需求也會翻倍到 802.80 MB。這種嚴格的線性關係來自於批次大小只是一個簡單的乘數。

一個常見的 LLM 啟動記憶體估算公式為：Activation Memory = 2 × (sequence length) × (batch size) × (hidden size) × (number of layers)

這個公式揭示了相同的模式：你可以把批次大小因子提出來，看成是「單樣本啟動記憶體 × 批次大小」。

序列長度則會讓情況變得更複雜：注意力矩陣大小會與序列長度平方成正比。將序列長度翻倍，顯示記憶體需求會變成原先的 4 倍。一個 2048 token 的序列，其注意力矩陣包含 536,870,912 個元素，在 float32 下約占用 2.0 GB；若擴展到 4096 token，元素將變為 2,147,483,648 個，顯示記憶體躍升到 8.0 GB。這種平方成長正是長上下文推理極易「爆顯示記憶體」的主因。

KV Cache 在顯示記憶體估算中的角色

在 LLM 推理中，KV Cache 往往是導致顯示記憶體溢出的主要因素。該快取用來儲存模型已處理過的每個 token 的 key 與 value 張量，其規模會隨批次大小、序列長度與層數一同成長。

你可以用一個簡單計算來估算「每個 token 每一層」的 KV Cache：以 2 乘以注意力頭數，再乘以每個頭的維度，最後再乘以每個元素的位元組數。以一個具有 32 個注意力頭、每頭維度為 128 且使用 FP16（2 位元組）的模型為例，每個 token 每層的 KV Cache 需求為：2 × 32 × 128 × 2 = 16,384 位元組，即 16 KB。再乘上序列長度、批次大小與層數，就能得到 KV Cache 的總顯示記憶體需求。

各式分析工具可協助你驗證這些估算。vLLM 的 profiler 能在部署前測量 GPU 顯示記憶體使用情況，並顯示其隨並發變化的趨勢。例如，Llama 8B 在 1 個並發請求時約佔用 16 GB，在 4 個並發請求時會上升到約 23 GB。你也可以透過 nvidia-smi 實時監控顯示記憶體使用情況，藉由比較「整體 GPU 顯示記憶體」與「初始配置量」來推斷 KV Cache 的成長。

並發推理的顯示記憶體估算

共用權重與疊加啟動開銷

當多個使用者同時向模型發送請求時，權重只會在顯示記憶體中載入一份，不會為每個請求各自複製一份 14 GB 的權重。真正會隨並發數量成長的，是每個請求各自佔用的啟動記憶體與 KV Cache。

總顯示記憶體的計算可以概括為：權重顯示記憶體 +（單請求啟動記憶體 × 並發請求數）+ 框架與上下文開銷。這個公式能協助你直觀看出顯示卡需要承載的負載。

動態批次處理（Dynamic Batching）能讓你更有效率地使用顯示記憶體。這項技術透過實時監控 GPU 顯示記憶體使用率，自動調整批次大小，在避免 OOM 的前提下盡量提升吞吐量。變長批次處理會將長度相近的序列分組，降低 padding 帶來的浪費。這些方法會依照當前顯示記憶體狀況自動調整，避免不必要的記憶體佔用。

你也需要理解顯示記憶體在各組件之間的分配方式。例如，在 vLLM 中，可見顯示記憶體通常等於總顯示記憶體乘上 gpu_memory_utilization 參數值；在這部分可用顯示記憶體中，再依序扣除模型權重、峰值啟動記憶體和框架開銷，剩餘部分才真正用於 KV Cache。這種分區思路說明了為什麼「並非所有 GPU 顯示記憶體都能拿來跑推理」。

實用範例與完整計算演練

以下透過一個具體場景示範完整計算流程：假設你有一個 130 億參數（13B）的模型，使用 FP16，權重大約需要 26 GB 顯示記憶體。每個並發請求（包含 KV Cache）大約需要 2 GB 啟動記憶體，而你預期的並發數為 10。

那麼估算結果為：26 GB 權重 + 2 GB × 10 個並發請求 = 20 GB，再加上約 1 GB 框架與上下文開銷，總計約 47 GB。由此可推斷，你至少需要一張 48 GB 顯示記憶體的 GPU（如 A6000），或是考慮將模型分散到多張 GPU 上。

接下來要思考批次大小與並發之間的取捨：較大的批次大小會佔用大量 GPU 顯示記憶體，尤其是 KV Cache，但吞吐量未必線性提升；同時，也可能因 DRAM 頻寬飽和而明顯拉高延遲。一種基於分析的調優方式——Batching Configuration Advisor——可以幫你找出一個在吞吐量與延遲之間較為平衡的最佳批次大小。透過採用這個最佳批次大小，你可以釋放出一部分顯示記憶體，在同一張 GPU 上跑多個模型副本。以 OPT-1.3B 為例，啟用 4 個副本且為每個副本使用經調優的顯示記憶體配置時，整體吞吐量可較「單副本 + 最大顯示記憶體占用」方案提升約 33.7%。

輸出長度對顯示記憶體的敏感度同樣不容忽視：以 OPT-1.3B 為例，當批次為 520 個請求、每個請求只產生 130 個輸出 token 時，KV Cache 只使用了約 20% 的容量；但若每個請求產生 520 個輸出 token，KV Cache 使用率就會飆升到 80% 以上。當輸出極度冗長時，並發帶來的效益會明顯遞減。

若單卡顯示記憶體始終不足，可考慮顯示記憶體切分方案。管線並行（pipeline parallelism）會將模型依層垂直切分到多張 GPU 上，例如 4 路切分即可把單卡權重顯示記憶體降到原來的四分之一。張量並行（tensor parallelism）則會在水平方向切分每一層，將權重與啟動記憶體分攤到多張 GPU 上。這兩種方式都可把整體記憶體負載分散到多卡，讓每張 GPU 都能為更大的批次或更多並發請求騰出空間。

在選擇 GPU 伺服器顯示記憶體時，也要記住總 GPU 數量會隨並發與模型並行規模成長。一個常見的估算公式是：Total GPUs = concurrency × (tensor_parallel_size × pipeline_parallel_size)。這個關係式能協助你從整體視角規劃 GPU 數量與顯示記憶體需求。以這些計算為起點，再搭配實際負載測試，你就能在避免顯示記憶體溢出的同時，最大限度地降低預算浪費。

現在，你已經掌握了一套清楚的三步驟方法：第一步，依據參數量與精度計算權重顯示記憶體；第二步，估算單樣本啟動記憶體（包含 KV Cache）；第三步，乘上預期並發數，再加上框架與 CUDA 上下文的開銷。

這個方法需要搭配反覆調整。透過 vLLM 的 profiler 或 nvidia-smi 等工具，你可以將理論估算與實際工作負載進行對照驗證。先在小顯示記憶體 GPU 上做壓力測試，再決定最終硬體方案。線上 GPU 顯示記憶體計算工具也能為你提供一個快速起點。

以這些公式為基礎，再結合實際業務負載進行測試，你就能同時避免顯示記憶體不足與預算浪費。記住：選擇 GPU 伺服器顯示記憶體應該建立在量測與數據上，而不是憑感覺。動態批次處理與對 KV Cache 的精細管理，將讓你的推理部署更加高效且穩健。

常見問題（FAQ）

7B FP16 模型的最低顯示記憶體需求是多少？

通常至少需要 15–16 GB。模型權重本身需要 14 GB，再額外預留 1–2 GB 供 CUDA 上下文與推理框架開銷。一張 24 GB 顯示記憶體的 GPU（如 RTX 4090）在推理場景下會相當充裕。

為什麼長上下文容易導致顯示記憶體溢出？

因為 KV Cache 與注意力矩陣會隨序列長度呈二次方成長。將序列長度從原先基準翻倍，注意力相關顯示記憶體需求就會變成 4 倍。例如，4096 token 的序列在 float32 下約占用 8 GB，而 2048 token 則只需約 2 GB。

我能在一張 GPU 上服務多位使用者嗎？

可以。多位使用者會共用一份模型權重，但每位使用者都會有自己獨立的啟動記憶體與 KV Cache。你可以用以下方式估算顯示記憶體需求：權重顯示記憶體 +（單使用者啟動記憶體 × 使用者數量）+ 框架與上下文開銷。

上線部署時是否應該使用量化？

量化可以大幅降低顯示記憶體占用並加速推理。INT8 每個參數只用 1 位元組，而 FP16 需要 2 位元組。以 7B 模型為例，從 FP16 切換到 INT8，權重顯示記憶體會從 14 GB 降至 7 GB，讓你在同樣的顯示記憶體下放入更大的模型或支援更多並發。