DeepSeek V4 每百萬Token費用：完整計算機

嘿，大家好。我是 Dora。

上個月我花了三週時間在正式環境中運行 DeepSeek V4。我的月費帳單是 18 美元。同樣的工作量在 GPT-4o 上大約需要 380 美元。在 Claude Opus 4.5 上，則接近 720 美元。

這個差距讓我認真深入研究這些數字——不是為了慶祝便宜的算力，而是為了了解這個定價在實際使用中是否站得住腳，以及隱藏成本藏在哪裡。

上線時的公佈定價（已驗證表格）

DeepSeek V4 的官方定價已正式上線：

標準費率（每 100 萬 tokens）：

輸入 tokens（快取未命中）：$0.30
輸入 tokens（快取命中）：$0.03
輸出 tokens：$0.50

離峰費率（每 100 萬 tokens）：

輸入 tokens（快取未命中）：$0.15
輸入 tokens（快取命中）：$0.015
輸出 tokens：$0.25

快取命中折扣為 90%。這意味著如果你的提示詞中包含重複元素——系統指令、工具定義、文件範本——在第一次請求之後，成本會大幅下降。

輸入 tokens——標準 vs 快取命中 vs 離峰

當 DeepSeek 識別到你的提示詞中有部分內容最近已處理過並重複使用計算結果時，就會發生快取命中。這只適用於一致的前綴——即在各次呼叫之間不會改變的系統指令或工具定義。

我用一個研究摘要工具測試了這一點。系統提示詞和提取 schema 在多次執行中保持不變。從第一次請求之後，快取命中率維持在 65-70% 左右。我的有效輸入成本從每百萬 tokens $0.30 降至大約 $0.12。

離峰定價約在北京時間（UTC+8）晚上 11 點至早上 7 點之間執行，所有 token 類型享有 50% 折扣。我將每週的批次作業安排在北京時間凌晨 2 點。相同的工作量，成本減半。由於批次處理不在意延遲，這個取捨非常直接明瞭。

輸出 tokens——標準 vs 離峰

輸出 tokens 成本較高，因為生成需要序列運算——模型無法像處理輸入那樣並行化輸出。以標準每百萬 $0.50 或離峰 $0.25 來說，你支付的費用仍然低於大多數模型僅輸入就收取的費用。

GPT-4o 每百萬輸出 tokens 收費 $2.50。Claude Opus 4.5 收費 $15。就我的使用情境——從 3000-5000 tokens 的輸入生成 800-1200 tokens 的摘要——即使沒有快取優勢，輸出成本仍低於輸入成本。

V4 與 V3 定價比較

V4 上線時的定價為輸入 $0.30 / 輸出 $0.50，而 V3 在 2024 年 12 月底推出時的定價為 $0.14 / $0.28。絕對值上大約提升了 15%。

這個漲幅反映了真實的架構改進：更長的上下文視窗（最高達 100 萬 tokens）、更好的工具呼叫準確性，以及 V3 中沒有的混合推理模式。改變的不只是價格，而是能力與成本的比率。V4 在 SWE-bench Verified 上得分 81%，相比 V3 的 69%，意味著你只需支付 1.14 倍的成本，就能獲得顯著更好的性能。

為什麼 DeepSeek 比 OpenAI 便宜 20-50 倍

定價差距不是行銷手法，而是架構效率轉化為運營成本的結果。

MoE 架構：6710 億總參數，370 億活躍參數

DeepSeek V4 採用混合專家架構，總參數量達 6710 億，但每個 token 只激活 370 億個參數。當你發送請求時，模型的路由機制從 256 個專家池中選取 8 個專門化專家，再加上一個處理所有內容的共享專家，共 9 個專家負責計算，其餘 247 個保持休眠狀態。

這很重要，因為計算成本與活躍參數成比例，而非總參數。與 GPT-4 等稠密模型相比，後者對每個 token 都會激活所有參數。像 Llama 3.1 這樣的 4050 億參數模型，每個 token 大約需要 2448 GFLOP。DeepSeek V4 大約需要 250 GFLOP——計算量少了近 10 倍。

這種效率也體現在部署需求上。V4 可以在配備雙 RTX 4090 的單台伺服器上運行較小的工作負載。具有相當能力的稠密模型則需要多節點 GPU 叢集。硬體成本在數百萬次 API 呼叫中不斷累積，這些節省最終反映在定價上。效率提升部分來自 DeepSeek 的流形約束超連接（mHC）架構，它優化了專家層之間的路由。

訓練成本（560 萬美元 vs GPT-4 的 1 億美元以上）

DeepSeek 使用 278.8 萬個 H800 GPU 小時，在 14.8 兆個 tokens 上以 560 萬美元的成本訓練了 V3。業界估計 GPT-4 的訓練成本約為 1 億美元或更多——大約高出 18 倍。

這個差距來自兩個因素：MoE 架構在相似能力水準下的訓練速度快於稠密模型，而且 DeepSeek 使用了成本低於 H100 的 H800 GPU，同時仍能提供足夠的性能。

較低的訓練成本不一定意味著較低的推理價格——公司可以按照市場能承受的價格收費——但 DeepSeek 一直在持續傳遞這些節省。V2、V3 和 V4 的上線定價均低於前沿模型水準，同時在關鍵基準測試中達到或超越其性能。這種模式表明定價是可持續的，而非暫時的。

實際成本計算範本

輸入：每日 tokens 數、快取命中率、離峰百分比

重要的變數：

每日輸入/輸出 tokens 總量
快取命中率（0-100%）
離峰使用百分比（0-100%）
每月天數

計算方式很直接：

cacheable_input = (input_tokens × cache_hit_rate × $0.03) / 1M
non_cacheable_input = (input_tokens × (1 - cache_hit_rate) × $0.30) / 1M
output_cost = (output_tokens × $0.50) / 1M
daily_cost = cacheable_input + non_cacheable_input + output_cost

套用離峰折扣（離峰時段享 50% 折扣）
monthly_cost = adjusted_daily_cost × 30

範例：每日 1000 萬 tokens 工作量

每日處理 1000 萬 tokens 的工作負載通常分為約 600 萬輸入和 400 萬輸出 tokens。這個比例對於摘要、改寫或內容生成任務很常見。

假設條件：

40% 快取命中率（對於具有一致系統提示詞的工作流程而言較為保守）
30% 離峰使用率（批次作業安排在夜間）
V4 標準定價

每日成本明細：

可快取輸入：(6M × 0.40 × $0.03) / 1M = $0.072
不可快取輸入：(6M × 0.60 × $0.30) / 1M = $1.08
輸出：(4M × $0.50) / 1M = $2.00
離峰前總計：$3.15

加入 30% 離峰排程後：

標準部分（70%）：$2.21
離峰部分（30% × 50% 折扣）：$0.47
調整後每日：$2.68/天，即 $80.40/月

作為比較，同樣每日 1000 萬 tokens 的工作量將花費：

GPT-4o：約 $450/月
Claude Opus 4.5：約 $900/月
DeepSeek V4：$80.40/月

在相當能力水準下，成本降低了 82-91%。

範例：快取命中率 80% 的 RAG 管道

檢索增強生成管道的快取命中率較高，因為相似查詢之間的檢索內容往往存在重疊。

一個每日回答 1000 次查詢的 RAG 系統：

每次查詢 8000 個輸入 tokens（2000 用於用戶問題 + 6000 用於檢索內容）
每次查詢 500 個輸出 tokens（生成的回答）
80% 快取命中率（文件片段在查詢間重複使用）
0% 離峰（面向用戶，需要即時回應）

每日成本：

總輸入：800 萬 tokens
可快取：(8M × 0.80 × $0.03) / 1M = $0.192
不可快取：(8M × 0.20 × $0.30) / 1M = $0.48
輸出：(500K × $0.50) / 1M = $0.25
每日總計：$0.92
每月：$27.66

不使用快取時，這個工作量每月需要 $122.50。適當的快取優化每月可節省約 $95——降低了 77%。這就是為什麼結構化、可重複的提示詞比看起來更加重要。

需要納入預算的隱藏成本

觸發速率限制時的重試開銷

DeepSeek 執行的速率限制約為每分鐘 ~10 萬 TPM 和 ~500 RPM（根據 V3 行為和測試結果）。當你觸及限制時，API 返回 429 狀態碼，你需要以退避方式重試。在一次刻意超出限制的測試中，約 8% 的請求需要重試一次，2% 需要重試兩次。重試的 token 成本為零（失敗的請求不計費），但對時間敏感的工作負載而言，延遲很重要。

長上下文（100 萬 tokens）請求

單次 100 萬 tokens 的輸入成本為 $0.30。如果你每天處理 100 份文件，光是輸入每月就需要 $270。更重要的是，長上下文請求需要更長時間——我的測試顯示，50 萬 tokens 的輸入從請求到第一個 token 需要 12-18 秒，而 1 萬 tokens 的輸入只需 2-3 秒。對於大多數使用情境，對文件進行分塊處理可以獲得更好的成本和延遲效果。

工具呼叫導致的 token 膨脹

工具定義會消耗輸入 tokens。一個典型的工具需要 150-300 個 tokens。如果暴露了 20 個工具，每次請求就會額外增加 3000-6000 個 tokens。工具呼叫還會使輸出膨脹，因為模型會為每次呼叫生成結構化 JSON（每次呼叫 50-150 個 tokens）。我測試的 15 個工具的代理程式，每次請求平均額外產生 250 個輸出 tokens。解決方案：只在每種請求類型中包含相關的工具。