DeepSeek V4 本地部署可行性：Pro 與 Flash 參數、記憶體估算和 API 選擇

DeepSeek V4 不能按普通 7B、32B 模型的方式理解。官方公佈的兩個版本都是 MoE 模型：

• DeepSeek-V4-Pro：約 1.6T 總參數，每個 token 啟用約 49B 參數；
• DeepSeek-V4-Flash：約 284B 總參數，每個 token 啟用約 13B 參數。

“活化參數少”主要影響單步計算量，不代表只需要為活化參數準備顯存。如果完整權重都參與路由，仍需存放全部專家權重。對單張消費級顯示卡而言，官方 API 通常比完整本地部署現實得多。

先區分官方事實與本文估算

官方釋出說明可以確認模型名稱、總參數、活化參數、上下文和 API 變更。下面的低位元體積則是數學估算，不是某個官方 GGUF 檔案的實測值，也不表示社群已經提供可直接執行的量化包。

最基礎的權重體積公式是：

1

权重体积（GiB）≈ 参数量 × 每参数位数 ÷ 8 ÷ 1024³

量化還會增加分組 scale、後設資料和對齊開銷；推理還需要 KV cache、執行時緩衝區和通訊空間，所以實際記憶體一定高於裸權重。

理論權重體積

這些數字只回答“權重至少多大”。例如 Flash 的 4-bit 權重理論上約 132 GiB，實際部署還要為量化後設資料、KV cache和後端緩衝預留空間。Pro 即使 4-bit，也已是多機或高階多卡伺服器範圍。

上下文為什麼會繼續吃記憶體

KV cache 與以下因素有關：

• 上下文 token 數；
• 併發請求數和批大小；
• KV cache 資料型別；
• 模型層數、注意力結構和後端實現；
• 是否啟用字首快取或其他最佳化。

因此“支援 1M 上下文”不等於本地必須以 1M 啟動，更不等於顯存不變。部署評估應從 4K 或 8K 上下文、單併發開始，再逐級增加並記錄峰值。

哪類機器才值得嘗試

“能載入”與“可互動使用”是兩回事。大量 CPU offload 可能使首 token 和生成速度低到沒有實用價值。

使用官方 API 的最小驗證

DeepSeek 官方說明 V4 提供 OpenAI Chat Completions 相容呼叫。先在環境變數儲存金鑰，再發最小請求：

1
2
3
4
5

$env:DEEPSEEK_API_KEY = "你的密钥"
curl.exe https://api.deepseek.com/chat/completions `
  -H "Authorization: Bearer $env:DEEPSEEK_API_KEY" `
  -H "Content-Type: application/json" `
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"只回复 OK"}]}'

成功時應返回 JSON，並在響應的 choices 中看到助手訊息。若返回 401，先檢查金鑰；若返回模型不存在，應查官方模型列表，不要用舊文章裡的名稱反覆重試。

官方公告指出，V4 上線後舊的 deepseek-chat 和 deepseek-reasoner 已進入遷移流程。模型名稱、價格和退役時間會變化，生產配置必須以當前 API 文件為準。

本地量化包的核驗清單

如果社群以後出現 V4 量化權重，至少核對：

1. 上游是否指向 DeepSeek 官方權重倉庫；
2. 檔案是否覆蓋所有分片和專家；
3. 量化演算法、校準資料和推理後端是否公開；
4. 後端是否明確支援該 MoE 架構，而不只是能讀取檔案頭；
5. 測試結果是否寫明 GPU、CPU、RAM、上下文、併發和 tokens/s；
6. 雜湊、許可證和下載來源是否可複核。

沒有真實檔案與後端測試時，只能釋出“容量估算”，不能寫成“某顯示卡實測可跑”。

先確認你拿到的到底是什麼

討論“本地部署 V4”之前，應把下載物件分成四類：

1. 官方完整權重；
2. 官方 API 模型名稱；
3. 第三方量化或轉換權重；
4. 只有相似名稱的非官方衍生模型。

API 名稱不能用來證明權重已經公開；一個 Hugging Face 倉庫也不能僅憑標題證明包含完整 V4。若檔案只有幾 GB，它更可能是介面卡、配置、tokenizer、索引或不完整分片。

在下載數百 GB 檔案前，先檢查倉庫檔案列表和總大小，並確認所有 shard 的編號連續。

從裸權重推導伺服器下限

容量規劃不能用“總顯存剛好等於權重”作為方案。以 V4 Flash 的 4-bit 理論值約 132 GiB 為例，還要預留：

• 量化 scale、分組資訊和後設資料；
• KV cache；
• CUDA/ROCm 上下文；
• 啟用與臨時計算緩衝；
• 推理框架自身佔用；
• 多卡通訊與容錯餘量。

工程上通常需要保留可觀的餘量，而不是把每張卡佔到 100%。具體比例必須由目標框架的真實日誌確認。

多卡容量只是第一關

假設多張 GPU 的合計顯存能裝下 Flash，還需要確認：

• 框架是否支援 V4 的專家路由；
• 權重能否按專家或張量合理切分；
• 卡間使用 NVLink、PCIe 還是跨機網路；
• 是否存在一張卡承擔額外 embedding、輸出層或快取；
• 最慢鏈路是否拖累整個請求；
• 單機電源、散熱和主機板通道是否足夠。

顯存相加只能說明容量可能夠，不能證明推理能啟動，更不能證明速度可用。

伺服器方案應怎樣做小步驗證

如果確實要研究本地 V4，建議把驗收分成以下層次：

層次一：識別配置

只讀取配置和權重索引，確認模型型別、分片數量、dtype 和專家參數能被當前框架識別。此時不要先分配全部 GPU。

層次二：載入短上下文

以單請求、最短可用上下文啟動。記錄每張 GPU 和主機記憶體的佔用，確認沒有 silent fallback 到 CPU 或磁碟對映。

層次三：生成固定短回答

用確定性提示測試 32–64 個輸出 token，觀察首 token 延遲、生成速度、錯誤日誌和跨卡通訊。

層次四：逐漸增加上下文

按 4K、8K、16K 增長，不要直接測試極限上下文。每次重啟並記錄峰值，以排除上一次快取影響。

層次五：增加併發

只有單請求穩定後才測試併發。併發會改變快取、排程和吞吐，可能讓單請求可用的配置立即 OOM。

一份可信的多卡實測需要哪些資料

至少公開：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

模型仓库与 commit：
权重格式与量化方法：
推理框架与 commit：
GPU 型号、数量、单卡显存：
CPU、系统内存、NUMA：
卡间连接与网络：
上下文、输入/输出 token：
并发与批大小：
每卡峰值显存：
首 token 延迟、tokens/s、总吞吐：
是否使用 CPU offload 或磁盘映射：

缺少模型檔案和框架版本時，速度數字無法復現；缺少上下文和併發時，顯存數字也沒有比較意義。

官方 API 的生產驗收

最小請求成功後，還要驗證延遲、用量、錯誤處理和模型切換。

PowerShell 可記錄一次請求總時長：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$headers = @{
  Authorization = "Bearer $env:DEEPSEEK_API_KEY"
  'Content-Type' = 'application/json'
}

$payload = @{
  model = 'deepseek-v4-flash'
  messages = @(
    @{ role = 'user'; content = '将这段日志归纳为三条排错建议。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

$elapsed = Measure-Command {
  $response = Invoke-RestMethod `
    -Uri 'https://api.deepseek.com/chat/completions' `
    -Method Post `
    -Headers $headers `
    -Body $payload
}

$elapsed.TotalSeconds
$response.usage
$response.choices[0].message.content

記錄 usage 能幫助核對輸入、輸出和快取計費；具體欄位與價格以當前官方 API 文件為準。

從舊模型名稱遷移

不要只在配置檔案裡替換字串。完整遷移要檢查：

• 新模型名稱是否在當前賬號和區域可用；
• system prompt 與取樣參數是否仍相容；
• 流式響應事件是否變化；
• 工具呼叫結構是否被客戶端正確解析；
• 最大輸出、上下文和超時是否需要調整；
• 舊模型回滾入口是否仍保留。

先複製一份生產請求做影子測試，比較回答質量、延遲、token 用量和失敗率，再逐步切換流量。

錯誤碼要分層處理

生產客戶端應使用指數退避和最大重試次數，並記錄服務返回的請求標識。涉及賬單或資料問題時，這些資訊比截圖更有用。

金鑰與資料邊界

API key 應放在環境變數、系統憑據庫或團隊秘密管理器中。不要把它寫入 Markdown、Git 配置、前端 JavaScript或共享截圖。

向雲端 API 傳送公司資料前，還要明確：

• 哪些欄位包含個人資訊或商業秘密；
• 是否需要脫敏；
• 日誌會保留請求正文還是隻保留指標；
• 團隊成員是否共用金鑰；
• 金鑰洩露後的輪換和撤銷流程。

如果資料政策要求完全離線，應選擇能夠在現有硬體上穩定部署的較小開放權重模型，而不是用不透明的第三方中轉冒充“本地”。

如何識別誇張的單卡宣傳

以下表述需要額外證據：

• “49B active，所以只需 49B 的顯存”；
• “4-bit 等於總參數直接除以二”；
• “1M 上下文不增加顯存”；
• “單卡載入成功，因此可流暢執行”；
• “使用同名模型，所以一定是官方 V4”；
• “截圖顯示 20GB，佔用就是完整模型”。

可信報告必須解釋權重是否完整、多少層在 CPU、是否使用遠端 API，以及速度如何測得。

API 與本地模型怎麼選

選擇依據應是任務、資料邊界、延遲和總成本，而不是隻比較參數量。

決策建議

• 個人和普通開發團隊：優先使用官方 API；
• 資料不能離開內網：先評估更小的開放權重模型，而不是強行載入 V4；
• 做推理框架研究：從 Flash、短上下文、單併發開始，並完整記錄軟硬體；
• 看到精確的單卡速度或顯存表：先查量化檔案、後端日誌和測試配置是否公開。

DeepSeek 官方入口

• DeepSeek V4 官方釋出說明
• DeepSeek API 文件