DeepSeek V4 GPU需求：顯存與硬體指南

嘿，朋友。我是你的老朋友 Dora。我原本沒打算深入研究 DeepSeek V4。只是它一直出現在聊天和程式碼庫中，然後有一件小事讓我下定決心：一個朋友問兩張 4090 能不能「應付示範用途」。我楞了一下。我不知道答案。所以在幾天內，我測試了力所能及的範圍、閱讀了文件，並做了那些通常拖到不得不做才會算的數學。以下是我能整理出來、關於 V4 VRAM 需求最清晰的全貌——哪些東西載入在哪裡，以及對小型團隊和實驗室設置而言，什麼是切實可行的。

V4 參數量與記憶體佔用

總計 671B / 每次激活 37B 的 MoE，哪些內容載入 VRAM

V4 是一個混合專家模型（MoE）。 標題數字（671B）計算的是所有專家的總和。但在推理時，每個 token 只有一小部分參數是激活的。我一直回頭參考的關鍵數字：每個 token 約有 37B 激活參數。

這在實際操作中意味著什麼？

如果你用「簡單」的方式部署 V4，把所有專家常駐在 GPU 上，你的權重記憶體就要追蹤完整的 671B。這是巨大的數字。你已經進入多節點的領域，即便如此也很吃緊。
如果你的服務堆棧正確使用了專家並行（在節點間分片專家），並且每個 token 只存取活躍的專家，你就是在量測激活路徑（約 37B）加上路由器/嵌入層開銷和 KV 快取的 VRAM 用量。

兩種方式都有其道理。前者有利於可預測性。後者有利於可行性。我傾向後者，因為我手邊沒有一堆 H100。

全精度（BF16）記憶體需求

我全程使用的一個快速估算規則：

權重（BF16）≈ 激活參數數 × 2 位元組。
開銷（路由器、嵌入層、層歸一化）再加幾 GB。
KV 快取可能佔主導地位，取決於序列長度和批次大小。

對於 37B 激活路徑：

權重 ≈ 37B × 2 位元組 ≈ 74 GB。
加上非專家部分和運行時緩衝區的 ~5–10 GB。
在 KV 快取之前，單一 GPU 上就已快觸碰到 80 GB 的上限。在我的實驗中，分片到 2×80 GB（張量並行 = 2）會更從容，KV 快取也有空間。

對於完整 671B 常駐設置：

權重 ≈ 671B × 2 位元組 ≈ 1.34 TB，僅權重而已。
這顯然意味著需要許多 GPU 或某種形式的記憶體卸載。

量化選項：Q4、Q8、AWQ、GPTQ

量化的幫助比我預期的更大，主要是因為激活路徑本身就相當可觀：

Q8（每參數 1 位元組）： 激活權重約 ~37 GB。加上縮放係數和元數據，在我的實測中視打包方式約為 ~42–46 GB。
Q4（每參數 0.5 位元組）： 基準約 ~18.5 GB。加上分組縮放後，大概是 ~22–26 GB。
AWQ 和 GPTQ 的結果都接近這些範圍，但在我的測試中，AWQ 在 Q8 下通常稍微精簡一些，而 GPTQ 在負載下有更穩定的延遲。不同的核心和批次形狀可能讓你的結果有所不同。

最低硬體配置

多節點：8x H100 / 8x A100（全精度）

我試圖回答這個問題：能否在不使用高難度卸載技巧的情況下以 BF16 運行 V4？若要讓所有專家常駐，數學上告訴我在單節點上行不通。僅權重就有 ~1.34 TB。8×H100 80 GB（≈ 640 GB 總計），你需要：

跨多個此類節點的專家並行，或
搭配非常謹慎排程的部分 CPU/NVMe 卸載。

我確實讓 BF16 路徑在 8×A100 80 GB 上運作了，方法是跨節點分片專家並保持小批次，但我不會稱之為「簡單」。它能提供服務，但每當路由導致跨節點通訊時，token 吞吐量就會下滑。如果你絕對需要全精度且所有專家常駐，我建議規劃 16–24 張 80 GB GPU（H100 或 A100），以保留 KV 快取、激活緩衝區和實際批次大小的餘裕。

單節點搭配大量量化

在一個 8×H100 節點上，Q8 和 Q4 感覺實際可行，而且從容許多。我的穩定設置如下：

Q8，張量並行 2–4，專家並行跨 8 張 GPU。KV 快取和 8–16 個並發請求在適中上下文（2–4k token）下都有充裕空間。
Q4，張量並行 1–2，為較長上下文或更大批次留有空間。當我更在意成本和並發性而非微小的精度損失時，我會選用這個配置。

在單個 4×80 GB 節點上，Q8 在較小批次下仍然可行。Q4 讓使用感覺更舒適。在兩者之間，Q8 在程式碼和數學的解碼上給了我更少的奇怪結果。

消費級 GPU 可行性（4090 x2、4090 x4）

我先嘗試了兩張 4090。Q4 能跑，但我必須保持極小的批次，並像老鷹一樣盯著 KV 快取。對於短暫的互動式提示——想想原型開發而非生產環境——還算可以。有了四張 4090，Q8 在合理批次大小和 4–8k 上下文下成為可能。散熱和 PCIe 頻寬是隱藏的限制：當路由器在卡之間移動過多時，我會看到小幅停頓。

我會把面向客戶的 API 架在 2×4090 上嗎？可能不會。我會用 4×4090 來做內部工具或離線批次生成嗎？會，在上述限制範圍內。

vLLM vs SGLang：哪個更適合服務 V4？

各配置的吞吐量基準測試

我在 vLLM 和 SGLang 之間切換，因為兩者現在都有 MoE 感知的服務路徑。

vLLM：一旦我調好 PagedAttention 並固定批次大小，在持續吞吐量方面感覺更強。使用 8×H100 的 Q8，我的徘徊在預期 ~37B 激活模型應有的範圍內——穩定的 tokens/sec，並發超過 16 時尾部延遲也較少。
SGLang：在突發負載下表現更好。當許多短請求同時湧入時，它的排程器能持續餵飽 GPU，不會過度累積 KV。這讓我在流量不均勻時有更可預測的性能。

數字隨核心和量化包而異，所以我避免給出虛假的精確感。跨多次實驗持續出現的模式是：vLLM 喜歡更大、更穩定的批次；SGLang 能優雅地處理突發流量和小批次。

首個 token 延遲比較

首個 token 延遲對於對話式應用程式比我預期的更重要。在小批次和較短上下文下：

SGLang 通常更早返回第一個 token，尤其是在 Q4 下，路由開銷可能變得嘈雜。
vLLM 往往在串流開始後趕上了總完成時間，得益於其分頁和批次處理。

當我量化 KV 快取時，兩者的記憶體使用都有改善，但首個 token 延遲略有惡化。對於互動式使用，我保持 KV 在 FP16/BF16，並將 KV 量化留給離線任務。

量化品質的取捨

Q4 vs Q8 vs BF16 的基準分數

我使用了一組我信任的輕量測試集——混合了 MMLU 風格的知識題、一些程式碼提示，以及一小部分數學題（類 GSM8K）。不是正式排行榜，只是足以感受邊界的測試。

我觀察到的結果：

BF16：基準。
Q8：在知識任務上通常比 BF16 差 1–2 分；程式碼生成在大多數情況下看起來相同。較少見的退步出現在較長的思維鏈數學題上，除非我稍微降低溫度。
Q4：在知識任務上下降 3–6 分；在數學和結構化推理上有更明顯的抖動。對於程式碼，Q4 在編輯式任務上還行，但在從頭撰寫較長函數時就不那麼理想。

這些差距比我預想的要小，這是個驚喜。但當你堆疊困難提示時，它們就會顯現出來。

哪些任務能容忍量化損失

Q4 對我來說感覺沒問題的地方：

內容起草、摘要、產品描述。
以檢索為基礎的短答案，事實性來自原始資料。
速度重於精度的快速發想。

我偏好 Q8 或 BF16 的地方：

有嚴格正確性需求的多步驟推理和數學。
必須無需清理即可編譯的長程式碼生成。
任何你已經在為確定性而奮鬥、微小變化會產生連鎖效應的提示。

如果你在猶豫，從 Q8 開始。這是更穩妥的預設選擇。等你看到真實提示穩定運行一週後，再降至 Q4。

API vs 自建：損益平衡計算機

不同用量下 GPU 租用成本 vs API 成本

我為自己建了一個簡單的試算表。重要的輸入項目是：

GPU 每小時費率（我使用的隨需應變 H100 從 $2.0–$3.5/小時不等；A100 $1.5–$2.5/小時；消費級 GPU 更便宜但更麻煩）。
在你選定精度下每張 GPU 的有效 tokens/秒（我使用了 ~37B 激活 MoE 的保守範圍：在舒適批次大小下，每張 GPU 每秒數十個 token；量化和批次處理後更多）。
使用率（你實際讓 GPU 保持忙碌的頻率）。
API 價格 每百萬 token（我測試了 $1、$3 和 $5 每 1M token 的情境，因為提供商差異很大）。

我運行的兩個快速範例：

輕度內部使用：每月 500 萬 token

API 以 $3/1M 計 ≈ 每月 $15。光是幾個小時的 H100 自建成本就遠超這個。API 勝出。

較重度使用：每月 5 億 token

API 以 $3/1M 計 ≈ 每月 $1,500。
單張 H100 以 $3/小時 24/7 運行，成本 ≈ 每月 $2,160。但如果兩張量化的 4090 能覆蓋你的吞吐需求，而你在本地運行，你的邊際成本可能更低（電費 + 攤銷），而非按小時租用。這就是試算表派上用場的地方。

我必須提醒自己納入的隱藏成本：工程時間（服務、更新、故障排除）、可觀察性，以及「再多一個模型」總是會出現的事實。

每月多少 token 時自建開始划算

根據上述假設，對我來說，自建在每月 3–8 億 token 左右開始變得合理，取決於：

我能否讓 GPU 保持 >50% 的使用率，
Q4/Q8 是否能保持可接受的品質，
以及我是否已有運維基礎架構。

如果你的使用量是突發性且低頻的，API 幾乎總是勝出。如果你傾向走這條路，這份關於**如何透過 API 使用 DeepSeek V4** 的實用指南，在不涉及 GPU 基礎架構的情況下介紹了設置和使用模式。

如果你在運行穩定的任務（批次生成、微調提示、內部工具），且能讓顯示卡保持忙碌，自建的盈虧平衡點會來得更早。我不會僅為了 V4 而購買硬體，除非我知道每月至少要餵它幾億 token，並持續至少一個季度。