qwen3.8-max)是阿里通義千問 2026 年 8 月 3 日釋出的新一代旗艦,稀疏 MoE 架構、2.4 萬億總引數,支援 1M 上下文、131K 最大輸出,原生接受文本、圖片、影片三種輸入。API易在釋出當天上架,並完成了 586 次實測呼叫——本頁的能力矩陣、引數行為與計費提醒全部來自實測,不是轉述官方文件。
API易已接入 Qwen3.8-Max:模型名
qwen3.8-max。預設開啟深度思考(預設 xhigh 檔,思考 tokens 計入輸出計費),日常對話建議顯式設 reasoning_effort="none",實測輸出可從約 158 tokens 降到 5 tokens。上一代見 Qwen3.6 系列(歷史版本)。核心優勢
比官網便宜 17.5%
輸入 $1.65、輸出 $4.95 每 1M tokens,阿里雲官網為 $2/$6。可疊加充值活動繼續下探。
1M 上下文實測可用
8K / 32K / 128K 三檔正文,中部與尾部各埋一枚標識,兩個端點 6/6 全部精確召回。128K 單次約 80 秒。
一個模型三種模態
文本、圖片、影片輸入全部實測通過,無需在「長文模型」和「視覺模型」之間切換。
Agent 能力大幅提升
FrontierSWE 由上代 40.7 升至 73.5,DeepSWE 21.6 → 56.6。工具呼叫鏈路完整,兩輪 round-trip 實測通過。
端點支援
模型定價
每 1M tokens,折扣前掛牌價:
可疊加充值活動,實際成本更低。
技術規格
官方基準:GPQA Diamond 92.6、PaperBench 93.0、OmniDocBench 1.5 92.1、Terminal-Bench 2.1 86.6、OSWorld-Verified 86.1、IFBench 82.8、FrontierSWE 73.5、SWE-bench Pro 67.7。
思考控制(最重要的一節)
Qwen3.8-Max 預設就在思考,檔位為xhigh。思考 tokens 計入輸出計費,且佔比常達 90% 以上。
reasoning_effort 七個值,四個真實檔位
引數接受 7 個值,但實測只對應 4 個真實檔位:
傳
max 不會比 xhigh 想得更多。傳其他值會返回 400 並列出合法值。
關閉思考的寫法
extra_body 裡的 enable_thinking: false 與 chat_template_kwargs: {"enable_thinking": false} 同樣生效,效果等價。
thinking_budget 不生效
傳 128 / 512 / 4096 任何數值,實測行為都等同於 low 檔,數值不起作用。請改用 reasoning_effort。
呼叫示例
Python(OpenAI SDK 相容)
圖片輸入
url 填成 https://... 即可。
影片輸入
{"type": "video", "video": [幀1, 幀2, ...]},要求 4–8000 幀,少於 4 幀會返回 400。
cURL
工具呼叫
Chat Completions 端點的工具呼叫完整可用:單工具、並行多工具、兩輪 round-trip、20 個工具中選 1、流式增量拼接、parallel_tool_calls: false 全部實測通過。
結構化輸出
response_format 的 json_schema 實測嚴格守約:巢狀物件、列舉、陣列、additionalProperties: false 全部生效,無多餘欄位、無 Markdown 程式碼塊包裹。
上下文快取
- 命中門檻約 1024 tokens:818 tokens 的字首不命中,1070 tokens 起命中
- 真實多輪對話吃得到快取:逐輪追加訊息的場景每輪都命中
- 長文收益顯著:128K 上下文實測快取命中 98.6%,32K 命中 99.3%
Anthropic 端點用法
/v1/messages 可用於程式碼整合,但回傳歷史訊息前需要剝掉 thinking 塊,否則返回 400(if content is list. item must be dict and key[type] should in dict)。
2026-08-08 追加複測:多輪工具呼叫本身沒問題
一輪 300 次呼叫的專項複測,結論是多輪tool_use / tool_result 鏈路本身是好的,卡點只在 thinking 塊:
tool_result沒有任何額外格式限制:content為字串或 block 陣列、is_error真假、空結果、50KB 大結果、亂序回傳、只回傳部分、偽造tool_use_id——15 種形態全部通過。控制字元、emoji、20 萬字符單行也都能過。thinking塊的signature取什麼值都救不了:空串、null、整個 key 缺失、偽造值,四種全部返回同一個 400。只能刪掉整個塊。- 剝掉
thinking後壓力測試通過:24K token 系統提示詞 + 8 個工具的自主 agent 迴圈,12 輪 × 2 組,上下文漲到 28.7K,24/24 全部成功。 - SSE 事件完整:
message_start/content_block_start/content_block_delta/content_block_stop/message_delta/message_stop齊全,另有ping;text_delta/thinking_delta/signature_delta/input_json_delta都正常。 - 沒有速率或併發限制:同一請求順序重複 40 次全部成功,併發 1 / 4 / 8 / 16 / 32 各檔全部成功,未出現 429。
想在 Claude Code 裡用怎麼辦
這類「特定客戶端裡跑不起來」的問題,未必是我們這邊的適配問題,也可能是模型側本來就不支援。建議先去阿里雲百鍊官方平臺用同樣的用法驗證一次(控制台:bailian.console.aliyun.com):
- 如果官方平臺同樣不支援,那就是模型側的限制,我們這邊也繞不過去;
- 如果官方平臺可以、我們這邊不行,請把請求體發給我們,我們跟渠道方對齊。
其他差異與實測注意
response_format被靜默忽略(結構化輸出請改用工具強制)tool_choice只接受 OpenAI 格式;強制工具呼叫(required或指定函式)在思考模式下兩個端點都不支援- 圖片只支援 base64,遠端 URL 返回 400
reasoning_effort不生效,關思考請用thinking: {"type": "disabled"}stop_sequences截斷本身生效,但stop_reason會誤報成end_turn、stop_sequence欄位返回null,不要依賴它判斷停止原因- 流式 usage 因線路而異:部分線路
message_start裡的input_tokens不可信,部分線路流式最終output_tokens恆為 0。需要精確核算時請以非流式返回的 usage 或賬單為準 - 輸入長度上限實測 983,616 tokens,超出返回
Range of input length should be [1, 983616]
引數相容性
最佳實踐
日常對話與高頻呼叫
顯式設
reasoning_effort="none"。實測耗時從約 5 秒降到 2 秒、輸出 tokens 降到 1/30。長文件與程式碼庫分析
128K 召回實測精確,長文快取命中率高。把大文件放在訊息前部,追問放在尾部。
資料抽取
用
json_schema 約束結構,同時關思考。守約程度不受影響。Agent 與工具編排
走
/v1/chat/completions。需要強制呼叫時記得關思考。常見問題
為什麼我設了 max_tokens 還是被扣了很多 token?
為什麼我設了 max_tokens 還是被扣了很多 token?
max_tokens 只約束可見回答,不約束思考部分。實測 max_tokens=1 仍被計 1054 個輸出 token。控制成本請用 reasoning_effort="none"。為什麼 tool_choice 指定了函式卻報 400?
為什麼 tool_choice 指定了函式卻報 400?
思考模式下不支援
tool_choice 強制呼叫。請同時傳 reasoning_effort="none"。為什麼 /v1/responses 調不通?
為什麼 /v1/responses 調不通?
該端點對本模型暫未接入,30 次測試全部失敗(錯誤碼在 404 與 400 之間跳變)。已反饋渠道方,接通後會在即時動態公告。請改用
/v1/chat/completions。Claude Code 能用這個模型嗎?
Claude Code 能用這個模型嗎?
暫時不能。
/v1/messages 端點拒絕含 thinking 塊的歷史訊息,而 Claude Code 預設原樣回顯,所以第一輪能出 tool_use、回傳 tool_result 後第二輪就 400。自己寫程式碼呼叫時剝掉該塊即可正常使用。需要在 Claude Code 裡幹活的話,建議直接用本站的 Claude 系列或 OpenAI 系列,預設分組就是官轉,不需要額外適配。也可以先去阿里雲百鍊官方平臺(bailian.console.aliyun.com)驗證同樣的用法是否支援——如果官方平臺同樣不支援,那是模型側的限制。為什麼第一輪好好的,回傳工具結果後就卡住/報錯?
為什麼第一輪好好的,回傳工具結果後就卡住/報錯?
這是
/v1/messages 端點上最典型的表現。原因是回傳的歷史 assistant 訊息裡帶了 thinking 塊,該端點不接受,返回 400。signature 改成空串、null 或刪掉這個欄位都沒用,必須刪掉整個 thinking 塊。實測剝掉之後,24K 上下文的 12 輪工具迴圈可以穩定跑完。多輪 tool_use / tool_result 鏈路本身沒有問題。usage 裡為什麼有時沒有 reasoning_tokens / 快取欄位?
usage 裡為什麼有時沒有 reasoning_tokens / 快取欄位?
該模型背後有多條上游線路,各線路回顯的 usage 欄位不一致:有的不回
reasoning_tokens 與 cached_tokens,有的 cache_read_input_tokens 恆為 0,有的流式最終 output_tokens 恆為 0。已反饋渠道方統一口徑。介面回顯不代表實際計費。 需要精確核算時,請以控制台日誌裡單條請求的計費詳情為準,那裡會列出基礎費用與快取費用的完整計算過程。影片呼叫為什麼很慢?
影片呼叫為什麼很慢?
影片理解單次實測 144–285 秒,屬於模型本身的處理耗時。請把超時設到 300 秒以上,並考慮用非同步佇列承接。
相關文件
- Qwen3.8-Max 線上除錯 — Playground 直接發請求
- Qwen3.6 系列(歷史版本) — 上一代五款模型
- Qwen3.8-Max 上線說明 — 基準資料與完整解讀
- 模型價格 — 全站模型單價、快取價格與可用端點
- 充值優惠活動 — 疊加折扣
本頁實測資料來自 2026-08-03 的 586 次呼叫(12:50–14:35 UTC+8),以及 2026-08-08 針對 Anthropic 端點多輪工具呼叫的 300 次專項複測(22:10–2026-08-09 00:40 UTC+8)。介面返回的 usage 欄位在不同上游線路間口徑不一致,計費請以控制台日誌的計費詳情為準。模型與閘道行為可能隨渠道調整而變化,以實際呼叫為準。