最近 DeepSeek API 調(diào)價的討論熱度很高。網(wǎng)上有“漲價 30 倍”的說法也有不少開發(fā)者曬出自己的賬單表示新價格下成本壓力明顯變大。但在同一波討論里也出現(xiàn)了另一個看似矛盾的觀點漲價之后的 DeepSeek仍然是當(dāng)前大模型 API 里絕對價格最便宜的一檔。這兩個真相同時成立才是這次調(diào)價事件最有意思的地方。這篇文章不打算復(fù)述新聞而是把“漲價 30 倍”這個數(shù)字是怎么來的、DeepSeek 的計費結(jié)構(gòu)到底怎么算、漲價之后項目還值不值得繼續(xù)接入這些事從頭到尾講清楚。我會給出完整的 API 調(diào)用示例、VSCode/Codex/企業(yè)微信等工具鏈的接入思路并把最近社區(qū)里高頻出現(xiàn)的reasoning_content報錯單獨拆出來分析。不管你是個人開發(fā)者還是團(tuán)隊負(fù)責(zé)人讀完后應(yīng)該能自己算明白漲價之后你的項目用 DeepSeek 到底貴了多少。1. 背景漲價 30 倍是怎么回事1.1 優(yōu)惠期結(jié)束價格回到正常區(qū)間DeepSeek API 早期為了快速積累開發(fā)者生態(tài)推出過力度非常大的限時優(yōu)惠活動。優(yōu)惠期內(nèi)輸入、輸出 token 的單價都被壓到了極低水平很多開發(fā)者習(xí)慣性地把“白菜價”當(dāng)成了 DeepSeek 的常駐價格。優(yōu)惠活動結(jié)束后API 價格恢復(fù)至常態(tài)價格部分計費梯度在活動前后對比之下出現(xiàn)了非常懸殊的倍率差?！皾q價 30 倍”這個數(shù)字正是社區(qū)根據(jù)活動價和恢復(fù)價之間的倍率對比得出的。需要注意的是這不是所有模型、所有計費維度都漲了 30 倍。DeepSeek 的計費維度包含輸入價格、輸出價格、緩存命中價格、緩存未命中價格不同維度在活動前后的優(yōu)惠力度不同恢復(fù)后的最終定價也不同。所以“30 倍”更像是一個最極端的對比口徑真實成本影響取決于你的請求模式。如果項目里大部分請求都能命中上下文緩存實際支出的漲幅會遠(yuǎn)遠(yuǎn)小于標(biāo)題里的數(shù)字。1.2 為什么漲價之后仍然是最便宜的一檔價格回調(diào)之后DeepSeek 的絕對單價放在全球大模型 API 市場里依然處于低價側(cè)這不是營銷話術(shù)背后有幾個實實在在的技術(shù)原因。第一DeepSeek 采用 MoE混合專家架構(gòu)單次推理只激活全部參數(shù)的一小部分單位 token 的推理成本被明顯壓縮。成本低定價空間就大。第二DeepSeek 開放了模型權(quán)重企業(yè)如果對成本極度敏感完全可以自己部署一套API 價格如果定得太高反而會把用戶推向自部署方案。第三DeepSeek 在上下文緩存、KV Cache 復(fù)用、推理引擎優(yōu)化上持續(xù)投入緩存命中價格遠(yuǎn)低于未命中價格高頻業(yè)務(wù)的實際成本被進(jìn)一步攤薄。所以準(zhǔn)確的說法是DeepSeek 的“標(biāo)價”漲了但它的“成本結(jié)構(gòu)”沒有變漲價只是把促銷期的補(bǔ)貼收回了。考慮到它仍能提供長上下文、開源權(quán)重、OpenAI 兼容協(xié)議這些條件漲價后它依然是大模型 API 里性價比很高的一檔。1.3 這次調(diào)價對開發(fā)者的實際影響調(diào)價對不同類型的項目影響差異很大。偶爾調(diào)用、個人練手場景幾乎感受不到變化但批量離線任務(wù)、Agent 多輪對話、代碼補(bǔ)全這類高頻調(diào)用場景月度賬單會有明顯波動。其中受影響最大的是思考型模型reasoner的長時間推理任務(wù)因為這類任務(wù)輸出 token 多、單次耗時長輸出單價在計費結(jié)構(gòu)里本身就是最高的。企業(yè)側(cè)更常見的應(yīng)對思路是混合方案簡單分類、抽取、格式化任務(wù)放到開源小模型或本地模型上復(fù)雜推理、數(shù)學(xué)、代碼生成任務(wù)繼續(xù)走 DeepSeek API。這樣既控制成本又不犧牲關(guān)鍵場景的模型能力。2. 看懂 DeepSeek 的計費模型2.1 四個核心計費維度DeepSeek 開放平臺的計費并不是簡單的“輸入多少錢、輸出多少錢”而是分成四個維度計費項含義價格檔位輸入緩存未命中首次請求或上下文前綴無法命中緩存時輸入 token 的單價較高輸入緩存命中相同上下文前綴命中系統(tǒng)緩存時輸入 token 的單價最低輸出模型生成內(nèi)容的 token 單價最高上下文緩存系統(tǒng)自動為相同前綴建立緩存無需手動開啟命中與否決定成本需要說明的是具體價格會隨著官方策略調(diào)整而變化任何網(wǎng)上的截圖都可能過期。最準(zhǔn)確的做法是登錄 DeepSeek 開放平臺控制臺查看“價格計算器”或最新價目表。本文重點講計算思路示例中的價格數(shù)字只用于演示不要直接當(dāng)成真實報價。2.2 單次請求成本計算公式一次 API 調(diào)用的費用可以拆成三部分單次請求費用 輸入未命中 token × 未命中單價 輸入命中 token × 命中單價 輸出 token × 輸出單價這里的關(guān)鍵點在于“輸入 token”并不是一個固定數(shù)字。DeepSeek 支持自動上下文緩存如果多輪對話的前綴沒有變化第二次請求的相同部分就能按緩存命中價格計費價格可能只有未命中價的四分之一甚至更低。所以同一個功能不同寫法的成本差異可以非常大。2.3 用 Python 腳本估算成本為了不讓“漲價 30 倍”停留在口頭上我寫了一個簡單的成本估算函數(shù)你可以把官方最新的單價填進(jìn)去折算自己項目的 token 分布# 文件路徑estimate_cost.py def estimate_cost( input_tokens: int, output_tokens: int, cache_hit_tokens: int 0, price_input_miss: float 2.0, # 示例價元/百萬 token price_input_hit: float 0.5, # 示例價元/百萬 token price_output: float 8.0, # 示例價元/百萬 token ) - float: 估算單次請求費用最終結(jié)果以元為單位。 input_miss_tokens max(0, input_tokens - cache_hit_tokens) cost ( input_miss_tokens * price_input_miss cache_hit_tokens * price_input_hit output_tokens * price_output ) return cost / 1_000_000 # 場景一次 4000 輸入 800 輸出的請求 # 假設(shè) 3000 個輸入 token 命中了緩存 cost estimate_cost( input_tokens4000, output_tokens800, cache_hit_tokens3000, ) print(f單次請求估算成本{cost:.4f} 元)函數(shù)里的價格參數(shù)是示例值實際使用時替換為控制臺的最新單價即可。你只需要把自己的請求日志里的 token 統(tǒng)計導(dǎo)出來套用這個函數(shù)就能得到比較接近真實賬單的月度成本。2.4 一個典型 Agent 場景的賬以 Agent 多輪工具調(diào)用為例。每輪對話都需要把系統(tǒng)提示詞、歷史消息、工具定義重新發(fā)給模型輸入 token 會隨輪數(shù)線性增長。假設(shè)單輪輸入 5000 token、輸出 800 token連續(xù)對話 20 輪如果每一輪都完整攜帶歷史累計輸入高達(dá) 10 萬 token。這種情況下緩存命中與否對最終賬單影響巨大。把系統(tǒng)提示詞固定、保持消息前綴穩(wěn)定讓后續(xù)輪次命中緩存輸入成本可能下降 50% 以上。這也是為什么很多 Agent 框架都會強(qiáng)調(diào)“system prompt 保持穩(wěn)定”的原因。它不只是為了效果一致更是為了省錢。3. DeepSeek API 快速接入3.1 創(chuàng)建 API Key 的前置步驟接入 DeepSeek API 之前需要先在開放平臺完成三件事注冊賬號、創(chuàng)建 API Key、為賬戶充值。創(chuàng)建 API Key 時注意Key 通常只在創(chuàng)建頁面完整展示一次關(guān)閉后無法再次查看務(wù)必復(fù)制保存到本地密碼管理器。生產(chǎn)環(huán)境強(qiáng)烈建議把 Key 放在環(huán)境變量或密鑰管理服務(wù)中而不是寫死在代碼里。后續(xù)所有代碼示例都會讀取DEEPSEEK_API_KEY環(huán)境變量。export DEEPSEEK_API_KEYsk-你的密鑰3.2 用 curl 發(fā)起第一個請求DeepSeek API 兼容 OpenAI 協(xié)議所以請求結(jié)構(gòu)和 OpenAI 基本一致。下面是最簡單的非流式調(diào)用curl https://api.deepseek.com/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -d { model: deepseek-chat, messages: [ {role: user, content: 用一句話介紹 DeepSeek API} ], stream: false }這里有兩個細(xì)節(jié)。model字段決定使用哪個模型deepseek-chat是通用對話模型適合大部分日常任務(wù)如果要做數(shù)學(xué)、邏輯推理可以換成deepseek-reasoner它的思考能力更強(qiáng)但延遲和成本也更高。base_url可以寫https://api.deepseek.com也可以寫https://api.deepseek.com/v1兩者對兼容層都做了支持。3.3 用 OpenAI SDK 調(diào)用 DeepSeek因為協(xié)議兼容Python 項目里可以直接使用官方openai庫只需要修改base_url。先安裝依賴pip install openai然后編寫調(diào)用代碼# 文件路徑deepseek_demo.py from openai import OpenAI client OpenAI( api_keysk-你的密鑰, base_urlhttps://api.deepseek.com, ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: user, content: 請用一段話說明項目周報該怎么寫} ], streamFalse, ) print(resp.choices[0].message.content)這段代碼就是完整的可運行示例。相比直接拼 HTTP 請求用 SDK 的好處是自動處理重試、超時和錯誤解析后續(xù)接流式輸出也只需要把stream設(shè)為True。3.4 思考模式與 reasoning_content使用deepseek-reasoner這類思考型模型時響應(yīng)里除了常規(guī)的content字段還會多出一個reasoning_content字段表示模型的內(nèi)部思考過程。在 OpenAI 官方協(xié)議里沒有這個字段這是 DeepSeek 的擴(kuò)展。代碼里可以這樣訪問resp client.chat.completions.create( modeldeepseek-reasoner, messages[ {role: user, content: 8 個人 6 天完成的工作量4 個人需要幾天} ], ) # 模型內(nèi)部思考過程 print(resp.choices[0].message.reasoning_content) # 最終回答 print(resp.choices[0].message.content)這個reasoning_content字段是后文報錯分析的核心很多第三方工具在轉(zhuǎn)換協(xié)議時就是栽在它身上先記住它的存在。4. 開發(fā)工具鏈接入 DeepSeek4.1 VSCode 插件接入 DeepSeekVSCode 接入 DeepSeek 最常用的方式是安裝 Continue 或 Cline 這類 AI 編程插件然后把模型 Provider 指向 DeepSeek。以 Continue 為例編輯它的配置文件config.json{ models: [ { title: DeepSeek Chat, provider: openai, model: deepseek-chat, apiBase: https://api.deepseek.com/v1, apiKey: sk-你的密鑰 } ] }不同插件的配置字段名可能略有差異但核心就是三樣API Key、Base URL、模型名。配置完成后就可以在側(cè)邊欄直接提問也能對選中代碼做解釋、補(bǔ)全或單測生成。這類插件本質(zhì)上都是把編輯器里的對話請求轉(zhuǎn)發(fā)到 API所以計費方式和你自己寫代碼調(diào)用完全一致插件本身不會額外產(chǎn)生模型費用。4.2 Codex 接入 DeepSeek 的協(xié)議問題Codex CLI 默認(rèn)走的是 OpenAI 的 Responses 協(xié)議而 DeepSeek 官方主要提供 Chat Completions 協(xié)議兩者不能直接互通。要在 Codex 里用 DeepSeek通常有兩種做法。第一種是修改 Codex 的config.toml自定義一個 Provider 指向 DeepSeek讓 Codex 直接走 Chat Completions。社區(qū)常見寫法如下但不同版本字段差異較大請以你安裝版本的官方文檔為準(zhǔn)model deepseek-chat [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat第二種做法是在中間加一個本地代理工具例如 CC Switch。Codex 請求發(fā)到本地代理代理把 Responses 協(xié)議轉(zhuǎn)換成 Chat Completions 再轉(zhuǎn)發(fā)給 DeepSeek。這樣做的好處是 Codex 配置不用大改但代價是多了一層協(xié)議轉(zhuǎn)換容易引入新的兼容問題第 5 節(jié)要講的報錯就是這么來的。4.3 Harness、Hermes 等桌面工具怎么用最近社區(qū)里出現(xiàn)了不少圍繞 DeepSeek 生態(tài)的桌面客戶端和插件Harness、Hermes 等名字頻繁出現(xiàn)在討論中。這些工具大多是社區(qū)開發(fā)者或第三方團(tuán)隊做的客戶端殼并不是 DeepSeek 官方統(tǒng)一發(fā)布的家族產(chǎn)品它們的使用方式大同小異下載安裝后填入自己的 API Key選擇模型名有些還會要求填 Base URL。在使用這類工具時有三條建議。第一盡量從開源倉庫或作者官網(wǎng)下載警惕來路不明的打包安裝包。第二安裝后先看一下版本號兼容問題往往在新版本中修復(fù)得很快。第三桌面工具本質(zhì)上還是調(diào)用官方 API官方模型能力和價格不會因為換了客戶端而改變別被工具宣傳里的“免費”“無限”誤導(dǎo)。4.4 企業(yè)微信群機(jī)器人接入 DeepSeek企業(yè)微信接入 DeepSeek 最常見的場景是群機(jī)器人通知。企業(yè)微信群機(jī)器人提供 Webhook 地址往這個地址 POST 一段 JSON就能把內(nèi)容推送到群里。結(jié)合 DeepSeek 生成內(nèi)容可以實現(xiàn)“定時生成周報推送到群”“自動總結(jié)并通知”這類小工具。# 文件路徑wechat_robot.py import requests from openai import OpenAI def notify_wechat(webhook_url: str, text: str): payload { msgtype: text, text: {content: text} } resp requests.post(webhook_url, jsonpayload, timeout10) resp.raise_for_status() return resp.json() # 1. 調(diào)用 DeepSeek 生成內(nèi)容 client OpenAI(api_keysk-你的密鑰, base_urlhttps://api.deepseek.com) answer client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 寫一條 50 字以內(nèi)的項目周報}] ).choices[0].message.content # 2. 推送到企業(yè)微信群 webhook_url https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key你的key notify_wechat(webhook_url, answer)注意這種 Webhook 方式適合“單向通知”場景。如果要做“群內(nèi) 機(jī)器人提問、機(jī)器人自動回答”的交互需要額外部署一個接收回調(diào)的服務(wù)并且處理企業(yè)微信的簽名校驗和消息加解密復(fù)雜度要高出不少建議先從小通知場景起步。5. 高頻報錯reasoning_content 必須回傳5.1 報錯現(xiàn)象最近很多人在 CC Switch 這類本地代理工具中接入 DeepSeek 時遇到如下報錯cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the reasoning_content in the thinking mode must be passed back to the api.從日志可以看出請求先經(jīng)過 Code