LLM 權杖用量：為什麼一個 4 token 的答案要收 217 個 token

問 GPT-5.6 一道一行的數學題，output 費用有 88% 是你永遠看不到的 reasoning：畫面上顯示 10 個 token，實際計費 81 個。而 GPT-5.6 還算輕微的。同一道題在 GLM 5.2 上，4 個 token 的答案要收 217 個 completion token，在 Qwen3.7-max 上更是同樣答案收 1,104 個。這不是異常，而是 reasoning 模型設計上的計費方式，也是多數成本儀表板從不拆解出來的其中一種 token 類別。這篇文章拿一個真實的 usage 物件，逐類拆解，並附上實測數字。

TL;DR

• GPT-5.6 預設值下，10 個 token 的答案收了 81 個 token，其中 88% 是 reasoning；GLM 5.2 是 98%，Qwen3.7-max 是 99.3%。
• Claude Sonnet 5 在一個 5 token 的答案上收了 114 個 thinking token，而且完全沒有帶 thinking 參數。
• 五個模型系列在沒有 thinking 的情況下答錯（399、400、427、466、467）；只有 GPT-5.6 在沒有 thinking 時也答對，而所有跑了 reasoning 的都回答 401。
• Claude 一次 1,181 個 token 的 cache 寫入接著讀取，分別花了 $0.01246 和 $0.00566，與定價完全吻合。

我們用什麼來測試

這篇文章裡的每一項測量，都是同一個單輪 prompt，除非某一列另有說明，否則都以各模型的預設值送出：

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

正確答案是 401（3 的倍數有 333 個，加上 5 的倍數 200 個，減去重複計算的 66 個，得到 467；再扣掉 15 的倍數 66 個，剩下 401）。這道題是刻意挑的：可見的答案很小，在每一種 tokenizer 上都固定是 3 到 4 個 token；正確答案只有一個，所以「思考有沒有帶來效果」是可以驗證的；而且難度剛好足以讓模型想去思考，而這正是我們要稽核的行為。

帳單上的五種 token 類別

一次現代的 completion 呼叫，最多會產生五種不同的 token 類別，並以四種不同的費率計價。單一的「tokens used」數字把這些全都藏了起來。

上面的欄位名稱是 OpenAI 相容格式。Claude 也有同樣的五種類別，只是換了自己的名字：input_tokens 和 output_tokens，thinking 記在 output_tokens_details.thinking_tokens 並以 output 計費，快取寫入則依 TTL 再拆進 cache_creation 物件（ephemeral_5m_input_tokens 為 1.25x，ephemeral_1h_input_tokens 為 2x）。結構一樣，標籤不同，這個解析問題後面章節還會再出現。

五種類別及其價格倍率，並標上 OpenAI 相容與 Anthropic 的欄位名稱。88% 這個數字是上面範例中 GPT-5.6 實測的 reasoning 佔比。

以下是那個總數背後真正的物件，GPT-5.6 用預設設定回答測試問題：

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

計費的算術就藏在這裡，值得完整算一遍。你收到的答案是 completion_tokens 扣掉 reasoning_tokens：81 − 71 = 10 個 token，也就是「401」這幾個字加上格式。其餘 71 個 token 是 chain-of-thought，以完整的 output 費率計價，佔了 output 費用的 88%，而在 GPT-5.6 上你一個字都看不到。這篇文章裡每一個「可見答案」的數字都是這樣算出來的。換到別的模型，這個比例只會更誇張：GLM 5.2 回答同一個問題用了 217 個 completion token，答案卻只有 4 個 token。所以把 completion_tokens 當成「模型說了什麼」的成本模型，在這裡誤差 8 倍，在那裡誤差 54 倍。

reasoning 是預算，而且可以調

同一個一行問題，跑遍三個可調節家族接受的所有 thinking 設定，走同一個閘道，日期為 2026-07-13/14（每個家族內的列由 reasoning 最少排到最多；其餘家族的旗艦預設值放在下一節）：

這張表值得誠實地讀出四件事：

• 有效的地方，這根槓桿很有力。 reasoning_effort: none 只花 $0.000062 就答對，比 luna 的預設便宜 8.5 倍；在更難的任務上，我們量到 GLM 5.2 便宜達 20 倍。選 tier 也是這根槓桿的一部分：GPT-5.6 旗艦在預設情況下就以零 reasoning 答對這題（見下一節），所以一個不需要思考的大模型，可以比一個需要思考的小模型還便宜。
• 無效的地方，它幾乎沒作用。 這個旋鈕能轉多遠是家族特性：Sonnet 5 上單調變化、成本擺動 5 倍（84 到 249），GPT-5.6 上幅度小且沒有順序，Qwen3.7-max 上幾乎沒作用（low 仍花了 974 個 reasoning 權杖，預設是 1,096），DeepSeek V4 Pro 上完全沒差（267 對 269）。
• 標籤不是單調的，預設也不是確定性的。 GPT-5.6 的 high 在這裡花的權杖比 medium 還少；GLM 的 low 在我們先前那篇文章裡花得比 high 多；Sonnet 5 在一個完全沒送 thinking 參數的請求上還是思考了 114 個權杖；同一個 GLM 預設請求，一次跑出 213 個 reasoning 權杖，另一次跑出 1,312 個，相差六倍。要量測旋鈕在你自己工作負載上的實際效果，別看標籤就下結論。
• 便宜但答錯，是反覆出現的失敗模式。 這裡兩個沒思考就作答的家族都答錯了（GLM 399、Sonnet 5 467）；完整的五個家族名單在下一節。reasoning 是一筆正確性預算，砍掉它划不划算取決於任務，而不是模型。

實務準則：把 reasoning_tokens 當成一級的帳目項目來對待。它以 output 費率計費，經常遠超過看得見的答案本身，而且會受參數影響，其實際效果你必須自己量測。在 GPT-5.6 上，注意計費規則也變了；GPT-5.6 成本指南 涵蓋了寫入溢價和 cache-key 需求。

你付了錢，真的讀得到嗎？

「跟答案分開」不代表就是隱藏起來，這個差別值得講清楚。我們檢查的是 response body，不只是 usage：

• GLM 5.2、DeepSeek、Qwen3.7-max、MiniMax 會回傳完整的推理文字，放在答案旁邊的 reasoning_content 欄位裡（這次分別是 3,987、1,604、2,509、581 個字元）。開發者可以讀到每一個被計費的 token；只有你自己把它 render 出來，終端使用者才看得到，而大多數應用都不會這樣做。
• GPT-5.6 不給你原始的思考鏈，頂多給一段摘要。 回應裡可以帶一段模型寫的 reasoning.summary（這次是 359 個字元），但被計費的那 91 個 token 是隱藏的原始文字，不是這段摘要。最接近那段文字的東西是 reasoning.encrypted_content：一段加密的 blob，你可以在多輪對話裡把它傳回去以維持連續性，但永遠解不開。你付了錢的那些 token 就躺在自己的 response body 裡，卻讀不了。
• Claude 則取決於你怎麼問。 我們用 adaptive-thinking 呼叫 Sonnet 5，回來的 thinking 區塊文字是空的，但 thinking_tokens 計費了 114：證明它有思考，卻沒東西可讀。Fable 5 在它 always-on 的預設模式下也一樣（計費 59，區塊為空）。可是同一個 Sonnet 5，只要帶上明確的 reasoning budget 去呼叫，就會回傳真正的思考文字（計費 73 個 token，文字有內容）。你怎麼問，決定了你看得到什麼。

所以帳單是一致的，能不能看到內容則不然：每一個模型家族都用 output 費率對推理計費，而你能不能稽核自己買到的文字，從「完整可讀」、「只有摘要」到「一個有簽章的空區塊」都有。

文字有回傳時，你就能機械式地打分。我們的問題有五個固定的中間結果（333、200、66、467、401），而每一份回傳的推理文字都包含這五個：GLM 5.2、DeepSeek V4 Pro、Qwen3.7-max、Kimi K2.7 Code、MiniMax M3 各自給出了完整的推導過程，而 low-effort 的變體則各漏掉一個步驟。對於需要過程、而不只是答案的人來說，差別就在這裡：有 reasoning_content，你可以驗證自己付了什麼錢；只有摘要或空區塊，你就只能靠信任。Invisible Tokens, Visible Bills 把這種問責落差形式化了，PALACE 則從外部估算隱藏的推理量。

用同一道題考各家最新的旗艦模型

前面那張參數調整表用不同層級的模型展示了各種旋鈕。這裡改用各家最新的旗艦模型，在預設設定下回答同一道題：

每個旗艦模型針對同一問題計費的輸出權杖（斜線橘色＝推理佔比；綠色＝可見的答案）。MiniMax 上的星號：其用量並未帶有推理計數，因此該佔比是透過減法重建，並對照其回傳的推理文字加以驗證。GPT-5.6 sol 上的勾號標示唯一正確的零推理執行；Gemini 3.5 Flash 上的叉號標示唯一答錯的旗艦答案（466）。

一張圖看盡各種回報方式：

• 八個旗艦有七個答對，但同樣是 401，價格天差地別。 Qwen3.7-max 花了 1,096 個 reasoning token、22 秒、$0.0084；GPT-5.6 的旗艦則是零 reasoning token、$0.00031。同一個正確答案，成本差 27 倍、延遲差 7 倍，這就是 reasoning 預算被攤開來看的樣子。
• MiniMax 會回傳 reasoning 文字，但不給數量。 260 個 completion token 對上 3 個 token 的可見回答：回應在 reasoning_content 裡帶了完整推導，但 completion_tokens_details 沒有 reasoning 這一項。缺數量時就用減法反推：completion 減掉可見 token 就是隱藏 output 的數量。
• Gemini 3.5 Flash 是異數：唯一答錯的旗艦（466），只有 3 個 completion token，任何地方都找不到 reasoning 數量。它的同門師兄 2.5 Flash 曾花 12.5 秒產出一個 3 token 的 401，帳單上完全看不出理由；換一次執行則答成 427。
• 答錯的都出在較小的層級和關掉 thinking 的情況。 GLM 關掉 thinking 後答 399；Sonnet 5 停用時答 467；較舊的 qwen3-max 完全沒思考（3 個 token）就答 400；沒有 reasoning 通道的 Kimi K2.5 用 144 個可見計費 token 把推理直接寫出來，在自己的內文裡推導出 401，最後卻結論成 400。五家模型，五個不同的錯誤答案：399、400、427、466、467；只有 GPT-5.6 不靠 reasoning 就答對了。

快取權杖：兩個方向，差距 12 倍

Prompt caching 把輸入再拆成兩類，而這麼拆的理由就是兩者的價差：在 Claude 上，寫入按輸入費率的 1.25 倍計費（1 小時 TTL 為 2 倍），讀取則是 0.1 倍。實際測了一組 Opus 4.8 的呼叫，帶一個 1,181 個 token 的快取 system prompt，第一次（寫入）花 $0.01246，第二次（讀取）花 $0.00566，兩者對照 list price 都能精確到小數點後第六位，輸入端的費用在兩次呼叫之間降了約 11 倍。這篇要講的重點是帳務：如果你把 cache_creation_input_tokens 和 cache_read_input_tokens 全都算進「input tokens」，你既無法驗證這個折扣，也不會注意到它什麼時候悄悄失效。而它失效的頻率比文件說的高：我們的快取實測發現實際門檻比文件記載的最小值高出 1.4 到 2.4 倍，prompt caching 指南則深入講解了各家的機制。

為什麼你本地端的估算永遠對不上帳單

常見的做法是用 tokenizer 函式庫在 client 端估算成本，事後再對帳。數字對不上有三個原因：

• 每家廠商的 tokenizer 都不一樣。 用 OpenAI 的 tokenizer 去數要送給 Claude 的文字，等於拿錯尺在量；同一段字串在每個模型家族的分詞結果都不同。
• 你付費的不只是你的訊息。 System prompt 和 tool schema 在每一次帶上它們的請求裡都算 input token，而這些很容易在本地估算時漏掉。
• 推理的用量在回應出來前無法預測。 沒有任何 client 端的計數能預測模型會花掉多少 thinking token；你只能從回傳的 usage 裡才知道。

回傳的 usage 物件就是上游自己的計費記錄，所以最省事又準確的計數方式就是別再估算，直接讀它。麻煩的是每家廠商的格式都不一樣：光是快取 token，依家族不同就會叫 cached_tokens、prompt_cache_hit_tokens、total_cached_tokens 或 cache_read_input_tokens。

那些明細物件也不是固定的 schema。OpenAI 的參考文件記錄了四個 completion 端的欄位：reasoning_tokens、audio_tokens，以及 Predicted Outputs 那一組 accepted_prediction_tokens / rejected_prediction_tokens；被拒絕的 prediction token 不會出現在輸出裡，卻仍然以 completion token 計費。在 prompt 端，同樣的結構在 cached_tokens 旁邊多加了 text_tokens、audio_tokens 和 image_tokens；GPT-5.6 又加了 cache_write_tokens，我們還在實際流量裡看過 video_tokens。各家會自由擴充：Kimi K2.7 回傳過一個沒有記載的 completion_tokens_details.text_tokens，而 Gemini 用自己的名稱把 thinking 和 tool-use 的 token 分開計算。解析時要防禦性一點：把未知的明細欄位當成預期會出現的東西，也絕不要假設欄位缺失就等於零。

閘道的價值就在這裡：Synthorai 把這些全都正規化成一個物件，reasoning_tokens 和兩個快取方向在 OpenAI、Anthropic、Gemini 以及各個 open-weight 家族之間都會填好，所以一套 parser 就能涵蓋你路由到的每個模型。

从看得到到挡得住

看懂帐单只是工作的一半，另一半是让超支根本无法发生，而不只是事后看得见。月底的仪表板只会在钱花光之后报告一个意外，而卡在重试回圈里的 agent 根本不会去看仪表板。在闸道上，每把 key 都带有 quota，会追踪 used_quota 和 RPM 上限，并在请求当下强制执行：预算用完的 key 会在下一次请求时拿到明确的错误，而不是三週后收到一张更大的帐单。每笔请求的归因（用哪把 key、哪个模型、BYOK 还是平台计费）会在同一个回应封包裡回传，所以要算每个功能的成本只需要一次 group-by，不必事后重建。

从这些量测衍生出来的操作顺序是这样的：先读 reasoning_tokens 和快取相关栏位，再谈优化；针对每个任务设定 reasoning 的强度；对每一把失败模式会变成回圈的 key 都加上硬性 quota。想知道特定的模型与 token 类别组合在你的用量下要花多少钱，cost optimizer 会用上面同一套的每 token 费率帮你算出来。

← 返回部落格