WaveSpeedAI

DeepSeek V4 定價：比 OpenAI 便宜 20-50 倍（成本分析）

DeepSeek V4 定價：比 OpenAI 便宜 20-50 倍（成本分析）

最近，我在尋找一個更安靜的模型，一個我可以頻繁調用而不用每小時都看著計費表的模型。DeepSeek V4 在我與其他開發者的聊天中不斷出現，通常伴隨著一個驚訝的眼神：「它……真的很便宜。」

Dora 來了。我在 2026 年 1 月下半月花時間將它集成到幾個小工作流中：一個研究摘要工具、一個產品筆記重寫器，以及一個每週待辦事項管理器。沒什麼花哨的。我關心的是這些 token 在正常一週內轉化為實際美元的情況。以下是我關於 DeepSeek V4 API 成本、重要折扣以及在發布前預算的一個非常簡單的方法所學到的內容。

當前 DeepSeek 定價

我不會假裝這些數字是穩定的。價格會變動，並且根據你購買存取權的地點（直接購買 vs. 通過 OpenRouter 等代理）而有所不同。因此，有兩個參考點：

  • 檢查來源：官方 DeepSeek API 文檔 和定價頁面。當你直接連接時，這些是標準費率。
  • 如果你通過市場路由，打開他們的模型卡。例如，OpenRouter 上的 DeepSeek 模型列出每百萬 token 費率和任何基於時間的折扣。 我在 2026 年 1 月末在各個提供商上看到的情況在精神上是一致的：DeepSeek V4 對於輸入和輸出 token 都遠低於前沿模型。具體的美分數額各不相同。我分享的是我如何處理定價，而不是將其凍結在某個地方。

標準費率

如果你剛開始接觸基於使用量的模型計費，有兩行很重要：

  • 輸入 token（你發送的內容）：每 100 萬 token 收費。
  • 輸出 token（你獲得的內容）：也按每 100 萬 token 收費，通常高於輸入。

在我的運行中，V4 的原始費率足夠低，以至於小的日常峰值不會造成傷害。這在批次工作中最明顯。例如，我的每週待辦事項管理器發送約 20 個提示，每個約 3,000-5,000 輸入 token，並接收約 1,000-2,000 輸出 token。即使使用保守的樣本費率，整個運行的總成本也保持在「咖啡錢」區域。

兩個實用注意事項：

  • 輸出膨脹會悄悄逼近你。如果你的提示鼓勵長思考，輸出行可能會使你的帳單翻倍。我設定了 max_tokens 上限並使風格更緊湊。節省了錢，獲得了更好的結果。
  • 塊大小很重要。如果你要摘要長文檔，你將為每個重疊的 token 付費。我從 1,600 token 重疊改為 400，但沒有損失質量。

緩存命中折扣（享受 90% 折扣）

這改變了我的心理計算。一些平台和模型供應商支援對重複前綴的提示進行緩存。如果你的提示的前 N 個 token 沒有變化（系統消息、共享指令、架構），緩存命中可以按陡峭的折扣計費。90% 折扣是我在一些供應商的緩存實現中看到的記錄數字（可用性不同：請在你的提供商的定價頁面上確認）。

這在實踐中的感覺如下：

  • 我的研究摘要工具共享一個長的、固定的系統提示和一個穩定的工具架構。只有源文本會改變。
  • 在第一次調用後，後續調用會對該共享前綴命中緩存。
  • 在遵守緩存計費的平台上，這些重用的 token 會降至折扣費率。

來自測試的兩個警告：

  • 「接近」不會被緩存。改變共享前綴中的一行，你就會錯過命中。
  • 大的、固定的架構可以自付成本。如果你可以將指令和工具合併到一個穩定的前綴中，做一次並使用緩存。

如果你的提供商沒有公開緩存，你仍然可以通過將重複的指導移到更短、更一致的系統提示中，並從用戶消息中修剪冗餘來模擬一些節省。

非高峰折扣（享受 75% 折扣）

一些市場已開始提供基於時間的折扣以平滑需求。我看到了有陡峭折扣的非高峰時段（數字如 50-75% 的折扣出現，但取決於轉售商和模型）。DeepSeek 模型傾向於參與，因為它們的經濟效益已經傾向於高效。

這對我有幫助的兩種方式：

  • 我將每週待辦事項工作安排在非高峰時段。相同的工作量，更低的成本行。
  • 我在晚上批量進行研究摘要。延遲無關緊要，但折扣很重要。

這並非普遍適用。如果你直接連接到 DeepSeek，檢查他們是否發布任何基於時間的定價。如果你通過代理，閱讀模型卡細則。差異可能足夠大以改變你運行內容的時間。

為什麼 DeepSeek 如此便宜

我想了解低價是否是促銷內容，或者架構是否確實支援它。根據公開的信息，有兩個部分突出。

MoE 架構

DeepSeek 的較新大模型依靠 混合專家 (MoE)。簡單來說：不是為每個 token 喚醒整個大腦，路由器選擇幾個專家子網絡來處理它。你仍然獲得一個能力強大的模型，但每步只有一小部分參數工作，這降低了計算和成本。

這在實踐中的重要性：

  • 吞吐量擴展性更好。在我這邊，即使我推動並行工作，p95 延遲仍然合理。
  • 成本不會隨著複雜性線性增加。長提示不會像在密集、始終開啟的模型上那樣嚴厲懲罰。

我使用過其他在小眾任務上感覺脆弱的 MoE 模型：V4 在結構密集的提示（JSON 輸出、工具使用）上處理得很好，沒有搖晃。這種穩定性也是成本故事的一部分：更少的重試，更少的重做。

Engram 效率

DeepSeek 的文檔提到了上下文處理和記憶效率的工作（他們在某些版本中提出了改進的注意力路由和 KV 緩存處理等內容）。我無法驗證內部情況，但我可以分享我觀察到的內容：

  • 長上下文提示在我 2026 年 1 月的測試中沒有降低吞吐量。我運行了 32K token 上下文，沒有「一切都變成泥沼」的感覺。
  • 確定性格式化在比我預期更高的溫度下保持，這意味著我可以保持輸出更短而不會降低質量。

我的看法：這個價格不是營銷花招。這是建築設計的結果，該設計旨在保持每個 token 的計算成本低，加上願意在票面價格上傳達這一點。如果你對技術說明感到好奇，請從官方 DeepSeek 文檔 和他們模型卡中的任何鏈接論文開始。

成本計算機模板

我不再將預算鎖定到確切的美分。我規劃範圍，然後在實際使用確定後進行調整。以下是我用於 DeepSeek V4 的模板。它足夠簡單，可以在電子表格中重新創建。

你將為每個工作量填寫的輸入：

  • 每天調用次數（或每個批次）
  • 每次調用的平均輸入 token
  • 每次調用的平均輸出 token
  • 每 100 萬 token 的輸入費率（來自你的提供商）
  • 每 100 萬 token 的輸出費率（來自你的提供商）
  • 每次調用的可緩存前綴 token（如果沒有則為 0）
  • 緩存命中折扣（例如，享受 90% 折扣時為 0.90）
  • 非高峰乘數（例如，享受 75% 折扣時為 0.25，否則為 1）

步驟：

  1. 分割可緩存和不可緩存的輸入 token。

    • cacheable_input = cacheable_prefix_tokens
    • variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)

  2. 以折扣費率對可緩存部分進行定價。

    • cacheable_cost = (cacheable_input / 1,000,000) × input_rate × (1 − cache_hit_discount)

  3. 以完整輸入費率對可變輸入進行定價。

    • variable_input_cost = (variable_input / 1,000,000) × input_rate

  4. 以輸出費率對輸出進行定價。

    • output_cost = (avg_output_tokens / 1,000,000) × output_rate

  5. 將它們相加每次調用，然後應用任何非高峰乘數。

    • raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
    • cost_per_call = raw_cost_per_call × off_peak_multiplier

  6. 按體積進行擴展。

    • daily_cost = cost_per_call × calls_per_day
    • monthly_cost ≈ daily_cost × 30

來自我測試週的一個小的、真實的例子（2026 年 1 月 23-30 日）：

  • 每天 120 次調用
  • 每次調用 3,200 輸入 token，其中 1,800 是固定的、可緩存的前綴
  • 每次調用 1,100 輸出 token
  • 例子費率：每 100 萬輸入 $0.40，每 100 萬輸出 $1.60（用你的實際費率替換）
  • 緩存命中折扣：90%
  • 非高峰乘數：0.5（通過轉售商使用 50% 折扣時段）

數學（四捨五入）：

  • 每次調用的可緩存成本 = (1,800/1,000,000) × $0.40 × (1 − 0.90) ≈ $0.0000072
  • 每次調用的可變輸入成本 = (1,400/1,000,000) × $0.40 ≈ $0.00056
  • 每次調用的輸出成本 = (1,100/1,000,000) × $1.60 ≈ $0.00176
  • 每次調用的原始成本 ≈ $0.0023272
  • 非高峰調整後 ≈ $0.0011636
  • 每日 ≈ $0.14
  • 每月 ≈ $4.20

這不是打字錯誤。低的每百萬費率加上緩存和非高峰，將一個「看著計費表」的服務變成了我可以忘記的東西。它一開始沒有節省時間，我花了一個小時使可緩存的前綴真正固定，但之後的每次調用都變得更便宜。

我在表格中保留的一些護欄：

  • 在 max_tokens 上設定硬上限。輸出膨脹是安靜的預算殺手。
  • 單獨追蹤重試。重試是實際支出。
  • 每週記錄平均 token。token 漂移在提示進展時發生。

適合的人：

  • 運行大量小型、相似調用的團隊（ETL、摘要、QA）。
  • 具有可以移至非高峰的批次工作的製造者。

可能不喜歡它的人：

  • 需要全天長的、流式輸出的應用，在高峰時段。節省額度縮小。
  • 沒有緩存支援的設置。你仍然會支付低費率，但不是傻傻的低費率。

如果你想要一個起點，在你選擇的工具中重新構建上面的模板。這是 10 分鐘的設置，可以節省之後的數小時猜測。

**最後一個註釋：**如果你混合提供商，在你的表格中將所有內容也標準化為「每 1K token 的成本」。當你決定是否保留 V4 在循環中或因質量原因將任務切換到前沿模型時，這使快速並排比較更容易。

我仍在觀察非高峰時段如何變化。最近它們在傍晚較早時移動。對於批次工作不是問題，只是我留意的東西。