LLM 權杖用量：為什麼 4 個權杖的答案會按 217 個權杖計費

拿一道單行數學題問 GPT-5.6，輸出費用有 88% 來自你永遠看不到的推理：可見答案只有 10 個權杖，計費卻是 81 個。這還只是 GPT-5.6，相對不算誇張。同一道題目，GLM 5.2 用 4 個權杖作答，卻按 217 個 completion 權杖計費；Qwen3.7-max 給出相同答案，更計了 1,104 個。這不是異常，而是推理模型原本的計費方式。它也是多種權杖類別中的第一種，而多數成本儀表板根本不會分項顯示。本文會逐類拆解真實的 usage 物件，並列出實測數據。

TL;DR

• GPT-5.6 預設設定用 10 個權杖作答，卻按 81 個權杖計費，其中 88% 是推理；GLM 5.2 的比例為 98%，Qwen3.7-max 則是 99.3%。
• Claude Sonnet 5 在請求未帶任何 thinking 參數時，針對 5 個權杖的答案計了 114 個 thinking 權杖。
• 五個模型家族在不推理時答錯（399、400、427、466、467）；只有 GPT-5.6 不推理也答對，而所有有推理的執行結果都是 401。
• Claude 先寫入再讀取 1,181 個快取權杖，費用分別為 $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；再排除 66 個 15 的倍數，剩下 401 個）。我們刻意選這道題：所有 tokenizer 產生的可見答案都固定只有 3-4 個權杖，而且答案唯一，因此很容易確認「花在推理上的成本是否有用」。題目也有一定難度，足以讓模型想要推理，而這正是我們要檢視的行為。

帳單上的五種權杖

現代 completion 最多會對五種權杖收費，費率則有四種。只看單一的「已使用權杖」總數，這些差異全都會被掩蓋。

以上是 OpenAI-compatible 的欄位結構。Claude 也有相同的五種類別，但欄位名稱不同：輸入與輸出分別是 input_tokens 和 output_tokens；thinking 記錄在 output_tokens_details.thinking_tokens，按輸出費率計費；快取寫入則依 TTL 進一步拆到 cache_creation 物件中（ephemeral_5m_input_tokens 為 1.25x，ephemeral_1h_input_tokens 為 2x）。結構相同，標籤不同；後面還會再談到這個解析問題。

五種類別及其價格倍率，並標示 OpenAI-compatible 與 Anthropic 的欄位名稱。88% 是上例中 GPT-5.6 實測的推理占比。

以下是標題所述情境背後的真實物件：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 個權杖，也就是「401」及其格式。其餘 71 個是 chain-of-thought，按完整輸出費率計費，占輸出費用的 88%，而且在 GPT-5.6 上一個字也看不到。本文所有「可見答案」數字都用同樣方式計算。其他模型的比例更誇張：GLM 5.2 回答同一道題，4 個權杖的答案卻產生 217 個 completion 權杖。因此，如果成本模型把 completion_tokens 當成「模型實際說出的內容」，在這裡會高估 8x，在 GLM 5.2 上則會高估 54x。

推理就是預算，而且可以調整

以下是在三個可調整模型家族支援的每種 thinking 設定下，回答同一道單行題目的結果。測試使用同一個閘道，日期為 2026-07-13/14。各家族內的資料依推理量由少至多排列；其餘家族旗艦模型的預設結果則列在下一節。

這張表有四個重點：

• 能調整時，效果很大。 reasoning_effort: none 只花 $0.000062 就答對，比 luna 預設便宜 8.5x；在更困難的任務上，我們也實測過 GLM 5.2 可省 20x。模型層級同樣是調節手段：GPT-5.6 旗艦版回答這道題時，預設完全沒用推理（見下一節）。如果較大的模型不必推理，成本可能反而低於需要推理的小模型。
• 無效時，幾乎調不動。 旋鈕能調整多少是模型家族本身的特性。Sonnet 5 隨設定單調變化，成本相差 5x（84 至 249）；GPT-5.6 變化較小，而且沒有固定順序；Qwen3.7-max 幾乎不受影響（low 仍用了 974 個推理權杖，預設則是 1,096）；DeepSeek V4 Pro 更是完全無效（267 對 269）。
• 標籤不保證單調，預設行為也不固定。 GPT-5.6 的 high 在這次測試中，權杖數反而少於 medium；我們先前的文章也測到 GLM 的 low 比 high 花更多權杖；Sonnet 5 在請求未傳任何 thinking 參數時仍推理了 114 個權杖；完全相同的 GLM 預設請求，一次用了 213 個推理權杖，另一次卻用了 1,312 個，相差六倍。請用自己的工作負載實測旋鈕效果，不要只看標籤判斷。
• 便宜但答錯，是反覆出現的失敗模式。 此處兩個關閉 thinking 的模型家族都答錯（GLM 回答 399，Sonnet 5 回答 467）；下一節會列出五個家族的完整結果。推理是正確率預算，削減它是否划算取決於任務，而不是模型。

實務上的原則很簡單：把 reasoning_tokens 當成獨立成本項目。它按輸出費率計費，通常遠高於可見答案，而且可以透過參數調整，但參數的實際效果必須自行測量。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 個字元）。開發者能讀到每個計費權杖；終端使用者則只有在應用程式顯示時才看得到，而多數應用程式不會顯示。
• GPT-5.6 不提供原始 chain of thought，最多只會給摘要。 Response 可以包含模型撰寫的 reasoning.summary（本次為 359 個字元），但計費的 91 個權杖是隱藏的原始文字，不是摘要。最接近原文的是 reasoning.encrypted_content：這是一段加密資料，可以在多輪對話中原樣傳回以維持連貫性，但你永遠無法解密。你付費購買的權杖就在自己的 response body 裡，卻無法閱讀。
• Claude 要看呼叫方式。 我們以 adaptive-thinking 呼叫 Sonnet 5 時，回傳的 thinking block 文字是空的，但 thinking_tokens 計了 114 個：能證明模型有推理，卻沒有任何內容可讀。Fable 5 在預設永遠開啟 thinking 時也一樣（計費 59 個，block 為空）。然而，對同一個 Sonnet 5 明確指定推理預算後，實際 thinking 文字就會回傳（計費 73 個權杖，而且看得到內容）。呼叫方式會決定你能看到什麼。

因此，計費方式一致，可見性卻不一致：每個模型家族都以輸出費率收取推理費用，但你能否稽核購買的內容，可能是「完整可見」、「只有摘要」，也可能只拿到「有簽章的空白 block」。

只要推理文字有回傳，就能用程式自動評分。我們的題目包含五個固定的中間結果（333、200、66、467、401），而每份回傳的推理文字都包含所有數字：GLM 5.2、DeepSeek V4 Pro、Qwen3.7-max、Kimi K2.7 Code 與 MiniMax 都提供了完整推導，低 effort 版本則各少了一個步驟。對於需要過程而不只要答案的人，差異就在這裡：有 reasoning_content，就能驗證自己付費取得的內容；只有摘要或空白 block，就只能相信模型。看不見的權杖，看得見的帳單 將這項問責缺口形式化，PALACE 則從外部估算隱藏推理量。

各模型家族的最佳模型回答同一道題

前一張表使用特定層級，目的是展示可調整的參數。以下則是每個家族最新的旗艦模型，以預設設定回答同一道題的結果：

各旗艦模型回答同一道題的計費輸出權杖（斜線橘色＝推理占比；綠色＝可見答案）。MiniMax 的星號表示其 usage 未提供推理數量，因此占比由相減重建，並透過回傳的推理文字驗證。GPT-5.6 sol 的勾號表示它是唯一零推理仍答對的執行結果；Gemini 3.5 Flash 的叉號表示它是唯一答錯的旗艦模型（466）。

這張圖涵蓋了所有回報方式：

• 八個旗艦模型中有七個答對，但同樣的 401，價格差異極大。 Qwen3.7-max 用了 1,096 個推理權杖、22 秒與 $0.0084；GPT-5.6 旗艦版完全沒用推理，只花 $0.00031。相同的正確答案，成本差 27x、延遲差 7x，推理預算的影響一目了然。
• MiniMax 回傳推理文字，但不提供數量。 Completion 共 260 個權杖，可見答案只有 3 個。Response 的 reasoning_content 包含完整推導，但 completion_tokens_details 沒有推理分項。缺少數量時，可以用相減重建：completion 減去可見權杖，就是隱藏輸出的數量。
• Gemini 3.5 Flash 是異常值：它是唯一答錯的旗艦模型（466），completion 只有 3 個權杖，而且完全沒有推理數量。它的同系列模型 2.5 Flash 曾花 12.5 秒產生只有 3 個權杖的 401，但帳單完全沒有說明原因；重跑一次後又回答 427。
• 錯誤答案主要出現在較小層級與停用 thinking 的情況。 GLM 關閉 thinking 時回答 399；Sonnet 5 停用 thinking 時回答 467；較舊的 qwen3-max 完全沒推理（3 個權杖），回答 400；Kimi K2.5 沒有 reasoning channel，卻在可見內容中推理了 144 個計費權杖，還在自己的文字裡推導出 401，最後卻得出 400。五個家族給出五種不同的錯誤答案：399、400、427、466、467；只有 GPT-5.6 不推理仍能答對。

快取權杖：兩個方向，價格相差 12x

Prompt caching 會把輸入再拆成兩類。兩者價差正是必須分開記錄的原因：Claude 寫入按輸入費率的 1.25x 計費（1 小時 TTL 則是 2x），讀取則是 0.1x。實測兩次 Opus 4.8 呼叫，使用 1,181 個權杖的快取 system prompt，寫入費用為 $0.01246，讀取則為 $0.00566；兩者都精確符合牌價至小數點後六位，而第二次呼叫的輸入端費用約降為第一次的 1/11。本文關注的是帳務紀錄：如果把 cache_creation_input_tokens 和 cache_read_input_tokens 全部混在「輸入權杖」裡，就無法驗證折扣，也不會發現快取何時悄悄失效。失效頻率比文件描述得更高：我們的快取實測發現，有效門檻比文件標示的最低值高出 1.4 至 2.4x；prompt caching 指南則深入說明各供應商的運作機制。

為什麼本機估算永遠對不上帳單

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

• 每家供應商的 tokenizer 都不同。 用 OpenAI tokenizer 計算送往 Claude 的文字，就像拿錯尺測量；相同字串在每個模型家族上的 tokenization 結果都不同。
• 計費內容不只你的 message。 只要請求包含 system prompt 與 tool schema，它們每次都會算入輸入權杖，本機估算時很容易漏掉。
• 收到 response 前，無法預測推理量。 Client 端無法預測模型會花多少 thinking 權杖；只能從回傳的 usage 得知。

回傳的 usage 物件就是上游供應商自己的計費紀錄，因此最便宜又準確的計數方式，是停止估算，直接讀取它。問題在於每家供應商的結構都不同。光是快取權杖，依模型家族就可能叫做 cached_tokens、prompt_cache_hit_tokens、total_cached_tokens 或 cache_read_input_tokens。

Detail 物件也不是固定 schema。OpenAI 的參考文件列出四個 completion 端欄位：reasoning_tokens、audio_tokens，以及 Predicted Outputs 的 accepted_prediction_tokens / rejected_prediction_tokens；被拒絕的 prediction 權杖永遠不會出現在輸出中，卻仍按 completion 權杖計費。在 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 權杖。解析時要採防禦式設計：未知的 detail 欄位本來就會出現，也不要假設欄位缺失就代表數值為零。Audio 欄位另有自己的成本結構；我們已針對七個專用 ASR 模型，依計費音訊分鐘分別實測語音轉文字成本。

這正是閘道的價值：Synthorai 會把這些格式正規化成同一個物件。無論是 OpenAI、Anthropic、Gemini 或開放權重模型家族，reasoning_tokens 與兩個快取方向的欄位都會填妥，因此只要一套 parser，就能涵蓋所有路由模型。

不只看見成本，還要阻止超支

讀懂帳目只完成一半；另一半是直接阻止超支，而不是等它發生後才看見。月底儀表板只能在錢已經花掉後回報意外支出，陷入重試迴圈的 agent 也不會查看儀表板。在閘道上，每個 key 都有一個 quota，會追蹤 used_quota 並設定 RPM 上限，而且每次請求都會即時強制執行。Key 耗盡預算後，下一個請求會收到明確錯誤，而不是三週後收到更高的帳單。每個請求的歸屬資訊（哪個 key、哪個模型、BYOK 或平台計費）也會放在同一個 response envelope 回傳，因此計算各功能成本只需要 group-by，不必事後重建。

依照實測結果，操作順序應該是：先讀取 reasoning_tokens 與快取欄位，再進行任何最佳化；針對不同任務設定推理等級；只要某個 key 的失敗模式可能形成迴圈，就加上硬性 quota。若要依實際流量估算特定模型組合與各類權杖的成本，可以使用成本最佳化工具，它採用的每權杖費率與本文相同。

← 返回部落格