MiniMax M3.1 Flash 思考努力程度：為什麼使用預設值修復同一個錯誤，成本會高出 7 倍

MiniMax M3.1 Flash 有五種思考層級，且無法關閉。若未選擇層級，模型會自動選用最深的層級。MiniMax 的文字生成指南指出，省略此參數時，努力程度「預設為 max」。

這個預設值的成本很高，但很容易被忽略。AIHubMix 在每個層級都執行了相同的兩個錯誤修復任務。預設值使用的思考 token 約為 low 的 10 倍，耗時約為 6 倍，而且每次執行、每個層級都通過了全部 215 項測試。模型的思考成本會隨努力程度設定增加，但任務難度始終相同。

簡單來說：從 low 開始，只有在任務失敗或需要重試時才調高，而且絕對不要將此欄位留空。

五種層級，無法關閉

思考功能無法停用。根據 MiniMax 的Messages API 參考文件，若設定 thinking: {"type": "disabled"} 或將努力程度設為 none，API 會傳回 HTTP 400，並顯示訊息 model "MiniMax-M3.1-Flash" requires adaptive thinking。較舊的 MiniMax 模型會完全忽略努力程度欄位。到目前為止，M3.1 Flash 是唯一會採用此欄位設定的 MiniMax 模型。

在 AIHubMix 上，minimax-m3.1-flash 支援全部三種通訊協定。它與 MiniMax 官方 API 的一項差異是：AIHubMix 接受 reasoning_effort: "none" 和 "minimal"，並傳回 HTTP 200，但模型依然會思考。請將這些值視為無效設定，而非關閉思考功能的方法。

單一任務在各層級的成本

測試內容：一個有兩個錯誤的計費函式。暫停期間超過計費週期結束日會重複計算一天，而重疊的暫停期間則會被重複扣除。模型會傳回修正後的函式，再由本機測試工具以 215 個隱藏測試案例進行檢查。2026 年 10 月 19 日，我們透過 AIHubMix 的 Chat Completions 端點，在每個層級各執行三次，並將 max_tokens 設為 32,768。所有數據均由 AIHubMix 測得，尚無其他人重現這些結果。

成本採用 AIHubMix 對 minimax-m3.1-flash 的定價：每百萬個輸入 token $0.165、每百萬個輸出 token $0.66、每百萬個快取輸入 token $0.0165。思考 token 按輸出 token 計費。舉例來說，「省略」那一列平均有 464 個 prompt token（約 192 個已快取）及 6,673 個輸出 token，每次修復的成本約為 $0.0045。

數據透露了什麼

這項任務用 low 就夠了。每個層級每次都能產生正確修復結果。對於範圍明確、只涉及單一函式的錯誤，更高層級增加的思考並未帶來可測量的效益。

從 low 調到 medium，差異很明顯。medium 的平均思考 token 數約為 low 的 2.6 倍，耗時也超過兩倍。

medium 以上，各層級的差異就不太明顯了。我們的 xhigh 執行結果平均 token 數少於 high，而 max 的數據範圍與兩者都有重疊。每個層級只執行三次，無法區分彼此。在這項任務中，「high」、「xhigh」和「max」都代表「思考得更多，有時多很多」。

省略設定的表現就像 max。這與 MiniMax 的文件一致。我們測得的「省略」平均值高於「max」，但兩者的數據範圍重疊，差異也在每次執行的波動範圍內。

每個層級的結果波動都很大。同一個 prompt 使用預設值時，耗時介於 39 到 82 秒。在 Anthropic Messages 端點上，三次 low 執行分別使用了 511、1,861 和 6,060 個思考 token。最後一次耗時 56 秒，與典型的 max 執行時間相同。努力程度設定的是平均思考深度，而非硬性的上限。

所有 24 次 Flash 執行的輸出速度都很穩定，約為每秒 112 個 token，因此耗時幾乎會隨思考 token 數等比例增加。以這個速度，思考 6,000 個 token 就得等將近一分鐘。

MiniMax 尚未公布各層級自己的 token 數或延遲數據。當較難的任務開始需要更高層級時，單憑這次測試，我們無法下定論。以上數據只能說明：任務不需要更高層級時，各層級的成本是多少。

簡短的 prompt 幾乎不需要思考

「永遠會思考」不代表「永遠思考很多」。思考是自適應的，因此思考深度會根據 prompt 看起來有多難而變化：

• 將五張客服工單分類至四種標籤之一：使用 low 時思考 token 數為 0，使用預設值時平均為 6。每張工單都分類正確。
• 對「What is 17 × 23?」使用 low：完全沒有思考，輸出 2 個 token。

因此，缺少關閉思考功能的開關，在簡短的分類、資訊擷取和路由呼叫中幾乎不會增加成本。成本主要出現在程式碼這類開放式任務中，因為你允許模型思考得越深入，它能想到的事情就越多。

從哪裡開始

以下是建議的起始設定。只有前兩列是直接測量的結果；其他是我們的建議，請依據你自己的重試情況加以驗證：

只有在你發現 high 無法處理這類任務時，才使用 max。

調整努力程度後可能出現的問題或成本增加

• 回答遭截斷。思考 token 也會計入 max_tokens。一次使用預設值的執行，在單一函式上就用了 9,376 個思考 token，因此，原本為 M2.x 回答設定的 4K 或 8K 上限，可能會導致回覆被截斷，並傳回 finish_reason: "length"。MiniMax 建議使用 131,072，並允許最高 524,288。
• 逾時。使用 high 以上層級時，單次呼叫可能耗時一分鐘。原本為快速模型設定的用戶端及代理伺服器逾時時間，應調高至 120 秒或更久。
• 設定值被悄悄忽略。透過 AIHubMix，none、minimal 和像 auto 這樣的未知值都會被接受，但模型依然會思考。根據一個閘道專案的測試（sub2api issue #8025），MiniMax 官方端點會拒絕未知值。請使用文件列出的五種值之一。
• 工具未提供這些層級的選項。目前 OpenCode 對此模型找不到任何努力程度變體，而有些框架會傳送「thinking disabled」，導致 HTTP 400 錯誤。請確認你的工具實際傳送了什麼內容。
• 同一個流程中混用多種模型。M3 和 M2.x 會忽略努力程度欄位。若你在不同模型間切換，能為 Flash 節省成本的努力程度設定，對其他模型完全不起作用。

如何在各種通訊協定中設定

透過 AIHubMix 使用一組金鑰，即可使用全部三種通訊協定。快速入門介紹如何取得金鑰；統一推理參數頁面則說明 AIHubMix 如何處理不同供應商的推理欄位。

Chat Completions：

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "minimax-m3.1-flash",
       "reasoning_effort": "low",
       "max_tokens": 32768,
       "messages": [{"role": "user", "content": "Write a function that merges overlapping date ranges."}]}'

Anthropic Messages（Python SDK；如果你的 SDK 版本不支援此欄位，請將 output_config 放在 extra_body 中）：

import os
import anthropic

client = anthropic.Anthropic(base_url="https://aihubmix.com", api_key=os.environ["AIHUBMIX_API_KEY"])

msg = client.messages.create(
    model="minimax-m3.1-flash",
    max_tokens=32768,
    messages=[{"role": "user", "content": "Write a function that merges overlapping date ranges."}],
    extra_body={"output_config": {"effort": "medium"}},
)
print(msg.usage)

Responses：

import os
from openai import OpenAI

client = OpenAI(base_url="https://aihubmix.com/v1", api_key=os.environ["AIHUBMIX_API_KEY"])

resp = client.responses.create(
    model="minimax-m3.1-flash",
    reasoning={"effort": "low"},
    max_output_tokens=32768,
    input="Write a function that merges overlapping date ranges.",
)
print(resp.usage)

請檢查前幾次呼叫的 usage。Chat Completions 會透過 completion_tokens_details.reasoning_tokens 回報思考 token 數；Messages 使用 output_tokens_details.thinking_tokens；Responses 則使用 output_tokens_details.reasoning_tokens。如果你調整層級時這些數字都沒有變化，代表設定沒有傳到模型。

常見問題

MiniMax M3.1 Flash 的預設努力程度是什麼？
max。若請求中沒有努力程度欄位，模型就會以最深的層級思考。

可以完全關閉思考功能嗎？
不行。在 MiniMax 的 API 上停用思考會傳回 HTTP 400。最低層級是 low，而對於簡短的 prompt，low 通常完全不會使用思考 token。

程式設計應該使用哪種努力程度？
單一函式修復和小型程式碼審查從 low 開始，多檔案修改則從 medium 開始，只有任務失敗時才調高。在我們的測試中，low 每次都能正確修復有兩個錯誤的函式。

max 努力程度會讓結果更準確嗎？
在我們的測試任務中沒有：每個層級都通過了全部 215 項測試。max 使用的 token 和時間都多得多。較高的層級或許有助於處理更困難的任務，但目前還沒有人公布數據，指出哪些情況下會有幫助。

為什麼相同的請求有時花 10 秒，有時又花 56 秒？
即使層級固定，每次執行的思考深度仍會變動。在 Messages 端點上，有一次使用 low 努力程度的執行，其思考 token 數約為另一次的十倍。

透過 AIHubMix 使用 reasoning_effort none 有效嗎？
這個值會被接受且不會報錯，但模型依然會思考。請改用 low。

如何查看一次呼叫使用了多少思考 token？
查看 usage 物件：Chat Completions 和 Responses 使用 reasoning_tokens，Messages API 則使用 thinking_tokens。

繼續閱讀：MiniMax M3.1 Flash 系列文章

• 若想全面了解這項設定的背景，包括 Space Bunny 發布，以及與 M2.7 和 M3 的價格比較，請參閱：MiniMax M3.1 Flash 就是 Space Bunny：相較 M2.7 和 M3 有何改變，成本又是多少
• 從 M2.5/M2.7 的程式碼遷移時，努力程度只是眾多變動之一。本文涵蓋 400 錯誤及其他問題：11 月 18 日前遷離 MiniMax M2.5/M2.7：修正 M3.1 Flash 的「requires adaptive thinking」400 錯誤
• 使用 low 努力程度時，Flash 在三個模型中修復相同錯誤的成本最低。以下比較 Flash 的預設值與 DeepSeek 和 Haiku：MiniMax M3.1 Flash vs DeepSeek V4.1 Flash vs Claude Haiku 5.5：修復一個錯誤，三種帳單

來源

• MiniMax：模型呼叫（文字生成指南）
• MiniMax：Messages API 參考文件
• AIHubMix：MiniMax M3.1 Flash
• AIHubMix：統一推理參數
• sub2api issue #8025：MiniMax M3 / M3.1 Flash 努力程度支援