前沿模型的真實成本:為什麼 $/Mtok 是一個誤</code>

前沿模型的真實成本:為什麼 $/Mtok 是一個誤導性的指標

$/Mtok 指標在不同供應商之間不具備可比性

所列出的每百萬個 token 的價格 ($/Mtok) 並非固定值,因為每個模型供應商都使用不同的 tokenizer 來將原始文本轉換為計費單位。 由於「token」並非固定數量的文本,兩個具有相同列表價格的模型對於相同的輸入可能會產生截然不同的帳單。請求的實際成本是內容轉換後的 token 數量與每個 token 的價格之乘積。

Claude 的新 tokenizer 增加了有效成本

Anthropic 最新的 tokenizer(用於 Sonnet 5、Opus 4.8 和 Fable 5)對於典型的英文和程式碼請求,產生的 token 數量比其前一個版本增加了約 32%,儘管某些模型的列表價格保持不變。這實際上起到了一種價格上漲的作用,而發票上卻沒有相應的項目列出。

不同內容類型的 Tokenization 通脹

使用 Anthropic 自己的 count_tokens 端點進行測量,顯示從舊的 tokenizer 遷移到新的 tokenizer 時,出現了以下增長:

內容 Token 數量變化
English prose +34%
TypeScript +31%
Rust +29%
Python +23%
JavaScript +20%
JSON tool schema +26%
Agent system prompt +39%
Chinese prose ~0%

Sonnet 5 的定價窗口期

Sonnet 5 以 $2.00 / $10.00 的優惠價格推出(低於 Sonnet 4.6 的 $3.00 / $15.00)。雖然這個較低的費率率可以覆蓋增加的 token 數量,但價格預計將在 2026 年 9 月 1 日恢復至 $3.00 / $15.00。在此日期之後,相同的任務量將比在 Sonnet 4.6 上的成本高出約三分之一。

供應商間的 Tokenization 分歧

當使用 GPT-5.x 的 o200k_base tokenizer 作為 1.00x 的基準時,Claude 的新 tokenizer 效率顯著降低,特別是在程式碼方面。 這種差距在 TypeScript 中最大,Claude 對於相同的檔案,產生的 token 數量是 GPT 的 1.73 倍。

Tokenization 倍率 (Claude 新版 vs. GPT-5.x)

內容 倍率
TypeScript 1.73x
Rust 1.58x
JavaScript 1.52x
Python 1.50x
English prose 1.40x
Chinese prose 1.44x

TypeScript 是最糟糕的情況,因為 GPT 的 o200k 對於基於 Web 的語言進行了高度優化,比 Claude 的 tokenizer 更有效地壓縮 camelCase 識別碼和 JSX 模式。

程式碼工作負載的有效定價

「有效價格」是列表價格乘以 tokenizer 分歧倍率。 對於典型的英文程式碼請求,有效成本出現了顯著的分歧:

模型 列表價格 (In/Out) 分歧倍率 有效價格 (In/Out)
GPT-5.1 $1.25 / $10.00 1.00x $1.25 / $10.00
Gemini 3 Flash $0.50 / $3.00 1.09x $0.55 / $3.27
Claude Sonnet 5 (Post-Sept 1) $3.00 / $15.00 1.50x $4.50 / $22.50
Claude Opus 4.8 $5.00 / $25.00 2.00x $7.50 / $37.50
Claude Fable 5 $10.00 / $50.00 1.50x $15.00 / $75.00

超越輸入 Tokenization:總任務成本

輸入 tokenization 僅是總帳單的組成部分之一;模型冗餘度、推理努力程度和緩存策略會導致總任務成本的分歧比 1.73x 的輸入差距還要大得多。

關鍵成本驅動因素

  • Cache Traffic: 由於緩存讀取和寫入是按 token 計費的,效率較低的 tokenizer 會使每次緩存操作的成本增加與輸入通脹的相同百分比。
  • Verbosity and Thinking: 模型生成為達到解決方案而產生的輸出和「思考」token 數量可能會大幅變化。模型對於相同的 agentic 任務,由於內部推理迴圈或較高的冗餘度,可能會使用比其他模型 2-4 倍的 token 數量。
  • Agentic Behavior: 工具調用 (tool calls) 的頻率、每步加載的上下文量以及子代理 (sub-agents) 的使用會顯著影響最終帳單。

社群洞察

使用者和開發者指出,這些差異在大型程式碼庫中感受最為強烈。一位使用者報告,一個約 9 萬行程式碼的舊有 C++ 程式碼庫,在 GPT 上產生了 1.12M tokens,而在 Claude 就產生了 2.2M tokens。其他人則強調,準確預測成本的唯一方法是測量「完成一個任務所需的美元數額」而非依賴於費率表。

比較模型成本的建議

  1. 在具代表性的內容上進行測試: 運行您特定語言和檔案類型的樣本,通過每個供應商的 tokenizer 數量來找出您的個人倍率。 | 2. 監控 tokenizer 定期更新: 將 tokenizer 更新視為價格變動。模型更新(例如, Opus 4.6 到 4.8)可能會導致成本增加約 32%,即使列表價格保持不變。 | 3. Measure Task-Based Costs: 使用供應商的 usage 欄位來計算完成一個任務的成本,這能將 tokenization、冗餘度與緩存策略整合在一個指標中。

Sources