DeepSeek V4 Pro (0813)：思考內容回傳與三種 API 對照表

本文整理 deepseek-v4-pro-0813 的使用須知與注意事項。AIHubMix 提供 Chat Completions、Responses 和 Claude 相容的 Messages API，可呼叫此模型。另請參閱：DeepSeek 官方 API 文件。

各節中標示為「已驗證」的結論與範例回應，皆來自 2026-08-13 透過 AIHubMix API（Chat Completions / Responses / Messages）實際發出的呼叫；未標示為「已驗證」的規格項目則出自 DeepSeek 官方文件。

1. 模型定位與規格一覽

V4 Pro 是 DeepSeek V4 系列的高階版本（輕量版 deepseek-v4-flash 則是同系列模型）。此系列可追溯至 2026-04-24 發布的 DeepSeek-V4 Preview，而 0813 是 DeepSeek 為目前版本指定的 MODEL VERSION 標籤。除了原始規格外，以下四項特色也讓它與眾不同：

• 稀疏型前沿模型：總參數量 1.6T / 啟用參數量 49B（採用 MoE，也就是專家混合架構——每次推論只會啟用部分專家網路：總參數量決定知識容量，啟用參數量則決定每次呼叫的運算成本）。模型卡列出 CSA+HCA 混合注意力、mHC 和 Muon 最佳化器。
• 採 MIT 授權開放權重：deepseek-ai/DeepSeek-V4-Pro 以 MIT 授權發布於 HuggingFace（這是限制最少的開源授權之一，允許商業用途和以閉源方式再散布），也可自行託管。對這種規模的模型而言，採用 MIT 授權並不常見。模型卡中的自架說明也指出，使用 Think Max（最高思考等級）執行時，上下文視窗建議為 ≥384K tokens——這是自架部署建議，不是託管 API 的規格。
• 原生支援多種協定，並非透過第三方轉換：DeepSeek 本身提供 OpenAI Chat API、Anthropic 相容端點（/anthropic，可將 claude-opus* 對應至此模型），以及 Responses API（DeepSeek 說明原生支援此格式，並針對 Codex 做了調整）。此外也提供 FIM（填補中間內容）補全 Beta 功能，使用獨立端點，不屬於 AIHubMix 的三種 API。
• 快取命中與未命中的價格相差約 120 倍：DeepSeek 公布的計價方式為快取命中 $0.003625/M、快取未命中 $0.435/M（輸出 $0.87/M），而快取會自動運作，無須設定參數。對於會重複使用長前綴（系統提示詞、長文件）的工作負載，這項價差會大幅影響帳單。實際零售價格以模型頁面所示為準。

已驗證：超過 max_tokens 限制時，會在驗證階段遭到拒絕，而不是直接截斷——傳送 max_tokens=9999999 會回傳 HTTP 400，錯誤內文會指出欄位名稱與上限 393216。

# max_tokens=9999999 -> HTTP 400
"...max_tokens... 393216"

❗ 圖片不會觸發錯誤，但會被丟棄：Responses API 的官方說明為「不支援圖片和檔案輸入（input_image 部分不會觸發錯誤，但會被替換為佔位文字）」——input_image 部分不會讓請求失敗，而是會被替換成佔位文字。Chat Completions 的使用者訊息 content 只接受字串，Messages 則將 type="image" 區塊標示為 Not Supported。建置多模態路由時，切勿將「沒有錯誤」視為模型確實讀取了圖片的證據。

2. 如何關閉思考模式？三種 API，三種欄位格式

V4 Pro 預設會進行思考：完全不傳任何參數，回應中也會包含思考內容。三種 API 關閉思考模式的欄位格式各不相同。

Chat Completions

使用頂層的 thinking 物件。

from openai import OpenAI

client = OpenAI(
    base_url="https://aihubmix.com/v1",
    api_key="<AIHUBMIX_API_KEY>",
)

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): message.reasoning_content present, reasoning_tokens = 43
# Thinking off (disabled): reasoning_content absent, reasoning_tokens absent

已驗證：設定 thinking.type="disabled" 後，message.reasoning_content 和 usage.completion_tokens_details.reasoning_tokens 會一併消失，確認切換已生效。

Responses

Responses 沒有獨立的開關；若要關閉思考模式，需將等級設為 none。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is 2 + 2?",
    reasoning={"effort": "none"},
)

# effort="none": usage.output_tokens_details.reasoning_tokens = 0
#                output[0] is the message item directly (no reasoning item)
# effort unset : output always starts with a reasoning item

已驗證：reasoning.effort="none" 與預設等級有可觀察到的差異（思考 tokens 降至零，且 reasoning 輸出項目消失），確認設定已生效。

Messages

欄位名稱與格式都和 Chat Completions 相同：頂層的 thinking 物件。

from anthropic import Anthropic

client = Anthropic(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com",
)

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    messages=[{"role": "user", "content": "What is 2 + 2?"}],
    extra_body={"thinking": {"type": "disabled"}},
)

# Thinking on  (default): content = [thinking block, text block]
# Thinking off (disabled): content = [text block]

已驗證：停用後，thinking 區塊會完全消失，只剩下 text 區塊。

關於思考等級：測試中，Chat Completions 的 low 和 max 都回傳 200（high 為預設值，省略欄位時會套用），但對同一個問題，不同等級的思考 token 數量並未呈現單調差異（簡單問題：low=43 / max=27；困難問題：low=114 / max=92），而且回應中也不會回傳等級資訊——系統會接受這些等級，但從回應中無法觀察到可區分的訊號。在 Responses 中，只有從回應端確認 none 等級（關閉思考模式）可行。

3. 為什麼多輪對話突然回傳 400？必須原封不動地回傳思考歷史

這是使用此模型時最常見的陷阱：在思考模式下，多輪對話必須原封不動地回傳前一輪的思考內容，否則請求就會遭到拒絕。不是效能降低，也不是品質變差，而是直接回傳 HTTP 400。

三種 API 會以不同欄位名稱傳遞相同的思考內容：

已驗證（觸發條件）：此驗證會穩定地在帶有 tools 的多輪請求中觸發（模型發出工具呼叫，接著再送回工具結果）。在本輪測試中，不含工具的純多輪請求若由模型直接回答，則不會觸發驗證，請求回傳 200。換句話說，工具協作流程（Agent／函式呼叫工作負載）最容易碰到這個問題，因此請將思考內容視為必須保存並重播的對話狀態之一。

Chat Completions

# Multi-turn: pass the previous assistant message back verbatim, including reasoning_content
messages = [
    {"role": "user", "content": "What is 1 + 1? Remember the result."},
    {
        "role": "assistant",
        "content": "2",
        "reasoning_content": "<reasoning_content from the previous response>",
    },
    {"role": "user", "content": "Add 1 to the result."},
]

# Dropping reasoning_content -> HTTP 400 invalid_request_error

已驗證：歷史中的 assistant 訊息若缺少 reasoning_content，就會回傳 400；補回該欄位後，相同請求就會回傳 200 並正確繼續執行。

Responses

# Multi-turn: input = previous input + response.output (reasoning item included) + new message
input = previous_input + response.output + [
    {"role": "user", "content": "Add 1 to the result."}
]

# Filtering out the type="reasoning" item -> HTTP 400

已驗證：只要將 response.output 原樣接回即可。組合歷史時若只保留 type == "message" 的輸出項目，就會漏掉 reasoning 項目並觸發 400——這是最常見的踩雷方式。

Messages

# Multi-turn: pass response.content back verbatim as the assistant message
messages = [
    {"role": "user", "content": "What's the weather in Paris?"},
    {"role": "assistant", "content": response.content},   # thinking + tool_use blocks
    {"role": "user", "content": [tool_result_block]},
]

# Stripping the thinking block -> HTTP 400

已驗證：從內容陣列中移除 thinking 區塊會回傳 400（error.type 的值為 invalid_request_error）。

4. 工具呼叫

各 API 使用各自協定格式來宣告工具，格式之間不能互換。

Chat Completions

巢狀格式（由 function 物件包住 name / parameters）。指定函式名稱的 tool_choice 可強制呼叫工具。

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get weather for a city",
            "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
        },
    }],
    tool_choice={"type": "function", "function": {"name": "get_weather"}},
)

# Observed: finish_reason "tool_calls", tool_calls[0].function.arguments = {"city": "Paris"}

❗ 已驗證：思考模式開啟時，不能使用 tool_choice: "required"——這會回傳 400 Thinking mode does not support this tool_choice；停用思考模式（thinking.type="disabled"）後，相同請求就會回傳 200。若需要「必須呼叫工具」的語意，請改用指定函式名稱的 tool_choice（如上所述，思考模式開啟時也能使用），或先關閉思考模式，再使用 required。

Responses

扁平格式（type / name / parameters 位於同一層）。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What's the weather in Paris?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get weather for a city",
        "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
)

# Observed output items: ["reasoning", "function_call"]; arguments = {"city": "Paris"}

已驗證：將 Chat Completions 的巢狀格式（function: {...}）複製到 Responses 會回傳 400——請改用扁平格式。tool_choice: "required" 也受到與 Chat 相同的思考模式限制。

Messages

Anthropic 原生格式（input_schema），使用 tool_choice: {"type": "any"} 強制呼叫工具。

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{
        "name": "get_weather",
        "description": "Get weather for a city",
        "input_schema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]},
    }],
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": "What's the weather in Paris?"}],
)

# Observed: content contains a tool_use block, name = get_weather, input = {"city": "Paris"}

❗ DeepSeek 設計上不允許關閉平行工具呼叫——官方 Anthropic 相容性頁面的 tool_choice 列指出，disable_parallel_tool_use is ignored；Responses 頁面也指出 parallel_tool_calls | Ignored (parallel tool calling is always enabled)。測試結果也一致：即使使用 disable_parallel_tool_use: true，同時詢問兩座城市仍會回傳兩個 tool_use 區塊。若需要依序執行，請自行處理第一個呼叫，或在用戶端排入佇列。

工具數量與上下文成本：在單一請求中傳送 200 個函式定義，仍會正常回傳 200 和一般答案，也沒有觸發數量驗證（此路徑觀察所得；未測試更高數量）。但該請求的 prompt_tokens 高達 6,105——工具定義會完整納入上下文並計費。工具很多時，請依不同情境精簡工具集，不要不加區分地全部宣告。

5. 結構化輸出

Chat Completions

response_format 支援 JSON 模式。

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Return {\"a\": 1} as JSON."}],
    response_format={"type": "json_object"},
)

# Observed response content: {"a":1}

已驗證：輸出為有效的 JSON。

Responses

透過 text.format 宣告 JSON Schema，並支援 strict 模式。

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Return the number 1 under key a.",
    text={
        "format": {
            "type": "json_schema",
            "name": "extract",
            "strict": True,
            "schema": {"type": "object", "properties": {"a": {"type": "integer"}}, "required": ["a"]},
        }
    },
)

# Observed output text: {"a":1}

已驗證：輸出嚴格符合指定的 schema。

Messages

Messages（Anthropic）協定沒有相當於 response_format / text.format 的欄位。常見的替代做法是將 schema 放在工具中——宣告一個工具，讓其 input_schema 使用目標 schema，設定 tool_choice: {"type": "any"}，並從 tool_use 區塊的 input 讀取結構化結果。本輪測試並未特別驗證此做法；若需要嚴格保證 schema，請優先使用 Chat Completions 或 Responses。

6. 如何啟用上下文快取？不必啟用，系統會自動處理

上下文快取（重複的前綴會重複利用，且快取部分的費率較低）預設為開啟，無須設定任何參數。第二次傳送相同長前綴的請求時，會在 usage 中回報快取命中，欄位名稱則依 API 而異。快取詳情和目前定價請參閱模型頁面；跨模型快取策略和命中率技巧請參閱提示詞快取實務。

Chat Completions

# usage of the second call with an identical long prefix
"prompt_tokens_details": {"cached_tokens": 640}   # first call: 0

已驗證：在相同通道上，使用相同長前綴連續呼叫兩次，cached_tokens 從 0 增至 640。

Responses

# usage of the second call with identical long instructions
"input_tokens_details": {"cached_tokens": 896}    # first call: 0

Messages

# usage of a call whose long system prefix was already warmed
"cache_read_input_tokens": 896

已驗證：上方的前綴先由內容相同的 Responses 請求預熱，Messages 首次呼叫便直接命中 896；這與快取以內容前綴為索引，且在不同協定介面間共用的情況一致。

7. logprobs：Chat 會回傳兩個通道

logprobs（對數機率——模型對各候選 token 的信心程度細節）在兩種 API 上的格式不同，解析程式碼必須分別處理。

Chat Completions

completion = client.chat.completions.create(
    model="deepseek-v4-pro-0813",
    messages=[{"role": "user", "content": "Say hi."}],
    logprobs=True,
    top_logprobs=2,
)

# Observed: choices[0].logprobs contains TWO arrays
#   logprobs.content[]            -> tokens of the final answer
#   logprobs.reasoning_content[]  -> tokens of the thinking text

❗ 已驗證：Chat 會同時為 content 和 reasoning_content 回傳對數機率。若程式只讀取符合 OpenAI 標準回應格式的 logprobs.content，不會發生錯誤，卻會默默漏掉思考通道；如果程式假設 logprobs 底下只有一個陣列，請先檢查資料格式。

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="Say hi.",
    top_logprobs=3,
)

# Observed: logprobs only on the final message item
#   output[-1].content[0].logprobs[] with logprob + top_logprobs details

已驗證：Responses 只會在最終文字項目附上對數機率，不會出現 Chat 上看到的雙通道格式。

Messages

Messages（Anthropic）協定沒有相當的欄位。若需要 token 層級的機率細節，請使用 Chat Completions 或 Responses。

8. 哪些 API 可以搜尋網頁？

此處的網頁搜尋是伺服器端工具（檢索作業在伺服器上執行；用戶端不會自行發出請求），測試確認 Responses 和 Messages API 都確實會執行搜尋。

Responses

response = client.responses.create(
    model="deepseek-v4-pro-0813",
    input="What is the latest stable version of Python?",
    tools=[{"type": "web_search"}],
)

# Observed output item sequence:
# ["reasoning", "web_search_call", "reasoning", "message"]

已驗證：輸出序列中會出現 web_search_call 項目，表示伺服器確實執行了檢索。

Messages

response = client.messages.create(
    model="deepseek-v4-pro-0813",
    max_tokens=1024,
    tools=[{"type": "web_search_20250305", "name": "web_search"}],
    messages=[{"role": "user", "content": "What is the latest stable version of Python?"}],
)

# Observed content block sequence:
# ["thinking", "server_tool_use", "web_search_tool_result", "thinking", "text"]
# usage.server_tool_use.web_search_requests = 1

已驗證：usage.server_tool_use.web_search_requests 計數為 1——檢索請求確實已執行並計費。

Chat Completions

Chat 無法觸發網頁搜尋。DeepSeek 官方 Chat API 參考文件的請求 schema 中完全沒有搜尋工具欄位（這是逐一檢查欄位清單後確認的缺項；DeepSeek 並未明確表示不支援）。官方明確聲明支援伺服器端搜尋的 API 是 Responses（web_search），而官方 Messages 相容性頁面也列出了與搜尋相關的內容區塊。

# Three control groups, same question requiring live information, all HTTP 200:
# A no search field       -> "cannot retrieve", annotations = null
# B web_search_options    -> "cannot retrieve", annotations = null, usage identical to A
# C enable_search         -> "cannot retrieve", annotations = null, usage identical to A

已驗證：傳送 web_search_options 或 enable_search 不會引發錯誤，但也不會執行任何檢索——回應中沒有 annotations（網頁搜尋執行時會附加在回應中的引文清單），而且各欄位的用量都與對照組相同。若要存取網頁，請改用 Responses 或 Messages API。

9. 使用注意事項：DeepSeek 的設計與我們這條路徑上的差異

以下情況雖然都會回傳 HTTP 200，實際行為卻違反直覺。成因各不相同，應對方式也不同，因此分開列出：第一組是 DeepSeek 對模型的設計，換用其他供應商也不會改變；第二組是 AIHubMix 路徑目前的行為，我們正在著手處理。

9.1 DeepSeek 的設計

9.2 AIHubMix 路徑目前的行為

9.3 DeepSeek 未明確定義，因此無從判定

傳送不在 reasoning_effort 列舉值中的值（例如 bogus_xyz），會回傳 200 和一般答案，不會發生錯誤，也看不出有任何影響。事實很明確——此路徑目前不會驗證 reasoning_effort 列舉值。尚不清楚的是，這種行為是否妥當：DeepSeek 公布了合法的列舉值，卻從未說明應不應拒絕不合法的層級，因此沒有判斷基準。這既不能算是官方行為，也不能算是我們路徑上的缺陷。安全的用戶端做法是自行驗證層級，不要指望 API 會代為攔截。

10. 功能 × API 支援矩陣

下方各儲存格列出各 API 對應的參數／欄位名稱。除非特別標示為 DeepSeek 的明確說法，所有結論均來自 2026-08-13 對 AIHubMix 正式環境 API 的實際呼叫。

圖例：✅ 已確認可運作 · 🟡 已接受，但無法確認是否生效 · ❗ 需留意（請參閱上方備註）· ➖ 此 API 不支援此概念

常見問題

deepseek-v4-pro-0813 在 AIHubMix 支援哪些 API？
Chat Completions（/v1/chat/completions）、Responses（/v1/responses），以及相容 Claude 的 Messages API（/v1/messages）。

為什麼多輪對話會突然回傳 400？
最常見的原因是沒有傳回思考歷史。在思考模式下，必須原封不動地重送前一輪的思考內容：Chat 中 assistant 訊息的 reasoning_content、Responses 中 type="reasoning" 輸出項目，以及 Messages 中的 thinking 內容區塊。搭配工具進行多輪對話時最容易遇到這個問題——許多框架在組合歷史紀錄時，會依 type == "message" 篩選輸出項目，因而丟棄 reasoning 項目。

可以關閉思考模式嗎？
可以。在 Chat 或 Messages 傳送 thinking: {"type": "disabled"}，在 Responses 傳送 reasoning: {"effort": "none"}。關閉後，思考內容和思考 tokens 都會消失。

三種 reasoning_effort 強度有何不同？
low / high / max 都會被接受（預設為 high；為了相容性，medium 和 xhigh 會對應至 high）。測試中，同一問題的思考 token 數量在不同強度間沒有呈現單調差異，而且也不會回傳強度值，因此呼叫端無法確認兩者差異。只有 Responses 的 none 強度（關閉思考）會產生明確可觀察的差異。

為什麼 tool_choice: "required" 會回傳 400？
思考模式開啟時不接受這個值（錯誤內容為 Thinking mode does not support this tool_choice）。若要在思考模式開啟時強制指定呼叫，請使用具名函式的 tool_choice（{"type": "function", "function": {"name": "..."}}）；或者先關閉思考模式，再使用 required。

如何啟用上下文快取？
不需要啟用——快取會自動運作。將穩定、不變的內容（system 提示詞、知識片段、工具定義）放在請求開頭，命中數會顯示在 usage 中：Chat 的 prompt_tokens_details.cached_tokens、Responses 的 input_tokens_details.cached_tokens，以及 Messages 的 cache_read_input_tokens。

如需定價與即時狀態，請參閱 deepseek-v4-pro-0813 模型頁面；如需探索更多模型，請造訪 模型庫。

相關實作指南：Kimi K3 實作指南（新參數與三種 API 支援矩陣），以及 GPT-5.6 提示詞快取與計費變更。